Subject: 6100/6120 chips, "Modern" -8 hardware, and other thoughts

From: [email-masked] (Bob Armstrong)
Date: Sat, 8 Jan 1994 01:20:00 GMT

Some miscellanous ramblings on 6100/6120 chips, building modern
PDP-8 hardware, and other ideas:

  Around twelve years ago, I built a PDP-8 based on the 6100 family
of parts.  It occupied four S-100 cards - a CPU (6100, 6102 MEDIC,
ROMs for control panel memory), 8K SRAM, a VT-52 compatible terminal
(built around an 8085), and a I/O card.  The latter included serial
and parallel ports, as well as a Kansas City audio cassette interface
that (approximately!) emulated a high speed reader/punch.  Worked
great - I used to run FOCAL on it all the time.

  Today I could easily get all of that, along with 32K RAM and
floppy/hard disk interfaces, on one small card (but I'd leave out
the audio cassette :-).  I frequently think about doing it too -
the original one was a lot of fun to build and there might even
be other PDP-8 lovers out there who would  like to buy or build one.
But I can't help but wonder whether such a project really makes sense.

  First, the 6100 and 6120 family chips are hard to get.  The only
sources I know of today are old DECmates - a VT78 will yield one
6100, and a VT278 (DECMate-I) will give up one 6120 and two 6121s
(and they're even socketed!).  I don't know exactly what's inside a
DM-II or DM-III, but there's at least a 6120 and some 6121s in both.
For a 6100 based system you really want the 6102 as well, but these
were never used in DECmates.  Are there any other sources for these
chips ?

  Second there is a speed problem.  The 6120 was reasonably fast (as
I remember, comparable to an 8/A or E), but the 6100 was quite
slow.  In either case, I wonder whether a 33 or 50 Mhz 486 PC with
an efficiently coded emulator couldn't execute PDP-8 instructions
faster.  And the PC would be cheaper too!

  Or if the 6120 really was faster than a PC based emulator, perhaps
it would be better to just build a 6120 based APU (auxiliary processor
card) that plugs into a PC.  This would give you a hardware accelerator
for your PC based PDP-8 emulator.  It's also somewhat ironic - the
DM-II could accept a 8088 PC APU card, and now we're talking about
a 6120 DECmate APU card for a PC!

  And in wilder moments, I even wonder how many modern FPGA chips
it would take to implement a PDP-8 ISP (instruction set processor).
One, perhaps ?  And how fast could it run ??  Maybe the 6100 and
6120s are completely useless now...

  Please post any comments you might have.

Bob

-- 
Bob Armstrong <[email-masked]>

---

From: [email-masked] (Charles Lasner)
Date: 9 Jan 1994 10:55:46 GMT

>great - I used to run FOCAL on it all the time.

I have heard from others doing a vaguely similar project.  They also have
problems getting 6100 chips, but went in a slightly different direction:

They made a printed circuit eurocard version.  A real serial port to a
real terminal is reasonable considering what the actual 03/04 console
requirement actually is.  32K, a minimal CP memory, but they built their
own memory controller.  There are two problems with the MEDIC chip: 1)
It's not completely compatible with the -8; that's (partially) why DEC
never used it in the VT-78, 2) It is too "busy" trying to be a sort-of DMA
controller that's really an attempt at dynamic RAM support instead of just
being an extended memory controller and related instructions, etc.
Moreover, they wanted to implement the time-sharing trap which is absent! 
PIE chips can be used to implement a roll-your-own disk device interface;
I volunteered to guide them through the software side of a viable
interface to run P?S/8 and OS/8 on it, etc.  They were open to rolling
their own disk interface sans PIE chips if need be; they already did the
03/04 and memory controller stuff using some form of PLA variant, etc.

The speed is slow by PDP-8/e standards, but fast by VT-78 standards,
because DEC's design never used the standard grade of 4.0 MHz 6100's! 
Instead they used the "commercial" grade-out, and then ran it even slower
than the nominal 3.3 MHz, but rather at something like 2.5 MHz, using
dynamic RAM, etc.  (DEC also rolled their own interfaces, etc; all are
compatible with 8/e.)

>But I can't help but wonder whether such a project really makes sense.

I wouldn't bother with the 6100.  The 6120 is faster and more complete. 
There are few incompatibilities as long as you avoid the 6121 which is the
downfall of the DECmate.

>were never used in DECmates.  Are there any other sources for these

The DM II has two 6121 and a 6120 and several CMOS UART's  The DM III
and III+ don't have the 6121 at all, as DEC bothered to make VLSI chips to
replace them.  Curiously, the replacement chips are unnecessarily different:

In the DM II, real 6121 are used for all interfaces except for the part
that interfaces to device 14 (APU/XPU) and the RX and the graphics, which
is partially DMA.  (The terminal is also a separate interface that is part
two-way video RAM.)  The DM II ROM initializes the 6121 chips to be 5 real
memory interfaces and 5 CP memory interfaces (meaning they kludge their
interrupts to goto CP memory and make them non-responsive from main
memory).  The desired device codes are downloaded just like it says in the
6120/6121 spec sheets, etc.

But in the DM III family, there is no initialization code!  Instead, there
are two similar yet different VLSI chips.  These chips are made to already
respond to the designated codes the way the 6121 are initialized to in the
DM II.  Since there is so little difference, it's a wonder that DEC
bothered to bundle in the slight addressing differences at all, since that
means that two VLSI chips had to be created where a single design could
have sufficed!  (Note: clearly the software people were cooperative to the
design, since they did have to change their ROM software - the init code
had to be excised!  It's not like you were asking them to write anything new!)

In any case, you aren't going to get too much cooperation in
canniballizing DECmates to give up chips!  These systems are too
"complete" to ask someone to give them up for what could merely be a
half-baked project, and in any case likely lacks the electro-mechanical
completeness of the DEC box!  We've made too much of a committment to
supporting the DECmates by improving the software! 

But it is tempting (for me!) to be able to work on a 6120-type system
minus all of the incompatibilities introduced in the DM's.  The 6120 is
close enough to the -8/e to not be a problem (although there are
picky-picky differences such as the GTF/RTF sequence, etc.).  It would
really be nice to have loadable CP memory not bogged down in trying to
(poorly) emulate a VT-220 (which at best causes real-time headaches!) and
also (poorly) emulating the 03/04 interface (incompatibly!  Yes, the
purpose of the CP memory code of the DECmate is to emulate an incompatible
console!  The emulated device would be what would happen if a real
terminal would be connected to a serial interface on device 03/04 of a
6121, not the standard PDP-8!  Moreover, this is hopelessly broken because
not all of the 03/04 instructions are trapped, only the ones that have to
be to achieve this lesser goal :-(.).

>faster.  And the PC would be cheaper too!

This touches on a different matter:  The performance of the emulators that
are either existent or are in some position to be hoped for completion
(please ignore "pie-in-the-sky" people who merely talk about these things;
there really are a few hardy individuals who really do write the code!)
leaves a lot to be desired. 

Part of the problem has to do with getting the emulator to run under the
"hostile" MS O/S, etc., part of it has to do with the over-rated nature of
many "modern" architectures which are rated in terms of how many
fastest-NOP's they can execute, not a mix of useful instructions (MIPS =
Meaningless Instructions Per Second), and part has to do with overhead
introduced by using abstract languages instead of assembler, because all
of the current emulators suffer from at least a partial agenda of keeping
the code "portable".  (Note: portability is a relative term, since some of
the emulated interfaces are by nature non-portable!  For example, one
PC-based emulator requires the specifics of the PC 5.25" floppy interface
so that it can emulate various *real* PDP-8 and DECmate interfaces, i.e.,
so you can actually boot *real* PDP-8 diskettes on the emulator as well as
on an -8 or DECmate.  What's the point in writing the code for that aspect
of the device in a "portable" way?)

Using the guidelines of past emulators, it would appear that in theory
these programs could rise to the occasion of executing -8 instructions
significantly faster than the -8/e or whatever.  However, the current
expected performance leaves much to be desired, thus only by brute force
will it be marginally true.  Presumably by applying a lot of optimization
techniques (meaning writing a lot of ASM code!) it won't be necessary to
have high-end PC's barely being able to emulate the clock speed of a 1971
version of an -8.

(Note: For those of you who are about to vigorously reply to this, note
that only a *complete* -8 emulator qualifies for this comparison, not some
out-of-context code fragment of the "heart" of an emulator.  A full
emulator has to arbitrate CPU cycles of various types, DMA cycles, and
interrupt cycles, realistic timing ratios of all of the above, and perhaps
CP memory cycles, and maybe even overlapped operations of an FPP and/or a
VT8E, etc.  Moreover, you have to factor in how much worst-case latency
the PC tends to throw in while your code gets interrupted by something
else!)

>a 6120 DECmate APU card for a PC!

The DM II takes an APU or XPU card.  The APU is a Z80 and 64K.  The XPU is 
a Z80, an 8086, and either 256K or 512K where the Z80 windows its 64K
space into the larger 8086 space.  The board is designed to work with a
daughterboard which is the APU or XPU.  The XPU in turn has a
grand-daughter board which is either the 256K one or a board that can hold
512K or 1 MBytes, but the 1 MByte is never implemented.  (Lots of
unpopulated RAM chip lands!)

>6120s are completely useless now...

This is perhaps a better way to go.  Anyone want to comment on the speed
ratio of FPGA chips to the best expectation of an emulator?

>  Please post any comments you might have.

Anyone else out there in the PDP-8 "peanut gallery"? :-)

>Bob

cjl

---

From: [email-masked] (Bob Smith)
Date: Mon, 10 Jan 1994 15:21:02 GMT

Bob,
for my two cents worth:
with the right set of pieces you can build a simple and fast pdp8.
a 10MHZ version would be easy easy easy,
a twenty mhz would also be easy thanks to new memory speeds..

It might no it really would be an itnerseting project to do...

I wonder if we could put together a pipelined 8...
hmmm
bob

---

From: [email-masked]
Date: 10 Jan 94 10:31:59 MDT

In article <[email-masked]>, [email-masked] (Charles Lasner) writes:
> also (poorly) emulating the 03/04 interface (incompatibly!  

If you're willing to give up the hard disk (!), you should be able to build
a compatible console interface attached to the hard disk connector. Then
change the ROMs to remap the 03/04 device out of the way, and you're off.

> Anyone else out there in the PDP-8 "peanut gallery"? :-)

I guess that'd be me...
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
[email-masked] |     'obsolete-ready'

---

From: [email-masked] (Charles Lasner)
Date: 11 Jan 1994 02:10:17 GMT

>change the ROMs to remap the 03/04 device out of the way, and you're off.

The APU socket I think is already too dedicated to being only device 14. 
Obviously the code itself can be changed, but I think only only one device
can go there.  The graphics socket has DMA, but I think is also too tied
in to being one device code.  Thus, the hard disk socket is the choice
because enough signals are present to roll-your-own.  (What we need is a
peripheral buss that plugs in here, and of course some compatible
peripherals!)

Of course, if the console plugs into the HD/RX socket, an alternate disk
controller could be made for device 14, thus no apu/xpu, but you do get
back a disk.  And those two dummy 03/04 devices can be mapped away as you
indicate, etc.

Note that this is hopeless for the III family though :-(.

cjl

---

From: [email-masked] (Huw Davies)
Date: Tue, 11 Jan 1994 10:39:57 GMT

>>PDP-8 hardware, and other ideas:
    [Lots deleted]
>Anyone else out there in the PDP-8 "peanut gallery"? :-)

Nibble, nibble, nibble (Oh, not those sorts of peanuts :-)

I think that there is little point in building a 'modern' pdp-8 using
either 6100 or 6120s - not enough performance. You might as well get a
real -8 (Yes, mine now runs fine and as soon as I've stopped playing
with this 11/44 I'll get to finish setting the -8 up).

It would be a lot of fun to build a bit-slice version of an -8 to see
how fast it would go. It would certainly keep me busy during the cold
wet weather we get during winter (What, it's summer at the moment! Could
have fooled me!). 

The design should be simple enough that it could be used as an
illustration of how to build a computer for the younger generation that
seem to think that all computers (both past and present) come in a chip.

-- 
  Huw Davies           | [email-masked]
  Computing Services   | Phone: +61 3 479 1500   Fax: +61 3 479 1999
  La Trobe University  | I own an Alfa to keep me poor in a monetary
  Melbourne Australia  | sense, but rich in so many other ways

---

From: [email-masked]
Date: 12 Jan 94 10:25:19 MDT

> wet weather we get during winter (What, it's summer at the moment! Could

I've long thought that it should be possible to build a PDP-8 in a large
Xilinx. Although I've done some fiddling about with designing bits and
pieces, I haven't gotten serious enough to do it.

OK, I'll fess up. My fiddling about has really been designing PDP-5 pieces
to fit in a Xilinx. Having the PC in memory location 0 means the interrupt
controller can be moved off the CPU (it's just a special sort of DMA
device, you see...). I just haven't found out enough about how the PDP-5
takes interrupts to be able to design the interrupt controller yet...
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
[email-masked] |     'obsolete-ready'

---

From: [email-masked] (Charles Lasner)
Date: 14 Jan 1994 11:37:07 GMT

>takes interrupts to be able to design the interrupt controller yet...

Are you referring to anything more than the notion that -5 interrupts are
one address higher than -8 interrupts?

IntSavePC -> 0001
restart at 0002

Whereas all -8's have
IntSavePC -> 0001
restart at 0001

So, it just means to move c(0000) -> c(0001) and put 0002 -> c(0000) on
the -5.  (Or perhaps put 0001 -> c(0000) depending on timing.  Note that
to get to ADDR, ADDR-1 -> c(0000) is what FOCAL, 1969 does to prove it's
running on the -5.)

cjl

---

From: [email-masked]
Date: 14 Jan 94 13:56:30 MDT

> one address higher than -8 interrupts?

That's what I was referring to. Didn't know where stuff was stashed or where
it went.

Thanks.

---

From: [email-masked] (Charles Lasner)
Date: 16 Jan 1994 10:47:49 GMT

>That's what I was referring to. Didn't know where stuff was stashed or where

Easiest place to look is in Focal, 1969.  Code to the effect of the
following is in there:

	TAD	(IAM5-1)	/GET DETERMINING ADDRESS
	DCA	0000		/STORE IN PC
NOT5,	CLA IAC			/CONTINUES HERE IF *NOT* PDP-5
	DCA	CPUTYPE		/CPU IS AT LEAST PDP-8
	TAD	(JMP I	0002)	/SETUP THE
	DCA	0001		/INTERRUPT HANDLER
	TAD	(INTHND)	/GET ADDRESS OF INTERRUPT ROUTINE
	DCA	0002		/STASH THE POINTER
	TAD	(JMP I	0000)	/SETUP THE INTERRUPT EXIT
	DCA I	(DISMISS)	/INSTRUCTION FOR ALL -8'S
	JMP	COMMON		/CONTINUE THERE

/	CAN ONLY GET HERE IF PDP-5 CPU.

IAM5,	DCA	CPUTYPE		/CPUTYPE=0, PDP-5
	TAD	(JMP I 0003)	/SETUP THE
	DCA	0002		/INTERRUPT HANDLER
	TAD	(INTHND)	/GET ADDRESS OF INTERRUPT ROUTINE
	DCA	0003		/STASH THE POINTER
	TAD	(JMP I	0001)	/SETUP THE INTERRUPT EXIT
	DCA I	(DISMISS)	/INSTRUCTION FOR -5
COMMON,	NOP			/DO COMMON STUFF HERE

/	INTERRUPTS HANDLED HERE.

INTHND,	DCA	ACSAVE		/SAVE AC
	RAL			/GET LINK
	DCA	LSAVE		/SAVE IT
	KSF			/KEYBOARD FLAG UP?
	JMP	OTHERS		/NO, TRY OTHER FLAGS
	KRB			/YES, GET THE CHARACTER AND CLEAR FLAG
/	HANDLE STUFF HERE
	JMP	INTXIT		/GOTO COMMON EXIT

OTHERS,	/OTHER FLAGS HANDLED HERE.

INTXIT,	CLA			/CLEAN UP
	TAD	LSAVE		/GET SAVED LINK VALUE
	RAR			/RESTORE IT
	TAD	ACSAVE		/RESTORE AC
	ION			/TURN ON INTERRUPTS
DISMISS,JMP I	0001		/RETURN TO INTERRUPTED PROGRAM
				/WILL BE JMP I 0000 ON PDP-8
				/WILL BE JMP I 0001 ON PDP-5

In essence, FOCAL reserves locations 0000-0003 for interrupts where family
of 8 programs only reserve 0000-0002.  The highest address is used to
point to the interrupt-handling address and the previous address is where
control is taken from.  The address prior to that one is where the saved
PC goes during the interrupt grant process (which on the PDP-5 is 0001,
*not* 0000; and on the -5, 0000 is actually the PC stored in memory).

Note that it is merely software convention that the interrupt routine
starts with essentially "JMP I .+1;INTHND" moved to 0001-0002 on PDP-8 and
moved to 0002-0003 on PDP-5.  A successful routine could work on either: 

	*0000			/WHERE -8 PCSAVE OCCURS

/	NOTE: DON'T STORE ANYTHING HERE!  IF YOU TRY, THE RIM/BIN LOADERS
/	WILL CRASH ON A PDP-5!

	*0001			/WHERE -5 PCSAVE OCCURS;IS ALSO -8 INT RESTART

	JMP I	0020		/GOTO INTERRUPT ROUTINE IF -8
	JMP I	0020		/GOTO INTERRUPT ROUTINE IF -5

	*0020			/AN AVAILABLE ADDRESS

	INTHND			/POINTER ADDRESS TO INTERUPT HANDLER

While you still have to setup the dismiss routine to exit according to the
correct saved PC, this code gets to the interrupt handler on either
machine.  Location 0003 is not used; instead 0020 (or any other convenient
address on page zero from 0003-0007 or 0020-0177) is used as a
machine-independent pointer to the interrupt handler.  If the CPU is -5,
then the JMP I 0020 at 0001 is destroyed and the PC is saved there. 
Restart is at 0002 to then JMP I 0020 to the INTHND routine.  If the CPU
is -8 then the PC is saved in 0000 and the JMP I 0020 in 0001 is the first
restarted instruction; the contents of 0002 are never referenced.

If this scheme is used, the only thing need be changed in the -5 detection
routine is the JMP I 0002 instruction at DISMISS (overlaying the PDP-8
default of JMP I 0001).  As a matter of efficiency, that could be achieved
by the method of ISZ I (DISMISS) to increment the instruction itself. 
(Note: either method uses exactly the same number of instructions and
storage.  The difference is merely the size of the initialization code
which is once-only.  In FOCAL, 1969 and any other reasonable program,
there is always available space that gets recycled as a buffer or
whatever, which you can use to temporarily house once-only code just
before the main running program is started up.

I guess this is where PDP-5 and PDP-8 programmers show that they're young
whippersnappers compared to the famous Mel!  Mel would have opted to
optimize the initialization code, while sometimes we go for clarity there!
However, Mel would be proud to see the lengths to which most of the code
gets optimized!)

An interesting historical side-note: The PDP-8/s project started out as an
entirely different project.  It was known as PDP-10 (a number obviously
reassigned!) and consisted of pretty much the way the CPU came out
including the deliberate sloth, etc.  The memory was to be 32K with parity
placed on a spinning disk, much the same as in one of Mel's drum computers.
CPU speed would be limited to disk access speed, etc.

Later the memory was changed to early quad-card core stacks of 4K each,
expandable to 32K, and the disk memory begat the DF32 disk peripheral for
any model (including PDP-8/s).

Thus, had this model been produced, it's conceivable that today we would
be discussing the efficacy of optimized initialization code!

cjl