Monday, December 31, 2012

DZREAD

    The complementary program to DZWRITE, is DZREAD. It reads an RX50 floppy on a PRO and writes it to a file.

  Here it is...

dzread.mac

  Assemble Link and run like DZWRITE. Or, if you're  tight on memory and disk space, you can link it to FCSRES and save a few bytes. DZWRITE can be linked this way as well.

$ MAC DZREAD
$ LINK DZREAD/OPTION
Option? LIBR=FCSRES:RO
Option?

Put floppy in...
$ DISMOUNT DZ2:
$ MOUNT/FOR DZ2:
$ RUN DZREAD
DZR>SOMEFILE.DSK=DZ2:
$

While writing this program, I ran into a crazy P/OS bug. Originally, I wrote it to read the floppy, block by block, and when I got a return status of IE.BLK (logical block too large) , I would know I was at the end and could close the DSK file and exit. When I did that, I got DSK files that were 801 blocks long....not right since the RX50 floppy is only 800 blocks big. A look at the 801st block in the output file revealed that it was a copy of the first block from the floppy. Evidently the DZ driver has an off by  one error in its range checking, and when the DZ controller and floppy drive gets a request for a block too large, it returns the block modulo 800. Even worse, the same thing occurs for writes - if you request the 801st block be written, it writes it to the first block...not good. DZWRITE didn't see that problem since DSK input files are only 800 blocks or less long, so it never tried to write an 801st block. 

  You can see this problem with DUMP. If you mount an RX50 foreign, and

$ DUMP/BL:800

  Which requests the 801st block, since they start at block 0, you'll see the first block dumped out. requesting block 0 and block 799 returns, correctly, the first and last blocks.

  I modded DZREAD to count blocks and stop at 800. Now the output files are the right size, and have all the right blocks in 'em.

Thursday, December 20, 2012

DZWRITE

  Recently I decided that I could reduce the storage space consumed by the assorted small PDP11 parts here by assembling some of them into systems. I had a BA23 cabinet and a pretty good selection of QBUS cards to work with. I installed an 11/73 CPU, a memory board, a DLV11J, a DHV11, an RQDX3, an RX50 and an RD53.

   The RD53 needed formatting, so I needed XXDP running on the system. I tried to use VTserver to load XXDP into memory, but, for some reason, it doesn't seem to play well with Windows 7 as the host. I spent quite a lot of time trying to debug it and discovered that it often completes IOs without bothering to get any input characters. This confuses the rest of the program (and me).

  Growing weary of Microsoft and Visual C++, I looked for another solution. It occurred to me that my old PRO-380 (formerly a VAX Console) had RX50s on it as well, that would allow me to create media for the 11/73. I dusted it off and spent a couple of days troubleshooting it. It was having all sorts of disk errors. I spend several days formatting and testing a goodly number of ST506 disks before I realized it was a bad disk controller card. I popped in a spare and all was well. After tussling with it and struggling with VTserver, I was glad to get a little closer to the original project again.

  I wrote a little program that will read an RX50 disk image file and write it to a floppy. On the long chance that there is anyone left in the world interested in using a PRO running P/OS system to support their PDP11, here it is... 

dzwrite.mac

  To use... 
$ MAC DZWRITE 
$ LINK DZWRITE
Insert floppy... 
$ DISMOUNT DZ1: 
$ MOUNT/FOR DZ1: 
$ RUN DZWRITE
DZW>DZ1:=somefile.dsk
DZW>^Z
$ DISMOUNT DZ1:

  The image I used was a copy of XXDP.DSK I found on the web that had the RQDX3 formatter on it. After DZWRITEing the image onto an RX50, I loaded it on the 11/73, and it booted fine. Unfortunately, the RQDX3 formatter sees the RD53 as an RX33, and is reluctant to format it, so it looks like I have some more hardware to sort out on that end...