MicroVAX and 8086 smartcards for DEC Professional

   I recently came into possession of two unusual CTI bus cards, for the DEC Professional (you know, Pro-325s,Pro-350s, Pro-380s). These are apparently prototypes for never released options for the PRO line. One card has a MicroVAX II chipset on it, and apparently was for a DEC project called Meteor - a workstation with capabilities somewhere between a PRO-380 and a Vaxstation II.

  Here's pictures of it, front, and back and a close up of the card name

  It came with a memory daughter card - here's shots of it, back and front.

  The other card has an 8086 processor on it. It was apparently going to be used to allow Pro systems to run x86 software (MS Windows? On an RSX11 derived OS? The horror!).

 

  

  Presumably, "8086 SC" in the above means "8086 Softtcard". This card has had several dynamic RAM chips removed, which I am replacing before I do any testing.

Neither card had an option code on their retraction handles like normal PRO options do.

  When I get some spare time, I plan to put them in a PRO-380 and read/write the slot addresses for them and see what happens. Realistically, I don't expect to get very far without more info on them. If anyone out there has any more info or any software for these prototypes, I'd sure like to hear about it...

Booting PDT-11/150 from TU58s and TU58 emulators

   A post or so back, I wrote up how to connect a TU58 (or emulator) to a PDT-11/150. Works great. But, you can't boot the PDT from a TU58 (or emulator - from here on, TU58 means TU58 or emulator - OK?), so you are still dependent on the RX01(ish) drives to get the system going. But there are a lot of PDT-11/150s out there with no software on floppies available, or with dead floppy drives. A way to boot from TU58 would enable people to load software or use them without the floppy drives.

  A look at the technical manual for the PDT, available at...

PDT-11/150 Tech Manual

 showed that the startup code for the PDT is in two 1K X 8 mask programmed ROMS on the memory board. I took a squint at the ICs in question, and saw that they were socketed - a good start - I'm in no mood to desolder a chip I can't replace if it gets destroyed in the process. They were mask programmed ROMs, part number NS82S2708. There is an EPROM  equivalent of this ROM, with the same pinout - the 2708. No sweat, I figured - sounds like a part from the common 27xx EPROM family. I can write new boot software, burn it to 2708s, and Bob's my uncle. I'll be done in an afternoon! Alas, that was not to be. Turns out that the 2708 is an early design EPROM. It requires three different supply voltages, and almost no hobbyist grade EPROM burners support it (for sure, mine doesn't). Pro grade ones that would support it are damned hard to find these days, and really expensive.

  So, that's about how these projects always go - a rush of initial enthusiasm, followed by a punch in the face from reality. Fortunately, this is an issue that has been dealt with already, by arcade video game  and pinball machine enthusiasts. Arcade games and pinball tables from back in the day often came with 2708 EPROMs. These hobbyists researched it and worked out that these can be replaced by 2716 2KX8 EPROMs, with a little work. The 2716 is a more typical 27XX part -  no exotic voltages required, and almost all EPROM programmers support it (most importantly, mine does). The 2716 is twice as big as a 2708 - you can program the 2708 image into the top or bottom half - the instructions below assume the code gets burned into the bottom half. You could even burn different programs into the two halves, and use a switch to select which one is active.  No need for that on this project.

  Here's the pinouts for the 2708 and the 2716

          2708                   2716
        +--U--+                +--U--+
      A7|1  24|Vcc(+5V)      A7|1  24|Vcc(+5V)  
      A6|     |A8            A6|     |A8
      A5|     |A9            A5|     |A9
      A4|     |Vbb           A4|     |Vpp
      A3|     |*CS/PE        A3|     |*OE
      A2|     |Vdd           A2|     |A10
      A1|     |Program       A1|     |*CE/PGM
      A0|     |Q8            A0|     |Q8
      Q1|     |Q7            Q1|     |Q7
      Q2|     |Q6            Q2|     |Q6
      Q3|     |Q5            Q3|     |Q5
Vss(GND)|12 13|Q4      Vss(GND)|12 13|Q4
        +-----+                +-----+

Purty close, nicht wahr? Looking at the pinouts, you can see how to use a 2716 in a 2708 socket. You have to...

 - Connect pin 21 to pin 24 (2716 requires Vpp pin be at Vcc for reading)

 - Connect pin 18 to pin 20 (connect both output enable and chip enable to Chip Select)

 - Connect pin 19 to pin 12 (this selects the lower half of the 2 K ROM. Connect 19 to 24 to use
   upper half of 2716 instead. 

 - Don't connect pins 18, 19, and 21 to the 2716 from the board . The 2716 would be
   discomfited by the crazy 2708 required voltages (-5 and +12) present on those pins.

  The way the arcade guys accomplished this was to use two additional sockets, plugged into each other. On one of them, the bottom one, that will plug into the board, they did the first three steps - carefully soldering jumper wires between the indicated pins. On the next socket up, they got rid of pins 18, 19 and 21 (if you use machined pin sockets, you can heat the pins with a small soldering iron and push them out of the frame). Then they'd plug the 2716 into the top socket, plug the top socket into the bottom socket, and plug the bottom socket into the board where the 2708 once made its home.

  Here's a site that explains this. Unfortunately, it's been archived so it doesn't have its pictures anymore, but it's the best rundown of the solution I found.

Adapter for 2708 to 2716 swap

 And if you're looking for 2716s, you can also use a TMS2516 for a 2716. I didn't have any 2716s in the giant box o' salvaged obsolete through hole pin ICs, but I had plenty of TMS2516s, and they are pin and voltage compatible. There's a long story about why TMS2516s are equivalent to 2716s, but TMS2532s are not the same as 2732s, but, it's got nothing to do with this project, so I'll skip it (for now...).

  Anyway, enough of this hardware talk. That reminds me, what are the three most destructive things in computing? A system programmer with a soldering iron, a hardware tech with a patch tape, and a manager with an idea - and I'm two out of three!

  So, first step, I need to get the current contents of the factory boot roms, so's I can add the TU58 boot code into the normal initialization process. Hmmm...my EPROM programmer won't even read a 2708... Not a problem. The PDT tech manual reports that the boot roms occupy the addresses 170000-173777. I just booted RT11 from disk and used ODT to read the contents of that address range. This was better than reading the ROMs on a reader anyway - if I had read the two ROMs directly, on the EPROM burner, I would have had the additional step of combining the two outputs into one file, since the ROMS contain the bytes of each word - one ROM has the even bytes, one ROM has the odd bytes. The ODT just gave me the words as the PDT sees them, as combined words.

  Now I needed to convert the listing of the ROM contents into MACRO-11, so I can see where to add my evil magic. I have several tools that will disassemble an RSX object file (I usually use ORCAM), but nothing that will do it to a string of words like ODT produced. I wrote an EDT macro to translate the ODT statements in the form

173242/074524
173244/062560
173246/071440

to 

        .word     074524      ;173242
        .word     062560      ;173244
        .word     071440      ;173246

  Here's the result of that, in case there's any other hardware hackers out there that want an unmolested ROM listing for reference.

pdtrom.mac

 And then I assembled the resulting file to a .obj file - which I could then input to the ORCAM utility. Well, the results were a bit of a mess (when you look at machine decoded Macro-11 and you see a bunch of floating point instructions, you know you have some hand work to do) . Since this code was written to fit in a limited space, it had all kinds of programming tricks in it that confuse automated disassembly tools. Things like using the numeric value of other instructions as literals for arguments , and the like. Some of the coding stunts didn't seem to make a lot of sense - for instance, in places, the programmer created his own JSR - RTS technique using branches and jumps instead of just using the actual instructions. One good thing I found - even though the code was littered with these space saving tricks, there was over 600 bytes of unused space in the ROM, so there wasn't really any need for exotic tactics. That's plenty of space to load the TU58 boot routine.

  Here's the partially, poorly disassembled source. Feel free to correct and expand on my efforts. I only did enough to get this project done. Much of it is wrong. Some of the comments are in error as well. It might serve a starting point for someone else. It might serve as a source of amusement for those more skilled than I at reverse engineering.

pdtdis.mac

  A lot of manual disassembly of the resulting mess  let me find a place to put the boot code, and a place to let the user indicate that they want to boot the TU58 instead of the RX01 drives.. There is an unused space from 171630 to 172776. The boot routine is small, so I decided to load it at an even address, for convenience sake - 172000 - still plenty of space starting there.

  For a boot routine, I adapted the boot code from TU58FS, by Joerge Hoppe, who credits work done by Don North and the M9312 boot code. It's important to credit other people's work, nicht wahr? Here's the boot code I used. It's pretty self explanatory - sets the line speed for terminal line 1, inits the TU58, sends a boot request, gets 512 bytes and stores 'em starting at address 0 - then jumps to 0 and starts executing.

ddboot.mac

  Now I need a way to invoke that code when I want to boot from the TU58. There is a place in the original boot code where, if neither disk is loaded, the system asks you if you want to boot disk 0 or 1 - that gives you a chance to load the disk and try again. If you answer 0 or just carriage return, it retries disk 0. If you answer 1, it retries disk 1. If you answer anything else, it asks you again. It only took changing a couple of words to alter that behavior to be, if you answer anything besides 0 or 1, jump to 172000 and do the TU58 boot. I use a capital G...for Gleason...I recommend you do the same.

  It looks like this...

  Unload both disks and power on. The system will say

Read error

Type start unit number (0 or 1):  

  If you type 0 or 1, it tries to boot...disk 0 or 1. If you enter anything besides a 0 or 1, it will jump to the TU58 boot code. A banner will print

PDT-11/150 TU58 Boot LKG V01A01

and it will try to boot from the TU58. 

 Here's what it took to make this happen. In the boot rom, I changed the code at lines 5 and 6 in the code snippet below

  Original:
        CMPB    (R1)+,R2        ;typed a 1?
        BEQ     3122$           ;then boot from PD1:
        CMPB    (R1)+,R2        ;typed a 0? 
        BEQ     3120$           ;then boot from PD0:
        CMPB    (R1)+,R2        ;compare for space input
        BNE     3042$
3120$:  CLR     R3 
3122$:  MTPS    #340

*******************************
Modified:
        CMPB    (R1)+,R2     ;typed a 1?
        BEQ     3122$        ;then boot from PD1:
        CMPB    (R1)+,R2     ;typed a 0? 
        BEQ     3120$ 
        JMP     @#172000     ;not 0 or 1,jump to our TU58 boot code.
3120$:  CLR     R3           ;clear r3 to boot from unit 0
3122$:  MTPS    #340

  In binary, this change amounts to swapping lines

       .word   122102  ;173114

       .word   001351  ;173116

with

       .word    137     ;173114

       .word    172000  ;173116

 

  This boot rom should work with a real TU58, or a TU58 emulator. I have only tested it with ETU58, the RSX TU58 emulator I wrote a while back (see previous TU58 post for details). A few small changes were required to ETU58, to support a boot request from the PDT. This new version of ETU58 still supports booting from the disk like normal, and accessing the DD devices just like it did before.

  OK, how to put it all together? First, mod those two lines in PDTROM.MAC and save as file NROM.MAC (for new ROM) Then assemble it to produce a listing file. You don't need an obj file.  Use LISPAR (see a previous blog post for the Macro-11 List File Parser utility) to convert the listing to an Intel format load file, using the /SP (split) switch on the output to produce odd and even output files (that contain the odd and even bytes of the file, that go into odd and even EPROMs).

>mac ,nrom=nrom
>run lispar
MLP>nrom/sp=nrom

  That produces files NROM.EVN and NROM.ODD.

  Assemble DDBOOT.MAC to produce a listing file. Use LISPAR to produce odd and even Intel format files. Use /ADR:1000 to tell it where we want the code in "EPROM address space" - that will cause it to appear at 172000 when everything gets done.

>mac ,ddboot=ddboot
>run lispar
MLP>ddboot/sp=ddboot/adr:1000

  Edit nrom.odd and nrom.even. Replace the two lines that go to address 1000 with the two lines in each of ddboot.odd and ddboot.evn. Save the files and burn them to two 2716 or 2516 eproms. OK, that's a lot of work. If you're good with the state of the code as it is, I provide the current version of two files that need to be burned to the EPROMs below. 

NROM.EVN

NROM.ODD

Then replace the ROMs on the memory board with these EPROMs, inserted into the double scoket adapter described above. The Odd EPROM goes on the left, if you're facing the front of the machine - the even EPROM goes on the right. Make sure and match the "U" notch orientation of the ROMs - the "U" notch faces the front of the machine.

  Then, connect the TU58 or emulator to Terminal 1 on the PDT. Remove the disks from the two drives and power on. When it asks boot from 0 or 1 - enter any character, and it should boot from the TU58.

  So, sweet - everything works and we're all done with this project...well, not quite. When I went to put the lid back on the PDT...the double socket style EPROM adapter discussed above  sticks up too far for the top to fit.  I thought about this problem for a bit. I have a dremel tool and lots of cutoff disks....but no, as much fun as putting a hole in the top would be, it would look terrible and allow junk to fall down onto the memory board. A little more study showed that the only function of the upper socket is to make sure pins 18, 19 and 21 don't get connected to the circuit board. I can get the same effect  by cutting  pins 18,19 and 21 off of the EPROM, and keep the lower socket with the wiring adds on it. That lowers us by one socket. Why didn't I do this from jump street? Why did the arcade and pinballs guys use two sockets? Because, once you mangle up the chip pins, you can't erase and rewrite the EPROM  anymore....and believe you me, the new EPROM code took several edits before it worked.

 And, like I said above, my RSX TU58 emulator, ETU58, needed a few changes to support the boot request from the PDT. I named this version of it NTU58 (New TU58). Here it is...

ntu58.mac

To use, it's just like ETU58, from previous blog post. Build instructions are also in the file itself.

  If any of the 4 or 5 people in the world who are PDT-11/150 AND TU58  hobbyists try this, let me know if you have any problems.

  

DX protocol comms host software for DECmates

   Back in the day, DEC built some deskside/desktop machines based more or less on the PDP8, using aftermarket CPU chips from Intersil. They were marketed as word processing systems, and had operating systems similar to OS/8, called OS/78 and OS/278. There were a number of variants, and they had a variety of names - WT78,VT278, DECmate I,II,III and III+ and no doubt some others that I'm not aware of.  Hey, I'm a PDP-11 and RSX family collector - I don't know much about the 12 bit machines and their software - these names and OSes could easily be wrong or incomplete. Anyway, the word processing application they ran was WPS-8.

  These systems could support a communication protocol called DX, that allowed them to transfer and print files to/from a host machine, and do terminal emulation to log on as a user. Truth to tell, I don't know which members of this family of products supported DX - at least  some of them required an optional board, a DP278 , to enable it. There was also software that ran on the host machines to enable the use of these features. There were versions available for several of the PDP11 OSes - DX/11M (for RSX11M), DX/IAS, and DX/RSTS. Maybe more - these are the ones that I have heard of. 

  I had thought that the DX family of software was another lost product, but a couple months back, I was going through some old boxes, and found a copy of DX/IAS on a small 9 track tape. It might be of some interest, since it included the Fortran sources for the product. Although IAS is not widely used these days (or ever was, for that matter), the IAS system dependencies for this product look pretty minimal, and converting it to work on RSX or RSTS looks like it would be pretty simple. Usually, if there's no privileged kernel level code in an IAS program, and it doesn't use the timesharing subsystem, it's pretty easy to get it to run on RSX (and vice versa). Setting terminal characteristics usually needs a little attention, since the approaches to that are slightly different. If there's kernel level code involved - be ready for a challenge, since RSX and IAS are very different on the inside. But, there's none of that in this code.

  These days, It's tough to find anyone with a 9 track drive willing to read tapes  - and this was an 800 BPI NRZI tape - most hobbyists have the later, smaller tape drives that only handle Phase Encoded tapes at 1600 and 6250 BPI. I found a commercial site near me that could read 800BPI, at a charge of $75 a tape. Ouch...direct hit to the wallet...but, I hate to see a piece of DEC software disappear forever, so I bit the metaphorical bullet and got it read.

  They only did a so-so job of reading it. Fortunately, it was in DOS-11 format, written by FLX on an RSX system, so even though the headers and trailers from the tape were horribly mangled, the contents of the files and the 14 byte RAD50 string that identifies each one came out fine. The contents of the tape were all ASCII files - Fortran sources, a command file and a Macro-11 file, made it easy to see what was what. 

  If you get far enough to need one, there's a manual on using the DX software available on Bitsavers

DX User's Manual

  So here's the files from the tape. If any DECmate collectors get this to work on an RSX or RSTS host, let me know. And if you get it running on an IAS system, definitely let me know - since that means you're running an IAS system...

ACKNAK.FTN

BYE.FTN

CHRIN.FTN

DISPLA.FTN

DSKIN.FTN

DSKOUT.FTN

DXINIT.FTN

DXINS.CMD

FINTSX.FTN

FSUBS1.FTN

FSUBS2.FTN

FVALID.FTN

GETCHR.FTN

GETNUM.FTN

GETVAL.FTN

HEDOUT.FTN

INTSIX.FTN

INTTXT.FTN

LDSPAC.FTN

LOOKUP.FTN

MAKHED.FTN

MISC.FTN

NEWSET.FTN

PRINT.FTN

PUTHED.FTN

RCVMSG.FTN

RECV.FTN

REPLY.FTN

SEND.FTN

SETCHAR.MAC

SNDMSG.FTN

SPCFLX.FTN

SPECS.FTN

STROUT.FTN

TXTWP8.FTN

VALID.FTN

VALUE.FTN

WP8DEL.FTN

WP8DIR.FTN

WP8FLX.FTN

WP8LPT.FTN

WP8OUT.FTN

WP8PIP.FTN

WP8TXT.FTN

WPS2.FTN

PDT-11/150 and TU58

   Recently, I've been playing around with a pair of old PDT-11/150s that I saved from a dumpster, years back. They are interesting machines - a PDP-11/03-ish processor, a pair of RX01-ish floppy drives, and a few RS232 ports, all in one (largish) desktop box. Back in the day, these got sold to do things like run a small office. These (and the PDT-11/130) could have been marketed as home computers early on, and beaten the IBM PC to the market, thus saving us from the horrors of Windows and the hideous ugliness of the X86 architecture. But, that's not what happened in this part of the Multiverse. Instead, the Dark Lord and Intel formed an unholy alliance, and together they made Orcs in mockery of Elves, and Trolls in mockery of Ents, and DOS in mockery of RT11, and NT in mockery of VMS, and on every side their foes fell reeling, defeated, one by one as they crushed them by sheer weight of numbers, their dread hosts darkening the plain (adapted from a USEnet post by Gary J. Robinson). But enough of that - I think everyone already knows how I feel about how things turned out.

  PDTs are fun to play around with but are....limited. The RX01 disk drives only hold 512 blocks each. One of them will be pretty much full by the time you get RT11, a few utilities, and BASIC loaded. The other one can hold data and programs you're developing/using.. It's still a little confining - you wind up with code and data scattered over a bunch of floppies, and have to change them a lot. And, as well, 8 inch floppies are getting old, scarce, and expensive.

  As well, PDTs are a little claustrophobic. Transferring files on and off of them is a bit of a challenge. Ethernet is right out of the question, and even if it had one, there wouldn't be enough disk  space for TCP/IP or  RT11 DECnet (and it's long lost, anyway - let me know if you come across a copy). Kermit would seem to be a natural  solution - after all, these things have an RS232 console, and 4 other RS232 ports. There's even a Kermit written specifically for these guys - KRTMIN, sized to fit on the available disk space. But, for whatever reason, I haven't been able to get KRTMIN to work when transferring files to the box. It will transfer files in the other direction just fine, but copying to the PDT errors out every time (let me know if you've ever gotten KRTMIN to work in that direction).

  So, it can be a pain in the sitz-platz. Pasting text  into the terminal emulator and capturing it on the PDT with PIP or KED can be done, but my terminal emulator chokes when I give it more than a few lines of text that way (yah, I know - I need a better terminal emulator). But this post isn't about my bad taste in software. Even if that worked great, it's a limited solution - it won't work for binary files.

  I was musing over this problem, and looking at the PDT-11/150 tech manual, when I noticed that the RS232 ports on this thing are very "DL11" like - they have an XMIT and RCV CSR, with the important bits defined in the same places as the DL11, and they have XMIT and RCV data registers, just like the DL11. That made me think of the TU58 - the disk-like tape drive  (or should I think of it as a tape-like disk drive?) that is controlled by a DL or DLV 11. I looked at the addressing of the registers for each terminal, and noticed that the CSR and vector for Terminal 1 is at 176500,300 - the same as the default location for a DL11 controlling a TU58. That's not really a requirement for the TU58 controller, but it did  made me think, I could probably get a TU58 to work on it.

  Normally, that might be interesting, but not that useful. I mean, who's got a working TU58 drive these days? And even if it was working, it doesn't add much space or significantly improve the ability to load files from another system (unless I had TWO working TU58s - one of them on another system).

  But, if Terminal 1 could drive a TU58, it could drive a TU58 emulator. I wrote one of those for RSX a while back (ETU58, described in another blog post). Coupling that with the TU58 large disk patch to the RT11 DD driver, it could support an emulated TU58 that had 65535 blocks. I could use SIMH to load files on the big disk image, copy it to an RSX system, and serve it to the PDT to Terminal 1 via ETU58. One drawback is the speed limitations of the PDT - Terminal 1's max speed is 2400 baud . But I don't plan to use this constantly for working storage - more as a place to put all of my RT11 resources, to load on and off the PDT as required, and a way to do file transfers on and off the PDT (transfer files to and from the virtual disk using SIMH, and then access the virtual disk on the PDT via the emulator.). The slow speed won't be that much of a problem for that. Besides, the RX01 drives on the PDT ain't all that speedy either.

  OK, should be no problem. I'll knock this out in 15 minutes or so, I figured. Well, it took a little longer than that. First thing I had to deal with is the fact that Terminal 1 on the PDT requires that pin 20, DTR, be asserted before it will transmit anything. Not a huge problem, I figure. Normally I'd just jump it to something that is asserted at that connector. But, no soap there - the PDT didn't assert any control lines, so jumping to other pins on that end was out. So, I'll need to get it from the other end. Except that, on the RSX system I was using to host things, MODEM support had not been SYSGENed in. That meant none of the modem control lines were asserted, and you couldn't set the terminal line  /REMOTE to get them to be.  None of the assorted other systems I had used with the TU58 emulator required this - they were all happy with just good ole pins 2,3 and 7, so it hadn't been a problem. But, no worries there - I eat SYSGENs for breakfast. I just changed the MODEM answer in the saved SYSGEN file and did another SYSGEN to get that feature turned on. Then I could set the terminal line /MODEM, and it would turn on modem signals. Then I connected pin 6 (DSR on the RSX end to pin 20 (DTR) on the PDT end. Now the PDT could transmit....but, since the RSX terminal line was set /REMOTE, now the RSX end  wasn't happy because  CD (carrier detect, pin 8) was not asserted. It was time for the universal fix for RS232 problems - on the RSX end I jumper 4 and 5 (RTS and CTS) together, and wired 6, 8 and 20 (DSR,CD and DTR together), and connected those three to pin 20 on the PDT end. Now both systems   could transmit and receive, both directions -I had achieved full duplicity. Such was life before USB. If you're using a different TU58 emulator, your experience will probably be quite a bit different. But if you're using another TU58 emulator, you probably know what's required.

  But enough about how we wired things up back in the Stone Age, when all we had was a soldering iron and a well worn copy of "Technical Aspects of Data Communication" by John McNamara to get computers talking to each other.  I connected the cable to Terminal 1 on the PDT, and tt5: on the RSX system. I set tt5 to /remote and 2400 baud.

>set term tt5:/remote/speed:2400

  I set the PDT terminal 1 to 2400 baud

.RUN SPEED.SAV
*/t:1/s:2400.               (don't forget the "." - otherwise it's an octal number)

 Then I made a 512 block data file, tu58.dsk, for the TU58 emulator. - doesn't matter what's in it. I ran the TU58 emulator on the RSX system

>run etu58
ETU>tt5:=tu58.dsk

 Then on the PDT, I tried to INIT the emulated TU58.

.INIT DD0:

  And...nothing. It just hung up forever. That was a bit of a disappointment. I thought we were there...So I broke out the HP 4951 data scope and had a look at what was happening. Turns out that the DD driver on the PDT starts up slightly differently than the other PDP11s I've used ETU58 on. But, no worries - I modded the startup code in ETU58 to accommodate this difference, and tried it again. This time it was all roses - worked great. The "disk" INITted, copied files to and from and did directories flawlessly. In any  case, your mileage with other TU58 emulators may vary.  Here's a copy of ETU58.MAC, in case you want to host disks on RSX - but, it's not required to serve images to PDT-11/150s - I reckon that most any other TU58  emulator would work as well.

ETU58.MAC

  OK, now all I had  to do is patch the DD driver to allow big virtual TU58 tapes. Various folk have done work in this area (Jörg Hoppe, Don North, and others), not sure who was first. Their work on this showed the size of the disk is stored only in the driver, and nowhere on the disk, so that's convenient. All I had to do is patch the DD.SYS driver file to make it support bigger disks. How to do that is covered well at 

TU58FS - File Sharing with a DECtape II simulator

 thanks to Jörg Hoppe. I should mention, that the location of the word to patch in the driver  varies a few bytes  plus or minus, between various RT versions - but it's easy to identify what word to change. In a stock DD or DDX.sys stock it will typically be within the first 50 or so bytes, and have the value as a word of 512. I patched up the driver, and made some big images. INITed them and copied things on and off - worked great 

So...

Copy DD.SYS to the RSX system where it's convenient to ZAP the 512. to 65535 (octal 1000 to 177777). Copy the patched DD.SYS to the PDT as DD64K.SYS. Also make a 64K block file to serve as the virtual disk.

On the RSX system...

PIP rt64kdisk.dsk=nl0:/bl:65600. (make it a little bigger than 64K, just in case)
PIP nt64kdisk.dsk/EOF                (set end of file to the end...of the file).

RUN ETU58
ETU>TT5:=rt64kdisk.dsk

  On the PDT...

.UNLOAD DD
.UNPRO DD.SYS
.RENAME DD.SYS DD512.SYS (you may want the original someday - you never know...)
.COPY DD64K.SYS DD.SYS

(reboot here - would a simple LOAD DD have been enough? dunno...I rebooted).

.INIT DD0:
DD0:/Initialize; Are you sure? Y

.DIR DD0:

 0 Files, 0 Blocks

 65467 Free blocks

  Lots more blocks now than 512...

So now I can  copy most everything I need from RT-11 to a large TU58 image, using SIMH, for the sake of speed and convenience,  and then have it online to the PDT-11/150 all the time - this will cut down a lot on the need to constantly swap floppies in and out. 

 If you give it a try, let me know if you have any problems. I like helping keep DEC"s quirkier systems on the air.

  

VAXstation 1 and PDP11 QBUS systems software install via ethernet programs (finally)

  Note - new versions of some of these programs are coming out this month. Watch for them as a new blog entry

   OK, after all of the previous confusing blog posts explaining how they work, here's some of the programs that actually do something.

   When this project started out all I wanted to do was load a disk image onto a VAXstation I without any physical hardware gyrations (floppies, tape drives, disks loaded on one system and moved to the VAXstation I, etc - you know, the usual).  As time went by I realized the same principles would also work for loading disks on QBUS PDP11's, and I actually have more occasion to do that than I do fooling with VAXstation I's - as a result, I wrote  PDP11  versions of the programs as well as VAXstation I programs, and have used them a heckuva lot more.

  So, for this project, there are  server programs and client programs.

 Server programs  run on a normal host system. There's nothing exotic or hardware dependent about the server programs - they are normal tasks/images that use supported techniques to send and receive packets on the ethernet and save/restore/check them to a disk file. Server programs' names all start with LOCAL (for VMS based server programs) or LCL (for RSX based server programs). The second part of the server programs name is determined by what function is being performed by the corresponding client. So, the VMS server program that serves blocks to a client program, that is writing the blocks to the target disk is named LOCALWRITE. The VMS server program that accepts blocks transmitted from the client, to save into a local disk image file, is called LOCALREAD. The VMS server program that compares a local disk image file to the contents of a disk on the target system is LOCALCHECK. In like wise, the RSX versions of these server programs would be called LCLWRT,LCLREAD and LCLCHK (but they haven't been written yet - they're on the way).

  Client programs are...different. They are not normal tasks/images. They run on the bare metal of the target system with no OS (heck, if you had an OS on the target systems, we wouldn't be doing all of this in the first place, nicht wahr?). They are assembled and linked special, and then get loaded onto the target systems via DECnet MOP, booting, as a system image. They are named similarly to the server programs - they start with REMOTE or REM (VMS or RSX), and the second part of the name refers to the function they are performing on the target - REMOTEWRITE is getting blocks off the ethernet from LOCALWRITE, and writing them to the MSCP disk on the target system. REMOTEREAD is reading disk blocks from the MSCP disk on the target and sending them to LOCALREAD to be stored in a disk image file. And like that for the check function, and for the RSX images.

  Clear so far? And here I want to point out that the server programs are not OS specific - that is, LOCALWRITE.EXE, running on a VMS host system, will work just fine with REMWRT.TSK running on a PDP11 system. Same goes for LOCALREAD.EXE and REMREAD.TSK, and LOCALCHECK.EXE and REMCHK.EXE. And the same symmetry will hold when LCLREAD, LCLWRT and LCLCHK server programs are written on RSX - they will support VAXstation I clients as well as PDP11 clients. But, like I say, currently, the only server programs are for VMS. Why am I writing this before the RSX server programs are done? Because I ain't writing them right away since I want to work on some other projects for a while....I'll eventually get back around to it. And probably some MicroVAX II client programs as well - that would be more widely useful than the VAXstation I ones. Lots more MIcroVAX IIs out there than I's. Anyway...here's the programs thus far...

  Update - this version of remoteread.mar and localread.mar has bugs and is being withdrawn. A new version is available in a later post on this blog. remotewritewrite.mar and localwrite.mar are withdrawn here, since new versions are available - they're in the later  blog post as well.

  Additional update - remwrt.mac has also been updated, and is available in a later blog post. The version listed here is withdrawn.

localread.mar

localwrite.mar

localcheck.mar

remoteread.mar

remotewrite.mar

remotecheck.mar

remread.mac

remwrt.mac

remchk.mac

  OK, so how do you use 'em? Here's an example. Suppose you have a MIcroPDP11 with an 11/73, an RQDX3, RD54 and DEQNA in it (a DELQA would probably work too - their software interface is not that different). You'd like to load software onto the disk. The first step would be to use SIMH or some other simulator to install RSX onto an RD54 disk image. If it's not already there, copy that image file to the system you'll be using as the server. Then, you'd edit remwrt.mac, the PDP11 client task for writing to the client disk, to indicate what file on the server system that image is in. The name is located at label filnam.

filnam: .ascii  /dua1:[mvax1]zombie.dsk/

  Save your change and assemble remwrt.mac

  >mac remwrt=remwrt

  Task build it...

>TKB
TKB>remwrt/-hd=remwrt
//
CORSIZ=32
STACK=0
PAR=GEN:0:160000
UNITS=0
/
>
  Ya gotta task build it funny, since it's not going to use an OS - its task is just a bunch of code that gets loaded. into memory like a system image.

  Alright, now you've got a system image that will request the disk image you want loaded. Next step, is to create or modify a DECnet node definition for the client node, on the system where the remwrt.tsk you just built is located. For this step you'll need to know the ethernet address of the target system. If you don't know it, read it off the card, or just try to boot it and read it from the failed load error messages on system consoles.  

For this example, let's say it's 08-00-01--02-03-04, and use the name zombie, as examples.

>
NCP>set node zombie addr 10.111 (address doesn't matter - make it unique for your site)
NCP>set node zombie service circuit QNA-0 hardware address 08-00-01-02-03-04
NCP>set node zombie  load file du1:[test]remwrt.tsk
NCP^Z
>

  Or you can use LANACP instead of DECnet to do this...if that's what you want...you know what to do instead.

  If you already have the node defined, you don't need to do all of this jazz every time, natch - just change it to match your current situation - usually just the filename changes.    

  OK, all set, client-wise. Now go to your VMS system and run LOCALWRITE.EXE. It will sit there waiting for a request from a client system. Go to the client system and tell it to boot from the ethernet, however it wants that done. On my test 11/73, I CTRL-C out of the autoboot and tell it to B XH0:

  When you do that, the system where REMWRT.TSK is, and where you set up  DECnet to load it, hears the MOP boot request, and  loads it into the client system. When it runs on the client system, It will then set up the RQDX and the ethernet card, while printing a truly eye watering amount of diagnostic messages, left over from development and that I'm too lazy to remove, then starts up and broadcasts a request for a server to feed it zombie.dsk. LOCALWRITE.EXE on the VMS system hears that request and starts sending blocks, which the client receives and writes.  You get a progress message on both systems every 1024 blocks or so. After a couple hours, it will print a done message, and now you have a runnable PDP11 - assuming you've done everything right. A couple hours is significantly faster than using something like VTserver or PDP11GUI to do the transfer on an asynch RS232 port.

  Here's what it looks like, up through the first 1024 blocks...

Commands are Help, Boot, List, Setup, Map and Test.
Type a command then press the RETURN key: B XH0

Trying XH0
Starting system from XH0
remwrt
deqna card vector
01FC
new deqna card vector
006C
old psw
FFE8
new psw
FFE8
init RQDX3 via RIP write
read and display RSA
0B40
current step value
0800
current step bit was set in rsa - write next value to rsa
step
8000
r3 shifted
1000
read and display RSA
1080
current step value
1000
current step bit was set in rsa - write next value to rsa
step
9900
r3 shifted
2000
read and display RSA
2000
current step value
2000
current step bit was set in rsa - write next value to rsa
step
0000
r3 shifted
4000
read and display RSA
4134
current step value
4000
current step bit was set in rsa - write next value to rsa
step
0001
r3 shifted
8000

RQDX3 Init complete
dskini returned
disk online touch IP
4000
0001
0000

disk characteristics
media type id
2564
4036
unit size
0004
BFA0
volume serial number
00BC
614E

RQDX3 Online complete

dskonl returned
Ethernet Address is...
08  00  2B  06  92  6D

starting DEQNA csr
1032
starting DEQNA csr decoded
CSR Set
SR  XL  RL  OK
CSR Clear
RE  NI  BD  IE  XI  IL  EL  SE  RR  CA  R2  RI
reset DEQNA csr decoded
CSR Set
XL  RL  OK
CSR Clear
RE  SR  NI  BD  IE  XI  IL  EL  SE  RR  CA  R2
Post reset DEQNA csr
1030
enter setup tmit
DEQNA setup interrupt
setup tmit fired
seek
send initack
got init packet
block delivered
0000
0000
block delivered
0000
0400
(note- the block delivered count is in hex, so 0000 0400 = 1024 decimal)

  Correspondingly, here's the message that occurs on the server system running LOCALWRITE.EXE. The double write of Newblk: 0 is a bug I haven't bothered to run down yet. Note that these counts are in decimal...so 1024 = 1024.

$ run localwrite
dua1:[mvax1]zombie.dsk
Newblk: 0
Newblk: 0
Newblk: 1024

  To write a disk image onto a disk in a VAXstation I, it's very similar. Edit REMOTEWRITE.MAR and change the file name at label filnam to match the name of the image file to use.

filnam: .ascii  /dua1:[mvax1]undead.dsk/

  Save the edited file. Assemble it.

$ mac remotewrite

  Link it, sort of funny, so it's a system image.

 $ link/notrace/nodeb/system=0/header remotewrite

  Make a system, image with SIMH.

  Use NCP and make an entry, just like for the above example.

$ mcr ncp
NCP>set node undead addr 10.112 (address doesn't matter - make it unique for your site)
NCP>set node zombie service circuit QNA-0 hardware address 08-00-01-02-03-04
NCP>set node zombie  load file dua1:[test]vaxzombie.dsk
NCP^Z
$

  OK, all set, client-wise. Now go to your VMS system and run LOCALWRITE.EXE. It will sit there waiting for a request from a client system. Go to the client system and tell it to boot from the ethernet, however it wants that done. Things proceed from there just like for the PDP11 case.

  Alright, writing disk images works pretty good. But after a while I wanted to save the work I'd been doing on  these systems. It occurred to me that relatively minor changes to the code could produce client and server programs that worked the opposite direction - read blocks from the local disk and send them across the network to a server program, to save in an image file.

  To do that, it's almost exactly the same as above. Edit remread.mac or remoteread.mar, and change the filename at label filnam: to whatever you want to call the resulting image file. Assemble and link. Make NCP changes to get it loaded when the client wants to boot. Run LOCALREAD on a server system. Boot it up and off it goes. When it's done, you'll have an image file of the contents of the disk on the client.

  OK, there's the basics - read and write. But, I'm pretty paranoid - how could I be sure that the entire disks were getting read and written OK? I wrote a set of server and client programs that will compare the contents of a client's disk to a disk image file. LOCALCHECK.MAR, REMOTECHECK.MAR and REMCHK.MAC.

  Ya set 'em up just like the above - edit the filename at filnam, of the image file to check the disk against. Assemble & link, set up network boot. Run the server program and boot the client system via ethernet. The programs will start comparing block checksums. You'll get progress messages, and eventually a successful exit...or lots of messages about disk differences. Either way, good to know.

  And that's our story thus far.

Using the PDP11 T-Bit trap

   Recently, I've been writing a lot of PDP-11/73 code that runs with no OS. After a little practice, I've gotten the hang of it, more or less, and after you're used to it, it's really no harder than writing code for RSX. In some ways, it's easier...Device drivers? Don't need em! Rules? There are no rules!

  Where it suffers in comparison is the debugging tools available. The machine itself provides Micro-ODT, a limited subset of RSX ODT - basically you can read and change values by address or register number.

  So that leads to the old classic technique of diagnostic print - adding code to the program that prints out values as it executes, as you look for where a problem is occurring. And that works pretty well, although it can be a bit of an effort, and time consuming as well.

  On one of these projects, I ran into a problem where an RTS instruction was being overwritten by...something (this programming environment doesn't support read only PSECTS for code). After attacking with diagnostic prints and Micro-ODT, I wasn't getting anywhere - I couldn't home in on exactly when it happened, or what was the culprit. There were thousands of lines of  code,  and some of the code was interrupt driven, so things weren't happening in a simple linear fashion.

  It occurred to me that I could use the T-bit trap to determine exactly what instruction was overwriting the RTS.

  The T-bit is a bit in the PDP11 processor status word (bit 4, mask value 16.). When set, it causes each instruction executed to  trap via vector location 14. You can load this trap vector to point to a routine, which does...whatever it needs to do. It can  then return by doing an RTT (Return from Trap)  instruction.  Basically. There are some more fine points to it, but for this project, that's it in a nutshell.

  So, I coded up a routine to check the value of the mauled RTS instruction after each instruction. When the routine detects that the RTS has been changed, it halts the machine, to allow for further inspection via Micro-ODT. Additionally, it stores the return PC on the stack each time it is called, in a simplified circular list. When the T-bit is set, this code will execute after every instruction. It will give me a log of where it's been, and halt right after the instruction that mauls the RTS instruction. Should take me right to the scene of the crime, nicht wahr? Here's the code.

  Lessee. a few notes about the routine first...the PC list is just a block of words. The first word is used as the address of the next free entry in the list. When the list is full, the index is set back to the beginning of the list - thus it's more or less "circular". Label ZAZEN is the address of the RTS routine that is getting clobbered. At TBITX, we check to see it it is still 207 - the octal value of an RTS instruction. If so, proceed. If not, it's like Jim Morrison said... "WAIT! There's been a slaughter here!" Halt and figure out what just happened. Oh, and push is a macro that translates to mov    arg,-(sp), and pop translates to mov    (sp)+,arg.

ttrap:
        push    r0               ;save r0
        mov     ttab,r0          ;address of next free entry to r0
        mov     2(sp),(r0)+      ;save return PC in that entry
        mov     r0,ttab          ;update next free entry pointer
        cmp     #ttab+2000.,r0   ;are we at the end of the table?
        bge     ttrapx           ;if not, pass on
        mov     #ttab+2,ttab     ;if so, reset to top of table

ttrapx: cmp     zazen,#207       ;is the RTS instruction still there?
        bne     ttrapy           ;if not, halt
        pop     r0               ;restore r0
        rtt                      ;get back and execute the next
                                 ;instruction

ttrapy:  halt                    ;something overwrote the RTS!
                                 ;break out the .LST file and
                                 ;get to looking!

ttab:   .word   ttab+2           ;stores addr of next free wd in ttab
        .blkw   1024.            ;1000 words, plus some slop at end

  OK, now all I gotta do is load the vector, set the T-bit, run the program, and open the champagne. Warmed by the mellow glow of my own cleverness, I proceeded to do just that. I added this at the top of my program.

   mov     #ttrap,@#14   ;load t-bit vector with a debug routine
   mov     #340,@#16     ;load a regular sort of PSW in the vector
                         ;priority 7 - don't wanna get interrupted

   psw = 177776          ;16 bit address of the PSW
                         ;we're using 16 bit addresses for this
                         ;project - it's a utility, not an OS.

   tbit = 16.            ;bit 4 is the T-bit, 16. as a mask value
   bisw    #tbit,@#psw   ;this is an 11/73, so I can directly access
                         ;the psw, or use MTPS.

   But - it didn't work. I tried it again, and displayed the PSW after I set it. It didn't "take" - the bit was not set. I tried it again using MTPS (MoveToProcessorStatusword ) instruction - but. no soap there either.

  A little research found a footnote in one of the PDP11 processor handbooks, that pointed out that you can't set the T-bit value like the rest of the bits in the psw - you have to create a PC/PSW pair of words on the stack,with the bit set in the psw word, then let it take effect when that word gets put into the psw during an RTT instruction. OK, then, easy enough to do - I pushed a return address and new PSW on the stack, and then did an RTT instruction to make it happen.

   push    #60       ;push a PSW value with T-bit set, priority 1,
                     ;on the stack
   push    #zzz      ;push the address of the rest o' the program
   rtt               ;then return from trap, setting the T-bit and
                     ;resuming execution

zzz:    (rest of program goes here)

  And that set the T-bit just fine.

   At that point, I got a trap to my routine after every instruction. When the RTS instruction was overwritten, the machine halted, and I used Micro-ODT to have a look at the PC log buffer, to see what instruction overwrote it, and how it got there. Only...the log showed that the instruction that did it was part of a timing loop, that merely incremented a register, and tested its value. It didn't write memory at all, much less write to where the RTS instruction was. The instructions pointed to by the PC's stored in the list leading up to it were all the same, more iterations of the timing instructions. There was no way that this caused the overwrite. Yet, here it was. A little more thinking made me realize, that if the CPU hadn't overwritten the instruction, then it had to have been DMA from a controller card. I suspect that the RQDX3 was doing the overwrite - the RTS instruction was located adjacent to an RQDX3 buffer, and the RQDX3 accesses host buffers via DMA.

 I fiddled with the RQDX3 code for a bit, and couldn't figure out why it was machine gunning DMA where it wasn't welcome. So, for a solution, I put a couple or words between the RTS instruction, and the RQDX3 buffer, and the overwrite landed on those words instead of the RTS instruction. Not sure exactly why the RQDX3 is writing a word before its buffer starts, but, there's plenty I don't know about how the RQDX3 works. Maybe it's alignment related. But, it's results that I'm interested in on this project... The spice must flow. All's well that ends - and the T-bit trap gave me the clue I needed to figure it out.

VAXstation 1 Software Install - part 5 - RQDX3 IO

  The main difficulty in reading and writing disk blocks with the RQDX3 was a lack of documentation. There's no programmers guide to the RQDX3. There are generic guides to using MSCP, and there is some info about programming UDA50s available, which was useful since MSCP devices are all programmed pretty much the same. It took quite a bit of experimentation to get simple single block reads and writes to work. But, all's well that ends. Bob Schor's commented disassembly of the RT11 MSCP bootstrap was very helpful. The  best doccos I found for  doing this project were found online in the usual places...

 Mass_Storage_Control_Protocol_Ver_2.4.0_Jun92.txt. 
AA-L621A-TK_UnibusPortDescription_1982.pdf
AA-L619A-TK_MSCP_BasicDiscFnsV1.2_Apr82.pdf

  QBUS configuration rules put the first RQDX3 at  172150, which translates to ^X20001468 in MicroVAX 1 IO address speak. If you have a second RQDX3 in a MicroVAX 1, well, you're on your own. It will go in floating address space. The interrupt vector of the 1st RQDX3 is 154, which we don't care about at all, since we don't use disk IO interrupts in this project - it's hard enough to get all of this to work without trying to  overlap disk and ethernet IO.

  The RQDX3 only has two registers, which doesn't make it easier to deal with, since they are  overloaded to hell and gone, doing a dozen different things, depending on what's happening. They are rich in state, and it's up to you to keep track of what state things are in. The two registers are called IP and SA. 

 The IP register has two uses. When written with any value, it causes a hard reset of the controller.   When read while things are operating. it causes the controller to initiate "polling", whatever that is. Just kidding, I know what that is. I'm just not all that interested in it for this project. 

  The SA register (where do they get these crazy names?) has four functions (see? I told you, they overload the hell out of these two registers). When read during initialization, it sends and receives data related to initialization. When written during initialization, it sends information to the controller. When read during normal operation, it returns status and error info. When a 0 is written to it, at any time, it tells the controller that a purge has been completed, whatever that is. Seriously, we don't use it in this program, so I don't need it.

  The real communication with the card is done a lot like the way the DEQNA does it - through lists of buffers that the card DMAs in and out of memory, willy-nilly, anytime it feels like it. Again, just kidding. You can control when it happens. More or less.

  But enough of these vague generalities - let's get right on to initialization. 

  To get ready for this, you need to prepare a table of four "steps" - longword values that will be passed into the RQDX3 during initialization. The table looks like this...

    istbl:
    ; Step 1 - assorted configuration bits        
               .word   ^X8000  
                        ;Step 1 bits
                        ;[15] = 1,
                        ;[14] (WR) = 0,
                        ;[13:11] (cmd  ring size as power of 2) = 0
                        ;[10:8]  (resp ring size as power of 2) = 0,
                        ;[7]  (Interrupt Enable/Disable) = 0
                        ;[6:0] (int vect/4) = 0
                        ;command and response rings = 1 element
                        ;no interrupts
                        ;no interrupt vector.

    ; Step 2 - Ring base address, low 16 bits. Entered here as 0,
               since PIC coding requires that we fill it in at                       runtime
     zazz:     .word    0

    ;Step 3 - Ring base address high 6 bits (always 0 for us),
              and Purge/Poll bits (likewise, 0 for us).
              .word   0 

    ;Step 4 - The GO bit. Finishes up the initialization                            .word   1

    ;End Marker - a null longword to signal the end
              .long   0 

  Since the table of values used for initialization requires the address of the command and response rings (to be stored in location zazz, above), let's discuss setting them up here, even though they don't get used until we do the ONLINE command.

  We indicated that we have only one command and one response packet, in the second entry above. You specify how many you have as a power of 2 - we entered zero for each there, so 2 to the 0th power is 1. RP and CP are the response and command packets, below. You put their addresses into the command and response rings table. Gotta do almost all of this at run time, since we're writing PIC here. Each entry of a command packet in the rings table consists of the address of the packet, and an ownership flag word - when it's ^X8000, we are saying that the the RQDX3 owns it. When the RQDX3 finishes processing it, it sets the flag to be non-negative - that's how we know it's done, and that we can use it again - and more important, when doing a read or write command, we then know that the card is through and the data is now valid

rp:    .blkb    64
cp:    .blkb    64

rings:
rpd:    .word    0
        .word    0
cpd:    .word    0
        .word    0

                moval    rp,rpd
                movl    #^X8000,rpd+2
                moval    cp,cpd
                movl    #^X8000,cpd+2

                moval    rings,zazz

  OK, Once all of this is set up, to start the initialization, you write anything into the IP register. CLRW writes a 0 to it.

    ;Define some symbols for the registers
           rcsr   = ^X20001468     ;RQDX3 CSR starts her
           rip    = rcsr           ;1st reg is called I
           rsa    = rip+2          ;2nd reg is called SA

           clrw    @#rip

  I should mention that longword accesses aren't allowed to the IO space on the MicroVAX - use word instructions. Also, data structures need to be longword aligned, or difficult to debug problems can occur.

  So that starts this moving. Now, read a word from the SA register. If it's negative, an error has occurred.  If it's positive, check and see if the initial step value bit is set in it (the initial match  value is ^X0800). If that bit is set, shift the match value one bit left, and then write the first value from ISTL into the SA register. Get another value out of the SA register, and test it for negative and bit match. If so, write the next istbl value to SA.  Repeat these steps until the match value hits ^X8000. If you get that far successfully, then the card is now initialized.

  OK, then you have to put the card into the online state. It's a whole 'nother story. The ONLINE command uses the command packets and rings we discussed above. Let's talk bout the contents of the packets themselves.

 The command packet for the ONLINE command is laid out thusly... 

                   31                             0               
                  +-------------------------------+              
                  |   command reference number    |              
                  +---------------+---------------+              
                  |   reserved    |  unit number  |              
                  +---------------+-------+-------+              
                  |   modifiers   | rsvd  | opcode|              
                  +---------------+-------+-------+              
                  |  unit flags   |    reserved   |              
                  +---------------+---------------+              
                  |           reserved            |              
                  +-------------------------------+              
                  |                               |              
                  +---        reserved         ---+              
                  |                               |              
                  +-------------------------------+              
                  |  device dependent parameters  |              
                  +-------------------------------+              
                  |           reserved            |              
                  +-------------------------------

  Command reference number - we don't use it - we're doing one command at at time, so we don't need to keep track of them. Unit number for me is always gonna be 0. If you need a different unit number - you know what to do.  The opcode is mscp$k_op_onlin, ^X0009. Modifiers - don't need any. Unit flags, likewise. Device dependent parameters - none. All in all, it's a pretty simple packet.

  The response packet is where the RQDX3 tells us how the command went. For the ONLINE command, it is laid out like this...

                   31                             0               
                  +-------------------------------+              
                  |   command reference number    |              
                  +---------------+---------------+              
                  |sequence number|  unit number  |              
                  +---------------+-------+-------+              
                  |    status     | flags |endcode|              
                  +---------------+-------+-------+              
                  |  unit flags   |multiunit code |              
                  +---------------+---------------+              
                  |      reserved         |spndles|              
                  +-------------------------------+              
                  |                               |              
                  +---     unit identifier     ---+              
                  |                               |              
                  +-------------------------------+              
                  |     media type identifier     |              
                  +-------------------------------+              
                  |           reserved            |              
                  +-------------------------------+              
                  |           unit size           |              
                  +-------------------------------+              
                  |      volume serial number     |              
                  +-------------------------------+              

  Command reference number and sequence numbers - I don't need 'em. Endcode - forget about  it. The status is where the status of the action is returned - we check it for errors. All the rest, don't need 'em. The media type identifier, unit size and volume serial number are interesting, but...don't really need 'em for this project

  OK, so you've set up these packets, and have gone through initialization as per above. Now, to execute the ONLINE command in the command packet,  write anything but zero into the IP register to launch things into motion. Then, loop until the value in rpd+2 is not negative, which means the online command has completed. Check the response packet status field and see if there was an error (success will be zero, anything else was an error). What could be simpler?

            mov    #1,@#rip

  Then you loop on the value in rpd+2 until it is non-negative

            1$:    tst    rpd+2
              blss    1$

  OK, all of this work, and all we've done is put the disk successfully online. Now, let's see if we can write a block (that we've presumably received on the ethernet - remember the whole point of this project?)

  Writing a block (and reading one, for that matter)  is not all that different from the ONLINE process. You set up the Command and Response packets, set up the RIng table, and then write a non-zero value to the IP registers. The main difference is in the command packet - it's a little different.

                   31                             0              

                  +-------------------------------+             
                  |   command reference number    |             
                  +---------------+---------------+             
                  |   reserved    |  unit number  |             
                  +---------------+-------+-------+             
                  |   modifiers   |  caa  | opcode|             
                  +---------------+-------+-------+             
                  |          byte count           |             
                  +-------------------------------+             
                  |                               |             
                  +---         buffer          ---+             
                  |                               |             
                  +---       descriptor        ---+             
                  |                               |             
                  +-------------------------------+             
                  |      logical block number     |             
                  +---------------+---------------+             
                  |   entry id    | hrn or entloc | (optional)  
                  +---------------+---------------+             

  You have to enter a byte count (512, since we're dealing with disk blocks), a logical block number (they start at 0), and a buffer descriptor. The format of a buffer descriptor includes support for all sorts of exotic situations, none of which apply here, using a QBUS and an RQDX3. It boils down to, put the address of the (read or write) buffer in the first longword, and zeroes in the other two. Unit number - we're still using 0. The opcodes for read and write, mscp$k_op_read and mscp$k_op_write, are ^X21 and ^X22. When you get the packet set up, set up the cpd, rpd and rings table again (if you need to), and once again write something to the IP register to make the magic happen. Loop on the value of rpd+2, just like for the ONLINE command, to wait for it to complete. And, if everything has gone just right, your block of data should have been read or written....

  In using the above techniques to read and write, I noticed that every few hundred thousand reads or write, the RQDX3 hangs up - never indicates completion. When that happens, all I do is go through the initialization and online steps again, and then do the read or write again.

  And a note about the returned statuses. a status of 0 is success. Errors take a myriad of formats. The most common one I've run into is invalid input data. This error code consists of offset*256+1. The offset refers to the offset in the command packet that is invalid - so for instance, a returned status of ^X1C01  - the 1 in the low bit tells us, invalid input. Divide it all by 256 and you get ^X1C - that's an offset into the command packet of 28, which is the logical block number field - you get a 1C01 error when you try and write to a logical block number that doesn't exist (ie, too high for the size of the disk).

  So, that's a sketchy, incomplete and confusing summary of how to talk to an RQDX3 in the simplest way possible. Poorly written, I'm well aware - but, this, along with the documentation  sources I mentioned above should give you a fighting change to make an RQDX3 do something. And pretty much everything I've described applies to RQDX3's when used in a QBUS PDP11 as well as in a QBUS MicroVAX. Actually, when I wrote the PDP11 versions of the code for this project, it was easier than the MicroVAX version - PDP11 code loads at 0, instead of 7000, so I didn't have to write it PIC. And the IO page addressing is simpler on the PDP11, which made finding the cards easier.

 Next and final installment - the programs that use all this info to  load and save disk images to a VAXstation/MicroVAX 1, and QBUS PDP11s as well.