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: 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: NNTP-Posting-Host: minsk.docs.uu.se In 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: NNTP-Posting-Host: sunsite.unc.edu In article , Megan 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 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: <2g9fcp$aqa@corax.udac.uu.se> NNTP-Posting-Host: sunsite.unc.edu In article <2g9fcp$aqa@corax.udac.uu.se>, Johnny Billquist 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 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 ..... 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 ..... 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 ..... 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: <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 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 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 wrote: >In article <1994Jan5.083414.15937@lugb.latrobe.edu.au>, >Huw Davies 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: <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 wrote: >lasner@sunSITE.unc.edu (Charles Lasner) writes: > >>In article <2g9fcp$aqa@corax.udac.uu.se>, >>Johnny Billquist 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: <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 wrote: >>lasner@sunSITE.unc.edu (Charles Lasner) writes: >> >>>In article <2g9fcp$aqa@corax.udac.uu.se>, >>>Johnny Billquist 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: <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 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: <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 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 References: <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 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 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 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: 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 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: <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 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: NNTP-Posting-Host: sunsite.unc.edu In article , Bob Armstrong 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 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: <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 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: Organization: Computer Sciences Corporation References: 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 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: <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: <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>, 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: <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 , Bob Armstrong 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: <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: <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>, 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: <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>, 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: <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>, 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 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" 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 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 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>, 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" 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: 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> 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 (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> NNTP-Posting-Host: sunsite.unc.edu Keywords: ignorant about DECmate error_16 In article , Randall Raemon 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 (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