Subject: alt.lang.focal

From: [email-masked] (Crystobal J. Junta)
Date: 10 Nov 1993 22:03:50 GMT

So, shall we call for votes on the creation of alt.lang.focal?
Also, on an unrelated note, anyone knows of a pdp-8 emulator in
a public domain?

Thanks.

-- 
****************************************************
*    Live from New York, it's Saturday Night!!!    *
****************************************************
*  To err is human; to forgive is not our policy   *
****************************************************
* Grigory Golberg            [email-masked] *
****************************************************

---

From: [email-masked] (Megan)
Date: Mon, 22 Nov 1993 07:59:19 GMT

>Also, on an unrelated note, anyone knows of a pdp-8 emulator in

I have one which I got from the net some months ago.  I don't
remember from where, but the following is the README which comes
with it, it may help.

- - - - -
This is the source for a simple, curses-based PDP8 simulator. It was
written by Neil A. B. Gray for use with his book,

    N.A.B Gray, "Introduction to Computer Systems," Prentice-Hall,
       Australia, 1987.

    US ISBN 0-13-480386-8

Neil tells me that it implements all of the PDP8 instruction set,
including the less well-known combined opcodes. It also supports
a simplified collection of I/O instructions (simulating disks and
such).

The code is in the public domain, but if you're going to use it,
port it to X windows, or whatever, it would be nice if you
credited Neil with the initial creation. Why not send him a postcard?
His address is

        Associate Professor N. A. B. Gray
        Department of Computer Science
        University of Wollongong
        PO Box 1144
        Wollongong NSW 2500
        Australia

or via email:

        [email-masked]

***************************************************************

The files in this archive are:

README          this file
assmblgo.c      assemble and go
exec8.c         the simulator
exec8.p         pascal version of the above
oldtrace8.c     older version of the simulator
smap.c          Simple Minded Assembler Program
smap.p          pascal version of the above
symbols
trace8.c        Simulator with tracing
trace8.p        pascal version of the above

***************************************************************

---

From: [email-masked] (Megan)
Date: Tue, 23 Nov 1993 01:52:05 GMT

[email-masked] (Adam Justin Thornton) writes:

>In article <[email-masked]> [email-masked] (Megan) writes:

>Sounds great, but, well, ah, where is the archive to be found?

As I mentioned, I don't know where I got it from, but with the
author's address in the readme file I listed, you might contact
him directly (maybe he's got an even more up-to-date version).

                                        Megan Gentry

---

From: [email-masked] (Charles Lasner)
Date: 25 Nov 1993 18:31:49 GMT

>remember from where, but the following is the README which comes

[description deleted]

Sorry, but that's not a "complete" emulator!

To really be a PDP-8 emulator that "matters" you need all of the following:

1)	Some means of loading/saving the contents of 4K of memory arbitrarily
	within the host file system.

2)	Total support of any of the 4096 possible instructions, not just the
	most likely combinations.  Real programs execute far more than the
	referenced program allows.  (Note: PDP-8 programs do occasionally
	execute instructions that "make no sense" because the instructions are
	used to form constants.  The inclusion of an innocuous micro-coded bit
	into an OPR instruction could form a needed constant, and the constant
	could be placed in line after another instruction that might skip to
	"protect" it.  For example:

	SDN			/SKIP ON DONE, CLEAR DONE FLAG ON RX8E
L7770,	SPA SNA SZL CLA		/THIS CAN BE SKIPPED BUT WON'T ITSELF SKIP!

This sequence clears the RX8E done flag, yet prevents problems executing the
code that would follow, since the worst thing that could happen is that the
AC would be cleared.  (Note, the AC would already be cleared, which is why the
instruction can't skip!)  And the program could require the constant 7770, so
instead of using an ordinary NOP (there are three of them!), the constant is
executable, etc.  A proper PDP-8 emulator must handle these cases correctly!

3)	It must have unconditionally-compatible support for the device 03/04
	console terminal.  This means a glass TTY: that does CR and LF
	correctly, and doesn't demand ^S/^Q support from within the emulator
	since much of the (especially early) PDP-8 code ran from synchronized
	asynchronous terminals.  (Meaning that the terminal's printing speed
	was the same as the interface baud rate.  No protocol is required in
	that situation, just merely to tend to the interface itself, etc.)
	(Note also that OS/8, unlike P?S/8, is similarly deficient in this
	area!  OS/8 has a two-page handler called KL8E which *does* handle
	the DC1/DC3 protocol, but its usage is optional, and further many
	OS/8 programs do their own output without the handler!  Virtually all
	programs that do their own terminal I/O do not handle ^S/^Q.  Contrast
	this with P?S/8 where *all* system programs do handle ^S/^Q correctly.)

4)	PDP-8 interrupts must be handled in a realistic manner.  This means
	that interrupts, if enabled, must cause overlap of background and
	foreground processing.  The pitfall is that the console output flag
	could virtually always be up causing interrupt servicing and no
	effective background processing.  Thus, you get all of the overhead of
	interrupt handling, and none of the benefits.  (Note: on the DECmates,
	the use of device 04 interrupts is not recommended for this very
	reason!  Essentially, when TLS is performed, it is trapped and the
	PDP-8 CPU doesn't run!  CP memory routines are enterred that talk to
	the built-in video hardware to emulate the latest character outputted
	to the VT-220 screen; this operation could take several milliseconds,
	etc.  Once the screen operation is finished, the PDP-8 program is
	re-enterred, but the console output flag is now raised!  Thus, by
	the time the PDP-8 program runs again, the flag has magically raised
	in no CPU cycles!  Thus, if interrupts are used, only interrupt
	handlers run until there is no more output to process.  All of the
	output buffering code is wasted!  Faster throughput is achieved by
	never using interrupts and assuming the flag is always up (which is the
	recommended procedure for DECmate-specific programming).)

	Since so many PDP-8 programs run without interrupts, a desirable
	feature could be to disable them, since the emulator would likely run
	faster that way, but interrupts are necessary for programs such as 
	FOCAL that use them effectively, etc.  The best way to implement this
	is that the emulator have alternate "engines" for interrupt and
	non-interrupt operation switchable as required.  This eliminates the 
	need to test whether interrupts should be polled; execution of the
	emulated ION and IOF instructions would switch engines, etc.  Thus,
	the fastest emulation of non-interrupt code is achieved this way, and
	also the fastest, albeit slower, emulation of interruptible code.

5)	The emulator must pass all of the diagnostics of some specific model,
	preferably the PDP-8/e.  (There are programs that require the 8/e
	instruction set.)  Additionally, model-dependent quirks must be handled
	carefully, so that programs that check for this are satisfied.  Thus,
	a proper emulator of a PDP-8/e mustn't handle certain operate cases
	the way a DCC-112 would, since that would make FOCAL-8's DCC virus-bomb
	code wake up and self-destruct the program!  FOCAL, 1969 attempts to
	identify the CPU it's running on, and it would be proper to accomodate
	that code correctly.  (Note: FOCAL, 1969 uses this code to handle
	problem cases such as the PDP-5 and -8/s.  The rest is part of a frill
	of model identification.  There is a bug in the code that confuses the
	-8/i and -8/l because it depends on an unreliable test: The -8/i, -8/l,
	and -12 all share a common quirk, the ability to execute NL3776, which
	depends on the quirk that when you rotate in both directions, the end
	most bits get cleared.  The -12 is properly tested for LINC mode
	presence, thus eliminating that case, but there is no CPU check for
	the difference between -8/i and -8/l.  Instead, the console is assumed
	to be 110 baud teletype!  Using the TTY output flag as a "clock", a
	series of 6000 (I/O NOP) instructions is executed.  Assuming the -8/l
	to be slower, then the TTY output flag will be raised by this point,
	unless it's an -8/i in which case it isn't raised yet.  Of course the
	test is invalid because the console flag could raise sooner because
	the console is faster than 110 baud, or because the -8/i memory is
	tuned slower than the nominal speed of an -8/l, which is often the
	case.  -8/l's generally used better memory that more likely satisfied
	their requirement for a slower machine.  Earlier -8/i memory was
	actually inferior and generally demanded slowing the machine down to
	even slower than an -8/l!  Thus for either reason, the test can come
	up wrong between these two!  There is a fix I discovered which is
	used within P?S/8 and also in Kermit-12: The -8/l executes the 
	instruction 7601 as a NOP contrary to all other -8 models.  This is
	because all EAE instructions are inhibited, even this innocuous one,
	which will merely clear the AC on an -8/i or -12.  Thus, the simple
	test is to load the AC and test whether it was cleared by 7601
	execution.  If not, it's an -8/l; all the rest of the model discovery
	then becomes straight-forward, etc.)

6)	Additionally, it would be nice to have EAE added to the emulator.  Many
	programs come in a form with EAE required or emulated by inefficient
	-8 code.  Clearly emulated EAE is faster if performed by the host
	emulator than by emulated -8 code!  Note that -8/e EAE is much more
	complex than -8/i,-12 EAE.  (-8 EAE is a subset of -8/i EAE missing
	one operation that loads the step counter.  To fake it, the EAE
	diagnostic for the -8 performs a normalize operation with a predictable
	step counter result, then reads it back to compare the result to the
	expected value.  On the -8, this method must be used if the step 
	counter must be loaded to an arbitrary value, presumably as a result of
	using EAE both in background and foreground and specifically in an
	interrupt dismissal routine, etc.)  Note that EAE is specifically
	unavailable on all models besides the -8 and LINC-8, -8/i and -12,
	-8/e,f,m, or any -8/a box with the -8/e CPU cards (KK8F).  Additionally
	the EAE of certain DCC machines is incompatible because it implements
	the EAE instruction set of the first PDP-8/e Handbook (1971) which
	was never made available by DEC.  (Rumor has it that DEC published
	this false EAE specification as a red herring to make DCC waste its
	resources, then produced the larger -8/e EAE set as we know it.  The
	DCC set implements instructions that never existed on DEC machines such
	as NMU (unsigned normalize), etc. while DEC implemented compatible
	EAE with mode B extensions such as double-precision, etc.  Thus DCC EAE
	cannot be used on any DEC program, while any mode A program can run on
	any DEC machine with EAE!)

7)	A useful feature would be to support the reader/punch (02/03) as a
	pair of files in the host system such as reader.bin and punch.bin.  The
	reader flag would always raise in response to RFC unless at EOF.  Punch
	output would always be appended to the punch output file as a series of
	8-bit characters, etc.  Assuming that the file reader.bin would be a
	series of 8-bit frames from the original paper-tapes, we already have
	a series of utilities to transfer programs in binary-paper-tape form to
	other systems where a host emulator could be run, such as a PC.  These
	files are being archived on sunsite.unc.edu to form a PDP-8 diagnostic
	library, etc.  Any system that can run the .BOO-format utilities that
	exist for OS/8, MS-DOS, VMS, unix, etc. can transfer PDP-8 binary files
	this way.  Note that any OS/8 .SV program can be converted to binary
	using the SV2BN.SV utility and then sent via this method, etc.  Using
	Kermit-12 on an OS/8 system, the files can be sent via Kermit to other
	systems, etc.  ASCII files can be sent directly, binaries can be first
	converted to .BOO files, and image files can first be converted to
	binary files with SV2BN.  Thus, any OS/8 file can be stored on another
	system as a .BIN file as long as the OS/8 system at the other end (even
	an emulated one!) can be used to decode the file into its original
	form, etc.

	It is note-worthy that certain systems (such as Poly Basic) are
	distributed on paper-tape, which when loaded causes a system to appear
	on an RF08, etc.  Thus, the reader support is needed to create the
	RF08 images!  This also applies to the Disk Monitor System (assuming
	there are masochists out there that want to run this!) which can only
	run on devices that can be expressed as records of 129 12-bit words
	such as the RF08, and is distributed on paper-tape, etc.  There even
	exists a version of the SABR/Fortran that uses a swapping linking
	loader explicitly for the DF and RF version of the DMS, etc.

8)	A truly useful emulator must support extended memory. 32K is standard,
	but support for the three additional methods should be considered.
	These are DEC's KT8A which allows 64K and 128K maximum modes, and the
	CESI MEC8 which allows 128K and 512K maximum modes.  (From an emulator
	point of view, all CESI modes are the same; the difference is that the
	CESI 128K max mode is hardware compatible with the KT8A, albeit not
	software compatible.  The CESI 512K mode requires CESI-specific memory
	modules DEC never made, etc.  Thus, CESI programming must look for
	memory sizes of 32K, 64K, 96K, 128K, 256K, 384K, 512K, but all of the
	programming methods are identical, etc.)

9)	A truly useful emulator must support a disk device, preferably one that
	really exists on an actual PDP-8 model.  There are two preferable
	devices to emulate:

	a)	The RF08 is a standard device that all PDP-8 systems support,
		and the maximum normal configuration is the size of a single
		full-size OS/8 logical device (4096 records of 256 12-bit words
		on 4 platters).  There exists an obscure version of the RF08
		that includes the DV08 option that uses up to 8 platters that
		can be trivially supported by OS/8.  Since these are DMA
		devices, it is easier for the emulator to handle them, since
		most of the work doesn't involve cycle emulation, etc.  The
		best way to handle RF08 emulation involves the use of an RF
		image file, preferably a RAM-disk.

	b)	The MDC8 is a CESI device that is an intelligent SCSI host
		adaptor for the Omnibus.  Coupled with SCSI controllers and
		drives, there exist systems with bootable hard disks of a
		large size, and also bootable HD 5.25" and 3.5" diskettes.
		Some systems even support SyQuest removable cartridge disks
		which are now available for up to 105 MBytes/cartridge.

		The emulator advantage of the MDC8 is that all of the work is
		normally off-loaded to an on-board micro that communicates with
		the -8 via DMA.  Thus, the emulator can read the memory of the
		emulated -8 and proceed to perform the indicated SCSI command
		to available devices, possibly in actual form, depending on the
		host configuaration.  (For example, a PC with an SCSI adaptor
		could issue the precise commands to a SyQuest drive that the
		actual -8 would, and cause the identical action, merely having
		to transfer memory data into/out of the PDP-8 memory to mimic
		the MDC8's DMA activity, etc.  In this way, a SyQuest cartridge
		could be bootable both on the actual PDP-8 and also on the
		emulated one!)

		Practical configurations of MDC8 I have access to support a
		slight variant of the standard IBM-PC 5.25" HD diskette format.
		Thus, a PC-based -8 emulator could support this format as well.
		This allows a single diskette to be moved between an actual
		PDP-8 and an emulated one.  (Note: newer Mac systems can
		support the 3.5" variant format to achieve the same level of
		inter-compatibility using HD diskettes, etc.)

	Thus, the MDC8 represents the best overall device to emulate, since
	it's not limited to non-dismountable devices of modest storage size,
	and can also support transferable media.  Both the RF08 and MDC8 allow
	for a low-overhead emulation, etc.

10)	Some people have requested graphical emulations of front panels, etc.
	Towards that end I would recommend something like the PDP-8 MARS panel
	or even the PDP-12 console, which is the most elaborate, or even the
	LINC-8 panel which has more registers displayed, etc.

	Note that most emulators will be running on machines where the
	underlying memory is wider than 12-bits.  This allows various debugging
	aids to be added such as fetch trap, exec trap, write-exception, etc.
	Also usage counts can be added to help optimize code, etc.

11)	Additional peripherals can be supported, such as fancier terminal
	emulations, and also analog hardware.  A most useful addition would be
	an analog display.  Assuming a PC-type machine with VGA, the VC8E could
	be emulated.  Periodically, display elements are moved from the screen
	as the emulated -8 code adds them on.  If fine tuning is allowed, a
	realistic display can be achieved.  On such a system, it would be
	possible to play the games MOONLANDER and POLY SPACEWAR.  (These
	programs run on the following hardware: 4K -8 with EAE, 03/04 terminal,
	analog display such as the VC8E, some form of pair of 4-bit input
	devices such as switches in parallel with the console switch register
	or connected to a DR-8E digital input register, etc.  Perhaps someone
	can invent a suitable alternative for the input box, which perhaps
	could be implemented as an actual pair of boxes connected to the
	parallel printer port!)

	Support of the RF08 and paper-tape, coupled with emulation of the 
	time-share trap option, allows the running of TSS8, which some people
	have interest in, etc.

So, to make a successful emulator, it takes a bit more than the referenced
program!

cjl

---

From: [email-masked] (Greg Ewing)
Date: Thu, 25 Nov 1993 22:48:28 GMT

Hey, great! Someone shares one of my weirder interests!

A few years ago I wrote a PDP-8 emulator that ran under SunView
and had a nice big GUI front panel. I got as far as emulating the
basic machine plus a TTY device. I had plans for a DECtape emulator
complete with animation of spinning tape reels, but other activities
intervened.

Recent discussions here have rekindled my interest. I may be
persuadable to resurrect the project - see below...

|> To really be a PDP-8 emulator that "matters" you need all of the following:
|> 
|> 2)	Total support of any of the 4096 possible instructions, not just the
|> 	most likely combinations.

Well, my emulator was based on the description of what each bit in the
OPR instruction was supposed to do, and didn't put any restrictions on
combining them. Never having used a real 8, however, I wouldn't know
about any combinations with "undocumented" effects which couldn't be 
deduced by reading the manual.

|> 3)	It must have unconditionally-compatible support for the device 03/04
|> 	console terminal.  This means a glass TTY: that does CR and LF
|> 	correctly, and doesn't demand ^S/^Q support from within the emulator

As far as I remember it used a serial port in raw mode, and didn't do
anything special with any character - is that good enough?

|> 4)	PDP-8 interrupts must be handled in a realistic manner.

I don't remember if I got around to interrupts. I may have provided
the mechanism in the emulator, but I didn't get around to implementing
any interrupt-driven devices.

|> 5)	The emulator must pass all of the diagnostics of some specific model,

If anyone can send me or point me towards a sufficiently interesting
body of genuine PDP-8 software, I may be persuaded to develop an
X-windows version and attempt to make it run all of the aforementioned
software correctly.

I am willing to make the results of such a project freely available
in exchange for some neat software to run on it. Actually I'm willing
to do that anyway, it's just that if I have some neat software it'll
greatly increase the chance that I'll do something about it!

|> 7)	A useful feature would be to support the reader/punch (02/03) as a
|> 	pair of files in the host system such as reader.bin and punch.bin.

What I think I would do is have the basic emulator communicate with
device emulators via pipes, so that new devices could be plugged in
easily. One of the devices could be an adaptor to make a file
look like a character device.

|>      These
|> 	files are being archived on sunsite.unc.edu to form a PDP-8 diagnostic
|> 	library, etc.

Sounds great! Is it just diagnostics, or are there any operating
systems, interpeters, games, etc. there too?

|> 10)	Some people have requested graphical emulations of front panels, etc.

That's half the fun! Especially now that I can do it in colour...

|> cjl

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of Japan Inc.|
[email-masked]	   +--------------------------------------+

---

From: [email-masked] (Megan)
Date: Sun, 28 Nov 1993 19:59:54 GMT

I've been working on the emulator I mentioned, adding such things
as producing 'assembly' listings, adding some more symbols, allowing
multiple statements per line (separated by ';').

I'm currently working on allowing pc-relative (.{+|-}symbol) and
'label-relative' (label{+|-}value).

Basically, I'm trying to allow the assembler front-end for the
program to recognize as much of the pal8 syntax as possible.

Back with I programmed -8's, we didn't have a disk and I hadn't
learned how to use the assembler, so I did all of my coding by
hand and toggled the programs into the 8/I directly.  So I have
to admit not being as knowledgable about pal8 syntax as I'm sure
most here are (not to mention I didn't do any interrupt programming
so didn't know how the interrupt system worked, nor did I even
know about the auto-index registers - but I'm 'catching up' on
this knowledge now) so I would like to ask if someone has a
pal8 document on-line that they could forward.

I'm also going to be looking into the emulation and see if it
really does handle the microinstructions correctly.

					Megan Gentry
					Former RT-11 Developer

---

From: [email-masked]
Date: Mon, 29 Nov 1993 04:03:58 GMT

>From article <[email-masked]>, by [email-masked] (Megan):
> 

My PDP-8 assembler is now up and running reliably enough that I'll make
it widely available. I've been using it to write RX01 diagnostic code,
complicated enough stuff that the assembler has seen reasonable exercise.

At the same time, I've been adding an RX01 to my emulator.  The emulator
will be released when I get a rudimentary X-windows front panel up and
running-- enough that you can toggle in a RIM loader and mount files
as emulated paper tapes on the high speed reader-punch.  The RX01
will come later.
				Doug Jones
				[email-masked]