EFI and the future of BIOS

[Brendan]

Hi,

The speed of emulating code to change screen mode isn't at all important, but when changing the window into the screen memory or changing the first byte to display (for smooth scrolling in any direction) it wants to be reasonably fast, so I'd be interested to know if you've discovered how many instructions typically need to be emulated on each call for these functions to get a better idea of how important the speed issue actually might be - at the moment I don't know if it's worth putting in the effort to make a complex, fast emulator or if a simple, slow one would do the job without a noticeable delay. Have you tested your emulator to see how quickly it emulates code compared with running the same code directly, and how well do you think it'll compare with other emulators?

It wouldn't be too hard to estimate. For almost all video cards, there'd be a "display start register" or maybe two of them (e.g. "display start high register" and "display start low register"). VBE would have some "if(function_number == ??)" code then some parameter checking, then some shift & mask operations, and a few writes (to IO ports or memory mapped registers). With some saving/loading registers on the stack and other misc. overhead I'd estimate around 100 instructions.

For a simple emulator, on average you're probably going to need about 30 instructions to emulate one instruction, so it's going to be about 30 times slower than real hardware. If changing the window into screen memory is 100 emulated instructions then it's going to cost 3000 real instructions. On a slow CPU (e.g. 2 cycles per instruction with 100 million cycles per second) that might take about 60 us. Even if the estimate is wrong and it's 100 times slower you'd still be able to do it 60 times per second.

However; this topic is about EFI and EFI doesn't have VBE. Basically, by the time your OS is "ready" (maybe 10 years) the real mode emulator will be useless for almost all end-users (who would've all shifted to EFI anyway). Rather than spending time implementing an "eventually useless anyway" emulator, it might be a lot more sensible to spend that time implementing a basic native video driver (e.g. mode setting and not much else) for Intel's video (which will be more useful for end-users in the long run).


Cheers,

Brendan

[Combuster]

Rather than spending time implementing an "eventually useless anyway" emulator, it might be a lot more sensible to spend that time implementing a basic native video driver (e.g. mode setting and not much else) for Intel's video (which will be more useful for end-users in the long run).

And based on intel's not-entirely-compatible (and the we have one chipset documented, forget the others) strategy, you get a driver that only works on the chipsets you were able to test on. And by the time you have that driver ready, the majority is using a different chipset again so there's hardly any difference here.

As the situation currently stands, you get much more coverage in shorter time by porting x86emu or implementing v8086 support (whichever is most appropriate) compared to writing a native driver. Native VGA is an even simpler option with the same coverage but it comes with a relative lack of features. Similarly, if you want to support EFI only, writing a graphics driver against the new firmware protocols should in theory provide more coverage than writing dedicated drivers. But I haven't spent any time on actual EFI implementations because they constitute a very small minority of my available machines whereas they do all support legacy BIOS.

[Owen]

Note that EFI provides less features than VBE. Namely, you cannot change the resolution once ExitBootServices has been invoked.

[Brendan]

Hi,

And based on intel's not-entirely-compatible (and the we have one chipset documented, forget the others) strategy, you get a driver that only works on the chipsets you were able to test on. And by the time you have that driver ready, the majority is using a different chipset again so there's hardly any difference here.

Does the video mode setting stuff change a lot between different chipsets (or are you mostly only saying the more advanced stuff that VBE doesn't cover changes)?

As the situation currently stands, you get much more coverage in shorter time by porting x86emu or implementing v8086 support (whichever is most appropriate) compared to writing a native driver.

The current situation is only relevant for people who's OSs are "ready" today. The future situation is what's important for people who's OSs won't be "ready" until some time in the future...

Native VGA is an even simpler option with the same coverage but it comes with a relative lack of features.

Let's have a look legacy hardware. Serial, floppy and parallel are already gone. The PS/2 (keyboard) controller has been replaced with USB (and "PS/2 emulation" in SMM) and the PIT has been replaced with HPET (and some more SMM). They're not completely gone, but they've been removed as much as possible without breaking BIOS compatibility. Then there's PIC chips, which have been replaced by IO APICs for years but can't be removed because the BIOS requires them. Then there's ISA DMA controllers and A20. To be honest I'm not sure why either of these are still present in modern chipsets.

Finally there's legacy VGA compatibility. To make it work, there's "special case" routing for legacy VGA in memory controllers, PCI host controllers and PCI bridges. I doubt any of the video card manufactures think it's fun either (for e.g. I'd assume some of the reason that parts of the VBE spec are ignored by video card manufacturers is that it's too hard to squeeze more code into the little "legacy ROM area").

Once EFI becomes widely accepted, hardware manufacturers will be like a pack of wolves circling an injured buffalo. It doesn't matter who takes the first bite - maybe it'll be firmware that doesn't bother setting up the deprecated "legacy VGA routing" even though the hardware supports it, maybe the video card manufactures will be the first to drop VGA, maybe it'll come from the PCI people, and maybe it'll come from somewhere else (Apple). It doesn't matter who starts it though, once it begins everyone else will breathe a huge sigh of relief and "The Great Cleansing" will begin. All that legacy stuff will be ripped to shreds in the blink of an eye; and for the first time in history "80x86 PCs" will have a relatively clean architecture.

I'm predicting that "The Great Cleansing" won't happen for the next 5 years (people need some time to adjust), but I am predicting that it will happen within the next 10 years.

VGA is not a viable long-term option.


Cheers,

Brendan

[Owen]

Not only have they dropped A20 support, Macs do not even pretend to have a keyboard controller. The ACPI embedded controller uses those ports, and if you touch it, you'll crash the machine

[Brendan]

Hi,

Not only have they dropped A20 support, Macs do not even pretend to have a keyboard controller. The ACPI embedded controller uses those ports, and if you touch it, you'll crash the machine

Unfortunately, I don't have any Apple hardware here to test, but I'm wondering - how does Apple's Boot Camp work?

The BIOS "keyboard services" functions could easily just use USB (or EFI's keyboard functions); but for low-level keyboard controller emulation, does Apple's EFI allow software like Boot Camp to mess with its SMM code, or is there the same "can't touch it" problem under both EFI and Boot Camp?


Cheers,

Brendan

[Owen]

Same "Can't touch it". Remember, Boot Camp is for Windows, and Windows respects the ACPI "No legacy keyboard controller" bit

[DavidCooper]

With some saving/loading registers on the stack and other misc. overhead I'd estimate around 100 instructions.

Thanks for that estimate - I'll try a simple emulator to begin with and hope it's fast enough.

However; this topic is about EFI and EFI doesn't have VBE. Basically, by the time your OS is "ready" (maybe 10 years) the real mode emulator will be useless for almost all end-users (who would've all shifted to EFI anyway). Rather than spending time implementing an "eventually useless anyway" emulator, it might be a lot more sensible to spend that time implementing a basic native video driver (e.g. mode setting and not much else) for Intel's video (which will be more useful for end-users in the long run).

It'll still be worth doing it for the many old machines which may go on working for decades (particularly in less wealthy parts of the world), and it shouldn't take long to write an emulator in any case - I would imagine it can be done in a week. Also, by the time EFI's the only game in town (for a new machine), A.I. will certainly have reached the point where any OS creator will be able to get unlimited help in writing all the complex drivers they need, so I'm not going to waste time trying to adapt to it this far in advance - I'd rather just try to get the best out of my OS on the machines of today over the next year or so, because after that the whole game will change anyway: any idiot in the street will be able to create an OS with full capability and which works exactly the way they want it to.

[Combuster]

And based on intel's not-entirely-compatible (and the we have one chipset documented, forget the others) strategy, you get a driver that only works on the chipsets you were able to test on. And by the time you have that driver ready, the majority is using a different chipset again so there's hardly any difference here.

Does the video mode setting stuff change a lot between different chipsets (or are you mostly only saying the more advanced stuff that VBE doesn't cover changes)?

Point in case is the lack of a 82945 GMA manual (there is one for the 965), and that the registers documented to be responsible for the 8/16/32bpp choice in the 965 manual do not quite work as expected on a 945. At least on a Trio or a Mach64, the key registers don't change in behaviour over the entire chip family.

As the situation currently stands, you get much more coverage in shorter time by porting x86emu or implementing v8086 support (whichever is most appropriate) compared to writing a native driver.

The current situation is only relevant for people who's OSs are "ready" today. The future situation is what's important for people who's OSs won't be "ready" until some time in the future...

If you want to be ready tomorrow, you'd want to test now.

[Brendan]

Hi,

Same "Can't touch it". Remember, Boot Camp is for Windows, and Windows respects the ACPI "No legacy keyboard controller" bit

Thanks.

That may be the way legacy hardware is removed going forward. For example, there's a flag in ACPI for "no dual PICs", a flag for "no VGA" and a flag for "no user visible ISA/LPC devices" (which I assume covers things like ISA slots, serial ports and parallel ports; and is intended to simplify hardware auto-detection). For things like ISA DMA controllers, the PIT and the RTC/CMOS, maybe it'd be good practice to not touch them until after an OS has checked ACPI's AML (e.g. searched for the corresponding "_HID" objects).


Cheers,

Brendan

[Brendan]

Hi,

However; this topic is about EFI and EFI doesn't have VBE. Basically, by the time your OS is "ready" (maybe 10 years) the real mode emulator will be useless for almost all end-users (who would've all shifted to EFI anyway). Rather than spending time implementing an "eventually useless anyway" emulator, it might be a lot more sensible to spend that time implementing a basic native video driver (e.g. mode setting and not much else) for Intel's video (which will be more useful for end-users in the long run).

It'll still be worth doing it for the many old machines which may go on working for decades (particularly in less wealthy parts of the world), and it shouldn't take long to write an emulator in any case - I would imagine it can be done in a week.

I'd estimate roughly one week for instruction decoding and framework (e.g. functions to simplify addressing modes, so that something like "[eax*8+ebx+1234]" gets simplified into an actual address). Then I'd allow one hour per instruction, ignoring FPU, MMX, SSE and AVX. There's about 70 general purpose instructions, so that adds up to another few weeks. On top of that, you'd need code to setup the virtual address space, code to find the correct version of the video card's ROM (e.g. video card's ROM may contain several images, where only one of them is for "PC BIOS" and is copied to 0x000C0000), code to handle PCI configuration space access and IO port access (to ensure the video card's ROM doesn't mess with anything it shouldn't and possible emulate parts of it), code to initialise the video card's ROM that mimics the BIOS POST (there's specifications for that somewhere but I can't remember where - be warned it includes "pre-boot environment memory management"). Finally you'd want to create an IVT and dummy BIOS, where all BIOS functions cause the emulator to display a "Someone tried to call int 0x?? with EAX=0x????????" message that you can use to find out which video cards use which BIOS functions; and then test it on as many video cards as you can and implement any/all BIOS functions that any of them use. That's might take another 4 weeks; giving a total of 6 weeks. I'd be very tempted to multiply that by a "just in case" scaling factor of about 1.5 (because nothing ever goes to plan), and call it 9 weeks or 2 months.

Unfortunately, for most hobbyist OS developers "2 months full time work" is more like "4 months part time work" because of things like jobs and study (and Minecraft ).

Also, by the time EFI's the only game in town (for a new machine), A.I. will certainly have reached the point where any OS creator will be able to get unlimited help in writing all the complex drivers they need

Back in July you said "just wait twelve months", so that must mean there's only 10 months until your A.I. is able to write native video drivers itself. If you spend 2 months getting real mode emulation working, then the real mode emulator will only be useful for the remaining 8 months.


Cheers,

Brendan

[DavidCooper]

I'd estimate roughly one week for instruction decoding and framework (e.g. functions to simplify addressing modes, so that something like "[eax*8+ebx+1234]" gets simplified into an actual address).

The addressing in real mode is a bit simpler than that, but it's still the most complex part of the emulator to do.

Then I'd allow one hour per instruction, ignoring FPU, MMX, SSE and AVX. There's about 70 general purpose instructions, so that adds up to another few weeks.

Most of them are dead easy and should only take minutes.

On top of that, you'd need code to setup the virtual address space,

Nothing to set up in my case as I don't use paging yet, but even when I do it will run in an area where the virtual addresses are the same as the physical ones.

code to find the correct version of the video card's ROM (e.g. video card's ROM may contain several images, where only one of them is for "PC BIOS" and is copied to 0x000C0000),

I would have thought this would be set up by the BIOS on booting, but if it's something that changes every time you change screen mode, maybe I'll have to use real mode when changing screen mode and only emulate the code for changing the start-of-display position and for the windor function.

code to handle PCI configuration space access and IO port access (to ensure the video card's ROM doesn't mess with anything it shouldn't and possible emulate parts of it),

If it was going to mess things up, wouldn't it already be doing that when using the BIOS directly?

code to initialise the video card's ROM that mimics the BIOS POST (there's specifications for that somewhere but I can't remember where - be warned it includes "pre-boot environment memory management").

Again this isn't something that's going to happen when changing the window position or the display start position. I don't know if it's an issue when changing screen mode.

Finally you'd want to create an IVT and dummy BIOS,

There's shouldn't be a need to emulate everything that can be done in real mode - I was assuming that the code I need to emulate would never want to run an int instruction, but maybe that's wrong. However, what I plan to do is get the emulator to go through the code first to check that it is capable of running it, and then to run it on subsequent attempts once it has worked out that it can. If it can't cope, it'll let me know which instruction it's unable to handle and I can improve the emulator.

One important question though: does the video rom ever generate interrupts? I had gained the impression that it doesn't, and I've certainly found that if I call screen-related functions with the interrupts disabled they seem to work fine, but maybe the BIOS enables them at the start of a function and puts them back as they were afterwards.

Unfortunately, for most hobbyist OS developers "2 months full time work" is more like "4 months part time work" because of things like jobs and study (and Minecraft ).

If it turns out to be too time-consuming I'll give up the attempt early on, but I've done most of the work before for a monitor program and that turned out to be dead easy.

Back in July you said "just wait twelve months", so that must mean there's only 10 months until your A.I. is able to write native video drivers itself. If you spend 2 months getting real mode emulation working, then the real mode emulator will only be useful for the remaining 8 months.

It could easily be 24 months if things don't go to plan (and they frequently don't), but I certainly don't intend to put more than a week into writing an emulator. If it can't handle changing screen mode, that's not really a problem, but I certainly don't want to have to keep switching back to real mode many times a second while scrolling or writing to screen memory as it steals lots of interrupts [edit: though I suppose I could just disable them as standard when making those BIOS calls..., and that would also tell me if the BIOS is enabling and disabling interrupts itself...].

[Brendan]

Hi,

I'd estimate roughly one week for instruction decoding and framework (e.g. functions to simplify addressing modes, so that something like "[eax*8+ebx+1234]" gets simplified into an actual address).

The addressing in real mode is a bit simpler than that, but it's still the most complex part of the emulator to do.

The addressing in real mode is almost exactly the same as it is in 32-bit protected mode. The only difference is the default code size (e.g. if the operand size override prefixes and address size override prefixes mean "use 32-bit and not 16-bit" or "use 16-bit and not 32-bit").

Then I'd allow one hour per instruction, ignoring FPU, MMX, SSE and AVX. There's about 70 general purpose instructions, so that adds up to another few weeks.

Most of them are dead easy and should only take minutes.

Something that looks simple like "add reg32,immediate" wouldn't be too hard and should only take a few minutes if your framework (above) is good, and if you've already got code to handle setting the condition flags in EFLAGS correctly. Supporting all of the different variations of "add" and handling all the corner cases correctly is going to take longer. Consider something like "lock add [gs:esp],bx" where GS:ESP = 0x000FFFFE and A20 happens to be disabled. Now consider writing some real mode code to test each variation of "ADD", including all the "should work" cases and all the "should generate an exception" cases (and running this test code inside your emulator and on real hardware and comparing the differences).

On top of that, you'd need code to setup the virtual address space,

Nothing to set up in my case as I don't use paging yet, but even when I do it will run in an area where the virtual addresses are the same as the physical ones.

If you're not doing it properly and just recycling the original BIOS and the original video ROM, then you won't need to setup much.

If you are doing it properly and using your own dummy BIOS, and using the video card's BARs in PCI configuration space to get a fresh/clean copy of the video ROM; then "virtual addresses are the same as the physical addresses" is an annoying pain in the neck. If you're not using paging, then the emulator can do "guest physical address to host physical address" conversion in software (which is probably harder and slower than using paging).

code to find the correct version of the video card's ROM (e.g. video card's ROM may contain several images, where only one of them is for "PC BIOS" and is copied to 0x000C0000),

I would have thought this would be set up by the BIOS on booting, but if it's something that changes every time you change screen mode, maybe I'll have to use real mode when changing screen mode and only emulate the code for changing the start-of-display position and for the windor function.

If the firmware is "PC BIOS" and if the video card is the first video card and if the boot code can't do anything to screw things up (including trashing the original BIOS's IVT or data areas, putting the video card into a state the video ROM isn't expecting, messing with PCI bridges, etc); then you could assume it's safe to recycle the original BIOS and video ROM. I don't like silly restrictions or potentially wrong assumptions; and therefore I'd do it properly and not use the original BIOS or the original video ROM. For example, if it's done properly then (with enough extra work) it might be possible to use VBE when the firmware is EFI; and (with enough extra work) might be possible to have 3 instances of the emulator for 3 different video cards (and mess with "legacy IO port and memory mapped IO" routing in the PCI host and bridges to make it look like all video cards share the same IO ports and memory ranges). It might also be possible to re-use the same real mode emulator for things like network card and SCSI controller ROMs (if it's done right).

code to handle PCI configuration space access and IO port access (to ensure the video card's ROM doesn't mess with anything it shouldn't and possible emulate parts of it),

If it was going to mess things up, wouldn't it already be doing that when using the BIOS directly?

Code in the video ROM may assume certain pieces of hardware are in a certain state, and these assumptions may be perfectly correct when the video ROM's code is running in real mode on the real BIOS; but after your OS has initialised (reconfigured) most of the hardware all the assumptions that were correct are now problems that your emulator has to handle.

On top of that I'd want to use some defensive programming and make sure that (for e.g.) badly written and/or buggy video ROMs can't completely screw my OS. For a simple example, if the video ROM happens to accidentally write to 0x12345678 then it may never cause a problem on real hardware in real mode; but the same bug can trash your kernel's data or something and it'd be nice to use the emulator as a type of "sandbox" to prevent that. An "extreme" OS developer might even use the "sandbox" nature of the emulator to protect against malicious code injection (e.g. where the video ROM's code has been tampered with deliberately in an attempt to bypass the OS's security), just because it's so easy for an emulator to protect against these sorts of things when it is done right.

code to initialise the video card's ROM that mimics the BIOS POST (there's specifications for that somewhere but I can't remember where - be warned it includes "pre-boot environment memory management").

Again this isn't something that's going to happen when changing the window position or the display start position. I don't know if it's an issue when changing screen mode.

It's an issue for "initialising that specific video card's ROM properly before using it"; and only applies when you're not recycling the original BIOS and original video ROM.

Finally you'd want to create an IVT and dummy BIOS,

There's shouldn't be a need to emulate everything that can be done in real mode - I was assuming that the code I need to emulate would never want to run an int instruction, but maybe that's wrong.

Nothing prevents the video ROMs code from calling any of the BIOS functions for any reason. Most video cards probably don't have a good reason to do this, but at a minimum you'd want to be able to detect when the video card is attempting to call BIOS functions that your emulator doesn't emulate.

One important question though: does the video rom ever generate interrupts? I had gained the impression that it doesn't, and I've certainly found that if I call screen-related functions with the interrupts disabled they seem to work fine, but maybe the BIOS enables them at the start of a function and puts them back as they were afterwards.

Nothing prevents the video card from generating an IRQ. For example, before switching video modes it might do "HLT" in a loop until a vertical retrace IRQ occurs or something. I'd assume that most video cards don't generate IRQs and most video card ROMs don't use them, and therefore it's important to cover cases where these assumptions happen to be wrong. At a minimum you'd want to be able to detect when the video card is attempting to use IRQs (e.g. trap writes to the IVT and the PIC chips during the "emulated POST" that you weren't planning to have) so that you know if any video card ever tries it.

Also don't forget that a video card might do other annoying things, like polling the BIOS's "ticks since midnight" variable, or relying on FPU instructions (and maybe even using IRQ13 for floating point errors).


Basically you're right, in that 1 week might be enough time to write a half-assed emulator that "works" for the limited number of computers and video cards you've got access to. Of course "works for me" may be the worst thing that can happen - I wouldn't want to receive hundreds of "It crashed for some reason and I can't give you any hints why, and I'm going to tell everyone that will listen that your OS is unstable crap" emails from unfortunate end-users after the OS is released.


Cheers,

Brendan

[Ready4Dis]

Well, so far my emulator is almost 386 complete (about 90% of instructions are done, 16/32-bit opcdoes work in their respective places), it took about 3 days of part time coding. I have run through older and newer amd/nividia option roms, so far nothing out of the ordinary like using FPU or calling misc. interrupts. Where you came up with that crap, I have no clue, but Bios have been around for some time, most motherboard and video card manufacturers would like their products to work with the majority of systems, so they don't rely on funny little tricks... they stick to the tried and true stuff. Honestly, none of the bios' that i've run through my emulator go into pmode, none use funny bios', I need to do a bit more digging to see if they rely on the clock at all (i'm sure some of them need some sort of clock for timing, but maybe not).

Either way, to say an emulator is a useless waste of time is ignorant. Especially when there are open source ones available that are almost plug and play. The time it takes to add this feature instead of hard coding a specific video card's set screen function is much more efficient, and will work on a wider assortment of cards (like, more than 1). Yes, you're OS may not be ready for 10 years, mine might never be ready, but my OS has had graphics mode before EFI (which was before UEFI) as released, and still works with a wide array of video cards... much more than if I had coded an intel specific set mode function.

Also, the one hour per instruction is a rediculous claim.. it's more like 5 minutes per instruction if you're framework isn't a complete pile. And depending on the instructions, some of them are much faster if you can copy/paste from a similar instruction. Yes, push took all of 20 seconds to write, pop took another 20. Call was a bit more complex as I had to call push, then update IP... ret was almost as hard calling pop, then updating ip. Add/sub/mul/div weren't really much harder.. the hardest part was making sure you had the correct src and dest (that encoding is a bit odd at first, but once you have it, it works for all instructions). Really none of the instructions are that difficult, especially if you write your framework in a somewhat organized manner.

Will my emulator be worthless in 10 years? I don't know, I don't have/use a crystal ball. I do however know that it works now, and didn't take very long to implement. It probably would have taken me just as long to read/understand an intel doc describing how to manipulate the correct registers of their GPU in order to set a mode.

EFI is becoming mainstream (slowly), and you'll be able to use GOP to set your mode, and nobody will have to worry about writing a specific driver for setting a screen mode, so in that case, either method is a waste of time.. unless of course you want it to work sometime soon on more than one chipset.

[DavidCooper]

Thanks for the thorough analysis, Brendan - it's good to get an overview of most of the possible pitfalls before starting on something like this.

I'd estimate roughly one week for instruction decoding and framework (e.g. functions to simplify addressing modes, so that something like "[eax*8+ebx+1234]" gets simplified into an actual address).

The addressing in real mode is a bit simpler than that, but it's still the most complex part of the emulator to do.

The addressing in real mode is almost exactly the same as it is in 32-bit protected mode. The only difference is the default code size (e.g. if the operand size override prefixes and address size override prefixes mean "use 32-bit and not 16-bit" or "use 16-bit and not 32-bit").

I was assuming that things like [eax*8+ebx+1234] wouldn't occur in real mode because it doesn't have segments capable of handling 32-bit addresses - it might well be possible to run the instruction, but the result would be an unusable address and therefore pointless, and that's why I don't expect to find that in video BIOS code. It might turn up on the odd machine, of course, but if it does I can simply make it resort to switching back to real mode every time on those machines until I've improved the emulator's capabilities - the important thing is to try to improve the performance on most machines.

Nothing prevents the video card from generating an IRQ. For example, before switching video modes it might do "HLT" in a loop until a vertical retrace IRQ occurs or something. I'd assume that most video cards don't generate IRQs and most video card ROMs don't use them, and therefore it's important to cover cases where these assumptions happen to be wrong. At a minimum you'd want to be able to detect when the video card is attempting to use IRQs (e.g. trap writes to the IVT and the PIC chips during the "emulated POST" that you weren't planning to have) so that you know if any video card ever tries it.

Good point - I could check to see if the IVT or PICs change after changing screen mode. A HLT would also be a clear sign of a problem. I can't see any reason for an interrupt to be involved when changing the window position, but it might be used with hardware scrolling.

Also don't forget that a video card might do other annoying things, like polling the BIOS's "ticks since midnight" variable, or relying on FPU instructions (and maybe even using IRQ13 for floating point errors).

I doubt the FPU will be involved - it's too slow to set up and access, requires RAM to get results out, and floating-point-number results would be a nightmare to process afterwards. I think it's safe to assume that it won't happen, but it if ever does I'll get an interesting error message from the emulator when it abandons the attempt and switches the OS over to using real mode directly.

Basically you're right, in that 1 week might be enough time to write a half-assed emulator that "works" for the limited number of computers and video cards you've got access to. Of course "works for me" may be the worst thing that can happen - I wouldn't want to receive hundreds of "It crashed for some reason and I can't give you any hints why, and I'm going to tell everyone that will listen that your OS is unstable crap" emails from unfortunate end-users after the OS is released.

Thanks for the warning about the worst-case scenario. I will make sure that the emulator quietly switches itself out if it can't handle the BIOS in an unusual machine, and that it provides a message as to why (which will be seen by anyone who looks under the hood). My hope is that it will only take a week to write a competent emulator which works on most machines, but time will tell - it may turn out that there's a major problem that will block the way, but at least I'll then know what it is and will be able to warn other people about it. I'll give you an update once I've written it, and if it works on all my machines I'll make it available here for people to test (and to use as a guide for writing their own emulator).