12/13/2023 0 Comments Bochs windows 95 int 15![]() Found a damned bug, where if a file has the kernel file name, but a wrong last character, the code considers it the kernel. It will lose a bit of "weight" once I remove some of the text output functions. The boot loader file size is getting uncomfortably close to 512 bytes. Wrote the fragment which finds the root directory entry which belongs to the kernel file. The code is now debug printing first three entries in the root directory. This was possible because there's no point in preserving the ax register, since it will be set in preparation for the int 13h call anyway, right after returning from the LBA-to-CHS routine. Saved 2 bytes from the LBA-to-CHS routine. LBA-to-CHS head/cylinder calculation makes sense fully now, and I've tested it using an online converter. Saved 4 bytes by switching to using the stack rather than temporary registers. I have a feeling I'll run out of space with the boot loader, so I'm refactoring the LBA-to-CHS function. TODO: Make sure head/cylinder calculation makes total sense before moving on TODO: Clean up LBS-to-CHS code (save results of division) ![]() The simple "print hex byte to screen" routine is already paying off. The ultimate purpose is for the loader to load the kernel. The point of this routine is to be able to map a logical disk sector number (0 to n-1) to a physical Cylinder-Head-Sector tuple which is required by the BIOS's interrupt 13h (disk services). ![]() Looks like it's working well, but I'd like to clean it up again. I've tested it using a converter utility website. I don't know if I will be able to find a suitable debugger for Windows which will work with Bochs, so I'm going to code up some functions to dump registry values.įound a good LBA-to-CHS translation routine and incorporated it in the code. ![]() Wrote some calls to help me debug FAT12 operations. Started reading about reading from a floppy disk, since the plan is to read FAT12 and locate a file with a specific name which will contain the kernel. The build script now injects a few test files into the floppy image. I don't know if this is a DOS-specific thing, or not, but the generated floppy image now boots in Bochs and VMWare, and is recognized as a valid floppy disk in both Windows XP and DOS. Instead, I changed the 0 to a nop (0x90) instruction, and it started working. With a 0 there, DOS 6.22 doesn't recognize the floppy as valid. While the FAT12 specification says that the first 3 bytes of the boot sector are ignored, this is not true. I refused to give up and took a look at an online example of a bootloader which specifies the PBP in order to make a "proper" floppy image. Of course, it boots in both Bochs and VMWare. I reached a compromise where DOS no longer can read the floppy, but Windows XP can. Of course, as soon as I try to copy even one file to the floppy image, it stops working (can't be read by DOS or Windows XP). It also became readable in both DOS and Windows XP. Once I added it, my floppy disk image booted in both Bochs and VMWare. It turns out I was missing one byte from the beginning of my BPB (BIOS Parameter Block). However, in VMWare, I can read the FS, but of course, doesn't boot. I added it, and it boots in Bochs, but I can't read the FS from a DOS 6.22 VM. The problem could be that I'm missing the BPB boilerplate. dd'ing the image to insert my own bootloader simply corrupts things.įor now, I can either create a floppy image with files on it, or a bootable, empty floppy image.Ībout five different tools later, I can boot, as well as have valid files on the floppy image. The floppy imaging tool tries to be extra smart and injects its own bootloader. Put together toolchain - it assembles and creates boot loader floppy image from one script. Installed Bochs, a virtual machine provider which I hope to use as my development environment. Start thinking about where applications will be loaded, and how they'll return to the OS. Start thinking about organization of segments (stack, etc.). Re-familiarized myself with boot loaders and BIOS booting process. Outside of this, I often spent time thinking about what to do next and how to do it. It was developed primarily during evenings, some longer and some shorter. ![]() This is the development log of Snowdrop OS. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |