+- Discussion Forum for all things Microbee (https://microbeetechnology.com.au/forum)
+-- Forum: Microbee Forum (https://microbeetechnology.com.au/forum/forum-1.html)
+--- Forum: Microbee Software and Documentation (https://microbeetechnology.com.au/forum/forum-7.html)
+--- Thread: Fun with HD18..rom compatible drives (/thread-1015.html)
Fun with HD18..rom compatible drives - shane.crozier - 20-04-2026
I have been working on patching the ship, init, maintain utilities to allow the use of a 20Mb hard disk drive (612/4/17) - effectively the same geometry as the Teac SD-520.
I didn’t have access to the assembly source for any of the software so started by disassembling the executables and working with GPT to identify the routines that called
The ship.com utility was the easiest as it’s effectively a tiny assembly routine that performs a seek beyond the 612 cylinder and waits for power to be turned off or a keypress.
The init.com utility was a lot more complex - as there were values that weren’t as obvious as cylinder / head / sectors - the total # of cylinders was calculated and ‘guard-rails’ were used as validation - I could get the ship.com hard disk routine to format the drive to the size I wanted quite quickly.
What was more complex (and is still ongoing) is the partition definition - the logic within the init.com routine allowed a maximum of 10Mb to be divided up in 0.5Mb increments - this needed to be extended to 20Mb while maintaining a maximum partition size of 8Mb.
A minimum of three partitions is required on a 20Mb disk as it needs to fulfil the criteria of no partition can exceed maximum CP/M 2.2 size of 8Mb, and the remaining space is automatically added to the last partition if the full drive capacity has not been reached.
I have managed to get the interface to work correctly -but- what appears to be the final *Hopefully* issue is the calculations of the DPB and placement of the directory blocks with the right offsets from track 0 for the second and subsequent partitions - use of partition #3 causes the system to crash.
RE: Fun with HD18..rom compatible drives - Graham72 - 23-04-2026
Have you tried using Claude to assist with this coding?
RE: Fun with HD18..rom compatible drives - shane.crozier - 24-04-2026
(23-04-2026, 04:57 PM)Graham72 Wrote: Have you tried using Claude to assist with this coding?
I did use GPT to do some disassembly and to assist with mapping the regions of the executable that were values / strings vs code - I might give Claude a shot at it since I'm hoping to work out how the init.com writes the DPB to the hard disk when I have time this weekend.
RE: Fun with HD18..rom compatible drives - greybeard - 25-04-2026
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
RE: Fun with HD18..rom compatible drives - MbeeTech - 26-04-2026
Hi All.
This may seem a little pedantic but I just want to bring up the use of AI within the hobby.
Specifically, the use of Microbee Technology IP (or in fact, anyone else's IP that you've accepted a License Agreement for) being analysed with the aid of AI.
If you are sharing code or rom images with any AI agent that is internet based (rather than an isolated, non-internet based AI)
you are allowing the code / rom / disk images into an uncontrolled environment (ie: you have no
control over what the AI does with it after it has accessed it.)
While the End User License Agreement does not specifically address AI usage at present, you are redistributing
the IP which is against the terms and conditions of usage.
In the coming months there will be an update to the End User License Agreement to specifically address AI usage.
RE: Fun with HD18..rom compatible drives - Graham72 - 26-04-2026
(26-04-2026, 02:22 PM)MbeeTech Wrote: Hi All.
This may seem a little pedantic but I just want to bring up the use of AI within the hobby.
Specifically, the use of Microbee Technology IP being analysed with the aid of AI.
If you are sharing code or rom images with any AI agent that is internet based (rather than an isolated, non-internet based AI)
you are allowing the code / rom / disk images into an uncontrolled environment (ie: you have no
control over what the AI does with it after it has accessed it.)
While the End User License Agreement does not specifically address AI usage at present, you are redistributing
the IP which is against the terms and conditions of usage.
In the coming months there will be an update to the End User License Agreement to specifically address AI usage.
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 g
PS If I am storing files on OneDrive or GoogleDrive is this permissible?
RE: Fun with HD18..rom compatible drives - MbeeTech - 27-04-2026
(26-04-2026, 06:09 PM)Graham72 Wrote: 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.
(26-04-2026, 06:09 PM)Graham72 Wrote: 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.
RE: Fun with HD18..rom compatible drives - shane.crozier - 30-04-2026
(27-04-2026, 12:07 PM)MbeeTech Wrote:(26-04-2026, 06:09 PM)Graham72 Wrote: 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.
(26-04-2026, 06:09 PM)Graham72 Wrote: 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.
(25-04-2026, 08:05 PM)greybeard Wrote: 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)
RE: Fun with HD18..rom compatible drives - Graham72 - 30-04-2026
Thanks Ewan.Claude assures me no roms are in memory.
Agents are a real concern cf :https://www.theguardian.com/technology/2026/apr/29/claude-ai-deletes-firm-database