Track reading (Sedoric / FDC)
Re: Track reading (Sedoric / FDC)
Unlike Sedoric, there is no information stored on the disk because FTDOS does not permit to adjust the disk geometry.
So the format is always: 2 sides x 41 tracks x 17 sectors x 256 bytes. (with Jasmin 2)
So the format is always: 2 sides x 41 tracks x 17 sectors x 256 bytes. (with Jasmin 2)
Re: Track reading (Sedoric / FDC)
Hey thanks a lot, very valuable information
Re: Track reading (Sedoric / FDC)
Interestingly, Omniflop lists 4 different formats for Jasmin:
40x17 340kB
41x17 348.5kB
42x17 357kB
They have been provided by Chloé so I suspect I should ask for details on the other forum!
40x17 340kB
41x17 348.5kB
42x17 357kB
They have been provided by Chloé so I suspect I should ask for details on the other forum!
Re: Track reading (Sedoric / FDC)
This is from Jasmin manual, not very informative...
Re: Track reading (Sedoric / FDC)
Thanks. I suspect the differences are with the user available tracks (would the system be present on the disk or not).
Or maybe small differences betwenn the (apparently) many different FTDOS versions.
Or maybe small differences betwenn the (apparently) many different FTDOS versions.
Re: Track reading (Sedoric / FDC)
One mystery solved: the Nibble manual explains how it deals with track mode.
It actually reads the whole track first, keeping in memory each of the sectors ID positions. Then it reads each sector, and puts them in place of the ones that were read in track mode... "Because of the bad quality of track reading".
That's how there are much less $C2 in Nibble "track+sector" reading
It actually reads the whole track first, keeping in memory each of the sectors ID positions. Then it reads each sector, and puts them in place of the ones that were read in track mode... "Because of the bad quality of track reading".
That's how there are much less $C2 in Nibble "track+sector" reading
Re: Track reading (Sedoric / FDC)
This makes sense - first to use whole track reading just to get the "description" of the track (i.e. number of sectors and their size) and then to read every sector individually. Very interesting!
Re: Track reading (Sedoric / FDC)
I've just discovered possibly the most egregious of false sync situations:
On track 41, the ID mark for any normally-written floppy will be [sync] A1 * 3, FB 29. The final nine bits of that sequence are 000101001, which MFM encodes to: 01 01 00 10 00 10 01 00 1x, i.e. the C2 sync followed by 00 1x.
So a read track is essentially guaranteed always to lose synchronisation when reading addresses on track 41.
On track 41, the ID mark for any normally-written floppy will be [sync] A1 * 3, FB 29. The final nine bits of that sequence are 000101001, which MFM encodes to: 01 01 00 10 00 10 01 00 1x, i.e. the C2 sync followed by 00 1x.
So a read track is essentially guaranteed always to lose synchronisation when reading addresses on track 41.
Re: Track reading (Sedoric / FDC)
Hi,
Today I learnt that apparently, the Fujitsu MB8877A FDC could be used in place of the WD 1793.
If so, do you think there might be a chance that it wouldn't suffer from the same sync "problems", or is there no reason it would?
(the datasheet might answer this but didn't have time to look yet, just asking in case FDC wizards would have a straight answer ! )
Today I learnt that apparently, the Fujitsu MB8877A FDC could be used in place of the WD 1793.
If so, do you think there might be a chance that it wouldn't suffer from the same sync "problems", or is there no reason it would?
(the datasheet might answer this but didn't have time to look yet, just asking in case FDC wizards would have a straight answer ! )
Re: Track reading (Sedoric / FDC)
Indeed... that would help in writing a disc clone Oric utility. I always wondered if read_track/write_track only would do, and feared it would not.
Re: Track reading (Sedoric / FDC)
Well, at least with existing FDCs, it doesn't. I had updated the very first post of this thread, so we can have a sum-up of the situation.
Re: Track reading (Sedoric / FDC)
On the real Oric, if you read the same track multiple times, do you get the exact same result, or does some of the data change?
Re: Track reading (Sedoric / FDC)
The MB8877A is drop-in replacement for WD1793 the only difference is that MB8877A doesn't require +12V (pin 40 is simply not bonded internally). I read (again ) both datasheets and there is no reason to make any conclusion that MB8877A is some how better/different than WD1793 in regard of sync problems.
I have both and can do any tests with real hardware which may be helpful just define what need to be done .
Re: Track reading (Sedoric / FDC)
Yes, I understood. I meant that I as almost sure it would not work. But reading the track to get the geometry, then using that information would. I imagine you can get the full geometry (sectors per track, sector size, interleave...) from a read_track command...
Re: Track reading (Sedoric / FDC)
According to what I tested long ago (see here), it seems it changes. Sometimes inserting $C2, sometimes crushing data, therefore probably making multiple reads/comparing/fixing a nightmare.
Thanks! I didn't have high expactations, but still dreaming there would be a workaround to this problem ^^I read (again ) both datasheets and there is no reason to make any conclusion that MB8877A is some how better/different than WD1793 in regard of sync problems.
I have both and can do any tests with real hardware which may be helpful just define what need to be done .
Regarding test, I'd have to find back the small testing program used earlier in this thread.
We sure could read each sector of a track after a read_track and see how many there are. Regarding the amount of tracks, I may be wrong but I don't think it is recorded somewhere? (outside Operating Systems doing it of course). Maybe this could be guessed by counting the amount of filling data somewhere, since it depends on the geomerty? That could be worth trying to figure out, not forgetting afterwards that working with the famous $C2 that can crush useful data won't be easy!I imagine you can get the full geometry (sectors per track, sector size, interleave...) from a read_track command...