MiSTer FPGA Forum

Oh boy.. Adding PC-DOS 1.10 was a breeze. DOSContainer now supports 1.00 and 1.10. Next up: the actual CLI and the manifest file format, so that I can finally give all of you something to play around with.

The Docker-ish layered approach is now also validated. I can mix and match the two supported DOS versions, the game distribution files as well as the IBM BASIC middleware layer. That's already 4 permutations for a single simple BASIC game that are dead-easy to build. Wait 'til I add GW-BASIC to the mix. Good news for collection builders!

Bas wrote: ↑Tue Nov 05, 2024 4:04 pm

Oh boy.. Adding PC-DOS 1.10 was a breeze. DOSContainer now supports 1.00 and 1.10. Next up: the actual CLI and the manifest file format, so that I can finally give all of you something to play around with.

The Docker-ish layered approach is now also validated. I can mix and match the two supported DOS versions, the game distribution files as well as the IBM BASIC middleware layer. That's already 4 permutations for a single simple BASIC game that are dead-easy to build. Wait 'til I add GW-BASIC to the mix. Good news for collection builders!

This is fantastic, you're building the gold standard to let people create in a breeze their collections year by year and DOS version by DOS version, again THANKS!

So IBM PC-DOS 1.00 and 1.10 have fixed boot sectors, they're all identical. Except for 1.10 where a few bytes at the start differ depending on whether the floppy is single or double sided. Easy enough and fairly well-documented (still a small todo on my end). And then other bytes change that NOBODY talks about anywhere I could find. Not even thestarman at pcministry.com. While this makes me a little bit sad, I'm noting it as a more significant todo for later and moving on.

Code changes for PC-DOS 2.00 are going to be a lot more extensive. The whole OS got a revamp with 2.00: subdirs, volume labels, hard disks, 180/360KB floppies.. the works! Many more code paths, many more tests to write.

So first: the manifest format and a CLI. At least those should be ready before Christmas

You want builds? I got builds again. DOSContainer is FAR from ready for prime time, mind you. I'm just barely ready to give you all something to play around with and test. A few points:

1. DOSContainer's old builds were all moved to an archived location. You can still get them, but please don't. They probably won't work anymore anyway.

2. New builds live at ftp://ftp.area536.com/doscontainer/builds/. The current build as of this writing is nr. 126. Every build comes with a GPG signature to validate that it came from me. Windows Defender and other antivirus may balk at DOSContainer because of what it does: fudge around with bootable disk images, write strange old code to funny places.. that's to be expected from a tool like this.

3. There are no docs yet because the manifest format is not final yet. You read that correctly. DO NOT create a lot of new manifests. It'll be a waste of time to start building a collection based on the current software. It's just here to prove that I'm still on the case, and for everyone to test out what's cooking.

So what is cooking??

DOSContainer supports IBM PC-DOS 1.00 and 1.10 completely now. That's to say: you can create floppy images that are 160KB or 320KB in size. These images will be bootable on an IBM PC and probably only an IBM PC, I haven't tested anything on compatibles. The should, however, be 100% bit-for-painstaking-bit identical to what IBM would have done in the early 1980's so they are indeed what I like to call 'museum quality'. Any deviation is a bug to me, so please report them.

Code lives here: https://code.area536.com/DOSContainer for now because I dislike GitHub and I dislike GitLab even more. Want to collaborate? I'm open to considering a move to GitHub at some point..

There's also a repository there called 'manifests'. It contains a single manifest from an ancient text adventure game named Intercept. I use it for testing. You can use it to gather specs on the YAML format.

Right next to it is a repo named 'manifest' without the extra 's'. That's the current sad state of affairs of Rust code that handles the YAML input. If you can read rust, you can gather the inner workings of the YAML format from there. Lots of old cruft in there. This will get completely scrapped and replaced with something decent.

That is, in fact, the next step for me. Strip down the manifest format so that it does what PC-DOS 1.00/1.10/2.00 requires, then start building library support for PC-DOS 2.00. Lots of new features in 2.00, so that'll take a while.

Intercept boots from a 180KB PC-DOS 2.00 disk now. Most of my previously hard-coded settings broke because of the code paths need to become dynamic, but nothing out of control. Previously fixed offsets depend on the sizes of other things now so I have to calculate stuff. Any builds my CI spits out after 131 are probably quite broken indeed. If you want to play with PC-DOS 1.00/1.10 you should only use build 131 and no others. I do feel like I finally got the right approach. Time for very meticulous automated unit testing or I'll go crazy chasing regressions.

Build 134 will drop in a few minutes. It properly handles the BIOS Parameter Block and media descriptor on PC-DOS 2.00 and allows making 180KB/360KB floppies opening up this much more mainstream format. No support for subdirs yet though. IBM/MS snuck in another byte, outside of the BPB, where it indicates how many sides a floppy has. Naughty!!