Encoding and writing an MFM track

[phx]

I'm currently thinking about implementing a disk-write routine for my game project, to be able to save highscores.

I will probably reserve a whole track for the highscores, to minimize the risk that any game data is damaged by write operations. My first plan was the following:

1. Read the track into the MFM buffer and save pointers to each of the 11 MFM sectors in a table (this already works in the loader).
2. Update the sectors I want to change in the MFM buffer.
3. Recalculate the number of sectors until the gap in each sector header.
4. Update header checksum and data checksum of all sectors.
5. Make sure there is a gap of 256 $aaaa words at the beginning and at the start of the track. Write the MFM buffer with DSKLEN = $1900 words.

When I thought about that some longer I realized that the track-gap could be a problem. Usually an MFM track has the following layout:

For each of the 11 sectors:
     4 Bytes with two $4489 sync words
    56 Bytes for the header (info field, label, checksums)
  1024 Bytes data
     4 Bytes sector gap ($aaaa, $aaaa)
It follows a gap with $aaaa words of variable length until the end of the track.

When I read a track the DMA starts at the first $4489 sync-word found, which can be any sector. This means that the gap could be somewhere in the middle of my MFM buffer. When I write the track back, with a gap at the beginning and end of the buffer, I will have two gaps and the track might become too large, right?

What is the recommended practice to write such a track? To reconstruct it from scratch? Or by shifting the sector data inside the MFM buffer to eliminate the gap?

[Codetapper]

Do you really want to go to all that trouble when you could simply incbin the Rob Northen routines? They're incredibly simple to call, and you just need to hand the function a chip memory buffer of approximately $3300 bytes plus a pointer to your data and tell it what track you want written.

Granted you would learn a lot from writing your own, but if it's simply to save high scores, I would save your effort for the game rather than low level disk I/O routines!

[Toni Wilen]

Standard method is to decode all sectors (and check checksums of all sectors), modify data, encode all sectors again, write track. Everyone does it this way.

[phx]

Originally Posted by Codetapper

Do you really want to go to all that trouble

Hmmm... yes?
It's really not so much trouble. The trackloader is already working. Making it write tracks is only a small addition.

when you could simply incbin the Rob Northen routines?

Only if I had them. Do you have a download link?

I would save your effort for the game rather than low level disk I/O routines!

The game is 90% finished. Just the last map (of 10), high scores, and maybe an end-sequence are missing.

[phx]

Originally Posted by Toni Wilen

Standard method is to decode all sectors (and check checksums of all sectors), modify data, encode all sectors again, write track. Everyone does it this way.

Yes, sure, that's what I wrote above. But I'm interested in the details, like: how to handle the gap.

And which ADKCON settings do I use for writing? AFAIK I need PRECOMP %00 for cylinders 0 to 39 and PRECOMP %01 for cylinders 40 to 79. Then I also set the FAST bit and... something else?

[Toni Wilen]

Originally Posted by phx

Yes, sure, that's what I wrote above. But I'm interested in the details, like: how to handle the gap.

I thought you meant keeping encoded data and only decoding&encoding sector(s) in place, instead of decoding all sectors, modifying data, then encoding all sectors again, overwriting old MFM buffer completely, which also re-creates the gap correctly.

IMHO this is the only easy way and there is no point in trying to optimize it.

When MFM encoding track, encode it as a single track not as separate sectors: keep last bit of previous sector when starting to encode following sectors. (There are trackwriters that reset MFM encoding state after each sector which works but can result in illegal MFM patterns)

And which ADKCON settings do I use for writing? AFAIK I need PRECOMP %00 for cylinders 0 to 39 and PRECOMP %01 for cylinders 40 to 79. Then I also set the FAST bit and... something else?

I haven't ever seen any software setting any precomp bits in ADKCON..

Remember to disable WORDSYNC when writing. It has undocumented side-effect: Start write with WORDSYNC enabled: Paula starts _reading_ from floppy without storing the data (just like it does when wordsynced read starts), write starts when wordsync register matches with data from disk: If track does not have any old wordsync markers: writing never starts, disk block interrupt never gets set.

[phx]

Originally Posted by Toni Wilen

IMHO this is the only easy way and there is no point in trying to optimize it.

That would mean to decode the whole track and copy the contents to a buffer, before constructing the track from scratch, even when I only change a single sector in it.

Maybe it is better in this case to shift MFM data around in the buffer? I will find out...

When MFM encoding track, encode it as a single track not as separate sectors: keep last bit of previous sector when starting to encode following sectors.

Yes, that's important. I had already written small functions to fix the border bits of the previous and the following MFM word, when inserting data.

I haven't ever seen any software setting any precomp bits in ADKCON..

Now I looked into trackdisk.device and the Rob Northen routines (which Codetapper kindly provided). Both set the PRECOMP bits in the way I wrote above. PRECOMP %10 and %11 are never used, though.

Also important to know is that I have to set MFMPREC (bit 12) and FAST (bit 8) when writing.

Remember to disable WORDSYNC when writing. It has undocumented side-effect

Thanks! Really useful information.
The HRM made me think that WORDSYNC has no meaning in Write mode.

[Toni Wilen]

Originally Posted by phx

That would mean to decode the whole track and copy the contents to a buffer, before constructing the track from scratch, even when I only change a single sector in it.

Maybe it is better in this case to shift MFM data around in the buffer? I will find out...

I don't see any point in attempting to optimize this case, or attempting to optimize single track writes. This isn't speed critical disk copier or formatter.

IMHO disk support should be as generic as possible, without special cases that are difficult to test. (depends on disk position etc..)

[phx]

Originally Posted by Toni Wilen

I don't see any point in attempting to optimize this case, or attempting to optimize single track writes. This isn't speed critical disk copier or formatter.

You're right, but it's not performance which concerns me, but the need to store the data of a whole track in a buffer which I don't have.

[Toni Wilen]

You could do following trick: start short read DMA (just enough to read sector header), check sector number, if not last, repeat read. If last, start normal read, sectors will be in expected order

[hooverphonique]

is there really sync words in front of each sector (does trackdisk.device also do this) ? I am pretty sure, I always used the sync to identify the start of the track, not a sector, and then always read/wrote complete tracks..

I must go home and check my old code :-)

[StingRay]

Originally Posted by phx

You're right, but it's not performance which concerns me, but the need to store the data of a whole track in a buffer which I don't have.

Turn off bitplane DMA and use screen memory.

[Toni Wilen]

Originally Posted by hooverphonique

is there really sync words in front of each sector (does trackdisk.device also do this) ? I am pretty sure, I always used the sync to identify the start of the track, not a sector, and then always read/wrote complete tracks..

I must go home and check my old code :-)

Yes. Any sector can be "first sector" when using wordsync to start read DMA. "Start of the track" does not really exist in Amiga formatted disks

This is the usual way to read tracks, start long enough wordsynced DMA, first read sector is some random sector, use sector number in header to position decoded data correctly.

[hooverphonique]

yes.. looking at my old code (actually an old non-system loader which fits in the bootblock and loads an OFS amigados file :-), I also first read the whole track, then use the sync word to look for the next sector and decode a single byte to determine if it's the sector I'm looking for..

@phx are you sure you can't dig up the ~12KB chipmem you need for a trackbuffer? :-)

the hardware ref manual has this to say about it:
"If you have too little memory for track buffering (or for some other
reason decide not to read a whole track at once), the disk hardware
supports a limited set of sector-searching facilities. There is a register
that may be polled to examine the disk input stream."

[StingRay]

That's the DSKBYTR register but it probably won't help much when it comes to writing data to disk.

[phx]

Ok, I followed the suggestion to recreate the MFM track from scratch.

The 12K Chip RAM for the MFM buffer are not a problem. I already allocated that for the loader. But now I allocated another 5.5K to buffer the 11 sectors for the track to be written. Fortunately that doesn't have to be Chip RAM.

Maybe 5.5K doesn't sound that much. But it is just for saving a few bytes of high scores, and I have no other use for it.