Date: Wed, 28 Aug 91 8:31:49 CDT
From: Philip Arny <lrccon@ux.acs.umn.edu>
Subject: I want to build a PDP8
To: pdp8-lovers@ai.mit.edu
Message-Id: <199108281331.AA29975@ux.acs.umn.edu>

Date: Wed, 28 Aug 91 8:31:49 CDT
From: Philip Arny <lrccon@ux.acs.umn.edu>
Subject: I want to build a PDP8
To: pdp8-lovers@ai.mit.edu
X-Mailer: ELM [version 2.3 PL8]
X-Envelope-To: pdp8-lovers@ai.mit.edu

hello out there...
As I progress in my career, I find myself remembering fondly the
simplicty of the PDP-8 instruction set.  I think I'd like to build a
PDP-8 from current technology (chips, etc); I don't have the room,
strength or stamina to deal with an original.  Can anyone out there
help me with: instructions, parts lists, schematics, board layouts, ???
I'm a relative novice in the electronic construction field, and I
think such a project would be fun and doable for me... let me know.
Thanks!  

Philip Arny
lrccon@ux.acs.umn.edu


Received: from eli.CS.YALE.EDU by BUGS.SYSTEMSY.CS.YALE.EDU; Thu, 29 Aug 91 00:36:25 EDT
Received: from life.ai.mit.edu by eli.CS.YALE.EDU via SMTP; Thu, 29 Aug 1991 00:35:50 -0400
Received: from watsun.cc.columbia.edu by life.ai.mit.edu (4.1/AI-4.10) id AA17844; Thu, 29 Aug 91 00:01:35 EDT
Received: by watsun.cc.columbia.edu (5.59/FCB)
	id AA24242; Thu, 29 Aug 91 00:01:00 EDT
Date: Thu, 29 Aug 91 0:00:59 EDT
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Cc: lrccon@ux.acs.umn.edu
Subject: An -8 from "modern" electronic hardware
Message-Id: <CMM.0.90.0.683438459.lasner@watsun.cc.columbia.edu>

Date: Thu, 29 Aug 91 0:00:59 EDT
From: Charles Lasner <lasner@watsun.cc.columbia.edu>
To: pdp8-lovers@ai.mit.edu
Cc: lrccon@ux.acs.umn.edu
Subject: An -8 from "modern" electronic hardware

    This is on the surface an interesting subject, but there are some
"hidden" problems.

    Most people are familiar with commercial micros (other than the 6100
and 6120) where a lot of pragmatic "rules" evolved over the years.
Unfortunately, most of them are expedient and geared toward repeating
the same old tired designs.  They expect the software to play a major
goal in the performance of the system, and thus overhead inevitably
creeps in.  It is scary to PDP-8 people to find ROM-resident support
programs that take up more memory than the PDP-8 generally uses just to
do "Basic Input/Output Services" or BIOS as some know it.  PDP-8
interfaces are so simple that the code is generally in-line in the
applications programs themselves.

    The point is, that to build a PDP-8 **CPU ONLY** is not that great a
challenge, but rather to create a complete enough system to do any
"useful work" with it.

    The bare minimum system would seem to be an -8/e or 6120 compatible
CPU with EAE (the 6120 -isms are minor and represent a compatible
superset).  While some 8/a models support more memory, most of the
action was/is in the 32K world.

    Implementing a 6100/6120 -style CP interrupt structure and memory
would allow peripherals to be "concocted" that would be along the lines
of the typical feeble "micro"-type  variety.  With up to 32K more PDP-8
memory to fake out the peripheral, a variety of add-on peripherals could
be devised easily.  This includes things like an SCSI port, which buys
you a whole lot of off-the-shelf stuff.

    I personally use the ill-fated MDC8 from CESI to accomplish this.
This is a late entry, expensive, yet high-performance SCSI host adapter
for the Omnibus -8/e,a, etc. that really makes the -8 into a serious
machine.  I have an 80 Meg MFM disk, sometimes another one, a 5.25"
high-density (similar to PC-AT hd diskettes) floppy, and one of the
following: another floppy, a 3.5" hd floppy, or a QIC-02 backup tape
drive.  The four of them are hooked to an OMTI 5400 SCSI controller.  I
also have SyQuest SQ555 removable cartridge disks (each are 45 MBytes
per cartridge which is spunup in 6 seconds, spundown in 3 seconds).
Using the infamous NODEM for the SCSI bus, it is possible to support
Ethernet on the -8.

    The point is that SCSI really opens a lot of doors for the -8, but
the interface has to be cost-effective, which the CESI board is not :-(.
Further, it is a hex board, not a quad board, so -8/e's can't use it.
My machine is an -8/e with an 8/a expander box, so I actually can use it
:-).

    So, a new design, with the SCSI port attached and addressable
through CP memory or equivalent would do nicely.

    For compatiblility, the following I/O peripherals **MUST** be
implemented **PRECISELY** as in the -8 family, and specifically **NOT**
as  misimplemented in the DECmates:

    Device 03/04 console serial port.  Everyone has some form of
terminal or emulator on another machine to use here.  PDP-8 software is
such that you have to do this interface as specified, and the terminal
has to be a glass TTY:.  The extensions aren't mandatory, but would be
nice, since a few programs know what a VT52/100/220/330, etc., are.

    Device 66 parallel LPT: for Centronics compatibility.  While we are
on this sub-subject, the parallel port should REALLY be compatible,
whereas many puny PC and Apple attempts are **NOT** compatible, only
nearly so.  To accomodate a lot of "crap" printers out there, the drive
capability of the output drivers should be such that although they are
defined as open collector, they have to be pulled up at the beginning,
not hope that the end has the terminator.  This allows short cables to
wimpy Epsons, etc., to work at all!  Further, the termination of the
handshakes coming back have to be strappable options from non-existent
to high-impedance to low-impedance to serve all comers.

    At least the standard 32K must be present, but the CP space should
be also 32K and part ROM capable.  Some part of it in EEPROM (EAROM) is
desirable for saving setups, etc.

    The actual implementation of the CPU and associated peripherals can
be done by either bit-slice or some form of gate-array-type thingy.  I
believe processors as complicated as a 68000 have been proffered this
way.

    If desired, incompatible additional memory can be added on along the
lines of the CESI or DEC extended/extended memory specifications.  This
would allow RAMdisks to be created, or serve as address space for future
compiler-generated code, etc. as necessary.  (Rumor has it that there is
a PDP-8 "C" compiler being written, but it will generate inefficient (of
space) code.)

cjl


From erd@cis.ohio-state.edu Thu Aug 29 20:28:06 1991
Return-Path: <erd@cis.ohio-state.edu>
Received: from cunixf.cc.columbia.edu by watsun.cc.columbia.edu (5.59/FCB)
	id AA05713; Thu, 29 Aug 91 20:27:53 EDT
Received: from life.ai.mit.edu by cunixf.cc.columbia.edu (5.59/FCB)
	id AA05253; Thu, 29 Aug 91 20:27:48 EDT
Received: from tut.cis.ohio-state.edu by life.ai.mit.edu (4.1/AI-4.10) id AA02105; Thu, 29 Aug 91 11:21:49 EDT
Received: by tut.cis.ohio-state.edu (5.61-kk/5.910703)
	id AA22910; Thu, 29 Aug 91 11:21:08 -0400
Date: Thu, 29 Aug 91 11:21:08 -0400
From: Ethan R Dicks <erd@cis.ohio-state.edu>
Message-Id: <9108291521.AA22910@tut.cis.ohio-state.edu>
To: pdp8-lovers@ai.mit.edu
Subject: Please change my subscription

My account at cis.ohio-state.EDU is going away.  I have arranged for alternate
access.  Please subscribe me at the address...

n8emr!uncle!jcnpc!kumiss!erd@zaphod.mps.ohio-state.edu

Thanks,
-ethan