D. Gesswein MFM-Emulator and SIMH

[spiceminer]

Dear all!

Today I have tried to save the contents of my Vaxstation 2000 RD54 Drive using David Gessweins "PDP8 MFM Emulator" https://www.pdp8online.com/mfm/mfm.shtml

Obviously, there are some errors (see annex). The drive itself works fine on the VAX - at least VMS "show errors" reports no findings and the machine is booting fine.

Does anybody know if captured files (Hexdump, Emu File, Transitions file) of the RD54 could be used for SIMH or of the files/directory structure could be restored somehow
on the PC?

Thanks a lot
Stephan

 

[djg]

Have you tried attaching the extracted data file (sector image) to SIMH and see what happens? This won't work with a real RQDX3 since it uses areas at the beginning of the disk for its own use. Those need to be removed from the image for SIMH. Nobody has figured out the remapping the RQDX3 does and written software to remove it.

Your output doesn't show the sectors with different format at the beginning of the disk a real RQDX3 uses so its possible that it does less remapping so might work.

The bad block set and associated messages may indicate that the controller is remapping those tracks to different areas of the disk. I don't know how that works so my code doesn't remap those so this may still cause problems with those sectors either returning bad data or all data will be shifted a sector after it if it just skips the bad sectors.

Looks like it is doing funny format at cylinder 1222 but this probably won't be an issue.

 

[spiceminer]

Have you tried attaching the extracted data file (sector image) to SIMH and see what happens?

Thanks a lot for the answer.
As the hard disk is from a VS2000 it has no "real" RQDX3 just some onboard logic for MFM. If this behaves like a real RQDX3 QBUS card I cannot tell.
Which is the sector image ? When I uses mfm_read, I obtain a "hexdump", a "flow transition" and an "emulator" file ? Or do I need to put the "flow transition" file through mfm_util first to get the sector image?

Thanks a lot
Stephan

 

[djg]

When I uses mfm_read, I obtain a "hexdump", a "flow transition" and an "emulator" file ? Or do I need to put the "flow transition" file through mfm_util first to get the sector image?

Not the terminology I used in the documentation so not sure what you are calling hexdump.

http://www.pdp8online.com/mfm/code/mfm/mfm_read_util_doc.html

You want --extracted_data_file -e filename. If you didn't create that when you read the disk you can use mfm_util to generate it from the --transitions_file -t filename.

 

[djg]

Did the extracted data file work with SIMH?

 

[spiceminer]

Did the extracted data file work with SIMH?

No, not yet. maybe I did something wrong. Was very busy in the last days, will try again at the weekend. In addition I will try if the Vaxstation will boot with the emulator instead of the real MFM drive. Thanks so much for your advice so far.

 

[spiceminer]

Dear all!

here is what SIMH shows me when I try to boot the image.

1.) My vax.ini

set cpu 512M
attach nvr vax.nvr
set rq0 RD54
attach rq0 vax.emu

2.) the emulator output



Unfortunately, the ka610.bin (for the VS2000 emulation) is not working, as soon as I try this, I get following message:



Can anybody point me to an error or is that in principle telling me that the vax.emu image from the MFM emulator (size=365MB) is not working with simh?

Thanks a lot
Stephan

 

[djg]

I played with a RQDX3 image from my VAXstation and image made made with SIMH from procedure online. In logical block 1 should be some data that if it doesn't find you get the ?43 error.
For my RQDX3 image I needed to remove 136 sectors of data to align with the SIMH image. The controller uses some of the disk for its own use. I was then able to boot my RQDX3 image with SIMH. Likely still issues where bad blocks were spared.

You may be able to do something similar.
This is what I needed to be at 0x200. The other image that I made under SIMH has some of the bytes the same but many different so this wasn't too diagnostic.

00011200 01 00 00 00 9b 00 00 00 74 40 01 00 01 02 01 00 |........t@......|
00011210 02 00 03 00 04 00 05 00 fd 0e 01 00 6c 87 00 00 |............l...|
00011220 09 00 09 00 00 00 00 00 00 00 08 00 01 00 01 00 |................|
00011230 00 00 00 00 00 00 00 fa 00 fe a7 d1 00 76 d3 7d |.............v.}|
00011240 33 fe 8d 00 07 03 05 00 00 00 00 00 00 00 00 00 |3...............|
00011250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

But this that should be at 0x3c0 was the same in both images. Should be able to find this and then see if you see the binary data before it. Trim/pad the image as needed to put them at the correct location in the file.
000113c0 00 00 00 00 00 00 00 00 00 00 00 00 20 20 20 20 |............ |
000113d0 20 20 20 20 20 20 20 20 4d 49 43 52 4f 56 4d 53 | MICROVMS|
000113e0 20 20 20 20 53 59 53 54 45 4d 20 20 20 20 20 20 | SYSTEM |
000113f0 44 45 43 46 49 4c 45 31 31 42 20 20 00 00 ca a5 |DECFILE11B ....|

In current simh you can make a microvax2000. My RQDX3 image did a fatal bug check on microvax2000. It worked on microvax2 and microvax3900.

 

[spiceminer]

Thanks a lot @djg for the insights.
Likely preparing an MFM image in SIMH and just copying it to the MFM-Emulator is not an option, at least not an easy one.

 

[djg]

Likely preparing an MFM image in SIMH and just copying it to the MFM-Emulator is not an option, at least not an easy one.

It would require some code changes and experimenting as a minimum.

Would need to add support to ext2emu. Your format doesn't have the funny format sectors at the beginning the RQDX3 creates but does have funny sectors at the end. Unknown if those are needed or leftover from previous format. My code doesn't support sectors of different format.

If you want to use the existing disk image we would need to figure out how the back blocks are handled. If you created a new image without bad blocks could ignore that.

 

[spiceminer]

@djg No need to use some specific existing image. It would be convenient to have the ability to work with an image on SIMH and transfer it back to the real machine and vice versa.

You suppose the VS2000 Controller behaves differently compared to the RQDX3?

I can make an image of a freshly formatted harddrive like RD54 or RD32 in case you are interested?

 

[djg]

You suppose the VS2000 Controller behaves differently compared to the RQDX3?

Your log of mfm_read shows it doesn't have the different format sectors at the beginning of the disk I see with my vaxstation with RQDX3.

I can make an image of a freshly formatted harddrive like RD54 or RD32 in case you are interested?

If it has bad sector so you are getting these errors not sure it will be useful. May need to use the board as emulator and format that so there are no bad sectors.

Bad block set on cyl 204, head 4, sector 255
Bad block set on cyl 204, head 4, sector 255
Logical sector 255 out of range 0-16 sector 255 cyl 204 head 4 phys sector 17

 

[leegleason]

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. That would provide the logical block sort of image file that SIMH likes. without any of the extra jazz on rhe RD54 like replacement blocks, etc. Also, you mentioned above creating an RD32 image for testing - be advised that SIMH creates RD32 disk images with an incorrect number of blocks. They work on SIMH, but other utilities and actual RD32's can become applexed at seeing the wrong number of blocks in an image. Ran into this using PDP11GUI to copy RD32 images back and forth to real RD32s.

 

[Wildfire]

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. That would provide the logical block sort of image file that SIMH likes. without any of the extra jazz on rhe RD54 like replacement blocks, etc. Also, you mentioned above creating an RD32 image for testing - be advised that SIMH creates RD32 disk images with an incorrect number of blocks. They work on SIMH, but other utilities and actual RD32's can become applexed at seeing the wrong number of blocks in an image. Ran into this using PDP11GUI to copy RD32 images back and forth to real RD32s.

@Joerg Hoppe
FYI

 

[leegleason]

@Joerg Hoppe
FYI

"@Joerg Hoppe"

Eh? I actually exchanged a few messages with Joerg about this, when I had this problem, and verified that his code is correct, and SIMH is wrong. I haven't bothered to report it to the SIMH maintainers, since the problem reporting process looked a little too rococo for me to figure out, and I figured, I'm likely the last person on the planet using RD32s and their images. I just patched the SIMH executable to have the right size (easy patch - there was only one place in the image with the incorrect value).

 

[czunit]

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)

 

[Wildfire]

"@Joerg Hoppe"

Eh? I actually exchanged a few messages with Joerg about this, when I had this problem, and verified that his code is correct, and SIMH is wrong. I haven't bothered to report it to the SIMH maintainers, since the problem reporting process looked a little too rococo for me to figure out, and I figured, I'm likely the last person on the planet using RD32s and their images. I just patched the SIMH executable to have the right size (easy patch - there was only one place in the image with the incorrect value).

Ah, ok - so all has been done...

Well, you are not the last person who is using RD32s irl and emulated
Yes, it would be good to know how you patched SIMH...

 

[tradde]

I have an RD32 in my DEC Rainbow 100. I too would like to know what you patched. TIA.

 

[czunit]

I wonder if I'm the last person with running RD53's

 

[leegleason]

I wonder if I'm the last person with running RD53's

Nope...I still run a few, and have a few good ones stocked. Although as each of the current ones fail I'm switching to Gesswein emulators. RD disks ain't diamonds - they're not forever.