DSKBYTR test programs needed
dirkwhoffmann opened this issue · comments
A weak point of the current drive implementation is the support of the DSKBYTR register. The HRM states that the currently read byte can be picked up from the lower 8 bits. However, the description is quite vague. I.e., it's not clear where the bits come from that are visible in DSKBYTR. Is it a byte from the FIFO? Is it the (lower / upper half of the) data register? Do the bits scroll through one by one?
Does anybody know a Amiga program that makes use of the DSKBYTR register? I am looking for test cases that proof my current implementation wrong.
"Deep, The (1988)(U.S. Gold)[cr Defjam - CCS][t +2 Defjam - CCS][b]" seems to be a notorious example, and it appears to work fine in latest vAmiga (*). Found a mention that minimig has/had issues with DSKBYTR and saw that game mentioned as an example (haven't seen what others might be impacted).
I don't think this behavior was widely used, so it might be require to make some test programs to figure it out. For 99.99% of software it won't be useful, but it might be good to capture some data (could also be used to figure out other floppy timing delays) before all drives die.
*: It has to be a cracked version, the original game doesn't rely on DSKBYTR. The interesting code starts at $250, put a breakpoint at $84 to see it from the start (happens after pressing F1).
I don't think this behavior was widely used, so it might be require to make some test programs to figure it out
Test cases such as the following ones would be cool:
- The tests fills a certain track with a bit pattern. First test: 10101010110.... Second test: 110011001100.... etc.
- The track is read back via disk DMA.
- Question 1: Is it possible to recreate the bit pattern by constantly polling bit 0 (or any other bit) in DSKBYTR?
- Question 2: Does the "Disk byte ready" bit become 1 every 8th time?
What this test would (most likely) reveal is whether DSKBYTR mirrors the current contents of the data register from the patent description (which must be a standard shift register). If I had been the hardware designer back in the day, I would have done it this way. I am a little unsure about this hypothesis, because the data register is 16-bit, but we only see 8 bits in DSKBYTR. Hence, we would only see half the contents of the shift register. Maybe they did it this way, because they needed the other bits for something else. Or my hypothesis is plain wrong.
Maybe something like this? disktiming.zip (boot.s is for the bootsector, disktiming.s after being assembled should go in sector 1 onwards with currently 6 sectors required). The code might be a bit of a mess and probably has some issues, but hopefully works as intended. It does the following:
- Read track 0 four times the standard way (with WORDSYNC) and reports the average time it takes.
- Times stepping to the next cylinder, and without waiting doing a short (1 word) read also with WORDSYNC enabled.
- Checks if the disk has been "prepared", if not it creates 2 custom tracks filled w/ $aa and $cc (the test patterns you mention) + 4 $4489 sync words (Note: after this the disk data can no longer be stored in a standard ADF file)
- Reads a standard amiga track (0) and the two custom tracks and records the value of dskbytr after reaching a syncword, and outputs it to the screen.
Note that on my A1200 w/ a gotek drive it only seems to work the first time, not sure why, but the track with $cc's doesn't contain valid mfm data so maybe that has something to do with it? More likely it's because it's the first time I've tried writing raw data to a disk so proceed with caution :)
Very nice test. This is what I get on my A500 with a Gotek installed:
First run:
Second run:
Now, we need to know what a real drive reports. Maybe @mithrendal can give it a try on his old A1000 flagship?
The output from tracks 21 and 22 look like they weren't properly written. It looks quite similar in WinUAE unless I use an extended ADF. I converted the disk to "HFE" format before using it with my gotek drive. Looked like this (sorry for poor quality, interlaced looks terrible on my monitor):
Not too far off what vAmiga shows:
launching original unmodified A1000 with one floppy disk drive (aka old rusty battlestar galactica ...)
@mras0 testprogram inside unmodified A1000 with original floppy drive 0
Runnning 3 rounds
@mithrendal thanks for taking the time to run the tests! (and glad it didn't set your floppy on fire)
Again sorry for using interlaced mode, but it fits more stuff on the screen.
There is definitely some interesting stuff in there that I'm still digesting.
- Sync time is much lower than gotek (and emulators). Maybe it's matching previous track (code is intentionally wrong).
- Invalid MFM data ($cc) is read as $66 (track 22). Probably expected, but not emulated by anyone.
- Data read in DSKBYTR seems almost byte aligned, but not quite, especially during transitions (with maybe wrong MFM encoded data?)
I think the test answers the major question about DSKBYTR. As long as we read from the same track, it contains byte-aligned data. This means that it does not reflect the shift register contents. If it did, we would see the incoming data scrolling through bit by bit (with the data ready bit signaling alignment). Hence, I guess DSKBYTR presents us the latest byte that has been written to the FIFO. This also means that the FIFO is likely not a 3 * 16 bit FIFO as described in the patent, but a 6 * 8 bit FIFO. If this is all true, then vAmiga already does the right thing.
Yes, I think it's safe to conclude that it is indeed showing the last byte read and not the contents of the shift register. I counted when a new byte arrives in the first image, and it's about every 112th clock cycle (so every 16 μs), which matches the expected 2μs/bit.
The current vAmiga implementation should be fine for all practical purposes, but the test reveals two differences: It looks like the data in DSKBYTR is delayed compared to the WORDSYNC comparison.
In a couple of the traces a "garbage" (shifted) value is observed at first despite INTF_DSKSYNC being set e.g. at the start (first image, track 22): $4024,$4024,$4024.., (third image, track 21): $c022,$4022, and later WORDSYNC is set before the byte is visible (first image, track 22 end of $30 row): $5044,$d089. I think the first part is emulated in WinUAE by keeping a bit counter and every 8th bit dskbytr is updated, when word sync matches the counter is reset (so first byte read is "randomly shifted" while subsequent ones are correctly aligned), second part I don't think is handled (so probably not important for any software found in the wild).
To be clear, I don't think it's worth making any changes unless some program happens to depend on this behavior (which I think is very unlikely).