5

I have some PC booter images from new homebrew games by this Japanese developer: http://inufuto.web.fc2.com/8bit/

As I know, those images have a 360k size, and are self-bootable by the old IBM PC (8088, 8086), but they can’t be read by MS-DOS, nor do they follow the FAT standard.

I would like to play those simple games on my Book8088, which is a new PC-XT in a laptop form-factor that it is being sold on Aliexpress.

I was thinking about using the dd command from Linux – I use Mint, BTW – to write those images in some kind of raw format to a USB flash drive.

Maybe anyone would have an example on how could I do such a thing. Sorry if this question sounds silly, I’m still learning bash and Linux in general.

Thank you very much!

12
  • 5
    Though this question is phrased to apply to a newly-made XT device, and involves USB, and so on - it seems to be to be of general interest to those retrocomputing fans who are interested in running really raw retro- software on old PC gear. Just my 2cents before any OT VTC.
    – davidbak
    Commented Jan 17 at 17:34
  • This is not a retrocomputing question, the hardware is new and must have manuals how to run something from USB sticks. Modern items like this could very well just mount and read floppy image files from USB file system. Other than that, how to use dd is an unix question and Mint includes manual pages for dd, did you try "man dd"?
    – Justme
    Commented Jan 17 at 18:32
  • 7
    This came from Unix.SE, and since the answer is probably specific to the modern Book8088, technically off-topic here — although IMO it’s only relevant for people actually trying to retro-compute, which is what this site is supposed to encourage. Commented Jan 17 at 18:50
  • You can just write them directly to the drive, starting at sector zero. I see the bootable images lack the 55AA boot signature, so you would need to insert that as well (fortunately, there is room for it) But that would be pretty wasteful, as it would only allow booting a single game off a flash drive that could contain so much more. A more interesting answer would involve ripping them into COM executables loadable from DOS. Which seems quite feasible, actually: all the games use pretty much the same loader, and there is very little segment register usage. All they need is a relocator. Commented Jan 17 at 20:00
  • 1
    @IgorPeruchi short complaint, nothing hostile: we really did not "kick you off" UNIX.SE, we said "hey, the answer to your question involves intense knowledge on retrocomputing platforms that are unrelated to UNIX/Linux, maybe ask this on retrocomputing.SE instead"! I went as far as getting one of these images and trying to specify it as boot floppy image for an emulator, before even writing that comment! Commented Jan 18 at 10:07

1 Answer 1

5

To write a disk image to a block device, you can run this command with administrative privileges:

dd if="${IMAGE_FILE}" of="/dev/${BLOCK_DEVICE}" conv=fsync

And that’s it. In fact, you do not even need dd, a plain cat "${IMAGE_FILE}" > "/dev/${BLOCK_DEVICE}" && sync will probably suffice in its stead. Booting from a USB drive (in a modern-ish system, that I presume Book8088 is likely to mimic) is no different from booting from any other block device like a floppy or hard drive: the first sector is loaded and then control is transferred into it, leaving it to load anything else it needs. Then, though, writing a 320 KiB image to a megabyte- or gigabyte-sized flash drive so that it can boot into a single game seems rather wasteful.

For the specific PC booter game collection you linked here, though, I can think of a much more convenient solution: convert those disk images into DOS executables, and copy them onto a FAT file system. Then you will be able to launch the games from DOS; exiting, though, will still require a power cycle. The conversion process can be accomplished with just a couple of Unix commands:

dd if=mazy.img of=mazy.com count=61
printf '\x0e\x58\x83\xe8\x20\x8e\xd8\x50\xb8\x00\x05\x50\xcb' | 
    dd of=mazy.com count=1 conv=notrunc,sync

This rips the booter image file into a COM file, replacing its loader (the boot sector that would normally read the rest of the game code from the floppy) with simple startup code that merely adjusts segment register values so that all offsets match the executable image that DOS already loaded, and then jumps to the entry point. 61 sectors (31 232 bytes) are ripped as a conservative estimate, but the game code is usually much shorter (you can check with hexdump -C | tail), so the executables can be made smaller than that.

This only works for the specific collection of games mentioned in the question, and isn’t a general solution. It takes advantage of the fact that the games only ever use near (16-bit) pointers, don’t use segmentation, and don’t even need to take pointers to stack variables. (Beware also that this quick-and-dirty startup code doesn’t check whether a whole 64 KiB of memory were allocated to the program; it may corrupt foreign memory if runtime game data and stack cannot fit within the allocated space. But this will probably not matter much if the game will never exit back to DOS anyway.)

4
  • You forgot to call sync after dd or use conv=fsync dd option. This is necessary to make sure the image is written when unplugging the disk.
    – zomega
    Commented Jan 18 at 11:34
  • 1
    @zomega: does sync actually help with that? My understanding is that it flushes writes buffered at filesystem level, but there is no such thing for /dev; blockdev --flushbufs would be needed instead?
    – grawity
    Commented Jan 19 at 5:52
  • Fantastic, that's just what I was looking for!! Thank you so much, @user3840170! Commented Jan 19 at 17:02
  • 1
    @grawity The sync command without parameters calls libc sync() which then does a system call of the same name. The man page of the sync command does not make any difference between file system or block device caches. And that matches my experience (it simply flushes everything). I guess what you are talking about is the libc documentation. It says something about file system caches but I think it's bad documentation only.
    – zomega
    Commented Jan 19 at 17:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .