ext2emu support for 3B2

[Seth Morabito]

After several years of not firing up my 3B2/400, I've started to try to experiment with the MFM emulator again.

It's already possible to dump real physical MFM hard disks and use them with the SIMH 3B2 emulator, but I'd really like to do the opposite: build hard disk images using the SIMH 3B2 emulator, and use those images with the MFM emulator. Unfortunately, it looks like there's no support in "ext2emu" yet, because the MFM track definition is missing from mfm_decoder.h. I'd like to help get this added.

The 3B2/310 and 3B2/400 both use a NEC uPD7261a hard drive controller. I've uploaded the track layout from the datasheet here:

https://archives.loomcom.com/share/upd7261a_track.png

I also have uploaded a compressed emulator file I dumped from a real 72MB hard disk here (9 heads, 925 cylinders, 18 sectors per track, 512 byte sectors)

https://archives.loomcom.com/share/cdc_86_gideon_20240419.emu.gz

I've observed the following gap lengths used by the firmware:

GPL1: 16

GPL2: 13

GPL3: 15

If there's any other information I can provide to help get this implemented, please let me know!

-Seth

[Seth Morabito]

On Saturday, April 20, 2024 at 6:05:46 PM UTC-7 Seth Morabito wrote:

 Unfortunately, it looks like there's no support in "ext2emu" yet, because the MFM track definition is missing from mfm_decoder.h. I'd like to help get this added.

I made a stab at a first pass of implementing this, but unfortunately haven't been successful yet. The changes I've made so far are here:

https://github.com/dgesswein/mfm/compare/master...sethm:mfm:3b2_mfm_test

I implemented the TRK_L definition for the 3B2 based on the datasheet for the NEC uPD7261A starting on page 6-87 of the 1987 Microcomputer Products Volume 2 databook (http://www.bitsavers.org/components/nec/_dataBooks/1987_Microcomputer_Products_Vol_2.pdf). The gap lengths come from the 3B2's firmware, which sets up the controller with GPL1=16, GPL2=13, and GPL3=15. The firmware also specifies to use CRC and to use 4E for ID and DATA header fill bytes.

The thing I'm most suspicious of is the "F0" byte following the "A1" byte in the DATA header. The datasheet seems to indicate that this marker byte also has a clock bit dropped, like the A1 byte. I've tried it both with and without the dropped clock bit, but no luck. My calculation for the dropped clock bit F0 data pattern might also be wrong, I did it by hand.

Later tonight I'll try to dig up the diagnostic floppy, which should give me more information in the form of the status and error bytes coming out of the uPD7261A.

-Seth

[d...@pdp8online.com]

This make a emulator file that I can decode with mfm_util. The example file you pointed to has data flag byte 0xf8 so I changed to just filling that value. I haven't seen the flag byte use dropped clock.

diff --git a/mfm/inc/mfm_decoder.h b/mfm/inc/mfm_decoder.h

index d3f4ecc..82e3d50 100644
--- a/mfm/inc/mfm_decoder.h
+++ b/mfm/inc/mfm_decoder.h
@@ -2592,7 +2592,15 @@ DEF_EXTERN TRK_L trk_att_3b2[]
         {7, TRK_FIELD, 0x00,
           (FIELD_L []) {
               {1, FIELD_A1, 0xa1, OP_SET, 0, NULL},
-              {2, FIELD_CYL, 0x00, OP_SET, 1, NULL},
+              // Upper byte of cylinder is xored with 0xff
+              // Lower byte is unmodified
+              {1, FIELD_FILL, 0xff, OP_SET, 1, NULL},
+              {0, FIELD_CYL, 0x00, OP_XOR, 16,
+                 (BIT_L []) {
+                    { 8, 16},
+                    { -1, -1},
+                 }
+              },
               {1, FIELD_HEAD, 0x00, OP_SET, 3, NULL},
               {1, FIELD_SECTOR, 0x00, OP_SET, 4, NULL},
               {2, FIELD_HDR_CRC, 0x00, OP_SET, 5, NULL},
@@ -2604,7 +2612,7 @@ DEF_EXTERN TRK_L trk_att_3b2[]
         {516, TRK_FIELD, 0x00,
            (FIELD_L []) {
               {1, FIELD_A1, 0xa1, OP_SET, 0, NULL},
-              {1, FIELD_F0, 0xf0, OP_SET, 1, NULL},
+              {1, FIELD_FILL, 0xf8, OP_SET, 1, NULL},
               {512, FIELD_SECTOR_DATA, 0x00, OP_SET, 2, NULL},
               {2, FIELD_DATA_CRC, 0x00, OP_SET, 514, NULL},
               {0, FIELD_NEXT_SECTOR, 0x00, OP_SET, 0, NULL},

[Seth Morabito]

On Monday, April 22, 2024 at 6:06:43 PM UTC-7 d...@pdp8online.com wrote:

This make a emulator file that I can decode with mfm_util. The example file you pointed to has data flag byte 0xf8 so I changed to just filling that value. I haven't seen the flag byte use dropped clock.

Thank you so much, this change is definitely right! The datasheet was flat out wrong about the data flag being 0xf0, and I simply misinterpreted it about having a dropped clock bit. I would never have thought to try the XOR'ed cylinder upper byte, either. All that was necessary.

There is still another hurdle, however. The system now sees the drive, can find track 0, and can load the kernel, but the kernel reports CRC errors and cannot mount the root filesystem. I went back and tried an unmodified "mfm_util" and an unmodified older emulation file that used to work (about 6 or 7 years ago, anyway) and that behaves identically, it also reports CRC errors and cannot mount the root filesystem. Very strange. It has been a long time since I used this emulator and this system, and a lot has changed with the source code between then and now. I will try to find an older checkout from git that works correctly with a known-good emulation file, and then do a git bisect.

-Seth

[Seth Morabito]

On Tuesday, April 23, 2024 at 8:56:14 AM UTC-7 Seth Morabito wrote:

  I will try to find an older checkout from git that works correctly with a known-good emulation file, and then do a git bisect.

Unfortunately this will be trickier than I thought. Checkouts from git older than about early 2023 do not compile on the current OS I'm running on the BeagleBone, so finding out when things broke will be challenging. Of course, I can't rule out a hardware failure either, until I do some more debugging.

-Seth

[David Gesswein]

I have the older OS as bootable image you can run for uSD card if you
don't want to reflash your board. Best to backup anyway in case I messed
up and it does reflash.
http://www.pdp8online.com/mfm/revb/software.shtml
Old OS bootable image BBB-mfm-emu-v4.20-OS-7.11.img.xz

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/d8eaf868-2fb6-472a-ada8-44388a996b42n%40googlegroups.com.

[David Gesswein]

On Mon, Apr 29, 2024 at 02:17:39PM -0700, Seth Morabito wrote:
> I have only one mystery left to solve: The 3B2 refuses to auto-boot from
> the emulator. It always reports a disk sanity failure when attempting to
> auto-boot. But, when I boot manually via the 3B2 firmware, it reports no
> errors and works perfectly.
>

Is this powering on the machine and emulator is booting at the same time? If
so emulator startup may be too slow. You can verify that by powering the
emulator with another power supply so its already booted when the machine
tries to boot. If not it is strange.

[Seth Morabito]

Strangely no, I have tried this with the MFM emulator already fully powered up and running long before trying to boot the 3B2, using a separate power source. It reports "Disk Sanity Failure" trying to autoboot, but then subsequently booting manually works just fine. I need to figure out what the uPD7261A controller thinks is happening in that case. It is very odd.

-Seth

[Seth Morabito]

This is resolved! It was (yet again) user error on my part, absolutely nothing to do with the MFM Emulator.

The problem was that I was using radial select with the "-d 0" flag. When I switched to using the "-d 1" flag and jumpering J1 for drive select 1, everything started working perfectly. Mea culpa!

So, in short: The changes to mfm_decoder.h to support the "ATT_3B2" controller work perfectly, and I can use raw hard disk images built on the SIMH 3B2 emulator, and turn them into MFM emulator files. Thank you!

-Seth

[David Gesswein]

Not much wants -d 0. Next update the mfm_emu command page will make that
clearer. Did you find -d 0 discussed elsewhere than this page?

http://www.pdp8online.com/mfm/code/emu/mfm_emu_doc.html

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/mfm-discuss/03db5d8a-91dd-4970-89b7-881eae6275d2n%40googlegroups.com.