VOGONS


First post, by Serious Callers Only

User metadata
Rank Member
Rank
Member

So, i'm trying to make instructions to make it easier for 'normal users' to use dosbox to run windows 95 games in linux (yes yes heretical i know).

Anyway, a major complexity of this process is creating new image files and attaching them to windows as readable. Assume dosbox is patched with the 'small' patches for large hd images without imgmake (which wouldn't solve the fdisk requirement, which is what i really want to get rid of).

It normally requires creating the image (with dd or boschs or something else), then imgmounting it in dosbox 'raw' with the -size parameters (which are hard to get), then run windows (possibly in another drive) or a bootdisk, and fdisk it with or without being vfat (in windows 95), creating the partition and finally rebooting and formatting to see the empty space and drive letter.

Anyway i thought i could use mkfs.fat to remove the need for fdisk and that first windows boot, but i need help to translate the created image properties to a usable 'size' for imgmount.

I'm using it like this - -C to create the file, -F32 to create a fat32 (it might be that this is a different thing and i should always use -F16 even when i want the max 8gb img that patched dosbox supports?), -v for verbose (to get the -size parameters) and the expression at the end is the number of blocks on the image for 50 mb on host (which will be different on usable mb on guest, because the filesystem doesn't use 100% of the file space for free space and the definition of megabyte changed over time from base 2 to base 10, now a 'mb' is 1000 bytes, while before it was 1024):

$ mkfs.vfat -C -F32 -v a.img $(( (50 * 1000) ))
mkfs.fat 4.1 (2017-01-24)
a.img has 64 heads and 32 sectors per track,
hidden sectors 0x0000;
logical sector size is 512,
using 0xf8 media descriptor, with 100000 sectors;
drive number 0x80;
filesystem has 2 32-bit FATs and 1 sector per cluster.
FAT size is 769 sectors, and provides 98430 clusters.
There are 32 reserved sectors.
Volume ID is a3b9dbe6, no volume label.

I'm _pretty sure_ that those properties don't map to imgmount -size parameters without calculation.

'logical sector size is 512' appears to map to 'bytes per sector'
but i believe 'sectors per cylinder', 'heads per cylinder' don't map to '32 sectors per track', '64 heads'

and who knows what 'cylinder count' maps to.

is it hopeless to use mkfs.fat for this and i always have to use boschs or dd, then use the windows fdisk for this? Can you think of any linux alternative that can support the CHS at (1023/255/63) max scheme of the patch and calculate those parameters easily while outputting a formatted ready to use image file?

Last edited by Serious Callers Only on 2020-04-28, 07:44. Edited 2 times in total.

Reply 1 of 7, by Zup

User metadata
Rank Oldbie
Rank
Oldbie

Have you tried using parted? It seems that it can operate over files, so you could:
- Create a disk-image using dd (dd if=/dev/zero of=disk.img bs=4*17*512 count=617 should create a disk image of a 617 track, 4 heads and 17 sectors HDD).
- Use parted mklabel msdos to create a partition table.
- Use parted mkpart to create a partition.
- use parted set to set the boot flag.

Note that there are missing two important steps:
- I don't know if a bootable master boot record is placed when doing the mklabel part . If not, I guess you should use mbr.bin from syslinux-common package (but be careful to NOT truncate your newly created disk image).
- parted won't create a filesystem on your partition, so you'll have to make one. But keep in mind that your filesystem starts where your partition starts (on older systems, it used to be at the first track; on newer systems it is counted by Mb) so you'll have to skip some blocks.

I have traveled across the universe and through the years to find Her.
Sometimes going all the way is just a start...

I'm selling some stuff!

Reply 2 of 7, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

mkfs.fat is not going to work correctly since when used with files (instead of devices) it just makes up the heads/sectors per track, which may be completely different from what you want/what the partition table uses (if you actually put one on the image before trying to add a partition/filesystem; if not, good luck booting it!).

Reply 3 of 7, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Is providing premade images an option? AFAIR these empty images compress ver nicely...
But I get that scripting everything is better.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 4 of 7, by Serious Callers Only

User metadata
Rank Member
Rank
Member

This is basically for simplifying the horrible 'readme' that appears when you install the ppa and for making the workflow easier. About 4/5ths of that are me getting lost in explaining how to create a imgfile and fdisk and formatting it with the windows native tools, to the point i forgot about how to explain linux mounting the disk to be able to transfer files (you have to skip the boot sectors).

A archive link with several 0 sized ready to use files in a zip would probably be simpler, but the scale between 'requires a simple 50 mb' and 'requires 5.5 gb (Black Dahlia) or 'requires the maximum 8,4 gb' (nothing yet) has a lot of fixed steps. A not so smart/cautious person that just unzipped the whole dir is setting themselves up for suffering.

There is the concept in linux of 'sparse file' which is a file where the zero ranges are not actually 'filled' in the filesystem (not all filesystems support it but all modern ones do). Zip does not appear to support it, but tar does - https://linuxgazette.net/174/misc/lg/compress … heir_holes.html

I guess what i should do instead is just create a git repo with a readme.mk just linking to a bunch of tgzs of single (already formatted and setup as 'd' ) image 'sparse' files on the range [20mb -8.4gb] and link it there and start writing about the more important process to install games in wine and transfer their files and registry entries to the img the user downloads.

Create equation to given a 'size' by the user calculate the cylinders it will have on the CHS [1-1023, 255, 63] scheme, then fallocate a bunch for a range of increments of 50mb for [50-500]mb then another bunch for increments of 500mb for [1, 8.4] gb and then painstakingly fdisk all of them, reboot and format them 'quick' and hope the 'sparseness' doesn't make them balloon... I may die if i try this. It would be 'tolerable' if i could use mkfs.fat and a script loop. But that goes right back to what jmarsh said of mkfs.fat not respecting the CHS. And if i could do this script, i could do a script in the package to create any size image file, so the git repo wouldn't even be needed.

It's unsettling this is not a solved problem already. Can i mount a sized image file as a block 'device' and use mkfs.fat on it to make it try to respect a CHS instead of assigning one it wants? Edit2: no.

edit: change the link to the correct one.

Reply 5 of 7, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image at variable sizes or simply documenting the procedures in readme or writing up a scripts? Frankly, DOSBox disk image support has been leaving something to desire. QEMU comes with a number of handy tools to deal with disk images and support raw format that can be used by DOSBox. If you only care about Linux, then you can also consider qemu-nbd for mounting disk image with partition and manipulating the filesystems directly without any emulators. Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

My workflow looks like this:

  • Create raw image with dd using precise CHS geometry
  • Boot from Win98SE.ISO in QEMU with the disk image. Select MS-DOS with CDROM support.
  • Inside QEMU, FDISK, reboot QEMU, FORMAT C: /S. XCOPY entire WIN98 folder from CD to disk image.
  • On Linux, use parted/fdisk to remove LBA flag. On Windows, boot up a Linux VM on QEMU to do the same.
  • Add the disk image to [autoexec] in dosbox.conf and boot it in DOSBox. Start Win98 installation with SETUP /pi /nm.

Reply 6 of 7, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
kjliew wrote on 2020-04-29, 20:08:

Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

MS-SYS to create the proper MBR.
http://ms-sys.sourceforge.net/

Write IO.SYS and MSDOS.SYS (in that order) to the filesystem.

All hail the Great Capacitor Brand Finder

Reply 7 of 7, by Serious Callers Only

User metadata
Rank Member
Rank
Member
kjliew wrote on 2020-04-29, 20:08:
Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image a […]
Show full quote

Still trying to figure out what your end goal is to do all this. Are you looking for dynamically creating Win95 bootable image at variable sizes or simply documenting the procedures in readme or writing up a scripts? Frankly, DOSBox disk image support has been leaving something to desire. QEMU comes with a number of handy tools to deal with disk images and support raw format that can be used by DOSBox. If you only care about Linux, then you can also consider qemu-nbd for mounting disk image with partition and manipulating the filesystems directly without any emulators. Since there is no easy way of doing "SYS C:" outside of DOS, I would just prepare the disk image using DOS in QEMU to boot with DOSBox.

My workflow looks like this:

  • Create raw image with dd using precise CHS geometry
  • Boot from Win98SE.ISO in QEMU with the disk image. Select MS-DOS with CDROM support.
  • Inside QEMU, FDISK, reboot QEMU, FORMAT C: /S. XCOPY entire WIN98 folder from CD to disk image.
  • On Linux, use parted/fdisk to remove LBA flag. On Windows, boot up a Linux VM on QEMU to do the same.
  • Add the disk image to [autoexec] in dosbox.conf and boot it in DOSBox. Start Win98 installation with SETUP /pi /nm.

I want to avoid the need for the user to boot into windows9x, including to reboot after the format to create a harddrive. I don't necessarily want this to happen for OS install purposes, but it'd be a nice bonus (my-sys looks super useful for that), but the main aim is to create a script for given a number of mb create a drive already fdisked and formated with FAT16 or FAT32 with 1 partition, and output the geometry (for imgmount) and the command to mount it in linux (to copy over files while skipping the MBR), and the image would only vary in cylinders in [0-1023, 240, 63] CHS, and preferably be a sparse file.

The way i use images is to have the OS (FAT16) be separate from the game (FAT32), to share the OS (and manipulate the autostart from dosbox [autoexec]). I only switch the game drive and modify which game is being autostarted (well i also have a copy on write script for the game image and ramdisk the OS image but that is unnecessary detail).

So a bunch of confusing intructions, caculate the cylinders, dd, boot into windows, fdisk, reboot, format, mount drive in linux and copy over game go away and become 'only' the expanded version of the last:

'use script to create drive, mount it in linux with this command that skips the MBR, mount the dir as drive in wine, install game there in windows 95 mode, install whatever no-cd hacks the game has, find the registry entries of the game and export it, umount, mount in dosbox, boot, try game and if it doesn't work import registry entries'.

This is the most important to be able to use games since dosbox windows doesn't have support for external cds passthrough (mounted or with cdemu), and is more than enough work for a hapless user.