That sounds like a serious bug to me - if the timer IRQ occurs before you're ready the OS crashes.suthers wrote:It assembles fine, but it causes an error in bochs 2.0.2, but not in 2.3.6....
Weird.
I looked at bochs 2.0.2 debug output to find the error... turns out bochs 2.0.2 generates a system timer interrupt before my IDT is setup, where as 2.3.6 doesn't...
Weird, but I can live with that (for some reason I prefer 2.0.2 because I started with it, but I'm trying to shift completely to 2.3.6... )
Bochs 2.0.2 probably has different timing to Bochs 2.3.6 so it only crashes on Bochs 2.0.2; but a real 80486, a real Pentium, a real Opteron, a real Celeron all have different timing too - I wonder how many real computers your OS will (or won't) crash on? Heck - I wonder what would happen if you played with your "bochsrc.txt" files (changing your "ips=10000000" to a different value could make your OS crash or work under either version of Bochs).
Worse, Bochs is fairly deterministic (i.e. same amount of time between "power-on" and the PIT's IRQ each time you run it) but real hardware may not be deterministic. For example, if there's a boot manager or something and the user needs to press a key to continue, then you get a different amount of time between "power-on" and the PIT's IRQ every time you boot - the OS would crash randomly (depending on exactly how quick the user presses a key). You could also get a situation where the OS works if you boot from floppy but crashes if you boot from CD-ROM on the exact same computer. Timing bugs are nice like that; which is why they're so annoying to find and fix, and why you should fix it immediately (while you can).
Note: for debugging, if you can get it to crash then you can find the problem (Yay!), but if you can't get it to crash then you can't find the problem and you're screwed (Doh!)...
I use NASM to generate flat binaries - no linker (and no linker script).suthers wrote:P.S. Brendan, If you don't use a linker script what do you use?
Cheers,
Brendan