English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 29 October 2013, 10:57   #1
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
Encoding and writing an MFM track

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:
Code:
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?
phx is offline  
AdSense AdSense  
Old 29 October 2013, 11:06   #2
Codetapper
2 contact me: email only!

Codetapper's Avatar
 
Join Date: May 2001
Location: Auckland / New Zealand
Posts: 3,128
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!
Codetapper is offline  
Old 29 October 2013, 11:15   #3
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,361
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.
Toni Wilen is online now  
Old 29 October 2013, 12:31   #4
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
Quote:
Originally Posted by Codetapper View Post
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.

Quote:
when you could simply incbin the Rob Northen routines?
Only if I had them. Do you have a download link?


Quote:
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 is offline  
Old 29 October 2013, 12:33   #5
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
Quote:
Originally Posted by Toni Wilen View Post
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?
phx is offline  
Old 29 October 2013, 12:48   #6
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,361
Quote:
Originally Posted by phx View Post
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)

Quote:
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.
Toni Wilen is online now  
Old 29 October 2013, 14:11   #7
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
Quote:
Originally Posted by Toni Wilen View Post
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...

Quote:
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.


Quote:
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.


Quote:
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.
phx is offline  
Old 29 October 2013, 15:06   #8
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,361
Quote:
Originally Posted by phx View Post
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..)
Toni Wilen is online now  
Old 29 October 2013, 15:27   #9
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
Quote:
Originally Posted by Toni Wilen View Post
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.
phx is offline  
Old 29 October 2013, 15:48   #10
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,361
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
Toni Wilen is online now  
Old 29 October 2013, 16:40   #11
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 687
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 :-)

Last edited by hooverphonique; 29 October 2013 at 16:48.
hooverphonique is offline  
Old 29 October 2013, 16:43   #12
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,471
Quote:
Originally Posted by phx View Post
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.
StingRay is offline  
Old 29 October 2013, 16:58   #13
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 42
Posts: 19,361
Quote:
Originally Posted by hooverphonique View Post
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.
Toni Wilen is online now  
Old 29 October 2013, 23:03   #14
hooverphonique
ex. demoscener "Bigmama"
 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 687
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."
hooverphonique is offline  
Old 30 October 2013, 07:12   #15
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 5,471
That's the DSKBYTR register but it probably won't help much when it comes to writing data to disk.
StingRay is offline  
Old 30 October 2013, 10:33   #16
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 975
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.
phx is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Custom MFM & Dos tracks BippyM Coders. General 25 25 January 2008 19:41
mfm/custom regs/track loader snyp Coders. General 9 06 June 2006 19:42
MFM.DEVICE problem with escom floppy drive??? CFOU! support.Hardware 7 22 May 2006 00:22
Blitter MFM decoding Photon Coders. General 14 16 March 2006 11:24
Winuae+IPF > MFM > Floppy killergorilla project.SPS (was CAPS) 1 14 July 2004 13:04

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:31.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.23958 seconds with 11 queries