Page 1 of 1
Bochs, Floppy, DMA and memory issues?
Posted: Thu May 08, 2008 10:09 am
by Ready4Dis
Well, I have been working on this floppy driver for some time now, trying to figure out why I have gotten no error codes from Bochs, yet it still displays nothing on screen when I print the contents of the boot sector. Well, I tried it on a real pc, fixed a few small timing issues, and it works fine. Tried it on bochs again, displays nothing. Here comes the really weird part, if I change my DMA memory address from 0x10000 to anything else (well, i only tried like 5 different addresses, 0xf000, 0x11000, 0x30000, and a few others) and it works like a champ. I have read the low memory tables from many sources, and 0x10000 should be fine. If I write a byte to 0x10000 and read it back it is fine. Has anyone every witnessed something like this before? Like I said, it only happens in bochs, not on a real PC. Also, that byte that I wrote to 0x10000, even after my read call, it still stays set to whatever I set it to, so it appears the buffer is never being filled in by bochs. Everything looks good when I suspend my program and check the dma file, the settings are correct (page = 0x01, offset = 0x0000, mode =1, etc, it looks exactly the same as when I do 0x30000 (except page = 0x03 instead).
Re: Bochs, Floppy, DMA and memory issues?
Posted: Fri May 09, 2008 10:48 am
by stlw
Ready4Dis wrote:Well, I have been working on this floppy driver for some time now, trying to figure out why I have gotten no error codes from Bochs, yet it still displays nothing on screen when I print the contents of the boot sector. Well, I tried it on a real pc, fixed a few small timing issues, and it works fine. Tried it on bochs again, displays nothing. Here comes the really weird part, if I change my DMA memory address from 0x10000 to anything else (well, i only tried like 5 different addresses, 0xf000, 0x11000, 0x30000, and a few others) and it works like a champ. I have read the low memory tables from many sources, and 0x10000 should be fine. If I write a byte to 0x10000 and read it back it is fine. Has anyone every witnessed something like this before? Like I said, it only happens in bochs, not on a real PC. Also, that byte that I wrote to 0x10000, even after my read call, it still stays set to whatever I set it to, so it appears the buffer is never being filled in by bochs. Everything looks good when I suspend my program and check the dma file, the settings are correct (page = 0x01, offset = 0x0000, mode =1, etc, it looks exactly the same as when I do 0x30000 (except page = 0x03 instead).
I would suggest you to open a bug report for Bochs. Attach your example, which works on PC with sources and if it Bochs issue it will be fixed soon.
Stanislav
[email protected]
Posted: Fri May 09, 2008 2:12 pm
by bewing
Hi Stanislav,
I would really like to know one thing about the bochs bug reporting process. How old can our version of bochs be, before you will ignore the bug report as being for an "obsolete" version? Sometimes I think I should report a bug, but I do not want to go through the process of downloading / compiling / installing the most recent version of bochs -- in order to see if the bug is already fixed. I am currently using 2.3.5 from September ... is that too old?
Bruce
PS. I also had to slightly mod my bochs source so that it would compile on MSVC 5. Are you interested in those mods? And would I submit them as a "bug report"?
Posted: Fri May 09, 2008 9:53 pm
by Ready4Dis
Thank you for the info about the bug reporting, however my project is pretty large and to strip it down to just the floppy disk driver would be very cumbersome. For now, I just set that page as in use and allow my memory manager to bypass it. My example is very large, as it's part of my OS, and my floppy disk driver is just that, a driver that is loaded as a module from my OS. There is a lot of supporting code, so not sure if that will help or not. I may try to strip it down sometime, but for now I can work around it easily, and it runs on multiple real PC's, so i'm not to concerned, but the offer is appreciated.
Posted: Sat May 10, 2008 2:59 pm
by stlw
bewing wrote:Hi Stanislav,
I would really like to know one thing about the bochs bug reporting process. How old can our version of bochs be, before you will ignore the bug report as being for an "obsolete" version? Sometimes I think I should report a bug, but I do not want to go through the process of downloading / compiling / installing the most recent version of bochs -- in order to see if the bug is already fixed. I am currently using 2.3.5 from September ... is that too old?
Bruce
PS. I also had to slightly mod my bochs source so that it would compile on MSVC 5. Are you interested in those mods? And would I submit them as a "bug report"?
In general it takes VERY long time for bug report to become obsolete. One should prove the bug is already not exists or part of the emulator code related to the bug report should go other some major change. Otherwise the bug report will remain open forever.
Another reason to remove bug report - when it can't be reproduced and the person who opened bug report disappeared for a long time. After year 'can't be reproduced' bug usually removed.
About 2.3.5 - I suggest you to go to CVS already. I measure it 2.5x faster and list of bug fixes in the CPU model is more than 100 bugs fixed.
Between 2.3.6 and 2.3.6 the speedup is 1.5x and around 20 bugs fixed. But also 3 newly added
Stanislav
[email protected]