Thanks for your answer.
Here is the debug log in attachement. I disabled the debug on the screen shot I sent because I noticed I could get a bit more memory without it. With the debug on, I got : Banked Window 416K at 3800:0 segment and a free memory of 15680K
I'll try to find what confuses C-DOS. It reacts a bit strangely... When I add or remove options from the SeaBIOS, the memory avalaible change and the size of banked window changes too. So I hoped there was a way to have enough memory to run my application... Otherwise, I will have to stuck with Qemu 0.11 and PC-BIOS.
Do you know if there is any DOS utility to get the memory map ?
Thanks,
Alain
________________________________ On Mon, May 07, 2012 at 08:58:45AM -0700, Alain Ribière wrote:
Hello,
I have a memory trouble with an old DOS OS from Digital Research
called Concurrent DOS.
It worked fine till Qemu v0.11.1. I
use Qemu to make a legacy application run without any modification.
Starting with Qemu 0.12, my legacy application has not enough memory to run. Actually it seems that the SeaBIOS doesn't use the same memory mapping than PC-BIOS used to, causing trouble to my application.
Is there any way to get SeaBIOS use (more or less) the same memory amount and memory mapping than the older PC-BIOS ?
I tried to recomplie SeaBIOS 1.7.0 with less options but the result is the same.
When reporting an issue with SeaBIOS, please include the log obtained when running qemu with "-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios".
I took a quick look at this, and I don't think this is a memory size issue - the screenshots actually show that running under seabios makes more memory available (15664 vs 15648). Instead, I'd guess concurrent dos is not making a "banked window" that is large enough. I don't know why the memory segments between 0x0b00 and 0x3400 aren't being used. There is no legacy bios interface to reserve memory under 1meg, so I'm sure SeaBIOS isn't doing this wrong. Indeed, SeaBIOS is much more careful about touching ram under 1meg than Bochs bios is.
So, I'd guess something unrelated is confusing concurrent dos and the above is just a symptom of the problem. Unfortunately, I don't know of any way to track that down without source code for the image and spending a large amount of debugging time.
-Kevin
