Errius wrote on 2024-06-13, 23:03:BOOT is for bootable disks, which often don't have a DOS filesystem. IMGMOUNT is for DOS disks and won't work with most bootable […]
Show full quote
BOOT is for bootable disks, which often don't have a DOS filesystem. IMGMOUNT is for DOS disks and won't work with most bootables. Typically you would use one or the other, not both.
(yeah, 98% of my experience and knowledge is based on DOS starting with the 386 I built out of spares back in 1994 I was only 12 years old!)
What error message do you get when you run BOOT DISK.IMG -L A ?
(I wasn't keeping good notes, just that it couldn't boot.) I first tried BOOT disk.img -l a (the a drive was no mounted or IMGMOUNTed at the time.
I read the wiki and it seemed from the info that it had to be IMGMOUNTed first. THAT worked.
If I just use BOOT disk.img -l a, I get "unable to boot off of drive A"
No errors about opening the image, so the assumption is the img is good.
IMGMOUNTING it first worked.
The test image is Infocom's text adventure Cutthroats
(Note that BOOT, MOUNT and IMGMOUNT look for images (1) in the DOSBox root directory, (2) in the DOSBox program directory. Relative paths are relative to these two locations.)
I understand the relative paths to the working directory of dosbox. I got into the habit as it is easy to organize and makes it somewhat portable. Like my father, who is now retired and has free time again and wants to play some games we got in the mid 90's that he never finished or just wants to play for nostalgia. I made a directory he could easily get off my file server (no longer have due to a cat jumping on it and knocking it over. Ever experience the terror of 6 x 8TB RAID platter drives hitting the floor, which housed a carefully maintained movie and music server, local file server intended as a digital store of all my physical media. VHS rips, DVD rips, sourcecode snippets for a game I was star ting to actually make into something. 🙁
example;
D:/
├─ DOSBox/
│ ├─ dosbox.exe
│ ├─ dosbox.conf
├─ C_HDD/
GAME1/
GAME1.EXEorBATorCOM
I can easily 7zip the GAME1 folder and delete it, free up some space and copy the 7zip to a large 12TB platter drive I have to store and free up space on the SDD I use for modern games and everyday use. this way I can juast decompress the folder into the C_HDD folder and ready to ply instead of mounting images and going though the install process every time I want to play "that one game".
I plan on the same with booter images.
So, what works for me, unless a future problem can be seen, is this:
In the C_HDD folder, I have
BOOTER GAME/
├─ GAME.BAT
├─ disk_a.img
├─ disk_b.img
GAME.BAT contents
IMGMOUNT -u a **ensures A is available
IMGMOUNT -u b **ensures B is available
IMGMOUNT A ".\disk_a.img" -t floppy **game disk A or booter
IMGMOUNT A".\disk_b.img" -t floppy ** game disk B or save file disk
BOOT -l a boots game
Using the same Cutthroats booter image as mentioned;
This, so far works. It allows me to reference in my batch menus to see that game's BAT and follows my current folder organization practices.
So far, I need to just find a way to restart DOSBox or start it back up when the game quits to go back to the batch menus. That I am sure I can figure out.
Not sure where to begin as the test booter I am using is an infocom text adventure and doesn't "drop to a shell" like games I am familiar with
As this "works" I can run that BAT and it mounts the images, then boots off A, plays the game, ;lets me save progress
I shut down DOSBox anf run the BAT again and I am able to resume my progress as the game saves to the B drive/image
I just originally thought BOOT was enough. relative or direct paths to the img file didn't work.
I even used a boot image for DOS and it wouldn't BOOT till I IMGMOUNTed it first. That image IS good, tested on real floppy writer on real a couple real machines.