(OT but good to see you here madmab, your work on xbox is amazing! all your ports give new life to the machine!)

I just noticed this in the readme file.

Q: The sound stutters or sounds stretched/weird.
A: You're using too much CPU power to keep DOSBox running at the current speed.
You can lower the cycles, skip frames, reduce the sampling rate of
the respective sound device (see the DOSBox configuration file) or
the mixer device. You can also increase the prebuffer in the configfile.
If you are using cycles=max or =auto, then make sure that there no
background processes interfering! (especially if they access the harddisk)

[mixer]
nosound=false
rate=22050
blocksize=2048
prebuffer=10

So is this one thing I should consider? Which is best to start with? prebuffer or blocksize?

Thanks

keropi wrote:

(OT but good to see you here madmab, your work on xbox is amazing! all your ports give new life to the machine!)

Didn't see you're reply at first.

Thanks.. Dosbox has been alot of fun, even if it gives me a headache at times.

get a better CPU

robertmo wrote:

get a better CPU

I'll be sure to tell microsft to send me one to put in my xbox.

i think the only option in all consoles is to buy a new version, so xbox360 in your case

@robertmo:

since you obviously have no idea about madmab's work, please stop this now.

If the mt32 emu patch is using current munt then there is the problem. Last time canadacow messed with munt he changed some stuff which resulted in much higher cpu needs.
Btw. for ultima underworld I'd advise using the cm32 roms...

any reason why you are not running on auto cycles ?

Anyway. Dosbox generates at regular intervals sound in advance for the callback of SDL. The scheduling of those intervals depends on a few parameters, but scheduling itself depends on the cycles. if they are too high the scheduler can't keep up. (so there is no sound ready when SDL calls, then if there is a little too little dosbox stretches the sound. If there is a lot too little dosbox simple ignores the call. (eg. repeating/stuttering of the sound)
DOSBox increases the rate of sound generation then, but that sound generation is an adaptive process, so when there is a too much sound ready, the rate is lowered again.

The parameter prebuffer determines the size of the buffer of sound that dosbox pregenerates on top on the normal SDL required amount of sound samples. This amount of sound samples is the blocksize.

http://www.dosbox.com/DOSBoxManual.html
"At present, DOSBox running on a high-end machine will roughly be the equivalent of a Pentium I PC."
Dark Forces is a Pentium I game indeed,
but PIII 733 MHz is definitely not a high-end machine, it is not even a machine, it is a museum exhibit.

http://en.wikipedia.org/wiki/Xbox

Unfortunately console systems are a little hard to upgrade. But thanks for the suggestions from those who actually read my post more carefully. I know full well my PC with a higher processor can run games far better than the measely xbox. But it's not the pc code that I am currently working on.

As for the cycles=auto. I'll have to look into that more closely. If I remember it was causing the xbox to crash, but a quick debug session might shed some light as to why.

Thanks for the info qbix.. That was the impression I was getting from reading the code but I wanted to confirm with people who are more familar with the dosbox code and how it works.

So basically upping the cycles is stealing time from the mixer code to do it's thing so it's compensating in the manner you mentioned which seems consistent with my experiences.

I know already that the mt32 code is a bit slow (for what it's worth I'm currently on .072) so would the .072 mt32 code have these changes that slow things down?

As for ultrasound code does it require a little more "umph" then the soundblaster code?

Thanks again..

if there are small moments of breaking up (e.g caused by the game executing every 10 seconds more complex to emulate instructions than in the other seconds), then I would advice on increasing the prebuffer as that should catch small deficiencies in the scheduling. However if the scheduling is constantly in problems, then there is no choice but to lower the cycles. (although quite a few systems benefit from a small blocksize as well.))

You can modify the mixer code if you want, the conditions on what to do are for a large part based on our feeling what works best. For example, slowing down the rate with which dosbox lowers the sound generation rate, might help you.

BTW: maybe check the 0.74 sources for the main loop (that does the auto scheduling (in dosbox.cpp). there have been improvements/changes in that quite a bit)

I think the main problem with the Xbox port is that it's ancient, based on 0.65 IIRC. The slow CPU and low amount of memory doesn't help either I'm sure. I have no idea about coding on that level, but maybe it's possible to update the emulation "core" to a more recent DOSBox version? I guess that'd be the only "clean" solution for better performance. This is only an educated guess: you may be able to achieve slightly better performance by fiddling with the sound emulation related stuff, but I think you'd have to tackle the emulation core to achieve really noticeable improvements. It is by the way possible to upgrade the Xbox' CPU (and memory), but that's not a feasible option for casual users.

It's basically the same for all Xbox emulators. They basically have been unchanged since Xport lost interest in the platform, bar frontend changes which may look pretty but do nothing for emulation performance and compatibility. Don't get me wrong, I'm sure many people appreciate madmab's work, but I'd rather have the emulation cores updated properly than having "holes plugged" by updating bits and pieces of code.

EDIT: from the "DOSXBox 286/386 PC Emulator port for XBox v5" readme:

- Implemented DosBox 0.62 sources

That's the last reference to the DOSBox source version used in the Xbox port.

I already updated the core to .072 and got the dynamic recompiler working. See my fourth post.

I also tried .074 but it uses more memory than .072 and thus makes it impossible to play games that need up to 20 megs of RAM (command and conquer series and a couple other games). I already got the emu running several games the previous release didn't even have a chance of playing

I updated the atarixlbox core some time back, made numerous fixes to the core in a7800x in addition to adding things, as well as adding two whole new sound cores to AdamX, overlay support (for AdamX and BlissX) and fixed the Intellivoice in BlissX. Plugged a memory leak in winuaex, fixed the DF0: problem, tweaked the "clip excess borders" feature, fixed the disk mounting issues that plagued winuaex, and added auto config database and preset controllers to make it easier for newbs to use Winuaex.

Added in gamegenie and pro action replay cheat code support in Mekax. Gamegenie and action replay support, fixed the black border at the bottom of the screen in some games, added multiplayer 5 support, support for PAL roms in Snes9x. I am also currently implementing core updates for pcsxbox including improving the CDDA audio playback. Improved the stuttering issue with Vice64. Fixed lock-up problems with rewind on Neogenesis. At least now it is useable.

On all Emus.. I Added in better samba support for those who prefer to keep their files elsewhere (including in the gamebase 64 for Vice64) and fixed the garbage produced by the software filters. So we hardly have "frontend" changes going on here.

Suffice it to say that updating a core is more work than you think and the xbox is already pushing the limits of what it can do so a core update is not always practical (see xboyadvance as an example). Sometimes on a limited architecture (like the xbox, wii, etc) using the latest core is not always practical.. Updating the core is not always the best solution.

Heh... Where to begin.

It wasn't clear from your post that you've sucessfully implemented the 0.72 DOSBox core, nor was it clear that you have a working DOSBox dynamic core (which should speed up the emulation quite a bit). From reading your post it sounded more like you've implemented the mt32 functionality from DOSBox 0.72. Looks like a misunderstanding to me (; . Also, I didn't say that updating an emulation core is easy. What I said is that I believe it's the only way to achieve a noticeable performance increase.

I have my reasons for thinking that you need to implement a recent DOSBox version in order to get substantial better performance. I've been using DOSBox on a P4/2.6Ghz for quite a while, and the one thing that really made a difference in respect to performance was an upgrade to a new DOSBox version. IIRC I've used three DOSBox builds on the machine, and the performance got better with every upgrade.

The next thing that had a substantial impact on performance was the output method. I don't know which method the Xbox build is using, but the best performance on Windows comes from using either DDRAW or (even better) D3D. D3D is not a "standard" output method though, it's a patch that has been developed by (I think) Gulikoza.

These two factors - DOSBox build and output method - will influence DOSBox' performance more than anything else I believe. As the Xbox is basically a PC running with a cut-down version of the NT kernel I believe it acts similar to a slow-ish PC, that's why I assume my P4 experiences apply to the Xbox. If memory on the Xbox is an issue, you could maybe offer two "emulation cores", like with the N64 and PSX emulators.

Well, I have actually tested an upgraded version of DosXbox by Madmab and yes it's currently a genuine core update. Like he told you before, the core changed from 0.62 to 0.72 and yes, I can see a significant difference on the xbox regarding compatibility and performances.
Adding MT-32 emulation, is one of the new features he's trying to implement these days. And that's the main subject of this topic.

And regarding Xport emus, I think you're wrong. Most had important improvements and not only eye candies like you seem to consider, which is a bit unfair. Let's not forget that the xbox has limited resources and it's great to have what we have now. For instance, I'm a keen user of Winuaex and i can tell this port gives me more satisfaction than using E-UAE on my Mac. But let's avoid any controversy and stick to this interesting subject instead.

I just wish to see the best Dosbox port possible on my good old console. 😉

🤣, here come the fanbois. You're basically confirming my theory about how to achieve better emulation speed (this is what the thread is about, after all) anyway, so what's your effing point.

By the way, you are aware that MT-32 emulation is not officially a part of DOSBox, aren't you? I think the patch has been done by Gulikoza. Quote from Gulikoza's website:

- Munt (MT32) - updated to latest Munt code, made mt32 code threaded (this should greatly speed up Munt running with dosbox); you might have problems running MT32 on a single core cpu!

. If you want to hear my opinion (which you probably don't want to, but I'll voice it anyway (; ): if I had to choose between a well performing emulator without MT-32 emulation, and a not-so-well performing one with MT-32 emulation, I'd pick the one without MT-32. The large majority of "interesting" DOS games is SB compatible anyway, so MT-32 is more "nice to have" than "must" IMO. GM support (possibly something like Timidity with soundfont support) would be more interesting I'd say, but is probably hard to implement on the Xbox.

Why do you feel the need to be insulting ?

The difference between you and me is that I'm actually testing this new emu and I know what I'm talking about. So please keep you're theory for yourself. We see enough tire kickers all days...

And regarding your opinion on sound quality, you can do whatever you want. Anyways soundblaster's FM sound is awful to hear. So if I can chose GUS or MT32, I chose it.

Now let's end this please. Looking for constructive suggestions so we can move forward...

GUS and MT32 sound is by far better than SB sound and both only affect the core "performance" when a game is actually setup to "use" them. So adding them does not affect anything except give all the "fanboi's" out there more choice.

Isn't munt a totally seperate project? I'm using the mt32 code included in the SVN core?

And I know full well that mt32 is not officially part of dosbox. But I also know that my question is perfectly legit because it applies to GUS emulation as well and can be answered well within the confines of the "official" release.

Now can we get back on topic please?

mt32 emulation is very demanding currently, so if you really need some music
maybe target the 0.74 default adlib code (which the very most people know from
"back then" due to the widespread nature of adlib-compatible cards and games).