VOGONS


First post, by Fizzban

User metadata
Rank Newbie
Rank
Newbie

Hi.. 😀

I have found out why Orion Burger (and a few other games) works fine with UniVBE but the display is truncated after the first 65536 pixels with the built-in VESA driver.

The VBE2.0 specifications for the function "Display Window Control" says to set DX to the "Window number in video memory in window granularity units". However, in the actual VESA implementations, only the value of DL is processed.

That's why Orion Burgerjust sets DL and leaves DH to its current value.. which happens to be 1, so the value of DX is always much too high and the DOSBOX implementations of the function fails.

After changing the function so it just uses DL, the game works fine without UniVBE. I have attached a diff with my changes.

Attachments

  • Filename
    VESA_SetCPUWindow.diff.txt
    File size
    1.06 KiB
    Downloads
    417 downloads
    File comment
    Diff to current CVS
    File license
    Fair use/fair dealing exception

Reply 1 of 9, by Jiri

User metadata
Rank Member
Rank
Member

Thanks, Fizzban. 😀 Seems that another group of "unplayable" games could change the status. I´m looking forward to test the games affected by this vesa problem after the implementation of your fix to CVS.

UPDATE: I´ve compiled DOSBox and tested it. I can confirm that with this fix SciTech Display Doctor is no more needed for Orion Burger, Riddle of Master Lu and Chronomaster. On the other hand, as you have already mentioned ( Mouse driver: Maximum virtual coordinates ), the movement problems persist, so these games are not yet playable.

Upadate2: With a new fix from Fizzban ( FPU: FPATAN incorrectly implemented ) everything works. 😁

Reply 2 of 9, by whyneed2register

User metadata
Rank Newbie
Rank
Newbie

hello there...
i'm just a bit curious... but how the heck do you do it Fizzban?

in such a short time you solved some wicked issues/bugs.... it's just that, since you don't belong to the Dosbox develop team, the at-ease with the code and the solving of the wicked bugs kind of impressed me...
a lot of assembly experience and many nights in front of a debugger ?

(note: i'm not trying to diminish the work of the Dosbox team, or make it less impressive in any way... i'm very greatfull for the work of the team, and i do find it quiet impressive... making an emulator/vm is no easy task... thx guys 😁 )

ps: if this post seemed lame... excuse me... 😒 😢 😖 but this question was killing me...

Reply 3 of 9, by Jiri

User metadata
Rank Member
Rank
Member

Could somebody from developers look at "int10_vesa.cpp" please?

Vesa has been fixed according to Fizzban´s instructions, but "dx" seems to be still there instead of "dl".

< else reg_ah=VESA_SetCPUWindow(reg_bl,reg_dx);
---
> else reg_ah=VESA_SetCPUWindow(reg_bl,reg_dl);

In new RJPA´s compiled DOSBox those games with vesa problem do not work correctly and this could be the cause. I´m not a programmer, so sorry if I´m wrong.

Reply 7 of 9, by Jiri

User metadata
Rank Member
Rank
Member

Strange. The day when Fizzban posted his vesa info I downloaded source from http://pcnwstage.phys.rug.nl/ manually changed the lines according to his instructions, compiled DOSBox and picture was perfect. Now I downloaded RJPA´s build from 13.1. (I presume he does not use outdated source) and the display is still truncated after the first 65536 pixels. I do not get it. So I will compile DOSBox from actual source and post here the result.

Reply 8 of 9, by Jiri

User metadata
Rank Member
Rank
Member

The problem is in fact in that RJPA´s CVS build dated 13.1. (strange, since vesa fixes are from 11.1.) and my speculations were incorrect. In DOSBox I´ve compiled myself those games work well. Thank you for your quick reply and explanation, Harekiet.

Reply 9 of 9, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

the source generation was broken for a couple of times I noticed in my mailbox. Maybe the source download was of a slighty older date.

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