D. Gesswein MFM-Emulator and SIMH

[shirsch]

Oh, how did you patch it? I've always wondered why SIMH strives to be authentic, but can't read a drive image in an authentic manner.

I ran head first into this issue with RX50 floppy images. An image that simply reads off sectors in an order determined by their headers (as ALL floppy image capture devices do) will not work in SIMH or Xhomer - and vice-versa. It was the vice-versa that nailed me when I discovered that a large majority of RX50 images on the web will not result in a working diskette when written to media. I ended up writing a pair of little Python tools to shuffle sectors around in both directions.

 

[djg]

Lessee, is your MIcroVAX 2000 connected to the ethernet? You could boot it as a satellite of a SIMH VMS instance, mount the 2000's RD54 /FOREIGN on the load host, and copy the blocks over the network to a file.

Do you know of any writeup on doing this that a non VMS person could follow? I have made a VMS image under SIMH using I think this procedure https://microvax2.org/wp/2023/05/03/microvax-i-vax-vms-4-7-successful-bootstrap/ and can boot my VAX Station which has Ethernet but don't really know how to do this. Would like to see if can figure more on converting emulator images to SIMH but this month is booked so will be future project. Getting image this way would be good to compare to real disk image.

 

[pbirkel@gmail.com]

I ran head first into this issue with RX50 floppy images. An image that simply reads off sectors in an order determined by their headers (as ALL floppy image capture devices do) will not work in SIMH or Xhomer - and vice-versa. It was the vice-versa that nailed me when I discovered that a large majority of RX50 images on the web will not result in a working diskette when written to media. I ended up writing a pair of little Python tools to shuffle sectors around in both directions.

Where are those written up and published? (nudge, nudge ...)

 

[leegleason]

I ran head first into this issue with RX50 floppy images. An image that simply reads off sectors in an order determined by their headers (as ALL floppy image capture devices do) will not work in SIMH or Xhomer - and vice-versa. It was the vice-versa that nailed me when I discovered that a large majority of RX50 images on the web will not result in a working diskette when written to media. I ended up writing a pair of little Python tools to shuffle sectors around in both directions.

This is why I like to capture disk and floppy images using the actual OS. I read them in logical block order using VMS or RSX and save images that way instead of reading by tracks and sectors using a PC or other device. I did write an RSX utility to convert track-and-sector order images to LBN images, since I occasionally get RX50 images in that format. Didn't write one to go the other way since I don't have any need for track-and-sector format.

 

[leegleason]

Do you know of any writeup on doing this that a non VMS person could follow? I have made a VMS image under SIMH using I think this procedure https://microvax2.org/wp/2023/05/03/microvax-i-vax-vms-4-7-successful-bootstrap/ and can boot my VAX Station which has Ethernet but don't really know how to do this. Would like to see if can figure more on converting emulator images to SIMH but this month is booked so will be future project. Getting image this way would be good to compare to real disk image.

I don't have one handy, but there are lots of web pages out there that have instructions on installing VMS as a cluster and adding diskless satellites to them.

 

[leegleason]

Oh, how did you patch it? I've always wondered why SIMH strives to be authentic, but can't read a drive image in an authentic manner.

(Does this also happen with RQDX1 and RQDX2? I seem to recall Xhomer can read a real Pro/350's RD53 without issue)

Its not much of a patch, not like I'd think of in the VAX/VMS days, where the PATCH utility would let you patch in whole new routines with trival ease. It's more of a hex edit. I looked at SIMH module pdp11_rq.c, where data structures for VAX and PDP11 MSCP devices are set up. There you can see a comment block with a line of info for each disk type. The one for RD32 says

RD32 17 6 820 6 1 4*8 83204 Seagate ST-251

Which all looks right, especially the size, 83204, which PDP11GIU uses. But, further on down where the structures are created for each disk, it says

#define RD32_LBN 83236

83236, where it needs to be 83204.

If I was a C programmer (shudder!) and skilled GIThub user, I could just correct it in the source file and rebuild, but that's not where my hobbyist interests lie. I had a look at SIMH image PDP11.EXE, using a binary editor (XVI32 I've been using it forever), and searched for bytes 24 45 01 (83236, in hex, reversed order). Luckily, there was only one instance in the file. To double check that it was the right place, I checked some nearby longwords to make sure it was the structire for the RD32 (there was a an 820 (34 03), the count of cylinders, a few longwords back, and a 200 (C8) a few after, just like in the source file. I deposited 04 45 01 (83204, in hex and reversed) saved it, and now SIMH was making RD32 disk images that were the same size as PDP11GUI and other tools liked.

 

[shirsch]

This is why I like to capture disk and floppy images using the actual OS. I read them in logical block order using VMS or RSX and save images that way instead of reading by tracks and sectors using a PC or other device. I did write an RSX utility to convert track-and-sector order images to LBN images, since I occasionally get RX50 images in that format. Didn't write one to go the other way since I don't have any need for track-and-sector format.

Right, but if you do it that way the resulting image cannot be used in a hardware emulator (flashfloppy in my case). It's a mystery to me why the DEC operating systems read in physical order to begin with. My view is that if you have sectors 1-9 on a track, then they should be read in a sequence based on the sector id header rather than their physical occurance on the media.

 

[shirsch]

Where are those written up and published? (nudge, nudge ...)

I posted some explanation of the process and rationale on the DEC Discord, but here are the utilities.

 

[leegleason]

Right, but if you do it that way the resulting image cannot be used in a hardware emulator (flashfloppy in my case).

Good point. My needs for these images are just in SIMH, and as VCP and virtual disks under RSX and VMS, where logical block order is required.

 

[shirsch]

To me, "logical" order is when they are sequenced in a position-independent manner by sector header and "physical' is what results from a read in the native environment (where they apparently come out in order of how they appear after index. But, it's just syntax...

 

[leegleason]

I've never given it much thought. I could be all wrong with that term. I just call it logical block order, because when I write utilities that access disks via the OS's I use (RSX and VMS), I'm using IO.RLB and IO.WLB QIOs (Read Logical Block and Write Logical Block). The Logical there doesn't really refer to any data ordering, though - it's Logical (treating the disk as one big collection of numbered blocks) vs Virtual (block numbers are relative to the start of a file).

 

[czunit]

Hm. I have to think about all of this for a bit and look through my notes. A long time ago I blew a SYSVMR on my RSX11M 4.0 disk (Fujitsu 5.25 120mb drive on a MTI ESDI controller emulating MSCP) and it was non-bootable for 20 years. Finally fired up pdp11gui, read the disk to a file, fired it up in Simh with no problems, figured out the problem (easy when you can sysgen M in about 3 minutes on an RL02 image) and fixed the disk. Then copied it *back* to the Fujitsu drive and all was well.

Wonder why this worked.

Oh wait, maybe because it wasn't the Gesswin emulator. This is a bit of a pickle.

 

[leegleason]

Hm. I have to think about all of this for a bit and look through my notes. A long time ago I blew a SYSVMR on my RSX11M 4.0 disk (Fujitsu 5.25 120mb drive on a MTI ESDI controller emulating MSCP) and it was non-bootable for 20 years. Finally fired up pdp11gui, read the disk to a file, fired it up in Simh with no problems, figured out the problem (easy when you can sysgen M in about 3 minutes on an RL02 image) and fixed the disk. Then copied it *back* to the Fujitsu drive and all was well.

Wonder why this worked.

Oh wait, maybe because it wasn't the Gesswin emulator. This is a bit of a pickle.

It worked because PDP11GUI uses the MSCP controller, and gets its data in logical block order, and just the data blocks - no skew, no interleave, no extra MSCP jazz...as Detective Joe Friday might have said, just the blocks. SIMH likes its disk data that way, so it worked there fine. Then when you wrote it back via PDP11GUI, it used the MSCP controller to do the writes, so jjust logical blocks going in was fine. And you could have written it to the Gesswein emulator instead of a real disk, as long as the Gesswein emulator was connected to the system through the MSCP controller. The MSCP controllers abstact away all of the complicated physical disk complications. Anyway, this has been my experienece and understanding. I've copied lots of images to and from physical disks via PDP11GUI to SIMH and back (that's how I discovered the SIMH RD32 size issue). Now I use the ethernet to do these xfers, since PDP11GUI takes a long time at serial speeds.

 

[spiceminer]

Do you know of any writeup on doing this that a non VMS person could follow? I have made a VMS image under SIMH using I think this procedure https://microvax2.org/wp/2023/05/03/microvax-i-vax-vms-4-7-successful-bootstrap/ and can boot my VAX Station which has Ethernet but don't really know how to do this. Would like to see if can figure more on converting emulator images to SIMH but this month is booked so will be future project. Getting image this way would be good to compare to real disk image.

In case you just intend to boot your real VS2000 from another (bigger) real VAX machine I can help.
You just need to register a VMS Cluster license "VAXCLUSTER" on the host machine.
login as SYSTEM. Then register a product authorization key with
@sys$update:vmslicense.com

https://docs.vmssoftware.com/docs/VSI_LMF_GD.pdf

Afterwards the Cluster Config will guide you through
@SYS$MANAGER:CLUSTER_CONFIG.COM
Setup one Satellite. You need to enter the MAC Address of the "diskless satellite". Tell the skript you wont be using a local page file.
Then you connect the ethernet of both machines and boot the diskless VAX with "BOOT ESA0"