Progress on 1.00 release

📅 2025-06-16  · ✍️ Bas v.d. Wiel  ·  🏷 announcement

The good news is that the codebase as built from the main branch is feature complete. It works, but I haven’t announced it as 1.00 yet because the project hosting infrastructure is not yet up to standards. Apparently not all URL’s in the example content are reachable for everyone and I have work to do on that. Work, the professional kind, is unfortunately getting in the way of this so a final 1.00 announcement will have to wait. You want to test? Read on!

Some more detail on progress then. Time permitting, I’m still coding on DOSContainer itself and working on its architecture. As it turns out, it’s very easy to support an operating system that only knows about a single kind of floppy and nothing else. Many code paths were hard-coded on that assumption, but they’ll need to become very dynamic indeed in the near future as more and more operating system variants come into play.

The releng/1.10 branch in the code repository is where all the work culminates up to a future release 1.10 for DOSContainer. It’ll have support for a few important items:

• OS-selection based on what HwSpec and Manifest contain, the algorithm for that changed from 1.00 to 1.10 but the file formats remained identical.
• Support for 320KB floppy disks: this is where many of the dynamic code paths come from. Supporting a single entity is simple. Supporting two is hard. The good news on this one is that this effort only needs to be expended once. It doesn’t matter all that much whether DOSContainer supports two or two dozen different types of disks. After the code paths become conditional, the rest is all a matter of entering the correct data to define new disk types.
• Support for IBM PC-DOS 1.10. Not that much changed between 1.00 and 1.10 from a disk generation perspective, but still: it warrants its own FAT12 serializer implementation. And although there is a lot of repetition in that code between 1.00 and 1.10, this concept is proving its value.

So you want to test?

Awesome! And go right ahead. Assuming you have a working Rust toolchain on your system you can simply pull the main branch from the Core repository and build it by running: cargo build --release in the project’s root. The folder target/release will then contain your finished executable ready for use.

Don’t like building Rust? There are automated builds from the main branch available online over FTP. Check the anonymous FTP server ftp.area536.com/doscontainer/builds and pick the ZIP file with the highest build suffix. Whenever something changes in the main branch, a new build will be uploaded here a few minutes later. The ZIP archive contains builds for assorted Linux versions and Windows. Mac builds will become available sometime later, but those are not too high on my priority list right now. If you really want one, drop me a note on the MiSTerFPGA forum.

A bit on Museum Quality

The stated objective for DOSContainer is to emit disk images that are of museum quality, indistinguishable from the real deal from back in the 1980’s. The currenct code base is up to the point where it follows the documented workings of PC-DOS 1.00 to the letter. As it turns out, PC-DOS 1.00 does something very weird when writing files using the COPY DOS command.

Any file to be written, gets cut up into cluster-sized chunks. In PC-DOS 1.00 those clusters are 512 bytes each, so we get chunks of 512 bytes. There’s usually a last cluster that won’t be completely full because the file size is not an exact multiple of 512. In that case the root directory helps us by recording exactly how many bytes the file takes. Any ‘slack space’ in the last cluster will, thus, be ignored by any sensible application.

As it happens, PC-DOS 1.00 does not handle the slack space very well. After COPY is done writing the actual file, it appears to just dump some random part of memory into the rest of the cluster to fill it up to the required 512 bytes. These random bytes will be ignored by any software that reads the file, but they still show up on disk. This, in my eyes, is a massive bug in DOS and a security issue. Not that that’s very relevant anymore, but it’s a sign of sloppy coding from Microsoft.

DOSContainer does not inject gibberish bytes into the slack space between the end of a file and the start of the next cluster at this point. The primary reason for that is because it’s completely non-functional and undocumented, and the second is that those bytes are not actually completely random. They contain parts of what seems to be the PC’s RAM at the time of performing the COPY operation. Now until I figure out whether the creation of a file always generates these weird bytes in slack space or it’s just an artifact of a badly coded COPY command, I’m holding off on trying to implement it. If it’s just COPY that’s doing this, then I’m leaving the behavior out. If it’s DOS core routines, I’m going to need to figure out exactly what is happening so I can at least implement this part to be bug-for-bug compatible with DOS, and thus keep my end of the museum quality promise.