+- 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 a 32mb CF image (/thread-1014.html)
Fun with a 32mb CF image - Graham72 - 18-04-2026
using Grok and Claude I have managed to get a working 21mb image:
MicroBee 512k CP/M Compact Flash Image — Project Summary
Background
The MicroBee 512k is emulated here under the ubee512 emulator. The system boots from a Compact Flash card image, with the ROM BIOS (version 0.58/cf8) loading a secondary bootloader (BOOT.SYS) which in turn initialises the CP/M environment across multiple disk partitions. The starting point was a working 30MB image with four partitions — A: through D: — each limited to approximately 5MB, leaving roughly 11MB of the image completely unused.
Objective
To safely expand the D: partition to use as much of the unused space as possible, while keeping A:, B: and C: fully intact and bootable.
Investigation
The project required significant detective work before any modifications could be made safely. Analysis of the MBR partition table revealed the image geometry — 123 cylinders, 16 heads, 32 sectors per track — correctly decoded from the filename
Code:
cfboot_0_58_cf8_123_16_32Early attempts at enlarging D: failed because the CHS fields in the MBR were being calculated against the wrong geometry (16 SPT instead of 32 SPT), producing partition table entries that confused the BIOS.
A key breakthrough came from the PART.COM utility output running inside CP/M, which revealed the BIOS was reporting 32 sectors per track — not 16 as initially assumed. Once the correct geometry was confirmed by reverse-engineering the original CHS values mathematically, partition table entries could be constructed accurately.
Further investigation uncovered a second constraint: an apparent signed 16-bit boundary in the BIOS or BOOT.SYS where any partition whose LBA start address exceeded 0x8000 (32,768) would become inaccessible. This explained why earlier 8MB attempts with incorrectly positioned partitions failed — D:'s start address was being interpreted as a negative number.
Testing Methodology
With the geometry corrected and D:'s LBA start address confirmed safe at 0x7600, a systematic binary search was conducted on D:'s size, testing incrementally in cylinder units (each cylinder = 512 sectors = 256KB):
- 20 cylinders (5MB) ✓ original
- 21 cylinders (5.25MB) ✓
- 24 cylinders (6MB) ✓
- 25 cylinders (6.25MB) ✓
- 26 cylinders (6.5MB) ✗
- 28 cylinders (7MB) ✗
- 32 cylinders (8MB) ✗
The ceiling of 25 cylinders is consistent with the compiled-in DSM value in the CP/M BIOS Disk Parameter Block — the maximum block number the BIOS was built to address for that partition. Exceeding it causes silent failure without any error message.
Result
The final production image retains the original filename for compatibility, with the following partition layout:
Drive A:4.73MB (unchanged, bootable)
B: 5.00MB (unchanged)
C: 5.00MB (unchanged)
D: 6.25MB (expanded)
Total
~21MB usable
All four drives are accessible, existing data on A: was preserved throughout, and files copied to D: during testing survived correctly. The expansion represents the maximum achievable without recompiling the CP/M BIOS with a larger DSM value — a significantly more complex undertaking.
RE: Fun with a 32mb CF image - greybeard - 18-04-2026
Output from part for a 1gb cf (o/p on a linux box so I could screen capture) formatted on an actual microbee under cpm
I gave up after creating 23 partitions (small attention span
) ! 6.5M/partitionBut you can only mount 4 partitions at a time.
Expert command (m for help): p
Disk /dev/sdc: 1.91 GiB, 2048901120 bytes, 4001760 sectors
Disk model: CompactFlash
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x00000000
Device Boot Start End Sectors Id Type Start-C/H/S End-C/H/S Attrs
/dev/sdc1 * 63 13103 13041 db CP/M / CTOS / ... 0/1/1 12/15/63 80
/dev/sdc2 13104 26207 13104 db CP/M / CTOS / ... 13/0/1 25/15/63
/dev/sdc3 26208 39311 13104 db CP/M / CTOS / ... 26/0/1 38/15/63
/dev/sdc4 39312 4001759 3962448 5 Extended 39/0/1 897/15/63
/dev/sdc5 39375 52415 13041 db CP/M / CTOS / ... 39/1/1 51/15/63
/dev/sdc6 52479 65519 13041 db CP/M / CTOS / ... 52/1/1 64/15/63
/dev/sdc7 65583 78623 13041 db CP/M / CTOS / ... 65/1/1 77/15/63
/dev/sdc8 78687 91727 13041 db CP/M / CTOS / ... 78/1/1 90/15/63
/dev/sdc9 91791 104831 13041 db CP/M / CTOS / ... 91/1/1 103/15/63
/dev/sdc10 104895 117935 13041 db CP/M / CTOS / ... 104/1/1 116/15/63
/dev/sdc11 117999 131039 13041 db CP/M / CTOS / ... 117/1/1 129/15/63
/dev/sdc12 131103 144143 13041 db CP/M / CTOS / ... 130/1/1 142/15/63
/dev/sdc13 144207 157247 13041 db CP/M / CTOS / ... 143/1/1 155/15/63
/dev/sdc14 157311 170351 13041 db CP/M / CTOS / ... 156/1/1 168/15/63
/dev/sdc15 170415 183455 13041 db CP/M / CTOS / ... 169/1/1 181/15/63
/dev/sdc16 183519 196559 13041 db CP/M / CTOS / ... 182/1/1 194/15/63
/dev/sdc17 196623 209663 13041 db CP/M / CTOS / ... 195/1/1 207/15/63
/dev/sdc18 209727 222767 13041 db CP/M / CTOS / ... 208/1/1 220/15/63
/dev/sdc19 222831 235871 13041 db CP/M / CTOS / ... 221/1/1 233/15/63
/dev/sdc20 235935 248975 13041 db CP/M / CTOS / ... 234/1/1 246/15/63
/dev/sdc21 249039 262079 13041 db CP/M / CTOS / ... 247/1/1 259/15/63
/dev/sdc22 262143 275183 13041 db CP/M / CTOS / ... 260/1/1 272/15/63
/dev/sdc23 275247 288287 13041 db CP/M / CTOS / ... 273/1/1 285/15/63
RE: Fun with a 32mb CF image - Graham72 - 18-04-2026
i'll give that output to Claude. Grok is sulking.
RE: Fun with a 32mb CF image - Graham72 - 18-04-2026
Yes, excellent result.
"Before greybeard's data arrived we had settled on 25 cylinders = 12800 sectors = 6400KB (6.25MB) as our confirmed maximum.
Greybeard's data pushed us to 13104 sectors = 6552KB — a gain of 304 sectors = 152KB over what we had found on our own." ~ Claude.
The limits are real and proven, anything over fails silently.
RE: Fun with a 32mb CF image - shane.crozier - 19-04-2026
(18-04-2026, 07:54 PM)Graham72 Wrote: Yes, excellent result.
"Before greybeard's data arrived we had settled on 25 cylinders = 12800 sectors = 6400KB (6.25MB) as our confirmed maximum.
Greybeard's data pushed us to 13104 sectors = 6552KB — a gain of 304 sectors = 152KB over what we had found on our own." ~ Claude.
The limits are real and proven, anything over fails silently.
Does this mean other CF's could also be used with this understanding of the mechanics?