VOGONS


First post, by DOSferatu

User metadata
Rank Newbie
Rank
Newbie

Dear developers of DOSBox!

At first: I don't want to mock around that much. DOSBox is a great tool and you've done great work Oh, and please apologize my English - for I'm German (so English is not my native language).

Oh, and I don't really know anything about bug reports - I hope my text isn't too long.

But, recently I've found some kind of bug in your CPU emulation - or better: A friend of mine, testing one of my self-written tools - in DOSBox (because he don't own a real DOS machine) - found a bug. At first he thought, it's in my tool (and I thought it, either, because of: who humble I am and who expert are the DOSBox developers?) ...

But testing the special part revealed: my tool worked fine in real DOS. Even a test program, using the same opcodes, worked fine in real DOS. Furthermore, both - my tool AND the test program - work fine with DOSBox setting core=dynamic. But with core=normal or core=simple (and core=auto, which I think chose normal/simple in that case, too) the bug appears.

After some research in the mighty Internet about what the "core"-settings do in DOSBox, it makes total sense to me: setting "dynamic" compiles the code into real machine code, so the real CPU does the work here. The other settings make an emulation of the opcodes - and hereby maybe something wrong happens.

The bug(s) are happening with the commands ROL and ROR (rotate left/right) - and only, when it is done at a memory location - not in a register: The behavior corresponding the setting of the CARRY flag is wrong then when someone uses a rotating-count with X lower bits zero when the value is X bits wide. That behavior is (from 80386 and above) totally right - with values of 32 bits. But the "AND 01fh" to the rotate-count happens always, even if the value to be rotated is just 8 or 16 bits wide! So, it is totally "legal" to make something like:

rol byte ptr[cs:1234h],8

At first, it would SEEM to make no sense to rotate an 8-bit memory value 8 times, because the value will stay the same doing so. BUT - the carry flag is set (and has to be set!) as if the whole 8 rotations were done. Why? Because it is an easy way to copy the MSB or LSB (bit 7 or bit 0 in this case) into the carry flag without making some other "stunts" and it works for 8-bit and 16-bit values even on 80386 and above (despite the "masking out" of the upper 3 bits of the rotating-count value since 80386 - the lower 5 bits are still used, nonetheless of the bitwidth of the data to be rotated)

For rotating REGISTERS, DOSBox does it the right way - in ALL settings of core (dynamic, auto, normal, simple). But for rotating memory locations, DOSBox fails, if the lower 8 or 16 bits of the rotating count are zeroes and the value to be rotated is only 8 or 16 bits wide - in this case (except with "core=dynamic"), DOSBox does the CARRY flag ALWAYS SET (=1), even it was clear before and even if the value to be rotated is 00h / 0000h (=all bits zeroes). That is definetely wrong.

Maybe someone tried some kind of "speed hack" here or something. That should be still possible:

rol byte ptr[xxxx],8 -or- rol byte ptr[xxxx],16
should copy bit 0 (LSB) of xxxx into carry.

ror byte ptr[xxxx],8 -or- ror byte ptr[xxxx],16
should copy bit 7 (MSB) of xxxx into carry.

rol word ptr[xxxx],16
should copy bit 0 (LSB) of xxxx into carry.

ror word ptr[xxxx],16
should copy bit 15 (MSB) of xxxx into carry.

I've added a small test tool (for 8-bit values) and some of its output files:
ROLROR.EXE - the tool
MSDOS622.TXT - output from a real machine with real MS-DOS v6.22
DYNAMIC.TXT - output from DOSBox with core=dynamic
AUTO.TXT - output from DOSBox with core=auto
NORMAL.TXT - output from DOSBox with core=normal
SIMPLE.TXT - output from DOSBox with core=simple

Output of the tool uses standard MS-DOS functions, so redirecting output this way is possible:
ROLROR.EXE >example.txt

I hope I didn't bother you all too much - but I guess, an emulation should be correct.

Sincerely,
DOSferatu

Attachments

  • Filename
    ROLROR.zip
    File size
    50.57 KiB
    Downloads
    3 downloads
    File license
    Public domain

Reply 1 of 8, by jmarsh

User metadata
Rank Member
Rank
Member

This was fixed a while ago: https://sourceforge.net/p/dosbox/code-0/4256/

Are you using an up-to-date build?

(The BT instruction is a better choice for shifting bits into the carry flag if you have the option to use it, since it doesn't issue a write.)

Reply 2 of 8, by DOSferatu

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2020-02-08, 02:44:

Are you using an up-to-date build?
(The BT instruction is a better choice for shifting bits into the carry flag if you have the option to use it, since it doesn't issue a write.)

Probably I wasn't aware of a new version. I will test it soonly. (Thanks for the mention.)
And I'm aware about BT, but sometimes it needs more cycles. Nevertheless - an emulator bug has to get fixed, because it may cause some unpredictable behavior of emulated software.

So, I've downloaded, installed and tested the current version v0.74-3 - and: The bug is still there.
(I don't compilate dosbox sources - or ANY sources, I download the installers including the EXE-files.)
I got it from https://sourceforge.net/projects/dosbox/files/

So, either a do something wrong here (maybe this isn't the most current version there?) or the bug is still around.
You can test it with my little tool (rolror.exe - source is in rolror.pas) and redirect it into a file (see above).
With any other option for core= except for dynamic, (i.e. auto, normal, simple) the bug still appears.
Easiest way to "fast-find" in the produced output file to check, if the bug happened, is to search for an ! (exclamation mark). The ! are only used if excepted data mismatches the received data.

Sorry, I'm new here and I won't do "hassle around" here.
But, in my opinion, coding shouldn't be done to "match functions/disfunctions" of an emulator, but to match the real (original) machine. So coding with "avoiding tricks" to "ship around emulator's bugs" is not the proper way.
The original machine/cpu should be the reference for an emulator - wether stupid or intelligent code has to be executed.

Reply 3 of 8, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The bug is fixed in SVN (the up to date sourcecode) so you have to either build it yourself or grab a precompiled build. It's not in a release yet.

But, in my opinion, coding shouldn't be done to "match functions/disfunctions" of an emulator, but to match the real (original) machine. So coding with "avoiding tricks" to "ship around emulator's bugs" is not the proper way.
The original machine/cpu should be the reference for an emulator - wether stupid or intelligent code has to be executed.

You need to be aware of Dosbox' goal: that is playing Dos games in a fast way, giving great audio and graphics. It's not meant to be a full Dos machine emulator. Because that is costing you speed for no gain in playing Dos games.
For full Dos emulation use bochs, dosemu, pcem...

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 4 of 8, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Attached an SVN exe. Try it to see if it fixes your game issue.

Emulation requires processing power. DOSBox runs on more processors than just an i7.

/EDIT Removed due to possibly old version of SVN.

Last edited by DosFreak on 2020-02-08, 18:40. Edited 2 times in total.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 5 of 8, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Here's a different build. Prior might be older.
Attached is the build from my compilation guides thread from 1-28-2019 so not completely functional but enough for this.

Attachments

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 6 of 8, by DOSferatu

User metadata
Rank Newbie
Rank
Newbie
Dominus wrote on 2020-02-08, 11:52:

The bug is fixed in SVN (the up to date sourcecode) so you have to either build it yourself or grab a precompiled build. It's not in a release yet.

I'm just a humble "oldschool" coder - I don't use or even own some "modern" compilers - and even when, I wouldn't know how to use them... That's all to freaky and overkill to me (for being me that ancient kind of coder).
(I'm still using Borland's Turbo Pascal v7.0 - and, of course, MUCH of the build in assembler in the last over 20 years or so. All the "386 and above" code I do directly by inserting the corresponding bytes (TP asm can only up to 286) ... and so on... - You know, the kind of pascal/asm coding people had done 25 years ago...)

But, in my opinion, coding shouldn't be done to "match functions/disfunctions" of an emulator, but to match the real (original) machine. So coding with "avoiding tricks" to "ship around emulator's bugs" is not the proper way.
The original machine/cpu should be the reference for an emulator - wether stupid or intelligent code has to be executed.

You need to be aware of Dosbox' goal: that is playing Dos games in a fast way, giving great audio and graphics. It's not meant to be a full Dos machine emulator. Because that is costing you speed for no gain in playing Dos games.
For full Dos emulation use bochs, dosemu, pcem...[/quote]
I'm really aware of DOSBox' goal. But:
Well, technically it's not about games or tools or demos or whatever. Technically they are all just programs, consisting of code (x86 code DOS programs, in this case). Thus, every piece of code may contain every combination of opcodes and parameters - there aren't any opcodes or opcode/parameter combinations which are "not to be used in games" or so. Thus, fixing an emulator's bug - whether found in a tool, in a game or in some self-written piece of junk - will also help to fixing some games that weren't running before.

And, while I myself still using the real hardware - but I'm appreciating the existence and usefulness of DOSBox (for being able to run my stuff on the windows computers I've also here - being a "computer nerd" I don't have only ONE computer, you know...) - and I know MANY people out there using DOSBox not just only to run old games, but also to run old (or new) 16bit tools or even CODE tools in DOSBox, well, because DOSBox, despite meant to play old games with it, is much better than just only "a game platform" - for many reasons. (For example: unpack and put it and all its files into a directory and it runs - no "installing" and "spreading all its contents over your whole system". And with manually editable configuration files and so on. All the things real DOS users/"fans" like so much about it.)

So, please don't mistake my little notice/bug report for some kind of a rant - I just wanted to help.

Note at the end: I just downloaded the compiled version, DosFreak was so kind to make and attach here.
And - it works! (Yeah!)

At last, a little question:
I'm not really familiar of the work processes of the DOSBox developer guys: So, please apoligize my (maybe stupid/redundant) question: Is there a plan/schedule of when new versions are released? - With, kind of "every 10 another fixed issues a new official version is released" or "Every birthday of one of the developers" or "When the moon is full and the Mars is in its zenith" or such? Or is it just as simple as "Every quarter of a year"? And, is there some kind of... black board or such, where someone can notice if a new official release is available?

Reply 7 of 8, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

The problem is users and companies using DOSBox when they shouldn't be running their power plant, HVAC, etc using a game emulator and then blaming DOSBox for their issues and expecting free support. It's difficult enough supporting thousands of old DOS games which no one cares about without supporting thousands of programs that aren't games as well. The more code that is added to DOSBox then the larger DOSBox becomes, the more code that has to be reviewed and supported, etc.

Even with DOSBox just supporting games there are differences of opinions on what to add. No one really cares about compatibility, they just want their feature added for their specific OS and specific game without regard to any other issues.

WID. The last official release was 0.74-3 which was 0.74 but with mostly non-game fixes added for security and compilation issues. Next release is in testing. You can download the SVN code and compile or download a compiled binary from emucr or wherever until then.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 8 of 8, by DOSferatu

User metadata
Rank Newbie
Rank
Newbie
DosFreak wrote on 2020-02-09, 14:20:

The problem is users and companies using DOSBox when they shouldn't be running their power plant, HVAC, etc using a game emulator and then blaming DOSBox for their issues and expecting free support...

Oh, it was meant only as some kind asking - I'm NOT demanding (or expecting) anything.