Uhm let's see.

first of all 66000 cycles is maybe a bit too high.
Sound might not be of the best quality when using the dynamic core.
So try the regular core (normal) with much less cycles.

the soundblaster 16 is backwards compatible with earlier models although you can order dosbox to emulate an older model as well. (sbpro for example is the one used in 0.61 and 0.60) Just look in dosbox.conf.

the Mem command in dosbox is accurate enough for what you are doing. I was probably refering to the shared ems/xms pool. Dosbox has more than enough low memory free. Maybe even too much!
you could try loadfix -8 before starting the game.

you should try overlay as output. not opengl. opengl might result in stutering sound.

old versions of dosbox are available on the download page incase you want to try them.

The number of cycles does NOT correspond to Mhz on the real computer... There is no direct relation between number of cycles and Mhz (it depends on what the game is doing).
You also refer to a build mine - not sure what you mean... I may have done a few public builds, but as far as I remember it was when trying something on beta board...
In any case I have not done any public build recently...
Or is there another "mirekluza"?

Mirek

Thank you both for your help. (And for creating and upgrading DosBox, etc, etc (that's enough slavish noobism on my part for the moment, at least to my taste, and should ward off all but the most very-fearsome of the forum-trolls (Did I say that aloud?))).

To explain, I typically use about 20,000 cycles (I tried many different settings, in increments of about 500, some weeks ago, and it seemed best). Part of the problem was that I might have tried these with Direct3D mode, though, which seemed much faster taking into account its higher resolution, but which (I suspect because of the uselessness of my LCD or some other factor) can't seem to support any lower resolution than about '800x600' (effectively a very-pixellated 1024x768 after the bizarre remapping).

I use surface mode always, after trying all the others (direct3d was also useful, if one can stand the pixellation at higher fullscreen resolutions (I didn't like the performance hit from the shaders/scalars). I think overlay doesn't allow a small fullscreen resolution (similar to the original game), at least on my useless lcd (only supports 1280x1024, 1024x768, and 800x600; everything else results in 'input not supported' error). (Of course, I've always used fixed fullscreen res in the conf as well, so it must be a monitor or driver problem (am using nvidia drivers ~78.03, so it must be some other drivers which don't allow it to function properly)). Should I install a newer version of directx? The current version I use is directx 9.0c, but may be about a year old.

Another question: Recently I downloaded a (possibly new) version of the driver for my monitor just in case, but somehow, windows doesn't recognize the .inf file as a valid driver. (Error message to that effect). How do I make it do so? I've tried all the standard methods from device manager, found new hardware wizard, etc. Sorry if this is rambling. I'd considered the proverbial 'consulting the manufacturer', but the chances of a reply make the attempt seem somewhat dubious, or less than hopeful.

My question as regards sound blaster was: can I (with the right software or drivers) trick Arena into 'thinking' (sorry if I state this misleadingly) a Soundblaster Audigy 2 is a SoundBlaster 16, provided that Creative makes its soundcards backward-compatible, or is this what DosBox already does? My question is: if this is not how DosBox functions (I assume it emulates an entire soundcard (e.g. sb16 or earlier) wholly by software, and then outputs results to windows audio service/etc), then could there possibly be added a sort of throughput (similar to those for serial port/mouse/joystick/etc) the user can choose if he has a (modern) card made by Creative? Could this then eliminate need among soundblaster-users for (presumably slower?) software emulation of legacy soundblaster cards? It's more a feature request than anything else, except that DosBox might already function in this way. (?) Or is this too 'virtual pc'-ish and not really the purpose of an emulator? Or should I 'consult Creative'? 😀

I only stated 66000 cycles in case I should want the emulator settings to most closely match the requirements of the original game. I wasn't yet clear about what cycles meant, so thank you for explaining.

I apologize for calling the build Mirekluza. It was actually Gullikoza. I've tried the adaptive core-speed setting in this build, and it seems to help. It generates smoother sound, but warps the time of the sound more, since it accelerates or decelerates with the core speed.

One question: how do I determine the optimal core speed, apart from sound and animation? My idea is that I don't want to unnecessarily restrict the core to slower speeds where unnecessary, since in rain, fog, snow, shadow, or night-time this results in extremely lagged performance, but also don't want it so fast that under ordinary unmodified daylight conditions, animations and monster movement are much faster than intended. This was why I asked about cycles earlier, and whether they corresponded to actual mhz.

I've tried tweaking most every setting (particularly those I understood after reading threads here or those which didn't require additional software or drivers) in dosbox.conf several weeks ago. I think the reason I didn't typically use normal core speed was that I couldn't achieve high cycles, and assumed high cycles (~33,000 or 66,000) were necessary to accurately emulate the original game. Thank you for clearing this up. I will try normal again, and see how it runs.

I tried version 0.60, and somehow it was slower with the same configuration settings. I'm not sure why. Anyway, it was worth a shot.

Also there were new versions of Gullikoza and Ykhwong builds, so I tried these. Gullikoza seems noticeably faster than before, and has !new features!. Not to disappoint, I'll be sure to query everyone within range about each of them in just a minute. 😀

In the meantime, what is this 'loadfix -8' you speak of? Is it an emulated dos command, or specific to DosBox, and what is its effect? (Should I reread the faq, in case I've forgotten?)

About new features under Gullikoza August 29, 05 build: mostly I wanted to know about UMB. I understand that it provides access to upper memory area (above 640k), and may be (?) another scheme for managing additional memory, akin to EMS and XMS, and recall the old dos command 'dos = loadhigh, umb', which I mostly used rather unwittingly solely on the premise that loading dos into high memory was GOOD and leaving programs to run from lower memory was BAD, but I don't understand what effect setting <UMB> to <max> in the conf file of Gullikoza's (or for that matter, Ykhwong's) new build would have. (There are three settings: true, false, and max, for UMB, if I recall). Please explain if possible. Which should be used under given conditions?

Also, the original minimal requirements for Arena indicate 2 mb of EMS and 4 mb ram. Does this imply that I don't need XMS emulation, or may even hinder or hurt performance by enabling it? I forget how this works specifically. Aren't they independent memory-managers? How to learn if Arena uses XMS? Or does the fact that it requires 2 EMS and 2 extra ram imply that it must necessarily use XMS (or some other memory manager)?

Another question: if DosBox has 634 kb of lower memory free and 63 or 64 mb additional extended/expanded free, is this the total for its own operation plus that of programs running under DosBox. or solely for other programs? This has always confused me. Is there a hidden option somewhere to increase (actual) ram+vram usage for DosBox shell so as to conserve processing power, or to somehow swap ram/vram usage for processor usage? (I've already changed setting in conf to 63 mb). Or does emulation require heavy use of processor merely by nature?

Another question: does the adaptive speed configuration (for example, 'cycles <= 60000') under Gullikoza build work only with the dynamic core, or with the normal core as well?

One last question, again surely entirely off-topic and superfluous. (Sorry to be long-winded). Is it worth buying the newer versions of moslo, or are all of them equally buggy and useless? (even provided one uses them with VDMSound or similar). I can only find a demo for version 1.5, which can't run batch files (hence is questionable for arena, which always executes through a batch file after installed (in practice an old version (2.1 from ~1997, which permits use of batch files, packaged with ultima series) ran choppily)), so I don't know if the newer versions (3.x, for instance) are actually useful.

A few clarifications:
I stated: Should I disable advanced text services and other options in the pif file for dosbox?
What I meant is: or is this done by default by dosbox itself, or is it harmful, or else unnecessary?

Since the sound artifacts usually occur when I navigate a menu or click to select something, would using a serial/com passthrough for mouse input be useful, and if so, how to set this up?

Should I try Gravis/Timidity for sound, and if so, which version of Timidity is optimal? Would installing gravis drivers/timidity cause conflicts or other difficulties with existing drivers or softare for actual official soundcard?

Thank you for your patience.

well technically and now I know why there is no support for all those experimental features.
So disable automatic cycle updating.
Changeoutput to overlay and then find your optimum cycles!
Best is to change the decoder(core) to normal.

When you have done that then you can report your problems again.
If they aren't fixed by that.

the 63 mb setting is for games running inside dosbox. Dosbox itself takes more than that.
umb shouldn't really matter. I think true is fine enough. The lack of documentation is a work in progress

XMS can technically be bad for the performance but in dosbox there is no overhead if xms is on or off when using ems memory.

Gravis/timidity have nothing in common in dosbox.
timidiy is a midi emulator for linux.
Gravis is a type of emulated soundcard in dosbox.