From mbg@world.std.com Tue Jan  4 07:01:56 EST 1994
Article: 572 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!spool.mu.edu!bloom-beacon.mit.edu!world!mbg
From: mbg@world.std.com (Megan)
Subject: Program to disassemble .RIM/.BIN files
Message-ID: <CIzoHG.Iry@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
Date: Sun, 2 Jan 1994 06:24:51 GMT
Lines: 12


In case anyone is interested, I have written a first pass at
a pdp-8 RIM/BIN file disassembler.  It's pretty crude at the
moment, but if anyone is interested, I'll make it available.
It is written in C and has been tested on my Ultrix/VAX machine
and on a 386.

					Megan Gentry

p.s. I guess I'm looking for alpha-testers (no, not people with
     alphas... :-)



From supnik@human.enet.dec.com Tue Jan  4 07:33:39 EST 1994
Article: 573 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!ames!decwrl!pa.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: alt.sys.pdp8
Subject: RX01 8b/12b mode interaction
Date: 2 JAN 94 15:29:20
Organization: Digital Equipment Corporation
Lines: 26
Message-ID: <2g7arm$nb3@sousa.ako.dec.com>
NNTP-Posting-Host: human.enet.dec.com
Summary: Which byte order for 12b operations?
Keywords: RX01, byte order

The RX8E/RX01 can operate in either 8b or 12b mode.  In 12b mode, two
8b bytes are used to store a 12b word.  The question: do 12b stores into
the buffer store low/high, or high/low, ie,

If I FILL the buffer in 12b mode:

	12b data 0, XDR
	12b data 1, XDR, etc

and then EMPTY the buffer in 8b mode, do I see

a)	XDR, data 0<4:11>
	XDR, 0'data 0<0:3>
	XDR, data 1<4:11>
	XDR, 0'data 1<0:3> etc OR

b)	XDR, 0'data 0<0:3>
	XDR, data 0<4:11>
	XDR, 0'data 1<0:3> etc OR
	XDR, data 1<4:11>

Thanks... /Bob

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation


From bqt@Minsk.docs.uu.se Tue Jan  4 07:53:38 EST 1994
Article: 574 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!agate!doc.ic.ac.uk!uknet!EU.net!sunic!corax.udac.uu.se!Minsk.docs.uu.se!bqt
From: bqt@Minsk.docs.uu.se (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 3 Jan 1994 15:59:21 GMT
Organization: Uppsala University
Lines: 109
Message-ID: <2g9fcp$aqa@corax.udac.uu.se>
References: <CIvI64.366@world.std.com>
NNTP-Posting-Host: minsk.docs.uu.se

In <CIvI64.366@world.std.com> mbg@world.std.com (Megan) writes:


>I have been unable to find a description of the format of a .SV
>file.  Can someone possibly post it?

>					Megan Gentry

>From the OS/8 Software Support Manual (typed in without permission):

Appendix A.

A.2.2  Core Image (.SV Format) Files

A core image file consist of a header by the actual core image.  The
header block is called the Core Control Block.  The Core Control Block
consist of the first 128 words of the 256 word block reserved for
that purpose.  The second 128 words are unused.  The Core Control
Block is formatted as follows:

Location       Contents                         Notes

          CORE CONTROL BLOCK

         +-----------------------------------+
       0 ! Minus the number of core segments !
         +-----------------------------------+
       1 ! CDF CIF (starting field)          ! <- 62N3 where N is the
         +-----------------------------------+    starting field
       2 ! Starting address                  !
         +-----------------------------------+
       3 ! Job Status Word                   !
         +-----------------------------------+
       4 !                                   ! \  Core segment control
         +-----------------------------------+ |  double words
         /                                   /  >
         +-----------------------------------+ |  (K is the number of
    2K+3 !                                   ! /   core segments)
         +-----------------------------------+
         /                                   / Remainder of block is
     377 !                                   ! unused
         +-----------------------------------+

The format of the Job Status Word is as follows:

Bit Condition           Meaning

Bit 0 = 1	File does not load into locations 0 to 1777 in field 0.
Bit 1 = 1	File does not load into locations 0 to 1777 in field 1.
Bit 2 = 1	Program must be reloaded before it can be restarted.
Bit 3 = 1	Program never uses above 8K. This is used when Batch
		processing is active.
Bit 10 = 1	Locations 0 to 1777 in field 0 need not be preserved when
		the Command Decoder is called.
Bit 11 = 1	Locations 0 to 1777 in field 1 need not be preserved when
		the USR is called.

The Core Segment Doublewords control the reading and writing of the
associated areas of core.  The format of each entry is as follows:

Location         Contents                       Notes

        +------------------------------------+
      1 !           Core origin              ! Multiple of 400(8)
        +------------------------------------+
      2 ! ! Number of pages ! Field   !      ! Bits 0 and 9-11
        ! !     to load     ! to load !      ! are zero.
        +-+-----------------+---------+------+
         0 1               5 6       8 9   11

The core origin must be a multiple of 400 (octal).  The Core Segment
Control Doublewords are sorted within the header block in order of
decreasing field and increasing oridin within the same field.  There
can be no more than 32 (decimal) Core Segment Control Doublewords in
any Core Control Block.

The Core Control Block for the program at the time it is loaded into
the core is always saved in words 200 (octal) through 377 (octal) of block
37 (octal) (one of the system scratch blocks) on the system device.
It is placed there by the GET and RUN operations, or by the ABSLDR or
LOADER programs.  This Core Control Block is used when performing a
SAVE without arguments.

		NOTE

	The R command differs from the RUN
	command in that the program's Core
	Control Block is not written onto the
	scratch area when using the R command.
	In order to SAVE a program that has been
	loaded by the R command all of the
	arguments of the SAVE command must be
	explicitly stated.


Hope this is enough, otherwise I'll have to dig out my
FUTIL manual, and start experimenting... ;-)

	Johnny

Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From lasner@sunSITE.unc.edu Tue Jan  4 07:53:52 EST 1994
Article: 575 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Program to disassemble .RIM/.BIN files
Date: 4 Jan 1994 12:01:47 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 88
Message-ID: <2gblrb$cd2@bigblue.oit.unc.edu>
References: <CIzoHG.Iry@world.std.com>
NNTP-Posting-Host: sunsite.unc.edu

In article <CIzoHG.Iry@world.std.com>, Megan <mbg@world.std.com> wrote:
>
>In case anyone is interested, I have written a first pass at
>a pdp-8 RIM/BIN file disassembler.  It's pretty crude at the
>moment, but if anyone is interested, I'll make it available.
>It is written in C and has been tested on my Ultrix/VAX machine
>and on a 386.

I'll assume for the moment that what you mean is the following:

Assuming an 8-bit-byte-oriented machine and file structure, a file is
present that consists of the 8-bit frames of a RIM or BIN paper-tape in a
data stream, etc.  Note that such a file can easily be created from an
OS/8 file that was an actual paper-tape or assembler output (.BN) file by
using the PDP-8 ENBOO utility and MSBPCT on the 8-bit end, etc. (I would
assume Kermit got the encoded file between systems, etc.)

Further, that the BIN or RIM file is then pseudo-loaded into a PDP-8
"core" buffer and the 12-bit values are themselves available in some more
symbolic form such as 4-digit octal addresses and data, and hopefully,
beyond that some actual symbolic disassembly where PDP-8 symbols are used,
together with some address symbols.  (Note, most disassemblers use some
form of auto-generated address which is a mechanical translation of the
octal address.  For example, the addresses 0000-0177 could be referred to
as Z000-Z177, and 0200-0377 could be A000-A177, 400-577 could be
B000-B177, etc.  Of course beyond that, it would be nice to define
user-defined symbols to override the auto-generated addresses!)

Please note that anyone who already has an -8 OS/8 system or an OS/278
DECmate system doesn't need this sort of "reinventing the wheel".  (Nor
does someone successfully running a "complete" emulator!)  We already have
the DCP16 and DCP24 programs.  (Note: the sources to these were lost years
ago; they apparently originate in Europe in a country where German is the
prevailing language; it would be greatly appreciated if the sources were
restored, since there are a few minor annoying bugs still to be fixed in
the disassembler itself!)

DCP16 can take either .BN or .SV files as input.  ABLSDR can load  any .BN
into a .SV anyway, and the program SV2BN can do the reverse if needed,
etc.  You can assign symbol names and values, and distinguish between
definitions and addresses.  (Thus, KSF doesn't ever mean a reference to
location 6031! NL0002 doesn't mean a reference to location 7326 (CLA CLL
CML RTL), etc.)  Disassembly of any field is allowed, but only one-at-a-time.
Binaries and a terse poor-english document are available.

I have used DCP16 to disassemble several sets of the DECmate 4K ROM's,
etc.  Of course, you have to decide when to abandon the disassembler and
go it alone on your "source", but you can get pretty far fairly quickly. 
Typically, a control file is created after a few hours work that contains
about 60% of the most important symbols you need to override automatic
disassembly, so you then quit with an ugly but manageable source.  Many,
many hours later, a fully adorned source file (may) emerge if you are
persistent (as I was).

DCP24 needs 24K to run in (thus the name; the other needs 16K).  You get
two features more:

1)	It attempts to follow mode A and mode B EAE changes and does
translate EAE symbols; you can help it into the correct mode if you know
it's backwards.  In any case, it uses mode change instructions SWAB and
SWBA to change the disassembly assuming sequential mode application, etc.

2)	This may be more trouble than it's worth, but it allows you to
assign comments to addresses!  This of course means that disassembled
output is strictly limited to only comments on words of code, thus no
"loose" comments anywhere else, and only one-liners at that.  Since
comments usually want to be a bit freer than that, you probably won't add
comments until you can call the source "your own" and no longer
disassemble, etc.  Moreover, due to other cosmetic problems with the
program, you'll want to perform some clean-up pass on the source, and
seeing comments before cleanup may be counter-productive, etc.  (Your
comments could interfere with TECO macros used to clean the source up!)

Like many other disassemblers, it does occasionally tend to create
"bunched-up" source lines, meaning OR'ed together symbols that do generate
the correct code, but make no sense.  By carefully creating control
statements that affect the particular locations, this can be curbed or
even eliminated.  (But likely isn't worth the effort of totally
eliminating it!  Better to just contain it and fixup later when you are
getting the source to make more sense, etc.)

In any case, I would rate the current DCP16 at about a B+ in terms of what
you would theoretically want it to do for you.  Those of you familiar with
ASMGEN will find ASMGEN to be a rip-off of this earlier work (or merely an
interesting coincidence!).

cjl



From lasner@sunSITE.unc.edu Tue Jan  4 07:54:04 EST 1994
Article: 576 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: RX01 8b/12b mode interaction
Date: 4 Jan 1994 12:33:34 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 72
Message-ID: <2gbnmu$gum@bigblue.oit.unc.edu>
References: <2g7arm$nb3@sousa.ako.dec.com>
NNTP-Posting-Host: sunsite.unc.edu
Keywords: RX01, byte order

In article <2g7arm$nb3@sousa.ako.dec.com>,
Bob Supnik <supnik@human.enet.dec.com> wrote:
>The RX8E/RX01 can operate in either 8b or 12b mode.  In 12b mode, two
>8b bytes are used to store a 12b word.  The question: do 12b stores into
>the buffer store low/high, or high/low, ie,

The correct answer is that the sector is a bit stream.  12-bit mode takes
them out the same way as 8-bit mode does, just does it 12 at a time, not 8
at a time.  Thus, two 12-bit words are definable as word0[0-11] and
word1[0-11] in terms of identifying the bits in 12-bit mode.  8-bit mode
access to them would be byte[0-2].  The bits in the bytes are:

byte[0] -> word0[0-7] in the same left-to-right order as in the words
byte[1] -> word0[8-11] , word1[0-3]
byte[2] -> word1[4-11]

This is why any sector can be referenced in either mode, as long as you
are willing to forego the last 25% original values.  I think writing in
12-bit mode places the last transferred 8-bits data replicated into all of
the rest of the sector, 8-bits at a time.  A diagnostic probably checks
this!  (Note that no floppy i/o is needed to test this!)

RX50 is totally different!  If there are two adjacent bytes byte[0] and
byte[1], then the contents become:

byte[0] -> word0[0-7]
byte[1] -> word0[8-11], 0000

Yes, even bytes are preserved, but the low-order nybble of odd bytes get
zeroed out!

This is the crux of *why* OS/278 disks self-destruct when you type "SET
SYS OS278" (or similar).  (Or run FUTIL and write record 0):

There is apparently some DEC-wide convention (help us out here, Bob!)
regarding  at least all RX50 bootable volumes, perhaps more generic than
that.  In any case, as a result, the first 12 bytes of logical record 0 of
an RX50 are "sacred".  A value was assigned to OS/8-type systems that is
totally non-viable!  The reason is that a subset of the validity checking
for this value is in the DECmate II,III,III+ ROM's:  (I don't know the
full definition, just that which the DECmate actually checks for!)

byte[0]-byte[1] .AND. 377 = 000 (they are both 000 usually)
byte[2] is an index.  Use twice it and add two.

byte[index] .AND. byte[index+1] .AND. 010 = 010 (they are usually 10 and 11)
byte[index] + byte[index+1] + byte[index+2] + byte[index+3] .AND. 377 = 377

If the test fails, subtract two from index and repeat the test exactly once.

If it flunks again, the system is non-bootable!  Generally, hard disk
volumes use index value of 3 and floppy uses index value of 2.  (The hard
disk controller treats 12-bit and 8-bit identically to the RX50
controller!  The hard disk just moves the bytes two further down on the
record, but all else is the same, including self-destruction by OS/278, etc.)

Since the system can only write in 12-bit mode, the checksum part cannot
be preserved!  Thus, we have the brilliant (!) design of a system that
boots by reading in 12-bit mode a record that cannot be written in 12-bit
mode!  All routines to create boot blocks on the DECmate have to
pre-translate the intended 12-bit code into 8-bit, and write out in 8-bit
mode to ensure that the first 12 bytes on the record aren't affected! 
Needless to say, this is totally contrary to basic OS/8 philosophy at the
handler level!

(Note: I have a fix to this!  Before posting it, I want some input on just
how important preserving these volume header conventions are at this
point, etc.)

cjl




From lasner@sunSITE.unc.edu Tue Jan  4 07:54:30 EST 1994
Article: 577 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 4 Jan 1994 12:53:30 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 36
Message-ID: <2gbosa$l9v@bigblue.oit.unc.edu>
References: <CIvI64.366@world.std.com> <2g9fcp$aqa@corax.udac.uu.se>
NNTP-Posting-Host: sunsite.unc.edu

In article <2g9fcp$aqa@corax.udac.uu.se>,
Johnny Billquist <bqt@Minsk.docs.uu.se> wrote:

>Bit 11 = 1	Locations 0 to 1777 in field 1 need not be preserved when
>		the USR is called.

As I previously posted, some other bits have been defined.  I believe
bit[5] is the "no-R"  OS/78 bit, but it's become muddled in newer OS
versions, etc.

>The Core Segment Doublewords control the reading and writing of the
>associated areas of core.  The format of each entry is as follows:

>      1 !           Core origin              ! Multiple of 400(8)

Don't expect much validity checking of this restriction!

>      2 ! ! Number of pages ! Field   !      ! Bits 0 and 9-11
>        ! !     to load     ! to load !      ! are zero.

Bits[0] and [9-11] *better* be zero!  They aren't checked!  Attempting to
use bit[0] set means that it writes on the file instead of loading it!

>can be no more than 32 (decimal) Core Segment Control Doublewords in
>any Core Control Block.

I think you'll find that many OS/8 versions are restricted to nine maximum!

>LOADER programs.  This Core Control Block is used when performing a
>SAVE without arguments.


OS/278 is riddled with bugs in this area!

cjl



From ard@siva.bris.ac.uk Tue Jan  4 17:54:17 EST 1994
Article: 578 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!agate!doc.ic.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: 8" RX02 floppies on IBM PC
Message-ID: <4JAN199420374419@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <9312171136.AA03042@biomed.abdn.ac.uk> <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de> <2f7fp1$eet@bigblue.oit.unc.edu>
Date: Tue, 4 Jan 1994 19:37:00 GMT
Lines: 90

In article <2f7fp1$eet@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes...
>In article <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de>,
>krause <krause@azu.informatik.uni-stuttgart.de> wrote:
>>>Maybe this is a FAQ, but I've not managed to find it anywhere. Let me know
>>>if I've missed it, or if there's a better group I should be posting to.
>>>
>>>1/ My questions:
>>>
>>>(i)	Can I interface an 8" floppy drive to a standard PC controller on
>>>	a PC clone computer? Do I simply need a conversion cable?
>>>
>>I have a 8" (ITT 2020) drive on my -486 PC. It's connected, via an adapter
>>cable to a secondary FDC.
>>I don't know, how to access a secondary FDC via the 'legal' PC-BIOS, but with
>>the shareware programm 'ANADISK' I can make dumps of many floppies from several
>>machines: IBM 5120 (all in EBCDIC!), CP/M-disks and VAX 780 disks.
>>I think, if the RX02 floppies are not hardsectored, it should be possible to 
>>read (dump) them too.
> 
>RX01 disks are FM, but industry standard.  I have heard conflicting

True. RX01 disks are very similar to IBM 3740 or single-density CP/M disks in
terms of the sector layout.

>reports on the ability for a standard PC floppy controller card being able
>to control FM disks by using special software (BIOS definitely can't help
>you!) in conjunction with:
> 
>1)	Nothing.  Special software can make it work.
> 
>2)	Small hardware changes.
> 
>3)	Only works on some clone cards, not others.  Won't work on IBM card.
> 
>4)	Same as 3), but requires small hardware changes.
> 
>5)	Same as 3), but requires real IBM card or slavish compatible.
> 
>The card is based on the 765 chip, which can work with FM disks in principle.

Right. The original IBM XT controller could not do FM. Not without designing a
whole new data separator circuit and kludging it in. The original data
separator was built from about 3 chips.
Some clone cards used an 8-pin data separator IC (I forget the number), which
could do FM formats. But, it was permanently wired in MFM mode. If you lift the
control pin of the data separator, and link it though an inverter to the
density select output of the 765/8272, it should work. Details are in the
ANADISK (or is it the 22disk - a shareware CP/M disk reading program)
documentation. I've not tried this myself.
Some cards use an LSI disk controller that includes the data separator. The UMC
8398 (I think that's the number) claims to be able to FM formats, but I can't
get it to work reliably. The NatSemi one again can do FM, but you optimise the
loop filter components in the data separator PLL differently for FM or MFM.
I've not hacked a commercial card yet.
Of course, when the disk controller is in some other LSI chip, then FM mopde
may work, or it may not. Few data books even mention it these days


> 
>>
>>>(ii)	Is there any software around (PD/commercial) which would allow me
>>>	to read the RX02 format (written on an RSX system, so I guess this
>>>	implies Files-11)? Do some PC BIOSs include 8" floppy support, and
>>>	would this be any help to me (since it isn't an MSDOS floppy!)
>>>
>>Look for ANADISK, or if you attach your Drive to the normal controller, there
>>are some BIOS-calls to set the normal FDC to other sector numbers and sizes,
>>some PC-controller clones allow even to set them to single density!
>>I once wrote a turbo pascal programm to read and write CP/M disks, without 
>>one line machine code. 
> 
>But the problem is RX02, not RX01.  DEC uses an incompatible cross between
>single and double-density conventions in the RX02.  I doubt if any other
>floppy controller than DEC's "hand-made" one can deal with the format. 
>The headers are FM with MFM ID data and FM data preamble with MFM data in
>the data areas.  The index is pure FM.  Most machines are based on
>packaged floppy chips.  Name any that can switch modes in the middle of a
>record.

I must design my RX211-for-PC's card sometime. I've been thinking about a few
shift registers, and a bit of TTL to link a real RX02 drive to a PC. That
should be the simplest solution.


> 
>cjl
> 
> 
-tony



From lasner@sunSITE.unc.edu Tue Jan  4 17:54:53 EST 1994
Article: 579 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 8" RX02 floppies on IBM PC
Date: 4 Jan 1994 22:54:13 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 51
Message-ID: <2gcs2l$949@bigblue.oit.unc.edu>
References: <9312171136.AA03042@biomed.abdn.ac.uk> <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de> <2f7fp1$eet@bigblue.oit.unc.edu> <4JAN199420374419@siva.bris.ac.uk>
NNTP-Posting-Host: sunsite.unc.edu

In article <4JAN199420374419@siva.bris.ac.uk>,
PDP11 Hacker ..... <ard@siva.bris.ac.uk> wrote:
>In article <2f7fp1$eet@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes...

>True. RX01 disks are very similar to IBM 3740 or single-density CP/M disks in
>terms of the sector layout.

No, not merely very similar, but actually identical.  When the RX01 was
new, DEC was selling IBM 3740 media in the IBM box.  In fact, the whole
prohibition against using track 0 comes about because an actual 3740 won't
format a disk (remember, DEC's RX disks don't format!) unless it can
successfully read track 0 as 3740 format with certain "reserved" areas set
accordingly.  (I have second-hand info that it's still possible to format
blank or otherwise unacceptable media, but it involves changing some
inside connections, and customers never got the IBM info to do it, etc.) 
Thus, DEC decided to reserve track 0 so it would pristinely be acceptable
to an actual 3740, perhaps to get reformatted, etc.  (Note: this is
ultimately foolish because you can always write a utility to write on
track 0 the "sacred" contents, including any deleted-data sectors if
required; the RX01 hardware can do it all, etc.)

>I must design my RX211-for-PC's card sometime. I've been thinking about a few
>shift registers, and a bit of TTL to link a real RX02 drive to a PC. That
>should be the simplest solution.

Yes, the packaged RX01/02 is a complete subsystem with a simple serial
interface.  There's no reason why you can't merely build a PC version of
an RX interface and use the actual RX drive.

CESI built an Omnibus RX interface for industry-standard drives, such as
the Shugart SA-802.  It uses a floppy chip and a 6809 to run the
operations, and talk to the -8 ala the RX interface, so it's essentially
program compatible with the RX01.  The FLP8 even uses the "set media
density" command ala RX02 to *actually* format the media.  (Note: some
early RX01-only software that can also run on an RX02 if the
compatibility-mode switch is set in the drive, requires the use of the
same function to merely set the done flag and not get an error.  In the
actual normal-mode RX02 and in the FLP8, this software won't function
because the function is safeguarded: you have to issue an XDR with the AC
= 0111, the ASCII for "I" for initialize.  On the RX02 this changes the
media density, *not format* becuase the media has to be already formatted,
but on the FLP8 it will actually format.  Thus, only newer handlers can be
used on the FLP8 when it's setup to be an RX01 replacement.  That's not
the only viable configuration, since it can also be setup for RX50
equivalence, etc.)

Of course building a PC version of such an interface can be done, but it's
more work than just making an RX-compatible serial interface!

cjl



From ard@siva.bris.ac.uk Wed Jan  5 00:59:44 EST 1994
Article: 580 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: 8" RX02 floppies on IBM PC
Message-ID: <5JAN199400310522@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <9312171136.AA03042@biomed.abdn.ac.uk> <1993Dec21.102200.29174@ifi.informatik.uni-stuttgart.de> <2f7fp1$eet@bigblue.oit.unc.edu> <2gcs2l$949@bigblue.oit.unc.edu>
Date: Tue, 4 Jan 1994 23:31:00 GMT
Lines: 44

In article <2gcs2l$949@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes...
>In article <4JAN199420374419@siva.bris.ac.uk>,
>PDP11 Hacker ..... <ard@siva.bris.ac.uk> wrote:
>>In article <2f7fp1$eet@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes...
> 
>>True. RX01 disks are very similar to IBM 3740 or single-density CP/M disks in
>>terms of the sector layout.
> 
>No, not merely very similar, but actually identical.  When the RX01 was

I thought so, but wasn't absolutely sure
>>I must design my RX211-for-PC's card sometime. I've been thinking about a few
>>shift registers, and a bit of TTL to link a real RX02 drive to a PC. That
>>should be the simplest solution.
> 
>Yes, the packaged RX01/02 is a complete subsystem with a simple serial
>interface.  There's no reason why you can't merely build a PC version of
>an RX interface and use the actual RX drive.

The interface spec is in the user or maintenance manuals I think. It's pretty
obvious. Also in said manuals appears a flowchart of the internal drive
microprogram with the addresses of all the main routines given :-)

> 
>CESI built an Omnibus RX interface for industry-standard drives, such as
>the Shugart SA-802.  It uses a floppy chip and a 6809 to run the
>operations, and talk to the -8 ala the RX interface, so it's essentially
>program compatible with the RX01.  The FLP8 even uses the "set media
>density" command ala RX02 to *actually* format the media.  (Note: some

Such things existed for the Q-bus PDP11's (and I assume the Unibus, although
I've never seen one). The tended to use AMD 2901/2911 series chips. On those,
'set density' was a format instruction as well.

>Of course building a PC version of such an interface can be done, but it's
>more work than just making an RX-compatible serial interface!

True. But of course the latter assumes you have a spare RX02. 

> 
>cjl
> 
-tony



From lasner@sunSITE.unc.edu Wed Jan  5 01:00:04 EST 1994
Article: 581 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 8" RX02 floppies on IBM PC
Date: 5 Jan 1994 05:59:41 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 66
Message-ID: <2gdl0d$de4@bigblue.oit.unc.edu>
References: <9312171136.AA03042@biomed.abdn.ac.uk> <2f7fp1$eet@bigblue.oit.unc.edu> <2gcs2l$949@bigblue.oit.unc.edu> <5JAN199400310522@siva.bris.ac.uk>
NNTP-Posting-Host: sunsite.unc.edu

In article <5JAN199400310522@siva.bris.ac.uk>,
PDP11 Hacker ..... <ard@siva.bris.ac.uk> wrote:
>In article <2gcs2l$949@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes...
>> 
>>Yes, the packaged RX01/02 is a complete subsystem with a simple serial
>>interface.  There's no reason why you can't merely build a PC version of
>>an RX interface and use the actual RX drive.
>
>The interface spec is in the user or maintenance manuals I think. It's pretty
>obvious. Also in said manuals appears a flowchart of the internal drive
>microprogram with the addresses of all the main routines given :-)

In early RX01 diagnostics and prints, they include the complete listing of
the micro-code for DEC's roll-your-own processor.  It's actually a PAL10
program, although no actual PDP-8 code!

>
>> 
>>CESI built an Omnibus RX interface for industry-standard drives, such as
>>the Shugart SA-802.  It uses a floppy chip and a 6809 to run the
>>operations, and talk to the -8 ala the RX interface, so it's essentially
>>program compatible with the RX01.  The FLP8 even uses the "set media
>>density" command ala RX02 to *actually* format the media.  (Note: some
>
>Such things existed for the Q-bus PDP11's (and I assume the Unibus, although
>I've never seen one). The tended to use AMD 2901/2911 series chips. On those,
>'set density' was a format instruction as well.

The ones I am familiar with are from DSD (aka QuoData).  To format a track
on the RX01-compatible (210) you request a write to sector 152 octal. 
This sets up a request for 26 data values to be the sectors in the order
you want them starting from index, etc.  On the Q-bus, the
RX02-compatibles uses a different scheme: ask for sector 153 or 154.  153
gets you single density formatted entire disk, and 154 same only
double-density. (On the 210 it's a format *track* operation to be
interated 77 times.)  Set media density means nothing on the 210 which is
totally RX01 compatible including writ-protect, and on the RX02
compatibles set media density means just that.

>
>>Of course building a PC version of such an interface can be done, but it's
>>more work than just making an RX-compatible serial interface!
>
>True. But of course the latter assumes you have a spare RX02. 

They're fairly easy to get.

I have the rare combination of the 4-drive pedestal which is actually two
complete RX02's.

With the availability of more modern floppy chips, it's no longer
necessary to resort to 2901 or more complex controllers.  The innards of
the DECmate II, III, III+ are a 1793 or 1796 (only one side is used so it
doesn't matter) with a DEC-designed external data separator.  However, the
6120 doesn't touch it, instead deferring to an 8051 that "emulates" the
RX protocol to allow familiar -8 RX code, etc.  (And as a result, only
standard disks can be read.  The only exception is that the II, III
version can also read, but not write SSDD 40 track disks.  For reasons
unknown, this support was dropped in the III+ version in favor of support
for only two disks, not four as two RX50 pairs, each capable of separately
seeking, and wanting to support device-change, not device-ready.  The III+
doesn't ever package the second drive, but will support it if cabled into
the drive cable in the standard way as 34-pin cables are used, etc.)

cjl



From cchd@lucifer.latrobe.edu.au Wed Jan  5 14:10:07 EST 1994
Article: 582 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!sgiblab!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!lucifer!cchd
Newsgroups: alt.sys.pdp8
Subject: PDP-8A and Dual floppies
Message-ID: <1994Jan5.083414.15937@lugb.latrobe.edu.au>
From: cchd@lucifer.latrobe.edu.au (Huw Davies)
Date: Wed, 5 Jan 1994 08:34:14 GMT
Sender: news@lugb.latrobe.edu.au (USENET News System)
Organization: La Trobe University
Lines: 12

I'm trying to get a PDP-8A going as part of a demonstration for an
upcoming DECUS event. The problem is that I have a wide ribbon cable
that runs from the floppy controller and I had assumed that it would
just plug into the 8" drives. The problem is my usual one - sex! Both the
end of the cable and the socket in the drive are of the same (male) sex.
Should I just create a female-female cable and plug it in, or is there
some other magic required?
-- 
  Huw Davies           | Huw.Davies@latrobe.edu.au
  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 bqt@Update.UU.SE Wed Jan  5 14:21:17 EST 1994
Article: 583 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!bqt
From: bqt@Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 5 Jan 1994 16:57:57 GMT
Organization: Uppsala University
Lines: 62
Message-ID: <2geril$qlo@corax.udac.uu.se>
References: <CIvI64.366@world.std.com> <2g9fcp$aqa@corax.udac.uu.se> <2gbosa$l9v@bigblue.oit.unc.edu>
NNTP-Posting-Host: krille.update.uu.se

lasner@sunSITE.unc.edu (Charles Lasner) writes:

>In article <2g9fcp$aqa@corax.udac.uu.se>,
>Johnny Billquist <bqt@Minsk.docs.uu.se> wrote:

>>Bit 11 = 1	Locations 0 to 1777 in field 1 need not be preserved when
>>		the USR is called.

>As I previously posted, some other bits have been defined.  I believe
>bit[5] is the "no-R"  OS/78 bit, but it's become muddled in newer OS
>versions, etc.

Yes, I know. I was just quoting the manual. :-)
This is what the OS/8 Handbook Update says:

Bit 4 = 1	A core image file that was generated by LINK containing
		overlays
Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
		under OS/78
Bit 6-9		Unused and reserved for future expansion

>>The Core Segment Doublewords control the reading and writing of the
>>associated areas of core.  The format of each entry is as follows:

>>      1 !           Core origin              ! Multiple of 400(8)

>Don't expect much validity checking of this restriction!

:-)

>>      2 ! ! Number of pages ! Field   !      ! Bits 0 and 9-11
>>        ! !     to load     ! to load !      ! are zero.

>Bits[0] and [9-11] *better* be zero!  They aren't checked!  Attempting to
>use bit[0] set means that it writes on the file instead of loading it!

Yep. This field is formatted exactly as the device driver wants it, and
those other bits also have meanings.
(If you set bit 11, and the device is a DECtape, it will run in
reverse... :-)

>>can be no more than 32 (decimal) Core Segment Control Doublewords in
>>any Core Control Block.

>I think you'll find that many OS/8 versions are restricted to nine maximum!

Haven't checked that. Anyway, I was only quoting the manual.
Strange that they should restrict this later.
I assume you mean bastardized OS/8's, such as OS/78 and OS/278
by the way.

>>LOADER programs.  This Core Control Block is used when performing a
>>SAVE without arguments.

>OS/278 is riddled with bugs in this area!

(. Software always have a way to improve itself... .)
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From dicks@math.ohio-state.edu Wed Jan  5 14:21:28 EST 1994
Article: 584 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!swrinde!cs.utexas.edu!math.ohio-state.edu!not-for-mail
From: dicks@math.ohio-state.edu (Ethan Dicks)
Newsgroups: alt.sys.pdp8
Subject: Re: PDP-8A and Dual floppies
Date: 5 Jan 1994 13:40:18 -0500
Organization: Department of Mathematics, The Ohio State University
Lines: 28
Message-ID: <2gf1ii$min@math.mps.ohio-state.edu>
References: <1994Jan5.083414.15937@lugb.latrobe.edu.au>
NNTP-Posting-Host: math.mps.ohio-state.edu

In article <1994Jan5.083414.15937@lugb.latrobe.edu.au>,
Huw Davies <cchd@lucifer.latrobe.edu.au> wrote:
>I'm trying to get a PDP-8A going as part of a demonstration for an
>upcoming DECUS event. The problem is that I have a wide ribbon cable
>that runs from the floppy controller and I had assumed that it would
>just plug into the 8" drives. The problem is my usual one - sex! Both the
>end of the cable and the socket in the drive are of the same (male) sex.
>Should I just create a female-female cable and plug it in, or is there
>some other magic required?

No magic.  The standard cable has two 40-pin IDC connectors on each end
of a 40-wire ribbon cable.  It's one of the most ordinary cables used in
DEC hardware.  If you have to make one, just crimp a 40-pin connector
on each end of the cable.  I've got a bin of them, but shipping precludes
an easy solution.  Perhaps someone in OZ could help you out.

Others can probably quote the DEC part number (BC???-??) from memory, I cannot.
My best guess is BC08R-10 (for a 10' (3m) cable), but it could be a BC06R-10.

If you have a ribbon cable already coming out of the controller, what is on
the end of it that won't fit into the respective connector on the RX02?

-ethan
-- 
This message was (fortunately) not brought to you by Intel...
  "Intel: bringing you the "backward" in backward compatibilty."

dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org


From lasner@sunSITE.unc.edu Wed Jan  5 15:23:36 EST 1994
Article: 585 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: PDP-8A and Dual floppies
Date: 5 Jan 1994 19:55:30 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 73
Message-ID: <2gf5vi$miv@bigblue.oit.unc.edu>
References: <1994Jan5.083414.15937@lugb.latrobe.edu.au> <2gf1ii$min@math.mps.ohio-state.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <2gf1ii$min@math.mps.ohio-state.edu>,
Ethan Dicks <dicks@math.ohio-state.edu> wrote:
>In article <1994Jan5.083414.15937@lugb.latrobe.edu.au>,
>Huw Davies <cchd@lucifer.latrobe.edu.au> wrote:

>>upcoming DECUS event. The problem is that I have a wide ribbon cable
>>that runs from the floppy controller and I had assumed that it would
>>just plug into the 8" drives. The problem is my usual one - sex! Both the
>>end of the cable and the socket in the drive are of the same (male) sex.
>>Should I just create a female-female cable and plug it in, or is there
>>some other magic required?
>
>No magic.  The standard cable has two 40-pin IDC connectors on each end
>of a 40-wire ribbon cable.  It's one of the most ordinary cables used in

I think I see a major problem here: Is Huw trying to hook a *drive* to an
RX8E or an RX01/02?

The RX01/02 is not merely a floppy drive.  Rather it's a complete
sub-system which you communicate with via a fast serial interface with
commands and data, not floppy signals at all.  In turn, the drives within
the RX01/02 aren't industry standard because more of the drive electronics
are found on boards within the box than in the drive whereas industry
practice is to place the read/write electonics within the drive itself. 
Indeed, the earliest RX01 drives were Calcomp CDS-140 drives with the
electronics removed!  All that remains is the motor and head assemblies.

The standard cable for the RX controller <-> RX subsystem is generally a
40-pin flat ribbon cable coming out of the drive.  The simplest connection
is directly to the RX8E via a flat 40-pin male-male cable called BC05-L. 
The reason this isn't one of the BC06 or 08 family has to do with
notation:  DEC's "normal" convention is to number cables that are 40-pin
as pin A-VV on one end and VV-A on the other, i.e., there is a wire
connection from pin A to pin VV on the far end.  There are also cables
that label A-A and VV-VV for conventional interconnections, etc.  (These
would be BC08R and BC08S respectively.) But the problem is that these
cables are labeled "This side up" in a way consistent with the wiring
convention; the engineer assigned to the RX project didn't understand this
convention, and created what is essentially a cable that is the same as
BC08S but you have to *not* lay the cable down backwards as is normal,
thus this particular cable has to have a label on the "wrong" side, thus
the alternate part number. 

Thus, all of these cables are just 40-pin flat ribbon cables; you just
have to determine how to properly plug in the ends!  (Note: the BC06
cables are shielded variants however!  This also applies to some of the
BC08 family as well, such as the positive bus and data break cables for
the KD8E and KA8E; DEC has had several generations of shielded cables with
different characteristics; I suspect the specific details of the
differences are overstated and are actually interchageable in most
applications.  However, I would hesitate to use an unshielded cable where
a shielded one was specified!)  Since the RX controller drives the cable
well, unshielded cable is normal for this application.

In some other applications, the cabling is a bit more complicated.  Some
controllers output the controller signals on 40-pin connectors, but the
cable has a DB-25 on the other end.  This is because a standard option of
the table-top version of the RX drive is a bulk-head mounted DB-25 mating
connector that in turn has an internal 40-pin cable that plugs into the
drive board, etc.  Thus, external cabling is via a shielded variant of
RS-232 cable!

In the pedestal versions, 40-pin ribbon cable is used internally.  The end
farthest from the drive electronics connects to a bulkhead connector with
ferroid RFI chokes on each data lead and a DB-25 connector.  On a DECmate
I or DECmate II with RX78, a DB-37 <-> DB25 cable is used to connect the
computer to the drives.  I have the rare dual pedestal pair version that
has two internal cables to the bulkhead connector with DB-37 (which is
compatible with VT-78, VT-278 and RX-78, all of which support two pairs of
drives).

cjl



From lasner@sunSITE.unc.edu Wed Jan  5 15:26:28 EST 1994
Article: 586 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 5 Jan 1994 20:19:42 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 46
Message-ID: <2gf7cu$l7n@bigblue.oit.unc.edu>
References: <CIvI64.366@world.std.com> <2g9fcp$aqa@corax.udac.uu.se> <2gbosa$l9v@bigblue.oit.unc.edu> <2geril$qlo@corax.udac.uu.se>
NNTP-Posting-Host: sunsite.unc.edu

In article <2geril$qlo@corax.udac.uu.se>,
Johnny Billquist <bqt@Update.UU.SE> wrote:
>lasner@sunSITE.unc.edu (Charles Lasner) writes:
>
>>In article <2g9fcp$aqa@corax.udac.uu.se>,
>>Johnny Billquist <bqt@Minsk.docs.uu.se> wrote:
>
>Bit 4 = 1	A core image file that was generated by LINK containing
>		overlays

Which linker?  Macrel, F4, FORT?

>Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
>		under OS/78

In OS/278, there is confusion here, since the functionality of bit[5] is
still present, but occurs if some combination of bits[0,1,10,11] are set,
besides their normal function as stated.  For example, ABSLDR is subject
to the restriction unless you make it run more inefficiently by removing
at least one of the stated bits.  Thus, if bit[11] is cleared, "R ABSLDR"
is allowed!  Bit[5] has no effect either way.

>Bit 6-9		Unused and reserved for future expansion

Isn't one of the other bits reserved for batch purposes?
>
>
>(If you set bit 11, and the device is a DECtape, it will run in
>reverse... :-)

Partially.  What you refer to is the "search forward first" bit for
DECtape and LINCtape.  This is one of the "features" I am attempting to
eliminate (because it's a conceptual waste) in OS/8 version 5.  All of the
affected devices can have "smarter" handlers written that don't require
the stupid bit; they can do the job better themselves.  The bit in turn is
more useful to be defined as the "^C abort" bit in 07601, although the
worst action taken would be to forward search first as a program exited, etc.
>
>>OS/278 is riddled with bugs in this area!
>
>(. Software always have a way to improve itself... .)

Yes, it certainly can!

cjl



From bqt@Update.UU.SE Thu Jan  6 06:39:30 EST 1994
Article: 587 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!bqt
From: bqt@Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 6 Jan 1994 02:55:22 GMT
Organization: Uppsala University
Lines: 66
Message-ID: <2gfuiq$fso@corax.udac.uu.se>
References: <CIvI64.366@world.std.com> <2g9fcp$aqa@corax.udac.uu.se> <2gbosa$l9v@bigblue.oit.unc.edu> <2geril$qlo@corax.udac.uu.se> <2gf7cu$l7n@bigblue.oit.unc.edu>
NNTP-Posting-Host: krille.update.uu.se

lasner@sunSITE.unc.edu (Charles Lasner) writes:

>In article <2geril$qlo@corax.udac.uu.se>,
>Johnny Billquist <bqt@Update.UU.SE> wrote:
>>lasner@sunSITE.unc.edu (Charles Lasner) writes:
>>
>>>In article <2g9fcp$aqa@corax.udac.uu.se>,
>>>Johnny Billquist <bqt@Minsk.docs.uu.se> wrote:
>>
>>Bit 4 = 1	A core image file that was generated by LINK containing
>>		overlays

>Which linker?  Macrel, F4, FORT?

Um, neither of those is a linker, Charles.
LINK and LOAD (and maybe ABSLDR) is linkers.
Since the manual said LINK in capital letters, this is most probably
LINK. The only program that I know of, which generate object code
for LINK, is MACREL.

>>Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
>>		under OS/78

>In OS/278, there is confusion here, since the functionality of bit[5] is
>still present, but occurs if some combination of bits[0,1,10,11] are set,
>besides their normal function as stated.  For example, ABSLDR is subject
>to the restriction unless you make it run more inefficiently by removing
>at least one of the stated bits.  Thus, if bit[11] is cleared, "R ABSLDR"
>is allowed!  Bit[5] has no effect either way.

Well, I won't ever touch OS/78 or later, from what I've heard.
As long as I stick with OS/8, things work fine and consistently.

>>Bit 6-9		Unused and reserved for future expansion

>Isn't one of the other bits reserved for batch purposes?

Hmmm, not that I know of. There is one bit for batch. Bit 3.

>>(If you set bit 11, and the device is a DECtape, it will run in
>>reverse... :-)

>Partially.  What you refer to is the "search forward first" bit for
>DECtape and LINCtape.

Ummm, maybe, and maybe not.
To quote the manual:
"Bits 9 to 11	Device dependent bits, can be left zero.
		Currently only bit 11 is used;  on DECtape
		bit 11 determines the direction in which the
		tape is started.  If bit 11 is 0, the tape
		starts in reverse.  If bit 11 is 1, the tape
		starts forward.  All other handlers ignore
		these bits at present (except TM8E and TA8E)."

I'm not sure how this works out in life, and since my system with the
TD8E is at my parents place, I can't test it either...
I'll assume this just tells in which direction it should start
serching then.

	Johnny
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From supnik@human.enet.dec.com Thu Jan  6 06:41:02 EST 1994
Article: 588 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!agate!ames!decwrl!pa.dec.com!nntpd.lkg.dec.com!sousa.ako.dec.com!human.enet.dec.com!supnik
From: supnik@human.enet.dec.com (Bob Supnik)
Newsgroups: alt.folklore.computers,alt.sys.pdp8
Subject: Information Wanted: NOVA Moving Head Disk Controller (DKP)
Date: 5 JAN 94 21:55:00
Organization: Digital Equipment Corporation
Lines: 13
Message-ID: <2gfufk$el9@sousa.ako.dec.com>
NNTP-Posting-Host: human.enet.dec.com
Summary: Wanted: spec for early 70's NOVA disk controller
Keywords: NOVA, disk, specification
Xref: bigblue.oit.unc.edu alt.folklore.computers:54506 alt.sys.pdp8:588

As part of the historic machines project (to create simulators for
machines of historic interest), I am looking for a specification, users
manual, or even an O/S driver for the NOVA moving head disk controller
(mnemonic DKP under RDOS, device 033 or 073).  This controller handled
a variety of drives, including the Diablo 33 and 44, the Century 111
and 114, and DG's first floppy disk drive.  Please reply my email, as
I don't necessarily follow these conferences.

Thanks,

Bob Supnik	>Supnik@human.enet.dec.com
		>All opinions expressed are those of a hardline microcoder
		>and do not reflect those of Digital Equipment Corporation


From lasner@sunSITE.unc.edu Thu Jan  6 06:41:32 EST 1994
Article: 589 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 6 Jan 1994 11:39:23 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 438
Message-ID: <2ggt9b$aq1@bigblue.oit.unc.edu>
References: <CIvI64.366@world.std.com> <2geril$qlo@corax.udac.uu.se> <2gf7cu$l7n@bigblue.oit.unc.edu> <2gfuiq$fso@corax.udac.uu.se>
NNTP-Posting-Host: sunsite.unc.edu

In article <2gfuiq$fso@corax.udac.uu.se>,
Johnny Billquist <bqt@Update.UU.SE> wrote:
>lasner@sunSITE.unc.edu (Charles Lasner) writes:

>>>Bit 4 = 1	A core image file that was generated by LINK containing
>>>		overlays
>
>>Which linker?  Macrel, F4, FORT?
>
>Um, neither of those is a linker, Charles.

Macrel has an associated linker, as does F4 and FORT.  Each linker handles
(potentially) relocatable binary for its "family"'s files.

>LINK and LOAD (and maybe ABSLDR) is linkers.

LINK is the MACREL family linker apparently.  I think LOAD is the FORT
family linker (aka linking loader), and LOADER is the one for F4.  (Those
last two backwards?  Also, doesn't one of them have a library maintainer
called LIBRA?  Perhaps there is also a parallel program called LIBR for
the FORT family?  What is the equivalent for the MACREL family?)

ABSLDR is not a linker; it merely loads absolute binary paper-tape files
and does nothing that a linker ever does.  No image is created; merely,
memory is loaded wherever OS/8 allows it.  The SAVE command is used to
create an image file and must be used before any other commands wipe out
the image, etc.  Linkers have to deal with relocatable binary; ABSLDR
never does.  Linkers ought to have the concept of a library; clearly,
ABSLDR does not, nor can it since there is no relocatability (nor should
there be for its purpose).  ABSLDR also doesn't have the concept of
symbols or references or resolving or even designation of the "hierarchy"
of modules or even designating a starting address other than as an option
switch to indicate load-and-go as opposed to load and return to O/S. 
Thus, the basic function of something to link is absent.  All files loaded
by a *non*-linking loader such as ABSLDR have to be self-contained in terms
of no external references possible (except definable absolute ones like
the convention of calling the system handler at 07607, etc.).  It's just
that PDP-8 code, since it's designed for a fixed environment of generally
32K or 8K or 4K doesn't need any of these "features" unless you are
writing mindlessly regarding the efficiency of tight coding, etc.  (You
have to admit that by using MACREL, you have sacrificed certain ways in
which your code could be space-optimized; since there's often not much
space available, this can become counter-productive!  From the point of
view of a tight coder attempting to make a program fit into 4K or at most
8K to make it possible to run on all standard configurations, MACREL and
relocatable code generation seems to offer mostly negativisms!)

>Since the manual said LINK in capital letters, this is most probably
>LINK. The only program that I know of, which generate object code
>for LINK, is MACREL.

I can believe this.  When MACREL was released, it attracted a whole
generation of sloppy programmers.  One of the reasons was because it
promoted the use of a supplied mechanism for swapping in code.  Thus,
programs that never needed to be written with overlays if properly coded
were suddenly swapping, but only on the system device.  This mechanism was
inadvertantly and illadvisedly applied to several OS/8 system programs
until a manager realized the inherent conceptual bug in the process -
namely that it meant that the program violated OS/8 standards!  Attempts
to use the program via the "RUN" command corrupted the system!  As a
result, budgetary money was wasted "de-MACREL-izing" some programs, and
some were just summarily dropped, such as RESORC.SV, which is not
available for OS/278!  (The problem is that the swapping macro, as
provided, merely shows a mechanism for allowing the user to more easily
write overlay-oriented code from MACREL.  However, it has *never* been
necessary to require either the macro or the code within it to allow
overlay-oriented programming; it's admittedly easier to do it this way of
course.  Unfortunately, the provided macro is more limited than would-be
users suspected it - it requires that the affected program reside totally
on the SYS: device, and must be invoked with the "R" command.  Thus,
commands such as RUN DEV: RESORC.SV become dangerous to attempt as they
fail to execute the intended program.  OS/8 doesn't provide even a
mechanism to gracefully prevent this from being attempted; I suspect this
bit you mention is a "band-aid" on that problem.  In any case, the
incorrect usage of MACREL has clearly caused backwards steps in the
development of OS/8.  Even now, it becomes necessary to waste development
effort correcting mistakes of the past.  Some are attributable to hardware
incompatibility such as the DECmate-induced debacle, but the
MACREL-induced issues were/are totally avoidable.  As a specific aside,
it's my understanding that there was a small "wish list" associated with
RESORC, and to avoid having to optimize the code (which was never
particularly optimal, thus it had much potential to be hand-bummed down in
size!), a manager was talked into allowing it to be "translated" into
MACREL and take "advantage" of the available swapping capability to allow
it to still be usable in 8K, implement all of the wish-list features, and
still have plenty of development potential for the future, etc.  From the
manager's standpoint, this sounds (too) good (to be true), because it
means that he doesn't have to have one of the tight-coders maintain the
program anymore, and can instead depend on a lesser-qualified person (to
write tight -8 code!) to produce an acceptable (albeit slower due to
swapping) utility.  But since there are no system safeguards against using
the program as documented (such as RUN RXA0 RESORC) but in ways that fail,
there was some "spectacular" form of crash as someone used it that way,
etc.  As a result, RESORC was dropped entirely because no one good enough
to repair it was available.  For myself, I still wonder why they didn't
merely recycle the previous PAL8 version?)

Anyway, I'm not really here to start a "religious" war against MACREL,
just to point out that sometimes TAASTAAFL.  The translation to MACREL was
promoted on a false premise, namely that unrestricted swapping was
available to these CUSP's, and that *nothing* else would change.  Clearly,
once stripped of the false promise/premise, the conversion offers little
to support it; for the most part, MACREL was abandoned by those involved
in such projects.  (Note: others continued to use MACREL!  However, every
one of them is associated with a project, such as WPS, where traditional
PDP-8 code-squeezing is never performed.  WPS requires 32K; Master Menu
makes the user wait for 4 memory fields to be loaded each and every time
it comes up; it even counts down "4 3 2 1" as it is being loaded. 
Considering just how much (or little!) the user interface in MM is, 16K
seems to be an awful amount of code to accomplish that function, etc. 
Additionally, each menu option causes additional disk I/O, so this cannot
be attached to the notion of just attempting to load the "entire" program
in, as ill-advised as that would be.  It just appears that MM is overly
modularized and thus runs slower than necessary, etc.)

>
>>>Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
>>>		under OS/78
>
>>In OS/278, there is confusion here, since the functionality of bit[5] is
>>still present, but occurs if some combination of bits[0,1,10,11] are set,
>>besides their normal function as stated.  For example, ABSLDR is subject
>>to the restriction unless you make it run more inefficiently by removing
>>at least one of the stated bits.  Thus, if bit[11] is cleared, "R ABSLDR"
>>is allowed!  Bit[5] has no effect either way.
>
>Well, I won't ever touch OS/78 or later, from what I've heard.
>As long as I stick with OS/8, things work fine and consistently.

That's simply not true!  OS/78 is a mode of OS/8 V3D (internal version 3Q)
and not a separate O/S.  Later versions merely dropped the "OS/8" name and
officially became known as OS/78.  Here's the relevant history:

PS/8 V1		The original 1970 system
PS/8 V2		An upgraded system in various stages through 1973
OS/8 various versions before V3D which weren't stable.  Eventually we
realize that versions of system release and internal release versions
don't match!  The one that tends to stabilize is called V3D and internally
V3Q.  Various marketing schemes are applied to products all claiming to be
V3D.  One is an upgrade kit supporting TECO, but also includes an
alternate O/S head that supports the KT8A from the ODT command, and
includes some kludged utility to allow tedious extended SAVE operations
for memory beyond 32K and some form of support for the extended images
thus created.  (I think one of the programs was called SAVCCB) Another is
an alledged "different" O/S called OS/78, complete with its own variant
manual.  This package includes mostly standard release versions of the
CUSP's, although some are patched up to the latest revision level; someone
even suggested purchasing it to ensure getting the latest revisions!  The
only actual utilities included anew are the "symbiont" print spooling
program and its support routines.  Other than that, it turns out that the
KL8E handler has been "raped" so that it now only assembles correctly for
systems with VT-52 consoles (making changes produce either assembly errors
or misfeatures, or incompatibility with the SET command for console
functions), and that all of the supplied CUSP's now include a reservation
of location 00000-00002 to include an interrupt handler presumed to exist
in field 3.  (Each program has a place to save the PC on 00000; CIF 30 in
00001; JMP 0000 in 00002.  This only works if the machine is exactly 16K
such as a VT-78 *and* if there are no DMA disk devices!  Of course, the
system device of the 16K VT-78 is an RX, thus no problem on that limited
configuration!)  And of course, that fore-mentioned restriction on the
ability to use R or RUN or GET on the CUSP's.

At about this point, with all of the allegedly "same" versions that are
actually markedly different, something had to break!  In this case, it was
the software distribution mailing list!  What actually happened was that
the software distribution people switched to a PDP-11!  As a result, the
list was "accidently" mostly lost!  Virtually everyone who was ever on the
mailing list was now no longer getting the monthly updates and patches to
OS/8, etc. that had been reliably available up until then.  This situation
lasted well over a year despite numerous protests from angry users!  As a
result of all of this negativism, the managers alienated the entire
customer base - they decided to charge for updates!  One thing was done
though: a special "update" edition was published for the entire period. 
It was even fairly typo free.  (Note: these updates were often unreliable
because instead of using actual console output of ODT sessions, they had
secretaries with limited technical expertise transcribing the console
output!  Eventually, someone suggested a paste-up using a DECwriter
console printout!)  Several people were able to patch up a better working
OS/8 V3D system as a result, etc.  However, as late as 1980, DEC was
attempting to sell an overpriced (100's of % inflated price over the
previous V3D release!) package of OS/8 V3D which merely was the old
original with the programs at proper patch revision!  From a user's
standpoint, this was unconscionable.  DEC's managers were gouging the
users because they were responsible for complaining about management's
mistakes!

Somewhere in the midst of this, there was a release called OS/78 V2.  It
consisted of a one-page release note and some paper-tapes to update BASIC
and provide RL handlers.  (Whether there ever was a packaged "complete"
release I really don't know, but the update was quite meager!)

Eventually OS/78 V3 was released.  By this point, managers didn't want
anything called "OS/8" because of their self-induced (as a group) debacle.
Further, it become quite obvious that this release was a tossup as to
whether it was a step forwards, or a step backwards!  The key "features"
of this system seem to be:

1)	Support of the RL02 (which can be applied to V3D).

2)	Dropping support of all of the handlers other than RX, RK, RL,
TD8E.  This was proven to be a managerial manipulation.  All of the
handlers were stable; there was no reason to excise them!  However, there
were no machines available anymore to run them on just in case there was a
problem, etc.

3)	Dropping support for "pre-Omnibus" machines.  Since it is possible
to attach an RX to any -8, and specifically, many people had just recently
purchased DW8E's to attach the RK05 (w/RK8F, *not* RK8E!) to their -8/i,l,
-12's, etc., this was particularly offensive!

4)	Removing the ";" command support.  (Note: a feature of OS/8 V3D is
that if a command line ends with a ";", the command is not processed! 
Instead, it becomes input to an on-line editor.  The input terminates when
a line is typed that ends *without* a ";".  Then the entire file is passed
to BATCH, which in turn requires 12K to run.  If only 8K is available, the
process fails gracefully with a BATCH message to the effect of only 8K
available, thus wasting all of the user's typing.)

This system can have the OS/78 mode enabled or not, just like V3D (and
OS/78 V2, considering how little that contributes!), but cannot run
completely on -8, LINC-8, -8/i, -8/l, -12 because it is riddled with
defective constructs such as dependancy on OPR micro-coding where IAC and
rotates work as -8 and LINC-8 do not.  In fact, some ill-advised programs
were distributed with V3D such as the TC01/08 DECtape formatter modified
incorrectly to include CAF instructions which crashes certain models. 
(The instructions 600x behave differently on different models.  CAF is
6007 which pulses on all three IOP lines on an older machine.  On some
models, it enabled interrupts, on KF-12B-capable PDP-12 it enables API; on
the LINC-8 and PDP-8 it hangs!)  But in V3T (the internal version of OS/78
V3), the use of instructions that cannot run on older models became much
worse.

This wasn't merely an attempt to use BSW to create forced obsolescence;
there no longer were many people skilled in the art of not using extension
instructions!  As an example, there was a dialogue with one of the new
"developers" who assured us that he "knew what he was doing" and wouldn't
use anything that would be incompatible.  As an example, he showed us that
he knew how to code NL0002.  Unfortunately, he used:

CLA CLL IAC RAL

instead of

CLA CLL CML RTL

>From this point we realized that there was no hope!

Then they addressed the DECmate problem, and created the largely defective
OS/78 V4.  This release suffered from a lot of "surgery" and had out and
out problems not traceable to the incompatible DECmate hardware.  It also
had a large price tag, and was unpopular.

>From a long-term perspective, it was becoming obvious that DEC was
charging more and more for less and less, albeit likely because they were
involving more and more (but less and less skilled!) people in the
project, and pricing was based on costs, not quality of product.

OS/278 V1 was never released.  Many of us have self-start versions of it
which are the various forms of "install" RX50 disks for the DECmate II.  I
have an "enhanced" version of the System Test Diskette Version 2.4 which
restores the directory entries for deleted (but still present!) programs
including a lot of familiar CUSP's.  By renaming the startup program (from
OS/278 V2), you can gain control of the OS/278 V1 keyboard monitor. 
(Note: several versions of OS/8 support the feature of SET SYS INIT R
PROG.SV where PROG.SV is any system program.  On this particular disk, the
feature was enabled and all of the code is ignoring ^C abort attempts,
thus the disk can only be used for the intended purpose of a diagnostic
menuing system.  But by making the designated program unavailable, the
keyboard monitor complains that the file is not found, and provides the
normal prompt!)  Many of the CUSP's are just OS/78 V4 programs with no
changes, etc.

OS/278 V2 was released to DECUS, and is available on sunsite.unc.edu.  The
files were released as DM-101, and alleged "sources" as DM-111.  However,
the sources are not quite compatible with the binaries, and seem to be
about a half-generation behind the running binary.  Additionally, they are
incomplete!  Moreover, there are no sources to the part of the overall
environment that OS/278 V2 has to interact with, namely Master Menu, the
hard disk partition area, the ROM's, and the "slushware" (latest known
version = 422 aka "R").

Many aspects of OS/278 arbitrarily change some of OS/8 apparently to the
personal preference of some of the newest "developers".  Some bugs of
OS/78 were fixed; some were not.  Some were introduced!  A few are the
consequences of either dealing with the hardware differences in an
expedient manner, or not researching ways around apparent problems that
actually can be overcome with some effort.  (Note: I am making a
distinction here between OS/8 changes done to accomodate the hardware that
lead to different operation and OS/8 changes made because of misperceived
problems.  The former requires changes to the OS/8 structure; the latter
requires elimination of code added unnecessarily to band-aid problems that
can be better dealt with.  For example, the DECmate console hardware is
forever incompatible with the -8.  Only a new approach amenable to all
hardware will run on all machines; neither the traditional approach of
OS/8 nor the lame approach of OS/278 is acceptable.  However, OS/278 is
"broken" in aspects of the SET SYS command because of misperceived
limitations of the hardware, which can actually be worked around.  Thus,
the command's functionality can be restored to that of OS/8 without
dependancy on resolving the other hardware-specific problems.  The
developers of OS/278 applied their changes expediently because they knew
no way to resolve the hardware problem.  I have cleverly solved the
problem, thus making the changes unnecessary!  In fact, their expediency
isn't completely implemented, and as such is currently "risky" to use. 
When all of the changes are removed, this aspect of OS/278 will again be
OS/8 compatible!)

The tentative system I am working on to replace all of this mess is
called OS/8 Version 5.  It will be compatible with existing PDP-8
programs, but only if they are run on PDP-8 hardware.  CUSP's will have to
be rewritten to work with new conventions that are acceptable to all
hardware, but older versions will continue to work where possible, i.e.,
on pre-DECmate machines.  The new CUSP's will retain all of the
functionality of OS/8 regardless of hardware they are running on, etc. 
All of the personal-preference-induced changes of OS/278 will be
eliminated in favor of the original OS/8 settings.  In some cases, it may
be possible to support the OS/278 variants as user-settable options
subject to restrictions.  For example, OS/278 changes the prompt character
from "." to "}".  While this seems to be merely a cosmetic change, it also
affects the exact nature of BATCH operations.  Regardless of choice, BATCH
files from one era of OS/8 family existence are incompatible, etc.  Some
"latitude" may be necessary to correct this, etc.

>>>(If you set bit 11, and the device is a DECtape, it will run in
>>>reverse... :-)
>
>>Partially.  What you refer to is the "search forward first" bit for
>>DECtape and LINCtape.
>
>Ummm, maybe, and maybe not.
>To quote the manual:
>"Bits 9 to 11	Device dependent bits, can be left zero.
>		Currently only bit 11 is used;  on DECtape
>		bit 11 determines the direction in which the
>		tape is started.  If bit 11 is 0, the tape
>		starts in reverse.  If bit 11 is 1, the tape
>		starts forward.  All other handlers ignore
>		these bits at present (except TM8E and TA8E)."
>

For starters:

The TM8E and the TA8E don't count!  These are *not* disk device handlers;
they are strictly non-file-structured device handlers ala paper-tape.  The
use of a non-file structured handler causes a totally different action to
be taken since the entire device is a single file.  (For example, only a
non-file structured device can take a "soft" error return meaning
returning to the error return from a handler call with the AC *not* set to
a negative value.  This means the device is at End-Of-File, a concept
alien to a disk handler, etc.)

No handlers for disk devices use bits[9-10] and only the DECtape and
LINCtape handlers are elegible to use bit[11].  In point of fact, OS/8
only has a few pieces of code hard set to enable this bit at all!  This is
in the few places where it's a certainty that the next piece of data
needed is further down the tape than the present position.  Thus,
searching forward first saves a turn-around, since the default (when the
bit is 0) is to search backwards first.  (Note: statistically speaking,
most searchs *ought* to start backwards, because the data cannot be
accessed forwards.  This is the nature of DECtape and LINCtape.  Once you
shut down the tape, it rolls over the data you likely next want.  Unless
the next data transfer is at least three blocks forward of the last
transferred block, searching forwards is guaranteed to be the wrong thing
to do, and will only result in a double-turn around as the tape first goes
forwards, then reverses, traveling back to before the intended data's
block by three or more blocks less, etc., then turning around again to
transfer the data moving forward again.  By starting the search backwards,
the "extra" turn around is eliminated.  However, loading a file that is
many blocks forward of the directory is a case where searching forwards
first will be beneficial.  Unfortunately, there are few cases in OS/8
where this bit can be statically presented and it's hardly ever set, etc.)

Regardless of the setting of the bit, the ultimate data transfer is always
forwards, and only the overhead of search timing can be affected in any
way whatsoever, etc.

However, dependancy on this bit is ill-conceived, since it's possible to
write alternate handlers for the TC08 (and likely TD8E) that fend for
themselves in this issue.  Thus, a "smarter" DECtape handler will always
search in the best direction without being "told" to do it.  Additional
optimizations dynamically occur that OS/8 wasn't able to pass to the
handler merely because they weren't statically calculable, etc.

P?S/8 TC08 and TD8E system handlers already do this.  I have written an
alternate TC01/08 OS/8 handler that supports this (and ignores bit[11]). 
By using some techniques already present in the P?S/8 TD8E handler, it
appears likely that the TD8E can be similarly upgraded.

On the LINC-8, either hardware changes or an additional field of memory
are required to run either P?S/8 or OS/8.  The handlers for P?S/8 in 4K
and OS/8 in 8K already search in the proper initial direction.  (I wrote
both of them.)  The handler for an 8K minimum LINC-8 P?S/8 LINCtape system
(without hardware changes) also searches properly.  I have never had
access to a 12K LINC-8 to develop an OS/8 equivalent.

On the PDP-12, the handlers for 4K P?S/8 and 8K OS/8 LINCtape do not
search forwards ever due to limitations of the hardware (which *always*
searchs backwards unless you do a lot of work-around coding to counteract
the "automatic" nature of the hardware; this is beyond the scope of the
handler.  However, P?S/8 has an optional feature: the console overlay. 
When the console overlay is enabled, most of an additional memory field
is reserved for it.  Thus, most P?S/8 systems then require 8K, and a few
12K because of this, etc.  As part of the console overlay, two pages are
reserved for a "handler enhancement" that allows user interaction with
device errors reminiscent of the PDP-9/15 IOPS system, or even the MS-DOS
"critical" error handler, etc.  As part of the PDP-12 LINCtape version of
this code, the handler can actually force the tape hardware to search
forwards if appropriate!  It is possible to write a two-page OS/8
non-system handler or perhaps a two-page 12K system handler that would
also accomplish this, but the philosophy of OS/8 (and P?S/8!) is to always
attempt to write a one-page system handler to allow a minimum system (8K
for OS/8, 4K for P?S/8) so this was never done, etc.  The existing
handlers for 8K OS/8 on PDP-12 LINCtape are otherwise fine.)

Thus, the use of bit[11] is at most innocuous to the transfer, and more
importantly is not the best use of resources, since better handlers can be
written to serve the intended, but crudely implemented, feature of tape
search optimization.

Moreover, I want to incorporate the use of bit[11] as part of the "^C
abort" feature of OS/8 Version 5 to forever eliminate hardware dependancy
of the DECmates, etc.  The system call in 07600 would allow the low-order
bit(s) of 07601 to be set when a program aborts.  Thus, even if the
console hardware is incompatible, a program can still indicate it was
aborting due to ^C being hit.  (Note: on DECmates, KSF doesn't skip more
than once!  This is the key reason why traditional OS/8 console handling
can't work on a DECmate.  A program detecting the user's ^C keystroke
cannot convey that information to the keyboard monitor because KRS cannot
be used to pre-read the character without disturbing the flag, and KSF
clears the flag, thus it's no longer set!  By the time the keyboard
monitor could notice KSF skipping again, it's for an additional typed
character, not the ^C that caused the abort, etc.  By allocating bit[11]
to this purpose, an aborting program can signal the abort to the keyboard
monitor by executing ISZ I (7601).  By allocation of bits[9-11], there is
an additional safeguard against accidental multiple executions, since the
code could only be destroyed if executed more than seven times.)

cjl



From cchd@lucifer.latrobe.edu.au Thu Jan  6 23:46:48 EST 1994
Article: 590 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!usenet.ufl.edu!usenet.cis.ufl.edu!caen!batcomputer!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!lucifer!cchd
Newsgroups: alt.sys.pdp8
Subject: Re: PDP-8A and Dual floppies
Message-ID: <1994Jan6.101226.29319@lugb.latrobe.edu.au>
From: cchd@lucifer.latrobe.edu.au (Huw Davies)
Date: Thu, 6 Jan 1994 10:12:26 GMT
Sender: news@lugb.latrobe.edu.au (USENET News System)
References: <1994Jan5.083414.15937@lugb.latrobe.edu.au> <2gf1ii$min@math.mps.ohio-state.edu>
Organization: La Trobe University
Lines: 37

In article <2gf1ii$min@math.mps.ohio-state.edu> dicks@math.ohio-state.edu (Ethan Dicks) writes:
>
>No magic.  The standard cable has two 40-pin IDC connectors on each end
>of a 40-wire ribbon cable.  It's one of the most ordinary cables used in
>DEC hardware.  If you have to make one, just crimp a 40-pin connector
>on each end of the cable.  I've got a bin of them, but shipping precludes
>an easy solution.  Perhaps someone in OZ could help you out.

Constructing the cable wasn't difficult, it was just that I didn't want
to destroy the one and only -8A that I have access to. Normally in
self-maintenance mode I check with another identical system before
making any cables/changes etc (this works really well with our 11/785s
and 8800s under my maintenance care).

>If you have a ribbon cable already coming out of the controller, what is on
>the end of it that won't fit into the respective connector on the RX02?

A simple male connector at both the CPU and RX01 ends.

The good news is that the -8A booted for the first time earlier today.
I've even run a couple of basic programs (Snoopy amongst them) which
brought back some memories. Tomorrow I've promised myself to read a
little more about OS/8 and see if I can compile a simple FORTRAN
program.

On a related issue, where can I get a copy of FOCAL for the -8 and how
do I get it onto the machine?

There is a possibility that later this month that the -8A and an 11/44
that I'm setting up will appear on the net. Stay tuned for details...


-- 
  Huw Davies           | Huw.Davies@latrobe.edu.au
  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 bqt@Update.UU.SE Fri Jan  7 00:52:45 EST 1994
Article: 591 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!bqt
From: bqt@Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 6 Jan 1994 14:26:15 GMT
Organization: Uppsala University
Lines: 321
Message-ID: <2gh727$i9q@corax.udac.uu.se>
References: <CIvI64.366@world.std.com> <2geril$qlo@corax.udac.uu.se> <2gf7cu$l7n@bigblue.oit.unc.edu> <2gfuiq$fso@corax.udac.uu.se> <2ggt9b$aq1@bigblue.oit.unc.edu>
NNTP-Posting-Host: krille.update.uu.se

lasner@sunSITE.unc.edu (Charles Lasner) writes:

>In article <2gfuiq$fso@corax.udac.uu.se>,
>Johnny Billquist <bqt@Update.UU.SE> wrote:
>>lasner@sunSITE.unc.edu (Charles Lasner) writes:

>>>>Bit 4 = 1	A core image file that was generated by LINK containing
>>>>		overlays
>>
>>>Which linker?  Macrel, F4, FORT?
>>
>>Um, neither of those is a linker, Charles.

>Macrel has an associated linker, as does F4 and FORT.  Each linker handles
>(potentially) relocatable binary for its "family"'s files.

Associated linker is not the same as a linker.
Even though only one program generate code for each linker,
the linkers are general programs, which very well could be
fed with output from other programs, just that none have been
written.

>>LINK and LOAD (and maybe ABSLDR) is linkers.

>LINK is the MACREL family linker apparently.  I think LOAD is the FORT
>family linker (aka linking loader), and LOADER is the one for F4.  (Those
>last two backwards?  Also, doesn't one of them have a library maintainer
>called LIBRA?  Perhaps there is also a parallel program called LIBR for
>the FORT family?  What is the equivalent for the MACREL family?)

You are right on all accounts.
There is no library maintainer for the "MACREL family".
You create libraries just by using PIP.
The format of the object file is such that you can have them
concatenated.

>ABSLDR is not a linker; it merely loads absolute binary paper-tape files
>and does nothing that a linker ever does.

That's why I put it inside parenthesis. It does a very meager subset
of what linkers do.
I know you dislike macro assemblers. :-)

>Anyway, I'm not really here to start a "religious" war against MACREL,
>just to point out that sometimes TAASTAAFL.  The translation to MACREL was
>promoted on a false premise, namely that unrestricted swapping was
>available to these CUSP's, and that *nothing* else would change.

TANSTAAFL is always true.
Another golden rule is, if it ain't broke, don't fix it.
Seems to me that DEC broke that rule...

>>>>Bit 5 = 1	This program cannot be run by the R, RUn, or GET commands
>>>>		under OS/78
>>
>>>In OS/278, there is confusion here, since the functionality of bit[5] is
>>>still present, but occurs if some combination of bits[0,1,10,11] are set,
>>>besides their normal function as stated.  For example, ABSLDR is subject
>>>to the restriction unless you make it run more inefficiently by removing
>>>at least one of the stated bits.  Thus, if bit[11] is cleared, "R ABSLDR"
>>>is allowed!  Bit[5] has no effect either way.
>>
>>Well, I won't ever touch OS/78 or later, from what I've heard.
>>As long as I stick with OS/8, things work fine and consistently.

>That's simply not true!  OS/78 is a mode of OS/8 V3D (internal version 3Q)
>and not a separate O/S.  Later versions merely dropped the "OS/8" name and
>officially became known as OS/78.  Here's the relevant history:

>PS/8 V1		The original 1970 system
>PS/8 V2		An upgraded system in various stages through 1973
>OS/8 various versions before V3D which weren't stable.  Eventually we
>realize that versions of system release and internal release versions
>don't match!  The one that tends to stabilize is called V3D and internally
>V3Q.  Various marketing schemes are applied to products all claiming to be
>V3D.  One is an upgrade kit supporting TECO, but also includes an
>alternate O/S head that supports the KT8A from the ODT command, and
>includes some kludged utility to allow tedious extended SAVE operations
>for memory beyond 32K and some form of support for the extended images
>thus created.  (I think one of the programs was called SAVCCB) Another is
>an alledged "different" O/S called OS/78, complete with its own variant
>manual.  This package includes mostly standard release versions of the
>CUSP's, although some are patched up to the latest revision level; someone
>even suggested purchasing it to ensure getting the latest revisions!  The
>only actual utilities included anew are the "symbiont" print spooling
>program and its support routines.  Other than that, it turns out that the
>KL8E handler has been "raped" so that it now only assembles correctly for
>systems with VT-52 consoles (making changes produce either assembly errors
>or misfeatures, or incompatibility with the SET command for console
>functions), and that all of the supplied CUSP's now include a reservation
>of location 00000-00002 to include an interrupt handler presumed to exist
>in field 3.  (Each program has a place to save the PC on 00000; CIF 30 in
>00001; JMP 0000 in 00002.  This only works if the machine is exactly 16K
>such as a VT-78 *and* if there are no DMA disk devices!  Of course, the
>system device of the 16K VT-78 is an RX, thus no problem on that limited
>configuration!)  And of course, that fore-mentioned restriction on the
>ability to use R or RUN or GET on the CUSP's.

>At about this point, with all of the allegedly "same" versions that are
>actually markedly different, something had to break!

Well, it seems to me that OS/78 definitely are different from OS/8.
Your accounting just give me more reason to believe so.
Why you started by saying it wasn't so I don't understand.

>Eventually OS/78 V3 was released.  By this point, managers didn't want
>anything called "OS/8" because of their self-induced (as a group) debacle.
>Further, it become quite obvious that this release was a tossup as to
>whether it was a step forwards, or a step backwards!  The key "features"
>of this system seem to be:

>1)	Support of the RL02 (which can be applied to V3D).

>2)	Dropping support of all of the handlers other than RX, RK, RL,
>TD8E.  This was proven to be a managerial manipulation.  All of the
>handlers were stable; there was no reason to excise them!  However, there
>were no machines available anymore to run them on just in case there was a
>problem, etc.

>3)	Dropping support for "pre-Omnibus" machines.  Since it is possible
>to attach an RX to any -8, and specifically, many people had just recently
>purchased DW8E's to attach the RK05 (w/RK8F, *not* RK8E!) to their -8/i,l,
>-12's, etc., this was particularly offensive!

>4)	Removing the ";" command support.  (Note: a feature of OS/8 V3D is
>that if a command line ends with a ";", the command is not processed! 
>Instead, it becomes input to an on-line editor.  The input terminates when
>a line is typed that ends *without* a ";".  Then the entire file is passed
>to BATCH, which in turn requires 12K to run.  If only 8K is available, the
>process fails gracefully with a BATCH message to the effect of only 8K
>available, thus wasting all of the user's typing.)

Hmmm, interesting. The only thing I've ever seen with ";" on OS/8 was
the original version of CCL that I was using, which had the ";" to
separate commands, like in UNIX. The was removed in CCLX, which I now
use.
To actually separate the commands, CCL created a file with the commands,
and called BATCH to execute them one after another.

>This system can have the OS/78 mode enabled or not, just like V3D (and
>OS/78 V2, considering how little that contributes!), but cannot run
>completely on -8, LINC-8, -8/i, -8/l, -12 because it is riddled with
>defective constructs such as dependancy on OPR micro-coding where IAC and
>rotates work as -8 and LINC-8 do not.  In fact, some ill-advised programs
>were distributed with V3D such as the TC01/08 DECtape formatter modified
>incorrectly to include CAF instructions which crashes certain models. 
>(The instructions 600x behave differently on different models.  CAF is
>6007 which pulses on all three IOP lines on an older machine.  On some
>models, it enabled interrupts, on KF-12B-capable PDP-12 it enables API; on
>the LINC-8 and PDP-8 it hangs!)  But in V3T (the internal version of OS/78
>V3), the use of instructions that cannot run on older models became much
>worse.

>This wasn't merely an attempt to use BSW to create forced obsolescence;
>there no longer were many people skilled in the art of not using extension
>instructions!  As an example, there was a dialogue with one of the new
>"developers" who assured us that he "knew what he was doing" and wouldn't
>use anything that would be incompatible.  As an example, he showed us that
>he knew how to code NL0002.  Unfortunately, he used:

>CLA CLL IAC RAL

>instead of

>CLA CLL CML RTL

>From this point we realized that there was no hope!

>Then they addressed the DECmate problem, and created the largely defective
>OS/78 V4.  This release suffered from a lot of "surgery" and had out and
>out problems not traceable to the incompatible DECmate hardware.  It also
>had a large price tag, and was unpopular.

Well, by this time then, you cannot claim that OS/8 and OS/78 are the same.
OS/8 stayed by V3D (or 3Q internally, which actually is what my OS/8
says it is...)

>From a long-term perspective, it was becoming obvious that DEC was
>charging more and more for less and less, albeit likely because they were
>involving more and more (but less and less skilled!) people in the
>project, and pricing was based on costs, not quality of product.

>OS/278 V1 was never released.  Many of us have self-start versions of it
>which are the various forms of "install" RX50 disks for the DECmate II.  I
>have an "enhanced" version of the System Test Diskette Version 2.4 which
>restores the directory entries for deleted (but still present!) programs
>including a lot of familiar CUSP's.  By renaming the startup program (from
>OS/278 V2), you can gain control of the OS/278 V1 keyboard monitor. 
>(Note: several versions of OS/8 support the feature of SET SYS INIT R
>PROG.SV where PROG.SV is any system program.  On this particular disk, the
>feature was enabled and all of the code is ignoring ^C abort attempts,
>thus the disk can only be used for the intended purpose of a diagnostic
>menuing system.  But by making the designated program unavailable, the
>keyboard monitor complains that the file is not found, and provides the
>normal prompt!)  Many of the CUSP's are just OS/78 V4 programs with no
>changes, etc.

>OS/278 V2 was released to DECUS, and is available on sunsite.unc.edu.  The
>files were released as DM-101, and alleged "sources" as DM-111.  However,
>the sources are not quite compatible with the binaries, and seem to be
>about a half-generation behind the running binary.  Additionally, they are
>incomplete!  Moreover, there are no sources to the part of the overall
>environment that OS/278 V2 has to interact with, namely Master Menu, the
>hard disk partition area, the ROM's, and the "slushware" (latest known
>version = 422 aka "R").

>Many aspects of OS/278 arbitrarily change some of OS/8 apparently to the
>personal preference of some of the newest "developers".  Some bugs of
>OS/78 were fixed; some were not.  Some were introduced!  A few are the
>consequences of either dealing with the hardware differences in an
>expedient manner, or not researching ways around apparent problems that
>actually can be overcome with some effort.  (Note: I am making a
>distinction here between OS/8 changes done to accomodate the hardware that
>lead to different operation and OS/8 changes made because of misperceived
>problems.  The former requires changes to the OS/8 structure; the latter
>requires elimination of code added unnecessarily to band-aid problems that
>can be better dealt with.  For example, the DECmate console hardware is
>forever incompatible with the -8.  Only a new approach amenable to all
>hardware will run on all machines; neither the traditional approach of
>OS/8 nor the lame approach of OS/278 is acceptable.  However, OS/278 is
>"broken" in aspects of the SET SYS command because of misperceived
>limitations of the hardware, which can actually be worked around.  Thus,
>the command's functionality can be restored to that of OS/8 without
>dependancy on resolving the other hardware-specific problems.  The
>developers of OS/278 applied their changes expediently because they knew
>no way to resolve the hardware problem.  I have cleverly solved the
>problem, thus making the changes unnecessary!  In fact, their expediency
>isn't completely implemented, and as such is currently "risky" to use. 
>When all of the changes are removed, this aspect of OS/278 will again be
>OS/8 compatible!)

>The tentative system I am working on to replace all of this mess is
>called OS/8 Version 5.  It will be compatible with existing PDP-8
>programs, but only if they are run on PDP-8 hardware.  CUSP's will have to
>be rewritten to work with new conventions that are acceptable to all
>hardware, but older versions will continue to work where possible, i.e.,
>on pre-DECmate machines.  The new CUSP's will retain all of the
>functionality of OS/8 regardless of hardware they are running on, etc. 
>All of the personal-preference-induced changes of OS/278 will be
>eliminated in favor of the original OS/8 settings.  In some cases, it may
>be possible to support the OS/278 variants as user-settable options
>subject to restrictions.  For example, OS/278 changes the prompt character
>from "." to "}".  While this seems to be merely a cosmetic change, it also
>affects the exact nature of BATCH operations.  Regardless of choice, BATCH
>files from one era of OS/8 family existence are incompatible, etc.  Some
>"latitude" may be necessary to correct this, etc.

Well, when V5 comes out, I'd be interested in looking at it,
and maybe use it, unless something gets broken. ;-)

>>>>(If you set bit 11, and the device is a DECtape, it will run in
>>>>reverse... :-)
>>
>>>Partially.  What you refer to is the "search forward first" bit for
>>>DECtape and LINCtape.
>>
>>Ummm, maybe, and maybe not.
>>To quote the manual:
>>"Bits 9 to 11	Device dependent bits, can be left zero.
>>		Currently only bit 11 is used;  on DECtape
>>		bit 11 determines the direction in which the
>>		tape is started.  If bit 11 is 0, the tape
>>		starts in reverse.  If bit 11 is 1, the tape
>>		starts forward.  All other handlers ignore
>>		these bits at present (except TM8E and TA8E)."
>>

>For starters:

>The TM8E and the TA8E don't count!  These are *not* disk device handlers;
>they are strictly non-file-structured device handlers ala paper-tape.  The
>use of a non-file structured handler causes a totally different action to
>be taken since the entire device is a single file.  (For example, only a
>non-file structured device can take a "soft" error return meaning
>returning to the error return from a handler call with the AC *not* set to
>a negative value.  This means the device is at End-Of-File, a concept
>alien to a disk handler, etc.)

Ummm, Charles. I think most people know this already.
The reason I mentioned TM8E and TA8E is because I was quoting the manual,
and it said so. If I had skipped that, the quote would have been
incomplete.
So I don't think there was any cause for a discussion about this.
(I just think you are stating the obvious, and are overdoing it.
 And also have a tendency to spin off into sidetracks on subjects
 that really isn't part of what's being discussed.
 But I'll admit you know more of the stuff than anyone else
 I've ever heard of.)

>Regardless of the setting of the bit, the ultimate data transfer is always
>forwards, and only the overhead of search timing can be affected in any
>way whatsoever, etc.

Okay, in that case I agree that the bit could just as well be removed.
Coding this into a device driver hardly takes more than about
5 words.

>Moreover, I want to incorporate the use of bit[11] as part of the "^C
>abort" feature of OS/8 Version 5 to forever eliminate hardware dependancy
>of the DECmates, etc.  The system call in 07600 would allow the low-order
>bit(s) of 07601 to be set when a program aborts.  Thus, even if the
>console hardware is incompatible, a program can still indicate it was
>aborting due to ^C being hit.  (Note: on DECmates, KSF doesn't skip more
>than once!  This is the key reason why traditional OS/8 console handling
>can't work on a DECmate.  A program detecting the user's ^C keystroke
>cannot convey that information to the keyboard monitor because KRS cannot
>be used to pre-read the character without disturbing the flag, and KSF
>clears the flag, thus it's no longer set!  By the time the keyboard
>monitor could notice KSF skipping again, it's for an additional typed
>character, not the ^C that caused the abort, etc.  By allocating bit[11]
>to this purpose, an aborting program can signal the abort to the keyboard
>monitor by executing ISZ I (7601).  By allocation of bits[9-11], there is
>an additional safeguard against accidental multiple executions, since the
>code could only be destroyed if executed more than seven times.)

Sounds like a sensible idea.
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From billh@comtch.iea.com Fri Jan  7 01:05:37 EST 1994
Article: 592 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!news.intercon.com!udel!news.sprintlink.net!connected.com!krel.iea.com!comtch.iea.com!billh
From: billh@comtch.iea.com (Bill Haygood)
Newsgroups: alt.sys.pdp8
Subject: Bill H's pdp8 emulator OS/8 date
Date: 5 Jan 1994 02:12:36 GMT
Organization: CompuTech
Lines: 39
Message-ID: <2gd7mk$2cs@krel.iea.com>
NNTP-Posting-Host: comtch.iea.com
Summary: 1994 OS/8 date
Keywords: pdp8, emulator
X-Newsreader: TIN [version 1.2 PL1]

With the arrival of 1994, the famous OS/8 date problem again raises its
ugly head.  I submit the following short program for use on my pdp8
emulator to set the OS/8 date high order bits for the period 1994-1999
(Jim Van Zee informs me that most OS/8 date algoritms will only work
through 1999):
-------------------------------------------------------------------------
/	SET94.PA: SET 1994 HIGH ORDER DATE BITS
/
/	Author: Bill Haygood, billh@comtch.iea.com
/
	*200
/
	JMS I [7607		/ CALL SYS HANDLER
	0200			/ READ 2 PAGES
	0400			/ INTO ADDR 0400
	0			/ FROM BLOCK 0
	HLT			/ ERROR RETURN
	TAD [600		/ GET H O YEAR BITS
	DCA I [777		/ PLUG THEM INTO SYS BOOT BLOCK
	JMS I [7607		/ CALL SYS HANDLER
	4200			/ WRITE 2 PAGES
	0400			/ FROM ADDR 0400
	0			/ INTO BLOCK 0
	HLT			/ ERROR RETURN
	JMP I [7600		/ RETURN TO OS/8
/
	$
--------------------------------------------------------------------------

After the emulator comes up and OS/8 boots, type:

.COPY SET94.PA<PT:
.EX SET94

This sequence should copy the file into which you have put the above short
program and the .EX command should assemble and execute it.

--
Bill Haygood


From lasner@sunSITE.unc.edu Fri Jan  7 01:09:28 EST 1994
Article: 593 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 7 Jan 1994 05:52:12 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 181
Message-ID: <2gitac$fiq@bigblue.oit.unc.edu>
References: <CIvI64.366@world.std.com> <2gfuiq$fso@corax.udac.uu.se> <2ggt9b$aq1@bigblue.oit.unc.edu> <2gh727$i9q@corax.udac.uu.se>
NNTP-Posting-Host: sunsite.unc.edu

In article <2gh727$i9q@corax.udac.uu.se>,
Johnny Billquist <bqt@Update.UU.SE> wrote:
>lasner@sunSITE.unc.edu (Charles Lasner) writes:
>
>Associated linker is not the same as a linker.
>Even though only one program generate code for each linker,
>the linkers are general programs, which very well could be
>fed with output from other programs, just that none have been
>written.

Nor are likely to ever get written!  The linking loader (aka linker aka
linkage editor depending on your background) has to be rewritten for each
family of utilities because each had different requirements at the time. 
In any case, I am not trying to be as pedantic on this point as you are! :-)

>
>>>LINK and LOAD (and maybe ABSLDR) is linkers.
>
>>LINK is the MACREL family linker apparently.  I think LOAD is the FORT
>>family linker (aka linking loader), and LOADER is the one for F4.  (Those
>>last two backwards?  Also, doesn't one of them have a library maintainer
>>called LIBRA?  Perhaps there is also a parallel program called LIBR for
>>the FORT family?  What is the equivalent for the MACREL family?)
>
>You are right on all accounts.
>There is no library maintainer for the "MACREL family".
>You create libraries just by using PIP.
>The format of the object file is such that you can have them
>concatenated.

That makes sense to me.  I always wondered why a specific utility would be
needed, since the binaries are created individually, etc.  Other than
concatenating them together, what's ever required of a library?

>
>>ABSLDR is not a linker; it merely loads absolute binary paper-tape files
>>and does nothing that a linker ever does.
>
>That's why I put it inside parenthesis. It does a very meager subset
>of what linkers do.

Yes, namely program loading.  But historically, loaders predate linkage
editor-type loaders, so ABSLDR is only a loader not deserving to even be
grouped with linkers!

>I know you dislike macro assemblers. :-)

Yes, because I don't see enough "reward" to overcome the overhead they add
in terms of time-to-compile, etc.  Even global symbol handling can be done
in PAL8 using a TECO macro such as the one I use for Kermit-12
maintenance, etc.

>>Anyway, I'm not really here to start a "religious" war against MACREL,
>>just to point out that sometimes TAASTAAFL.  The translation to MACREL was
>>promoted on a false premise, namely that unrestricted swapping was
>>available to these CUSP's, and that *nothing* else would change.
>
>TANSTAAFL is always true.
>Another golden rule is, if it ain't broke, don't fix it.
>Seems to me that DEC broke that rule...

Absolutely.  Also note here that I am *defending* MACREL in this case; it
was a management blunder for misusing it!  However, it is true that there
is no general method for OS/8 program swapping on a non-SYS: device.  But
had they instead used the method of CHAIN, then it would gracefully
complain instead of potentially crashing quite badly (as did occur!).

In this way, P?S/8 is somewhat superior to OS/8: any system program can be
on any logical unit that the system handler can address (generally 0-7)
with no restrictions regarding residence on the booted-to unit (which in
turn need not be 0).  Overlays are allowed since the system program can
determine its own loading block and logical unit and just has to calculate
offsets to create absolute block arguments, etc.

Incidentally, years before there ever was a MACREL, there was a version of
a BASIC for OS/8 that worked ala the P?S/8 method.  It depended on the
specified order of saving images of pieces of the program.  Then you
deleted all of the directory entries for the (secondary) pieces.  Instead
of the overhead of a CHAIN, it just calculated block offsets, etc. 
(Unfortunately, all of this is also restricted to SYS:!)

>Well, it seems to me that OS/78 definitely are different from OS/8.
>Your accounting just give me more reason to believe so.
>Why you started by saying it wasn't so I don't understand.

Because OS/78 V1 *is* OS/8 V3D!  And the later versions are merely a
demented manager's preference for a system rename.

>Hmmm, interesting. The only thing I've ever seen with ";" on OS/8 was
>the original version of CCL that I was using, which had the ";" to
>separate commands, like in UNIX. The was removed in CCLX, which I now
>use.
>To actually separate the commands, CCL created a file with the commands,
>and called BATCH to execute them one after another.

Exactly.  This was dropped in later versions.
>
>Well, by this time then, you cannot claim that OS/8 and OS/78 are the same.
>OS/8 stayed by V3D (or 3Q internally, which actually is what my OS/8
>says it is...)

The name distinction is superfluous.  And up to OS/78 V4, you could still
make it call itself OS/8 with SET SYS OS/8.  BTW, other than the
development of BASIC into CBASIC (later renamed BASIC), a few handlers,
there really isn't much to OS/78 V3 other than dropping support for all of
the older stuff and not guaranteeing that the code won't contain
8/e-specific instructions (well, at least that some non-LINC-8, -8
instructions could "contaminate" the code).

BTW, OS/278 V2 does bring OS/8 users a benefit: the PAL8 Version B0 and
companion CREF Version B0 are superior to all prior versions.  A lot of
bugs were fixed, and there is only one minor "behavioral" anomaly
associated with interaction with the TTY: handler regarding type-ahead of
^Z.  I have checked the code and find no occurences of instructions that
would prevent operation on any model; this is why I distribute an ENCODEd
copy of them with the Kermit-12 package.
>
>Well, when V5 comes out, I'd be interested in looking at it,
>and maybe use it, unless something gets broken. ;-)

I hope so!  We need user feedback in case anything gets broken, so we can
fix it!  The primary aim is to make one system work everywhere.  The code
of V3D is the closest to that goal; only the changes absolutely necessary
will be made; any DECmate-specific stuff will be added in ways that don't
"hurt" the -8 versions, other than the console-mandated changes, etc.

>Ummm, Charles. I think most people know this already.
>The reason I mentioned TM8E and TA8E is because I was quoting the manual,
>and it said so. If I had skipped that, the quote would have been
>incomplete.

I imagine some people aren't aware of the TM8E/TA8E-specific extensions. 
In any case, it's harmless to mention them :-).  Over the years, some
people who *should* have known this stuff none-the-less wrote defective
code!  (Such as disk device handlers that returned soft error returns, etc.)
>
>>Regardless of the setting of the bit, the ultimate data transfer is always
>>forwards, and only the overhead of search timing can be affected in any
>>way whatsoever, etc.
>
>Okay, in that case I agree that the bit could just as well be removed.
>Coding this into a device driver hardly takes more than about
>5 words.

Coding the bit-related code takes about 5 words, but doing the
dead-reckoning from within the handler takes more!  Especially on the
TD8E.  Some of the hardware changes we made on the LINC-8 were designed to
allow the self-reckoning; the OS/8 bit was always ignored!

>
>>Moreover, I want to incorporate the use of bit[11] as part of the "^C
>>abort" feature of OS/8 Version 5 to forever eliminate hardware dependancy
>>of the DECmates, etc.  The system call in 07600 would allow the low-order
>>bit(s) of 07601 to be set when a program aborts.  Thus, even if the
>>console hardware is incompatible, a program can still indicate it was
>>aborting due to ^C being hit.  (Note: on DECmates, KSF doesn't skip more
>>than once!  This is the key reason why traditional OS/8 console handling
>>can't work on a DECmate.  A program detecting the user's ^C keystroke
>>cannot convey that information to the keyboard monitor because KRS cannot
>>be used to pre-read the character without disturbing the flag, and KSF
>>clears the flag, thus it's no longer set!  By the time the keyboard
>>monitor could notice KSF skipping again, it's for an additional typed
>>character, not the ^C that caused the abort, etc.  By allocating bit[11]
>>to this purpose, an aborting program can signal the abort to the keyboard
>>monitor by executing ISZ I (7601).  By allocation of bits[9-11], there is
>>an additional safeguard against accidental multiple executions, since the
>>code could only be destroyed if executed more than seven times.)
>
>Sounds like a sensible idea.

Actually, it could be ISZ'ed up to 63 times, but after 7 times it makes
the wrong field get saved!  After that, the page count is increased which
will partially corrupt the system!  Of course the reloaded keyboard
monitor will clear the bits out each time, etc.!

So far, no other word in field 0 has been shown to have any equivalent
potential for ^C abort marking.  I am also seeking other bits to enhance
the system date word!

cjl



From lasner@sunSITE.unc.edu Fri Jan  7 01:10:04 EST 1994
Article: 594 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Bill H's pdp8 emulator OS/8 date
Date: 7 Jan 1994 06:05:34 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 30
Message-ID: <2giu3e$hgo@bigblue.oit.unc.edu>
References: <2gd7mk$2cs@krel.iea.com>
NNTP-Posting-Host: sunsite.unc.edu
Keywords: pdp8, emulator

In article <2gd7mk$2cs@krel.iea.com>,
Bill Haygood <billh@comtch.iea.com> wrote:
>With the arrival of 1994, the famous OS/8 date problem again raises its
>ugly head.  I submit the following short program for use on my pdp8
>emulator to set the OS/8 date high order bits for the period 1994-1999
>(Jim Van Zee informs me that most OS/8 date algoritms will only work
>through 1999):

Yes, I am working on that problem, and there are several tentative
solutions (to be discussed at another time).

However, there is no need to run the supplied (and correct!) program to set
the word, since FUTIL can do it for you:

.R FUTIL
0.377/ xxxx 0600 [hit <LF> here]
0.400/ EXIT

However, there is another problem: it is actually device-dependent as to
whether the last word of logical record 0000 actually loads into 07777,
although this is certainly correct for an RK8E (or emulator thereof).  For
versions that run on TC01/08, and various RX, it may not be true at all!

The date word format currently is good for 8 years, but many programs are
incapable of handling 2000-2001 for algorithmic purposes in input and
output routines.  Thus, we are on notice that we have at most 6 years to
fix it for 2 more years, and then no additional time to fix it at all!  I
recommend we resolve this quickly for the benefit of OS/8 V5.

cjl


From zrepachol@cc.curtin.edu.au Sun Jan  9 04:49:20 EST 1994
Article: 595 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab!munnari.oz.au!uniwa!info.curtin.edu.au!cc.curtin.edu.au!zrepachol
From: zrepachol@cc.curtin.edu.au (Paul Repacholi)
Newsgroups: alt.sys.pdp8
Subject: Re: PDP-8A and Dual floppies
Date: 8 Jan 94 04:12:53 +0900
Organization: Curtin University of Technology
Lines: 15
Message-ID: <1994Jan8.041253.1@cc.curtin.edu.au>
References: <1994Jan5.083414.15937@lugb.latrobe.edu.au> <2gf1ii$min@math.mps.ohio-state.edu> <1994Jan6.101226.29319@lugb.latrobe.edu.au>
NNTP-Posting-Host: cc.curtin.edu.au

In article <1994Jan6.101226.29319@lugb.latrobe.edu.au>, cchd@lucifer.latrobe.edu.au (Huw Davies) writes:
> On a related issue, where can I get a copy of FOCAL for the -8 and how
> do I get it onto the machine?
> 
> There is a possibility that later this month that the -8A and an 11/44
> that I'm setting up will appear on the net. Stay tuned for details...


I think I've got a copy of Focal-8 on... paper tape. I'll have a look tomorrow,
( Sat, when I wake up. ) I think this is when I get to fix my paper
tape reader. We could also check UWA education, they had an 8 they did
data loging with.

~Paul



From rla@rahul.net Sun Jan  9 05:56:29 EST 1994
Article: 596 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab!a2i!rla
From: rla@rahul.net (Bob Armstrong)
Subject: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <CJAEDC.79A@rahul.net>
Sender: news@rahul.net (Usenet News)
Nntp-Posting-Host: bolero
Organization: a2i network
Date: Sat, 8 Jan 1994 01:20:00 GMT
Lines: 51

  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 <rla@rahul.net>


From bqt@Update.UU.SE Sun Jan  9 07:52:49 EST 1994
Article: 597 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!bqt
From: bqt@Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 9 Jan 1994 03:22:59 GMT
Organization: Uppsala University
Lines: 112
Message-ID: <2gntaj$plu@corax.udac.uu.se>
References: <CIvI64.366@world.std.com> <2gfuiq$fso@corax.udac.uu.se> <2ggt9b$aq1@bigblue.oit.unc.edu> <2gh727$i9q@corax.udac.uu.se> <2gitac$fiq@bigblue.oit.unc.edu>
NNTP-Posting-Host: krille.update.uu.se

lasner@sunSITE.unc.edu (Charles Lasner) writes:

>In article <2gh727$i9q@corax.udac.uu.se>,
>Johnny Billquist <bqt@Update.UU.SE> wrote:
>>lasner@sunSITE.unc.edu (Charles Lasner) writes:
>>
>>Associated linker is not the same as a linker.
>>Even though only one program generate code for each linker,
>>the linkers are general programs, which very well could be
>>fed with output from other programs, just that none have been
>>written.

>Nor are likely to ever get written!  The linking loader (aka linker aka
>linkage editor depending on your background) has to be rewritten for each
>family of utilities because each had different requirements at the time. 

Well, I have, from time to time, considered writing a compiler which
would produce .RB-files...
Why waste a good linker? :-)

>In any case, I am not trying to be as pedantic on this point as you are! :-)

Nope. Sorry if I'm getting on your nerves... ;-)

>>>>LINK and LOAD (and maybe ABSLDR) is linkers.
>>
>>>LINK is the MACREL family linker apparently.  I think LOAD is the FORT
>>>family linker (aka linking loader), and LOADER is the one for F4.  (Those
>>>last two backwards?  Also, doesn't one of them have a library maintainer
>>>called LIBRA?  Perhaps there is also a parallel program called LIBR for
>>>the FORT family?  What is the equivalent for the MACREL family?)
>>
>>You are right on all accounts.
>>There is no library maintainer for the "MACREL family".
>>You create libraries just by using PIP.
>>The format of the object file is such that you can have them
>>concatenated.

>That makes sense to me.  I always wondered why a specific utility would be
>needed, since the binaries are created individually, etc.  Other than
>concatenating them together, what's ever required of a library?

Well, I like to be able to replace modules in the library, be able
to check which modules that are in the library, and what versions
they are. Also, specific dates when different modules were added
to the library can be handy.
All but the dates can be solved within the format today. Maybe
I'll write a program for this. when I have time (which probably
isn't any time soon... :-( )
I can see some uses of a library program, but I can live without
it as it stands today.

>>I know you dislike macro assemblers. :-)

>Yes, because I don't see enough "reward" to overcome the overhead they add
>in terms of time-to-compile, etc.  Even global symbol handling can be done
>in PAL8 using a TECO macro such as the one I use for Kermit-12
>maintenance, etc.

Guess I'm lazy, and spoilt by MACRO-11... :-)

>>Well, it seems to me that OS/78 definitely are different from OS/8.
>>Your accounting just give me more reason to believe so.
>>Why you started by saying it wasn't so I don't understand.

>Because OS/78 V1 *is* OS/8 V3D!  And the later versions are merely a
>demented manager's preference for a system rename.

Well, OS/78 V1 isn't the definition of OS/78 as a whole, is it?

>>Hmmm, interesting. The only thing I've ever seen with ";" on OS/8 was
>>the original version of CCL that I was using, which had the ";" to
>>separate commands, like in UNIX. The was removed in CCLX, which I now
>>use.
>>To actually separate the commands, CCL created a file with the commands,
>>and called BATCH to execute them one after another.

>Exactly.  This was dropped in later versions.

A little sad, I agree, but I can live without that one.

>>Well, when V5 comes out, I'd be interested in looking at it,
>>and maybe use it, unless something gets broken. ;-)

>I hope so!  We need user feedback in case anything gets broken, so we can
>fix it!  The primary aim is to make one system work everywhere.  The code
>of V3D is the closest to that goal; only the changes absolutely necessary
>will be made; any DECmate-specific stuff will be added in ways that don't
>"hurt" the -8 versions, other than the console-mandated changes, etc.

Sounds like the correct approach. Next question is; can it be done?

>Actually, it could be ISZ'ed up to 63 times, but after 7 times it makes
>the wrong field get saved!  After that, the page count is increased which
>will partially corrupt the system!  Of course the reloaded keyboard
>monitor will clear the bits out each time, etc.!

>So far, no other word in field 0 has been shown to have any equivalent
>potential for ^C abort marking.  I am also seeking other bits to enhance
>the system date word!

Hmmm, aren't there any free bits left in 07777?
Also, what is address 17777 used for? (I can't remember it being used
for anything, and the OS/8 Software Support Manual claims it
is reserved for future use...)

	Johnny
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From lasner@sunSITE.unc.edu Sun Jan  9 07:53:50 EST 1994
Article: 598 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Date: 9 Jan 1994 10:55:46 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 188
Message-ID: <2gonri$fi1@bigblue.oit.unc.edu>
References: <CJAEDC.79A@rahul.net>
NNTP-Posting-Host: sunsite.unc.edu

In article <CJAEDC.79A@rahul.net>, Bob Armstrong <rla@rahul.net> wrote:
>  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.

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.)

>
>  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.

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.

>
>  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 ?

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 :-(.).

>
>  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!

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!)

>
>  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!

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!)

>
>  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...

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
>
>-- 
>Bob Armstrong <rla@rahul.net>

cjl



From lasner@sunSITE.unc.edu Sun Jan  9 07:54:09 EST 1994
Article: 599 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Format of .SV files?
Date: 9 Jan 1994 12:52:44 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 301
Message-ID: <2goums$8lr@bigblue.oit.unc.edu>
References: <CIvI64.366@world.std.com> <2gh727$i9q@corax.udac.uu.se> <2gitac$fiq@bigblue.oit.unc.edu> <2gntaj$plu@corax.udac.uu.se>
NNTP-Posting-Host: sunsite.unc.edu

In article <2gntaj$plu@corax.udac.uu.se>,
Johnny Billquist <bqt@Update.UU.SE> wrote:
>lasner@sunSITE.unc.edu (Charles Lasner) writes:
>
>>Nor are likely to ever get written!  The linking loader (aka linker aka
>>linkage editor depending on your background) has to be rewritten for each
>>family of utilities because each had different requirements at the time. 
>
>Well, I have, from time to time, considered writing a compiler which
>would produce .RB-files...
>Why waste a good linker? :-)

The original intent was to write a high-performance FORTRAN that replaced
FORT/SABR.  The compiler was canned, but Stan had written enough of MACREL
that they let him finish the initial offering and even get a manual
written for it.  I have his followup work on a next-generation MACREL
which was never completed (but might fix some limitations/bugs of the
released MACREL) he did as a hobby for awhile, etc.  The compiler was
never started, other than some circumspect overall specifications, etc. to
convince the suits that the product was even needed!

>Well, I like to be able to replace modules in the library, be able
>to check which modules that are in the library, and what versions
>they are. Also, specific dates when different modules were added
>to the library can be handy.
>All but the dates can be solved within the format today. Maybe
>I'll write a program for this. when I have time (which probably
>isn't any time soon... :-( )
>I can see some uses of a library program, but I can live without
>it as it stands today.

As I understand it, some of this is also lacking in the F4 family.  Some
of the utilities to implement some of what you seek were user-written
though.  (And in a most unlikely language - PASCAL!)  Perhaps you could
more readily modify the PASCAL programs to accomplish the requirement!

>
>>>I know you dislike macro assemblers. :-)
>
>>Yes, because I don't see enough "reward" to overcome the overhead they add
>>in terms of time-to-compile, etc.  Even global symbol handling can be done
>>in PAL8 using a TECO macro such as the one I use for Kermit-12
>>maintenance, etc.
>
>Guess I'm lazy, and spoilt by MACRO-11... :-)

Just put it this way:

You have written -8 code the way -11 code is often written.  Sometimes
expediency is a goal in and of itself.  (And also a lot of other
trade-offs you could add, etc.)

But the simple fact is that P?S/8 and OS/8 "proper" couldn't be developed
in MACREL assuming it pre-existed compatibly on another "convenient"
machine.  That kind of environment doesn't lend itself to the tricks that
make the existent code possible.  Much of the code is difficult to
"maintain" (by the conventional definition of maintainence - meaning that
a mediocre individual can quickly step into the shoes of the original
author and fully understand the nature of what can/cannot be done to the
code as it stands; for proof of this, just look at all of the introduced
bugs in OS/278 that have no particular hardware dependency as the "excuse"
for them, etc.!) and MACREL would only make such a task more difficult, etc.

>
>>>Well, it seems to me that OS/78 definitely are different from OS/8.
>>>Your accounting just give me more reason to believe so.
>>>Why you started by saying it wasn't so I don't understand.
>
>>Because OS/78 V1 *is* OS/8 V3D!  And the later versions are merely a
>>demented manager's preference for a system rename.
>
>Well, OS/78 V1 isn't the definition of OS/78 as a whole, is it?

It appears that strictly speaking, "OS/78" means *only* all of the following:

1)	You can execute the command SET SYS OS/78 to enable it.

2)	You can execute the command SET SYS OS/8 to cancel it.

3)	During it, the VERSION command indicates it's present.

4)	During it, all programs with bit[5] of the JSW set are subject to
the restriction that the R, RUN, and GET commands will not function.

5)	In memory, the only indication of the various modes is whether the
HLT at 07604 is a HLT, CLA HLT, OSR HLT, or LAS HLT.  OS/8 is HLT, and
OS/78 is CLA HLT.  The other two cases are attempts at being known as
VT278 and OS/278 mode respectively.  It's not clear (nor consistently
implemented!) just what these actually are, but my best guess is that they
mean that the terminal can be expected to be a VT-52 or a VT-100.  I would
recommend that they be re-implemented as the object of SET TERMINAL
commands that actually do that!  Clearly, some OS/278 programs are
attempting to check these bits to gain "permission" to be outputting VT-52
and VT-100 escape sequences, but in inconsistent ways, etc.

However, there is no clear way to implement properly what's implied
anyway!  There is no purpose served in tieing together the notion of the
command restriction and also the terminal type.  This leads to the
limitation that OS/8 can never have a designated terminal type, or
alternatively that OS/78 restriction is a subset of designating that you
have a VT-52 or VT-100 present.  (Perhaps someone else can suggest what
they were attempting to designate here!  I would suggest an alternative:
the other bit means that there is a VT-52 or a VT-100 present.  All of the
programs are attempting to do tricks such as clear-screen.  You can write
code that will work on all VT-52 and VT-100 to do that without caring
about the difference; merely add code to enter VT-52 mode first; it's
ignored on an actual VT-52 mode terminal or emulator.  Then the bit
controls whether you can presume the VT-52 screen enhancements at all, etc.)

>
>>>Hmmm, interesting. The only thing I've ever seen with ";" on OS/8 was
>>>the original version of CCL that I was using, which had the ";" to
>>>separate commands, like in UNIX. The was removed in CCLX, which I now
>>>use.
>>>To actually separate the commands, CCL created a file with the commands,
>>>and called BATCH to execute them one after another.
>
>>Exactly.  This was dropped in later versions.
>
>A little sad, I agree, but I can live without that one.

It complicated the keyboard monitor, and was flakily implemented.  And it
still depended on the ability to chain to BATCH after the fact, which on
8K systems isn't allowed!  Moreover, there are *fatal* commands to BATCH
such as SQU SYS: /O.  It's better to restrict the usage of "safe" commands
to formal BATCH input (*.BI files) than to also allow impromptu files
created by (perhaps accidently!) typing a ";". 

>
>>>Well, when V5 comes out, I'd be interested in looking at it,
>>>and maybe use it, unless something gets broken. ;-)
>
>>I hope so!  We need user feedback in case anything gets broken, so we can
>>fix it!  The primary aim is to make one system work everywhere.  The code
>>of V3D is the closest to that goal; only the changes absolutely necessary
>>will be made; any DECmate-specific stuff will be added in ways that don't
>>"hurt" the -8 versions, other than the console-mandated changes, etc.
>
>Sounds like the correct approach. Next question is; can it be done?

To implement what I want to do, all that needs to be done is the following:

1)	Plan for all DECtape/LINCtape handlers to be upgraded to obsolete
the use of bit[11] of the function word.  However, the worst case
consequence is that ^C abort causes the core-save function call to search
initially in the wrong direction and then turns around and proceeds as
before, etc.

2)	Rewrite all portions of OS/8 and its handlers that are generic to
DECmates.  Things like RK8E handlers need not be changed.  Only the
console-related code needs to be changed.  However, some of the programs
have already been otherwise modified as versions migrated to be able to be
run on DECmates such as the F4 run-time system, etc.  Some of the changes
introduced in the newer versions need to be retrofitted back into the
older code or vice-versa.  Note that the rewrite also includes
user-written programs and handlers.  Also, some things such as
user-written RX handlers may not be able to be run from the DECmate II or
DECmate I or VT-78 due to space or speed limitations.

3)	Some of the DECmate-specific changes depend on work in progress
that stems from disassembly of code with no source available.  Much of the
work is already done however.  There will come a point where the OS/8 V5
code will be stable per se, but still won't completely function correctly
until "slushware" changes are made as well, etc.

Due to the large amount of work that needs to be done, it's likely that
this will happen gradually.  Along the way, various "experimental"
releases will tend to happen where it's known what can't possibly work
yet, etc.

Note: I have already completed the P?S/8 equivalent of this about 95%. 
Some of the remaining few percent isn't done because the DECmate
environment has suggested alternative ways to implement certain things
already implemented in a way that is either inefficient or slightly
incompatible on a DECmate, but works fine on the -8's.  Other than
handlers, this only involves the extended software interrupt environment
of the P?S/8 console overlay, especially as it relates to providing
services to programs such as FOCAL.)

(Note:  P?S/8 supports a concept totally lacking in OS/8 - an alternate
console "overlay".  There is an orderly mechanism in P?S/8 that allows any
and all cogniscent programs to stop using "raw" device 03/04 code for the
console (and raw device 66 code for the LPT the way some OS/8 code also
does!) and instead call defined software routines in the overlay to
accomplish the equivalent to a configurable console device.

Existent console devices already implemented include using a VT8E and also
alternate KL-type interfaces to other external terminals and printers
w/keyboards, etc.  All of the P?S/8 system programs have already been
upgraded to support ^S/^Q whether on the device 03/04 interface of either
an -8 or a DECmate or to the logical console device.  However, all of
these programs (except P?S/8 FOCAL) are non-interrupt-driven.  The logical
LPT support even includes some print buffering that noticeably speeds up
printing on parallel printers, etc.  However, for maximum efficiency in an
interrupt-driven environment, the mechanism for interrupt handling has to
be redefined.

The basic problem is that a typical program already knows what devices it
handles interrupts for, and just has an interrupt routine for it, etc. 
But when the console and LPT routines are generic, they have to be hooked
into the interrupt handler at the correct point so that the former
hardware-oriented interrupt handlers can be replaced by software calls to
the generic routines.  Not all of the details are worked out
satisfactorily, but a rudimentary version already exists.  Currently, you
are obliged to inspect a table of overlay-supported devices, and delete
any devices you may be redundantly be handling, such as device 03/04. 
Various event flags are set after you call the overlay's interrupt scan
routines that you can inspect, and then make calls to deal with the
associated data, etc.  But at present, there can be some confusion about
exactly which device is which in the most general implementation of the
routines. 

Consider the following example:  The console could be defined as a
replacement for 03/04 and actually goes to 03/04 or alternatively to
another KL-type device such as 40/41.  (Which doesn't matter to the
example.) Alternatively, the console may be defined as the VT8E which
generates keyboard input and keyboard input interrupts, but outputs
without an interrupt structure.  (You merely output by poking at memory,
possibly reformatting memory, but the call to the console routines
finishes the job without subsequent interrupt, etc.)

Beyond this, FOCAL may itself be running with a patch file that creates
FOCAL-12-like features where display graphics functions may be active,
and, *if* the console device is the VT8E, it wants to additionally
"time-share" the hardware between text mode and graphics mode switching
context at the video clock rate, and additionally enable various commands
that determine which of either of these modes (or both!) are being
enabled.  Additionally, if FOCAL determines that the console isn't the
VT8E, it wants to output to the VT8E itself using its own built-in
routines as part of the VT8E patch package, etc.  Thus, there needs to be
a more orderly (and less confusing!) mechanism that determines whether
FOCAL, as an application program has total, partial, or no control as to
whether to context switch the VT8E hardware as determined by whether the
console device coming in is either none, partial, or completely using the
VT8E hardware.  This is also complicated by the fact that the VT8E also
could be the parallel LPT interface, with a slight incompatibility: the
interrupt enable for the LPT isn't in device 66, but rather is shared
KL-style with the keyboard of the VT8E.  (DEC envisioned the VT8E as a
hardcopy terminal with a DMA screen, keyboard and printer.  The standard
VT8E is delivered complete with a diagnostic report that it passed the
DECwriter I (parallel) tests!)

(Since experiencing the needs of making the DECmate work in this kind of
interrupt environmment handled by generic software at times, I have begun
to rethink some of the intended mechanisms of the console overlay to best
serve all requirement in a "cleaner" way.  All of the non-interrupt
implementations are actually fairly elegant however, etc.  And were there
not the complications of the console overlay, all of the console-relevant
DECmate hardware differences are currently solved; the current version of
P?S/8 FOCAL *does* totally run on the DECmates.  When the code is
redesigned, it will additionally run under all of the VT8E variants
possible on an -8/e as well; currently it does run under most of the
"useful" configurations (but not all of the possible cases!).)

In any case, the non-interrupt aspects of upgrading P?S/8 wasn't that much
work; I think it gives a yardstick for doing the equivalent in OS/8, etc.

>>So far, no other word in field 0 has been shown to have any equivalent
>>potential for ^C abort marking.  I am also seeking other bits to enhance
>>the system date word!
>
>Hmmm, aren't there any free bits left in 07777?
>Also, what is address 17777 used for? (I can't remember it being used
>for anything, and the OS/8 Software Support Manual claims it
>is reserved for future use...)

I believe all of 07777 is used up currently;  I would be open to a
redesign of BATCH to possibly free up some of it, etc.  Note that there
was a user-written batch processor that can run in 8K!  By better
integrating it into the OS/8 environment, perhaps some of the overhead of
BATCH could be eliminated.  (Certainly the 12K requirement!  Note that
P?S/8 runs in 4K, BATCH or no BATCH!)

I think 17777 is basically reserved for BATCH, along with a few words in
27777 and nearby.  It would be nice to free it up as the date extension word.

Note that even when the date extension gets defined (and only a few bits
are needed!  I could even live with using 07601 bits[9-10] for the date
extension and [11] for the ^C abort with no margin for the error of
multiple ISZ I (7601) mistakes.  This would make the date last four times
as long as the 32 years of 1970-2001!), you still need to have two extra
information words in the directory to implement it better than the current
imprecise to 8 years kludge.  But many people complain that even one extra
word is too many, and have a whole bunch of little files with no dates and
still have wasted disk space on the end of the device!

Of course if you have only a few files, as most of us do, the disk runs
out before the directory space.  And further, there are user-written
"partition" utilities to encapsulate files within their own directory
space, and only take up one OS/8 directory entry.  If they are upgraded,
this allows a means for everyone to at least have some viable way of
maintaining file dates at some level, etc.  Note that Kermit-12's ENCODE
utility warns the user that the date in the file is imprecise, and asks
the user to set the proper 8-year group at the other end of the decoding,
etc.  If we had this upgraded mechanism, ENCODE could be upgraded to
provide precise information if available, etc.  In any case, complete date
information I would want bundled into any scheme to extend the viability
of the date mechanism itself! 

cjl



From bob@sed.csc.com Mon Jan 10 21:00:28 EST 1994
Article: 600 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!netsys!news.echonyc.com!news.kei.com!eff!cs.umd.edu!anagld!bob
From: bob@sed.csc.com (Bob Smith)
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <CJF6n2.Gvu@sed.csc.com>
Organization: Computer Sciences Corporation
References: <CJAEDC.79A@rahul.net>
Date: Mon, 10 Jan 1994 15:21:02 GMT
Lines: 28

rla@rahul.net (Bob Armstrong) writes:

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


>  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,
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
>Bob Armstrong <rla@rahul.net>


From ivie@cc.usu.edu Mon Jan 10 21:04:47 EST 1994
Article: 601 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!udel!news.intercon.com!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <1994Jan10.103159.7402@cc.usu.edu>
Date: 10 Jan 94 10:31:59 MDT
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu>
Organization: Utah State University
Lines: 21

In article <2gonri$fi1@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes:
> 
> 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!  

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
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Mon Jan 10 21:14:49 EST 1994
Article: 602 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Date: 11 Jan 1994 02:10:17 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 23
Message-ID: <2gt1q9$clm@bigblue.oit.unc.edu>
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu> <1994Jan10.103159.7402@cc.usu.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <1994Jan10.103159.7402@cc.usu.edu>,  <ivie@cc.usu.edu> wrote:
>
>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.

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 cchd@lucifer.latrobe.edu.au Thu Jan 13 20:36:16 EST 1994
Article: 603 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!uwm.edu!msuinfo!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!lucifer!cchd
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <1994Jan11.103957.10934@lugb.latrobe.edu.au>
From: cchd@lucifer.latrobe.edu.au (Huw Davies)
Date: Tue, 11 Jan 1994 10:39:57 GMT
Sender: news@lugb.latrobe.edu.au (USENET News System)
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu>
Organization: La Trobe University
Lines: 34

In article <2gonri$fi1@bigblue.oit.unc.edu> lasner@sunSITE.unc.edu (Charles Lasner) writes:
>In article <CJAEDC.79A@rahul.net>, Bob Armstrong <rla@rahul.net> wrote:
>>  Some miscellanous ramblings on 6100/6120 chips, building modern
>>PDP-8 hardware, and other ideas:
>>
    [Lots deleted]
>>
>>  Please post any comments you might have.
>>
>
>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           | Huw.Davies@latrobe.edu.au
  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 ivie@cc.usu.edu Thu Jan 13 20:37:33 EST 1994
Article: 604 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!magnus.acs.ohio-state.edu!csn!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <1994Jan12.102519.7637@cc.usu.edu>
Date: 12 Jan 94 10:25:19 MDT
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu> <1994Jan11.103957.10934@lugb.latrobe.edu.au>
Organization: Utah State University
Lines: 19

In article <1994Jan11.103957.10934@lugb.latrobe.edu.au>, cchd@lucifer.latrobe.edu.au (Huw Davies) writes:
> 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!). 

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
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Fri Jan 14 06:37:50 EST 1994
Article: 605 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Date: 14 Jan 1994 11:37:07 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 25
Message-ID: <2h6053$ivj@bigblue.oit.unc.edu>
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu> <1994Jan11.103957.10934@lugb.latrobe.edu.au> <1994Jan12.102519.7637@cc.usu.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <1994Jan12.102519.7637@cc.usu.edu>,  <ivie@cc.usu.edu> wrote:
>
>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...

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 ivie@cc.usu.edu Sun Jan 16 05:48:19 EST 1994
Article: 606 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Message-ID: <1994Jan14.135630.7886@cc.usu.edu>
Date: 14 Jan 94 13:56:30 MDT
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu>  <2h6053$ivj@bigblue.oit.unc.edu>
Organization: Utah State University
Lines: 23

In article <2h6053$ivj@bigblue.oit.unc.edu>, lasner@sunSITE.unc.edu (Charles Lasner) writes:
> In article <1994Jan12.102519.7637@cc.usu.edu>,  <ivie@cc.usu.edu> wrote:
>>
>>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...
> 
> Are you referring to anything more than the notion that -5 interrupts are
> one address higher than -8 interrupts?
> 
> IntSavePC -> 0001
> restart at 0002

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

Thanks.
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Sun Jan 16 05:51:49 EST 1994
Article: 607 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: 6100/6120 chips, "Modern" -8 hardware, and other thoughts
Date: 16 Jan 1994 10:47:49 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 120
Message-ID: <2hb60l$1oue@bigblue.oit.unc.edu>
References: <CJAEDC.79A@rahul.net> <2gonri$fi1@bigblue.oit.unc.edu> <2h6053$ivj@bigblue.oit.unc.edu> <1994Jan14.135630.7886@cc.usu.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <1994Jan14.135630.7886@cc.usu.edu>,  <ivie@cc.usu.edu> wrote:
>That's what I was referring to. Didn't know where stuff was stashed or where
>it went.

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



From lasner@sunSITE.unc.edu Sun Jan 16 06:22:30 EST 1994
Article: 608 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: OS/8 Date Problems
Date: 16 Jan 1994 11:21:52 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 179
Message-ID: <2hb80g$5fo@bigblue.oit.unc.edu>
NNTP-Posting-Host: sunsite.unc.edu

At the request of some, here is a detailed explanation of the OS/8 Date
expiration,etc. issues:

In OS/8 V3D, the date is determined as follows:

Bits[3-4] of the c(07777) are a *8 multiplier of the base date group year
off of 1970.  Thus there are 4 possible values:

00 - 1970
01 - 1978
10 - 1986
11 - 1994

Thus, the current correct-time value for these bits is 11, the case for
1994.  This also means that the current method expires 31-Dec-2001. 
(Note: Most date printout routines throughout OS/8 are deficient in that
they will produce incorrect output past 31-Dec-1999.  This is not a
limitation of the date counting itself!)

The relative year is held separately as c(17662).  There are 3 bits for
the relative year 0-7 past the base year.  Other bits stand for the
relative day of the month, and the relative month of the year.

(Note:  A side issue regarding the date word itself is the ability to
easily compare file dates arithmetically.  In this regard, the specific
ordering of these bits was poorly chosen.  Had they been properly ordered
and weighted, it would be possible to compare dates of files directly to
find out if they are before/after some arbitrary date.  Instead, the date
words first have to be unpacked and shuffled into a proper binary
weighting scheme. 

Further, each field (other than the 3-bit year field) has many wasted
states.  Thus, the date word is only useful for exactly an 8-year period. 
Contrast this with the P?S/8 date word scheme:  Each month is assumed to
have exactly 31 days.  The day within a group is determined by multiplying
the year by 372 (12 months in a year * 31 days in a month), and adding on
31 * {relative month in the year 0-11} and adding on {relative day in the
month 0-30} to produce a relative day in that period.  Thus, the only
wasted states are for the few nonexistent days (at most days 29-31) in short
months. 

The resultant date value arithmetically compares directly for newer/older
date tests, etc. Retrieving the individual date values of year, month, day
is accomplished by simple integer division.  Additionally, the useful
range of this method is nearly 12 years.  Since the base group year is
also a multiple of 8 just as in OS/8, this means that the user can
"procrastinate" updating the system's reckoning of the base 8-year group
by nearly 4 years.)

The original design of the PS/8 date scheme was for 1970-1977 only.  The
date within a file is held in an optional "additional information" word
(AIW) in each directory entry, which the user can activate or disable when
the directory is initialized.  Some users opt to avoid file dates because
the limited capacity of the directory can cause disk space to be
inaccessible because there are many (a few hundred) small files.  This
situation is aggravated when the AIW count is increased (from none to
one), etc.  Thus, all standard utilities are written to only care about at
most one AIW word.  If only one is present, it's the date word.  In
theory, if there are more AIW words, then the first one is the date word,
and the rest are user defined. 

To avoid changing the existing flimsy scheme as much as possible, the
extension using bits[3-4] in 07777 was added in OS/8 V3.  Now the date
word is relative to an 8-year group base value which is 0-3 * 8 years past
1970.  The date of a file is actually anomalous, and is subject to being
wrong by integer multiples of 8 years.  A file's date is *presumed* to be
in the 8 year period starting January 1, seven years before the current
year and ending December 31, the current year. 

This is especially troublesome at the beginning of the year.  For example,
as of this writing in January, 1994, files created in December of 1986
appear to be created in the future!  (In December of 1994.)

A partial fix for this would be to change the reckoning to be that if the
year appears to be the current year, then in fact that's only true if the
date is today or less during this year, else the file must be actually
nearly 8 years old.  At the minimum, all date processing in all programs
has to be modified to rectify this particular point.

However, given the need to fix *something*, a better solution ought to
include extending the date in a non-anomalous way.  For starters, this
means that files have to be able to support the notion of 2 AIW values. 
If the second AIW word is present, then it should mean that the file's
exact year can be determined.  Only if a single AIW is present should the
present scheme be used (modified to avoid the rest-of-current-year
"future" anomaly for files nearly 8 years old). (And of course the total
absence of AIW words continues to mean the file is undated.)

Since the current structure supports 32 years since 1970, not too many
bits are needed to make the date last to a reasonably practical upper
limit.  This is fortunate, since finding extension bits may be
problematic. 

One plan to obtain bits currently under consideration is to modify the
contents of 07601.  Other than the incidental usage of bit[11] to
tentatively indicate the "recommendation" to search the tape starting
forwards instead of the normal reverse, bits[9-11] of this word have no
significance whatsoever. 

(Note: the bit[11] usage is meaningful only to certain tape handlers for
all calls made to the handlers, not just this specific usage in 07601
which just happens to be the function word of the call used to save memory
when a program exits by jumping to 07600.  Thus, the only consequence of
this bit set is that the save-exit will take an additional turn around as
the tape starts forward then turns around again realizing that reverse was
a better choice.  Note that unless the tape is physically rewound into the
end zone manually before the program exits, the proper choice for this
operation is certainly to start the tape search in reverse.  Additionally,
there eventually will be available "smarter" tape handlers that ignore
bit[11] and instead produce better tape motion for all calls based on an
internal reckoning of current tape position on a dynamic basis; the
current definition is only purposefully acted upon by a few specific
system handler calls where the efficiency of a forward initial search can
be statically determined.)

Bit[11] of 07601 is being considered as the ^C-abort indicator.  This
would allow programs to indicate ^C keyboard abort by setting this bit and
exiting to 07600.  (This design feature is necessary to facilitate DECmate
functionality of proper program abort exit where the DECmate keyboard
hardware is incapable of supporting the original PDP-8 ability to detect
^C abort.)

Proper design of the abort mechanism requires bit[11] only, but making
available bits[9-10] would allow a safety mechanism should the word be
accidentally incremented too many times.  (Note: as long as all programs
are consistently implemented, the safety mechanism is unnecessary.  P?S/8
has already undergone the analogous change to all system programs.  No
safety mechanism is provided, and the scheme works perfectly well, etc.)

Thus, if the modifications for ^C-abort affect only bit[11], then
bits[9-10] can be used to extend the scope of the date word by a factor of
4.  Thus, OS/8 dates could be extended to the year 2097.  Unless other
bits are located, it would appear that the best overall compromise is to
use the three low-order bits of 07601 in this manner, etc. I would
appreciate any user feedback on the wisdom of this particular set of
tentative changes to allow code to be written to carry it out!

Once the definition for these bits is stabilized, the rest of the problem
consists of modifying the DATE program to maintain them correctly, and
changing the USR and related routines to handle all AIW cases correctly. 
Any program that indicates today's date or the dates within files
according to available AIW words needs to be updated. 

Since the modification only defines two bits of the second AIW word in a
directory entry, perhaps this is a good time to tentatively define the
rest of the bits in the second AIW word.  I propose that it become the
time of day to the nearest two minutes. 

There are 720 two-minute periods in a day, thus this can be expressed in
the remaining 10 bits of the second AIW word.  The format can be all 0000
means that there is no time info in the word.  0001 means the file was
created at 00:00, 0002 means 00:02, 0003 means 00:04, 0004 means 00:06,
etc.  (Note: making a case that means time isn't available as opposed to
00:00 avoids the common anomaly of MS-DOS files in XT-class machines where
there routinely was time reckoning but no hardware clock to maintain the
actual time when the machine was unused.  Unless the user sets the time
accurately, files routinely appear to have been created shortly after
00:00 on 1-Jan-1980.  Better to indicate no time information than clearly
wrong information!)

There are various clocks for the PDP-8 that would allow for real-time
reckoning of the time (DK8E family and the CESI "ASCII" front panel
controller which includes a battery-operated CMOS clock chip are available
for the -8's.  Also, this is an obvious user-definable hardware project! 
All DECmates II and above already support the video clock in CP memory
which is accessible from OS/278 by a documentable call, etc.)  The VT78
and DECmate I always have a 100 Hz clock, as do virtually all -8/a
systems, etc.  Note: it's still the province of a user-defined program to
actually insert this information!  However, most machines at least have
the hardware to make it possible to provide time information if desired. 
Thus, we should implement the mechanism in OS/8 that makes it possible, etc.

If all of the above is completely implemented, then OS/8 file dates from
00:00 1-Jan-1970 through 23:58 31-Dec-2097 can be uniquely represented.  I
leave it to PDP-8 hackers of the 22nd century to further extend what's
discussed here! 

cjl (January 1994)



From napi@cs.indiana.edu Tue Jan 18 06:42:17 EST 1994
Article: 609 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!uhog.mit.edu!rutgers!news.cs.indiana.edu!napi@cs.indiana.edu
From: napi@cs.indiana.edu (Mohd Hanafiah Abdullah)
Newsgroups: alt.sys.pdp8
Subject: Request: Assembler for PDP8
Message-ID: <1994Jan17.121253.1747@news.cs.indiana.edu>
Date: 17 Jan 94 17:12:51 GMT
Organization: Computer Science, Indiana University
Lines: 10


Hi,

I'm new to this newsgroup.  I would like to know if there's a Public Domain
assmbler written in C for the PDP8.  If there's, please inform me where I can
FTP it.

Thanks.

Napi


From jones@pyrite.cs.uiowa.edu Tue Jan 18 06:42:33 EST 1994
Article: 610 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!paladin.american.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!sol.ctr.columbia.edu!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: Re: Request: Assembler for PDP8
Date: 17 Jan 1994 17:50:09 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 10
Distribution: inet
Message-ID: <2hej4h$emf@nexus.uiowa.edu>
References: <1994Jan17.121253.1747@news.cs.indiana.edu>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

>From article <1994Jan17.121253.1747@news.cs.indiana.edu>,
by napi@cs.indiana.edu (Mohd Hanafiah Abdullah):

> I'm new to this newsgroup.  I would like to know if there's a Public Domain
> assmbler written in C for the PDP8.

I E-mailed him the assembler I wrote.  I wonder if they still build PDP-8
systems at Indiana?
					Doug Jones
					jones@cs.uiowa.edu


From eweingar@cs.indiana.edu Tue Jan 18 06:43:09 EST 1994
Article: 611 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!rutgers!news.cs.indiana.edu!eweingar@cs.indiana.edu
From: eweingar@cs.indiana.edu (Peter Weingartner)
Newsgroups: alt.sys.pdp8
Subject: Re: Request: Assembler for PDP8
Message-ID: <1994Jan17.161515.9350@news.cs.indiana.edu>
Date: 17 Jan 94 21:15:11 GMT
References: <1994Jan17.121253.1747@news.cs.indiana.edu> <2hej4h$emf@nexus.uiowa.edu>
Distribution: inet
Organization: Computer Science, Indiana University
Lines: 18

In article <2hej4h$emf@nexus.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879
	<jones@pyrite.cs.uiowa.edu> wrote:
>I wonder if they still build PDP-8 systems at Indiana?

Yes, we still do. Currently, the digital design class is building a
serial port for their PDP-8s. In another few weeks, they'll be redoing
the PDP-8's control logic in microprogram form. I'm the AI (what's
known as a TA in those lands _not_ under the dominion of Bobby Knight)
for the lab, so send me mail if you have any questions of what we're
doing.

By the way, thanks for sending Napi the assembler; it will be a big
help to the class when they start debugging their serial ports.

--pj
-- 
"Small change can often be found under seat cushions." -- Lazarus Long


From ivie@cc.usu.edu Tue Jan 18 06:43:31 EST 1994
Article: 612 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: Request: Assembler for PDP8
Message-ID: <1994Jan17.131434.8017@cc.usu.edu>
Date: 17 Jan 94 13:14:33 MDT
References: <1994Jan17.121253.1747@news.cs.indiana.edu> <2hej4h$emf@nexus.uiowa.edu>
Distribution: inet
Organization: Utah State University
Lines: 15

In article <2hej4h$emf@nexus.uiowa.edu>, jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
> From article <1994Jan17.121253.1747@news.cs.indiana.edu>,
> by napi@cs.indiana.edu (Mohd Hanafiah Abdullah):
> 
>> I'm new to this newsgroup.  I would like to know if there's a Public Domain
>> assmbler written in C for the PDP8.
> 
> I E-mailed him the assembler I wrote.  I wonder if they still build PDP-8
> systems at Indiana?

Maybe he just wants to build some custom ROMs for his DECmate...
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From russ@cs.indiana.edu Tue Jan 18 06:45:24 EST 1994
Article: 613 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab!news.cs.indiana.edu!russ@cs.indiana.edu
From: "J Russ" <russ@cs.indiana.edu>
Subject: PDP8 stuff available via anonymous ftp.
Message-ID: <1994Jan18.024436.24785@news.cs.indiana.edu>
Organization: Computer Science, Indiana University
Date: Tue, 18 Jan 1994 02:44:27 -0500
Lines: 83

I've set up an anonymous ftp server to archive every paper tape, DECtape,
LINCtape, and RX01 floppy I have.  The host name is "nickel.ucs.indiana.edu"
and the ip address is "129.79.1.5".

Over the past few weeks I've uploaded about 100 DECtapes.  I'm in the
process of slowly sorting through the stuff.  Most of what I've uploaded
is source.  Here is a brief summary of what has been dug out so far:

	/pub/DEC/PDP8/Langs	(Languages: Compilers/Interpretters)

		Pascal		Pascal for 28K PDP8 systems
		Lisp		Lisp 1.5
		Algol		"ROGALGOL"
		Focal		Focal and extentions
		8bal		Macro Processor
		Edu25Basic	Edusystem 25 Basic

	/pub/DEC/PDP8/Utils	(Misc Utility Programs)

		DCP		Disassembly programs
		Futil		
		Memo		Program to produce memos
		Ocomp		Octal dump and compare
		Sort		SORT/MERGE/XTRACT
		Spip		Star Pip
		Squash		DECtape Squasher (replaces "/S" option of PIP)
		VC8E		VC8E Graphics 
		Tk4013		Tektronix 4013 Emulator (requires VC8E)

	/pub/DEC/PDP8/Misc	(Misc Stuff)

		PDP8-Cookbook	Programming Examples
		Triple		Simulates a 36-bit PDP8

	/pub/DEC/PDP8/Diags	(Diagnostic/Maintenance Programs)

		RK05-Alignx

	/pub/DEC/PDP8/Music	(Programs for playing music)

		Music1		music.pa version 3 and music files
		Music2		earlier version of music.pa
		Music3		Another music program

	/pub/DEC/PDP8/Teco	(Teco related stuff)

		Macros1		Teco macros

	/pub/DEC/PDP8/Games

		SpaceWar	Space War for LAB8/e systems
		Adventure	The "Adventure" program
		Basic		Dozens of games in Basic

In addition to the DECUS stuff I've also uploaded all of the OS/8 and
compiler sources.  Once the copyright issue of the stuff gets resolved
I'll make all of it available.

Each subdirectory of stuff has two subdirectories: Ascii and OS8.  The
files in the OS8 subdirectory are in native OS/8 format and the files
in the Ascii subdirectory are source/text files converted from the OS/8
files.  The DECtape files have been transferred block by block and the
resulting UNIX file sizes are a multiple of 256*2 bytes.  Each 12-bit word
occupies 16-bits with the upper 4 bits being zero (yes, wasting 25% disk
space).

In addition to PDP8 stuff I also plan to upload PDP4, PDP9, LINC-8, PDP12,
and PDP15 tapes.  If anyone has DECUS stuff on DECtapes and would like them
to be added to the archive let me know.  Over the next few years I'm
planning to enter the schematics of the Flip-Chip modules and eventually
the schematics of entire machines.  I've also started typing in PDP8
diagnostics from the source listings, its painful but someone has to do it.
So far I'm just about done with the TD8E diagnostic.

I also hope to start archiving old CDC operating systems (I plan to build
a CDC 6400 sometime in the future).  I've got the source code to MACE and
Kronos on tape.  I've also started collecting old Apollo workstations and
hope to locate and archive the old Aegis operating system source code.

----------------------------------------------------------------------------
Jeff Russ				russ@silver.ucs.indiana.edu
University Computing Services		PHONE: (812) 855-2733
Indiana University, Bloomington, IN     I want to buy old PDP[4-9] systems.


From jones@pyrite.cs.uiowa.edu Wed Jan 19 07:44:33 EST 1994
Article: 614 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news
From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879)
Newsgroups: alt.sys.pdp8
Subject: DTL chips?  74H... chips?
Date: 18 Jan 1994 16:25:28 GMT
Organization: University of Iowa, Iowa City, IA, USA
Lines: 18
Distribution: inet
Message-ID: <2hh2ho$ipu@nexus.uiowa.edu>
NNTP-Posting-Host: pyrite.cs.uiowa.edu

I've acquired a fair collection of PC boards from random old hardware,
and recently, I've been trying to reduce its size by pulling chips and
throwing out the old fiberglass.  I've got a few hundred 1970 to 1975
chips salvaged at this point, about 20% DTL, 30% 74H... and 50% regular
TTL, and a fair stock of Signetics 8T series chips.  It's a brainless
thing to do, I admit, but when it's 20 below zero outside, a warm
soldering iron (with DIP de-soldering head) is nice company.

So, I suppose my next little job will be to start testing the darned
things.  If I get a 50% yield on chips that are no-longer in production,
I'll be content.

Should I even bother with recovering DTL chips?  At first, I skipped
them, but then I went back and pulled a pile of them just on
speculation (long cold days do that to people, I guess).

					Doug Jones
					jones@cs.uiowa.edu


From ard@siva.bris.ac.uk Wed Jan 19 07:45:51 EST 1994
Article: 615 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: DTL chips?  74H... chips?
Message-ID: <18JAN199419463966@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <2hh2ho$ipu@nexus.uiowa.edu>
Distribution: inet
Date: Tue, 18 Jan 1994 18:46:00 GMT
Lines: 48

In article <2hh2ho$ipu@nexus.uiowa.edu>, jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes...
>I've acquired a fair collection of PC boards from random old hardware,
>and recently, I've been trying to reduce its size by pulling chips and
>throwing out the old fiberglass.  I've got a few hundred 1970 to 1975

I only do that if I can't identify the board, or it's physically damaged, or I
_know_ I'll never get the hardware it fits. Otherwise it gets labeled and put
in my box_of_spares_for_stuff_I_might_get_one_day, which currently contains a
lot of demountable disk spares and (OBpdp8) a load of R,S,B series boards for a
straight-8, amongst other things.

>chips salvaged at this point, about 20% DTL, 30% 74H... and 50% regular
>TTL, and a fair stock of Signetics 8T series chips.  It's a brainless
>thing to do, I admit, but when it's 20 below zero outside, a warm
>soldering iron (with DIP de-soldering head) is nice company.

I prefer the solder-sucker myself, and have a pretty good record of separating
the board from the chip and leaving both intact.

> 
>So, I suppose my next little job will be to start testing the darned
>things.  If I get a 50% yield on chips that are no-longer in production,
>I'll be content.
> 
>Should I even bother with recovering DTL chips?  At first, I skipped
>them, but then I went back and pulled a pile of them just on
>speculation (long cold days do that to people, I guess).

If it were me, I'd pull the DTL, and leave the 74xxx. I can normally find a
modern replacement for TTL (I don't insist on historical accuracy - I'll quite
happily pop a 74F00 in the place of a 74S00 for example), but DTL is difficult
to find replacements for. If the wire-AND feature is not being used, then TTL
will work, and if it is, the equivalent O/C TTL will work with a 3k (ish)
pull-up. BUT, what do you do when a DTL flip-flop has wired-and outputs? In
some cases, pulling the output of such a device low can change the state of the
flip-flop, and I've seen this feature used in a commercial device.
So, I'd keep the DTL as well.


> 
>					Doug Jones
>					jones@cs.uiowa.edu

-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.



From billh@comtch.iea.com Wed Jan 19 07:46:35 EST 1994
Article: 616 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!umn.edu!gaia.ucs.orst.edu!connected.com!krel.iea.com!comtch!billh
From: billh@comtch.iea.com (Bill Haygood)
Newsgroups: alt.sys.pdp8
Subject: FPP-8/A Floating Point Processor
Date: 16 Jan 1994 18:02:26 GMT
Organization: CompuTech, Spokane WA
Lines: 22
Message-ID: <2hbvfi$l8l@krel.iea.com>
NNTP-Posting-Host: comtch.iea.com
X-Newsreader: TIN [version 1.2 PL1]

If you can answer any of the following questions about the FPP-8/A,
I would appreciate a response.  Please cite a printed reference, if
possible (but, please respond anyway if not!):

	Questions:
	(1) Once the FADDM/FMULM bit gets set, does it stay set until
 		the next FPICL or does it get cleared with each new FPP
		instruction execution ?  (Presently implemented as the
		latter in my emulator.)
	(2) What do opcodes 5100-5177 do ?  (Presently implemented as
		Unknown OpCodes causing an exit from the emulator.)
	(3) What do opcodes 6000-6177 and 7000-7177 do ?  I think they
		they refer to the mnemonics IMUL, IMULI, LEA and LEAI.
		What format do they use and what should an instance of
		execution produce ?  (Presently implemented in my
		emulator as my GUESS--and when I guess, I frequently
		get it wrong!)
	(4) The OS/8 Handbook, page 5-9 states that TRAP3 acts as a
		JMP to PDP8 mode and that TRAP4 acts as a JMS to PDP8
		mode.  Any ideas what this means ?

--Bill Haygood


From dicks@math.ohio-state.edu Wed Jan 19 07:47:33 EST 1994
Article: 617 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!math.ohio-state.edu!not-for-mail
From: dicks@math.ohio-state.edu (Ethan Dicks)
Newsgroups: alt.sys.pdp8
Subject: Re: PDP8 stuff available via anonymous ftp.
Date: 19 Jan 1994 01:26:44 -0500
Organization: Department of Mathematics, The Ohio State University
Lines: 37
Message-ID: <2hijr4$773@math.mps.ohio-state.edu>
References: <1994Jan18.024436.24785@news.cs.indiana.edu>
NNTP-Posting-Host: math.mps.ohio-state.edu

In article <1994Jan18.024436.24785@news.cs.indiana.edu>,
J Russ <russ@cs.indiana.edu> wrote:
>I've set up an anonymous ftp server to archive every paper tape, DECtape,
>LINCtape, and RX01 floppy I have.  The host name is "nickel.ucs.indiana.edu"
>and the ip address is "129.79.1.5".

Jeff,

I've got a bunch of paper tapes from DEC as well as DECUS.  At the present
time, I've got no easy way to read them (most of my older -8 stuff is in 
storage and it's -20F tonight!)  The entire collection is 4 12" boxes of
fanfold tape (~60 tapes, max)

Some of these tapes are the MAINDEC diags for the 8/I, some are diags for
the 8/e.  Some are DECUS utilities.

I've also got a few dozen DECtapes that were last used by me in about 1985.
Most of the contents are various cominations of OS/8 CUSPS with an original
PA source build tape thrown in for fun.

I've still got that RK05F pack for you, anytime you want it.  I will be
happy to arrange shipping or to meet you at a Hamfest in the next few months.

After you get all of your stuff on the ftp site and add to that any of
mine that you don't already have, how about working towards a CD-ROM archive
of the whole shootin-match?  With enough *pre-sold* copies, it should be
doable for ~$25-$40/disk (one disk, presumably, updates as necessary, but 
rarely).

Let me know.  I'm posting this to forment additional discussion.

-ethan
-- 
This message was (fortunately) not brought to you by Intel...
  "Intel: bringing you the "backward" in backward compatibilty."

dicks@math.ohio-state.edu -or- erd@kumiss.cmhnet.org


From ivie@cc.usu.edu Wed Jan 19 07:56:39 EST 1994
Article: 618 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!gatech!howland.reston.ans.net!agate!dog.ee.lbl.gov!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: JMS I Z 10?
Message-ID: <1994Jan18.163529.8097@cc.usu.edu>
Date: 18 Jan 94 16:35:29 MDT
Organization: Utah State University
Lines: 14

Greetings!

As I mentioned earlier, I've been fussing about on and off with building a
PDP-5 inside a Xilinx. One thing that's always stymied me, though, is handling
an indirect JMS through an autoindex register. I've not figured out how to
do it without using an extra register (I've toyed with using the accumulator,
but decided that clearing the accumulator was not a good side effect for the
JMS instruction).

Any software out there that actually does a JMS I Z 10?
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From lasner@sunSITE.unc.edu Wed Jan 19 07:57:00 EST 1994
Article: 619 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: DTL chips?  74H... chips?
Date: 19 Jan 1994 12:44:27 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 33
Distribution: inet
Message-ID: <2hj9vb$g46@bigblue.oit.unc.edu>
References: <2hh2ho$ipu@nexus.uiowa.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <2hh2ho$ipu@nexus.uiowa.edu>,
Douglas W. Jones,201H MLH,3193350740,3193382879 <jones@pyrite.cs.uiowa.edu> wrote:
>
>Should I even bother with recovering DTL chips?  At first, I skipped
>them, but then I went back and pulled a pile of them just on
>speculation (long cold days do that to people, I guess).

Two things:

1)	If the DTL chips are spares for the W707, etc. modules of the
PT08, please make them available.  Some of us have repairable boards for
the peripheral which don't work "for the want of a nail" of repairing some
of those boards *all* of which are DTL.

2)	This raises the issue of what spare chips we all need to support
some of the 8/e boards.  Unfortunately, DEC used some chips that were
never all that popular, and while we can more easily get older stuff, what
do you do for certain specific ones?

In any case, I think we should start compiling lists of chips that aren't
74xx and give references to their frequency of usage, i.e., there are
Omnibus boards that use 1-3 SP314 chips as the device decoder, etc.  And
also, the boards need to be "weighted" in terms of both how many are
likely to be needed to be supported.  (It's reasonable to expect 3 KL-type
boards per reasonablly-configured -8/e, so their funny-chip-usage counts
should be multiplied by 3, while funny-chips from say the DP8E synchronous
modem interface shouldn't "count" as much, etc.)

Then hopefully we can get a handle on just what our potential requirements
are, as well as potential sources for the chips themselves, etc.

cjl



From lasner@sunSITE.unc.edu Wed Jan 19 07:57:30 EST 1994
Article: 620 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: JMS I Z 10?
Date: 19 Jan 1994 12:56:32 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 26
Message-ID: <2hjam0$b9b@bigblue.oit.unc.edu>
References: <1994Jan18.163529.8097@cc.usu.edu>
NNTP-Posting-Host: sunsite.unc.edu

In article <1994Jan18.163529.8097@cc.usu.edu>,  <ivie@cc.usu.edu> wrote:
>Any software out there that actually does a JMS I Z 10?

Yes, diagnostics.  The hardware guys were always testing odd cases that
weren't mainstream coding techniques.  Occasionally, some of their ideas
became part of the "regular" software!

I don't have a particular example, but here's a counter-example taken from
the -8/e EAE diagnostic:

In mode B EAE, the MUY instruction does *not* take its argument in-line
(as in mode A) but rather the next word is a *pointer* to the argument. 
The diagnostic places the MUY instruction into 00007 and dares the
hardware to screw up on both the DF and auto-index implications of the
reference to 00010 in the deferred state.

I *almost* used the notion of placing a DLD;xxxx sequence into locations
00016-00017 as part of a subroutine to pull in a DP list off a pointer,
but it doesn't work the way I want it to!  Unfortunately, they auto-index
(as expected!) the c(00017) but then copy the pointer address data into an
internal register.  Thus, it's only good if you want to "half"-increment
your way through a list of DP values.  (Perhaps this could be useful! 
Just wasn't to me at the time!)

cjl



From lasner@sunSITE.unc.edu Wed Jan 19 13:35:26 EST 1994
Article: 621 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8,comp.sys.dec.micro
Subject: RX50 FAQ Update
Date: 19 Jan 1994 18:34:44 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 15
Message-ID: <2hjug4$l90@bigblue.oit.unc.edu>
NNTP-Posting-Host: sunsite.unc.edu
Keywords: PC's RX50 DECmate Rainbow Pro Micro-11 Formatting
Xref: bigblue.oit.unc.edu alt.sys.pdp8:621 comp.sys.dec.micro:2330

The RX50 FAQ file regarding PC utilities, etc. has been updated and is
available via anonymous ftp from sunsite.unc.edu.  The path is:

/pub/academic/computer-science/history/pdp-8/docs/rx50faq.doc

This file should contain anything you ever wanted to know about RX50's and
PC utilities to maintain them, etc.  

Future versions will incorporate more generic aspects of RX50 such as
media considerations, etc. which are available in other documents
presently, etc.


cjl



From krause@azu.informatik.uni-stuttgart.de Fri Jan 21 09:41:36 EST 1994
Article: 622 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news
From: krause@azu.informatik.uni-stuttgart.de (krause)
Subject: Re: DTL chips?  74H... chips?
Message-ID: <1994Jan21.091705.25351@ifi.informatik.uni-stuttgart.de>
Sender: news@informatik.uni-stuttgart.de
Organization: Informatik, Uni Stuttgart, Germany
References: <2hh2ho$ipu@nexus.uiowa.edu>
Distribution: inet
Date: Fri, 21 Jan 1994 09:17:05 GMT
Lines: 30

In article <2hh2ho$ipu@nexus.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>I've acquired a fair collection of PC boards from random old hardware,
>and recently, I've been trying to reduce its size by pulling chips and
>throwing out the old fiberglass.  I've got a few hundred 1970 to 1975
>chips salvaged at this point, about 20% DTL, 30% 74H... and 50% regular
>TTL, and a fair stock of Signetics 8T series chips.  It's a brainless
>thing to do, I admit, but when it's 20 below zero outside, a warm
>soldering iron (with DIP de-soldering head) is nice company.
>
>So, I suppose my next little job will be to start testing the darned
>things.  If I get a 50% yield on chips that are no-longer in production,
>I'll be content.
>
>Should I even bother with recovering DTL chips?  At first, I skipped
>them, but then I went back and pulled a pile of them just on
>speculation (long cold days do that to people, I guess).

Certainly you should!
You can (still) buy TTL-chips, but you can't buy DTL-chips.
A similar problem is with the old japanase PMOS-chips, for example HD 31xx
and HD 32xx or uPD 10 and so.
They are very often in old desktop calculators and Hitachi and NEC even don't
remember that they ever built such things.

So put them on stock.

Klemens Krause
University Stuttgart
(germany)



From krause@azu.informatik.uni-stuttgart.de Fri Jan 21 09:42:30 EST 1994
Article: 623 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news
From: krause@azu.informatik.uni-stuttgart.de (krause)
Subject: Re: PDP8 stuff available via anonymous ftp.
Message-ID: <1994Jan21.093447.28033@ifi.informatik.uni-stuttgart.de>
Sender: news@informatik.uni-stuttgart.de
Organization: Informatik, Uni Stuttgart, Germany
References: <1994Jan18.024436.24785@news.cs.indiana.edu>
Date: Fri, 21 Jan 1994 09:34:47 GMT
Lines: 31

In article <1994Jan18.024436.24785@news.cs.indiana.edu> "J Russ" <russ@cs.indiana.edu> writes:
>I've set up an anonymous ftp server to archive every paper tape, DECtape,
>LINCtape, and RX01 floppy I have.  The host name is "nickel.ucs.indiana.edu"
>and the ip address is "129.79.1.5".
>
>
>In addition to the DECUS stuff I've also uploaded all of the OS/8 and
>compiler sources.  Once the copyright issue of the stuff gets resolved
>I'll make all of it available.
>
>the schematics of entire machines.  I've also started typing in PDP8
>diagnostics from the source listings, its painful but someone has to do it.
>So far I'm just about done with the TD8E diagnostic.


The best idea I ever heard here on the net!

I could add some programs (chekmo for example) and I could also supply the
diagnostics for the lab-8/E. (The .BN-files.) I'm trying to scan the operation
instructions and convert it to ASCII with OCR-software. But sometimes I think
it would be simpler to type it in directly.

I have also some sources e.g. DIRECT.PA which come from DECUS so there shouldn't
be any copyright problems.



Klemens Krause
University Stuttgart
(germany)



From ard@siva.bris.ac.uk Fri Jan 21 09:42:54 EST 1994
Article: 624 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!pipex!uknet!warwick!bsmail!siva.bris.ac.uk!ard
From: ard@siva.bris.ac.uk (PDP11 Hacker .....)
Subject: Re: DTL chips?  74H... chips?
Message-ID: <21JAN199410545222@siva.bris.ac.uk>
News-Software: VAX/VMS VNEWS 1.41    
Sender: usenet@info.bris.ac.uk (Usenet news owner)
Nntp-Posting-Host: siva.bris.ac.uk
Organization: University of Bristol Physics Department
References: <2hh2ho$ipu@nexus.uiowa.edu> <1994Jan21.091705.25351@ifi.informatik.uni-stuttgart.de>
Distribution: inet
Date: Fri, 21 Jan 1994 09:54:00 GMT
Lines: 24

In article <1994Jan21.091705.25351@ifi.informatik.uni-stuttgart.de>, krause@azu.informatik.uni-stuttgart.de (krause) writes...

>A similar problem is with the old japanase PMOS-chips, for example HD 31xx
>and HD 32xx or uPD 10 and so.

Are those the ones that stuff the boards in (say) the Casio AL2000?
If so, does anyone have pinouts/data/etc for them. I've got some machines using
them that I am trying to repair at the moment.

>They are very often in old desktop calculators and Hitachi and NEC even don't
>remember that they ever built such things.
> 
>So put them on stock.
> 
>Klemens Krause
>University Stuttgart
>(germany)
> 

-tony

Bristol University takes no responsibility for the views expressed in this
posting. They are the personal views of the user concerned.



From jhhl@panix.com Sat Jan 22 08:58:30 EST 1994
Article: 625 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!corpgate!news.utdallas.edu!wupost!uhog.mit.edu!MathWorks.Com!europa.eng.gtefsd.com!paladin.american.edu!howland.reston.ans.net!news.ans.net!tinman.dev.prodigy.com!panix!not-for-mail
From: jhhl@panix.com (Henry Lowengard)
Newsgroups: alt.sys.pdp8
Subject: TRAC-64
Date: 21 Jan 1994 12:28:57 -0500
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 27
Message-ID: <2hp3cp$4tr@panix.com>
NNTP-Posting-Host: panix.com
Summary: Looking for this decrepit language
Keywords: TRAC-64, STRING

   Hi folks:
    On my college's PDP/8 running TSS/8 we had a language known as
STRING which was really a version of TRAC-64. We also had source for this
and I was wondering if either of these things has appereared. I made
my own adaptation (I think) called FADEN - just so people wouldn't know what I was doing.

   TRAC code looks like this:
     #(DS,F,#(ML,ARG,4))'
     #(SS,F,ARG)'
     #(F,6)' 24
etc. 
  sort of a cross between FORTH and LISP. I actually wrote my own variant
of this on the MOSS/AMORAL system for NORD-10 (Norwegian) computer in 
Oslo in 1976. (?!) My version was easier to read and was called
MOTHBOL. MOTHBOL had some very weird ways of making temporary
variables (there is no stack in TRAC or MOTHBOL - the text itself is
continuously interpreted and substituted). Also, real TRAC has an
arbitrary precision math (integer) package as a default!
    and: I recently came across my one surviving paper tape from 20
years ago. perhaps I'll transcribe it and run it through the emulator!
(Lots of spare time on my hands?)
        jhhl

-- 
+---------------------------------------------------------------------------+
| jhhl   @panix.com    Henry Lowengard     43 W16 #2D NYC 10011-6320 USA    |
+---------------------------------------------------------------------------+


From cchd@lucifer.latrobe.edu.au Sat Jan 22 08:58:54 EST 1994
Article: 626 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!lugb!lucifer!cchd
Newsgroups: alt.sys.pdp8
Subject: Hard Disk for my -8A
Message-ID: <1994Jan22.033505.3220@lugb.latrobe.edu.au>
From: cchd@lucifer.latrobe.edu.au (Huw Davies)
Date: Sat, 22 Jan 1994 03:35:05 GMT
Sender: news@lugb.latrobe.edu.au (USENET News System)
Organization: La Trobe University
Lines: 11

With all the successes I've had in the last few days on other projects
(the 11/44 now boots and hopefully will be running Unix by the end of
the weekend) I've been thinking about my -8A again. Whilst floppies are
nice? I think a hard disk would be quieter! What sort of hard disks are
supported? In particular, can I connect an RL02 (I have a spare one or
two from the -11 project)?
-- 
  Huw Davies           | Huw.Davies@latrobe.edu.au
  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 ivie@cc.usu.edu Sun Jan 23 01:39:50 EST 1994
Article: 627 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!sol.ctr.columbia.edu!caen!hellgate.utah.edu!cc.usu.edu!ivie
From: ivie@cc.usu.edu
Newsgroups: alt.sys.pdp8
Subject: Re: PDP8 stuff available via anonymous ftp.
Message-ID: <1994Jan21.212050.8462@cc.usu.edu>
Date: 21 Jan 94 21:20:50 MDT
References: <1994Jan18.024436.24785@news.cs.indiana.edu> <1994Jan21.093447.28033@ifi.informatik.uni-stuttgart.de>
Organization: Utah State University
Lines: 13

In article <1994Jan21.093447.28033@ifi.informatik.uni-stuttgart.de>, krause@azu.informatik.uni-stuttgart.de (krause) writes:
>  I'm trying to scan the operation
> instructions and convert it to ASCII with OCR-software. But sometimes I think
> it would be simpler to type it in directly.

Speaking of which, I've noticed that there isn't a copyright notice on my
PDP-8/i programming card. I believe the same is true of my PDP-5 programming
card. If I get some copious free time, I'll try scanning them. I don't think
the PDP-5 card will scan well; it's dark green on a light green background.
-- 
----------------+------------------------------------------------------
Roger Ivie      | Don't think of it as a 'new' computer, think of it as
ivie@cc.usu.edu |     'obsolete-ready'


From bqt@Update.UU.SE Sun Jan 23 01:40:17 EST 1994
Article: 628 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!darwin.sura.net!howland.reston.ans.net!pipex!sunic!corax.udac.uu.se!bqt
From: bqt@Update.UU.SE (Johnny Billquist)
Newsgroups: alt.sys.pdp8
Subject: Re: Hard Disk for my -8A
Date: 23 Jan 1994 05:42:41 GMT
Organization: Uppsala University
Lines: 20
Message-ID: <2ht2oh$8fq@corax.udac.uu.se>
References: <1994Jan22.033505.3220@lugb.latrobe.edu.au>
NNTP-Posting-Host: krille.update.uu.se

In <1994Jan22.033505.3220@lugb.latrobe.edu.au> cchd@lucifer.latrobe.edu.au (Huw Davies) writes:

>With all the successes I've had in the last few days on other projects
>(the 11/44 now boots and hopefully will be running Unix by the end of
>the weekend) I've been thinking about my -8A again. Whilst floppies are
>nice? I think a hard disk would be quieter! What sort of hard disks are
>supported? In particular, can I connect an RL02 (I have a spare one or
>two from the -11 project)?

The RL01 and RL02 can be connected, if you have the RL8A controller.
Not that common, though. Much easier to find RK8E controllers, and
hook up RK05J (or RK05F) to it.
However, the RK05 media is different for 12-bit and 16-bit machines.

	Johnny
--
Johnny Billquist                  || "I'm on a bus
CS student at Uppsala University  ||  on a psychedelic trip
email: bqt@minsk.docs.uu.se       ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


From krause@azu.informatik.uni-stuttgart.de Tue Jan 25 19:12:37 EST 1994
Article: 629 of alt.sys.pdp8
Newsgroups: alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!darwin.sura.net!howland.reston.ans.net!xlink.net!news.belwue.de!ifi!news
From: krause@azu.informatik.uni-stuttgart.de (krause)
Subject: Re: DTL chips?  74H... chips?
Message-ID: <1994Jan24.094203.9221@ifi.informatik.uni-stuttgart.de>
Sender: news@informatik.uni-stuttgart.de
Organization: Informatik, Uni Stuttgart, Germany
References: <2hh2ho$ipu@nexus.uiowa.edu> <1994Jan21.091705.25351@ifi.informatik.uni-stuttgart.de> <21JAN199410545222@siva.bris.ac.uk>
Distribution: inet
Date: Mon, 24 Jan 1994 09:42:03 GMT
Lines: 30

In article <21JAN199410545222@siva.bris.ac.uk> ard@siva.bris.ac.uk (PDP11 Hacker .....) writes:
>In article <1994Jan21.091705.25351@ifi.informatik.uni-stuttgart.de>, krause@azu.informatik.uni-stuttgart.de (krause) writes...
>
>>A similar problem is with the old japanase PMOS-chips, for example HD 31xx
>>and HD 32xx or uPD 10 and so.
>
>Are those the ones that stuff the boards in (say) the Casio AL2000?
>If so, does anyone have pinouts/data/etc for them. I've got some machines using
>them that I am trying to repair at the moment.
>
>
I have the pinouts and short functional description of some of them. 
HD 31.. was high voltage PMOS (-27V) and HD 32.. was low voltage PMOS (-17V) or
so. Most of them was SSI, but there is also a BCD-ALU and shift registers.
I can post my information here on the net, but I don't know, if this here is
the right group (.PDP8)?

I once analyzed the Casio AS/L, a small desk top calculator with those IC's from
1970. It's highly interesting, he has something like microprogrammed CPU below
the i 4004. The whole microprogramm consists of 256 words with 16 Bits, where
8 bits contain the adress of the next word. Conditional jumps are made by an
AND which is connected to the carry output of the CPU and which masks out an
address line of the microprogramm ROM.
The 256 words of microprogramm perform floating point and fix point arithmetic
as well as one calculating memory register.

Klemens Krause
University Stuttgart
(Germany)



From lluther@disney.com Tue Jan 25 19:13:17 EST 1994
Article: 630 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!walt.disney.com!wdi.disney.com!alice!lluther
From: lluther@disney.com (Larry Luther)
Newsgroups: alt.sys.pdp8
Subject: Re: TRAC-64
Date: 25 Jan 1994 05:41:20 GMT
Organization: Walt Disney Imagineering
Lines: 40
Message-ID: <2i2be0INN2c5@ford.is.wdi.disney.com>
References: <2hp3cp$4tr@panix.com>
NNTP-Posting-Host: alice.rd.wdi.disney.com


In article <2hp3cp$4tr@panix.com>, jhhl@panix.com writes:
>    Hi folks:
>     On my college's PDP/8 running TSS/8 we had a language known as
> STRING which was really a version of TRAC-64. We also had source for this
> and I was wondering if either of these things has appereared. I made
> my own adaptation (I think) called FADEN - just so people wouldn't know what I was doing.
> 
>    TRAC code looks like this:
>      #(DS,F,#(ML,ARG,4))'
>      #(SS,F,ARG)'
>      #(F,6)' 24
> etc. 
>   sort of a cross between FORTH and LISP. I actually wrote my own variant
> of this on the MOSS/AMORAL system for NORD-10 (Norwegian) computer in 
> Oslo in 1976. (?!) My version was easier to read and was called
> MOTHBOL. MOTHBOL had some very weird ways of making temporary
> variables (there is no stack in TRAC or MOTHBOL - the text itself is
> continuously interpreted and substituted). Also, real TRAC has an
> arbitrary precision math (integer) package as a default!
>     and: I recently came across my one surviving paper tape from 20
> years ago. perhaps I'll transcribe it and run it through the emulator!
> (Lots of spare time on my hands?)
>         jhhl
> 
> -- 
> +---------------------------------------------------------------------------+
> | jhhl   @panix.com    Henry Lowengard     43 W16 #2D NYC 10011-6320 USA    |
> +---------------------------------------------------------------------------+

    You didn't do justice to TRAC by comparing it to Forth and Lisp.
Its elegance is comparable but TRAC and GPM are general purpose macro
processors.  TRAC was used as a preprocessor for the rendering software
used on Digital Productions Cray XMP.  It is quite interesting.  I first
came accross it at school where I implemented it on a PDP 11/20.  It
only took about 900 instructions.


Larry Luther
lluther@disney.com


From geremin@decus.org.au Tue Jan 25 19:33:30 EST 1994
Article: 631 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!news-feed-2.peachnet.edu!emory!europa.eng.gtefsd.com!howland.reston.ans.net!cs.utexas.edu!swrinde!sgiblab!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!decus!geremin
Newsgroups: decus.nop,aus.general,comp.org.decus,vmsnet.pdp-11,alt.sys.pdp8
Subject: January Meeting of NOP SIG in Sydney.
Message-ID: <1994Jan25.222707.14765@decus.org.au>
From: geremin@decus.org.au
Date: 25 Jan 94 22:27:07 AEST
Organization: DECUS, South Pacific Chapter
Lines: 48
Xref: bigblue.oit.unc.edu comp.org.decus:2655 vmsnet.pdp-11:692 alt.sys.pdp8:631


	D E C U S     R L 0 2  -  D I S K    R O U N D U P    T I M E

	Now is the time to clean out the computer room cupboards and 
	send all your old RL01/RL02 packs off to the NOP SIG Library. 
	We need these to help complete the DECUS collection of DEC Software. 
	We want any system - any version. Documentation is also wanted.

	Dont think that your old packs are useless if you do not have a 
	complete set, we already have lots of partial sets of RL packs
	and the more we get the better.   
	
	Call Cameron on 02-872 4728, or John on 02-764 4855 to arrange for
	a pick-up. Dont forget the matching manuals and documentation.
	Popular third-party products are also very welcome. 


	DECUS  NOP  DECUS  NOP  DECUS  NOP  DECUS  NOP  DECUS  NOP


	NOP SIG Meeting -  RL02 Sorting and Cataloguing Party.
	======================================================

	Mike Chevallier has offered to host the next meeting on 
	Monday, 31st January, 1994 at 6pm, at 23 Wattle Street, Killara. 

	Minor formalities will include a report from Tom Gayford, newly
	elected Board member. Other people will report on out attempts to
	obtain some proper workshop/display space for our NOP machines.
	
	Mike, as the new NOP SIG Chairman will introduce his committee so
	that we will all know who to contact for specialist advice. This 
	will be followed by refreshments (sounds like bribery to me).BYOG. 

	RSVP:-  All network users are to reply via e-mail to 
	NOW:		IN%"geremin@decus.com.au".
		Others to Mike at Ramparts on 02-498 3383.

	John G. on behalf of  Mike Chevallier, NOP SIG Chairman.
		      --------------------------------

-- 

Regards,   John G.		(alias 'megaJOHN')
v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v
 John Geremin,   HARDWARE  SWG  Chairman,   DECUS Australia.
IN%"geremin@decus.com.au"     voice: 61-2- 764 4855  (9am-9pm)
-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-


From delta1@netcom.com Tue Jan 25 19:33:39 EST 1994
Article: 632 of alt.sys.pdp8
Newsgroups: comp.lang.c,alt.folklore.computers,alt.sys.pdp8
Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!delta1
From: delta1@netcom.com (Randall Raemon)
Subject: Re: Trivial? YOU be the judge
Message-ID: <delta1CK779n.Fsv@netcom.com>
Followup-To: alt.sys.pdp8 
Keywords: DECmate ancient decrepit error_16
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References: <2i1e6e$eqg@caslon.CS.Arizona.EDU> <759454386snz@genesis.demon.co.uk> <CK5yE1.440@mentor.cc.purdue.edu>
Date: Tue, 25 Jan 1994 18:27:22 GMT
Lines: 57
Xref: bigblue.oit.unc.edu comp.lang.c:57508 alt.folklore.computers:56651 alt.sys.pdp8:632

First off, my apologies to the net for quoting the entire article. However,
there is a reason: A DECmate III is part of the PDP-8 family of machines, and
I am cross-posting to alt.sys.pdp8 so the folks there can give their insights
to the machine...

Please note the reply email address at the end. 

Also, I have set follow-up postings to go to alt.sys.pdp8

Good luck...


In article <CK5yE1.440@mentor.cc.purdue.edu> (null pointer)@fugue.cc.purdue.edu (Branden 'Crash' Robinson) writes:
>OK, this may be about as effective as spitting into the wind, but I've
>lurked in this newsgroup occasionally, and if you guys don't know the
>answer, no one will.
>
>Scenario: There is an old, old DECmate III sitting in the dumb terminal
>room in Tarkington Hall here at Purdue.  Why is it here?  My best guess
>is that it's left over from bygone days.  Just so y'all don't think Purdue
>is COMPLETELY broke, we *do* have 3 486's, 2 Mac IIci's, and a Sun SPARC
>IPC in the REAL computer room.
>
>Anyway, this computer^H^H^H^H word processor sits here, unused, whiling
>away its lonely hours next to the Zenith dumb terminals.  Does it work?
>Almost.  It boots (it's a loud thing) but instead of giving a menu screen
>like the manuals say it should, it places a cryptic error number in the
>middle of the screen: 16.  A hapless block cursor flashes in the upper
>left-hand corner.  Absolutely NOTHING but the power switch budges it
>from that state...which is all it will do.
>
>At any rate, the docs are here on using the word processor, but the
>infamous "Owner's Manual" is nowhere to be found.  The office doesn't
>have it, and the hall computer guru doesn't know or care what made that
>book vanish in the past 10 years.
>
>To wrap up this sad saga, this machine DOES have communication capability,
>described in some detail in these manuals.  It will support a direct
>serial cable of some sort, and even a modem.  At the very least, it could
>spend its remaining years jacked into the PUCC net instead of gathering
>dust.  Of course, it would be easy to just say, "Let the thing die," but
>I figure, hey, it's lived 10 years as of '94, so why not USE it?
>
>Does anyone else have sympathy for lonely old computers, however limited
>they may be?  What is this mysterious "error 16"?  Can it be fixed by a
>sentimental young engineering major with a screwdriver, duct tape, and
>a wicked glint in the eye?
>
>Email your suggestions for this lost cause to:
>branden@symphony.cc.purdue.edu
>
>Heck, post 'em, too.
>
>G. Branden Robinson
>(.sig coming soon to a newsreader near you!)
>



From lasner@sunSITE.unc.edu Tue Jan 25 20:41:37 EST 1994
Article: 633 of alt.sys.pdp8
Path: bigblue.oit.unc.edu!sunSITE!lasner
From: lasner@sunSITE.unc.edu (Charles Lasner)
Newsgroups: alt.sys.pdp8
Subject: Re: Trivial? YOU be the judge
Date: 26 Jan 1994 01:30:26 GMT
Organization: University of North Carolina, Chapel Hill
Lines: 123
Message-ID: <2i4h3i$oac@bigblue.oit.unc.edu>
References: <2i1e6e$eqg@caslon.CS.Arizona.EDU> <759454386snz@genesis.demon.co.uk> <CK5yE1.440@mentor.cc.purdue.edu> <delta1CK779n.Fsv@netcom.com>
NNTP-Posting-Host: sunsite.unc.edu
Keywords: ignorant about DECmate error_16

In article <delta1CK779n.Fsv@netcom.com>,
Randall Raemon <delta1@netcom.com> wrote:
>First off, my apologies to the net for quoting the entire article. However,
>there is a reason: A DECmate III is part of the PDP-8 family of machines, and
>I am cross-posting to alt.sys.pdp8 so the folks there can give their insights
>to the machine...

Thanks for the posting to the appropriate place.

>In article <CK5yE1.440@mentor.cc.purdue.edu> (null pointer)@fugue.cc.purdue.edu (Branden 'Crash' Robinson) writes:
>>OK, this may be about as effective as spitting into the wind, but I've
>>lurked in this newsgroup occasionally, and if you guys don't know the
>>answer, no one will.
>>
>>Scenario: There is an old, old DECmate III sitting in the dumb terminal
>>room in Tarkington Hall here at Purdue.  Why is it here?  My best guess
>>is that it's left over from bygone days.

With standard software usually provided, it makes an OK dumb terminal 
(VT-220 mostly).  Even today, some of the machines you describe below 
have problems doing the same (such as 132-col mode, reverse video 
changeable on demand with no contents loss, etc.).  Moreover, the DEC 
keyboard is so popular, there's a PC version of it.

>>  Just so y'all don't think Purdue
>>is COMPLETELY broke, we *do* have 3 486's, 2 Mac IIci's, and a Sun SPARC
>>IPC in the REAL computer room.

I'm underwhelmed.

>>
>>Anyway, this computer^H^H^H^H word processor sits here, unused, whiling
>>away its lonely hours next to the Zenith dumb terminals.  Does it work?
>>Almost.  It boots (it's a loud thing) but instead of giving a menu screen
>>like the manuals say it should, it places a cryptic error number in the
>>middle of the screen: 16.  A hapless block cursor flashes in the upper
>>left-hand corner.  Absolutely NOTHING but the power switch budges it
>>from that state...which is all it will do.

You decided that it booted.  In point of fact, it did not; the 16 is an 
error message with appropriate volume.  Had it actually booted, there 
would be a whole lot of disk activity, and eventually the menu, etc.  
This of course assumes you run WPS, since you are decribing a WPS manual, 
not a DECmate requirement.  Unfortunately, while the DECmate family is 
indeed part of the PDP-8 world, DEC's policy for far too many years was 
to obscure that fact, and only make available WPS (and maybe COS) for it, 
not any of the more general PDP-8 stuff now only available because of 
DECUS and other user efforts, etc.  (Such efforts include hand 
disassembly of ROM's on my part, etc.)

>>
>>At any rate, the docs are here on using the word processor, but the
>>infamous "Owner's Manual" is nowhere to be found.  The office doesn't
>>have it, and the hall computer guru doesn't know or care what made that
>>book vanish in the past 10 years.

There is a semblance of an owner's manual; it's useless.  However, it may 
have given you a clue about the error as I remember it.

>>
>>To wrap up this sad saga, this machine DOES have communication capability,
>>described in some detail in these manuals.  It will support a direct
>>serial cable of some sort, and even a modem.  At the very least, it could
>>spend its remaining years jacked into the PUCC net instead of gathering
>>dust.  Of course, it would be easy to just say, "Let the thing die," but
>>I figure, hey, it's lived 10 years as of '94, so why not USE it?

As virtually every reader of alt.sys.pdp8 knows, this little machine's 
main problem is lack of a hard disk.  So, things tend to take longer to 
happen, and you my have to flip some floppies, etc.  However, with 
available software (such as my Kermit-12 and OS/278 V2) you can be 
exchanging files with the rest of the world from it directly.

BTW, "old"  is a relative term.  I have a functioning LINC-8 from 1966. 
The DECmate III series was discontinued from production in 1990. 

>>
>>Does anyone else have sympathy for lonely old computers, however limited
>>they may be?  What is this mysterious "error 16"?  Can it be fixed by a
>>sentimental young engineering major with a screwdriver, duct tape, and
>>a wicked glint in the eye?

Our group specializes in it, and many of us have DECmate(s).  The III is 
the baby of the line, but can be upgraded to have all of the following:

Instead of mono monitor, it can have a RGB color monitor with 800 lines 
of video and a color graphics board.  How many of those machines you 
rattled off could do 800 line video in 1984?

It can have the APU option board to run CP/M-80 (and might already; they 
were fairly common add-ons).  They were added for the somewhat demented 
reason - the management found it easier to find someone to write Z80 code 
to add foot-note formatting and DECspell than to get the same thing done 
in less disk space (and require less hardware!) using direct PDP-8 code.  
(Note: WPS is a system short on space since it all has to exist on a 
single RX50.  This problem is made deeper because it requires PDP-8 
support code for the Z80 and Z80 instruction loading by PDP-8, etc.)

It also supports an internal version of the DEC "Scholar" modem for 
300/1200.  No great shakes, but normal for 1984.  It is conceivable that 
the modem slot can support a better serial port.  (Note: standard 
equipment also includes a serial port for the printer and a USART 
interface to any external serial device, etc.  These are *not* part of 
this option!)

Now, to answer the basic question:  Try plugging in a DEC keyboard.  The 
thing just wants a functioning keyboard which it interrogates for being 
both present and working.  Clearly this is not the case presently, or 
someone busted the keyboard, etc.  Check to see if the 4 LED's on the 
keyboard start off, then on, then off.  Sometimes, a broken keyboard has 
them all stay on.  Likely one of the internal keyswitches is stuck on 
from a previous fall, etc.

As anyone with a working DECmate II,III, III+ can demonstrate, pulling 
the keyboard causes 16 to appear.  Merely plugging it in makes the error 
go away and advances it to the end of the self-test so it says "DECmate" 
and beeps.  After that, it will then attempt an actual boot to the 
floppy.  Errors at that point cause a giant hack picture of a blinking 
floppy to appear.  But if you leave out a diskette, the "DECmate" message 
just stays there.

cjl



