While I’m disappointed not to have won, I’m encouraged to see that our approaches were remarkably similar. We both wrote custom EFI CSM drivers to emulate the BIOS functions Windows requires to boot. I’m very curious how they managed to get VGA working, and I won’t be surprised if it doesn’t work in either the Mini or the Macbook Pro, as it looks like they did all their development on an iMac.

If nothing else, this was a tremendous learning experience for me, and the timing couldn’t have been better. I have recently become interested in Intel assembly and protected mode programming, topics I considered too challenging years ago when I was doing DOS programming, but concepts that make much more sense to me now. I had randomly dusted off some old assembly language references from my bookshelf and read some chapters on protected mode programming a few weeks prior to beginning work on this project, so I was able to grasp what needed to be done to provide a working solution almost immediately.

With the deadline fast approaching and narf’s Flickr images haunting me, I coded quickly and didn’t spend much time making the code pretty or maintainable, but I’m still fairly proud of the code I wrote. It’s fairly succinct, but does quite a bit. Anyone who’s interested can peruse the code here.

The main function is in OSXP.c, which contains code for reading the GPT partition table that Mac OS X uses, writing a MBR partition table that Windows would use, and loading a bootloader from an El Torito bootable CD-ROM.

Code to switch from protected mode to real mode (called a thunk) is in thunk.c and asmthunk.s. It’s not very general, but it’s the first protected mode assembly code I’ve ever written, and, surprisingly enough, it works.

Code to setup a real-mode interrupt vector table and the real-mode interrupt service routine is in rmisr.s. For the most part, this duplicates the thunk code, but in reverse order: it switches from real mode to protected mode and then back again. This reverse thunk is necessary to emulate BIOS functions using the native EFI functions (read disk sector, print character, etc).

The protected-mode interrupt service routine, which does the actual BIOS emulation, is in pmisr.c. It reads and writes a saved register context on the stack that the real-mode code inherits upon return from the interrupt service routine.

Just writing those thunk and interrupt service routines is probably about 50% of a complete solution, and I’m very happy with how they came out. The first time I thunked into the MBR code, it worked better than I expected, and actually identified the active partition, loaded the boot sector from it, and jumped to it. Booting into the CD bootloader worked also, though it hung right after probing memory.

I’m pretty amazed that my code works, but to toot my own horn a little more, I’m pretty happy with some of the debug techniques I came up with along the way. Running EFI applications in the pre-boot environment leaves a lot to be desired. You can’t exactly fire up gdb and throw a bunch of watchpoints on your code to find out what’s going wrong (though I did toy with the idea of compiling GDB for EFI). And even if I had a debugger at my disposal, it’s hard to debug a protected mode/real mode transition.

At first, my debugging consisted of writing copious amounts of debug output to the console and waiting for my tester, Chris, to run the code and take a picture of the result. At that time I didn’t have an Intel Mac to play with, so needless to say, progress was slow. We did get fairly far with this method, though. I wrote all of the partition table (GPT and MBR) code without ever having seen my code run with my own eyes. Chris’ pictures showed me what I needed to know, then I’d make a change, recompile, and Chris would download the new file and reboot. Again and again. Thanks, Chris.

I was unsure of how to access the CD-ROM under EFI, because it didn’t show up when I listed all the block I/O devices in Chris’ Macbook Pro. Ryan was nice enough to lend me his shiny new Mac Mini, and I was pleased to find that the CD-ROM device showed up once there was a disk in the drive. I was even more pleased to see that my El Torito code worked almost flawlessly from the beginning.

Then came the hard part, thunking into real mode. I wrote code and pored over it for hours making sure it looked right, but when I ran it, the computer spontaneously rebooted. Unsure of which instruction(s) were causing the reboots, I added an infinite loop to a section of the code, recompiled, and ran it. The machine hung. That validated that all of the code above the loop was not causing the reboot (at least not directly), so I moved the loop down a few instructions and tried again. Using this technique I was eventually able to find all of the bugs in my code, which were all stupid syntax problems and not logic problems (there’s a big difference between $0×10 and 0×10 in AT&T assembly).

Once the thunk and interrupt handler code was working, I started looking into why NTLDR was hanging after probing memory. NTLDR is 233kb and its disassembly is 97k lines long. I knew roughly where the hang occurred, based on the output I had from the last BIOS interrupt it invoked, but I wanted to narrow it down to a specific routine.

It occured to me that I could just write my own debugger of sorts. By handling interrupt 3, my code would get control anytime the NTLDR code stumbled onto an INT3 instruction. So, using the disassembly listing as a guide, I made a list of instructions that I thought might be interesting stopping points, and wrote a routine to replace those instructions with 0xCC (the INT3 opcode). Then I wrote an INT3 handler that replaced the original instruction and decremented the return address by one so the original code would be run upon return from the interrupt service routine. And, to my surprise, it worked!

Earlier today I extended this a bit by automatically enabling trap mode in the INT3 handler so I could repatch the breakpoint instruction with 0xCC right after executing the original code. This change allowed a breakpoint to show up each time through a loop or each time a particular function was called. Then I went a step farther and added a breakpoint option that would leave trap mode enabled, so I could get a trace of every instruction executed between two points in the code. This would prove useful for figuring out which branches the program took as it made various tests and decisions.

The one thing that continues to elude me is how to enable VGA text mode. The standard graphics and text framebuffers (0xA0000 and 0xB8000) aren’t even mapped in memory, and reading from the VGA registers appears to return garbage. I suspect if I knew more about PCI programming, I’d be able to map the framebuffer memory and configure the I/O ports, but I’m at a loss for how to do that. In the interim, I’ve been patching NTLDR at load time so that it writes to my own text framebuffer, which I then scan on every interrupt in order to paint a portion of the emulated textmode screen. This is slow and hackish, and I know it’s possible to enable true VGA mode (narf and blanka did), but I don’t know where to begin.

All in all I’m pretty happy with the code I wrote, even though I didn’t win the contest. I’m looking forward to the next big challenge and an opportunity to use some of the techniques I learned on this project.