On Sun, 13 Jan 2002, Peter Jay Salzman wrote:
> are the variables:
>
> $_sb_base = (0x220)
> $_sb_irq = (5)
> $_sb_dma = (1)
> $_mpu_base = "0x330"
>
> supposed to be emulated variables or are they supposed to reflect the
The emulated settings. DOSEMU doesn't talk to the hardware directly - it
uses the standard OSS interface (under Linux) These are simply so it knows
where to place the emulated hardware. The defaults correspond to the
"standard" location of the SoundBlaster card.
> also, someone on the list sent me email saying that he thinks the sound
> code in dosemu is completely broken, as in, dosemu can't utter a peep
> right now. but he wasn't sure. is this pretty much the situation for
> dosemu 1.1.2?
Depends upon the application, how well behaved it is, and how many bugs
there are in the emulation in the area that the application uses. I don't
normally release the code for inclusion in a release unless it at least
does *something* useful on my system. However, that doesn't mean that it
will do the useful thing that everybody else wants.
>
> lastly, when i run redneck rampage, it bails with the following message:
[...]
> i'm at an utter loss -- i don't know how to diagnose something i can't
> understand. can someone guess as to what's happening?
Use the debug settings in DOSEMU to get a record of what the application
is trying to do. There are lots of options so that you can fine tune the
list of things that it looks at. Don't forget to output the log to
something so that you can check it. If it then looks like a bug in DOSEMU
then send a compressed copy of the log in a bug report to this list.
(Ideally, don't use full debugging - just send the relevant parts of the
log) If the log file is huge, even after compression, then the best thing
is to put it on a web/ftp site somewhere and put a URL in the bug report.
Alistair
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
