Answer by user3840170 for How to use dd command to write a PC booter floppy image to a USB flash drive?

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=61printf '\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.)