Page 4 of 5

Re: Track reading (Sedoric / FDC)

Posted: Sat Jan 05, 2019 2:02 pm
by christian
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)

Re: Track reading (Sedoric / FDC)

Posted: Sat Jan 05, 2019 3:49 pm
by Symoon
Hey thanks a lot, very valuable information ;)

Re: Track reading (Sedoric / FDC)

Posted: Sat Jan 05, 2019 7:32 pm
by Symoon
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!

Re: Track reading (Sedoric / FDC)

Posted: Sat Jan 05, 2019 8:18 pm
by iss
This is from Jasmin manual, not very informative...
jas-man.png

Re: Track reading (Sedoric / FDC)

Posted: Sun Jan 06, 2019 10:00 am
by Symoon
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.

Re: Track reading (Sedoric / FDC)

Posted: Tue Jan 08, 2019 8:35 pm
by Symoon
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 ;)

Re: Track reading (Sedoric / FDC)

Posted: Wed Jan 09, 2019 9:08 am
by iss
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)

Posted: Mon Jan 13, 2020 4:56 pm
by ThomH
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.

Re: Track reading (Sedoric / FDC)

Posted: Tue Nov 15, 2022 2:39 pm
by Symoon
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 ! )

Re: Track reading (Sedoric / FDC)

Posted: Tue Nov 15, 2022 3:21 pm
by Chema
iss wrote: Wed Jan 09, 2019 9:08 am 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! :)
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)

Posted: Tue Nov 15, 2022 3:53 pm
by Symoon
Chema wrote: Tue Nov 15, 2022 3:21 pm 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.
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)

Posted: Tue Nov 15, 2022 6:19 pm
by Dbug
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)

Posted: Tue Nov 15, 2022 8:00 pm
by iss
Symoon wrote: Tue Nov 15, 2022 2:39 pm... 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 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 :D) 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)

Posted: Tue Nov 15, 2022 8:23 pm
by Chema
Symoon wrote: Tue Nov 15, 2022 3:53 pm
Chema wrote: Tue Nov 15, 2022 3:21 pm 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.
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.
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)

Posted: Wed Nov 16, 2022 8:49 am
by Symoon
Dbug wrote: Tue Nov 15, 2022 6:19 pm 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?
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.
I read (again :D) 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 :).
Thanks! I didn't have high expactations, but still dreaming there would be a workaround to this problem ^^
Regarding test, I'd have to find back the small testing program used earlier in this thread.
I imagine you can get the full geometry (sectors per track, sector size, interleave...) from a read_track command...
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!