Geehaf asked some questions about how to read Amiga disks in the MEGA65, so I started looking into what's involved.
Note that this is for reading Amiga disks from the MEGA65 core, and has no impact on any future Amiga core that would allow you to run Amiga software on the MEGA65. That is quite a separate activity, that we look forward to seeing, but isn't what I'm working on today.
First, we have to understand that the MEGA65 floppy interface hardware can read and write any format at all -- because the FDC "chip" is implemented inside the FPGA, which has direct connections to all the FDC cable signals. This also means that when an Amiga core comes out for the MEGA65, it will be able to read and write Amiga disks natively in the internal drive just fine. In fact, with only minor work, it will be able to read and write Amiga HD disks at 2x the speed that the Amiga could, because instead of slowing the drive down, we can just artificially slow down the magnetic flux signals.
So, that all means that we just need to improve the FDC in the MEGA65 core if we want the MEGA65 to be able to read Amiga disks. (We'll get to writing a bit later).
Specifically, we need to understand how the Amiga writes tracks of data out to the disk. I found this nice (and hopefully correct) description here:
The following are details about how the bits on the Commodore-Amiga
disk are actually written.
Gross Data Organization:
3 1/2 inch (90mm) disk
double-sided
80 cylinders/160 tracks
Per-track Organization:
Nulls written as a gap, then 11 or 22 sectors of data.
No gaps written between sectors.
Per-sector Organization:
All data is MFM encoded. This is the pre-encoded contents
of each sector:
two bytes of 00 data (MFM = $AAAA each)
two bytes of A1* ("standard sync byte" -- MFM
encoded A1 without a clock pulse)
(MFM = $4489 each)
one byte of format byte (Amiga 1.0 format = $FF)
one byte of track number
one byte of sector number
one byte of sectors until end of write (NOTE 1)
[above 4 bytes treated as one longword
for purposes of MFM encoding]
16 bytes of OS recovery info (NOTE 2)
[treated as a block of 16 bytes for encoding]
four bytes of header checksum
[treated as a longword for encoding]
four bytes of data-area checksum
[treated as a longword for encoding]
512 bytes of data
[treated as a block of 512 bytes for encoding]
NOTE:
-----
The track number and sector number are constant for each particular
sector. However, the sector offset byte changes each time we rewrite
the track.
The Amiga does a full track read starting at a random position on the
track and going for slightly more than a full track read to assure
that all data gets into the buffer. The data buffer is examined to
determine where the first sector of data begins as compared to the
start of the buffer. The track data is block moved to the beginning
of the buffer so as to align some sector with the first location in
the buffer.
Because we start reading at a random spot, the read data may be
divided into three chunks: a series of sectors, the track gap, and
another series of sectors. The sector offset value tells the disk
software how many more sectors remain before the gap. From this the
software can figure out the buffer memory location of the last byte
of legal data in the buffer. It can then search past the gap for the
next sync byte and, having found it, can block move the rest of the
disk data so that all 11 sectors of data are contiguous.
So, this tells us that Amiga disks use only 2 sync bytes, instead of the usual 3 that PC and 1581 disks use. Then we expect to see a $FF byte, followed by track and sector numbers, and if we're a bit lazy, 25 bytes of stuff we don't have to deal with.
One of them is used to indicate where on the track the sector has been written, 16 are a magic stash for the Amiga DOS to put stuff, which we really can ignore, so far as I know, and 8 more are CRCs for the header and data block which we will ignore for now, partly because I don't know the CRC that the Amiga used (maybe standard CRC32), and partly because for testing, we just don't need to check it, and finally, because reading Amiga disks in the MEGA65 in this easy way is not a high-stakes exercise: The occassional missed CRC error won't cause us great grief. If you want the certainty, then do the track-at-once flux reading using DMAgic, and check the CRCs in that.
That all said, this doesn't mean that we can't implement the CRC check, just that I'm not bothering to implement them right now.
It would be great to find an Amiga disk in my pile, and see if I can read it, else that will be upto Geehaf to try. Also, it would be great to get the raw flux of a track of an Amiga disk, so that I can make a VHDL test case, especially if my modifications don't work first time.
So, speaking of those modifications, it's actually a really small and simple change, assuming I have understood everything correctly. It's all in mfm_decoder.vhdl:
First up we check for the Amiga 2x SYNC + $FF prefix:
elsif byte_valid_in='1' then
sync_count <= 0;
if sync_count = 2 then
if byte_in = x"FF" then
-- Amiga sector marker.
-- See info block at top of file for how we have to handle these
state <= AmigaTrackNum;
end if;
end if;
if sync_count = 3 then
-- First byte after a sync
report "TRACKINFO: Post Sync byte = $" & to_hstring(byte_in);
if byte_in = x"FE" then
-- Sector header marker
Then we just have to add some state machine states for the reading:
when AmigaTrackNum =>
seen_track <= byte_in;
seen_side <= x"00"; -- Amiga disks don't encode the side
sector_size <= 512; -- Amiga disks have fixed sector size
state <= AmigaSectorNum;
when AmigaSectorNum =>
seen_sector <= byte_in;
amiga_skip_bytes <= 25;
state <= AmigaSkipBytes;
when AmigaSkipBytes =>
if amiga_skip_bytes /= 0 then
amiga_skip_bytes <= amiga_skip_bytes - 1;
else
if (target_any='1')
or (
(to_integer(target_track) = to_integer(seen_track))
and (to_integer(target_sector) = to_integer(seen_sector))) then
found_track <= seen_track;
found_sector <= seen_sector;
found_side <= seen_side;
sector_found <= '1';
seen_valid <= '1';
byte_count <= 0;
state <= AmigaSectorData;
else
seen_valid <= '0';
state <= WaitingForSync;
end if;
end if;
when AmigaSectorData =>
if (byte_count = 0) and (seen_valid='1') then
first_byte <= '1';
else
first_byte <= '0';
end if;
byte_out <= byte_in;
byte_valid <= seen_valid and byte_valid_in;
if byte_count < sector_size then
byte_count <= byte_count + 1;
else
-- We ignore CRC for Amiga disks for now.
crc_error <= '0';
-- Report end of sector
sector_end <= '1';
sector_found <= '0';
end if;
And that's all there is to it. Everything else is done by the existing machinery that handles the decoding of PC/1581 MFM sectors and MEGA65 RLL sectors. If nothing else, it makes me feel warm and fuzzy about the disk reading architecture that I implemented, that adding another disk format is that simple.
Now to wait for a bitstream to build, and see if I have got lucky, and it just works first time :)
Okay, bitstream is built, and I found an Amiga disk (actually an original set of Workbench 3.0 disks), and tried reading it, but unfortunately no sectors are being seen. Now to find out why.
I used the src/tests/floppytest.prg built from mega65-tools repo to read the raw flux of track 0. So now I have a 64KB file of flux inversion intervals, that I can try to decode off-line. src/tools/mfm-decode.c is the utility I wrote for the 1581 disk format originally, and it shouldn't be too hard to modify to handle the Amiga format. That way I can know if my disk is good, and if so, use it as the basis for an automated test of the Amiga disk support in mfm_decoder.vhdl.
I've started by adding support for data field type $FF to mean Amiga sectors, and I am seeing it report 542 bytes between pairs of sync bytes. 28 header bytes plus 512 data bytes = 540 bytes. Add in the two bytes of $00 written before the sync bytes (and thus also seem to appear at the end of a sector), and we get the total of 542 bytes. So that looks good. However, the track and sector numbers seem to not be valid. I'm seeing the following for the first four bytes of the header for the various sectors that appear in my track dump:
$f0 $03 $f1 $01
$f0 $03 $f1 $10
$f0 $12 $f1 $01
$f0 $12 $f1 $10
$f0 $01 $f1 $23
$f0 $01 $f1 $32
$f0 $10 $f1 $23
$f0 $10 $f1 $32
$f0 $21 $f1 $01
$f0 $21 $f1 $10
$f0 $30 $f1 $01
$f0 $03 $f1 $01
$f0 $03 $f1 $10
...
As there are only 11 sectors on the track, from those last 2 we are looping back around to the start of the track.
Okay, those do not look like what I expected, with one byte of track number, and another byte of sector number. Let's convert them to binary, and see if we get any more clues that way.
11110000 00000011 11110001 00000001
11110000 00000011 11110001 00010000
11110000 00010010 11110001 00000001
11110000 00010010 11110001 00010000
11110000 00000001 11110001 00100011
11110000 00000001 11110001 00110010
11110000 00010000 11110001 00100011
11110000 00010000 11110001 00110010
11110000 00100001 11110001 00000001
11110000 00100001 11110001 00010000
11110000 00110000 11110001 00000001
Now, allowing for the fact that the we don't know the order the sectors were written to the track, we don't know which of those is sector 0 (or does the Amiga count them from sector 1?). It would be really handy to have some more detailed information about low-level Amiga disk layout stuff than that page I already found.
Okay, now I have a clue: The odd bits are encoded, then the even bits, for groups of 32 bits. Reading around the place, like, here, for example, I am reminded that the Amiga did some funky tricks for the disk encoding/decoding stuff. This is because the Amiga's FDC controller is quite "dumb", and uses the CPU to find the sectors in the raw flux data etc. As MFM requires to bits per data bit encoded, they used a clever hack of encoding all the odd bits, then the even bits, so that they could mask out the bits not being encoded, and instead insert the necessary MFM clock bits where required, without having to shuffle everything around the place.
Anyway, this means we need to re-interleave the bits together, before examining them for track and sector info. Also, the _entire_ 512 byte data block is also similarly encoded. So we will need a buffer of some sort to demunge them, or modify the sdcardio.vhdl to have a function to "demangle Amiga sector", or just pass the raw sector to the user to process however they wish.
But let's start with the 4 bytes of track/sector info, and de-interleave those bits back together. As I only need to do this once, I'll just make an emacs macro that does it, and paste the result below:
11111111000000010000000000001011
11111111000000010000000100001010
11111111000000010000001000001001
11111111000000010000001100001000
11111111000000010000010000000111
11111111000000010000010100000110
11111111000000010000011000000101
11111111000000010000011100000100
11111111000000010000100000000011
11111111000000010000100100000010
11111111000000010000101000000001
Okay, now that looks way more sensible. Convert those back to hex, and we get:
$FF $01 $00 $0B
$FF $01 $01 $0A
$FF $01 $02 $09
$FF $01 $03 $08
$FF $01 $04 $07
$FF $01 $05 $06
$FF $01 $06 $05
$FF $01 $07 $04
$FF $01 $08 $03
$FF $01 $09 $02
$FF $01 $0A $01
So, it looks like after the MFM sync bytes, it indeed has the $FF to indicate Amiga, but then has the $FF also encoded in that first long-word of data. No drama. We can easily accommodate that. Also the bit munging I can handle fairly readily in VHDL as well. Of course, anyone who has worked deeply on the Amiga would have known all that, but I never did, so it was an interesting journey of discovery for me.
Now, all this discovery says to me that if I enable the FDC in the MEGA65 to identify any sector, not just the targeted sector, then it should still see the Amiga sectors, just that it will think that they are all track $F0 and sector $01.
Next step is to implement the bit munging in VHDL, and then use the track dump I made as a test vector to let me more quickly make sure I have it right, and fix any silly bit order bugs.
Okay, making the simulation test was, as usual, a good idea. I found several annoying little bugs quite quickly, and have it synthesising again now... and now the disk read test sees the Amiga sectors. No idea if it reads the data in them or not yet. That will have to wait for Geehaf's investigation.
Note that it might be some time before this feature will end up in a MEGA65 release core, as there is still some way to go. But it's a nice start.
No comments:
Post a Comment