PSOS Disk image decoding issues

[peterzieba]

Hi,

I have made a flux image from a 3.5" DD floppy which manages to boot on this 68000 based system which uses a WD1772 controller, however, the image file that is produced is simply filled with 0x4E.

This is probably some type of layout issue, but I'm not sure what. The only part I feel that is likely the same is the 1k sector size. The other possibility is that the system itself is compatible with multiple formats and this is something wildly different.

In the past I think I remember being able to play with a .textpb file to change things, however, do I need to recompile now if I want to test out different layout options?

Attached is an example of this unusual floppy.

v2.02-blue.zip

[davidgiven]

The disk looks exactly like what I'd expect for an empty disk with every sector containing 0x4e bytes. The sector layout looks right with no missing gaps where more data might be. Even the sector headers contain the right track information, which rules out a stuck head causing the same track to be read over and over again.

Can you verify that the machine really is booting from it, and it's not just booting from ROM after looking briefly at the disk and seeing that there's no data there?

[peterzieba]

There's a ton of back and forth disk activity and there are all sorts of things printed to the screen that do not appear anywhere in the ROM. I'm certain this is from the floppy.

The only variable here is that the floppy drive in the system is not the same as the drive I am using to read the disk with Fluxengine. The drive in the system is "taller" (more ancient) than the one I am using with fluxengine, however, considering it seems to read fine I'm having a hard time believing that it could somehow be the drive itself. I'm also using the fluxengine drive with other DD floppies just fine.

I remember there being issues with how the system's drive is jumpered such that I'm hesitant to try getting fluxengine to work with it, however, if that flux file really seems to be empty then I suppose this might be worth trying.

[peterzieba]

So, I am looking at some spares of what I believe to be the same drive as is in the system (they're all oddly tall).

One of them has a sticker on it that says "600 rpm Drive".

The other has a sticker that says 80 tracks per side, 135 TPI. One of these is a TEAC FD-35F-03-U and the other is a TEAC-FD-35FN-18-U.

All of these are likely 600rpm. Could that be causing all of the confusion?

Peter

[peterzieba]

Ok, I have this figured out, but I'm very confused as to how/why something can be fail in this way and still have everything appear to be working.

The short of it is that a Sony MPF520-1 drive will consistently produce an image file filled with 0x4E. Because you mention that the sector headers look correct, I'm absolutely confused as to how it would be possible for a drive to be able to successfully return the data in the sector headers to fluxengine but not the data associated with them.

A regular Teac FD-235F will create an image file that has real data in it, as will one of the more ancient TEAC FD-35F drives with the 600rpm sticker on it. I had to place a jumper onto "MS" for this ancient drive and move D2 to D0 for fluxengine to recognize it.

I'm sort of under the impression that the drive should not have any knowledge about sector sizes and things like that, and so none of the strangeness of this format should have any significance for the drive itself.

Is there something about the technical implementation of this format that would prevent certain drives from working?

[peterzieba]

It looks like the issue is that 3.5" DD drives read these floppies properly, whereas a modern HD floppy drive will read what appears to be every other 5120bytes, which happen to be filled with 0x4E. Not sure if that's exactly what is happening, but I think I'm close.

I was under the impression that modern floppy drives could read DD disks and this would work automatically. Is there something I'm doing wrong?

[peterzieba]

Ok, trying all this with a TEAC FD-235HF drive, the floppy reads correctly and matches exactly the output of the original drive.

The problem seems to be consistently reproducible with the Sony MPF520-1. This drive returns 0x4E for the whole resulting image.

So I'm leaning toward it's just this particular sony drive that is very much broken but I'm still confused as to how something like this could even be possible.

[davidgiven]

That's utterly baffling. The only thing I can think of is that the drive is lying and faking a blank disk? But why?

It's a reach, but could you have two drives plugged into the same bus and with the MPF520 you're picking up a blank disk in the other drive?

600rpm, BTW, means it's an x2 drive. These are pretty rare. I have one, and it's a USB drive which means I can't use FluxEngine on it. But AFAIK the TEAC FD-35Fs didn't do that, so that's weird that they're labelled as such.

[peterzieba]

No, just a single drive.

I have some idea of what it might be: Every 5120 bytes are 0x4E on the good image.

The 0x4E really is there on the good disk, just not the entire bit of it, it's just being read in places it shouldn't be...

Is it possible the side-select pin is stuck either high or low? But if that were the case, shouldn't the sector header returned be wrong and therefore caught as the wrong side being returned? Does fluxengine check for this?

Incidentally, I believe the floppies are all formatted with 0x4E as a fill because 0x4E4E is 68000 assembly for TRAP 14, which would prevent code execution from going wildly off into nowhere in case something is executed that shouldn't be.

[davidgiven]

Ooh, yes --- turns out the PSOS decoder actually ignores the side byte in the header and rewrites it based on the physical head (because it's handled oddly on PSOS). So that would perfectly explain what's going on.

[peterzieba]

Is it possible to confirm that's what happened from the previous flux image?

I was trying to do this myself but wasn't able to come to a solid conclusion -- it seemed right but then I don't know how it all works under the hood. I just can't think of anything else it could be.

[davidgiven]

If you do this:

fluxengine read -c psos -s v2.02-blue.flux --decoder.dump_records=true

...then as it does the read it will also dump the undecoded raw record data. You can then see the data for each sector record before decoding. Unfortunately it is before decoding, so you'll have to manually undo the MFM to see the individual bytes, but as each byte turns into two raw bytes you can see that the head byte is always encoded as a9 2a.