VOGONS


First post, by RayeR

User metadata
Rank Member
Rank
Member

Hi,
I was noticed that DOSBox supports CPUID instruction and returns CPUID as 486 processor. But when I try to run my CPUID info program it tells me no CPUID is supported. I use a test if CPUID is supported when checking if bit 21 of eflags is writable (i found this method in various code on internet, see below). Would be possible to patch DOSBox code to respect this behavior and make bit 21 of eflags writtable?

pushfd                  ; save EFLAGS
pop eax ; store EFLAGS in EAX
mov ebx, eax ; save in EBX for later testing
xor eax, 00200000h ; toggle bit 21
push eax ; put to stack
popfd ; save changed EAX to EFLAGS
pushfd ; push EFLAGS to TOS
pop eax ; store EFLAGS in EAX
cmp eax, ebx ; see if bit 21 has changed
jz NO_CPUID ; if no change, no CPUID

Reply 2 of 14, by RayeR

User metadata
Rank Member
Rank
Member

I have no special need of CPUID but I just want to notice when it is supported it should be implemented correctly.
Some guy sent me mail that tried to run my CPUID program also in DOSBox just for fun and it didn't worked while some other programs show CPUID. So we treace the problem and it is in different CPUID support detection routine.

Reply 3 of 14, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The correct way to identify whether cpuid is present or not is to
see if that ID-bit can be toggled. Under dosbox it can't (it's always
set) so it behaves like 386s and early 486s, which is just fine for
the games that dosbox targets at.

Reply 4 of 14, by RayeR

User metadata
Rank Member
Rank
Member

OK.

BTW do you plan to support higher CPUs? Maybe some latest games/demos/progs will require some 486/pentium features.

But I'd rather to see DOSBox support dualcore CPUs (if it can gain performance) 😀

Reply 7 of 14, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well we're not aiming at pentium+ compatibility at the moment 😉
I'd like to have a #define that switches between 386/486/pentium
(different flags behaviour, pagefault privileges, instruction differences)
but Qbix didn't like it too much so the aim is to run everything <586.
The rdtsc-requiring game wasn't worth adding it imo...

Reply 8 of 14, by icemann

User metadata
Rank Member
Rank
Member

Since dosbox is a games emulator above all else, then how come adding that in isn`t worth it?

Even if 2 games benefit its that bit closet to 100% compatibility.

Two stones, two crosses, the rest is just icing. - 7th Guest

Reply 9 of 14, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

What 2 games?

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

Reply 10 of 14, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

then how come adding that in isn`t worth it?

Because it was some really crappy game and i don't have a clue what it was called.
Feel free to add it to your sourcetree, instructions are above.

Reply 13 of 14, by cfoesch

User metadata
Rank Newbie
Rank
Newbie

RDTSC should't be hard to implement, just return dosbox cpu cycles in EDX:EAX:

That is not how RDTSC works, it returns real-time not cycle time. If DOSBox were to run at a variable rate, then just returning the cpu cycles done so far would then return the wrong value, and introduce clock drift.

Reply 14 of 14, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Well it returns "ticks" or "cycles" or however it may be called, and since games either
measure the tsc distance against a real time measure using rdtsc as a quick way to
get high resolution timing, or just require an always-increasing timer, the dosbox cycles
should work fine. If you know of a game that takes measurement otherwise but relies
on rdtsc, or misbehaves because of the current implementation, please post.