dlfrsilver wrote:
you got a point about track write on amiga. But there are games using trackloading on ST (i should say sector loading), and even better, there's no MFM used, the track contents on ST are readable. what's the point of the sectors headers ? In ST format, you have a header saying 10 or 9 sectors per track, otherwise how a game could find back his babies ?
I think you're confusing tracks and MFM and sectors. The ST tracks *are* MFM, there's no other way, the WD1772 read MFM data.
Yes, it's possible to build a track with only data and no sector (Lankhor games for example), but this has some drawback because you need to avoid using some specific bytes that would confuse the WD1772 when reading the track (and you would get wrong data), so you loose some space in each track to 'escape' those bytes with a different code when you need to store them. In the end, I think most game developpers considered it was not worth the effort to gain a few hundred bytes per track when you could get much more by compressing data (and many games didn't need more than 800 kB, so regular 10 sectors per track is enough)
The point of sector header is that when you tell the WD1772 to read a sector, then it doesn't get confused about some bytes like the read track command would be; this is a known "bug" in the WD1772 that read track can't read back all bytes as they were written at first.
If the ST format miss some NEEDED informations, then it's not suitable for emulation. Because we won't start writing and modifying the STX files.
This has to be done is another disk container format.
It could be a simple file with a linked list of sectors, each sector having a track, side, size information, then the sector data, then a pointer to the next sector.
If you need to write a sector that already exists, you overwrite it ; if it's a new sector to save, you add an entry at the end of the linked list.
But there could be many other way to store this ; the format should also be able to store the result of a "write track" command.
Nicolas