1050 tracks needed

[mikey]

Hey,

 

Can anybody with a speedy or happy modded drive (those that can read raw tracks) post a full track (any) of the formatted SD/ED/DD disk?

I mean the bitstream of all the bytes on the track. I want to test some track buffering feature of the 1050e that I'm working on.

Thanks, I'd appreciate any answer

 

ps. I know the IBM track format from the WD datasheets, and also the format used on stock 1050 (from the code analysis, it's a modified IBM format)

but I'd like to see the real stuff. Anybody?

 

Thanks

M.

[ijor]

Hi Mikey,

 

I'm afraid your question/request doesn't make much sense. You might want to elaborate what exactly you want to see, and for what purposes.

 

It is this concept: "bitstream of all the bytes on the track", the one that doesn't have, at best, a precise meaning. Note that modded drives do NOT read "raw tracks" (if I understand correctly what you mean by this, because again, it doesn't have a precise meaning). For the purpose of track buffering, those drives just read all the sectors in the track.

[mikey]

I wanted to see the track as formatted by the modded (happy/speedy) drive.

But if they cannot do it (read the raw track - thought they did) then indeed, that's pointless

What about Archiver/SuperArchiver? They cannot read raw tracks either?

 

I really thought the best way to do a track buffer is to read the whole track in one disk revolution (FDC read track command) and the

read track command is implemented in such a way that you can read every single byte on the medium (perhaps without the index gap ($fc), i didn't check). So why the idea doesn't make sense I really don't know.

 

It does not make sense if the happy/speedy cannot do it sure, but I didn't know.

 

Regards

[ijor]

I really thought the best way to do a track buffer is to read the whole track in one disk revolution (FDC read track command)...

 

You can NOT use the read track command for this purpose. The whole explanation is a bit long. You might get an idea about why this doesn't work, reading the relevant paragraphs in the WD datasheets, and we might follow up on PM if you want.

 

I wanted to see the track as formatted by the modded (happy/speedy) drive. But if they cannot do it (read the raw track - thought they did) then indeed, that's pointless

 

They can do it, but they normally (with the provided firmware and software) don't do it. The reason is, as explained above.

 

What about Archiver/SuperArchiver? They cannot read raw tracks either?

 

Neither the Archiver, neither the SA, have a track buffer at all. Conceivable, they could use it, but without enough RAM, it wouldn't be so useful. And regardless, they are still limited by the FDC as mentioned above.

 

Conceivable the Bit Writer does. It is a hardware add-on to the SA, but I don't have much info about it.

 

I wanted to see the track as formatted by the modded (happy/speedy) drive.

 

If you still want that information, I can probably provide it. But again, it depends on exactly what you want to see. Or yet better, if you would explain why you want to see, then I will probably realize what you provide. Ok, curiosity might be a good enough reason But if so, then please elaborate about what exactly you want to see, because, e.g., what you write to the FDC is not exactly the same that the FDC writes to the disk, etc.

[mikey]

You can NOT use the read track command for this purpose. The whole explanation is a bit long. You might get an idea about why this doesn't work, reading the relevant paragraphs in the WD datasheets, and we might follow up on PM if you want.

 

If you mean the 'desynchronisation in data area' and 'this command will not function as track copy' statements in the WD docs, I know them.

The docs say also that 'id am, id field, id crc, dam, data and data crc bytes will be correct' and that only the gap info may be incorrect - which is irrelevant to the buffer.

 

If you still want that information, I can probably provide it. But again, it depends on exactly what you want to see. Or yet better, if you would explain why you want to see, then I will probably realize what you provide. Ok, curiosity might be a good enough reason But if so, then please elaborate about what exactly you want to see, because, e.g., what you write to the FDC is not exactly the same that the FDC writes to the disk, etc.

 

I know that what gets written is not always whats provided on the data register (e.g. F5 to FF commands ).

Yes curiosity about what exactly gets written to the disk is one, the other reason is I just want to code the fastest track buffer on the planet

That information should suffice and if you can provide those tracks I will be more than happy Thanks.

 

M.

[HiassofT]

IIRC the disk format of Happy/Speedy etc. only differs in the sector skew, but this can easily be handled in your drive firmware:

 

Upon disk insertion (check the drive door for disk changes) use the "Read Address" command to scan the sector headers of a whole track. Then check the number of sectors, it must be either 18 or 26, depending on density, if you got another number disable the sector buffer (could be the case when inserting a copy-protected disk). Now re-arrange the list so it starts with sector 1 and you have the sector skew needed for reading/writing a whole track without delays.

 

BTW: it's also a good idea to add a permanent buffer for sector 1 (SpartaDos accesses it really often) and the VTOC/directory sectors. This eliminates a lot of (useless) track-seeks when accessing a DOS disk.

 

so long,

 

Hias

[ijor]

The docs say also that 'id am, id field, id crc, dam, data and data crc bytes will be correct' and that only the gap info may be incorrect - which is irrelevant to the buffer.

 

The docs are wrong here.

 

I know that what gets written is not always whats provided on the data register (e.g. F5 to FF commands ).

Yes curiosity about what exactly gets written to the disk is one, the other reason is I just want to code the fastest track buffer on the planet

That information should suffice and if you can provide those tracks I will be more than happy Thanks.

 

I will post some tracks, hopefully tomorrow. But note the following. I'm not sure you would be able to make track buffering any faster than Speedy or Happy. The order/interleave of sectors is not fixed, the correct way to handle that is how Hias described.

[+bob1200xl]

Have you actually tried to verify that you cannot do a "Read Track" and rip up all the data sectors from a disk?

 

You might do better to build the sector sequence as you describe and then "Read Address" at the beginning of each track to see where you are in the sequence. The seek will take some time and you may miss the 'first sector' in your list. (why use 1 as the first sector? use the physical first sector on the track, whatever that may be, and use the track padding for seek)

 

Bob

 

 

 

 

The docs say also that 'id am, id field, id crc, dam, data and data crc bytes will be correct' and that only the gap info may be incorrect - which is irrelevant to the buffer.

 

The docs are wrong here.

 

I know that what gets written is not always whats provided on the data register (e.g. F5 to FF commands ).

Yes curiosity about what exactly gets written to the disk is one, the other reason is I just want to code the fastest track buffer on the planet

That information should suffice and if you can provide those tracks I will be more than happy Thanks.

 

I will post some tracks, hopefully tomorrow. But note the following. I'm not sure you would be able to make track buffering any faster than Speedy or Happy. The order/interleave of sectors is not fixed, the correct way to handle that is how Hias described.

[mikey]

I will post some tracks, hopefully tomorrow.

 

Hi ijor,

 

Any news?

[ijor]

Hi ijor, Any news?

 

Sorry for the huge delay. Here is the track layout as written by the Happy on both densities. Let me know if you need something else (and hopefully I'll reply faster, sorry again).

 

Happy single:

$00 * 172
$FC
$00 * 16
[ repeat for each sector]
$00 * 6
$FE ... full sector header
$00 * 17
$FB
Sector data
Sector CRC
$00 * 14
[ end repeat]
$00 Until end of command

Happy MFM

$4E * 400
$00 * 12
Index Mark
$4E * 50
[ repeat for each sector]
$00 * 12
Sync Mark * 3
$FE ... full sector header
$4E * 22
$00 * 12
Sync Mark * 3
$FB
Sector data
Sector CRC
$00 * 18
$4E * 32
[ end repeat]
$4E Until end of command

[ijor]

Have you actually tried to verify that you cannot do a "Read Track" and rip up all the data sectors from a disk?

 

You definitely can't at all on MFM disk (double and enhanced density). On most sectors (depending on the exact data) you never read the actual data, no matter how many times you try.

 

I haven't researched the behaviour so much in FM (single density). But I can't tell you that it is not very reliable. Conceivable you could use it, but it wouldn't make much sense in most situations. The software would need to have some smartness to detect the sector data, and you would need to compute and verify the CRC's. That would be very slow without a more faster/modern processor.

 

You might do better to build the sector sequence as you describe and then "Read Address" at the beginning of each track to see where you are in the sequence. The seek will take some time and you may miss the 'first sector' in your list. (why use 1 as the first sector? use the physical first sector on the track, whatever that may be, and use the track padding for seek)

 

Yeah, I agree, this is better and faster.