Page 1 of 1
Time goes fast in Bochs
Posted: Mon Nov 12, 2007 7:22 pm
by Dandee Yuyo
Hi, I'm facing a problem with Bochs, and maybe someone ran into this before. I don't know if I'm doing something wrong or if it's simply a bochs issue.
Very early in my kernel I read the CMOS date and time and after reprogrammed the 8259 to map IRQ above the one's reserved by Intel. I installed an ISR to service the timer IRQ (the one that click 18.2 per second), and the result is that the time is going darn fast on bochs.
I tried on QEMU and real hardware and is working OK dough.
Has someone seen this before?
I also noticed that the A20 line seems to be always enabled in both emus...
Posted: Mon Nov 12, 2007 7:52 pm
by JackScott
http://bochs.sourceforge.net/doc/docboo ... SOPT-CLOCK
That will explain the clock running at the wrong speed. It appears that in the current version there is no way to fix it (edit: documentation out of date?). But it is an explanation at least. Essentially Bochs doesn't bother 'hlt'ing when you wait for an interrupt... it just creates the interrupt straight away.
As for the A20, no idea. I use GRUB.
Posted: Mon Nov 12, 2007 7:58 pm
by frank
I think that
does a good job of slowing down the simulation to close to normal time.
Posted: Mon Nov 12, 2007 8:30 pm
by Dandee Yuyo
Thank you guys. I'll give a try to the realtime setting.
Posted: Mon Nov 12, 2007 8:50 pm
by Dandee Yuyo
frank wrote:I think that
does a good job of slowing down the simulation to close to normal time.
It didn't work. All I got is this (I'm running a Windows build)
Code: Select all
========================================================================
Bochs x86 Emulator 2.0.2
January 21, 2003
========================================================================
00000000000i[ ] reading configuration from bochsrc.txt
00000000000p[ ] >>PANIC<< bochsrc.txt: directive 'clock' not understood
00000000000i[SYS ] Last time is 0
00000000000i[ ] restoring default signal behavior
========================================================================
Bochs is exiting with the following message:
[ ] bochsrc.txt: directive 'clock' not understood
========================================================================
00000000000i[CTRL ] quit_sim called with exit code 1
[/code]
Posted: Tue Nov 13, 2007 3:48 am
by Combuster
How about using the latest version...
Posted: Tue Nov 13, 2007 3:58 am
by AndrewAPrice
I wish time actually went fast in Bochs rather than just the clock. In Bochs my memory manager takes around 3 seconds to initialise (it sets up page tables and bitmaps), but happens seemingly instantly on every other emulator and on real systems.
Posted: Tue Nov 13, 2007 4:27 am
by Combuster
You'll have to tweak these numbers to get some performance:
Code: Select all
# 60 fps (ips / vga_update)
vga_update_interval: 100000
# 6 MHz processor
cpu: ips=6000000
# slow down the clock to match processor
clock: sync=slowdown, time0=local
iirc ips and update_interval are by default rather low - if you up ips alone it will not help as it will spend relatively more time redrawing the screen. Depending on what you want, you should compute the vga update to be somewhere between 1 fps and 100 fps.
Posted: Tue Nov 13, 2007 6:54 am
by AndrewAPrice
Combuster wrote:
Code: Select all
# 6 MHz processor
cpu: ips=6000000
I can understand why now, thanks! I wonder who's design decision it was to make the processor default at 6 million instructions per second?
Posted: Tue Nov 13, 2007 10:50 am
by Combuster
I wonder who's design decision it was to make the processor default at 6 million instructions per second?
Ahem, that was from MY config file
- just a suggestion what you should be aware of...
Posted: Sat Dec 15, 2007 2:11 am
by bewing
Combuster wrote:How about using the latest version...
Didn't somebody mention something about making a sticky thread for Bochs-related stuff, somewhere? I can't find it. I'm compiling the most recent version, and there are 11 compiler warnings that worry me some. (If you ignore the hundred warnings about signed/unsigned assignments.) The one that worries me the most is:
Code: Select all
unsigned long op1_32, diff_32;
diff_32 = -op1_32;
That is the actual code that the current ver of Bochs uses to calculate all NEG opcodes. Isn't using negation that way "undefined behavior" in C/C++? I personally have no idea how any of my compilers will respond to that code.
So, in general, my question is: I have seen a few people mention recently running into Bochs bugs. Are they in the current version (2.3.5)?
I know that 2.0.2 had several deadly ones.
Posted: Sat Dec 15, 2007 2:43 am
by inflater
@Combuster: So why this syntax...
Code: Select all
# 60 fps (ips / vga_update)
vga_update_interval: 1500000
# 90 MHz processor
cpu: ips=90000000
# slow down the clock to match processor
clock: sync=slowdown, time0=local
makes the update interval too slow? I tried also "sync=realtime" but it the same as "slowdown".
The CPU in PortixOS is detected now as 90 MHz, but a real Pentium I hadn't response time >1200 ms...
Posted: Sat Dec 15, 2007 5:05 am
by Combuster
inflater wrote:@Combuster: So why this syntax...
Code: Select all
# 60 fps (ips / vga_update)
vga_update_interval: 1500000
# 90 MHz processor
cpu: ips=90000000
# slow down the clock to match processor
clock: sync=slowdown, time0=local
makes the update interval too slow? I tried also "sync=realtime" but it the same as "slowdown".
The CPU in PortixOS is detected now as 90 MHz, but a real Pentium I hadn't response time >1200 ms...
Three things:
- The host processor must be well in the GHz to actually be able to emulate a ~100MHz processor
- The pentium is pipelined and can do 2 instructions per clock
- You still have the overhead of 60 redraws / sec which take significant time. If you have tried the likes of DOSBox which has a similar ips/fps configuration you might have noticed that you can get up to 30% more performance by lowering the number of frames that are actually drawn. Try increasing the VGA update interval to lower the FPS.
If you're still unsatisfied, get a virtual machine instead of an emulator.
Posted: Sat Dec 15, 2007 7:58 am
by mystran
Just reprogram the PIT and it'll work. It's just the default setting that's off.