x86asmban - Sokoban in an MBR

[Fahr]

Hello all,

I've been sitting on this one for a while. Finished it almost 2 years ago with the intention of doing a full write-up on it as a series of blog posts, but I've just not had the time.

Bottom line; I've built a fully (hopefully) working version of the game sokoban as an MBR using mode 13h for graphics and a PC speaker for audio. This was mainly an exploration project for myself to tinker with pure x86 asm, but I'm quite happy with the result.

Before I do a full write up/blog series about this, I figured I'd link it here in case anyone wants to look at it. Bear in mind that this is my first serious pure x86 asm project (though I've previously written drivers and other low-level stuff), so I'm not just looking for feedback on the actual functionality of the thing, but - perhaps even more - on the code, quality and design choices.

Perhaps too big an ask, but I have to start somewhere to get some feedback

Repo with more instructions is here; https://github.com/gboor/x86asmban

Thanks in advance to anyone who wants to have a look!

[Octocontrabass]

as an MBR

The MBR is just the first sector of the disk, I don't think it counts as an MBR when you're using more than one sector of the disk.

Speaking of which, if you want to try booting it from USB instead of a floppy disk, you might have trouble because you don't have a partition table in your MBR. Some BIOSes are picky about that.

using mode 13h for graphics and a PC speaker for audio.

Oh, I've got some PCs I'd like to try this on...

[Fahr]

The MBR is just the first sector of the disk, I don't think it counts as an MBR when you're using more than one sector of the disk.

I realize that and I actually did some research into that. While there doesn't seem to be any actual standard, bootloaders like Grub seem to use up to the first 64 sectors of a disk and, from what I gathered, this is generally considered to be ok. I might be wrong, but Grub definitely uses more than one sector. As do many other bootloaders... perhaps "bootloader" here is better than "MBR", though it's also not exactly a bootloader as it doesn't load anything...

Speaking of which, if you want to try booting it from USB instead of a floppy disk, you might have trouble because you don't have a partition table in your MBR. Some BIOSes are picky about that.

Line 130 in mbr.asm has a fake "partition table", which should satisfy most BIOSes. Though it may require an actual entry; I've not tested this broadly on actual hardware (actually only on an old NAS that still has a disk drive; haven't tested it on a USB stick at all), but some emulators that complained about there being no partition table stopped complaining once I put that in.

Oh, I've got some PCs I'd like to try this on...

I am very curious about how (and IF) it runs on what actual hardware. As mentioned above; I don't have too many devices I can test this on. I've also not been able to load it from a USB stick despite trying; the requirements seem to be quite different in terms of what data needs to be provided in the first sector. I've also not really tried beyond a small experiment, it's still on my todo.

[Octocontrabass]

Line 130 in mbr.asm has a fake "partition table", which should satisfy most BIOSes. Though it may require an actual entry;

It depends on the PC, but some do indeed require an actual entry. They can be pretty picky about it, too, but you can usually satisfy them just by creating a partition in Windows and marking the partition as active (bootable).

I am very curious about how (and IF) it runs on what actual hardware.

The first PC I tried it on said "Error reading disk". I'd guess that's because you're telling the BIOS to read a floppy disk and I can't boot any PCs from a floppy disk at the moment.

[Fahr]

The first PC I tried it on said "Error reading disk". I'd guess that's because you're telling the BIOS to read a floppy disk and I can't boot any PCs from a floppy disk at the moment.

That's a good catch... I've always only tested with the first disk drive, so dl being 0 has never affected anything - oops. I've rectified this in the github code now, it should save and restore the proper value of dl.

Just out of curiosity, what are you trying to boot it from? USB? HDD?

[Octocontrabass]

it should save and restore the proper value of dl.

Indeed it does. Now it says "Error reading sector", which I'd guess is because this PC's BIOS does something that isn't what you expect.

Just out of curiosity, what are you trying to boot it from? USB? HDD?

HDD. (It's actually a CF card but the BIOS doesn't know that.)

[Fahr]

Now it says "Error reading sector", which I'd guess is because this PC's BIOS does something that isn't what you expect.

I've removed the sector check. I guess it's silly to have that anyway if the read returns an OK status. I may still add handling for ah = 0x11 (data ECC corrected) at some point, but that seems like overkill for now.

HDD. (It's actually a CF card but the BIOS doesn't know that.)

That sounds like an interesting setup. I did some quick searching and found there's SD to SSD adapters as well, which will definitely help a lot with testing this stuff. I shall order one. Does your adapter hot-swap? Could you send me a link?

[Octocontrabass]

I've removed the sector check.

Now the game starts, but keyboard input is messed up. I see at least one incorrect assumption about BIOS behavior.

Does your adapter hot-swap? Could you send me a link?

It's not an adapter, the PC in question has a CF slot instead of a 40-pin IDE connector. It definitely does not hot-swap!

[Fahr]

Now the game starts, but keyboard input is messed up. I see at least one incorrect assumption about BIOS behavior.

This is a very odd one. I definitely didn't come up with the idea that int 0x16 clears CF, but I cannot find any reference to it. Strangely enough; it works in my various emulators... I've altered the code specifically clear CF when there's something in the buffer.

It's not an adapter, the PC in question has a CF slot instead of a 40-pin IDE connector. It definitely does not hot-swap!

I've done a bit of searching and it looks like a great upgrade for old hardware since CF is basically IDE... I have an old machine I sometimes test stuff on and this looks like a smart thing to do. At least smarter than doing something SATA or USB with SD for old machines. I had no idea this was possible. Thanks for pointing it out, I'm gonna buy one

[Octocontrabass]

I've altered the code specifically clear CF when there's something in the buffer.

It's still acting really weird. It looks like you're expecting CF to be preserved across calls to INT 0x16 AH=0x01, but BIOS calls that modify one flag will usually modify all of them.