Calculate DSK file offset from track, sector and side

[+khanivore]

Hi folks,

Following on from the discussion yesterday about offsets in DSK files, just FYI, I found that the track number for side 2 of the disk is "inverted" as we suspected so I have to subtract the track number from 39 when seeking on side 2.

This function correctly finds the right sector in the file.

static void seekDiskFile (void)
{
    int sector = disk.sector;

    if (disk.side)
        sector += 360 + (39 - disk.track) * sectorsPerTrack;
    else
        sector += disk.track * sectorsPerTrack;

    fseek (diskFile, sector * DISK_BYTES_PER_SECTOR, SEEK_SET);
}

Now I can play ZORK 🙂
 

[+llabnip]

[+khanivore]

Or Hitchhikers's guide .. even better

[Tursi]

10 hours ago, khanivore said:

Following on from the discussion yesterday about offsets in DSK files, just FYI, I found that the track number for side 2 of the disk is "inverted" as we suspected so I have to subtract the track number from 39 when seeking on side 2.

Be warned, it's likely that only old disk images have this. I've had the option to invert side 2 in Classic99 for decades and never needed to use it myself.

 

[+khanivore]

13 hours ago, Tursi said:

Be warned, it's likely that only old disk images have this. I've had the option to invert side 2 in Classic99 for decades and never needed to use it myself.

Interesting, thanks @Tursi.  Yes I checked yesterday and noticed you were doing 79-Trk in ImageDisk.cpp.  We've possibly taken different approaches though.  I'm using the original (I think) disk controller DSR ROM and just doing a simple emulation the FD1771 FDC.  So the code just fetches the sector the DSR asks for by converting track,sector,side to an LBA sector number.
 

The dsk file is just a linear dump of sectors and is consistent.  If I use my disk dump tool to look at HITCHHIK.dsk I can see the LOAD program is at sector 602, which is on side 2:

Vol-Label='HITCHHIKER', sectors=720, sec/trk:9, DSR:'DSK', Protect:' ', tracks:40, sides:2, density:01, Chains
Name       Sector Len    Flags           #Sectors #Records EOF-offset L3Alloc Rec-Len Sectors
========== ====== ====== =============== ======== ======== ========== ======= ======= =======
80HITCHHIK      2   5632 01(FIX-ASC-PROG)      23        0          0       0       0 0=(50-72)
80HITCHHIL      3   3072 01(FIX-ASC-PROG)      13        0          0       0       0 0=(73-85)
HITC1           4      0 00(FIX-ASC-DATA)      90       90          0   23040     255 0=(86-175)
HITC2           5      0 00(FIX-ASC-DATA)     356      356          0   25601     255 0=(176-531)
HITCHHIKER      6   3328 01(FIX-ASC-PROG)      14        0          0       0       0 0=(532-545)
HITCHHIKES      7   5632 01(FIX-ASC-PROG)      23        0          0       0       0 0=(546-568)
INF             8   7664 01(FIX-ASC-PROG)      30        0        240       0       0 0=(569-598)
INF-DOCS        9      0 80(VAR-ASC-DATA)       3        9        225     768      80 0=(599-601)
LOAD           10   1888 01(FIX-ASC-PROG)       8        0         96       0       0 0=(602-609)
VOCABULARY     11      0 80(VAR-ASC-DATA)       3        9        245     768      80 0=(32-34)

And if I decode the contents of sector 602, it looks correct:

100 !@S.Gary 2 North Dr.#216  Scarboro Ont.Canada M1N 1Z2
110 !**********************
120 !*                    *
130 !*    Generated By    *
140 !*    SysTex  V1.0    *
150 !*      (C) 1985      *
160 !*   By Barry Boone   *
170 !*                    *
180 !**********************

BUT when I run my emulator, the DSR is fetching the LOAD program from Track13,Sec8,side1, which unless I invert the track yields the wrong sector number of 485:

DSK - read sector 1 [T:0 Sec:1 Side:0]
DSK - read sector 9 [T:1 Sec:0 Side:0]
DSK - read sector 11 [T:1 Sec:2 Side:0]
DSK - read sector 10 [T:1 Sec:1 Side:0]
DSK - read sector 485 [T:13 Sec:8 Side:1]
DSK - read sector 468 [T:12 Sec:0 Side:1]
DSK - read sector 469 [T:12 Sec:1 Side:1]
DSK - read sector 470 [T:12 Sec:2 Side:1]
DSK - read sector 471 [T:12 Sec:3 Side:1]
DSK - read sector 472 [T:12 Sec:4 Side:1]

Changing that to Track (39-13=26), Sec8, Side1 yields the correct LBA of 602 and the LOAD works.

So my read is that the dsk file is correct but the logic to invert the track is in the DSR?

[Tursi]

hmm, dunno. I only worry about the sector number and treat it linearly, I stop emulation before I get to the disk controller IC.

 

[JasonACT]

17 hours ago, khanivore said:

So my read is that the dsk file is correct but the logic to invert the track is in the DSR?

 

Yep...

https://www.unige.ch/medecine/nouspikel/ti99/dc2.txt

 

*---------------------------------------
* Sector read/write
*---------------------------------------
A40E8  LI   4,>000A           try ten times
A40EC  MOVB @A4630,@>0050(9)  no error
       BL   @A4496            select drive
       BL   @A45F0            point to # of last track
       CLR  0
       MOVB @>FBFE(15),0      get # of last track accessed
       CI   0,>D700
       JH   A410C             too high: drive was reset
       BL   @A4524            seek track 0
       SETO 0                 inverted data bus" >FF will be >00
A410C  MOVB 0,@>5FFA          place >00 in track register
       MOV  @>004A(9),1       sector #
       SBZ  7                 side 0
       CLR  7
       CI   1,>02D0           max 720 (DS/SD)
       JHE  A41B6             error 7
       CI   1,>0168           on which side is it?
       JL   A413E             0-359: on side 0
       AI   1,-719            on side 1: sector # grow from in to out
       ABS  1                 719 - sector #
       CLR  0
       DIV  @A4632,0          sect/track (=9)
       AI   1,-8              invert: 8=0, 0=8, 7=1, etc
       ABS  1
       SBO  7                 side 1
       LI   7,>0100           side number = >01
       JMP  A414E
A413E  CI   1,>0001           is it sector 0 or 1?
       JH   A4148             no
       BL   @A4524            yes: seek track 0
A4148  CLR  0
       DIV  @A4632,0          R0=track #, R1=sector #
A414E  SWPB 0

 

This part in particular

       CI   1,>0168           on which side is it?
       JL   A413E             0-359: on side 0
       AI   1,-719            on side 1: sector # grow from in to out
       ABS  1                 719 - sector #

But I've also replaced this function along with "format disk" in my custom DSR build (it now makes direct requests to my Pi Pico).  It also doesn't seem to have any issues with 360KB disk images (or 1600 sector ~400KB RAMDisks I've just implemented) now these functions are replaced.

[+khanivore]

Ah, very good, thanks.  I had missed Thierry's commented disassembly of the DSR.  It would have helped a lot!

[+FarmerPotato]

adding my 2 cents  -- the common DSK image is a logical sector dump, not a physical layout.

With Kryoflux, I would dump the two sides in separate files, then invert the track order of side 2.

 

Also  we don't keep sector interleave in the DSK logical dump! (Yuck) The distinction between SD and DD is only detectable in the sector 0 header. 
 

I suspect that since the TI-99/4 first had a SSSD drive, the reverse track order was preferable, once DSSD drives were  adopted. Save on head movement.
 

Might be different if a computer system had always had double sided floppies--both sides of cylinder 0 might be logically contiguous. (Example?)

 

TI's track scheme on 8" floppies in the DX10 operating system is something else. Stuck trying to decipher it.  It's the ancestor of the TI-99 DSR.
 

(Someone was too clever: decided to squeeze in 288 bytes/sector. It lets you create a DIS/FIX 288 file if you like.)

 

 

Edited October 24 by FarmerPotato

[+khanivore]

I guess once we got drives with multiple heads, and even multiple platters, it made sense to read both sides at the same time and cluster the sectors together so track/cylinder numbering needed to be consistent.

 

Deciphering the 8" sounds like fun 

[+OLD CS1]

1 hour ago, khanivore said:

I guess once we got drives with multiple heads, and even multiple platters, it made sense to read both sides at the same time and cluster the sectors together so track/cylinder numbering needed to be consistent.

On the Amiga, a lot of tools work the same track and both sides in sequence.

6 hours ago, FarmerPotato said:

(Someone was too clever: decided to squeeze in 288 bytes/sector. It lets you create a DIS/FIX 288 file if you like.)

This is interesting.  I understood MFM 8" formats, and the 5.25" descendants, use an IBM standard (System/34, IIRC,) format.  (FM would be 3740 or something like that.)  Are 288-byte sectors a different format altogether?

[+FarmerPotato]

19 hours ago, OLD CS1 said:

On the Amiga, a lot of tools work the same track and both sides in sequence.

This is interesting.  I understood MFM 8" formats, and the 5.25" descendants, use an IBM standard (System/34, IIRC,) format.  (FM would be 3740 or something like that.)  Are 288-byte sectors a different format altogether?

You can read the Shugart SA855 8" floppy drive manual for a good explanation of the FM and MFM recording formats, plus the "standard" track and sector byte streams.

 

I don't know if those low-level formats persisted unchanged, but IBM did copy the Shugart 50-pin interface, reducing it to 34, and that  endured.

In the Shugart low-level format, you have data sector islands in a stream of sync bytes, CRC code, logical sector number, and dead space. The "unformatted" capacity of a track was 500 Kbps * 300 rpm = 100 Kbps or 12,500 bytes. Within that, 18*512 formatted bytes means 3284 is "in between"--about 20% of the so-called "unformatted" capacity. That's 182 bytes in the gap between each sector. 
 

You could choose any sector size really, but Shugart laid out the math for 256, 512, and 1024.  You can see the tradeoffs: amount of wasted space vs required memory buffer size and maximum response time. Whether your CPU could keep up. 
 

Why 288, TI??!

 

288 bytes is 256 + 32. It could make a difference for database files: you get 32 bytes for the overhead of an index! At least that's my guess. KEY-INDEX database files added overhead to your FIXED record size. 
 

Can you steal 32 bytes out of the gap space?

Table

 

You get equal formatted capacity of 9216 with any of these ratios:

 

12500 - 9216 = 3284

Factors of 9216 bytes:

 

9 *1024 : gap 3284/9=364

18*512 : gap 3284/18 = 182

32*288 : gap 3284/32 = 102

36*256 : gap 3284/36 = 91

 

36*288 : gap 2132/36 = 59

 

If it's 32*288, no big deal. If you squeeze out more, the timing is very very tight. 


Many of TI's hard disks, like DS10 or DS50, used 288-byte sectors, but others 256. (Copying files was... awkward.)

I don't know which came first, hard disk or floppy sector 288. I'm trying to justify it. 

 

Edited October 25 by FarmerPotato

[+FarmerPotato]

Different topic. 
 

Interleave and Skew

During low-level format, 

you can also number the sectors in a different order. Unless your controller can keep up with 1,2,3,4 during the little dead space between sectors, you want them reordered like 1,9,2,10... That is 2:1 interleave and you have a MUCH longer time between logical sector 1 and 2.  (The TI DSR returns the sector, code asks for more, lots of memory moves...)

 

You can guess the interleave by listening to a sector-by-sector copy.  Measure the time between the audible clicks, which is the head advancing to the next track.  1 second at 300 rpm = 5 revolutions. Does it require 1, 2, or 3 revolutions? (Also,  a revolution or two is wasted while the head moves.)

 

 

CorComp and Myarc controllers allowed a choice if interleave. Also skew.
 

Skew: Tracks have a first logical sector at different spots. Why? While the head moves to the next track, the disk revolves partially. If you get skew right, the next logical sector is moving under the head just when the head is ready.
 

I remember trying the combinations on a TI-99/4A. HyperCopy I think?
 

If you have a JumpBoot disk for Geneve, you're seeing interleave and skew in perfect harmony. MDOS, more than 300 sectors, would boot much faster. 
 

16-Sector Double Density 5.25"

 

Remember the first Myarc DSDD controller made 16*256 sectors per track? While CorComp got 18*25. TI's unreleased "Lewisville" was 16*256 (HexBus disk too?)

 

I think the controller chip was limited in some way?

 

I guess that if recording density was the same, it's all up to the gap between sectors. So is it just a software problem? if your software can keep up?  When Myarc upgraded from 16 to 18, was it just software? I don't know for certain.
 

I only used the Myarc as a 16-sector variety. Now I have the HFDC.  (And I think all my unreadable floppies were made on that FDC in MDOS. I don't have a theory as to why they're unreadable on anything. Even Kryoflux gives up.) 

 

Better quit now, talked too much. 

[+mizapf]

The HX5102 (Hexbus floppy drive for the TI-99/8 and /2) also offers DSDD16. The only reason that I can imagine is that 16 sectors/track make calculations of cylinder/head/sector simpler. The 16-sector variant just shows longer gaps than the 18-sector variant; this does not make recording any safer.

 

An unformatted MFM track can contain up to 6250 bytes. However, you need some bytes for gaps and marks, so you end up with 18 sectors in a comfortable layout (with sufficient gaps). No squeezing or other tricks. It is certainly possible to put fewer sectors into the track by making the gaps longer, but this does not help in any way, not even in terms of transfer rate, since we also have to apply sector interleaving.

 

One way to create unreadable floppies is by using an 80-track drive. The disk will not be readable in any 40-track drive anymore until it is formatted.

[+InsaneMultitasker]

13 hours ago, FarmerPotato said:

I only used the Myarc as a 16-sector variety. Now I have the HFDC.  (And I think all my unreadable floppies were made on that FDC in MDOS. I don't have a theory as to why they're unreadable on anything. Even Kryoflux gives up.) 

A friend used various 80 track drives with his 40-track controller.  Did you use an 80 track drive, perhaps unwittingly? This might explain the Kryoflux issue as well. 

 

If I recall correctly, the HFDC supports both 16- and 18-sector per track, though I can't say I've tested that in decades.   Myarc's MDM3 (for the FDC) had a few iterations back in the day, with later releases supporting 16/18 track format options and 80 track disk management. 

[+FarmerPotato]

On 10/24/2023 at 12:16 AM, JasonACT said:

 

Yep...

https://www.unige.ch/medecine/nouspikel/ti99/dc2.txt

 

 

This part in particular

       CI   1,>0168           on which side is it?
       JL   A413E             0-359: on side 0
       AI   1,-719            on side 1: sector # grow from in to out
       ABS  1                 719 - sector #

But I've also replaced this function along with "format disk" in my custom DSR build (it now makes direct requests to my Pi Pico).  It also doesn't seem to have any issues with 360KB disk images (or 1600 sector ~400KB RAMDisks I've just implemented) now these functions are replaced.

Wow, you patched the TI DSR! 

 

Thanks for the pointer to the disassembly, I hadn't found that. Studying it. 

 

This line is the TI disk interleave: it's 4:1 (4 revolutions to get the whole track)

A464F  BYTE 0,7,5,3,1,8,6,4   sector interlace pattern
A4657  BYTE 2

 

[chris36]

On 10/24/2023 at 10:20 AM, FarmerPotato said:

With Kryoflux, I would dump the two sides in separate files, then invert the track order of side 2.

 

As an aside, the latest Kryoflux software added an option to reverse the track order when writing out the image.