From krause@azu.informatik.uni-stuttgart.de Thu Sep 1 06:05:57 EDT 1994 Article: 1030 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!math.ohio-state.edu!jussieu.fr!univ-lyon1.fr!swidir.switch.ch!scsing.switch.ch!news.belwue.de!news.informatik.uni-stuttgart.de!news From: krause@azu.informatik.uni-stuttgart.de (krause) Subject: Re: PDP-8 emulator Message-ID: Sender: news@informatik.uni-stuttgart.de Organization: Informatik, Uni Stuttgart, Germany Date: Tue, 30 Aug 1994 12:46:37 GMT Lines: 21 I put our pdp-8 emulator to the incoming directory of sunsite.unc.edu. In the moment it is in /pub/academic/computer-science/history/pdp-8/incoming I'll email to CJL to put it somewhere in .../pdp-8/emulator or so. Our emulator is running on 80386's and up under MSDOS (NO x, NO windows: raw vast TEXTMODE.) We are adult computer users and no kindergarten. You have to pkxarc the tm_pdp8.arc and just type: EMU I hope for you, that you have a keyboard that allows CapsLock, because ShiftLock is no fun with OS/8 Klemens Krause krause@azu.uni-stuttgart.de From ars@world.std.com Thu Sep 1 06:07:20 EDT 1994 Article: 1031 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!eff!news.kei.com!world!ars From: ars@world.std.com (Alan R Sieving) Subject: VT278 / DecMate available. Message-ID: Organization: The World Public Access UNIX, Brookline, MA Date: Wed, 31 Aug 1994 02:38:02 GMT Lines: 29 Hi- A coworker recently acquired a VT278/Decmate? which we don't know the condition of, nor do we have any need for it. As I am not an '8 person (we do 11s) I'll describe it, and you can tell me if it is worthwhile. It is a VT100-like chassis/CRT with keyboard, and a quad sized backplane in the back. There are two boards in the backplane, a board with Comm 0 and 1, and a board with connectors for Disk, Printer, and the keyboard. The Comm board (M8437) has 2 2651's, and two empty 40 pin sockets. The CPU board (M8436) has two 6402's, two 6121's, a 6120, and six Sips, with four 4116's on each. The boards date from 1982. Again, condition is unknown. (If I plug it in, do I need a disk? I can tell the boards are in the backplane with the right orientation, but is there a specific slot order?) Does anyone want this for parts? Is it worth the cost of shipping? (Or should I keep the CRT for a spare?) In an unrelated question, How did DEC decide on the M-number assignments? They obviously aren't ordered by age, so how did these numbers get assigned? Thanks! -- --al. Alan Sieving, ars@quickware.com or ars@world.std.com Quickware Engineering & Design, 225 Riverview Ave Waltham, MA, 02154-3874 W: 617-647-3800, FAX: 617-647-3311 800-237-1185 for fast PDP-11's. From crisis@netcom.com Thu Sep 1 06:07:52 EDT 1994 Article: 1032 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!agate!darkstar.UCSC.EDU!news.hal.COM!decwrl!netcomsv!netcom.com!crisis From: crisis@netcom.com (Crisis Computer Corp) Subject: DEC pdp8F! Message-ID: Keywords: pdp8f Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Thu, 1 Sep 1994 00:21:18 GMT Lines: 14 Can anybody tell me the difference between a pdp8e from a pdp8f? Basic board set are the same but "e" and "f" has to have a reason. I'd appreciate a reply either through this newsgroup or e-mail me at crisis@netcom.com Neph Medina 800/726-0726 408/270-1100 USA 408/270-1183 FAX From jones@pyrite.cs.uiowa.edu Fri Sep 2 13:11:35 EDT 1994 Article: 1033 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: Re: DEC pdp8F! Date: 1 Sep 1994 13:59:33 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 50 Distribution: world Message-ID: <344mo5$ee6@nexus.uiowa.edu> References: NNTP-Posting-Host: pyrite.cs.uiowa.edu >From article , by crisis@netcom.com (Crisis Computer Corp): > Can anybody tell me the difference between a pdp8e from a pdp8f? > Basic board set are the same but "e" and "f" has to have a reason. The power supply difference: An 8/E uses linear regulators, while an 8/F uses a switcher. The difference is measured in pounds and watts, and is significant! The front panel difference: An 8/E uses incandescent lamps, while an 8/F uses LEDs. Late 8/E systems used 8/F front panels. Box size: The 8/E had room for 2 backplane modules of 20 slots each, knock off one one for the front panel and 2 for the jumper, and that means you could put 37 boards in the machine. The 8/E power supply was big enough for that load. The 8/F had room for only 1 backplane module, so you could put 19 boards in it. The power supply was downsized accordingly. In performance, they were identical. If you added external expansion boxes, they could be expanded to similarly huge configurations. If you wanted a minimal system, however (and most PDP-8 systems ever sold were pretty minimal), the 8/F came in at a lower cost. Now, a far harder question? What was the difference between the 8/F and the 8/M? One correct answer: The difference in silkscreen lettering on the front panel insert. Actually, the 8/M was an OEM machine, and most were sold with only a blank minimal function panel on the front. The 8/F was sold to end users who didn't need the expansion capability of the 8/E, so most were sold with full function front panels. All the same options applied to the 8/F and 8/M, however. It's all in the FAQ, next posting scheduled Oct 8, but you can look at the most recent version in the archives on: ftp://rtfm.mit.edu/pub/usenet/alt.sys.pdp8 ftp://ftp.uu.net/usenet/news.answers/dec-faq ftp://src.doc.ic.ac.uk:/pub/usenet/news.answers/alt.sys.pdp8 ftp://sunsite.unc.edu/pub/academic/computer-science/history/pdp-8/docs Automatic translations of the FAQ to HTML format (as used by World Wide Web) are available from: http://www.cis.ohio-state.edu/hypertext/faq/usenet/dec-faq/top.html Doug Jones jones@cs.uiowa.edu From jones@pyrite.cs.uiowa.edu Fri Sep 2 13:13:52 EDT 1994 Article: 1034 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8 Subject: RX01 boot problems Date: 1 Sep 1994 20:57:55 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 32 Distribution: world Message-ID: <345f8j$rdk@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu I'm trying to use some RX01 images I got from people out on the net, and I think I'm being messed up by interleaving. The disks were sent to me as 8 bit images, as read on some other (non PDP-8) system, and I don't know how the software that read the disks interleaved the sectors. If I had some idea what physical sector 2 of the disk was supposed to contain, I think I'd have a good chance of reconstructing things. Anyway, here's sector 1 of track 1 of my OS8 disk image. I did some disassembly and it makes a bit of sense, but I'd like it if somebody could verify that this is indeed the right start. 0000: 7577 0001 4021 3044 6201 1002 3017 4021 0010: 4021 1060 3420 6757 4402 7645 7623 0004 0020: 7126 1060 6751 7326 1003 4053 3003 7201 0030: 4053 6755 5054 6754 7410 7402 7450 5421 0040: 7326 6751 6211 4053 3417 5044 0000 7607 0050: 7607 0000 0000 0000 0000 0000 0000 0000 0060: 0000 0000 0000 0000 0000 0000 0000 6202 0070: 4207 1000 0000 0007 7746 6203 5677 0400 So, could someone verify that this is indeed what is expected on physical sector 1 of track 1, and could someone tell me what should be on physical sector 2 of track 1 (or alternately, tell me what physical sector number is used for logical sector 2, and tell me the expected contents of that sector). Also, CJL, some time ago, posted code for a minimal RX01 bootstrap. Is it sitting on one of the archive sites where I can grab it? Doug Jones jones@cs.uiowa.edu From bill@sydney.dialix.oz.au Mon Sep 5 02:36:38 EDT 1994 Article: 1035 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news-feed-1.peachnet.edu!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!munnari.oz.au!news.uwa.edu.au!DIALix!not-for-mail From: support@perth.DIALix.oz.au (DIALix Support Person) Newsgroups: alt.sys.pdp8 Subject: PDP 8-I parts for sale (Australia) Date: 4 Sep 1994 11:05:58 +0800 Organization: DIALix Services, Perth, Western Australia Lines: 10 Sender: support@perth.DIALix.oz.au Message-ID: <34bdim$h11$1@perth.dialix.oz.au> Reply-To: bill@sydney.dialix.oz.au NNTP-Posting-Host: perth.dialix.oz.au X-Newsreader: NN version 6.5.0 #5 (NOV) I have many cards from a pdp 8-i which I saved when we removed two units. Please make an offer for any cards or parts of an upper memory unit etc. Email to bill@sydney.dialix.oz.au Thanks! JS (posting for WJ) From lasner@sunSITE.unc.edu Mon Sep 5 02:37:02 EDT 1994 Article: 1036 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp10,comp.sys.dec,alt.sys.pdp8 Subject: Re: alt.sys.pdp10 created Date: 5 Sep 1994 06:04:42 GMT Organization: University of North Carolina, Chapel Hill Lines: 21 Message-ID: <34ecdq$14ua@bigblue.oit.unc.edu> References: <33vs4g$nnc@ss1.digex.net> <1SEP199422365826@siva.bris.ac.uk> <34644a$i5s@ss1.digex.net> NNTP-Posting-Host: calzone.oit.unc.edu Xref: bigblue.oit.unc.edu alt.sys.pdp10:40 comp.sys.dec:22424 alt.sys.pdp8:1036 In article <34644a$i5s@ss1.digex.net>, Doug Humphrey wrote: >You can keep your Integrated Circuits, and leave the REAL systems >(with TRANSISTORS) to the like of ME! ;-) ;-) ;-) What do you mean TRANSISTORS! The LINC-8 comes in the same cabinet as the KA-10, and it also has TUBES besides R,S,B series. LINC-8 drives are held together with rubber drive belts and relays. Your new-fangled TU55 (Solid State DECtape) drives only have head relays. > >Peace, OK, a pax upon you. > >Doug cjl From asvirsky@lynx.dac.neu.edu Wed Sep 7 19:45:04 EDT 1994 Article: 1037 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!fastrac.llnl.gov!osi-east2.es.net!cronkite.nersc.gov!dancer.ca.sandia.gov!overload.lbl.gov!dog.ee.lbl.gov!ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!howland.reston.ans.net!noc.near.net!chaos.dac.neu.edu!lynx.dac.neu.edu!asvirsky From: asvirsky@lynx.dac.neu.edu (alex svirsky) Newsgroups: alt.sys.pdp8 Subject: DECmate II and os/278 Date: 6 Sep 1994 18:02:04 GMT Organization: Northeastern University, Boston, MA. 02115, USA Lines: 28 Message-ID: <34iaqs$ast@chaos.dac.neu.edu> NNTP-Posting-Host: lynx.dac.neu.edu X-Newsreader: TIN [version 1.2 PL1] Hi! A couple of days ago I made an os/278 system disk for the DECmate, from the Teledisk file, and I have been playing with it since, but I have a couple questions: I have been trying to set up basic for os/278 with no luck. I got basic.pa, basic.tx, bcomp.pa, and bload.pa from sunsite.unc.edu, and I followed the instructions regarding pal, load and save found in the *.pa file headers. With basic.sv, bload.sv, and bcomp.sv on rx50: typing "basic" gets the RX50 spinning and the heads move a bit, and then the message "INCOMPLETE SYSTEM" appears and I get the system prompt. I am using a DECmate II with ROM 31Z if that makes any difference. I haven't tried it on my DECmate III yet. I also tried to get focal to work, but didn't seem to have much luck with that. I assume it is because it wasn't written for the DECmate. Is there an os/278 version? I am unfamiliar with most programming except for basic, but I am trying to change that. I got a copy of DEC's Intro to Programming for the PDP8 (1969). It has been useful. Another question came up while writing this. Kermit-278 froze 4 times while writing this post. The only fix I know of is to exit Kermit and run it again from the prompt. It happens while typing rapidly while the host trys to update the screen. It's a long list of questions, but people here seem to know what they are talking about. Thanks for the help! Alex Svirsky asvirsky@lynx.neu.edu From asvirsky@lynx.dac.neu.edu Thu Sep 8 05:54:20 EDT 1994 Article: 1038 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!news2.near.net!noc.near.net!chaos.dac.neu.edu!lynx.dac.neu.edu!asvirsky From: asvirsky@lynx.dac.neu.edu (alex svirsky) Newsgroups: alt.sys.pdp8 Subject: DECmate II and os/278 Date: 6 Sep 1994 21:54:55 GMT Organization: Northeastern University, Boston, MA. 02115, USA Lines: 8 Message-ID: <34ioff$fha@chaos.dac.neu.edu> NNTP-Posting-Host: lynx.dac.neu.edu X-Newsreader: TIN [version 1.2 PL1] Regarding basic and os/278: uh.. never mind. I found brts.pa and math.pa and things seem to work fine now. I am still wondering though if focal works on the DECmate. Thanks again for your help. Alex Svirsky asvirsky@lynx.neu.edu From smj@sdf.lonestar.org Thu Sep 8 05:54:46 EDT 1994 Article: 1039 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!gatech!howland.reston.ans.net!cs.utexas.edu!convex!egsner!sdf!smj From: smj@sdf.lonestar.org (Stephen M. Jones) Subject: BASIC on the decmate .. lets have some fun. Message-ID: Organization: sdf public access UNIX - dallas, tx.. 1 + 214/248.9811 Date: Sat, 3 Sep 1994 16:55:09 GMT Lines: 28 If anyone is up to writing some games for the DECmate pdp8 machines, it could be alot of fun. I have just received the volume 1.1 and volume 2. There is a great version of Pac-Man on there called 'DECmaze/DECman' in which you are DEC and you must evade the IBM, Tandy, WANG and Apple corporations while you collect sales (eat dots). I wrote a very simple and disgusting Pac-Fag in IBM basic years ago, but this DECmaze is wonderful. The maze is dynamic on each round. There is also a Q-bert clone called DEC-bert ... I advise you to turn your bell down or off .. you may be annoyed. So I am going to try and get the basic interpreter on my machine and start on some game hacking when I get some time. It should be fun. This means my Decmate is not forsale anymore :( ... However, if you DO need a DECmate II or III, contact me. I may be able to DIG up something for you. some ideas I'd like to see: DECdug (digdug) DECipede (err ..) DECycles (tron light cycles/surround) DECong (pong) and others of course... hey .. don't ask me when I will be done with them :) -- stephen m. jones ... smj@sdf.lonestar.org From lasner@sunSITE.unc.edu Thu Sep 8 05:59:06 EDT 1994 Article: 1040 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: DECmate II and os/278 Date: 8 Sep 1994 09:53:54 GMT Organization: University of North Carolina, Chapel Hill Lines: 132 Message-ID: <34mmvi$o50@bigblue.oit.unc.edu> References: <34iaqs$ast@chaos.dac.neu.edu> NNTP-Posting-Host: calzone.oit.unc.edu In article <34iaqs$ast@chaos.dac.neu.edu>, alex svirsky wrote: > Hi! A couple of days ago I made an os/278 system disk for >the DECmate, from the Teledisk file, and I have been playing with it >since, but I have a couple questions: > I have been trying to set up basic for os/278 with no luck. I >got basic.pa, basic.tx, bcomp.pa, and bload.pa from sunsite.unc.edu, and >I followed the instructions regarding pal, load and save found in the >*.pa file headers. With basic.sv, bload.sv, and bcomp.sv on rx50: >typing "basic" gets the RX50 spinning and the heads move a bit, and then >the message "INCOMPLETE SYSTEM" appears and I get the system prompt. I >am using a DECmate II with ROM 31Z if that makes any difference. I >haven't tried it on my DECmate III yet. Using the DECmate II with the 31Z ROM revision means a few things, but not anything you mentioned. But since you do have one of these things, let me elaborate: 1) All of these revision machines were *supposed* to be eliminated in favor of upgrades. Clearly they were not! 2) Some of them have an unreliable RX50 circuit which is easily fixed by a few wires worth of ECO. If you lack a few green wires near the RX50 connector, then you need to upgrade. Contact pjhurst@mcimail.com for details of all hardwre upgrades except for ROM's; I do those :-). 3) Assuming the few green wires are present, you most certainly won't have the big ECO that adds scads of green wires. The most obvious sign is lack of the graphics board two-prong connector on the area underneath the graphics board-specific connector. Newer boards have the connector soldered into the board; older ones have it glued on and connected to ECO green wires. 31Z goes away along with this ECO, thus it would be bizarre that you have old ROM's on a newer board, etc. 4) Unless the graphics ECO is done, you can't use the graphics board option, but if you upgrade the ROM set, you can use anything else, including the APU/XPU boards, RX78 or hard disk and controller. The APU/XPU is not afected by the ROM revision. 5) Version 31Z is ignorant of the newer format of slushware. It loads it in (painfully slowly) in the wrong format! The newer-type slushware actually checks for this, and includes a routine for the benefit of 31Z that *reloads* all of the slushware all over again (also painfully slowly!) in the proper format. (The first slushware block is always read in by any version correctly. Within this block is the code that checks if the other 19 blocks were misread, etc.) You can really get noticeable boot time improvement if you use a system written on an optimized diskette (using FDFORMAT, TELEDISK, etc.) since this is literally the worst-case of all DECmates. (Better still, also upgrade the ROM's!) 6) Newer slushware expects the ROM to handle four functions correctly: i) Setup panel ii) Halt panel iii) RX50 boot operation iv) Boot-best-available-device operation Note that on DECmate III or floppy-only DECmate II function iv becomes function iii. If the ROM is 31Z, then all operations become i which is incorrect. The most annoying is that HLT shouldn't go to SETUP, since it means you can't continue from the HLT, etc. 7) A hard disk isn't supported at all. Obsolete attempts are made to control a possible hard disk, but this is thoroughly obsolete, and not supported in the released version of the disk controller, etc. Re BASIC: Try adding a copy of BRTS.SV. > I also tried to get focal to work, but didn't seem to have much >luck with that. I assume it is because it wasn't written for the >DECmate. Is there an os/278 version? You may be a victim of stray interrupts. In spite of the incompatibility, FOCAL's lame console handling is compatible with the subset of the real -8 interface simulated in the DECmate! You may need to incorporate a patch to inhibit some devices, etc. > I am unfamiliar with most programming except for basic, but I am >trying to change that. I got a copy of DEC's Intro to Programming for >the PDP8 (1969). It has been useful. Only if you avoid any advanced discussion of peripherals will it be useful! > Another question came up while writing this. Kermit-278 froze 4 >times while writing this post. The only fix I know of is to exit Kermit >and run it again from the prompt. It happens while typing rapidly while >the host trys to update the screen. Yes, a known limitation is that for high-speed connections, this can happen especially if the screen support for a VT-100 family terminal is enabled. One of my long-term projects is to rewrite the slushware to allow "hooks" for comm port character grabbers. The problem stems from the fact that the DECmate simulates a VT-220-like terminal in CP memory which is enterred by trapping the console instructions, etc. Since the comm port is a real, semi-normal interrupting peripheral, these CP routines might take too long to get back to the -8 code that is the terminal program within Kermit-12. PDP-8-style interrupts are *not* a solution to this problem! The only way to handle it is to allow for comm port character buffering *during* the CP memory routines. Note that CP memory is not interruptible by the comm port, but the comm port flags can be checked, and the characters grabbed, etc. A complication is that the flag is shared by the output as well as the input, thus a calling program (such as a replacement for Kermit's terminal routine) would have to check periodically for CP-induced output flag changes, as well as CP-induced buffered characters, etc. Anyone familiar with the last few versions of TECO-8 will understand the logic here. In TECO-8 the high-speed escape sequences of a console terminal could get lost; buffering routines called by highly used subroutines guaranteed that characters wouldn't get lost. Lossage of this type isn't possible in the simulated case of the DECmate, but instead this output problem is present, etc. > > It's a long list of questions, but people here seem to know what >they are talking about. Hope that makes a dent in it :-). > > Thanks for the help! > Alex Svirsky asvirsky@lynx.neu.edu > cjl From daigneault@aeolus.enet.dec.com Sat Sep 17 06:45:44 EDT 1994 Article: 1041 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!enews.sgi.com!decwrl!pa.dec.com!mrnews.mro.dec.com!aeolus.enet.dec.com!daigneault From: daigneault@aeolus.enet.dec.com (Dan Daigneault) Newsgroups: alt.sys.pdp8 Subject: VT278/RX02/LQP02 for sale Eastern MA Date: 13 Sep 1994 17:16:26 GMT Organization: DIGITAL Equipment Corp. Lines: 15 Distribution: world Message-ID: <354mpa$re0@mrnews.mro.dec.com> Reply-To: daigneault@aeolus.enet.dec.com (Dan Daigneault) NNTP-Posting-Host: aeolus.enet.dec.com X-Newsreader: mxrn 6.18-10 Hi, I have a VT278 and RX02 on/in a terminal stand that holds the VT and an RX0*. It has a com board installed and DF03 external 1200 baud modem. Also a serial LQP02 printer on an LQP01 printert stand. Some spare boards, power supply, and lots of RX0* floppy disks. Prints and some documentation. And its all for sale... I'd like $125 for the whole lot. I might even deliver with in reason. (Suject to my interpretation of reasonable). If you want it shipped out side of this area you pay the shipping. Inqueries to DAIGNEAULT@AEOLUS.ENET.DEC.COM Regards, DanD From jones@pyrite.cs.uiowa.edu Sat Sep 17 06:46:10 EDT 1994 Article: 1042 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!math.ohio-state.edu!hobbes.physics.uiowa.edu!news.uiowa.edu!news From: jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.sys.pdp8,comp.emulators.misc Subject: World Wide Web PDP-8 stuff Date: 16 Sep 1994 21:58:37 GMT Organization: University of Iowa, Iowa City, IA, USA Lines: 14 Distribution: world Message-ID: <35d4ed$f75@nexus.uiowa.edu> NNTP-Posting-Host: pyrite.cs.uiowa.edu Xref: bigblue.oit.unc.edu alt.sys.pdp8:1042 comp.emulators.misc:1195 Now that we have stable support for World Wide Web here at Iowa, I've begun to move some stuff I've been working on to WWW for export. This includes a bunch of PDP-8 material, which I will slowly make available from the following URL: http://cs.uiowa.edu/~jones/pdp8/index.html Right now, about the only stuff I have there are the HTML versions of the 1965 and 1967 PDP-8 reference cards (reproduced with permission). I hope to get the 1974 card out soon, and when I have other PDP-8 material ready for export, it'll get indexed in the same page. Doug Jones jones@cs.uiowa.edu From dcb@tauon.ph.unimelb.edu.au Tue Sep 20 01:00:38 EDT 1994 Article: 1043 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!swrinde!ihnp4.ucsd.edu!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!tauon!dcb From: dcb@tauon.ph.unimelb.edu.au (David Bell) Newsgroups: alt.sys.pdp8 Subject: DECmate: what is CLI???? Date: 20 Sep 1994 00:14:50 GMT Organization: University of Melbourne Lines: 24 Message-ID: <35l9hq$nn1@ariel.ucs.unimelb.EDU.AU> NNTP-Posting-Host: tauon.ph.unimelb.edu.au X-Newsreader: TIN [version 1.2 PL2] I recently got a decmate! however it's lacking a APU and XPU it's a DECmateIII I found the boot disks on sunsite but when I go to run the games disks, I get CLI not loaded so I need to know how to load the CLI (which I assume is the Command Line Interpreter) and then run the games disk. Thanks The DECmate faq doesn't seem to answer this question, it there a users manual on the net? Thanks David -- ---------------------------------------------------------------------- David Bell |E-mail: dcb@electron.ph.unimelb.edu.au School of Physics |Phone : +61 3 344 5451 The University of Melbourne |Fax : +61 3 344 4783 Parkville, Victoria, AUST, 3052 | From lasner@.unc.edu Tue Sep 20 01:00:54 EDT 1994 Article: 1044 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!!lasner From: lasner@.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: DECmate: what is CLI???? Date: 20 Sep 1994 05:00:35 GMT Organization: University of North Carolina, Chapel Hill Lines: 70 Message-ID: <35lq9j$vc3@bigblue.oit.unc.edu> References: <35l9hq$nn1@ariel.ucs.unimelb.edu.au> NNTP-Posting-Host: calzone.oit.unc.edu In article <35l9hq$nn1@ariel.ucs.unimelb.edu.au>, David Bell wrote: >I recently got a decmate! >however it's lacking a APU and XPU it's a DECmateIII So, it doesn't have the optional APU! There's more to the world than CP/M-80 and the ability to run DECspell and footnote formatter from WPS :-). DECmate III doesn't ever have XPU, just a vicious rumor, never sold by DEC. > >I found the boot disks on sunsite but when I go to run the >games disks, I get CLI not loaded so I need to know how >to load the CLI (which I assume is the Command Line Interpreter) >and then run the games disk. There are no "boot disks" for the DECmate III, which has no hard disk. Instead, each of several O/Ses runs from its own diskette. In the case of OS/278, there are data-only diskettes (non-system), but the games disk is not meant to be used that way, i.e., it's an actual stand-alone bootable system unto itself, and must be used that way. BTW, the message should be about CCL not loaded. You're not too far off, but that's actually an option to the command interpreter. OS/8 follows the original DEC-10 notion of the Concise Command Language on top of specific commands. Thus, the following commands are identical in performance: To run the PAL8 assembler to create the binary file BAR.BN from the PAL source file FOO.PA, you can type .R PAL8 *BAR.BN >Thanks > >The DECmate faq doesn't seem to answer this question, >it there a users manual on the net? Again, the problem is that this is a versatile machine that has lots of unrelated operating systems for it. The hard disk machines even have an "umbrella" system to coordinate which system is desired called Master Menu. Some of these systems are independently documented, others not so much, etc. > >Thanks > >David > > >-- >---------------------------------------------------------------------- >David Bell |E-mail: dcb@electron.ph.unimelb.edu.au >School of Physics |Phone : +61 3 344 5451 >The University of Melbourne |Fax : +61 3 344 4783 >Parkville, Victoria, AUST, 3052 | cjl From moisan@bronze.lcs.mit.edu Sat Sep 24 05:47:41 EDT 1994 Article: 1045 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!uwm.edu!cs.utexas.edu!usc!bloom-beacon.mit.edu!ai-lab!bronze.lcs.mit.edu!not-for-mail From: moisan@bronze.lcs.mit.edu (David Moisan) Newsgroups: alt.sys.pdp8 Subject: Re: CLL and PIP under OS/278 Date: 22 Sep 1994 19:13:44 -0400 Organization: Guest of MIT AI Lab Lines: 35 Message-ID: <35t338$5h8@bronze.lcs.mit.edu> References: <35l9hq$nn1@ariel.ucs.unimelb.edu.au> <35lq9j$vc3@bigblue.oit.unc.edu> NNTP-Posting-Host: bronze.ai.mit.edu In article <35lq9j$vc3@bigblue.oit.unc.edu>, Charles Lasner wrote: >recommended to be disabled! In any case, the first form is always >supported while you need CCL enabled to perform the second form, etc. Hmm. I tried running PIP that way, like I used to do on the other DEC systems I used, RT-11 and RSTS, but got this: .R PIP BAD IMAGE There are several commands in the CLL that use PIP (as specified in the helptext), and they worked fine. I infer that PIP.SV wasn't meant to run alone, but must be invoked by the CLL. Too bad, really, I was very accustomed to the DEC way of doing things in the -11 series. I really should snarf the OS/278 source off of sunsite and look at it. >>The DECmate faq doesn't seem to answer this question, >>it there a users manual on the net? > If I didn't already have two FAQ's to write (the GE Superradio FAQ and the RTTY/FAX FAQ), I'd take on this one. As Charles says, there are several operating systems available for the DECmates, but there is still room for a basic FAQ with pointers to Charles' stuff, basic hints on OS/278 and CP/M (the most common OS's you will see, especially if you're a hacker :) and basic care and feeding suggestions. Dave -- | David Moisan, N1KGH /^\_/^\ moisan@bronze.lcs.mit.edu | | 86 Essex St. Apt #204 ( o ^ o ) n1kgh@amsat.org | | Salem. MA 01970-5225 | | ce393@cleveland.freenet.edu | | | From jankowiak@fallout.lonestar.org Wed Sep 28 03:33:27 EDT 1994 Article: 1046 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!wupost!news.utdallas.edu!feenix.metronet.com!montagar!fallout!jankowiak Newsgroups: alt.sys.pdp8 Subject: PDP-8 stuff Message-ID: <1994Sep26.212409.12141@fallout.lonestar.org> From: jankowiak@fallout.lonestar.org Date: 26 Sep 94 21:24:09 CST Organization: DECUS DFWLUG BBS *Dallas*TX*214-270-3313 Lines: 5 I still curse myself for not buying a PDP-8 at "ham-com" for $20 several' years ago. the guy said it didn't work, but it would have made a nice thing to look at. (this was before I knew what a pdp-8 was..) From kgg@mv.mv.com Wed Sep 28 11:38:09 EDT 1994 Article: 1047 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!howland.reston.ans.net!news.sprintlink.net!mv!mv.mv.com!kgg From: kgg@mv.mv.com (Kenn Goutal) Subject: sunsite.unc.edu Message-ID: Nntp-Posting-Host: mv.mv.com Sender: usenet@mv.mv.com (System Administrator) Organization: MV Communications, Inc. Date: Wed, 28 Sep 1994 05:23:05 GMT Lines: 6 Tried to ftp to sunsite.unc.edu, got timed out. Is this a valid ftp site, home of pdp8 stuff? Thanks, -- Kenn Goutal kenn@mv.mv.com http://www.mv.com/users/kgg/kenn.html From moisan@bronze.lcs.mit.edu Fri Sep 30 03:51:17 EDT 1994 Article: 1048 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!gatech!howland.reston.ans.net!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!bronze.lcs.mit.edu!not-for-mail From: moisan@bronze.lcs.mit.edu (David Moisan) Newsgroups: comp.sys.dec.micro,comp.os.cpm,alt.sys.pdp8,rec.radio.amateur.digital.misc Subject: Re: a scary idea for the DEC Rainbow Date: 28 Sep 1994 16:48:34 -0400 Organization: Guest of MIT AI and LCS labs Lines: 46 Message-ID: <36ckr2$2q7@bronze.lcs.mit.edu> References: <36c47b$msa@vixen.cso.uiuc.edu> NNTP-Posting-Host: bronze.ai.mit.edu Summary: You are not the only one wanting KA9Q, albeit for a DECmate Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3167 comp.os.cpm:7348 alt.sys.pdp8:1048 rec.radio.amateur.digital.misc:4912 In article <36c47b$msa@vixen.cso.uiuc.edu>, Dwight A. Schwartz wrote: >Hi Rainbow lovers, Well, I used to use the Rainbow and liked it, but that's not what this is about, exactly. :) > > My idea is this: MS-DOS Kermit for the Rainbow contains source code >which directly handles the Rainbow's communciations hardware. KA9Q appears to >contain the code needed to run SLIP on an IBM-PC style MS-DOS machine. How >feasible is it to take the code from the Rainbow's Kermit for controlling the >serial port hardware and using it within a program like KA9Q, with the end >result that we would have SLIP for the Rainbow? My thought was that then we >could use the latest Rainbow Kermit (perhaps modified to connect to a BIOS I have wondered this myself, albeit with my DECmate II, which has the Z80 card. I know that, of all the terminal programs I've seen in the CP/M environment, Kermit-80 was the only one with a specific overlay for my machine, oddly enough. I have been tracking down leads for a CP/M-based KA9Q but have come up empty. I've even thought of taking Phil Karn's source and running it through HiTech C (which I've not downloaded yet) to get a working (NOT!) copy there. I don't think you need a PhD to do this. I was planning on doing a SLIP for my HP48 just from reading Douglas Comer's books and Phil's code, though admittedly I've a CS degree. :) You'd probably have to accept a more limited feature set than you'd get on a Linux or even PC box, but for my purposes, that's fine. The DECmate will be connected to a TNC (radio modem) and the ham radio TCP/IP network (ampr) and thence by SLIP to my PC. I'd like to explore the HP for portable applications. I've crossposted this to comp.os.cpm, alt.sys.pdp8, and rec.radio.amateur. digital.misc, since the folks there might have more ideas for us. Dave -- | David Moisan, N1KGH /^\_/^\ moisan@bronze.lcs.mit.edu | | 86 Essex St. Apt #204 ( o ^ o ) n1kgh@amsat.org | | Salem. MA 01970-5225 | | ce393@cleveland.freenet.edu | | | From billh@comtch.iea.com Fri Sep 30 04:34:48 EDT 1994 Article: 1049 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!koriel!cs.utexas.edu!howland.reston.ans.net!news.sprintlink.net!nwnexus!krel.iea.com!comtch!billh From: billh@comtch.iea.com (Bill Haygood) Newsgroups: alt.sys.pdp8 Subject: Re: sunsite.unc.edu Date: 28 Sep 1994 16:37:34 GMT Organization: home Lines: 17 Message-ID: <36c64f$1hl@krel.iea.com> References: NNTP-Posting-Host: comtch.iea.com X-Newsreader: TIN [version 1.2 PL1] Kenn Goutal (kgg@mv.mv.com) wrote: : Tried to ftp to sunsite.unc.edu, got timed out. : Is this a valid ftp site, home of pdp8 stuff? : Thanks, : -- Kenn Goutal : kenn@mv.mv.com : http://www.mv.com/users/kgg/kenn.html Yes, at least when I tried a few weeks ago, it worked fine. Probably just down at the moment. When you try again and get through, look in directory /pub/academic/computer-science/history/pdp-8 Good hunting! _ |_) |_)ill From ug940014@omega.scs.carleton.ca Fri Sep 30 04:35:08 EDT 1994 Article: 1050 of alt.sys.pdp8 Newsgroups: alt.sys.pdp8 Path: bigblue.oit.unc.edu!concert!news.duke.edu!convex!cs.utexas.edu!swrinde!pipex!lyra.csx.cam.ac.uk!warwick!uknet!strath-cs!bnr.co.uk!bcarh8ac.bnr.ca!bcarh189.bnr.ca!nott!cunews!omega.scs.carleton.ca!ug940014 From: ug940014@omega.scs.carleton.ca (Iain Bennett) Subject: PDPs in heaven Message-ID: Sender: news@cunews.carleton.ca (News Administrator) Organization: School of Computer Science, Carleton U., Ottawa, Canada X-Newsreader: TIN [version 1.2 PL2] Date: Wed, 28 Sep 1994 18:49:19 GMT Lines: 3 Here at Carleton, we have a PDP6 in the engineering building. Also, we may be getting an old PDP11 to run as a unix server for the Computer Science Society!! OOO ahhh... From mbg@world.std.com Fri Sep 30 04:37:43 EDT 1994 Article: 1051 of alt.sys.pdp8 Newsgroups: vmsnet.pdp-11,alt.sys.pdp8,alt.sys.pdp11,comp.sys.dec.micro Path: bigblue.oit.unc.edu!concert!inxs.ncren.net!taco.cc.ncsu.edu!lll-winken.llnl.gov!ames!agate!howland.reston.ans.net!cs.utexas.edu!uunet!world!mbg From: mbg@world.std.com (Megan) Subject: pdp-8 and pdp-11 simulators Message-ID: Keywords: pdp8 pdp11 simulator Organization: The World Public Access UNIX, Brookline, MA Date: Thu, 29 Sep 1994 13:55:10 GMT Lines: 106 Xref: bigblue.oit.unc.edu vmsnet.pdp-11:1865 alt.sys.pdp8:1051 comp.sys.dec.micro:3172 After getting permission from the author, I have placed a compressed tar file containing a pdp8 and pdp11 simulator in my ftp area on the world. The file is obtainable from: ftp.std.com:/ftp/pub/mbg/pdp_simulators.tar.Z I have used the pdp-11 simulator on a VAX running ultrix, a MIPS R4000 running ultrix and an Alpha running DEC OSF/1 V1.3 and V2.0 and have successfully booted RT-11 (V5.6), some flavor of RSX and some flavor of RSTS (I think it was V9.2). Enjoy! Megan Gentry Former RT-11 Developer The 0readme.txt file follows: The following is the original 'announcement' of the availablility of the pdp8 and pdp11 simulators to a private list. It has been edited to remove certain sensitive pieces of information: - - - - - I am pleased to announce the (internal field test) for the PDP-8 and PDP-11 simulators. To get the sources and the simulated OS8 and RT11 disks, copy xxxxxx to your system and proceed as outlined in these notes. Sketchy documentation on the simulators is in file 0simdoc.txt [ed. - the OS8 and RT11 disks are not available due to licensing issues ... if you have a disk, simply copy the disk to an image file and use that.] 1. The simulators work on both VAX/VMS and on Alpha/OSF1. [ed. - and on mips/ultrix] 2. Each simulator includes a CPU, memory, reader, punch, terminal, line clock, RK05 disk, and RX01 disk. (The PDP-8 has an RF08, and the PDP-11 has an RL11.) 3. There's a VMS build file for each simulator: pdp8_build builds PDP8.EXE pdp11_build builds PDP11.EXE [ed. - A preliminary Makefile is provided which will build the simulators, but may not be as concise or as full-purpose as it could be] The build files include the debugger, remove that if you want. For OSF/1, the build command lines are: cc pdp8*.c scp*.c -lm -o pdp8 cc pdp11*.c scp*.c -o pdp11 4. The simulators are only partially tested. I would APPRECIATE YOUR FEEDBACK. Feel free to try small programs to test the EAE, FP11, and devices. If you find bugs, feel free to look through the sources and send me the fixes...:-) [ed. - The author has set up a mail alias to receive such mail. You can send mail to him at dsmaint@pa.dec.com] 5. To get the simulated operating systems up and running (OSF/1 shown): % pdp8 PDP-8 simulator V1.0 sim> att rk0 os8.dsk sim> boot rk0 . <-- OS/8 prompt This is pretty much instantaneous on either VAX or Alpha. You must first set the date (note that OS/8 REQUIRES CAPITAL LETTERS FOR INPUT) and then you can type HELP or DIR to explore further: .DA 14-MAR-94 .DIR For the PDP-11 and RT11: % pdp11 PDP-11 simulator V1.0 sim> att rk0 rt11.dsk sim> boot rk0 RT11SJ (S) V5.04 . . <-- RT11 prompt Note that on a slow VAX (eg, a 3100) it takes 45 seconds to get to the banner, and another 15-20 seconds to get to the prompts. On Alpha/OSF1, it takes a few seconds to reach the prompt. You can then set the date, type HELP or DIR, and so on. RT11 accepts lower case input. The simulator is stopped by typing ^E (control-E). This can be changed through the WRU register. From lasner@sunSITE.unc.edu Fri Sep 30 04:38:12 EDT 1994 Article: 1052 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: alt.sys.pdp8 Subject: Re: CLL and PIP under OS/278 Date: 30 Sep 1994 08:04:04 GMT Organization: SunSITE, University of North Carolina, Chapel Hill Lines: 196 Message-ID: <36ggpk$edu@bigblue.oit.unc.edu> References: <35l9hq$nn1@ariel.ucs.unimelb.edu.au> <35lq9j$vc3@bigblue.oit.unc.edu> <35t338$5h8@bronze.lcs.mit.edu> NNTP-Posting-Host: president.oit.unc.edu In article <35t338$5h8@bronze.lcs.mit.edu>, David Moisan wrote: >In article <35lq9j$vc3@bigblue.oit.unc.edu>, >Charles Lasner wrote: > >>recommended to be disabled! In any case, the first form is always >>supported while you need CCL enabled to perform the second form, etc. > >Hmm. I tried running PIP that way, like I used to do on the other >DEC systems I used, RT-11 and RSTS, but got this: > >.R PIP >BAD IMAGE > >There are several commands in the CLL that use PIP (as specified in the >helptext), and they worked fine. I infer that PIP.SV wasn't meant to >run alone, but must be invoked by the CLL. Too bad, really, I was very >accustomed to the DEC way of doing things in the -11 series. I really >should snarf the OS/278 source off of sunsite and look at it. > >>>The DECmate faq doesn't seem to answer this question, >>>it there a users manual on the net? Indeed PIP is nothing special in theory; all OS/8 CUSPS are meant to be able to be run from the ".R xxxx" form of the program where xxxx.SV is the executable file name, etc. CCL format was added as an aid to making things easier, not more difficult! And there are always compelling reasons to *not* use CCL since it is neither efficient nor a panacea, etc. Thus, the .R and .RUN DEV forms are always necessary, etc. Or so we thought! Someone at DEC years ago dreamed up an alternate notion we've heard elsewhere - less is more. OS/78 V1 was created to fulfill a debatable need, namely a downsized system lacking features standard to OS/8, and also deleting the ability to support the standard syntax for no clear definable reason, other than modestly shortening the documentation in an otherwise redundant manual. (The point is that if the manual is 100% redundant, you can't justify it on a cost-cutting basis. Clearly *not* producing an OS/78 manual in addition to an OS/8 manual is cheaper!) The actual implementation was that an unused JSW bit was defined as the "don't run this program" bit. Thus, only CCL chaining to the program was allowed, i.e., starting it via a chain operation at one higher than the stated standard starting address, etc. CCL chaining is of course normal, but the standard starting address becomes unreachable. The overall mechanism is controlled by whether or not the system is considered to be in "OS/8 mode" or in "OS/78 mode" which is indicated in memory by the state of the extraneous bits that can be .OR.'ed into the contents of location 07604, which is normally 7402 or HLT. There is actually room for two such bits, since the instruction can be expanded to OSR HLT, CLA HLT, or LAS HLT. (This location is the error return for the attempt to save memory called at 07600. This is one of those parts of OS/8 where the error return isn't handled well; there are a few such sore spots, etc.) Thus, if any particular program is saved with the particular JSW bit set *AND* location 07604 indicates other than "OS/8 mode" ("VT278 mode" and "OS278 mode" have also been defined, although not quite clearly.) then the program cannot be executed, sometimes with a bizarre error message such as "bad image" etc. The bulk of OS/8 CUSP's were shipped with the JSW bit set. In essence, OS/78 V1 is just a selected subset of OS/8 V3D with the mode set using the command "SET SYS OS78" to prevent the R and RUN commands, etc. The restriction can easily be removed merely by using "SET SYS OS8" to return to the full system, etc. But something happened as OS/8 "decayed" into OS/278 V2. Somewhere along the way, the code got broken. In OS/278, a lot of the particulars of what constitutes a core image are mishandled. Some of this is documented in the Kermit-12 .BWR file. In particular, the bit designated to be the "don't run" bit no longer functions as such! Worse still, other important bits with specific meaning are being misinterpreted as the "don't run" bit! For example, a program may indicate that it neither loads nor runs in field 0 or field 1 0000-1777. This allows various optimizations if feasible, etc. Thus, a program such as ABSLDR may have bits 0,1,10,11 set (JSW is 6003). According to OS/8 V3D (OS/78 V1) this would be varied to 6103 to make it abide by the OS/78 restriction, etc. Yet, in OS/278 V2, clearing bit[5] in the JSW has no effect! The mere combination of those other innocent bits renders the program as non-executable! By removing the bits indicating the program doesn't require swapping for field 0 and 1 0000-1777, use of ABLSDR becomes possible with the R and RU commands, but all ABSLDR operations suffer needless inefficiency in the process, etc. It appears that some code somewhere in the monitor is now badly flawed. Fixing it will restore the former system, and again allow PIP to be run as intended, etc. Note further that the command "SET SYS OS8" is specifically forbidden in OS/278 V2!! The reason for this is rather complex and diabolical, but repairable. The problem is that code has been added to prevent the change of system type! Unfortunately, the delivered system is already set for "OS278 mode" and thus the R and RU commands won't work on most image programs, etc. Clearly, if the system were patched to the OS8 mode, we would be caring less about it, but the system cannot easily be patched as provided, etc. The reason in turn for the prevention of the command being changed is because attempts to use the SET SYS commands are fatal to the system! Literally, any SET SYS command corrupts the system and makes it non-bootable next time! If performed on the hard disk, the problem is permanently fatal as distributed; on diskettes, there are band-aid commands available to repair the effects of the "illegal" command! The code is in (of all places we were discussing!) PIP itself. Should a system head be rewritten by calling the handler, the head becomes non-bootable. In the specific case of the RX50 diskette, there are non-device-independent (read kludge!) options to transfer the head of another system onto the broken system, thus restoring its boot capabilities, etc. But hard disk volumes stay broken! Thus, the attempt to change the SET SYS to any value is met with a warning message, essentially telling you that having succeeded in rewriting the header, you will be denied the benefit of the change, and additionally you are warned your system is either an about-to-die hard disk volume or a needs-to-be-repaired diskette system, but in either case is now non-viable! Thus, savvy users avoid (and curse!) the mechanism, and just put up with the restriction. (I use the inefficent ABLSDR so I can type R ABSLDR :-).) The underlying explanation as to *why* the need to prevent the command, i.e., what destruction it causes is in turn solvable, or at the minimum is manageable. The underlying problem is a "feature" of the DECmate II, III, III+ ROM's themselves. DEC created a specification for how bootable volumes arrange certain header bytes for all of the machines with RX50 as well as some other devices, etc. No particular care was taken to assign values to the DECmate-specific volumes as to whether the presence of the designated areas would cripple the boot process of the affected system! As such, the OS/278 system faces a bizarre dilemma: Values are required in the header that must be written in 8-bit mode, i.e., the same values *cannot* be maintained when writing in 12-bit mode, yet the DECmate bootstrap convention is to *read* this same data in 12-bit mode! Additionally, OS/278 addresses all of its logical records in 12-bit mode, thus attempts to write on logical record 0000 of the system will corrupt the ability for this vital (in 8-bit mode!) data to be present. (And of course, the mechanics of the SET SYS command precisely affect writing out of this area of the system. Since the design philosophy of OS/8 is to be device-independent, there is no rational way to prevent a program such as the SET command from corrupting the system by realizing to perform a device-dependent routine to write out the system header record when updating a part of it, etc. Note that the code in PIP is a device-dependent kludge that bandaids the problem only for RX50; the hard disk volumes' analogous problems aren't even addressed! Proliferating all OS/8 programs with private device-dependent routines for all known problem devices isn't a solution!) Actually, there is a solution to the problems!!! By changing *ONE WORD* on the hard disk volume, it is possible to change the volume header so that it passes the ROM checks in the actual machines. (Note: the DEC convention is then violated; it appears that the ROM only implements a cursory check of the DEC requirement! Had the ROM writers been more diligent, this fix wouldn't be possible!) There is a similar patch to perform the same fix on the RX50. Should there be any software on any system tight-ass enough to check this ill-conceived convention, a specific program can be written to "export" the diskette by using the original, albeit flawed, header data, and to "import" the diskette by changing it to the value that passes through the ROM check, etc. (Clearly, there won't be any software on any machine policing whether hard disk volumes on a DECmate are obeying this artificial convention!) In earlier posts I explained the underlying hardware reasons for all of this; interested readers are referred to the archived back pages of a.s.p for more details. In any case, doing all of the above merely sets the stage for the actuation of the fix. Once repaired, a SET SYS command *could* work harmlessly. The kludge code added to PIP could be removed as it then becomes unnecessary, as well as ruining PIP (it makes PIP device-dependent and also requiring 12K). It is still necessary to remove the warning code from the OS/278 monitor so that it functions as originally intended, i.e., to allow the user to set the option any way chosen, etc. Additionally, the bugs associated with the save image header mishandling, especially the incorrect JSW bits accidently enabling the R, RU restriction, have to be corrected as well. Once all of this is done, the problems of PIP, as you raised, will be eradicated. (A lot of work undoing the cumulative damage, but it's a high priority issue!) cjl From lasner@sunSITE.unc.edu Fri Sep 30 04:38:28 EDT 1994 Article: 1053 of alt.sys.pdp8 Path: bigblue.oit.unc.edu!sunSITE!lasner From: lasner@sunSITE.unc.edu (Charles Lasner) Newsgroups: comp.sys.dec.micro,comp.os.cpm,alt.sys.pdp8,rec.radio.amateur.digital.misc Subject: Re: a scary idea for the DEC Rainbow Date: 30 Sep 1994 08:35:25 GMT Organization: University of North Carolina, Chapel Hill Lines: 23 Message-ID: <36gikd$vua@bigblue.oit.unc.edu> References: <36c47b$msa@vixen.cso.uiuc.edu> <36ckr2$2q7@bronze.lcs.mit.edu> NNTP-Posting-Host: president.oit.unc.edu Xref: bigblue.oit.unc.edu comp.sys.dec.micro:3176 comp.os.cpm:7356 alt.sys.pdp8:1053 rec.radio.amateur.digital.misc:4936 In article <36ckr2$2q7@bronze.lcs.mit.edu>, David Moisan wrote: > >You'd probably have to accept a more limited feature set than you'd get >on a Linux or even PC box, but for my purposes, that's fine. The DECmate >will be connected to a TNC (radio modem) and the ham radio TCP/IP network >(ampr) and thence by SLIP to my PC. I'd like to explore the HP for >portable applications. Please be advised for any of these schemes that the Z80 is a captive processor on the DECmate. It does zilch I/O. The 6120 is in charge of all I/O, and port I/O is subject to the overhead of CP memory. Note that the hardware limit of 19200 is *NOT* supported under CP/M (9600 baud max). One of the major changes I need to make to improve Kermit-12 is to rewrite the slushware to provide CP hooks for polling the port during too-long CP sequences with -8 interrupts turned off in the terminal emulator, etc. CP/M has no access to any of this. Writing the support for the 6120 side would be more practical though! cjl