Development of Blake's 7 (was OASIS development)

[Silicebit.]

A picture is worth a thousand words.

interleave-factor.png (16.63 KiB) Viewed 12558 times

[Symoon]

Thanks
And as far as I can understand, Dbug is calculating an offset to write the next sector - and not the sector value to write next as I thought.
So from now on I'll shut up

[Chema]

I made another test, this time with an interleave value of 10 and I got 19/20/19 seconds. Seems a bit faster, but nothing relevant. Besides I can't explain why. I even thought what could happen if writedsk is saving with some kind of interleaving (so in the end it would be like multiplying the two values), but I could not see anything like that in the source code.

So I am now a bit lost. The game loads something such as 82 sectors, plus some more for the loader, microdisc code, etc. If a sector is loaded each 35000 cicles, in the ideal case it should load everything in something such as 3 seconds. Add the track search, motor on, etc. but 20 seconds seem too much.

[Dbug]

BTW I realise, now I'm feeling a bit better, that what I posted above fro Sédoric à Nu was about the 1st sector of each track. Not the interleave between sectors in one track.
I'm afraid I've been generating noise rather than good ideas there...

It's actually a good idea, it means the sector order is not the same on each track, because if the sector count is not a perfect modulo, it means going from the last sector of a track to the first sector of the next track may not respect the interleave parameter.

That obviously only matters when a file overlaps multiple track and when they are not fragmented

That could be an interesting optimisation for FloppyBuilder if one day I add a layout optimisation module (to make sure to limit the number of track changes when reading files).

Now, regarding Chema's test, are we sure that WriteDsk does not reorder the sectors before writing them?

Would be interesting to use ReadDsk on two of the floppies to see if two DSK that had different interleaves did not end up written the same on disk

[Symoon]

The easiest way to check the result of writedsk might be to read the written disk with Nibble, in track mode?

BTW checked the code: Readdsk 2.0 uses a geometry parameter set to 1, and Writedsk uses the geomertry stored in the DSK file.

[Dbug]

The easiest way to check the result of writedsk might be to read the written disk with Nibble, in track mode?

I've never used Nibble, I believe you
I unfortunately don't have any machine able to create physical floppies...

BTW checked the code: Readdsk 2.0 uses a geometry parameter set to 1, and Writedsk uses the geomertry stored in the DSK file.

Interesting, so my idea of using ReadDsk would not work :p

[Silicebit.]

From Sedoric 3.0 à nu:

Début de la piste (facultatif): 40 [#4E], 12 [#00], [#C2 #C2 #C2 #FC] et 40 [#4E] (soit 96 octets pour SEDORIC).

Pour chaque secteur: 12 [#00], 3 [#A1] [#FE #pp #ff #ss #01 CRC CRC], 22 [#4E], 12 [#00], 3 [#A1], [#FB], les 256 octets, [CRC CRC], 12, 30 ou 40 octets [#4E] (selon le nombre de secteurs/piste). Soit environ 256 + (72 à 100) = 328 à 356 octets pour SEDORIC.

Dump with NIBBLE track 0 for a dsk image in EUPHORIC:

Code: Select all

Page    : 00 Piste   : 00 Lecteur : A

 0000 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 0010 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 0020 4E 4E 4E 4E 4E 4E 4E 4E 00 00 00 00 00 00 00 00 NNNNNNNN........
 0030 00 00 00 00 C2 C2 C2 FC 4E 4E 4E 4E 4E 4E 4E 4E ........NNNNNNNN
 0040 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 0050 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 0060 00 00 00 00 00 00 00 00 00 00 00 00 A1 A1 A1 FE ................
 0070 00 00 01 01 FA 0C 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E ......NNNNNNNNNN
             |
             -----------------------------------------------------------------> SECTOR 1
0080 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 00 00 00 00 NNNNNNNNNNNN....
 0090 00 00 00 00 00 00 00 00 A1 A1 A1 FB 01 00 00 00 ................
 00A0 00 00 00 00 20 20 20 20 20 20 20 20 00 00 03 00 ....        ....
 00B0 00 00 01 00 53 45 44 4F 52 49 43 20 20 20 20 20 ....SEDORIC     
 00C0 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
 00D0 20 20 20 20 20 20 20 20 20 20 20 20 53 45 44 4F             SEDO
 00E0 52 49 43 20 56 33 2E 30 30 36 20 30 31 2F 30 31 RIC V3.006 01/01
 00F0 2F 39 36 0D 0A 55 70 67 72 61 64 65 64 20 62 79 /96..Upgraded by
 0100 20 52 61 79 20 4D 63 4C 61 75 67 68 6C 69 6E 20  Ray McLaughlin 
 0110 20 20 20 20 20 20 20 20 0D 0A 61 6E 64 20 41 6E         ..and An
 0120 64 72 7B 20 43 68 7B 72 61 6D 79 20 20 20 20 20 dr{ Ch{ramy     
 0130 20 20 20 20 20 20 20 20 0D 0A 0D 0A 53 65 65 20         ....See 
 0140 53 45 44 4F 52 49 43 33 2E 46 49 58 20 66 69 6C SEDORIC3.FIX fil
 0150 65 20 66 6F 72 20 69 6E 66 6F 72 6D 61 74 69 6F e for informatio
 0160 6E 20 0D 0A 20 20 20 20 20 20 20 20 20 20 20 20 n ..            
 0170 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
 0180 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20                 
 0190 20 20 20 20 20 20 20 20 20 20 20 20 BE 12 4E 4E             ..NN
 01A0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 01B0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 01C0 4E 4E 4E 4E 4E 4E 00 00 00 00 00 00 00 00 00 00 NNNNNN..........
 01D0 00 00 A1 A1 A1 FE 00 00 02 01 AF 5F 4E 4E 4E 4E ..........._NNNN
                               |
                               ------------------------------------------------> SECTOR 2
 01E0 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 01F0 4E 4E 00 00 00 00 00 00 00 00 00 00 00 00 A1 A1 NN..............
 0200 A1 FB 00 00 FF 00 D0 9F D0 9F 02 B9 01 00 FF 00 ................
 0210 00 B9 E4 B9 00 00 E6 12 00 78 A9 7F 8D 0E 03 A9 .........x......
 0220 10 A0 07 8D 6B 02 8C 6C 02 A9 86 8D 14 03 A9 BA ....k..l........
 0230 A0 B9 20 1A 00 A9 84 8D 14 03 A2 02 BD FD CC 9D .. .............
 0240 F7 CC CA 10 F7 A2 37 A0 80 A9 00 18 79 00 C9 C8 ......7.....y...
 0250 D0 F9 EE 37 B9 CA D0 F3 A2 04 A8 F0 08 AD 01 B9 ...7............
 0260 A8 D0 02 A2 3C 84 00 A9 7B A0 B9 8D FE FF 8C FF ....<...{.......
 0270 FF A9 05 8D 12 03 A9 85 8D 14 03 A9 88 8D 10 03 ................
 0280 A0 00 58 AD 18 03 30 FB AD 13 03 99 00 C4 C8 4C ..X...0........L
 0290 6C B9 A9 84 8D 14 03 68 68 68 AD 10 03 29 1C D0 l......hhh...)..
 02A0 D5 EE 76 B9 EE 12 03 CA F0 1F AD 12 03 CD 00 B9 ..v.............
 02B0 D0 C1 A9 58 8D 10 03 A0 03 88 D0 FD AD 10 03 4A ...X...........J
 02C0 B0 FA A9 01 8D 12 03 D0 AA A9 C0 8D 0E 03 4C 00 ..............L.
 02D0 C4 0C 11 53 45 44 4F 52 49 43 20 56 33 2E 30 0A ...SEDORIC V3.0.
 02E0 0D 60 20 31 39 38 35 20 4F 52 49 43 20 49 4E 54 .` 1985 ORIC INT
 02F0 45 52 4E 41 54 49 4F 4E 41 4C 0D 0A 00 00 00 00 ERNATIONAL......
 0300 00 00 0E 9A 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E ....NNNNNNNNNNNN
 0310 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E NNNNNNNNNNNNNNNN
 0320 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 00 00 00 00 NNNNNNNNNNNN....
 0330 00 00 00 00 00 00 00 00 A1 A1 A1 FE 00 00 03 01 ................
                                                 |
                                                 ------------------------------> SECTOR 3
 0340 9C 6E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E 4E .nNNNNNNNNNNNNNN
 0350 4E 4E 4E 4E 4E 4E 4E 4E 00 00 00 00 00 00 00 00 NNNNNNNN........

The interleave seems be 1:1 for a dsk image.

[Chema]

Do you recommend me to boot with sedoric and try nibble on the real disks? The images are surely different, that I can tell.

Well, while we are dealing with this interesting and challenging question, I spent the evening finishing one feature: now a game position can be saved and loaded back from script code!

Still need a lot of testing and cleaning, but it is working!!! I managed to do with 7 sectors only of saved data. It could be less, if I reduce the amount of variables available to scripts. I will have a look, but that is great news!

[Dbug]

I just realized one thing: At the moment the layout of the floppy is to first use the side 0, then the side 1.
In term of performance, it would probably make sense to alternate between the two sides, to limit the number of track changes...

Hmm... so many things

[Symoon]

Do you recommend me to boot with sedoric and try nibble on the real disks?

The idea was, if one wants to check the geometry result of Writedsk, this is certainly the easiest way to check it.
Having to read the disk again in a PC to make a DSK file would be longer, and maybe not valid since you'd use another reading/writing tool that probably changes what you're trying to verify

BTW: geometry is stored in the header of the DSK files. I can't recall how it could be changed, maybe it was with very first versions of Readdsk, the ones that later required Old2mfm.exe to be converted to nowadays DSK files that now seem to only use "1".

[Dbug]

BTW: geometry is stored in the header of the DSK files. I can't recall how it could be changed, maybe it was with very first versions of Readdsk, the ones that later required Old2mfm.exe to be converted to nowadays DSK files that now seem to only use "1".

Haaaaaaa.... I totally missed that one:

Code: Select all

    FloppyHeader& header(*((FloppyHeader*)m_Buffer));
    header.Clear();
    header.SetSignature("MFM_DISK");
    header.SetSideNumber(numberOfSides);
    header.SetTrackNumber(numberOfTracks);
    header.SetGeometry(1);

So, what exactly is the definition of geometry in this context?

The actual header definition is:

char m_Signature[8]; // (MFM_DISK)
unsigned char m_Sides[4]; // : 4 bytes (2)
unsigned char m_Tracks[4]; // : 4 bytes (42/$2A)
unsigned char m_Geometry[4]; // : 4 bytes (1)
unsigned char m_Padding[236]; // : 236 bytes (000000...00000 )

So the geometry parameters are taking 4 bytes.
What should I write if I play with the sector interleave in the actual sector data

Basically what I did is to physically interleave the sectors in the DSK file, but I did not touch the geometry value, so possibly WriteDsk just ignored all my sector interleaving and just forced it to whatever geometry was set... would explain the almost constant speed between the different tests.

[Silicebit.]

I just realized one thing: At the moment the layout of the floppy is to first use the side 0, then the side 1.
In term of performance, it would probably make sense to alternate between the two sides, to limit the number of track changes...

Hmm... so many things

That's a brilliant idea!!

Detailed information in Defence Force Wiki, about disk formats: http://wiki.defence-force.org/doku.php? ... are:floppy

[Symoon]

BTW: geometry is stored in the header of the DSK files. I can't recall how it could be changed, maybe it was with very first versions of Readdsk, the ones that later required Old2mfm.exe to be converted to nowadays DSK files that now seem to only use "1".

Haaaaaaa.... I totally missed that one:
[..]
Basically what I did is to physically interleave the sectors in the DSK file, but I did not touch the geometry value, so possibly WriteDsk just ignored all my sector interleaving and just forced it to whatever geometry was set... would explain the almost constant speed between the different tests.

That's a possibility, I wasn't clear enough when I said Writedsk used the geometry of the DSK file: it actually reads it from the header.
I wish I could find back old DSK files with different geometry but it's not easy to search unless you're a grep wizard I'm certain I saw DSK files with sectors that were not "in the right order" (for me at the time, I mean! ), but I suspect it was before Readdsk 2.0.

EDIT: argh, no it's probably more yet another red herring
From CEO-Mag 153, by Fabrice himself:

POUR LE FORMAT "MFM", toujours un en-tête de 256 octets :
- une signature de 8 octets: MFM_DISK
- le nombre de faces (toujours 32 bits little-endian)
- le nombre de pistes (32 bits)
- le type de géométrie (32 bits)
- le reste de l’entête est inutilisé actuellement mais réservé pour un éventuel usage futur (par ex.: une extension du format pour prendre en compte correctement les disquettes BD-500 !)...
Viennent ensuite les contenus des pistes: implicitement chaque piste contient 6250 octets, complétée par des octets inutilisés pour avoir une taille multiple de 256, soit 6400 (ce sont ces octets inutilisés que j’ai réquisitionnés pour faire entrer la disquette BD-500 dans le format existant !). Le type de géométrie indique dans quel ordre viennent les pistes: la géométrie 1 donne d’abord toutes les pistes de la première face, puis celle de la seconde, etc. ; la géométrie 2 donne d’abord les pistes du cylindre 0, puis celles des cylindres 1, 2, 3, etc. (la géométrie 1 est celle utilisée par les OS Oric, la géométrie 2 celle utilisée dans le monde hors-Oric). Comme je le disais, je risque d’étendre l’entête MFM en rajoutant un champ donnant le nombre d’octets dans chaque piste, la valeur 0 actuelle signifiera 6250.
[Exemple, voici les 20 octets d’en-tête de la disquette Sedoric 3.0 au format "mfm":
4D464D5F4449534B 02000000 50000000 01000000 soit:
MFM_DISK (8 octets), 2 faces (4 octets), 80 pistes (4 octets) et géométrie n°1 (4 octets). Les 246 octets suivants sont inutilisés pour l’instant. Pour le nombre de face #01=une et #02=deux. La géométrie utilisée par Oric est toujours #01.]

To make it short, the "geometry" parameter used by Readdsk and Writedsk apparently doesn't affect the sectors order, but the tracks order in the DSK file (and on real floppy?) : all side 1 1st, then 2nd side, or tracks order whatever the side.
So Geometry would rather apply to tracks order, and interleave to sectors order? (just asking to try to be clear next time)
PS: should we move this discussion into a dedicated thread? We're filling Chema's one with general technical chat...

[Chema]

I have no problem with having this discussion here, but if you prefer to have it in the FloppyBuilder forum...

Okay, so writedsk does not change anything (still to be confirmed, but highly probable), but we still get quite constant reading times. What about looking for the culprit in another place? Don't know, maybe a bug which makes the drive search for the track at each sector read or something..

Maybe a dedicated test should be prepared, two blocks to be read one compressed the other uncompressed and using FloppyBuilder and as a normal SEDORIC file?

I have too much work to do, but if someone points me into the correct direction (or better yet, gives me some code to test) I may try it this weekend.

On another note, not only the saving/loading seems to work (nobody commented on that but it is good news) but I also have a preliminary version of the PAUSE/MENU. Just a stub for now, but working.

From the menu you will be able to change the volume settings, redefine the keys and load the last saved position. The menu can be launched from within a script (so it is opened automatically after the intro) or when pressing ESC.

As the saving is ordered from within the script code I plan to save each time the player achieves something, maybe when he picks something up too. Any ideas? Too much saving is a bit intrusive, but too little is not good either.

Btw, I made a test today saving in the middle of a script (the response of a Look At action over an object) and, when loaded, the script continued running just after the save instruction, in this case making Blake describe the object. So it is working quite nicely

[iss]

... two blocks to be read one compressed the other uncompressed ...

You read my mind Attached is what I've done today - test which reads one and the same picture as uncompressed and compressed. It uses the old version of FloppyBuilder, but I think there should be no big differences with the new version. Time is measured in microseconds with T1 extended to 32-bit. Letter 'R' is printed on start of every sector.
I plan using HxC tools to create from this image real floppies with different interleave.

testfbs.dsk

(500.25 KiB) Downloaded 295 times