• Please review our updated Terms and Rules here

Creating an extremely small bootable (PC) disk image

H

Hak Foo

Experienced Member
Joined
Jul 18, 2021
Messages
218
So I now have the ability to boot off of a ROM-disk, but precious little ROM space. I found one pre-prepared 63k disc image, but it's not the content I want. It also uses a FreeDOS kernel, which consumes 38k of the space for KERNEL.SYS before we even look at payload, so I'm sort of interested in seeing if, say, the open-source DOS 2.11 release (which looks to be closer to 22k) can do better.

If I try just formatting a disk image file in 86box, the MS-DOS and FreeDOS format commands throw up their hands if specified a geometry below 160k.

I tried the mformat command in mtools, and that supports a smaller geometry (i. e. 10 tracks, 9 sectors, 1 head), that tools recognize as a FAT disc image, but if I try to mount it as a drive in 86box (i. e. to make it bootable), again, DOS seems to freak out.

Were there any utilities "in the era" that allowed producing a more flexible geometry? I could imagine someone *wanting* to format a disc with only a sliver of the space available to get some mileage out of bad, but expensive, media, or to create a tiny disk image for some embedded device.


The source for the 63k image mentions in passing that it was a snapshot of a RAM disk-- maybe that's a more flexible way to get to a bootable arbitrary-size image.
 
You couldn't just truncate a 160K image you have partially filled, and set up your ROM disk such that int 13h calls beyond the truncated portion of the disk just return errors?
 
FWIW it might be worth taking a look at the BIOS ROM image for the Tandy 1000 HX for inspiration. That machine had 128k of ROM running from E0000 to FFFFF, which was divided up like so:

E0000-EFFFF: 64k of embedded resources for the special version of DeskMate it ran. (It still needed to start the program from a floppy, but it could swap for a data disk once running.)
FC000-FFFFF: 16k Phoenix BIOS customized for the Tandy 1000 and…
F0000-FBFFF: (The relevant part) 48k holding an incredibly simple ROM disk driver in the first (if I recall correctly) 0.5k and the rest composed of a disk image holding a minimal DOS 2.11 startup disk similar to what you’re looking for.

A few years ago there was a thread dissecting this driver and image. My recollection is the driver itself is structured similarly to a RAMDISK, and likewise the disk image “looks like” a snapshot of a RAMdisk. (If you extract it it’s mountable with standard FAT filesystem tools; I have no idea what its virtual geometry is.) I think it’s been demonstrated that the driver works as a normal BIOS extension and can be booted on a regular PC, you might try it on your hardware just for laughs.
 
@Makefile, I tried that earlier and had some problems, which I suspect trace themselves to:

1) I was trying to debug by running the code in 86box, and forcing it in by loading the ROM as "the ROM intended for some random XT-IDE card". This works well enough for some things (restructuring output on the bootloader itself), but it doesn't map the huge volume of ROM space this task needed, so when it hit DOS, it would start loading in parts of the ROM that weren't mapped and died. This was fixed by actually moving to real hardware which could populate whole ROM where I wanted.

2) The part of the ROM disc driver that did CHS -> address mapping needed to be tweaked; it was assuming 2 heads in calculating offsets, so it probably would have an easier time dealing with a "360k" image than a "180k" one. When I switched the calculation to assume only 1 head, it started to work with the truncated image.

Gave it another shot, now that I at least wasn't chasing dragons in part 1) process that worked for real hardware, and it does boot.

Once I had a bootable and otherwise empty 180k image, It's possible to stuff the data I want on somewhat easily with mtools, and then crop it to size and run with it. It's not *elegant* by any means-- no guardrails to keep you from fitting 90k in the image and then cutting it down to 70 and being confused when random stuff happens. However, I did achieve my main goal: basically a joke based on the description on https://mindbleach.itch.io/8088-tetris-attack -- "The only PCs this won't kick ass on did not have video." He neglected machines without *disc drives*, but now we're here. Built a 74k disk image containing a minimal DOS 2.11 boot, an autoexec.bat that runs the program, and the program itself, and you can now play without having to bend the knee to the fatcats at Tandon or Shugart Associates. :D :D :D
 
Hak Foo said:
Were there any utilities "in the era" that allowed producing a more flexible geometry? I could imagine someone *wanting* to format a disc with only a sliver of the space available to get some mileage out of bad, but expensive, media, or to create a tiny disk image for some embedded device.
Click to expand...
I think the solution for most people for getting mileage out of bad media in those days was to format it normally and let the format tool identify and mark the bad blocks, or in some cases to type in some bad block information which was on a label attached to a hard drive (I'm not sure what the process was for filling in that information, did they come from the factory like that, or did you run a disk tool to figure it out and then write it on the label for your own future reference?).

I did a Google search for FAT bad blocks and the first result was a man page for mbadblocks (part of mtools) which might be helpful. As well as the usual scheme of it trying to figure out which blocks are bad by read testing, you can optionally give it a list of sector or clusters to mark as bad, so maybe you could use this to give yourself some guardrails? Of course you'd still have a FAT which is larger than would be necessary if you could have the smaller filesystem you really wanted, so the RAM disk solution sounds nicer although presumably more work.

Wikipedia's page for FAT gave me the answer I was really looking for:
Clusters containing bad sectors were marked unusable with the reserved value 0xFF7 in the FAT.
Click to expand...
 
It seems like the practical way to let this go is to just make a "180k" image that happens to roll off into oblivion if you seek past the actual available space, and just manually make sure you keep everything simple and defragmented.

This works without any tricks of convincing the system to handle an odd set of disc dimensions, but at the cost that it will still say an ambitiously high "bytes free" when you take a directory listing. The ROM-Disk INT13 handler rejects writes so we're not in too big of a risk zone.
 
I tried out mbadblocks, it turns out you don't even have to give it a list of bad sectors/clusters if the file is already truncated (conversely, when I tried to give it such a list when the file wasn't truncated, it segfaulted, so I don't know what is going on there):

Code: 
$ mformat -f 160 -i test.img ::
$ truncate -s 90K test.img # I can't remember what size you said but hopefully it doesn't matter
$ mbadblocks -i test.img ::
Bad cluster 175 found
Bad cluster 176 found
...
Bad cluster 314 found
$

After this, I ran MS-DOS 5 in QEMU:

Code: 
A:\>chkdsk b:
Volume Serial Number is 4DCE-39FB
 
    160256 bytes total disk space
       512 bytes in 1 user files
     71680 bytes in bad sectors
     88064 bytes available on disk
    
       512 bytes in each allocation unit
       313 total allocation units on disk
       172 available allocation units on disk
...

Looks like this gives a working available disk space count - and probably prevents accidentally using that space - at the cost of making it look like something is wrong with the filesystem.

By the way, this thread sounds like the continuation of an existing project of yours, is there any chance you could link to a prior post for context? I'm quite curious about where the ROM image is going!
 
NFORMAT will let you format to almost any disk geometry and size. The catch is you need DOS 3.3 (perhaps 3.2) or later to read any non standard format. DOS 1.x, 2.x and early 3.x used a geometry lookup table based on the media byte in the boot sector, so they only recognized 160k, 180k, 320k, 360k, and so on. On the flip side, it is possible to edit the lookup tables in the DOS binary to make it recognize other formats. I've booted DOS 2.11 on a 1.44mb formatted floppy by doing that.
 
doshea said:
By the way, this thread sounds like the continuation of an existing project of yours, is there any chance you could link to a prior post for context? I'm quite curious about where the ROM image is going!
Click to expand...
It's the intersection of two existing projects.

I built a memory board that used a cheap 128k flash for the BIOS. Originally, I just enabled 64k of that but it seemed a waste, so I eventually came up with a scheme to map all that extra flash, and needed something useful to do with it.

The most useful thing I had handy was an Option ROM that provided INT 13 (disc) services, so I took its skeleton and made a simple ROM-disc system out of it

So basically I got to a place where my system has 128k of ROM at E0000. The lowest 2k is reserved for the ROM-disk support firmware, then 90k for a disc image, then a series of other options (HD floppy, CH375/6 USB drive support, clock card option, and XT-IDE), and the last 8k is an actual BIOS. If we force "boot ROM BASIC", instead of the usual "No ROM BASIC - system halted" failure, it pretends the 90k chunk of ROM is drive A and boots a DOS 2.11 image with EDLIN, DEBUG, and a Tiny BASIC. Not that useful, as DOS 2.11 doesn't know about high-density floppies or hard discs bigger than like 16Mb, but fun as proof of concept.
 
You must log in or register to reply here.
Back
Top