This forums is for OS project announcements including project openings, new releases, update notices, test requests, and job openings (both paying and volunteer).
What I do here is make a copy of the first block of memory to somewhere that isn't NULL.
meanwhile, your version sets the first block (including the IVT) to zero, hence calling an interrupt causes the emulator to try to emulate at 0000:0000, which you set to zero.
I knew it was a stupid mistake! What I did was (by quickly taking over and rewriting) assume that the memcpy was simply copying 0 to to something (to set it to 0), but in fact it's doing something entirely different.
You'll be happy to know that the switching works now, although it takes around 7 to 10 seconds to perform one video switch, whereas my real mode switcher takes less than one second, but I guess it's part of the emulation and might even be sped up in the future (through various optimizations). I've also tried switching back to text mode but I can't quite seem to get that working. I set AX to 0x02 to switch back (and it does), but it never seems to return. Is there anything specific I need to keep in mind once I made a call to an interrupt?
EDIT: With -O3, the emulator is considerably faster (one switch takes around 3 seconds, which is a lot more acceptable).
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
Not a lot, I've been working on other things for now, but there has been some bugfixes to it.
However, once I get my 64-bit kernel up, it's going to get a lot of stress testing. (A lack of VM8086 mode means I will have to use this for what it was designed).
astrocrep wrote:It's been a while, but I believe textmode is 0x3...
This project looks very interesting!
--
Edit: ehh crud... sorry for bumping a old thread...
But since I'm here, any updates on this project?
Thanks,
Rich
I tried it again afterwards with 0x03 as well and for some reason, I could switch to 0x13, 0x12 and such but never back to text mode. It did the actual switch, but execution never continued (I guess it got stuck somewhere). I also tried it in 64-bit some time ago, I got a page-fault (page not mapped) somewhere way too high where I wasn't even placing anything (apparently the emulator was trying to access it for some reason). That was quite some time ago, though, and I don't have the code here anymore (it was more of a test).
I still think it's a good way of handling BIOS calls in long mode, even though it's considerably slower than e.g. a PMode -> RMode -> PMode switch, but I remember that turning optimizations on made a huge difference in speed. I guess you'll probably want to optimize your code (after you've finished it, of course).
When the chance of succeeding is 99%, there is still a 50% chance of that success happening.
Very interesting, but not useful on real hardware. Simply some instruction used by modern BIOSes to increase the performances aren't covered (AAA, DAA, INS, OUTS and so on). It still work on emulators but not on real hardware. So I decide to add these and other instructions to the code. I hope the author doesn't mind
Go ahead, but could you apply them as a patch to the git tree? I've been slowly working on it since I posted and I think I've implemented some of those opcodes myself.
