VOGONS

Common searches


Set cycles to specific xt/at/386/486/586 speed.

Topic actions

  • This topic is locked. You cannot reply or edit posts.

First post, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

Someone had asked about setting XT speed exactly, but since DOSBox doesn't do exact, I made some simple batch files to set to system speeds based on rough measurement. Written to also accept MHz as an argument, but alas, DOSBox doesn't handle set /a, so currently statically set to xt@4.77, at@8, 386@20, 486@33, & Pentium@75. Look at the batch files to change these static settings.

Update. Added /a handling to set, patch attached, and updated the attached batch files with un-rem'ed versions. With the patch applied, you can now pass mhz as an argument, "xt 16," "386 40," "586 233," etc. Without an argument the batch files set the default.

Attachments

  • Filename
    setcpu.rar
    File size
    1.32 KiB
    Downloads
    444 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    set.diff
    File size
    1.45 KiB
    Downloads
    308 downloads
    File license
    Fair use/fair dealing exception
Last edited by ih8registrations on 2008-10-09, 09:05. Edited 1 time in total.

Reply 2 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

PPS, it calculates and can take floating point as input but returns integer, which is a complaint of the real /a. It works out perfectly for this use since it calculates the original 4.77 MHz and dosbox only uses integer for cycles setting.

Reply 3 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

Playing with ANSI color, and added some reference.

Attachments

  • dosbox_000.png
    Filename
    dosbox_000.png
    File size
    5.42 KiB
    Views
    4980 views
    File license
    Fair use/fair dealing exception
  • Filename
    setcpucolor.rar
    File size
    2.17 KiB
    Downloads
    200 downloads
    File license
    Fair use/fair dealing exception

Reply 4 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

Ah, I've discovered the K "erase to the end of the line" escape sequence!:) What I've been looking for to fill the set color to the end of the line. Can add/make changes without dealing with line ends, and makes the batch files cleaner.

Attachments

  • Filename
    setcpucleanedup.rar
    File size
    2.05 KiB
    Downloads
    188 downloads
    File license
    Fair use/fair dealing exception

Reply 5 of 74, by MiniMax

User metadata
Rank Moderator
Rank
Moderator

You can streamline the BAT-files a bit (basically use the same bat-file with different names) by doing something like this:

@   echo off

if "%0" == "at.BAT" goto setat
if "%0" == "AT.BAT" goto setat
if "%0" == "xt.BAT" goto setat
if "%0" == "XT.BAT" goto setat

goto end

:setat
set cpu=AT
set cpucycles=6
set dosboxcycles=94
goto display

:setxt
set cpu=XT
set cpucycles=4.77
set dosboxcycles=58.28
goto display

:display
echo cpu=%cpu%
echo cpucycles=%cpucycles%
echo dosboxcycles=%dosboxcycles%

:end

DOSBox 60 seconds guide | How to ask questions
_________________
Lenovo M58p | Core 2 Quad Q8400 @ 2.66 GHz | Radeon R7 240 | LG HL-DT-ST DVDRAM GH40N | Fedora 32

Reply 7 of 74, by ADDiCT

User metadata
Rank Oldbie
Rank
Oldbie

Eh... i don't get it. I had a look at the batch files, and it seems they simply set some environment variables, and certain "cycles" entries. I can't see how this is supposed to be an "all-around" solution. I don't think DOSBox' cycle-setting scales with the host's CPU power. This means that, for example, in order to reach specific "real PC" speed, you'll need different "cycles" settings on different systems (different CPU's, like P4 vs. C2D for example). There's already a way of setting "cycles" via the command line, AFAIK.

I was thinking about a way to set cycles independantly from the host system speed, and it should be possible to do. If there would be a way of including a set of simple benchmarking tools into DOSBox, we could generate reference numbers for "real" (metal) DOS systems, and then set the "cycles" according to the benchmarking results. Am i making any sense? (; To describe it plainly: create benchmark (preferrably CPU-based), run it on different "real" DOS systems, note the resulting numbers, run the same benchmark on an emulated system, and set cycles until the benchmark reports (more or less) the same numbers. This could be done in some kind of one-time "calibration" app inside DOSBox.

Unfortunately, i can't code at all, and thus can't implement the idea in software.

Reply 8 of 74, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

dosbox it's cycles don't depend on the host pc.
for some info on the problems though read this page (and my post on it)
http://forums.steampowered.com/forums/showthr … t=733169&page=3

Water flows down the stream
How to ask questions the smart way!

Reply 9 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

Not that I trust your sincerity, but to answer the question anyway, as I explained in the first post, the resulting settings are based on rough measurements. The batch files take emulated system speed as input, or uses the default, and multiplies by the rough measurement of the given system. DOSBox cycles are equivalent to an emulated system regardless of host. Host speed only determines how much load on the host system is required to attain a given DOSBox setting, and if not fast enough will fall short of achieving the set DOSBox speed. The batch files do set /a cycles=%dosboxcycles%*%cpucycles%. dosboxcycles being the rough measurement of how many dosbox cycles there are to one emulated xt/at/386/486/586 cycle, and cpucycles the desired emulated machine cycle setting. As for rough, the estimates could possibly be made more accurate with some more testing, but they will never be truly accurate since DOSBox doesn't count cycles on an opcode basis, so some are faster/slower compared to a given emulated machine even when set to that level overall, and things are really out of whack when it comes to FPU, DOSBox is running the FPU way faster. Ironically?, on XT machines, the FPU ran slower than the CPU. So, this is as good as it gets until someone adds cycle counting per opcode to DOSBox.

As for your I see no point of the batch files. One, it's much easier and faster to type and remember "xt" or "xt 8" than "cycles fixed 277," and two, setting by system has context from personal association and game options, like "tandy" or "ps/2" or "mcga"(why I added the reference info to the output.)

Reply 10 of 74, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I experimented with using the classic Dhrystone and Whetstone synthetic CPU benchmarks to approximate cycles settings for DOSBox. Trying to adust cycles in DOSBox so the benchmarks matched historical records of old machines (I used a PC @4.77mhz) resulted in cycles that seemed too fast by almost double in a cycle-sensitve game (I used Digger for my experiment). I figure it will always be hit-and-miss with such approximations, depending on how closely a particular game matches the mix of instructions used in a synthetic benchmark.

Dhrystone & Whetstone benchmarks for DOS: http://freespace.virgin.net/roy.longbottom/ol … #anchorBenchDOS

Reply 11 of 74, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

The only 100% way is to have DOSBox monitor the game while the person is playing it and then upload the results. If a person plays a game for a long enough time (say an hour....although idealy to completion). Then once they are done the results could be uploaded.

Results would contain:

Name of game
version of game
game configuration
DOSBox version
DOSBox configuration
Host hardware
Host processes and memory load
etc.

Then either built into DOSBox or the frontend it would scan these results for the specific game and give you a choice or automagically select it.

This would be the "easiest" way. No gamer today is going to know what a "pcjr" "tandy" 486dx/66, P90 is or what the performance is like. They MIGHT possibly read the documentation for an old game and MIGHT set DOSBox for that configuration but only like 5% of DOSBox users would actually do that.

How To Ask Questions The Smart Way
Make your games work offline

Reply 12 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

FYI, I used a combination of benchmarks to come up with the estimates. As for "no gamer today," as I said, personal association and game options. It's a lot less arbitrary to get familiar with xt, at, 386, etc, and many game configuration suggest what to go with. If you're selecting tandy or pcjr sound or video or mcga video, you can surmise from the output of running "xt" of what to go with to match the speed. I don't imagine a database is going to be integrated into DOSBox anytime soon, and I believe individual game/program configurations are rather the point of frontends, that's what they do. These batch files ease the use of setting DOSBox for those vaguely aware to the familiar, not for the completely inept. That this is command line, not point and click, should have given that away. ie. you're applying the wrong audience to these batch files(any batch file is wrong for that audience.) The audience you speak of can stick to their frontends. As for the target audience, there's plenty of DOSBox users who use the command line, these batch files are to their benefit.

Reply 13 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

Fixed the handling of /a to be specific, "/a " at the beginning of the line, and ran into an issue with another check in set. There's a test for "==" which is puking on setting a variable with spaces in the value. It still completes even though it's written to fail, but it spews error messages in the process, mucking up the output. Commenting it out makes things happy, but if the check is wanted, will have to figure it out.

Rewrote the batch files so that there's now a setcpu.bat that does all the handling, and the xt/at/etc bats only set variables.

Finally, redid the display in the style of old microprose games startup selection.

Attachments

  • Filename
    setcpurevamped.rar
    File size
    1.55 KiB
    Downloads
    179 downloads
    File license
    Fair use/fair dealing exception
  • Filename
    set2.diff
    File size
    1.69 KiB
    Downloads
    170 downloads
    File license
    Fair use/fair dealing exception

Reply 14 of 74, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

There's a test for "==" which is puking on setting a variable with spaces in the value.
did you test real dos for that ?
Our current code isn't perfect (patch on sf.net),
but you are working in IF there
and if "a b" == "a b"
doesn't work in real dos.
So where do you exactly need it for ?

Water flows down the stream
How to ask questions the smart way!

Reply 15 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

The issue comes up when variables are set to values that have spaces in them. From setcpurevamped.rar:

xt.bat:

set info1=8088@4.77MHz PC, XT, PCjr, Tandy 1000

setcpu.bat:

if %info1% == "" goto displayend2
echo [1;37;44m[A
echo ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»[K
echo º º[K
echo [A[1C %info1%

Works in XP(seperate issue, but just to note, XP requires quotes around %info1% in the if, where DOSBox doesn't.) As you'll notice, I do an empty check, not "a b"=="a b". Out of curiosity, I tested such, which showed it works in XP, but not in DOSBox(falls through even if different.) So.. curiosity has revealed DOSBox could still use some more fixing, but in the meantime, empty check works.

Reply 16 of 74, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

if "a b" == "a b" dir

doesn't work in MSDOS 5.0.
So I see no reason why DOSBox should support it. I have to test MSDOS 6.x though.
XP isn't really dos.

Water flows down the stream
How to ask questions the smart way!

Reply 17 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

For variables set to values with spaces, the only thing I've done was to get rid of the error message, the handling is unchanged. It comes down to the benefit of having the error message vs the benefit of not having it. Not having the error message allows writing the batch files as I've done, which is cleaner, simplified. With the error message, batch files have to be written to work around it, which are more cluttered. You can't pass info strings, so you'd have duplicate the info handling in each file, or add all the info to setcpu.

Reply 18 of 74, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The quotes around the variables are there to make matches against empty variables possible. they are not markers to allow spaces. (which we did in 0.72) (the current Stripword at the bottom of CMD_IF will go away in the CVS and be replaced with a space searching loop)
So you can do
if "%DRIVE" == "" set DRIVE="C:"
Treating "" as command to allow spaces could break constructs like this. Or we have to complicate the checks to allow an empty string as argument.
Maybe it is allowed in variables. but it certainly isn't allowed when typing on the shell.
I don't want to risk breaking things with weird installers

Water flows down the stream
How to ask questions the smart way!

Reply 19 of 74, by ih8registrations

User metadata
Rank Oldbie
Rank
Oldbie

What? Two additional separate issues. One, I only mentioned the need for quotes for the left side of if in relation to XP, it doesn't affect what we've been talking about. Two, it's never been asserted or anyway suggested to use qoutes for spaces. "" is valid DOS, not handling that would break batch files. The set diff only does two things, gets rid of that error message so it doesn't mess up the screen, and adds handling of basic arithmetic, which doesn't affect anything.

Last edited by ih8registrations on 2008-11-01, 14:42. Edited 1 time in total.