Track reading (Sedoric / FDC)

Anything related to the tools Tap2Wav, Tap2CD, Tap2Dsk, Sedoric Disc Manager, Tape Header Creator, WriteDsk, and generaly speaking tools related to the management of Oric data files and devices.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Track reading (Sedoric / FDC)

Post by Dbug »

Is it not possible to compute some reliable offsets range from reading multiple tracks and trying to figure out how many bytes spaced different sectors on properly readable tracks, and use that as heuristics for the "complicated" tracks?
User avatar
Symoon
Archivist
Posts: 2301
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: Track reading (Sedoric / FDC)

Post by Symoon »

Dbug wrote: Wed Nov 16, 2022 10:23 am Is it not possible to compute some reliable offsets range from reading multiple tracks and trying to figure out how many bytes spaced different sectors on properly readable tracks, and use that as heuristics for the "complicated" tracks?
If this is about data fiability: this is beyond my "quick reply" capabilities ;)
All I remember are the 144 $C2 values read on a track. IIRC a track is approx. 6kb big. I just honestly don't know how to deal with that (especially if we consider an Oric tool on 48kb). We'd need at least three different readings in memory to decide when a value is correct or not. Based on my experience on errors on tape, four or five would probably be better (5 track readings = 30kb), and we'd have to deal with possible data shifting... Ouch I'll stop there, I'm sounding depressing.
But being rather ignorant on the subject, I'd be more than happy to be proven wrong ;)

But if you meant that to find out the geomerty of a disk, that might be doable easier, providing there is a distinct combination of different "fill types" allowing to figure out the amount of tracks (depending I guess on amount of sectors, and type of disk 3" or 3.5"). We'd need to set a sort of big table with all possible combinations, and check for a unique test to detect each of them.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Track reading (Sedoric / FDC)

Post by Dbug »

I had to re-read the entire thread to remember what it was all about.

First, I think I need to re-address the fact that you don't need to know if a floppy contains some Sedoric, Jasmin, floppy builder or even Atari or MS-DOS formatted data to be able to copy it, as long as you replicate the number/length of tracks and sectors you should be good to go.

Now, being able to detect the type of floppy can be useful so you can use the proper defaults, like if it's an Atari ST or MS-DOS floppy, that will most probably be 512 bytes sectors, 80ish tracks and 9 or 10 sectors, while if it's a Sedoric floppy, it's mostly going to be 256 bytes sectors, and the number of tracks will mostly depend if it's a 3" or 3.5" floppy, all informations you can get from the actual DOS information on the disk.

So personally, I would have two things:
- A low level thing that can read/format/write a specific track using dos agnostic parameters ("Read 10 512 bytes long sectors on the side 2 of track 27")
- A higher level "module" which uses the low level one to try to detect the type of floppy by attempting to read known parameters to see if the floppy looks like some known format, and then use that to target the low level module.

Regarding the implementation of the low level, it looks like whatever Nibble is doing seems to be working nicely, so maybe just copy what Nibble did?
Post Reply