Time goes fast in Bochs
- Dandee Yuyo
- Member
- Posts: 47
- Joined: Fri Nov 09, 2007 6:46 pm
- Location: Argentina
Time goes fast in Bochs
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...
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...
NaN - Not a Nerd
Working on: Physical Memory Management with a 5-lod mipmap XD
Working on: Physical Memory Management with a 5-lod mipmap XD
- JackScott
- Member
- Posts: 1036
- Joined: Thu Dec 21, 2006 3:03 am
- Location: Hobart, Australia
- Mastodon: https://aus.social/@jackscottau
- Matrix: @JackScottAU:matrix.org
- GitHub: https://github.com/JackScottAU
- Contact:
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.
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.
Last edited by JackScott on Mon Nov 12, 2007 8:08 pm, edited 1 time in total.
I think that
does a good job of slowing down the simulation to close to normal time.
Code: Select all
clock: sync=realtime
- Dandee Yuyo
- Member
- Posts: 47
- Joined: Fri Nov 09, 2007 6:46 pm
- Location: Argentina
- Dandee Yuyo
- Member
- Posts: 47
- Joined: Fri Nov 09, 2007 6:46 pm
- Location: Argentina
It didn't work. All I got is this (I'm running a Windows build)frank wrote:I think thatdoes a good job of slowing down the simulation to close to normal time.Code: Select all
clock: sync=realtime
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
NaN - Not a Nerd
Working on: Physical Memory Management with a 5-lod mipmap XD
Working on: Physical Memory Management with a 5-lod mipmap XD
- AndrewAPrice
- Member
- Posts: 2309
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
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.
My OS is Perception.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
You'll have to tweak these numbers to get some performance:
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.
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
- AndrewAPrice
- Member
- Posts: 2309
- Joined: Mon Jun 05, 2006 11:00 pm
- Location: USA (and Australia)
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?Combuster wrote:Code: Select all
# 6 MHz processor cpu: ips=6000000
My OS is Perception.
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:Combuster wrote:How about using the latest version...
Code: Select all
unsigned long op1_32, diff_32;
diff_32 = -op1_32;
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.
@Combuster: So why this syntax...
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...
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
The CPU in PortixOS is detected now as 90 MHz, but a real Pentium I hadn't response time >1200 ms...
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Derrick operating system: http://derrick.xf.cz (Slovak and English )
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Three things:inflater wrote:@Combuster: So why this syntax...
makes the update interval too slow? I tried also "sync=realtime" but it the same as "slowdown".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
The CPU in PortixOS is detected now as 90 MHz, but a real Pentium I hadn't response time >1200 ms...
- 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.