Here's a page on my website that I'll be updating as things progress for now:
https://www.area536.com/posts/doscontainer-releases/
This URL won't change for the foreseeable future, so by all means bookmark this if you want the builds. I'm absolutely going to fold under the first C&D I receive of course, but I do honestly wonder how Archive.org does get away with what it is doing because legally it's doing the exact same thing.
Lemmings and Oh no! More Lemmings are now added (hope to add Xmas Lemmings later today). Had to write a postprocessor feature into the build framework to permit fudging the disk check copy protection in the original Lemmings. It's big missing conceptual features like this that still keep me from open sourcing the build framework right now. The framework is now close to 1000 lines of Bash code with a sprinkling of external utils for good measure and zero documentation. 
How to precisely handle CD image files is another big feature I'm still contemplating. I can add IMGSET to the VHD's, but I can't predict where the end user will store their CD images so I'm looking at making that configurable at the build level so that everyone can bake their own VHD builds: have your cake and eat it too. Once that's all done, documented and working in a STABLE way, I promise I will release the whole shebang to the world and accept outside contributions. That'll be something of a New Year's gift from me to the world though, after which I expect to return much of my focus to porting Leisure Suit Larry to the C64.. but that's a whole different story.
Why Lemmings though? Apart from the fact that it's a major classic, Lemmings got priority because my 6 year-old expressed an interest and I don't want to babysit his MiSTer use too much. So that's also a pragmatic factor for me: I'd rather teach him current Linux skills than archaic MS-DOS incantations at this point.
Bas wrote: ↑Thu Nov 30, 2023 12:39 pmLemmings and Oh no! More Lemmings are now added (hope to add Xmas Lemmings later today). Had to write a postprocessor feature into the build framework to permit fudging the disk check copy protection in the original Lemmings. It's big missing conceptual features like this that still keep me from open sourcing the build framework right now. The framework is now close to 1000 lines of Bash code with a sprinkling of external utils for good measure and zero documentation.
How to precisely handle CD image files is another big feature I'm still contemplating. I can add IMGSET to the VHD's, but I can't predict where the end user will store their CD images so I'm looking at making that configurable at the build level so that everyone can bake their own VHD builds: have your cake and eat it too. Once that's all done, documented and working in a STABLE way, I promise I will release the whole shebang to the world and accept outside contributions. That'll be something of a New Year's gift from me to the world though, after which I expect to return much of my focus to porting Leisure Suit Larry to the C64.. but that's a whole different story.
Why Lemmings though? Apart from the fact that it's a major classic, Lemmings got priority because my 6 year-old expressed an interest and I don't want to babysit his MiSTer use too much. So that's also a pragmatic factor for me: I'd rather teach him current Linux skills than archaic MS-DOS incantations at this point.
This is cool, are you using eXoDOS as the base for where you are getting your games? If so, I wonder if your process could be automated into using exodosconverter (https://github.com/Voljega/ExoDOSConverter) so you can just select the games you want and it output VHDs for each. Here is a vhd creator script that memmaker did if you need that: https://github.com/memmaker/mister_dos_ ... ter/vhd.py
I tried basing off eXoDOS but that became more of a hassle than it seemed worth because of subtle differences in many places so I abandoned that. Now I'm pulling every game off archive.org in the most authentic versions I can find, run the installer, write a boot menu for popular hardware choices and pack them up.. so the hard way. By far the most time goes into creating the boot menus because most games are different.
Bas wrote: ↑Thu Nov 30, 2023 4:58 pmI tried basing off eXoDOS but that became more of a hassle than it seemed worth because of subtle differences in many places so I abandoned that. Now I'm pulling every game off archive.org in the most authentic versions I can find, run the installer, write a boot menu for popular hardware choices and pack them up.. so the hard way. By far the most time goes into creating the boot menus because most games are different.
Out of anyone on the planet. I know this pain. 
Hello, tested some games. Lemmings 1 has strange scrambled graphics with wrong colors on my system and only pc speaker.
Lemmings 2 asks for handbook pages as copy protection and all 3 Lemmings have only PC-Speaker, should have Soundblaster Effects and with enough memory also music.
Masters of Orion doesn't start, "not enough expanded memory". SQ3 and PoP work fine though.
The ExoDOS comverter was quite useful, but I suppose automating all of it is more work than a fresh install?
Small update: my silence here means I'm working on my build framework to support versions of MS-DOS 4.01 up to 6.22 and everything in between plus DR/IBM-DOS and Win95/98 DOS in later iterations, a whole slew of mouse drivers and tweaks to those, memory management by QEMM386 as well as EMM386, proper CD-ROM support, etc. I don't always have easy access to my MiSTer, so testing happens in bursts for me. The result that's beginning to surface now is a very quick method to spit out large numbers of VHD's with all sorts of subtle differences between them, so it becomes easy to make reproducible tests to find out which one works best.
By the way, I'm not using eXoDOS because that collection is more often than not "tainted" by all manner of patches and mods that weren't part of the original games. I'm only using their zipfiles in cases where I can't find originals of the games in question. I'm also going to publish many "duplicates" in different stages of patching/expansion from the original vendor. Unpatched versions of games tend to be lost to history, even though they do have relevance.
As soon as I update my website's games page again, I'll add a column to indicate the maturity of the build so you can actually see how much testing was done on each build and if a game even works on MiSter at all. This is all a work in progress between jobs and family life though, so patience is a virtue here..
For the best versions I recommend getting Total Dos Collection and Gruby's Floppy Images pack. These will save you a lot of browsing.
CRT SCR$ Project - building a collection of high-quality photos of CRT displays
CRT ART Books - retro-gaming books with authentic CRT photos
I may be going just a little bit overboard here, but my framework now eats YAML instead of raw Bash for game configuration. I'd say something like this looks reasonable for human authors to create:
Code: Select all
metadata:
title: Quest for Glory I
publisher: Sierra OnLine
year: 1989
comment: Original EGA version
diskname: qfg1.vhd
disksize: 10
distfiles:
- name: qfg1.zip
checksum: a470936fed52d6e4cffd0ece2bbc3a9c50ffe0388b9ca89d9edaad90455aac39
drivers:
- CHOICE
- CUTEMOUSE
gamefiles:
- QFG1
OS: MSDOS500
AUTOEXEC: |
PATH=C:\DOS
cd C:\QFG1\DOSK8S
RUN.BAT
CONFIG: |
..as opposed to
Code: Select all
DISKNAME="qfg1.vhd"
DISKSIZE=10
DISKLABEL="QFG1"
declare -A DISTFILES=(
["qfg1.zip"]="a470936fed52d6e4cffd0ece2bbc3a9c50ffe0388b9ca89d9edaad90455aac39"
)
DRIVERS=(
"CHOICE"
"CUTEMOUSE"
)
GAMEFILES=(
"QFG1"
)
OS="MSDOS500"
AUTOEXEC=$(cat << EOF
PATH=C:\DOS
cd C:\QFG1\DOSK8S
RUN.BAT
EOF
)
CONFIG=$(cat << EOF
EOF
)
..and in other news I can now do builds for MS-DOS from version 4.01 up to 6.22 and every official release in between. Gearing up quite nicely for a full release by the end of the year. Oh and I got Windows 3.0 and 3.1 to run as well, but there's a huge number of moving parts in there so that's.. a thing.. for later. My memories of WIN.INI and SYSTEM.INI are a bit rusty.
Bas wrote: ↑Thu Dec 14, 2023 10:15 amI may be going just a little bit overboard here, but my framework now eats YAML instead of raw Bash for game configuration. I'd say something like this looks reasonable for human authors to create:
Code: Select all
metadata: title: Quest for Glory I publisher: Sierra OnLine year: 1989 comment: Original EGA version diskname: qfg1.vhd disksize: 10 distfiles: - name: qfg1.zip checksum: a470936fed52d6e4cffd0ece2bbc3a9c50ffe0388b9ca89d9edaad90455aac39 drivers: - CHOICE - CUTEMOUSE gamefiles: - QFG1 OS: MSDOS500 AUTOEXEC: | PATH=C:\DOS cd C:\QFG1\DOSK8S RUN.BAT CONFIG: |..as opposed to
Code: Select all
DISKNAME="qfg1.vhd" DISKSIZE=10 DISKLABEL="QFG1" declare -A DISTFILES=( ["qfg1.zip"]="a470936fed52d6e4cffd0ece2bbc3a9c50ffe0388b9ca89d9edaad90455aac39" ) DRIVERS=( "CHOICE" "CUTEMOUSE" ) GAMEFILES=( "QFG1" ) OS="MSDOS500" AUTOEXEC=$(cat << EOF PATH=C:\DOS cd C:\QFG1\DOSK8S RUN.BAT EOF ) CONFIG=$(cat << EOF EOF )..and in other news I can now do builds for MS-DOS from version 4.01 up to 6.22 and every official release in between. Gearing up quite nicely for a full release by the end of the year. Oh and I got Windows 3.0 and 3.1 to run as well, but there's a huge number of moving parts in there so that's.. a thing.. for later. My memories of WIN.INI and SYSTEM.INI are a bit rusty.
Fantastic declarative solution! I'm looking forward for the tool release, thanks for your precious work!
Is it worth trying FreeDOS with any of these games? I heard the latest version is way more compatible than the previous version...
Last tasks before initial release:
Functionally it looks like we have lift-off on version 0.1 of DOSContainer. Now writing unit tests is crummy business, but fortunately we have generative AI to do a lot of the boring grunt work on that nowadays. Things are looking good for Christmas!
Things are working better and better, thanks for that handy tool! But, please!, add the parameter /TESTMEM:OFF to himem.sys in config.sys
...already checked, tested and can confirm that it is working with a significant boost. Yikes!
I see that you have changed "sed" to "gsed". I'm using ArchLinux and there is no gsed; if I change that back to sed in framework.sh, everything is still working...so what's the point of gsed?
FreeBSD and its distinction between sed and gsed, which is niche but is also how MacOS works.. which is less niche. Can you report an issue for it? Some tools need a slightly more robust detector.
There's a more serious bug right now that kills the fetching of distfiles for me completely.. that code could also do with some more sanity.
Sed detection works. Found some boilerplate in an older script of mine that I could adapt. Now back to the other bugs.. aggravating how Arch does add gawk for AWK.
Kudos to @RealLarry for creating a whole bunch of game configurations! They're in the repo:
Thank you for the additions. 
I'm getting an error building Terminal Velocity tveloc.yaml
Checksum verification failed for tveloc.zip
Thanks for reporting. This is fixed now. Must have been a problem with in (my) file cache.
Are the already built containers downloadable somewhere or is the project designed so that everyone has to build their own containers?
For now you build your own. I'm still considering how to connect GitLab pipelines to the repo and have automated builds from there. If you know GitLab CI and/or Docker welk, raise your hand please.
I have to take a deeper look, but I'm afraid not many ppl (incl. me) are able to do this
