Fun with HD18..rom compatible drives

[shane.crozier]

Noted. I have deleted my conversations which has deleted the roms also i believe. To clarify I have not used any AI agents which are more of a concern than Claude and Grok.  I will cease and desist in my AI use. Regards 

No need to stop using AI if you want to do that, just be mindful of what you send to it, that's all.

PS If I am storing files on OneDrive or GoogleDrive is this permissible?

As you have to have a secure account for both of these, that only you have access to, I see no problem.
If you are sharing the content of your OneDrive or GoogleDrive with others, then you need to remove access
for the files covered by the EULA.

Thanks for your understanding.

Thanks for the reminder Ewan - I have a subscription for the AI tools I use, and ensure the settings I have forbid AI using any uploaded data for training, and do not use any free versions for this reason - but I get where you're coming from.

Its pretty easy to forget that it's not just a helpful geek that is getting acccess - its a piece of someone elses's IP.

---

There is a lot of source code for formatting floppy drives on the various cpm resource sites. Have a look at how a floppy is formatted, I'd speculate that it is pretty similar to how the HD were formatted. Then have a look at the cf bios code, there is a format code in there and partition code that runs on both ide and cf. The underlying media only has impact at lower level.
I suspect you're thinking more of partitioning rather than the dpb.
Original cpm code worked with 128byte sectors, then mostly changed to 512 byte sectors by adding blocking/deblocking code (also fairly well documented in cpm manuals online). Apart from much later homebrew systems, hd used c/h/s but now we add partition tables as another layer. Each partition is effectively the same as a big floppy disk from the user api point of view.
Much of this bled into msdos so the descriptions of how that works is pretty similar.
With that info on board, working out how the init.com works will be a little clearer. Keep in mind the year that this stuff was written and the hardware that it as used on, the concepts that were known then aren't always the same as we have had since then.
Good luck
gb
aka Rod

Cheers Rod - I think from what I have observed on the virtual hardware, the following seems to be true;

The Init.com utility calculates a disks geometry and creates a number of tracks based on the cylinder count. ie Tracks=Cyl x Heads  - the 10Mb hard disks we have all seem to have a 612 x 2 or 306 x 4 geometry so the total track count stays the same.

I have managed to work the locations in the init.com which use this value and patch them to a 20Mb geometry (612 x 4) which works fine - the init.com utility does the necessary writing of the E5 values over each sector (and the size of the virtual hd in uBee512 extends to the 21Mb mark)

I have sort of managed to update the partitioning routines - these are harder - there is a 'clamp' value in there which uses an accumulator to calculate the sum of the partitions and clamp it to 10Mb which needed to be updated - once you settle on a number of partitions and sizes - a DPB is calculated and created in ram, and then can be written to the drive or to floppy and rebooted - this describes which area of the HDD are seen as which logical drive (and has entries for the Floppy and M drives too)  I beleive the CPM 2.2 used has enough space in the DPB it uses for Drives A-D and Floppy E-G, Ram M and it points L back to E  (Unless it is booted from floppy disk in which cases it is A-C Floppy, D-G Hard Disk, Ram M and L points back to A)

In terms of creating a partition or constructing a dpb with a sector offset for subsequent drives to finish after the one before it - I beleive these activities are effectively the same thing.

In larger disks, the DPB needs to define a block shift larger than smaller disks - it doesnt trigger that element and the DPB that is written seems to over-write data in neighboring partitions (I suspect this isn't catered for in the vanilla init.com since none of the drives would typically get big enough, even though the max partition size is 8Mb and it theoretically could)

The Faulty DPB its writing to the boot disk now looks something like this 
   

Offset   SPT  BSH  BLM  EXM  DSM    DRM  AL0  AL1  CKS  OFF     Size
0x10C5   68   5    31   1    2047   511  F0   00   0    2       8 MiB
0x10D5   68   5    31   1    2047   511  F0   00   0    966     8 MiB
0x10E5   68   5    31   1    4095   511  F0   00   0    1226    16 MiB
0x10F5   68   5    31   1    1684   511  F0   00   0    1655    ~6.58 MiB

I can use cpmtools' fsed.cpm to check the layouts of the virtual drive and poke around, but since CPM is interpreting the drives, its a lot more useful to do it inside the Virtual machine.

Having access to one of the Teac 520 Drive versions of the init.com would confirm my approach - but I dont think there's one in the repository (or we'd all be using 20Mb partitions on uBee512)