From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Mar 1 20:10:07 EST 1993 Article: 175 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Why a DECmate isn't a PDP-8 Message-ID: <1993Mar1.183956.10266@news.columbia.edu> Keywords: DECmate PDP-8 (not!) Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Mon, 1 Mar 1993 18:39:56 GMT This newsgroup is primarily for PDP-8 family stuff, and will therefore support DECmates as well. But a DECmate isn't *quite* a PDP-8 as we know it. Certain problems thwart the prevailing software from running on it, and instead some "bastardized" versions have appeared (such as OS/278). This will be the first in a series of articles to detail the areas of incompatibilty and what can be done about them. 1) CPU issues. The DECmate is based on the 6120 micro version of the PDP-8. It is mostly compatible, and includes the powerful extension of CP memory and related hardware, dual push-down stacks, etc. Certain instructions have minor differences such as the exact definitions of the PDP-8/e-originating superset instructions GTF and RTF. The differences are so slight that the existing software for PDP-8/e interrupt handling will just work, but certain diagnostic programs will likely fail on these specific points. There are differences such as: PDP-8/e RTF does not clear the AC afterwards; 6120 does. This is even a useful improvement as there is no software reason not to clear the AC at that point. (The AC is being loaded from a temporary to restore the former status saved during an interrupt. Then the AC has to be loaded with the former AC value, thus a CLA after RTF is in all practical 8/e code. The RTF performing its own clear thus allows a 6120-only interrupt handler that is shorter/faster.) PDP-8/e GTF reads back the state of interrupt into bit[4]. PDP-8/e RTF ignores bit[4] and re-enables the interrupt. 6120 GTF reads back a one into bit[4]. 6120 RTF loads interrupt enable per AC[4]. For normal interrupt handling for PDP-8/e, this sequence is essentially compatible enough. Note that classic PDP-8 interrupt handling is totally compatible on all models, but that there are PDP-8/e and newer interrupt routines, etc. The use of extended memory instructions on the PDP-8/e is compatible with former processors, but can be extended via the KT8A or CESI MEC8 extensions. The 6120 is only compatible with the subset found on the PDP-8/e without those extensions because other instructions have been assigned to the same IOTs. These include new instructions such as GCF (Get Current Fields) which is essentially the non-interrupt-oriented version of GTF, etc., and a set of instructions only valid in CP memory to handle that section. Some of the instructions are defined for CP memory trap, and others are for manipulating the built-in dual stack. As long as the program sticks to the compatible subset found in a 32K PDP-8/e, the instructions are otherwise compatible. 2) Console issues. On I/O, the 6120 largely parts company with the PDP-8/e. The actual implementation of I/O on the DECmate consists of using packaged interfaces usually called "pie" chips (or Programmed Interface Elements). The problem with these chips is that they are only *almost* compatible with existing PDP-8 interfaces whereas the prevailing OSes demand *total* compatibility with the older hardware. There are several internal interfaces within the DECmate for particular use of no concern to the OS, and this is not at issue, such as the internal interface for the keyboard which is actually on an additional serial port (bidirectionally) or the APU/XPU interface, etc. PDP-8 compatibility demands that the device 03/04 instructions be truly compatible. On the 6121 PIE chip, liberties were taken with the design that cause out-and-out incompatibility such that only trivial programming examples still work, while the actual usage within the operating system is totally incompatible. A breakdown of the console instructions: 6030 Clear the keyboard flag, do not advance the reader if a TTY: is the console device, do not clear the AC. The 6120 version of this is to *set* the flag! (This instruction is not used on earlier models, so compatibility issues aren't as bad as it sounds!) 6031 Skip on the keyboard flag. Notably, the PDP-8 convention is that this instruction work *precisely* as stated. Specifically, 6031 must skip if the flag is set. Repeating the instruction must repeat the same effect. On the 6120, 6031 executes as skip on *and clear* the flag, thus 6031 when repeated is totally incompatible, because the flag won't raise until the data is read. PDP-8 OS compatibility demands that the 6031 repeat facility be present. Without this, various programs, handlers, and all BATCH operations are incompatible. OS/278 consists of a bunch of wimpy emasculated versions of cusps that either don't work properly, have existing bugs to be fixed, or kludges to create the perception of ^C and/or ^S/^Q handling being present correctly, but in point of fact, it is 100% deficient in this area. When OS/278 is run on an actual PDP-8, it behaves as poorly since it can't take advantage of the proper console interface, instead sticking to the subset where 6031 cannot skip repeatedly, etc. 6032 Clear the AC, advance reader run if a TTY: console, clear the keyboard flag. On the 6120, 6032 merely clears the AC. Since 6031 clears the flag, they didn't bother to make 6032 accomplish it. However, 6032 on the 6120 will allow the flag to raise for the *next* character since the interface is both buffered and simulated. Due to hardware limitations of the DECmate, it is not possible to re-implement the simulated console interface any better than currently provided. The base reason for this is that only the "even" IOT's are trapped and emulated while the "odd" IOT's are allowed to be used in hardware. Had the entire interface been trapped, we could emulate the compatible version! 6033 NOP This IOT is essentially reserved for situations where the interface baud rate could be programmed, but doesn't apply in the case of either the PDP-8 or the DECmate. 6034 Read the latest character, do not disturb the flag. The data is logically ORed into the AC. This is used to notice that the data is a ^C or other character without disturbing the flag, so that other software can check it again, after being swapped in. (It's used in conjunction with 6031 which doesn't clear the flag when it skips.) The 6120 version of this instruction is to OR into the AC the *previously read* character provided by either 6032 or 6036, but it cannot initiate a new character by itself. While it is of marginal utility to be able to re-read a previously read character, the inability to read in the latest character without disturbing the flag is the crux of the compatibility issue. 6035 Load interrupt enable for devices 03/04 per AC[11]. On the 6120 this is changed to device 03 only. The 04 function is handled by 6045. Since this is a PDP-8/e instruction, it is not a serious compatibility issue except for initialization routines that use interrupts. However, since the keyboard is emulated on the DECmate, interrupt timings may prove "choppy" compared to a real PDP-8, and interrupts to the console are not recommended. 6036 LOAD the AC with the latest character and clear the flag. Also enable reader run if the console is a TTY:. Essentially this is the OR of 6032 and 6034. The 6120 still ORs together the two operations, but the underlying two operations aren't compatible, since the flag is unaffected. However, reading the character will cause the next character's flag to raise (when available). If 6032 or 6036 is not executed, then the flag will *never* raise even if the user pounds on the keyboard! (There is an OS/278 ODT bug related to this which is fixable per se, but not the ^C handling as described above.) 6037 NOP 6040 Set the output flag. Actually compatible on 6120! (And not needed for compatibility with earlier machines that didn't have it.) 6041 Skip on output flag. Like the input flag, the 6120 also clears the flag when issuing 6041. There is less of a compatiblilty issue since it is possible to write code that doesn't depend on the second skip, as long as you time out the flag in any initialization code. (P?S/8 has always done this in the past; OS/8 tends to not overlap the console I/O so therefore the skip on flag gets checked after outputting not before, so this is good enough for most routines.) 6042 Clear the output flag. On the 6120 it clears the AC. Usually the AC contents is unimportant during 6042, so not a serious compatibility issue, but diagnostics will fail. 6043 NOP 6044 Output the character, do not clear the flag. Same on 6120, but since the output routine is emulated, the flag will immediately be up when the program is running after the trap. On a real PDP-8, the flag comes up one character time later after it's actually sent, not immediately. This could affect some interrupt routines. Again, interrupt handling of the console is not recommended on the DECmate, especially on the output side. 6045 On the PDP-8/e, this is skip on input OR output flag raised AND interrupt enable in the device. Useful to cause interrupt polling routines that have to favor other devices to have less overhead. If the device actually has the flag raised, then you have to do a few extra instructions, but when the interrupt is elsewhere, it lowers the latency. On the 6120, this is replaced with load interrupt enable for device 04 only per AC[11]. Since this is an extension beyond the basic interface, this is a compatibility issue for interrupt-driven PDP-8/e and newer routines only. 6046 Output the character and clear the flag now, causing it to raise later. On the 6120, the instruction is trapped, so the net result is to raise the flag when the trap handling is over and execution resumes. Causes interrupt routines to always be entered and no background processing to occur during the simulated interrupt handling, which is not recommended. Non-interrupt programming is not affected by this aspect of compatibility however. 6047 NOP So, in summary, console handling is severely incompatible with regard to keyboard handling, and moderately incompatible for screen handling, most notably in regard to either flag initialization and/or interrupt handling. Yet, simple-minded examples from Introduction to Programming will more-or-less work; "live" OS routines cannot work. I am working on a replacement system to be known as OS/8 Version 5, which will work within the available subset and thus will run on all models. However, existing OS/8 cannot work on the DECmates, and OS/278 cannot perform many functions found in OS/8. Next time, more info on other compatibility issues. cjl From news.columbia.edu!sol.ctr.columbia.edu!caen!msuinfo!uwm.edu!cs.utexas.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!bnr.co.uk!uknet!reading!eastwood!ssusgree Mon Mar 1 20:11:01 EST 1993 Article: 176 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!caen!msuinfo!uwm.edu!cs.utexas.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!agate!doc.ic.ac.uk!pipex!bnr.co.uk!uknet!reading!eastwood!ssusgree From: ssusgree@csug.cs.reading.ac.uk (S. G. Green) Newsgroups: alt.sys.pdp8 Subject: Re: Old Iron at home - PDP-11 Message-ID: Date: 1 Mar 93 18:13:46 GMT References: <1mchsuINN3oi@srvr1.engin.umich.edu> Sender: news@csug.cs.reading.ac.uk Reply-To: ssusgree@csug.cs.reading.ac.uk Organization: Dept. of Comp. Sci., University of Reading Lines: 23 Nntp-Posting-Host: eastwood Well, I've got what claims to be a DEC "micro" PDP-11 lying around at home. It's about the size of a large upright suitcase. It's got about 18 seperate RS232 sockets for terminals, a couple of line printer sockets, some buttons and flashing lights and a mysterious slot which I assume is some sort of tape drive. I managed to get it up and running with a dumb terminal, and it appears to be running some bizzare operating system called RT-11. From what I could figure out, it's got a 500Mb hard disk. Wow. It makes an impressive amount of noise when you power it up, too. Can anybody tell me anything about this machine ? Is there anywhere I can get software (PD or otherwise) for it ? Any ideas what I could use it for apart from as a piece of furniture ? Thanks, Si Green. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ |teeveevideojpegmpegdiscretecosinetransformslzwdecpdp11 Simon Green thisisasp| |amigagigerescherdalgibsonsterlingbankswatchmencellular E-mail him: acethisis| |automatafractalcompressionmandelbrotlyapunoviavirtualr ssusgree@susssys1.rdg| |ealityat80millionpolygonspersecohshitmybrainsexploding aspacethisisas .ac.uk| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!bogus.sura.net!udel!apache.dtcc.edu!apache.dtcc.edu!not-for-mail Tue Mar 2 01:49:29 EST 1993 Article: 177 of alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!bogus.sura.net!udel!apache.dtcc.edu!apache.dtcc.edu!not-for-mail From: chuck@apache.dtcc.edu (Chuck Whealton) Newsgroups: alt.sys.pdp8 Subject: Re: Old Iron at home - PDP-11 Date: 1 Mar 1993 23:19:29 -0500 Organization: Delaware Technical & Community College Lines: 28 Message-ID: <1mun8hINN40@apache.dtcc.edu> References: <1mchsuINN3oi@srvr1.engin.umich.edu> NNTP-Posting-Host: apache.dtcc.edu In article ssusgree@csug.cs.reading.ac.uk writes: >Can anybody tell me anything about this machine ? >Is there anywhere I can get software (PD or otherwise) for it ? > >Any ideas what I could use it for apart from as a piece of furniture ? Wow... Sounds pretty neat! I don't know much about the PDP's at all even though I've got my own MicroPDP 11/23+ sitting in the closet that I need an OS for. I do know that you can get software for it by checking through the DECUS catalog. Unfortunately, all I have is the catalog and none of the other DECUS information... However if you dial the order number they might be able to give you the *CORRECT* number for joining (it's currently free). The number is (508)841-3500 and the address on the catalog is... Digital Equipment Computer Users Society 333 South Street, SHR1-4/D33 Shrewsbury, MA 01545-4195 I hope this helps and if somebody has the correct number/address to get ahold of DECUS at to join, please post it for this person... Chuck From news.columbia.edu!sol.ctr.columbia.edu!eff!world!mbg Tue Mar 2 13:46:29 EST 1993 Article: 178 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!eff!world!mbg From: mbg@world.std.com (Megan B Gentry) Subject: Re: Old Iron at home - PDP-11 Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <1mchsuINN3oi@srvr1.engin.umich.edu> Date: Tue, 2 Mar 1993 16:02:13 GMT Lines: 43 ssusgree@csug.cs.reading.ac.uk (S. G. Green) writes: >Well, I've got what claims to be a DEC "micro" PDP-11 lying around at home. >It's about the size of a large upright suitcase. It's got about 18 seperate >RS232 sockets for terminals, a couple of line printer sockets, some >buttons and flashing >lights and a mysterious slot which I assume is some sort of tape drive. That sure sounds like a strange beast, doesn't sound familiar >I managed to get it up and running with a dumb terminal, and it appears >to be running >some bizzare operating system called RT-11. From what I could figure out, >it's got a 500Mb hard disk. Wow. It makes an impressive amount of noise >when you power it up, too. Excuse me, RT-11 is not Bizarre (I was a developer of it for fifteen years). 500mb drive?! Wow. Keep in mind that RT can only access disk volumes up to 32mb at a single time. If it is an MSCP device, you'll have to use something called 'partitioning', which is built into the MSCP device driver. >Can anybody tell me anything about this machine ? Boot the system and issue the command 'show configuration' and send me the results, I'll be able to tell what you have... >Is there anywhere I can get software (PD or otherwise) for it ? DECUS (Digital Equipment Computer User's Society) is a good place for all sorts of software for PDP-11's, although it's not like going to CompUSA and getting a copy of Quicken ... >Any ideas what I could use it for apart from as a piece of furniture ? If you get to the point of wanting to use it as furniture, drop me e-mail and I might take it off your hands. Megan Gentry former RT-11 developer p.s. The pdp-11 newsgroup you could also try is vmsnet.pdp-11 From news.columbia.edu!rpi!usc!cs.utexas.edu!hellgate.utah.edu!cc.usu.edu!ivie Wed Mar 3 15:47:37 EST 1993 Article: 179 of alt.sys.pdp8 Path: news.columbia.edu!rpi!usc!cs.utexas.edu!hellgate.utah.edu!cc.usu.edu!ivie From: ivie@cc.usu.edu (CP/M lives!) Newsgroups: alt.sys.pdp8 Subject: Re: Old Iron at home - PDP-11 Message-ID: <1993Mar3.110931.64722@cc.usu.edu> Date: 3 Mar 93 11:09:31 MDT References: <1mchsuINN3oi@srvr1.engin.umich.edu> Organization: Utah State University Lines: 19 In article , mbg@world.std.com (Megan B Gentry) writes: > ssusgree@csug.cs.reading.ac.uk (S. G. Green) writes: > >>Well, I've got what claims to be a DEC "micro" PDP-11 lying around at home. > >>It's about the size of a large upright suitcase. It's got about 18 seperate >>RS232 sockets for terminals, a couple of line printer sockets, some >>buttons and flashing >>lights and a mysterious slot which I assume is some sort of tape drive. > > That sure sounds like a strange beast, doesn't sound familiar Sounds like a Micro PDP-11 in the floorstand box with a TK25 or TK50 tape drive. Not all that strange. -- Roger Ivie "My God! That computer is full of Pentium! ivie@cc.usu.edu It's a wonder that you haven't been turned into mutants!" From news.columbia.edu!rpi!gatech!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!not-for-mail Sat Mar 6 02:21:14 EST 1993 Article: 180 of alt.sys.pdp8 Xref: news.columbia.edu vmsnet.pdp-11:838 alt.sys.pdp8:180 Path: news.columbia.edu!rpi!gatech!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!not-for-mail From: locicero-joe@yale.edu (Joe LoCicero) Newsgroups: vmsnet.pdp-11,alt.sys.pdp8 Subject: Help for a Newcomer Date: 6 Mar 1993 01:31:57 -0500 Organization: Yale University Science & Engineering UNIX(tm), New Haven, CT 06520-2158 Lines: 49 Distribution: world Message-ID: <1n9ggtINN16v@MINERVA.CIS.YALE.EDU> NNTP-Posting-Host: minerva.cis.yale.edu Well, folks, I managed to do it. After using a PDP 11/44a for a number of years during grammar school (hope I don't make too many of you feel too old) :-) But seriously... I just got (out of the school's dumpster) a PDP-11/23 with 2 RL01s, what looks like a home-spun (but I'm probably wrong) RX01/02, some sort of peripheral bus, and a whole shebang of RL01 platters. Disks labled RT-11 were left in the 8" drives. RL01 packs labled various things. So, before I try and hook the thing up and turn it on, a few questions: 1) Is there a FAQ for people such as myself who need some help starting up a system like this? (It's been a while since I've even seen the Orange wall.) 2) Is there a list somewhere of what these Mxxxx boards that fit in the backplane do? I'd like to be able to mix & match about 20 of these boards that are lying here 3) There is also (sitting in a less conspicuous place) a pair of RX07 drives with platters that read VAX/VMS Diagnostics (Jul. 86), an RX611, and a BA11E, amongst a digital corp. printer from 1961 or something :). Can these be used with the PDP-11/23? ` 4) Can I get a hold of some useful utilities if they aren't on the platters easily (eg TECO, Basic Plus, & so on)? I'm sure that this will be a continuing saga, and this is only Chapter 1... but I feel that these new types that think the first computer was the Apple //e need to learn what REAL computers were like, and I'm going to prove that the PDP-11 systems were actually quite useful! ( I even have some old listings that I could try to use, but they are in PASCAL - must find that first... ) Thanks in advance! Hope this will be the beginning of a new friendship... or the rebirth of one! ;-) -- --------------------------------------------------------------------- -Joe LoCicero locicero@minerva.cis.yale.edu - --------------------------------------------------------------------- From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!bogus.sura.net!jhunix.hcf.jhu.edu!fmsrl7!lynx.unm.edu!umn.edu!staff.tc.umn.edu!lemay Sat Mar 6 20:41:00 EST 1993 Article: 181 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!bogus.sura.net!jhunix.hcf.jhu.edu!fmsrl7!lynx.unm.edu!umn.edu!staff.tc.umn.edu!lemay From: lemay@staff.tc.umn.edu (Lawrence LeMay) Subject: PDP8 M8655 and M7856 Message-ID: Sender: news@news2.cis.umn.edu (Usenet News Administration) Nntp-Posting-Host: staff.tc.umn.edu Organization: University of Minnesota Date: Sat, 6 Mar 1993 16:56:30 GMT Lines: 4 I found a few M7856 interfaces. They seem to be somewhat similar to the M8655 terminal interface i also have, but i was wondering what the differences are... I'm sure someone has the answers... From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Mar 6 22:07:38 EST 1993 Article: 182 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Why a DECmate isn't a PDP-8 Message-ID: <1993Mar7.030555.20287@news.columbia.edu> Keywords: DECmate PDP-8 (not!) Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar1.183956.10266@news.columbia.edu> Date: Sun, 7 Mar 1993 03:05:55 GMT This is the second in a series of posts about why the DECmate series of small computers is not quite what we know as a PDP-8. Part one dealt with the few minor CPU issues and detailed the significent differences in the console interfaces between all PDP-8 (and VT-78) models and the DECmates. 2a) Consequences of the console problems and what to do about them. Since the console interface is hopelessly "mangled" we have to learn to live with it. Existing PDP-8 programs designed for the various OSes will have to be either supported as is or be changed for DECmate and PDP-8 use. P?S/8 has already undergone a console "overhaul" such that all system programs can now be run on any model of PDP-8, VT-78, PDP-12, or DECmate. (The family of 8 rule applied to P?S/8 as well as OS/8, thus neither will run on a PDP-5 or PDP-8/s.) To accomplish a compatible console interface compromise, the following rules were laid down: If a program is meant to strictly run on a PDP-8 or VT-78 only, then it can assume the old-style console interface exists. Thus, *only* on a PDP-8 can the following code or equivalent be used: KSF /FLAG UP? JMP NOT /FORGET IT KRS /READ IT IN NOW; DON'T DISTURB THE FLAG AND (177) /GET RID OF PARITY BIT TAD (-3) /COMPARE TO ^C SZA CLA /SKIP IF IT MATCHES JMP CLRIT /JUMP IF OTHER / DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC. JMP I (7600) /KEYBOARD MONITOR WILL NOTICE THE ^C CLRIT, KCC /CLEAR THE FLAG WE NOTICED ON OTHER THAN ^C NOT, CLA /CONTINUE PROCESSING; NO ^C PRESSED This code is applicable to OS/8 and P?S/8, but only on PDP-8's, not DECmates. The changes to the keyboard monitor of either system has to still include the check for ^C by noticing the KSF skips, execute KRB and check if the character is ^C and take the appropriate action, etc. Note that the pre-DECmate P?S/8 and all pre-V4 OS/8 family systems essentially worked this way, etc. To function on the DECmate, P?S/8 was modified so that there is a new system concept: the "soft ^C" bit. In this specific case, it was defined as bit[11] of the memory size word in 007611 to facilitate being set with an ISZ instruction, etc. Here is a reworked piece of code that can function only on the newly reworked P?S/8 system: KSF /FLAG UP? JMP NOT /FORGET IT KRB /WE MUST READ THE CHARACTER IN AND (177) /GET RID OF PARITY BIT TAD (-3) /COMPARE TO ^C SZA CLA /SKIP IF IT MATCHES JMP NOT /JUMP IF OTHER / DO WHAT'S NEEDED HERE, SUCH AS SET THE DF TO 00, ETC. ISZ I (7611) /SET THE "^C WAS HIT" BIT JMP I (7600) /KEYBOARD MONITOR WILL NOTICE THE ^C The keyboard monitor in this case won't have a skipping KSF, but since it also examines bit[11] of 007611, it will notice the abort that way. Thus, we have an equivalent of the original code that works on either PDP-8 or DECmate hardware, but only under the new operating system. This code has an additional advantage: certain applications run from an alternate device where a user abort can occur, such as another terminal on other than devices 03/04, etc. This could be a serial printer with a keyboard, or a graphics terminal, etc., where it could be desirable to write an application that would have the option of user abort from this alternate device. The program can check for its local abort condition and exit as the replacement console routines would above, thus logically extending the operation to the alternate device. OS/8 requires modification to allow a similar abort exit that is as generic. The keyboard monitor will have to be made sensitive to a new bit, as well as responding to a skipping KSF/KRB combination that detects ^C, which will allow compatibility with older programs, but only if the hardware is actually a PDP-8 or VT-78, etc. The current candidate is 007601, which is the function word in OS/8's memory save routine that is initiated in 007600. The breakdown of that word is: 1 0 1 0 0 0 0 0 0 0 0 0 ^______________________ Indicates this call is a write function ^ ^ ^ ^ ^ ___________ Indicates that 8 pages should be written out ^ ^ ^ Indicates that field 00 is to be used ^ ^ ^ These bits are usually undefined The use of bits[9-11] of the function word of OS/8 are not defined for any file-structured device with a minor exception: bit[11] being set is optionally to be set for the benefit of the existing DECtape/LINCtape handlers to indicate that the caller believes that there is less overhead directing the handler to initiate searching for the requested block in the forward direction, whereas the default is to search backwards. Statistically, most searches ought to be initiated backwards on these devices because it is likely that the next tape transfer is contiguous to the previous one. However, once the latest transfer is completed, it is impossible to restart another transfer without backing up the tape because the latest block has already partially gone by. Thus, in practice, the only calls that can benefit are those where the caller needs widely spread out information stored on known blocks that are futher apart than the overshoot factor of the tape (typically 2-3 blocks must be skipped to make use of an additional forward transfer; the DECtape copy program makes use of this feature by only copying half the tape deliberately skipping over many blocks, and then copying only the previously skipped blocks while spinning the tape in the reverse direction skipping over the previously copied blocks.). In actual fact, there are only a small handful of static calls within OS/8 that are made with this bit set, due to the design of OS/8 lacking much need for the feature of search direction override; the usual OS/8 component isn't forward of the previously read in component, etc. Thus, while a useful feature in principle, not much of OS/8 sets the bit because in the static sense, there isn't too much that can be done to predict this situation. Actually, this is unfortunate, since in the dynamic sense, there are quite a few more situations where the actual call could have been made more efficiently had the handler been aware of the circumstances which were not told to the handler. In P?S/8, the OS tells the handler nothing at all in this regard, yet overall performance is noticeably better. Part of the reason for this is that in P?S/8 DECtape handlers, the handler is internally responsible for maintaining the current position of the tape. Any call will be used to determine whether to search forward or backwards based solely on the current tape position info obtained from the previous call to the handler. Years ago I wrote such a handler for OS/8 that ignores bit[11] in the function word and instead maintains this "dead reckoning" on its own. If interest is warranted, I can locate this code and make it available to the user community. (It is not an exact knee-jerk "clone" of the standard OS/8 TC01/08 DECtape handler as there are design philosophy differences on other issues as well, but IMHO any user would appreciate the differences and would prefer my handler to the standard one.) In any case, it is clear that the following handlers are up for consideration: TC01/08 system and non-system handlers. TD8E system and non-system handlers and the TD8E MR-8EC ROM system handler. PDP-12 LINCtape handler LINC-8 LINCtape hander for a modified LINC-8 and the non-system handler. Also the 12K system handler for an unmodified LINC-8 and a possible two-page handler for use as a non-system handler on original hardware. The TC01/08 system consideration was outlined above. The TD8E system handler is also written to obey this bit. Among other considerations already implemented in P?S/8 is the same optimization for search direction on this hardware. It is likely that both the system and non-system handlers can be made similarly "smarter". The ROM-based system ignores the bit. The PDP-12 hardware is too complicated to allow the OS/8 handlers to deal with the bit, so all transfers are made starting with a reverse search. It is conceivable that the LINC-8 handlers can be made similarly smarter; the modified LINC-8 hardware includes helpouts to the handler for P?S/8 to accomplish this already, but it isn't clear that the non-system handler for an unmodified machine can accomplish this in less than two pages. In any case, it would appear that an adequate job can be done to eradicate the need for this bit in OS/8 completely. The worst-case consequence of the bit is that the call to save memory during the exit via 007600 would involve a transfer initiated with a forward search. (And it's conceivable that this might even be the proper thing to do!) There are no other OS/8 handlers that pay attention to this bit. (Note, there are non-file-structured devices that use these bits; this is irrelevant!) So, a replacement console routine for OS/8 Version 5 would be the same as the P?S/8 example, except that the location being incremented would be 007601, not 007611. The OS/8 keyboard monitor would have to be made sensitive to bit[11] of 007601 as well as the case of the KSF/KRB skip of a ^C but only on PDP-8 hardware. Thus, a replacement OS/8 system can be built for use on PDP-8's or DECmates, but every system program that requires DECmate application must be upgraded to the new standard. Along the way, some other issues will be addressed, such as creeping model dependencies, which must be eliminated to allow one system version to run on all of the machines it ought to, which is not currently the case in OS/8. (P?S/8 already has accomplished this: you can carry a single RX01-type 8" floppy disk to any appropriately configured machine all the way from a classic 1965 PDP-8 through a DECmate II and boot that very same disk on any of the machines.) Next time, more DECmate-specific quirks that impede compatibility due to other problems, etc. cjl From news.columbia.edu!watsun.cc.columbia.edu!lasner Sun Mar 7 10:46:33 EST 1993 Article: 183 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Why a DECmate isn't a PDP-8 Message-ID: <1993Mar7.154536.11591@news.columbia.edu> Keywords: DECmate PDP-8 (not!) Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar1.183956.10266@news.columbia.edu> <1993Mar7.030555.20287@news.columbia.edu> Date: Sun, 7 Mar 1993 15:45:36 GMT This is the third in a series of posts about why the DECmate series of small computers is not quite what we know as a PDP-8. Already covered are the minor CPU issues, and the significent differences in the console interfaces between all PDP-8s and all DECmates, and what can be done about these particular consequences, etc. 3) Disk issues. Systems such as OS/8 and P?S/8 have to be configured for whatever machine-specific disk environment they run on, so in theory, this aspect of compatibility shouldn't be an issue. However, there are some problematic compatibility details anyway. The DECmate I is essential compatible on this issue, as the boot device of the DECmate I is either an RX01/02 or an RL02. The only actual difference between the DECmate I RX interface and a PDP-8 version is that the VT-78-style interface is present, i.e., the software has to deal with the potential of two pairs of RX drives. This is controlled by the SEL IOT (6750) which is defined as: load pair select per AC[11] where 0=the drive pair found on the PDP-8 and 1=the optional pair found only on the VT-78 or DECmate I (VT-278). Some system handlers for RX do not include the SEL instruction to ensure this condition, but it is the default state of the machine. All software, such as the non-system handler to access the second pair, is responsible for resetting the select line to ensure the proper functioning of the system handler; it is likely that certain, but not all, existing system handlers for RX usage will be so tightly coded that this convention must be obeyed, since this is another tradeoff of features and performance versus handler space that could not have been anticipated by the authors of these handlers. There are user-written RX handlers to accomplish such things as byte-mode transfers to gain back 33% more disk space over the standard DEC 12-bit mode. There are also handlers to allow for accompishing this with/without the use of the otherwise wasted space on track 0, and also to mimic the disk layout of COS and/or WPS to allow conversion programs such as WPFLOP to function. Still others are designed to be able to boot a byte-mode system so that the system device also benefits from the additional space, etc. There also exists a set of handlers for use on RT-11-style disk layout to gain faster throughput as well. The overall point here is that there has been a lot of RX work provided by the user community seeking performance beyond what little DEC has provided. By switching the "rules" and requiring the software maintain yet another item of "housekeeping" compromises these handlers yet further. (Even in 12-bit mode, it is impossible to accomplish all of the requirements of an RX handler in only two pages, the OS/8 upper limit. There exists an analogous handler for P?S/8 usage, which requires three pages; P?S/8 allows handlers up to 32 pages long. Thus, any two-page handler is compromised in some way, usually in the area of error recovery or performance, possibly only affecting certain models, etc.) The DECmate II complicates this issue further. On this specific machine, the RX-78 option allows for one or two pairs of RX01/02 (and at the same time prevents the RD51D hard disk option; you can either have one pair of RX50 and a hard disk or up to eight floppies implemented as two pairs of RX01/02 and two pairs of RX50). However, the selection interface of the DECmate II is incompatible with that of the VT-78 and DECMate I, and requires several more instructions to provide compatible selection with the prior models. Thus, all existing user-written and older DEC-provided handlers cannot run on the DECmate II. Only those that can be modified slightly can be made to run on this hardware (which is somewhat more difficult presently than necessary; see below). This issue is complicated further by a specific design "philosophy" of OS/278: In OS/8, the RX done flag is used as a status indicator. Assuming no interrupt enabled (or the RX device interrupt is specifically disabled; this is in the province of any interrupt-driven program designed for the machine, etc.) the done flag being up is used as an idle status indicator. The reason for this is that a handler can never know the current status of the drives when it is called; there could be a system reset in progress, which takes up to five seconds to complete. The convention for the handlers is to assume that you should wait for the done flag to raise, since it's already up or will be up (eventually) at which time you should proceed with the main work of the call. Handler exit is accomplished by executing an innocuous function that cannot fail (such as READ ERROR REGISTER) and then exiting without waiting for the function to complete. (The problem is that to test the done flag is to clear it, since the relevant IOT (SDN) is Skip on DoNe set, clear done flag.) Thus, the hardware is now in a favorable state for the next caller. Should a power-clear condition occur at some point, the handler will have to wait for up to five seconds, but can otherwise proceed, etc. When OS/278 was introduced, the new designers revised this convention. Under OS/278, the RX done flag is always assumed to be clear. This sometimes causes handlers to fail, or at the least go through some error recovery cycles before accomplishing the requested handler calls, etc. There exists some user programs that make the system crash when run from an OS/278 floppy, while functioning correctly when run from an OS/278 hard disk volume! All of this is traceable to bad interaction with the new convention. To operate under this convention will add an undue burden to the handlers written by the user community, and it isn't necessary. I have already written P?S/8 handlers that work perfectly fine under the original flag convention on the DECmate II hardware. (I have created a "bootable" RX01/02 P?S/8 system. Since the hardware of the DECmate II can only boot to an RX50 or hard disk volume, it is necessary to first boot to the RX50, then run a "re-boot" program to bring up the RX01/02-based P?S/8, which is meant to be booted directly on a PDP-8 or VT-78 or DECmate I, etc.) OS/8 version 5 will restore the original convention, and thus will require rewriting the DEC-style handlers accordingly. However, all user-written handlers will function as intended, i.e., will function only on the PDP-8 system they were designed for. If possible, all handlers should be modified to be compatible with the restrictions of all of the machines. (Some of the specific requirements are: 1) Must be able to have decent throughput on the slow VT-78; this is often not the case, especially on writes. 2) Must be able to support the SEL hardware of the VT-78/DECmate I, and preferably the DECmate II. 3) Should have decent error recovery if possible. In general, it's impossible to have all of this, especially if the format involves the use of byte-mode transfers, and the format is single density, thus requiring checking for the possibility of performing byte-mode single density transfers on RX02 as opposed to RX01 which programs slightly differently in this mode, etc.) In any case, the user-community software investment in RX utility will not go to waste. In the case of the DECmate I, there is only one consideration: the RL8A controller allows for the ability to support existing software for RL01 or RL02, but not both. There exists a support jumper on the RL8A hardware that prevents some unforeseen consequence from occuring regarding the bit normally used in the RL02 for additional seek cylinders, etc. Apparently, the jumper has to be set so that the hardware isn't subject to a mis-set bit in the software. Several theories exist as to what the proper setting of this bit is, that the hardware provides to the drives, etc. Possible examples are: 1) always one. 2) always zero. 3) Sign extension of the bit immediately to the right of this bit. 4) some form of parity. In any case, RL01 software doesn't maintain any consistent usage of this bit, so the hardware jumper is used to maintain compatibility. When the RL02 is used, the software correctly uses this (extra) bit. Thus, mixed systems of RL01 and RL02 are not allowed. In theory, if/when we find out what this bit setting is, we can possibly modify all of the RL01 software to support an RL01 in a controller where the bit is set for full RL02 support, similar to the existing PDP-11 support currently. In any case, RL8A users cannot currently mix RL01 and RL02 drives. The DECmate I RL-278 controller apparently lacks this jumper altogether, thus only allowing RL02 drives, until the software clean-up described is implemented. In the case of RL02 software specifically, the DECmate I is fully compatible. (This does assume that the software is *otherwise* compatible, such as with the DECmate console interface or CPU differences!) On the DECmate II, III, III+, new software has to be written for the RX50, since the DEC-provided OS/278 handlers instigate the above-mentioned flag incompatibility. This should prove as difficult as modifying the user-written handlers, etc. DECmate II and III+ hard disk volume software is essentially acceptable, up to a point, since this is the province of these machines only. Next time, problems of the RX50 and hard disk volume software not covered yet. cjl From news.columbia.edu!watsun.cc.columbia.edu!lasner Thu Mar 11 12:14:18 EST 1993 Article: 184 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Why a DECmate isn't a PDP-8 Message-ID: <1993Mar11.164558.26719@news.columbia.edu> Keywords: DECmate PDP-8 (not!) Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar1.183956.10266@news.columbia.edu> <1993Mar7.030555.20287@news.columbia.edu> <1993Mar7.154536.11591@news.columbia.edu> Date: Thu, 11 Mar 1993 16:45:58 GMT This is the fourth in a series of posts about why the DECmate series of small computers is not quite what we know as a PDP-8. Already covered are the minor CPU issues, all aspects of the problems of the incompatible console interfaces, and some specific issues about RL and RX01/02 drives, especially as it relates to the goals of the replacement OS/8 Version 5 system which will unify the entire family of 12-bit machines, etc. 3a) Disk problems on the DECmate II, III, III+. The bootable devices for the DECmate II, III, III+ machines are the RX50 for all models, and the RD51D hard disk for the III+ and II with hard disk option. The RX50 always takes precedence over the hard disk if mounted/ready. RX50 diskettes may be mounted in the drive, yet the machine will boot to the hard disk, if the diskette is determined to be non-bootable by the system ROM. If the hard disk is also determined to be non-bootable, then the machine will hang waiting for the problem to be corrected (presumably on the RX50 drive). (Some early versions of boot ROM's have bugs such that you have to turn the machine off and on to recover from this.) The RX50 convention for boot viability is fundamentally incompatible with the aims of OS/8! OS/278 has been partially emasculated to prevent certain of the commands that are problematic, or alternatively, the commands have been left in, and instead warning messages are issued to indicate to the user that the system has been destroyed! The casual user of OS/278 may not have encountered this phenomena, but it most certainly does happen, and is even partially documented in the release info for OS/278 version II. In essence, the latest set of authors basically gave up, leaving the system in not completely viable shape! Specifically on the RX50, the problem has been determined to be that the design of the machine's boot ROM is incompatible with certain restrictions placed on the design of the bootstrap record of OS/278. Thus, certain operations normally occurring in an OS/8 environment are specifically forbidden and when allowed to happen will definitely crash the system disk! The specific underlying problem is as follows: There exists a DEC company-wide RX50 Bootstrap Block Standard that applies to the DECmate in part. The relevant information is that the Boot Block (Track 1, Sector 1) contain the following at its beginning: Byte # Contents 0 0 1 0 2 N - an offset to additional ID information 3 1 - System Disk (0=non-system disk) 4 0 5 0 Additional ID bytes are: 2*N+2 010 - PDP-8 code on this diskette 2*N+3 010 - RX278 controller 2*N+4 011 - OS/8 diskette structure. (Other values could apply for other OSes.) 2*N+5 346 - computed check value for above data 2*N+6 0 - always 2*N+7 1 - Revision of this diskette standard + single-sided diskette used. In the case of the usual RX50's used for OS/278, N=2, thus the additional ID bytes are found in the range of 6-13 (octal) Since this standard was applied "externally", i.e., wasn't checked to see if in conflict with PDP-8 requirements, it comes as no surprise that indeed it is (somewhat fatally) in conflict with PDP-8/DECmate requirements! The reason for this, is that byte[11] is required to have high-order bits set. On the RX01/02, data written in byte mode and in 12-bit mode are identical for the first 75% of the sector. Any data differences occur in the last 25% of the sector where, in general, the last 8-bits sent are replicated to pad out the data (in 12-bit mode). But the point of the matter is that if a sector is read, then written in either byte mode or 12-bit mode, the data relevant to 12-bit mode is unchanged. On the RX50 this is *not* the case at all! Instead, each two bytes are involved in a data distortion: the even bytes are unmodified (and are taken from the low-order 8 bits of the 12-bit word when written in 12-bit mode) while the odd bytes have their high-order 4 bits zeroed. (The low- order 4 bits of the odd byte are taken from the 4 high-order bits of the 12-bit word.) Thus, any scheme that depends on the data value of the high-order nybble of the odd bytes is hopeless if the record is ever written in 12-bit mode. OS/278 handlers must operate in 12-bit mode, and for all other purposes, do an adequate job operating this way, etc. However, commands such as SET SYS OS278 will rewrite logical record zero, which includes the boot block data, thus clearing all odd byte high-order nybbles, including the ones that pertain to the boot-block standard. Thus, the execution of reasonable, normal OS/8 operations is destined to destroy the system diskette! The release version of OS/278 contains a warning message should, for any reason, the flag bits in relative word 004 of the image of the boot record residing in 007604 become different from the value particular to SET SYS OS278, which is the default for the system release diskette. (Although default, it is arguably the least useful value!) Note that if this comes about from using a SET SYS command, then returning it to the OS278 setting doesn't clear the boot-block problem, just the warning message. Indeed, merely using SET SYS OS278 will cause no warning message, yet the system is now crashed! This half-baked message routine should be eliminated, since it doesn't work usefully, nor is it complete. (A parallel situation exists for RD51D hard disk, yet there is no attempted solution implemented at all.) I have studied the boot ROMs to determine precisely what the problem is, and indeed, there is a validity check made to determine if the floppy is bootable, but it's only a subset of the DEC Boot Block Standard: Byte[0]-Byte[1]=0 (Thus they merely have to be two's complement of each other not strictly zero. Byte[2] containing N is used to calculate the pointer to the rest of the bytes. In the specific case of the DECmate bootable diskette, N=2. N=3 is tried first, because this is the correct value for the RD51D. If the validity check fails, N=2 is attempted. Thus, Byte[6]=10 and Byte[7]=10 must be correct as in the standard. Byte[6]+Byte[7]+Byte[10]+Byte[11]=377. No specific check that one is 11 and the other is 346, just that the sum of the four is 377, however typical disks do have Byte[10]=11 and Byte[11]=346. There is a simple fix for this problem - violate the DEC Boot Block Standard! I doubt if there is much software that cares if the disk has the "sacred" combination. In any case, a utility program can be written to allow the "conversion" of standard-compliant disks to/from the working values, etc. The fix itself is rather easy - just swap the contents of Byte[10] and Byte[11] which doesn't change the overall checksum. However, Byte[10] now containing 346 will be preserved, since it is an even byte. 12-bit writing of the new Byte[11] will clear the high-order nybble of this byte, which corresponds to the desired value. Implementing the fix is rather simple. Using OS/278 FUTIL, open record 0 relative location 004. The current value will be 3011, since the 346 reads back as 006 but is used shifted 8 bits left. The 11 part is accurately rendered as the low-order 8 bits. Changing the value to 4746 allows the 11 part to be read back as 11 while the 346 part is preserved. Writing the new value back invokes a 12-bit call, but the validation sum is maintained thus the ROM validation code allows the disk to be bootable. OS/278 will have to be re-written to eliminate the half-baked attempt at curbing the SET SYS command, since that part of the system can now be made functional, etc. (Unfortunately, there is also a logic error associated with the functional differences between OS/8 and OS/278 mode, so this additional unrelated fix must also be implemented; in essence, the code has to be restored the the original OS/8-OS/78 values, etc.) This is also on the stack for OS/8 Version 5 fixes. The RD51D has a quite similar problem to solve. The only difference is that N=3 is used to locate the ID bytes at a different (by two) offset; this is why the ROM tries two different offsets, etc. The fix is the same except that the specific location affected is one different. Presumably there is no software that particularly cares that a hard disk volume conforms to the boot block standard. Certain standard utilities may have to be rewritten if they tend to write the standard (problematic) boot block values. The System Test Diskette is the largest candidate for the correction., In any case, a utility to ensure the correct value is quite trivial. 4) Sundry issues. The hardware configuration of the DECmate is quite different from most PDP-8's in other ways; the software *ought* to be able to overcome the remaining problems. It is a glaring fault of OS/8 that causes some remaining issues: While "advertised" as a device-independent system, in reality OS/8 isn't quite so generically configurable. In point of fact, the LPT: support of OS/8 partially depends on it conforming to the standards of the output-only device 66 Centronics/Data-Products type printer. Further, output goes to the LPT: *without* using a handler under (at least) the following circumstances: a) Batch log output comes directly from the tightly coded section of the resident batch code. (Batch requires 12K while OS/8 proper requires 8K unless the system handler requires 12K, in which case, the area from 27600-27777 is used by both the handler and the batch processor.) The LPT: is tested for and timed-out if not present. In fact, there was a patch made to OS/8 for the benefit of the LA-180, since the time-out was too fast for this specific printer which raises the flag slightly slower than the original Data Products or Centronics printers (LS8E, LA8, etc.). b) Fortran IV has a special-case device 66 buffered interrupt-driven LPT: output routine that is used instead of the handler if it's determined to be the standard hardware. Certain existent OS/8 programs make special-case checks for info pragmatically found in the LPSV standard device 66 LPT: handler regardless of actual hardware device code. While this allows the use of the LPSV handler for either the device 66 usage, or for the obscure usage of the 8/a option board IPB interface, (or certain user-written handlers such as a serial ^S/^Q aware printer handler, etc.), this doesn't allow all programs access to all of the LPT: characteristics, etc. A notable example is the SET command which will pragmatically identify the LPSV handler as a prerequisite for changing the parameters. All other cases yield error messages claiming the version of the LPSV handler is wrong, etc. Thus, OS/8 is hopelessly locked into the device 66 hardware. Various versions of newer releases of the OS/8 family may have limited support for other interfaces such as the device 32/33 interface found on the VT78 and all DECmates. There exists a CP trapped panel request to output a character on the serial port to the printer. This allows the ROM and slushware to control the ^S/^Q protocol and minimizes the code in tight routines such as BATCH, but is only valid on the DECmate II, III, III+. Some programs will not be able to adapt to the more complicated protocol of the serial printers for full compatibility. Certainly almost all of them will not easily be able to adapt dynamically to the configuration at hand. So, at best, we can hope to have some utility to configure all of the relevant sections of OS/8 to support the appropriate hardware; it would be helpful if such a utility would support "non-standard" configurations, etc. Certainly OS/8 Version 5 should include conditionals at the source level to create a default system suitable for the various configurations, etc. Also binaries for the common variants can be provided for user customization, etc. The communications port of the DECmate I differs greatly from all previous systems. All previous systems are virtually identical other than perhaps device codes and programmable baud rate in the case of the VT78. (The DECmates share a similar structure for baud rate setting with the VT78, but all else is quite different.) The DECmate II, III, III+ are all quite similar and quite different from all of the previous systems. Careful programming can allow DECmate II, III, III+ compatibility with the same code, etc. However, the DECmate III (and possibly III+) allow for a unique option of another port to an internal 300/1200 baud modem requiring not only careful initialization code to avoid, but additional coding to actuate, etc. While Kermit-12 currently doesn't support the internal modem option, it does correctly initialize the communications ports of all three models. Also it can access either of the dual ports of the DECmate I with DP-278 if that is the machine configuration, etc. Any other communications program has to be able to support all of these disparate configurations. PDP-8 configuration usually consists of setting the device codes; the DECmates impose these newer situations, etc. Since much of the terminal emulation of the DECmates is entered via CP traps, the PDP-8 program will have real-time "gaps" where it appears to not be executing any cycles. (The cycles exist, but are all taken up by CP memory routines.) This severely hampers many real-time programs that expect to allocate all CPU resources to the appropriate amount of background and foreground processing, etc. since some of the CPU resources aren't available to either purpose. Moreover, the "burstiness" of this cycle lossage is model-dependent. The DECmate I has the lowest overall overhead, but tends to take the overhead in larger bursts, thus making the character-drop-free maximum baud rate much lower than on the DECmate II, III, III+ where the cycles are "smoothed" out better, etc.) In some cases, better throughput is achieved by *not* using console interrupts, especially to the screen. This kind of "backwards" performance characteristic affects programs such as Fortran IV, etc. The last category of incompatibility has nothing to do with hardware - there is a major lack of documentation for the DECmate. Almost no hardware documentation exists, especially for option boards. Many utilities, some found in OS/278, are not documented, and the source program isn't available either. In virtually every case, utilites added since OS/78 V3 have never been made available, especially the hard disk utilities such as FIXDIR, MOUNT, BOOT, MENU, and also more generic programs such as EDIT.SV which at first glance requires merely that the console terminal be VT-100 compatible or better. Yet, there is need for a patch specific to the PDP-8/e (and due to creeping model dependencies), and likely earlier machines will not properly run EDIT.SV, etc. Much of the sorely-needed information has been obtained by manual dis-assembly of the relevant binaries, but some parameters remain undecipherable without source code listings, etc. With proper documentation, the DECmate should become more "embraced" as a member of the PDP-8 family. cjl From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Tue Mar 16 00:13:27 EST 1993 Article: 185 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: KL8JA (M8655) notes Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar15.224607.2499@news.uiowa.edu> Date: Mon, 15 Mar 1993 22:46:07 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 219 Technical notes for the M8655 KL8-JA OMNIBUS asynchronous interface board by Douglas Jones jones@cs.uiowa.edu The M8655 board supports asynchronous communications at a variety of baud rates, with either an RS232 or a current loop interface. The board uses a UART chip, but most of the options that might be programmable in a more modern system are selected by jumpers on the board. In most respects, the M8655 board and the M8650 board are interchangable, but the M8655 can generate and detect parity, and it can support data widths from 5 to 8 bits, while the M8650 can support higher nonstandard baud rates and is thus more appropriate for high speed PDP-8 to PDP-8 links. There's also no way to send a break on an M8655, while this can be sent on an M8650 by jamming data into the transmit buffer while it is transmitting. General geography of the M8655 board: \\____// \\____// \\____// \\____// ______||__||_____________||__||____________||__||_____________||__||_____ | o ____ _ o _o _ o _o _ _ o _ o _ _ _ _ _ o| | |_ | | | | | | | o : : | | | | ..| | | | || | | | | | | | | | FIL : : | | | | | | | | | CAN | | | | |_| |_| |_| o :_: |_| |_| ..|_| |_| _ _ _ _ || | | | _ _ _ _ _ _ _ _ _ ___ | | | B| | | | | | | | | | | | | | | | | | | | | | | | E| | | | | | | | | | | | | | | | | | | |OSC| | | | R| .o |_| |_| |_| |_| |_| |_| |_| |_| |_| |___| | | _| G| TTY _ _ _ _ _ _ _ _ _ _ | | |____| .o | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | . | | | | | | |_| |_| |_| |_| |_| |_| |_| |_| |_| |_| | | . | | _ _ _ _ _ _ _ _ _ _ | | | | | | | | | | | | | | | | | | : : | | | | | | | | | | | | | | | | | | ____ | | : : | | | | |_| |_| |_| |_| |_| |_| |_| | | |_| :_: |_| | | _ _ _ _ _ _ _ | | _ ___ ___ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o o | | | | | | | | |_| |_| |_| |_| |_| |_| |_| | | NP SB|_| |___| |___| | | _ _ _ _ _ _ _ | | o o _ XMIT RCV | | | | o | | | | | | | | | | | | |____| o o o| | | | | | | | | |SWD| | | | | | | | | | | | EVN 1 2| | | | | | | | |_|.o |_| |_| |_| |_| |_| |_| o o o|_| |_| |_| | | W3 | |_ . __|| _|| __|| | | | | | | | | | |______________| |______________| |______________| |______________| Given an M8655 board, various optional jumpers and switch settings must be inspected and possibly changed prior to any use of the board. The following sections treat the primary options that limit the range of baud rates supported, that select a particular rate, and that select the I/O device addresses used for the board. 1) Jumpering to set-up basic communications options. \\____// \\____// \\____// \\____// ______||__||_____________||__||____________||__||_____________||__||_____ | o ____ _ o _o _ o _o _ _ o _ o _ _ _ _ _ o| | |_ | | | | | | | o : : | | | | ..| | | | || | | | | | | | | | FIL : : | | | |W5W2 | | | | CAN | | | | |_| |_| |_| o :_: |_| |_| ..|_| |_| _ _ _ _ || | | | _ | | B| | | ^ ^^ | | E|W1 | | A jumper between A zero ohm resistor or | | R| .o |_| these split lugs wire jumper should be | _| G| TTY will insert 4 inserted at either W2 | |____| .o nulls after each or W5, but not both. linefeed. (This This selects the highest ^ is needed for the baud rate the board will A jumper between the DEC VT05 at 2400 support. TTY split lugs or baud at 60 Hz. a zero ohm resistor This is a poor W5 (left) = 19200 baud at W1 is required design; it does W2 (right) = 9600 baud for 110 baud current not give enough loop operation, both delay at 50 Hz, The originl GI UART could must be absent for and it is overkill only do 9600 baud. The higher baud rate at 600 and 1200 SMC COM 2017 can do both. current loop service. baud.) 2) Jumpering for error reporting on received data. | _ _ The split lugs marked SWD are in parallel with the | | | o | | jumper location W3. If no jumper is present in either | | |SWD| | location, the M8655 KL8JA board will look, to software, | |_|.o |_| exactly like an M8650 KL8E board. | W3 |_ . __| If a jumper is present at this location, the board | | recognizes a new software option allowing reporting |______________| of the UART status word with each character read. The command to turn this option on and off is: KIE (6xx5) -- Bit 11 of AC is the interrupt enable bit, as usual; Bit 10 of AC is the status word report reqest bit. If the status report request bit is set, the data returned in AC by the KRS (6xx4) and KRB (6xx6) commands is formatted as follows: bit[0] -- error detected. bit[1] -- parity error detected in this character bit[2] -- framing error detected, this might not be a character bit[3] -- overrun error detected, previous character lost bits[4-11] -- the data read (as usual) 3) Jumpering for data format: _ _ _ | | | | | | | | There are 5 pairs of split lugs and one zero ohm | | . | | | | | resistor or jumper wire in this group. In general, |_| W4 |_| |_| | if none of these are jumpered, the board will behave . | like an M8650. _ _ _ | | | : : | | | SB -- number of stop bits ____ | | : : | | | W4 -- jumper in parallel with SB lugs | | |_| :_: |_| | jumper present - 1 stop bit | | _ ___ ___ | jumper absent - 2 stop bits | | | | | | | | | | | o o | | | | | | | NP -- parity generation and checking | | NP SB|_| |___| |___| | present - 1 parity bit. | | o o _ XMIT RCV | absent - no parity bits. |____| o o o| | | | | | | EVN 1 2| | | | | | | EVN -- sense of parity bit o o o|_| |_| |_| | absent - parity = odd(bitcount(data) | present - parity = even(bitcount(data) __|| | | | | NB1,NB2 -- number of data bits |______________| |______________| 0 0 8 1 0 7 0 = jumper absent 0 1 6 1 = jumper present 1 1 5 4) Switch settings: ___ ___ | The two DIP switches are divided logically into 2 groups of | | | | | switches to control the baud rate and device addresses. | | | | | |___| |___| | The bottom 6 switches on each DIP switch cluster set the XMIT RCV | device addresses. The left switches handle the transmit | | | | | address, the right handles the receive address. Both | | | | | switch groups have the same format: |_| |_| | | | ==- | MD3 MSB of device address | | | ==- | MD4 | | | ==- | MD5 For all bits, |______________| | ==- | MD6 ON = 1, OFF = 0 | ==- | MD7 _______ _______ | ==- | MD8 LSB of device address | | | | |_______| | ==- |B3 | ==- |B1 | ==- |R=150 | ==- |B2 The 3 baud rate bits, B1, B2, B3 give the baud rate: B1 B2 B3 0 0 0 = 110 baud As a special case, if the 0 0 1 = 150 baud R=150 switch is on, the 0 1 0 = 300 baud On = 1, Off = 0 receive baud rate is set 0 1 1 = 600 baud to 150 baud. Normally, 1 0 0 = 1200 baud the transmit and receive 1 0 1 = 2400 baud baud rates are the same. 1 1 0 = 4800 baud 1 1 1 = 9600 or 19200 baud (see part 1, jumpers W2 and W5) 5) Discrete crystal versus integrated oscillator. \\____// ______||__||_____ As originally designed, the M8655 board used a large o _ _ _ _ _ o| crystal can mounted over the large pad in the upper | | || right corner of the board. This was not a satisfactory | | | CAN | design, and DEC abandoned this can in later revisions |_| _ _ _ _ || of the board. Instead, the integrated circuit at position _ ___ | E4 (shown at OSC here) was replaced with a CTS 5.0688 MHZ | | | | | oscillator (DigiKey part CTX110). This requires that the | | |OSC| | circuit traces connecting to pins 1 and 8 of E4 be cut |_| |___| | (note that pins 7 and 14 were unused), and it requires that | discrete components immediately above, below and to each side of E4 be removed (be careful not to remove the power supply decoupling capacitor below E4). 3 jumpers must then be installed: From pin 7 to ground (the left end of a nearby decoupling capacitor). From pin 14 to +5 (the right end of a nearby decoupling capacitor). From pin 13 to pin 8. All these jumpers should be 30 gauge wire-wrap wire so that there is room to put the jumper in the same hole as other component leads. If your oscillator has a metal can, mount it with a plastic shim (DigiKey K266-ND, an OK Socket-Wrap ID tag, should work) so the case doesn't short to any traces on the board below it. 6) Cables \\____// ______||__||______ | o ____ o | |_ | | | | The cable plugged into the Berg connector determines whether | | | the board uses a current loop interface or an RS 232 interface. | | | | | B| The following connector hardware will mate with the Berg | | E| connector on the board (DigiKey part numbers for AMP parts): | | R| | _| G| ASC40G-ND 40 pin gold socket connector | |____| ASSR40-ND strain relief for above ASPT40-ND pull tab to make it easy to unplug For an RS232 interface, you need the equivalent of DEC's BC01V cable. This mates with the Berg connector at one end and has a male DB25 connector at the other end, in conformance with the RS232 specification. For a current loop interface, you need a 7008360 cable with a Mate-N-Lock connector at the far end. From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Tue Mar 16 00:18:30 EST 1993 Article: 186 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: BC01V notes Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar15.224739.2580@news.uiowa.edu> Date: Mon, 15 Mar 1993 22:47:39 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 176 Technical notes for the BC01V RS232 interface cable by Douglas Jones jones@cs.uiowa.edu The M8650 and M8655 boards use the BC01V cable to communicate with RS232 devices. These notes describe how to build this cable. The BC01V cable supports most of the RS232 standard, but most devices don't use more than 9 of the 25 pins in the standard. The M8650 and M8655 only require three of these, transmitted data (txd), received data (rxd), and ground (gnd), but they provides support for request to send (rts) and data terminal ready (dtr), both of which are held high. The following cable should work with any DEC board that expects a BC01V cable, so it provides full support for all 9 commonly used signals. Male DB25 connector Female 40 pin plug as seen from back as seen from back ---1 Board A B Free | 14 This jumper configures side side | 2-----------. the interface for RS232 C D | 15 \ \ | 3---------. \ -----E ,F rxd | 17 \ \ \ ,-----cts>------ / ,---|-------' | 5---------\---\---\--' \/ / | K L | 18 `---\---\-------cts 21 \ \ \ `------rxd>-----' \ `--\-------' 9 \ \ \ \ \ U ,V -----------\--. | 11 \ \ \ | Y ,Z >dsr 24 `--------------rsd>---------. \ `--|-----' 12 \ \ | AA ,BB >rsd 25 The cable should `---\---|-----' 13 be 25 feet long. \ | CC ,DD Received data (rxd) 16 16 --------4 4--- < Request to send (rts) | 17 17 | --------5--------. ,-------------5--- > Clear to send (cts) 18 \ / 18 --------6 X 6--- > Data set ready (dsr) | 19 / \ 19 | | 7--------/---\-------------7 | Signal ground | 20-----------/-. ,-\-------20 | < Data terminal ready (dtr) | 8------' X `-----------8 | > Received signal detect (rsd) | 21 / \ 21 | | 9 / \ 9 | ---22-----------' `-------22------- > Ring indicator (rng) 10 10 23 23 11 11 (Note that in this wiring diagram, 24 24 all places where 4 wires seem to 12 12 meet are really places where two 25 25 wires cross without touching!) 13 13 The theory behind this is as follows: a) txd from one device becomes rxd to the other. b) rts from one device becomes cts for that device and rsd for the other. c) dtr from one device becomes dsr and rng for the other. Parts b and c only really matter for devices that use EIA flow control. Such devices lower dtr to stop the flow of incoming data, and they await dsr before they send outgoing data. In addition, they raise rts when ready to transmit, and they await cts before transmitting. From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Wed Mar 17 01:54:51 EST 1993 Article: 187 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: KL8JA enhancements? Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar16.223210.23616@news.uiowa.edu> Date: Tue, 16 Mar 1993 22:32:10 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 46 While decyphering the myriad options offered by my M8655 KL8JA board, I hit on the following idea, which is described in the following optional section of the KL8JA technical notes: =========================================================================== ?) Unused sockets. \\____// \\____// _________||__||_____________||__||_____ The KL8-JA board contains two o _o _ _ o _ o _ _ _ _ _ o| sockets that were apparently : : | | | | ..| | | | || used in production line testing : : | | | | | | | | | CAN | of the board. Nothing should :_: |_| |_| ..|_| |_| _ _ _ _ || be plugged into these sockets ^ _ ___ | for normal operation. unused! | | | | | | | |OSC| | An interesting option would be to use these sockets to |_| |___| | hold the logic needed to implement software selectable _ _ | baud rates. This would involve cutting the unneeded | | | | | traces to the sockets and using them for the flipflops | | | | | to hold the baud rate. The flipflops outputs would drive |_| |_| | the inputs currently driven by switches B1 B2 and B3 | (see section 4), and the inputs would come from bits _ _ | 7 8 and 9 of AC on a KIE instruction when the SWD : : | | | jumper is present (see section 2). unused! >: : | | | :_: |_| | =========================================================================== This enhancement shouldn't be a hard one to implement, but I don't want to recommend that anyone undertake it until we can hash out whether or not it is desirable and how it should be standardized. I don't want to see 100 different hackers (well, how many PDP-8 hardware hackers are out there?) produce 100 different and incompatable designs, but if we could all agree on the same enhancement, with the mechanics of the change set down about as firmly as they are for DEC's field changes, we might be able to come up with a useful board revision and get a significant population of compatable hardware. Of course, the biggest place this would help anyone is in modem control, for example, if someone wanted to set up a PDP-8 based BBS. In this case, you'll probably need an M8653 KL8M modem control board to handle the rest of the RS232 lines that the KL8E ignores, and you'll probably also want to be able to diddle the parity bits and stop bits under software control. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Wed Mar 17 02:19:45 EST 1993 Article: 188 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: KL8JA enhancements? Message-ID: <1993Mar17.071841.22650@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar16.223210.23616@news.uiowa.edu> Date: Wed, 17 Mar 1993 07:18:41 GMT There already is a standard for PDP-8 baud-rate control. The implementation is 6xx3 where xx is the receive device code. The baud rate is obtained by the contents of AC[8-11] and is used to dump the 4-bit quantity into the selection register of a 5016/8016 baud rate chip. Curiously enough, the same 5.0688 MHz. crystal is used for this chip, so it is compatible on several levels. (The chip has an option to run directly a series-resonant crystal, or can be run by a TTL clock can.) The circuit is used on the VT-78 for the serial ports and serial printer, as well as for the same functions on all of the DECmates, including the baud rate for the relevant comm sections, etc. All of the options implement the same rates: AC bit# Rate 8 9 1 1 0 1 0 0 0 0 50 Baud 0 0 0 1 75 Baud 0 0 1 0 110 Baud 0 0 1 1 134.5 Baud 0 1 0 0 150 Baud 0 1 0 1 300 Baud 0 1 1 0 600 Baud 0 1 1 1 1200 Baud 1 0 0 0 1800 Baud 1 0 0 1 2000 Baud 1 0 1 0 2400 Baud 1 0 1 1 3600 Baud 1 1 0 0 4800 Baud 1 1 0 1 7200 Baud 1 1 1 0 9600 Baud 1 1 1 1 19200 Baud Thus, true compatibility can be had by imitating this standard. Likely most of the gating is already on the card. By eliminating the discrete logic used to run the dip switches, this software controlled verison can be implemented. Any additional gating can be placed in the saved real estate, etc. Eliminating the odd R=150 option is quite reasonable, as few of us can even take advantage of it. (I have a VT05 and I don't even bother!) Perhaps a clever design could come about that enables/disables the on-board DIP switches used for the current 3-bit select and the R=150 option to form a 4-bit register that overrides the programmable value should the SWD or some other jumper not be set. cjl From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Wed Mar 17 10:50:32 EST 1993 Article: 189 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: KL8JA enhancements? Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar17.135535.4306@news.uiowa.edu> Date: Wed, 17 Mar 1993 13:55:35 GMT References: <1993Mar17.071841.22650@news.columbia.edu> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 14 >From article <1993Mar17.071841.22650@news.columbia.edu>, by lasner@watsun.cc.columbia.edu (Charles Lasner): > Perhaps a clever design could come about that enables/disables the on-board > DIP switches used for the current 3-bit select and the R=150 option to > form a 4-bit register that overrides the programmable value should the > SWD or some other jumper not be set. In 2 chips? I doubt it! And the table of baud rates looks different enough from the table supported by the KL8JA that the mapping may be quite difficult. My suspicion is that compatability with this existing standard would be very hard to achieve. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Wed Mar 17 11:04:20 EST 1993 Article: 190 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: KL8JA enhancements? Message-ID: <1993Mar17.160247.12583@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar17.071841.22650@news.columbia.edu> <1993Mar17.135535.4306@news.uiowa.edu> Date: Wed, 17 Mar 1993 16:02:47 GMT In article <1993Mar17.135535.4306@news.uiowa.edu> jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >From article <1993Mar17.071841.22650@news.columbia.edu>, >by lasner@watsun.cc.columbia.edu (Charles Lasner): > >> Perhaps a clever design could come about that enables/disables the on-board >> DIP switches used for the current 3-bit select and the R=150 option to >> form a 4-bit register that overrides the programmable value should the >> SWD or some other jumper not be set. > >In 2 chips? I doubt it! And the table of baud rates looks different >enough from the table supported by the KL8JA that the mapping may be quite >difficult. My suspicion is that compatability with this existing standard >would be very hard to achieve. > Doug Jones > jones@cs.uiowa.edu Enabling the DIP switches to be a default override for the program-controlled values may be difficult unless you allow the switches to OR into the data a program might use. Thus, a program ignorant of the extension would work if the DIP switches were set to the desired value for the benefit of said program while a "smarter" program would fail to set the rate correctly unless you lucked out that the rate you wanted ORed with the DIP switches was the value you wanted. In any case, the implementation is rather simple: the decoded 6xx3 for receive should be available already and properly conditioned, etc. Use it to load the AC data into 4 flip-flops. I think one of the 82xx specials is literally this function. So, that's one chip. The other chip is the baud rate generator 8016/5016 which goes to the TTL oscillator can 5.0688 MHz. Also, this baud rate chip can take its own crystal if necessary; I can provide the appropriate series-resonant crystal. (I purchased a lot of them from the crystal vendor recommended by the chip manufacturer; they turned out to be local to me, and would only sell me a lot of 25, but at a cheap price :-). This was for a different project to create a baud-rate generator, but not for the KL8-JA, etc.) In the process of doing this, some other logic may become totally package obsolete, thus freeing more space to perhaps do the DIP switch "frill" part better, etc. (Use a 2-way 4-bit multiplexor to select either the 4 DIP switches or the outputs of the data flops as the source of the data for the baud-rate chip, etc.) cjl From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Fri Mar 19 23:36:27 EST 1993 Article: 191 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: DECmate option help please. Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar19.223556.3148@news.uiowa.edu> Date: Fri, 19 Mar 1993 22:35:56 GMT References: <1993Mar20.055748.1@cc.curtin.edu.au> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 22 Do not respond to me! My machine is going off the net for a week, and besides, I'm forwarding this post from comp.sys.dec.micro for Paul Repacholi. ======== Begin Forwarded Post ========= >From article <1993Mar20.055748.1@cc.curtin.edu.au>, by zrepachol@cc.curtin.edu.au (Paul Repacholi): Hi all, are there any DECMATE II experts out there? First, how can I install a second RX50? I guess that I either a) add a second cable from the back 40 pin header on the MB to the second drive. or b) make up a cable with 3 headers and daisychain the two drives. And install a jumper on the pins next to the drive header to change it to units 2 and 3. What options where available for them, and where do they go? I can get as many of these as I like, and they are quite OK for 99% of the text hacking etc I and the family want to do. Not screaming fast though... TNX Paul From news.columbia.edu!watsun.cc.columbia.edu!lasner Sat Mar 20 10:28:54 EST 1993 Article: 192 of alt.sys.pdp8 Xref: news.columbia.edu alt.sys.pdp8:192 comp.sys.dec.micro:2071 Newsgroups: alt.sys.pdp8,comp.sys.dec.micro Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: DECmate II Video Connections Message-ID: <1993Mar20.152811.18222@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Sat, 20 Mar 1993 15:28:11 GMT I am reposting an article from comp.sys.dec.micro that applies to this group along with some comments. Perhaps someone has some clues as to what's going on here. Newsgroups: comp.sys.dec.micro Subject: Re: Pinout of DECmate II videoconnector ? From: don@zl2tnm.gen.nz (Don Stokes) Date: 20 Mar 93 07:16:29 GMT The 15pin monitor cable connector pinouts are: 1 Blue return 2 Green return 3 Red return 4 Mono return 5,6 Ground 7,8 +12VDC 9 Blue video 10 Green video 11 Red video 12 Mono video 13 Monitor present 14 Keyboard receive 15 Keyboard transmit Signals are straight video. VR201 monitor gets its power through the +12VDC line (pins 7&8), VR241 has its own power supply. I'm not sure where the sync comes from in the colour signals (green?), but it's there in the mono signal. This pinout is pretty much the same for all DEC monitor cables. -- [End of copied material; unrelated parts deleted for bandwidth considerations only, etc.] My experience with the DM II (as opposed to the III and III+) is that the VR-241 doesn't work as the primary monitor. Note that the recommended configuration for a II is a mandatory VR-201, and if the graphics board is present (I have one for the II, not the III/III+) then you can optionally add the VR-241 to the 15-pin connector on the graphics option. (Monochrome graphics come out of the main connector because there is an after-thought jumper between the graphics board and the motherboard to route the text to the graphics card and also graphics to the main video out on the motherboard. This is part of the major hardware ECO to the older vintage DECmate II motherboards which were simultaneously not compatible with the hard disk board set and also not compatible with the graphics board. Beyond a certain level, this was merely due to the ROM contents, but this affects only the hard disk aspect. (I have disassembled the relevant ROM versions to confirm this, etc.) The ECO consists of adding on a small two-prong connector to an available small patch of empty board region, and then performing quite a few adds and deletes (about 25 wires) so that the option board functions correctly. (The System Test Diskette won't even acknowledge the existence of the graphics option without the ECO, etc.) The DM II graphics color cable is visually similar to the Rainbow cable, which I believe is the same cable for a DM III/III+ configured with the graphics board within. In essence, you have a one-monitor system with the ability to have either a VR-201 or VR-241, but not both, while a Rainbow can have either one or the other or both, the last case being similar to what's thrust upon you in the DM II case, and the former cases being the same as the III/III+. That Rainbow cable was given to my by a Rainbow person along with a VR-241. This is the kind with the three striped R G B BNC cables at one end, and the 15-pin connector at the other end. The wires come out of a large molded block with a strip of velcro on the back to hang on the back of the monitor. Additionally, the keyboard plugs into the block. I have also used this cable on a VT-240. It worked fine, and allowed me to plug the keyboard into either the VT-240 or the provided socket on the cable. My only disappointment was that the terminal identifies as a VT-240 not a VT-241, even though it also says VT-240 when you use a VR-201 with the keyboard in either place. I thought it could identify which monitor you are using and behave accordingly. It is conceivable it is working, yet just not proclaiming it at the ID, etc. Any ideas as to how to force the issue that the VT-241 indeed is recognized as such? (Does it return a terminal escape sequence that is different if a VR-241 is installed?) Although similar, the DM II cable is clearly different. It lacks entirely the modular socket in the block (and has no provision for the velchro stick-on). When that cable is used on the VT-240, you are of course forced to connect the keyboard to the internal connector on the back of the VT-240, but in any case, it comes up with an error message (I forget the exact verbiage) and then proceeds to otherwise function correctly. The Rainbow cable doesn't work in either 15-pin DM II positions. I.E., it won't allow the DM II to come up with color primary monitor, and the cable doesn't allow the use of the VR-241 on the graphics board either. Just before the recent blizzard in North America, I received (it's somewhat "buried" at the moment, so this may have to wait for awhile) a bizarre cable. This may be an in-house DEC special cable, but essentially, it's a cable that on one end looks like the Rainbow cable, complete with block and three R G B BNC leads, but the other end has *two* 15-pin connectors! (And of course, it should be interesting figuring which 15-pin goes to which connector!) Anyone have any clues on the above? cjl From news.columbia.edu!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don Sun Mar 21 11:50:20 EST 1993 Article: 193 of alt.sys.pdp8 Xref: news.columbia.edu alt.sys.pdp8:193 comp.sys.dec.micro:2072 Path: news.columbia.edu!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don Newsgroups: alt.sys.pdp8,comp.sys.dec.micro Subject: Re: DECmate II Video Connections Message-ID: <2124078@zl2tnm.gen.nz> From: don@zl2tnm.gen.nz (Don Stokes) Date: 20 Mar 93 23:59:10 GMT Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.) References: <1993Mar20.152811.18222@news.columbia.edu> Distribution: world Organization: The Wolery Lines: 82 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: That onfo came from Field Circus. I wanted to (and did) hook up a VR201 to a GIGI. The pinout is standard from DECmates to workstations; however note that mono only systems don't use the colour lines and vice-versa. There's only one "monitor present" line (tied to ground in the monitor, or in the connector block for those monitors that use BNC connectors), so a machine can't tell if there's a VR201 or a VR241 at the other end. (Actually, if the thing at the other end draws power, it's a 201, since the 241 has its own power supply, but I don't believe that's implemented anywhere.) Thus, you can (in theory at least, ie assuming the cable brings does the right thing with all the lines) use a VR201 with the same cable on a VT240, DECmate or Rainbow; likewise with the VR241. The cable is not so much a "DECmate" (or whatever) cable as a "VR201" (or VR241) cable. The VR201 cable is the same pinout at both ends -- you can bang two of them together if you need a longer cable to the monitor/keyboard. (I think it brings the colour lines out as well (which the VR201 ignores), but I'm not sure.) >From your commemts below, it sounds like while the VR201 cable is pretty much standard across the board, the 241 cables have some bogosities in their implementations. >My experience with the DM II (as opposed to the III and III+) is that the >VR-241 doesn't work on it at all. Note that the recommended configuration That will be because the VR241 doesn't listen to the mono line, and the mono socket of the DECmate doesn't put anything on the colour lines. Try re-wiring the mono line from DECmate to the green (I think -- whichever one generates the sync) line of the monitor. >I have used this cable on an actual VT-240. It worked fine, and allowed me >to plug the keyboard into either the VT-240 or the provided socket on the >cable. My only disappointment was that the terminal identifies as a VT-240 >not a VT-241, even though it also says VT-240 when you use a VR-201 with the >keyboard in either place. I thought it could identify which monitor you are >using and behave accordingly. It is conceivable it is working, yet just not >proclaiming it at the ID, etc. Any ideas as to how to force the issue that >the VT-241 indeed is recognized as such? (Does it return a terminal escape >sequence that is different if a VR-241 is installed?) Nothing changes on a VT240 whether there's a mono or colour screen on it; it doesn't detect the 241. Tha name "VT241" is ordering information only; what you got when you ordered a VT241 was a box with "VT240" on the front and a VR241 on top of it. The 240 base unit generates both colour and mono output, regardless of what's on the other end of the cable, and the ID sequence is identical. >Anyway, the DM II cable is different! It lacks entirely the modular socket >in the block (and they didn't provide for the velchro stick-on). When >that cable is used on the VT-240, you are of course forced to connect the >keyboard to the internal connector on the back of the VT-240, but in any >case, it comes up with an error message (forget verbiage) and then proceeds >to otherwise work anyway. Maybe they were lazy with that cable -- left out the "monitor present" jumper & didn't bring out the keyboard lines, probably. >The Rainbow cable doesn't work in either 15-pin DM II positions. I.E., it >won't allow the DM II to come up in color primary monitor, and the cable >doesn't allow the use of the VR-241 on the graphics board either! Any clues >as to what's different here? The 241 won't work at all in the mono socket. Don't know why it won't behave in the gpx socket -- time to break out a meter and look! >Just before the recent blizzard, I received (it's somewhat "buried" at the >moment, so this may have to wait for awhile) a bizarre cable. This may be >an in-house DEC special cable, but essentially, it's a cable that on one end >looks like the Rainbow cable, complete with block and three R G B BNC leads, >but the other end has *two* 15-pin connectors! (And of course, it should be >interesting figuring which 15-pin goes to which connector!) Dunno. Again, out with the meter! -- Don Stokes, ZL2TNM (DS555) don@zl2tnm.gen.nz (home) Network Manager, Computing Services Centre don@vuw.ac.nz (work) Victoria University of Wellington, New Zealand +64-4-495-5052 From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.weeg.uiowa.edu!jones Sun Mar 21 23:55:42 EST 1993 Article: 194 of alt.sys.pdp8 Xref: news.columbia.edu alt.folklore.computers:40089 alt.sys.pdp8:194 Newsgroups: alt.folklore.computers,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.weeg.uiowa.edu!jones From: jones@umaxc.weeg.uiowa.edu (Douglas W. Jones) Subject: Wanted: info on ADM5 terminal Message-ID: <1993Mar22.032407.12031@news.weeg.uiowa.edu> Sender: jones@news.weeg.uiowa.edu (Douglas W. Jones) Organization: University of Iowa, Iowa City, IA, USA Date: Mon, 22 Mar 1993 03:24:07 GMT Lines: 9 I have an old ADM5 terminal that I want to use as a console for my PDP-8/F. It has an option of using either current loop or RS232 for the interface connector -- does anyone know the pinout? It has different control codes from the ADM31 I have documentation for. Does anyone have documentation? A print set would be really nice, if I could get it. Doug Jones jones@cs.uiowa.edu From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.weeg.uiowa.edu!jones Mon Mar 22 00:05:13 EST 1993 Article: 195 of alt.sys.pdp8 Xref: news.columbia.edu alt.sys.pdp8:195 comp.sys.dec:13014 Newsgroups: alt.sys.pdp8,comp.sys.dec Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news.weeg.uiowa.edu!jones From: jones@umaxc.weeg.uiowa.edu (Douglas W. Jones) Subject: Wanted: Info on MMI third party boards for PDP-8/E Message-ID: <1993Mar22.033516.16179@news.weeg.uiowa.edu> Sender: jones@news.weeg.uiowa.edu (Douglas W. Jones) Organization: University of Iowa, Iowa City, IA, USA Date: Mon, 22 Mar 1993 03:35:16 GMT Lines: 24 I have gotten my old PDP-8/F up, and I've restored my asynch boards to good condition, but I have a problem with memory: In addition to an 8K core module made by DEC, I have 3 8K solid state memory modules made by MMI. Of these, two work well, but one is broken. I'd like to repair it, but I have no prints for the board. Does anyone have prints for a board with the following self-description? MO-V PL/PDP-8 303-0112-0010 -- the last 4 digits are rubber-stamped -- board revision? M -- the M is really an MMI logo. On the back side, the board has the following text: 304-0112-001 REV.C MADE IN USA 7622 -- more rubber stamps, a date code for week 22, 1976? SER. NO. E6 0207 -- more rubber stamps. Any and all help I can get would be appreciated (although, I admit, I've already got enough good memory to put 16K on each of my PDP-8 machines, so what more could I want? That's quite a bit, after all!) Doug Jones jones@umaxc.weeg.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Tue Mar 23 00:01:52 EST 1993 Article: 197 of alt.sys.pdp8 Xref: news.columbia.edu comp.sys.dec.micro:2082 alt.sys.pdp8:197 alt.folklore.computers:40187 Newsgroups: comp.sys.dec.micro,alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: LQP45 Message-ID: <1993Mar23.050041.17633@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Tue, 23 Mar 1993 05:00:41 GMT Anyone got a clue what a DEC LQP45 is? (Not LQP01, 02, 03 or 8E, but 45). For the less-informed, it's a DEC printer of some kind. Also, I once heard of an LQPSE; perhaps they are one and the same. If not, what is an LQPSE? cj "Enquiring document preparers want to know" l From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!quads!buzy Tue Mar 23 09:03:13 EST 1993 Article: 198 of alt.sys.pdp8 Xref: news.columbia.edu alt.tv.bh90210:1721 alt.toys.lego:1265 alt.toolkits.xview:1870 alt.thrash:3307 alt.sys.pdp8:198 alt.sys.intergraph:585 alt.sys.amiga.uucp:4815 Newsgroups: alt.tv.bh90210,alt.toys.lego,alt.toolkits.xview,alt.thrash,alt.sys.pdp8,alt.sys.intergraph,alt.sys.amiga.uucp Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!quads!buzy From: buzy@quads.uchicago.edu (Len Buzyna) Subject: DidYouKnow... Message-ID: <1993Mar23.051636.10121@midway.uchicago.edu> Sender: news@uchinews.uchicago.edu (News System) Reply-To: buzy@midway.uchicago.edu Organization: University of Chicago Computing Organizations Distribution: usa Date: Tue, 23 Mar 1993 05:16:36 GMT Lines: 29 Today Japanese companies own the 7/11 store chain, Dunlop, Universal Pictures, Columbia Pictures, Loews Theaters, MCA Home Entertainment, Tri-Star Pictures, CBS Records, Columbia Records, Spencers stores, Ciniplex Odeon (a big part), Firestone Tires and many many more very large US companies while foreigners are prevented from owning any important Japanese concerns. Ordinary Japanese are kind wonderful people, but what their companies and government are doing is racist and wrong. To find out more about this (and get a more complete list of the above), read (JAPANYES) "Does America Say Yes To Japan?";Leclerc 1992,93 which is available on INTERNET. (most recent edition is v031993). This thoughtfully written and important article has been circulating widely in many of America's biggest corporations & universities like IBM & Harvard. When you read it (it takes about 30 minutes), you'll see why. The essay provides a frightening yet fascinating detailed, referenced overview of the Japanese industrial machine at work and how Japan practices 'business is war' strategies to target and take over strategic critical U.S. industries like high technology, popular media and heavy industry as well as influence the decisions of the US government in favor of Japan. It is a very moving piece and is filled with many verifiable and disturbing examples. You can get JAPANYES 1 of 3 ways: 1)FTP to monu6.cc.monash.edu.au it's in directory: pub/nihongo as: JAPANYES 2)The article has been posted in its entirety (in three sections however) in the misc.test & soc.culture.usa & sci.econ newsgroups. Search on the author 'buzy' or the title 'article' to find the posts. 3)Email a request for JAPANYES to ar12@midway.uchicago.edu He will email you a copy. From news.columbia.edu!rpi!think.com!yale.edu!nigel.msen.com!caen!uunet!decwrl!pa.dec.com!@mail.uunet.ca:sandelman.ocunix.on.ca!parse!root@micor Tue Mar 23 13:57:49 EST 1993 Article: 199 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!rpi!think.com!yale.edu!nigel.msen.com!caen!uunet!decwrl!pa.dec.com!@mail.uunet.ca:sandelman.ocunix.on.ca!parse!root@micor From: root@parse.ocunix.on.ca Subject: PDP-8 binaries Message-ID: <9303222042.AA19250@parse.ocunix.on.ca> Date: Mon, 22 Mar 1993 20:42:26 -0500 X-Received: by usenet.pa.dec.com; id AA22650; Tue, 23 Mar 93 02:08:30 -0800 X-Received: by inet-gw-1.pa.dec.com; id AA24296; Tue, 23 Mar 93 02:08:28 -0800 X-Received: from ocunix by mail.uunet.ca with UUCP id <10160(1)>; Tue, 23 Mar 1993 05:01:06 -0500 X-Received: by micor.OCUnix.On.Ca (smail2.5) id AA04786; 22 Mar 93 23:15:11 EST (Mon) X-Received: by sandelman.ocunix.on.ca id AA17263 (5.65a/IDA-1.4.2); Mon, 22 Mar 93 20:58:43 -0500 X-Received: by parse.ocunix.on.ca (smail2.5) id AA19250; 22 Mar 93 20:42:26 EST (Mon) X-To: alt.sys.pdp8.usenet X-Mailer: ELM [version 2.3 PL11] Lines: 14 A while ago, some mention was made of someone (Mr. Jones at U of Iowa, perhaps? sorry, don't recall) going to find out from DEC if they could distribute the binaries to various PDP-8 utilities so that people could run them on their emulators. I had a news outage for a few weeks :-( and was wondering if any progress had been made on that front. Thanks! _ _ _ _ (rk@parse.ocunix.on.ca) 278 Equestrian Dr. __\ |_) ^ |_) ( |_ SOFTWARE Kanata, ON K2M 1C5 +1 613 599 8316 (fax 8317) / | /-\ | \ _) |_ DEVICES UNIX/VMS/QNX C/ASM86 Contract Services From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!linus!linus.mitre.org!linus!jbc Tue Mar 23 15:26:32 EST 1993 Article: 200 of alt.sys.pdp8 Xref: news.columbia.edu comp.sys.dec.micro:2086 alt.sys.pdp8:200 alt.folklore.computers:40221 Newsgroups: comp.sys.dec.micro,alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!agate!linus!linus.mitre.org!linus!jbc From: jbc@linus.mitre.org (John B. Campbell) Subject: Re: LQP45 In-Reply-To: lasner@watsun.cc.columbia.edu's message of Tue, 23 Mar 1993 05:00:41 GMT Message-ID: Sender: news@linus.mitre.org (News Service) Nntp-Posting-Host: beowulf.mitre.org Organization: Research Computer Facility, The MITRE Corporation, Bedford MA References: <1993Mar23.050041.17633@news.columbia.edu> Date: Tue, 23 Mar 1993 14:37:12 GMT Lines: 48 In article <1993Mar23.050041.17633@news.columbia.edu> lasner@watsun.cc.columbia.edu (Charles Lasner) writes: > Anyone got a clue what a DEC LQP45 is? (Not LQP01, 02, 03 or 8E, but 45). > For the less-informed, it's a DEC printer of some kind. > Also, I once heard of an LQPSE; perhaps they are one and the same. If not, > what is an LQPSE? > cj "Enquiring document preparers want to know" l The LQP45 was (is) a daisy-wheel printer that DEC planned to make the successor to the LQP03. I saw a bunch of them for sale, in original cartons, a few months ago here in Boston, and almost thought of buying one to replace the LQP02 I have. But then I looked it up in the DEC Direct catalog and found that the supplies and daisy wheels were not compatible and I didn't relish buying new ones. The -45 was not notably faster than the LQP02. I have a hunch the 45 numbering scheme related to its character rate (45 cps.) in which case it's a tad slower in sprint speed than the -03. If DEC really intended the 45 to be the successor to the 03, it might be software compatible. For what it's worth, ribbons for the 45 are $$15/box -- for the LQP02/03 they're $48/box. Box might hold more ribbons, though. I don't know as much about the LQPSE. The DECDirect catalog has ribbons for the LQP01 that are the same size as for the LQP01. Ribbons for the -02 are different. Ribbons for the -03 are different still. That leads me to suspect that the SE is a pretty old mechanism. -- **************************************************************** * * * * John B. Campbell * This space * * MITRE Corporation * * * Bedford, MA 01730 * intentionally * * (617)271-3434 * * * * blank. * * * * **************************************************************** From news.columbia.edu!watsun.cc.columbia.edu!lasner Tue Mar 23 15:27:30 EST 1993 Article: 201 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: PDP-8 binaries Message-ID: <1993Mar23.200231.29875@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <9303222042.AA19250@parse.ocunix.on.ca> Date: Tue, 23 Mar 1993 20:02:31 GMT In article <9303222042.AA19250@parse.ocunix.on.ca> root@parse.ocunix.on.ca writes: > >A while ago, some mention was made of someone (Mr. Jones at U of Iowa, >perhaps? sorry, don't recall) going to find out from DEC if they could >distribute the binaries to various PDP-8 utilities so that people could >run them on their emulators. > >I had a news outage for a few weeks :-( and was wondering if any progress >had been made on that front. In point of reality, DEC doesn't actually care what we do with the binaries. Doug Jones has successfully gotten DEC to agree to his excellent reprints of various manuals, to which he has added the phrase "reprinted with permission 19xx" in the appropriate place, etc. Note that DEC doesn't do any of the work, so they are pre-supposing that the user community has the manuals in the first place. So it is with the binaries as well. Thus, while we don't have any express "permission" at this time, there is no resistance from DEC in our doing whatever we want with the programs. In any case, the logistics of the distribution of the files is where I come into the picture. (Incidentally, I am also a source of some of the binary files as well.) PDP-8 binaries come in several flavors. The most common is expressable as a stream of 8-bit paper-tape frames, and is known as BIN format. It consists of a leader of 200 octal code frames of indefinite length, followed by binary data, which includes unique codes for data, origin settings and field settings, followed by a checksum and a trailer identical to the leader. Origins are never defaulted; the tape always includes at least an initial origin, usually at 0200. Data words may be present without (many) origin settings, but the checksum just before the trailer is mandatory. Additionally, binary tapes may be "spliced" together where the trailer of one becomes the leader for the next section. This is usually done only for related binaries, where the loading of the follow-on sections is possibly optional, etc. (or an overlay). A cousin of BIN format is RIM format. The only practical difference is that, to shorten the loader code length, certain features were deleted. Each data word can only be loaded at the current origin setting; there is no automatic incrementing of the load point. Thus, RIM tapes consist of origin settings followed by data. These pairs are the bulk of the tape. Often the origin settings are in fact sequential, but of no consequence in RIM format. (P?S/8 includes utilities to convert RIM tapes to BIN tapes by optimizing out all of the origin settings that prove to be sequential; the resultant file is of course then a BIN file, not a RIM file! Also, P?S/8 can convert BIN into RIM inserting sequential origin settings, etc.) Additionally, RIM format has no checksum. It is possible to make a tape loadable by both BIN and RIM by using sequential origin settings at the source code level. Thus: *200 CLA TAD 377 HLT becomes: *200 CLA *. TAD 377 *. HLT *. The reason the final origin setting is added is to ensure that there is a sacrificial location. BIN formatting of this tape after assembly causes a checksum to appear at the end of the tape. If the RIM loader is used for this purpose, then were there not an additional origin setting, the checksum would be loaded (as garbage) over the last loaded location. Using this method it gets loaded *after* the loaded data addresses. (P?S/8's utilities that convert BIN to RIM automatically do this for the same reason.) It would appear that the most likely format we want BIN and RIM binaries stored in is a stream of 8-bit bytes in the exact order they were originally in. This also is preferred by the PDP-8 emulator authors I have spoken to, etc. Towards this end, I have written certain OS/8 utilities that can help distribute binary files. OS/8 stores files such as the above in a format that is equivalent to the stated format, just packed into twelve-bit words. The exact format is: Word[0]bits[4-11] First Byte Word[1]bits[4-11] Second Byte Word[0]bits[0-3] High-order Nybble of Third Byte Word[1]bits[0-3] Low-order Nybble of Third Byte This sequence is repeated 128 times thus storing 384 bytes in one logical record. At the driver call level, all OS/8 devices look alike in this manner. It is the responsibility of the caller to pack/unpack the data in the appropriate manner, etc. Other aspects of the system control overall file length in records, etc. ASCII and Binary files are stored this way; core-image files are stored in memory-image preceded by a header block that describes the memory allocation of the file, etc. Thus, any utility that can accurately unpack files into the 8-bit quantities described can transfer the files in their 8-bit representations according to the requirements of other systems. In the MS-DOS world (in fact almost anywhere that C exists) there exists a set of utilities to pack/unpack .BOO format files. This is a printably encoded binary format with some run-length compression capabilities, etc. It was developed originally to distribute MS-KERMIT through potential "hostile" links such as e-mail, etc. I have written PDP-8 ENBOO and DEBOO for the OS/8 family of systems. The file format is totally compatible with the MS-DOS equivalents, and since the underlying unpacking format is obeyed, ASCII and BIN and RIM files are translated correctly into byte streams as required by MS-DOS, etc. It is the user's responsibility to ensure that any CR/LF convention be obeyed correctly. This means that CR/LF of OS/8 ASCII files be handled correctly, and that incidental occurences of characters that appear to be CR or LF are not modified in binary files, etc. Thus, any PDP-8 binary paper-tape can be read into OS/8 and then converted to an OS/8 file. The OS/8 file can be encoded into .BOO format, and then sent via e-mail, etc. to another site where it can be decoded back into a byte stream. Thus we have a viable method of converting ASCII, BIN and RIM files between unlike systems, etc. For other OS/8 files, they can essentially be treated as 12-bit files with no regard for the underlying format. This includes other binary files such as .RL files, or save images (.SV), etc. To handle these files, I have written a set of utilities called ENCODE and DECODE which work with a file format intended as a replacement for uuencode or .BOO, but PDP-8 oriented. The file format includes an overall checksum, and run-length compression for 12-bit values, which often defy compression on systems where the run-length compression is only considered on 8-bit quantities. (ENCODE can compress PDP-8 binaries containing regions of HLT codes while unix LZW-compress and ZIP and .BOO will not compress the file because the objects compressed have to be multiples of 8-bits.) The intermediary file format is more robust than either .BOO or uuencode, and can accurately pass through more hostile environments, including EBCDIC sites. Unlike .BOO (and certain uuencode implementations) the file includes descriptive phrases to help define the file's purpose. User commentary is easily added and actually encouraged. The file format is immune to white-space distortions and can also pass through WPS environments. (Neither uuencode or .BOO are capable of getting through WPS because of the dependence on an overly large character set. Some EBCDIC systems are also problematic due to the presence of non-standard translation tables at some sites. ENCODE format does not depend on any characters that might be mis-translated, etc.) The file also includes both its own creation date and the file date of the original file to help in the recreation of the original file. (The file dates of the original file may have an 8-year anomaly caused by a limitation of OS/8 itself; some systems, notably MS-DOS, are incapable of expressing file dates preceding 1980 while many of these files date back to 1965. OS/8 itself can't express a date outside of the range 1970-2001. The actual date reckoned by OS/8 can be wrong by exactly 8, 16, or 24 years precisely because only the low-order 3 bits of that 32-year span are stored in the file. Other systems may have additional date resolution problems, so it's best to store the date info within the file itself.) Thus, any OS/8-expressable file may in turn be encoded for e-mail, etc. in a reliable and robust manner, complete with an internal self-description that will eliminate file confusion, etc. This should handle all of the present requirements of PDP-8 emulator authors, archivers, etc. Additionally, the ENCODE/DECODE programs have the ability to handle image files of entire devices, either whole or split into 2 roughly equal parts. Thus, it is possible to store the entire image of a bootable RX01/02 diskette as a compressed encoded file, etc. (or two smaller files). This is helpful for dealing with other systems such as bootable POLY BASIC DECtapes or P?S/8 RX01 diskettes, etc. to enable e-mail/net transfers, etc. As more device handlers become available, the ENCODE program will automatically correctly deal with them. At the present time, it is only possible to transmit a subset of an RX50 diskette via this method. The reason is that the distributed handlers for OS/278 RX50 aren't capable of addressing the entire diskette. (For each two 8-bit bytes, only 12 bits are used; the other four are zeroed rather than used for data. Additionally, track 0 is inaccessible.) Thus, usage on OS/278 for image transfer is limited to OS/278 12-bit file structure since this usage of the diskette is unique to current OS/278. (Other RX50 software generally used 8-bit mode and thus can address all bits of every byte. Some systems disallow easy access to track 0, or tracks 0, 78, 79.) I am also working on replacement handlers for OS/278 which will be full 8-bit mode. This will represent a 35% improvement in device size for all purposes, and additionally will allow the ENCODE/DECODE utility to address the entire RX50 diskette, etc. cjl From news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!caen!batcomputer!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!decus!geremin Thu Mar 25 00:35:02 EST 1993 Article: 202 of alt.sys.pdp8 Xref: news.columbia.edu alt.sys.pdp8:202 comp.org.decus:1991 Path: news.columbia.edu!sol.ctr.columbia.edu!howland.reston.ans.net!zaphod.mps.ohio-state.edu!caen!batcomputer!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!ucsvc.ucs.unimelb.edu.au!decus!geremin Newsgroups: decus.nop,decus.pdp11,decus.vax,alt.sys.pdp8,comp.org.decus Subject: DECUS NOP SIG meeting for APRIL in SYDNEY. Message-ID: <1993Mar24.213221.14528@decus.com.au> From: geremin@decus.com.au Date: 24 Mar 93 21:32:21 AEST Organization: DECUS, South Pacific Chapter Lines: 57 DISTRIBUTION: AU This is for DECUS Australia members - if you are not a member ring 02-561 5274 and get the office to send you a form. The NOP SIG is for users of Nostalgic Obsolete Products, (eg Any DEC product more than two years old 8-}.) =================================================================== Invitation to NOP SIG members and local PDP-11 ENTHUSIASTS. NOTICE of NOP SIG Meeting - 6th APRIL 1993. Pacific Digital Resale is DOWNSIZING - with BBQ. ==================================== Bill Allan from PDR has agreed to host the third meeting for 1993 of the Sydney Section of the SIG at 42B Wattle Street, Brookvale, from 4pm onwards, (with BBQ and refreshments at 6pm). Bill has decided that BIG cabinets are no longer in great demand and the first part of the meeting will be in the form of a 'trash-and-treasure' market for old cabinets, power supplies and other assorted hardware - (not only Digital labels). Here is your chance to fix that broken wheel or slide or to put all your gear into a proper cabinet. Prices will be minimal, eg around scrap metal prices - you cant lose. Bring your own tool-kit and box-trailer. Second part of the meeting will be a short talk from Bill Allan on the effects of "Downsizing in the Used Computer Arena". This will be followed by reports from various menbers on their own individual restoration projects. This will be followed by the BBQ and refreshments (the catering charge will be $10 per head). RSVP:- All network users are to reply via e-mail to IN%"gayford@decus.com.au". Others to John at Megatronics on 02-764 4855. All respondents will go into the draw for a mystery prize donated by Megatronics. Note:- Bargain hunters should arrive early as there will be limited daylight in which to work (or bring a torch). Bring a 'brolly if it rains. Tom Gayford and John Geremin for the local NOP activists, on behalf of Chester WILSON, NOP SIG Chairman. -------------------------------- 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, PDP-11 Support Consultant, MEGATRONICS, Aust. IN%"geremin@decus.com.au" voice: 61-2- 764 4855 (9am-9pm) -^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^- Help prevent brain cell deterioration - avoid using computers that contain excessive 'PLENTIUM-32' and 'PLENTIUM-64' - 8-} From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!uunet!world!bobleigh Thu Mar 25 19:00:14 EST 1993 Article: 203 of alt.sys.pdp8 Xref: news.columbia.edu alt.sys.pdp8:203 comp.sys.dec.micro:2104 Newsgroups: alt.sys.pdp8,comp.sys.dec.micro Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!darwin.sura.net!haven.umd.edu!uunet!world!bobleigh From: bobleigh@world.std.com (Bob Leigh) Subject: Re: DECmate II Video Connections Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <1993Mar20.152811.18222@news.columbia.edu> Date: Thu, 25 Mar 1993 15:45:59 GMT Lines: 23 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >Just before the recent blizzard in North America, I received (it's somewhat >"buried" at the moment, so this may have to wait for awhile) a bizarre cable. >This may be an in-house DEC special cable, but essentially, it's a cable that >on one end looks like the Rainbow cable, complete with block and three R G B >BNC leads, but the other end has *two* 15-pin connectors! (And of course, it >should be interesting figuring which 15-pin goes to which connector!) >From the information you've given, I think you may have a Rainbow dual-monitor cable. Earlier in your article, you stated: >In essence, you have a one-monitor system with the >ability to have either a VR-201 or VR-241, but not both, while a Rainbow >can have either one or the other or both... If that's what it is, then you should have one male connector (for the monochrome monitor) andand one female connector (for the Rainbow system box). I've got a document called "DUAL MONITORS ON A RAINBOW" that explains how to construct such a cable. I don't have the author's permission to post it here, but send me e-mail if you want a copy. -- Bob Leigh bobleigh@world.std.com (617) 641-2421 From news.columbia.edu!sol.ctr.columbia.edu!emory!darwin.sura.net!haven.umd.edu!uunet!world!bobleigh Thu Mar 25 19:03:28 EST 1993 Article: 204 of alt.sys.pdp8 Xref: news.columbia.edu comp.sys.dec.micro:2105 alt.sys.pdp8:204 alt.folklore.computers:40372 Newsgroups: comp.sys.dec.micro,alt.sys.pdp8,alt.folklore.computers Path: news.columbia.edu!sol.ctr.columbia.edu!emory!darwin.sura.net!haven.umd.edu!uunet!world!bobleigh From: bobleigh@world.std.com (Bob Leigh) Subject: Re: LQP45 Message-ID: Organization: The World Public Access UNIX, Brookline, MA References: <1993Mar23.050041.17633@news.columbia.edu> Date: Thu, 25 Mar 1993 15:57:14 GMT Lines: 9 lasner@watsun.cc.columbia.edu (Charles Lasner) writes: >Also, I once heard of an LQPSE; perhaps they are one and the same. If not, >what is an LQPSE? A Diablo-looking daisy-wheel printer built into a wheeled cabinet about 24" high. I saw it used with a WS211, a PDP-8-based, multi-user DEC word processor that came before the DECmate I. -- Bob Leigh bobleigh@world.std.com (617) 641-2421 From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Fri Mar 26 22:16:00 EST 1993 Article: 205 of alt.sys.pdp8 Xref: news.columbia.edu comp.sys.dec.micro:2108 alt.sys.pdp8:205 Newsgroups: comp.sys.dec.micro,alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: OS/78 marketing flyer Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar26.045325.16365@news.uiowa.edu> Date: Fri, 26 Mar 1993 04:53:25 GMT Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 20 In among a crate of old DECtapes I just rescued, I found a nice flyer that begins: OS/78 A powerful, small computer operating system The flyer lists high level languages (BASIC, FORTRAN) that run under OS/78, it lists the software tools and utility programs that come with OS/78, and more. It ends with a section on "When do you need an operating system," followed by a short list of OS/78 features. The pamphlet is copyright 1980, and is obviously immensely valuable only to someone with a DECmate or similar beast running OS/78. So, if you want the flyer, just send me a postal address, and it's yours! Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Mon Mar 29 13:18:51 EST 1993 Article: 206 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Teeny Tiny RX01 Bootstrap Message-ID: <1993Mar29.171612.23495@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University Date: Mon, 29 Mar 1993 17:16:12 GMT By popular demand, here is the tiny bootstrap for the RX01. It is for drive zero only, does not retry indefinitely, depends on the "kerclunka" self-test to do the reading for it, and is either for actual RX01 or compatible, or for RX02 set for RX01 mode only. There are only 13 significent words to load, and a bunch of zeroes in a row (which must be 0000) and one don't care location (a subroutine header) which can be loaded with the previous or next location's contents to save a switch setting operation, etc. / TINY RX01 DRIVE ZERO ONLY BOOTSTRAP. *33 /STARTS LOADING HERE 00033 6755 SHANGG, SDN /BOOTSTRAP STARTS HERE; DONE FLAG UP? 00034 5054 JMP SLODE1 /TRY TRANSFER FLAG IF DONE FLAG IS NOT UP 00035 7326 NL0002 /SETUP FOR EMPTYING 00036 6751 LCD /LOAD THE COMMAND 00037 0000 ZBLOCK SLP-. /0000'S WILL EXECUTE AND FALL THROUGH TO SLP! 00040 0000 00041 0000 00042 0000 00043 0000 00044 0000 00045 0000 00046 0000 00047 4053 SLP, JMS SLODE /GET A WORD 00050 3002 SLPSTR, DCA SBOOT&177+2 /PUT A WORD 00051 2050 ISZ SLPSTR /BUMP TO NEXT WORD 00052 5047 JMP SLP /KEEP GOING UNTIL SLP IS OVERLAYED! 00053 5047 SLODE, .-. /LOAD A WORD ROUTINE;OK to use same as previous or following or anything else 00054 6753 SLODE1, STR /WORD READY? 00055 5033 JMP SHANGG /NO, TRY DONE 00056 6752 XDR /YES, GET A WORD 00057 5453 JMP I SLODE /RETURN 00060 7004 SBU, 0^20+7004 /INDICATE UNIT ZERO TO NEXT LEVEL This is the shortest way to get an RX system going by hand. cjl From news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news Tue Mar 30 13:08:55 EST 1993 Article: 207 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Subject: Re: Teeny Tiny RX01 Bootstrap Sender: news@news.uiowa.edu (News) Message-ID: <1993Mar29.205751.12440@news.uiowa.edu> Date: Mon, 29 Mar 1993 20:57:51 GMT References: <1993Mar29.171612.23495@news.columbia.edu> Nntp-Posting-Host: pyrite.cs.uiowa.edu Organization: University of Iowa, Iowa City, IA, USA Lines: 23 >From article <1993Mar29.171612.23495@news.columbia.edu>, by lasner@watsun.cc.columbia.edu (Charles Lasner): > 00037 0000 ZBLOCK SLP-. > 00040 0000 > 00041 0000 > 00042 0000 > 00043 0000 > 00044 0000 > 00045 0000 > 00046 0000 > > 00047 4053 SLP, JMS SLODE This is a wonderful bit of code! My assembler sure wouldn't have guessed how many zeros to make from the source you've given. In fact, any number of zeros, including zero, would have worked here! Obviously, there was a prologue prior to the code you gave that specified an initial value for SLP so that pass 1 of the assembler could figure out how many zeros to put out! Doug Jones jones@cs.uiowa.edu From news.columbia.edu!watsun.cc.columbia.edu!lasner Tue Mar 30 13:09:14 EST 1993 Article: 208 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: news.columbia.edu!watsun.cc.columbia.edu!lasner From: lasner@watsun.cc.columbia.edu (Charles Lasner) Subject: Re: Teeny Tiny RX01 Bootstrap Message-ID: <1993Mar30.172316.10887@news.columbia.edu> Sender: usenet@news.columbia.edu (The Network News) Nntp-Posting-Host: watsun.cc.columbia.edu Reply-To: lasner@watsun.cc.columbia.edu (Charles Lasner) Organization: Columbia University References: <1993Mar29.171612.23495@news.columbia.edu> <1993Mar29.205751.12440@news.uiowa.edu> Date: Tue, 30 Mar 1993 17:23:16 GMT In article <1993Mar29.205751.12440@news.uiowa.edu> jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) writes: >From article <1993Mar29.171612.23495@news.columbia.edu>, >by lasner@watsun.cc.columbia.edu (Charles Lasner): > >> 00037 0000 ZBLOCK SLP-. >> 00040 0000 >> 00041 0000 >> 00042 0000 >> 00043 0000 >> 00044 0000 >> 00045 0000 >> 00046 0000 >> >> 00047 4053 SLP, JMS SLODE > >This is a wonderful bit of code! My assembler sure wouldn't have guessed >how many zeros to make from the source you've given. In fact, any number >of zeros, including zero, would have worked here! Obviously, there was >a prologue prior to the code you gave that specified an initial value >for SLP so that pass 1 of the assembler could figure out how many zeros >to put out! > > Doug Jones > jones@cs.uiowa.edu Yes, smart, ain't it! :-) Actually, the entire output is contrived because: 1) It is a fragment ripped out of a larger source (The P?S/8 RX non-system handler) file and thus lacks certain definitions. Also, did you expect that the RX definitions would also be predefined in the assembler? :-). 2) PDP-8 assemblers don't usually output those 0000 words the way stated in the file (PAL-10 actually does something like that in some early versions), and instead would just output the first of the zeroes. The next generated word would follow at the appropriate location. 3) There is a deliberate falsehood in the file. The location of the subroutine header is shown as ".-." which is a convention for a 0000 value as a placeholder only, not that literally 0000 is required to be stored there, etc. When the program executes, the stored PC goes there, so contents is totally unimportant. However, the contrived listing showed the same octal value as the previous location. This is to aid in toggling in the values since it means to just press DEP twice without actually changing the switch register. (I did indicate that the location might as well be the same value as either the previous or next word to avoid the unnecessary manual step. This altering of the listing is thus contrary to the related source lines, but in fact the best thing to place there for the purpose, etc.) So, there isn't any assembler "magic" at work here :-). In any case, this was posted here as a source guide to the octal numbers that need to be used for a manual boot in the shortest, least painful way. cj "let your fingers do the walking" l