Interview with Qbix on DOSBox online
in [ASM]
|
Prev: AMD X2 3800+ processor has bottleneck in integer multiplier ?
Next: How many branches in a loop can be predicted successfully ?
From: Rod Pemberton on 6 May 2008 05:45 This interview with "Qbix" goes into more depth on how DOSBox works: http://www.classicdosgames.com/interviews/peterveenstra.html As I've mentioned previously, DOSBox with SDL could be used as an OS: http://groups.google.com/group/alt.os.development/msg/fec484c7a0c0b4af With modifications, it could be used as the 16-bit layer for video BIOS calls, or as a QEMU replacement... Quotes from the interview I thought might be interesting to OS developers (out of order). The last quote should be interesting to assembly programmers... (Interviewer) "I've been impressed by how well Windows 3.1 runs in DOSBox ...." (Qbix) "Using disk images, it is even possible to run Windows 95 running Starcraft on DOSBox. That is kind of nice, but not currently a goal of DOSBox. With some patches (that are currently developer-only) you can even run (to some degree) Linux, NetBSD and Windows NT4 in DOSBox. A nice test for our hardware emulation, but again not a goal of DOSBox." (Qbix) "DOSBox is mostly OS independent, CD-ROM support using your real drive is an exception though." (Qbix) "DOSBox isn't a VDM, DOSBox is actually a full-blown PC emulator. So we emulate the CPU, timer, interrupt controller, sounds cards, video cards, BIOS, videobios and to make things easier to the end user: DOS, EMS client, XMS client, Mouse driver." (Qbix) "The emulation of the mouse, EMS, XMS and DOS happens with C/C++ code and not Assembly. This makes DOSBox different from other full PC emulators (and results in a lot of free conventional memory). To make this possible we have introduced an extra CPU instruction that isn't present on a real CPU. When this special instruction is emulated, DOSBox looks up the next instruction which contains a number of which C function should be executed. (All those C functions are stored in a table with their number). This makes it possible for us to code a mouse driver in C (which is easier/faster to write than ASM) and make it behave like a real loaded mouse driver. From these functions it is possible to read and modify the emulated CPU registers and the emulated memory. This system is also used to emulate most of the BIOS and VIDEO BIOS functions." Rod Pemberton
From: Wolfgang Kern on 6 May 2008 08:39 Rod Pemberton posted: > This interview with "Qbix" goes into more depth on how DOSBox works: > http://www.classicdosgames.com/interviews/peterveenstra.html I downloaded the 0.72 for windoze and will check if this 1.2 Mb C-created code does anything more than just calling API functions. Thanks for the info, __ wolfgang
From: Alexei A. Frounze on 7 May 2008 04:03 On May 6, 2:45 am, "Rod Pemberton" <do_not_h...(a)nohavenot.cmm> wrote: > This interview with "Qbix" goes into more depth on how DOSBox works: > http://www.classicdosgames.com/interviews/peterveenstra.html Interesting, but not fascinating. :) > As I've mentioned previously, DOSBox with SDL could be used as an OS: > http://groups.google.com/group/alt.os.development/msg/fec484c7a0c0b4af > > With modifications, it could be used as the 16-bit layer for video BIOS > calls, or as a QEMU replacement... There was some blog saying that when there're no 64-bit (or any?) video drivers for the video card, 64-bit Vista (and maybe earlier 64- bit Windows too) simply emulates the VGA/VESA BIOS instructions since there's no way to execute the BIOS code directly when the machine has switched into 64-bit mode (need to switch all the way back into 32-bit/ v86 or real mode). .... > (Qbix) "The emulation of the mouse, EMS, XMS and DOS happens with C/C++ > code and not Assembly. This makes DOSBox different from other full PC > emulators (and results in a lot of free conventional memory). To make this > possible we have introduced an extra CPU instruction that isn't present on a > real CPU. When this special instruction is emulated, DOSBox looks up the > next instruction which contains a number of which C function should be > executed. (All those C functions are stored in a table with their number). > This makes it possible for us to code a mouse driver in C (which is > easier/faster to write than ASM) and make it behave like a real loaded mouse > driver. From these functions it is possible to read and modify the emulated > CPU registers and the emulated memory. This system is also used to emulate > most of the BIOS and VIDEO BIOS functions." It's quite normal. Except, I don't think inventing instructions was necessary. Alex
From: Rod Pemberton on 7 May 2008 13:17
"Alexei A. Frounze" <alexfrunews(a)gmail.com> wrote in message news:b02293ea-798f-4e48-a253-f0a836ff564b(a)w1g2000prd.googlegroups.com... > There was some blog saying that when there're no 64-bit (or any?) > video drivers for the video card, 64-bit Vista (and maybe earlier 64- > bit Windows too) simply emulates the VGA/VESA BIOS instructions since > there's no way to execute the BIOS code directly when the machine has > switched into 64-bit mode (need to switch all the way back into 32-bit/ > v86 or real mode). There's also the Scitech x86emu... I think what surprised me the most was that they had a number of modern OSes running somewhat (in private...). The idea that DOSBox could with modifications be used like QEMU is also intriguing. I'm wondering if it would be faster than regular QEMU (without kqemu). It seems like there is much more code to execute, but since many DOS games run properly - it has to be faster than regular QEMU which seems a bit slow to me. > > (Qbix) "The emulation of the mouse, EMS, XMS and DOS happens with C/C++ > > code and not Assembly. This makes DOSBox different from other full PC > > emulators (and results in a lot of free conventional memory). To make this > > possible we have introduced an extra CPU instruction that isn't present on a > > real CPU. When this special instruction is emulated, DOSBox looks up the > > next instruction which contains a number of which C function should be > > executed. (All those C functions are stored in a table with their number). > > This makes it possible for us to code a mouse driver in C (which is > > easier/faster to write than ASM) and make it behave like a real loaded mouse > > driver. From these functions it is possible to read and modify the emulated > > CPU registers and the emulated memory. This system is also used to emulate > > most of the BIOS and VIDEO BIOS functions." > > It's quite normal. Except, I don't think inventing instructions was > necessary. True. I like that idea though. If I read that correctly, an entire C function or C program becomes one emulated instruction. I haven't looked, but it might be interesting to see how many patches they made into the BIOS or VIDEO BIOS functions... I wonder, what BIOS and video BIOS are they using?... host PC? BOCHS BIOS? I'll have to take a look. IIRC, one of the early C64 emulators for the PC did it that way. It was very clean. Only a few (IIRC, two) patches to one of the two ROM images (C64 and 1541). Apparently MS' NTVDM does something similar to run under WinNT/2k etc. Supposedly, MS-DOS 5.0 is patched with 0xC4 0xC4 sequences. I'm not sure if you caught the post, but I posted what I could find online of the 0xC4 0xC4 sequences and available info here: http://groups.google.com/group/alt.lang.asm/msg/5aaa8f198d5075fe Makes one wonder if someone has NTVDM working on non-MS OSes... But, I guess there's no point in aggravating MS over NTVDM when FreeDOS and DR-DOS is available. Rod Pemberton |