18 sectors per track?

[Dbug]

So a few months ago I asked a question about how well supported was the 18 sectors per track format.

My problem is that floppies generated by FloppyBuilder work fine with 17 sectors, but it does not work with 18, or more exactly it works in Oricutron, but it does not work on Cumulus, which could be a number of reasons including incorrect parameters.

What I used in FloppyBuilder is derived from existing tools, I never verified if it was correct:

Code: Select all

  // Heavily based on MakeDisk and Tap2DSk
  // Additional comments from "Sedoric a Nu", page 62
  int gap1,gap2,gap3;

  switch (numberOfSectors) 
  {
  case 15: case 16: case 17:
    gap1=72; gap2=34; gap3=50;
    break;

  case 18:
    gap1=12; gap2=34; gap3=46;
    break;

  default:
    ShowError("%d is an unrealistic sectors per track number, supported values are 15, 16, 17 and 18 sectors per track\n", numberOfSectors);
    return false;
  }

I generated two floppies, one with 17 sectors per track and one with 18 sectors per track. (I could not test on Loci because mine stopped working reliably after I updated to the latest firmware)

Not sure if there are any tools that can be used to determine if my format is correct?

If anyone has a 18 sectors per track DSK file that works fine on their cumulus, I would be interested in in having a copy!

DskTest-v1.1.2-17s.dsk

(525.25 KiB) Downloaded 143 times

DskTest-v1.1.2-18s.dsk

(525.25 KiB) Downloaded 141 times

Basically if I could get a reliable 18 sectors per track format, that would give me an additional 21 kb to finish a couple of "nice to have" for Encounter!

[iss]

Wow, amazing "System Check"!

Both images are working for me with LOCI just fine - no issues at all.
I've tested on purpose with a bad USB-stick (cheap, slow and with fake advertised size) and everything works.

Cumulus: I've checked quickly the sources and found a hard coded value of 6250 used as max track length in loops for read/write handling (see 179X.c link in your guthub ). I'm not sure if this is the exact problem but looks enough suspicious (DSK allocates 6400 bytes per MFM track). I can do some test with Cumulus if needed but not earlier than next week.

About GAP numbers - imho they should be OK.
*BUT*
In my (still unfinished ) project "booter" I've made some calculations of GAP sizes with the idea to distribute data evenly. I already forgot all details but this is the structure holding the GAP sizes:

Code: Select all

static struct {
  int gap_head_len;
  int gap_body_len;
  int gap_tail_len;
} gaps[5] = {
  { 142, 34, 98 }, // 15
  { 108, 34, 74 }, // 16
  { 88, 34, 52 }, // 17
  { 40, 34, 34 }, // 18
  { 28, 34, 16 }, // 19
};

... and the excel sheet from where the numbers come:

Attached are 2 DSK images with 18 and 19 sectors / 40 tracks / 1 side and the build log file for 18 sec variant.
The test reads a frame, shows it and writes it back
They both work well with LOCI !
The images should work with Microdisk, Jasmin and BD500 controllers, included is working code for 8D-FDC
but the layout 1:40:18 is not compatible with the Apple Disk ][ drive .

[Dbug]

Wow, amazing "System Check"!

Thanks, that was a practical way to check the actual "is the tech working on your machine" using the exact same codebase and loader as the game itself.

Both images are working for me with LOCI just fine - no issues at all.
I've tested on purpose with a bad USB-stick (cheap, slow and with fake advertised size) and everything works.

It worked on my LOCI last time, so not surprised.
I guess I should try on my Cumana reborn.

Cumulus: I've checked quickly the sources and found a hard coded value of 6250 used as max track length in loops for read/write handling (see 179X.c link in your guthub ). I'm not sure if this is the exact problem but looks enough suspicious (DSK allocates 6400 bytes per MFM track). I can do some test with Cumulus if needed but not earlier than next week.

Would be nice

I wonder if I could try to boot SEDORIC on A and have some random DSK on B and use the INIT command to format the other disk in 18 sectors and see if Cumulus can boot it properly.

The images should work with Microdisk, Jasmin and BD500 controllers, included is working code for 8D-FDC
but the layout 1:40:18 is not compatible with the Apple Disk ][ drive .

Are you working on Fantasmagoric 2.0 with support for even more drives?
If you have a working Jasmin, would be interesting to see if you can test the disks on it, see if it boots?
I know it works in Jasmin mode in Oricutron, but I was not able to test on a real one!

[Chema]

If I find some time, I will test on my Cumulus. Want to test with real floppies or Gotek?

If you have a working Jasmin, would be interesting to see if you can test the disks on it, see if it boots?
I know it works in Jasmin mode in Oricutron, but I was not able to test on a real one!

Blake's 7 does not work in a real Jasmin drive. We made some tests until it worked in Oricutron and Euphoric emulating a Jasmin, but still it fails to boot on the real thing. Never found out why.

[Dbug]

My hope is that if ISS "booter" works on Jasmin, he may have an idea about why B7 or Encounter would fail on it.

[iss]

Are you working on Fantasmagoric 2.0 with support for even more drives?

It's not Fantasmagoric related. It's just "booter" and is rework of the QuadroBoot and maybe I should call it already "QuintaBooter": i.e. Microdisc, Jasmin, BD500, Telestrat and 8D-FDC.
Well, basically it does the same as FloppyBuilder but I wanted to avoid (somehow) the 2-pass build which in fact is not big gain. The disk layout/size is limited to 1:35:16 (~144k) only when 8D-FDC compatibility is required. Anyway, I hope to finish it in the very near future...

My hope is that if ISS "booter" works on Jasmin, he may have an idea about why B7 or Encounter would fail on it.

The last status with Jasmin is: reading with polling (like Microdisc) but writing works only with IRQ.
I will do all test again (together with Cumulus) and it will be really useful someone else with Jasmin to simply confirm the results.

[Dbug]

Whaou, I modified FloppyBuilder gaps to be the ones you provided, and suddenly the disk tester works on Cumulus!

Before:

Code: Select all

     gap1 = 12; gap2 = 34; gap3 = 46;

After:

Code: Select all

     gap1 = 40; gap2 = 34; gap3 = 34;

Weird... need to double check!

EDIT: Ok, seems to work, you can try the disk here:

EncounterHD-FR-50HZ-Test-v1.1.2.dsk

(525.25 KiB) Downloaded 140 times

[iss]

Great! I'm very glad that It works! It works! I finally invent something that works!

34e440d8-5846-41a0-b4b5-c1fd74fcbf70_text.gif (402.42 KiB) Viewed 3234 times

So, next milestone Jasmin tests

[Sodiumlightbaby]

This is awsome! Well done!