Damn! Took me a lot of debugging to find the problem in the El Torito boot image of colorForth. Why it behaves differently I can't figure, but in the loop after reading a cylinder of the emulated floppy disk, moving data from the buffer to where it belongs in the RAM image, something would happen to the CPU (both actual and in VMware -- not in Bochs nor QEMU) that would zero the registers, right at the moment where the currently executing instruction was being overwritten. A real pisser, especially since it occurs in the bootblock, where space for debugging code is at a premium. I had to comment out some debugging code to make room for the new stuff.
Now to find out if simply skipping overwriting the first 512 bytes will be sufficient to resolve the problem. It would be so cool if the secret to testing all the colorForth images out there would be simply to give them my kernel and burn an ISO image with mkisofs. By the way, if you're developing on Cygwin, use the cdrtools package from smithii.com, not the versions compiled with Windows, if you're going to do file globbing for exclusions. I was getting lots of weird and useless "invalid option" error messages with one executable, which turned out to be caused by various seemingly innocuous things such as continuation lines in the Makefile. wtf?
last updated 2013-01-10 20:52:06. served from tektonic.jcomeau.com