OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Games => Topic started by: Martin Iturbide on December 18, 2020, 12:37:15 am
-
Hi
I was not able to run Drilling Billy for OS/2 (beta) (https://www.os2world.com/forum/index.php?action=dlattach;topic=2016.0;attach=3403) and I recently got time to check Dave's suggestions.
Try doing SET VESADLL=VESA_IBM or SET VESADLL=VESA_ALL in your full screen session before running os2billy. Can also try vesatest.exe
Still doesn't quite work here. Vesa.txt includes instructions to patch your video bios if you're really adventurous.
PS Running "markexe NOTWINDOWCOMPAT os2billy.exe" will force it to open a full screen session.
I created (on Arca OS 5.0.4 VM) a copy of the OS/2 "Command Prompt (Full Screen)" and added on Environment. First with SET VESADLL=VESA_IBM and later with SET VESADLL=VESA_ALL. No luck. Is it on "Environment" right?
Vesatest.exe gives me a message that says "VesaInitialize failed".
About "markexe NOTWINDOWCOMPAT os2billy.exe" where is markexe? I have never tried it.
Any other tips? Just trying to see if I can make os2billy.exe.
Regards
-
Hi
I was not able to run Drilling Billy for OS/2 (beta) (https://www.os2world.com/forum/index.php?action=dlattach;topic=2016.0;attach=3403) and I recently got time to check Dave's suggestions.
Try doing SET VESADLL=VESA_IBM or SET VESADLL=VESA_ALL in your full screen session before running os2billy. Can also try vesatest.exe
Still doesn't quite work here. Vesa.txt includes instructions to patch your video bios if you're really adventurous.
PS Running "markexe NOTWINDOWCOMPAT os2billy.exe" will force it to open a full screen session.
I created (on Arca OS 5.0.4 VM) a copy of the OS/2 "Command Prompt (Full Screen)" and added on Environment. First with SET VESADLL=VESA_IBM and later with SET VESADLL=VESA_ALL. No luck. Is it on "Environment" right?
If you mean the Environment tab of the programs properties, leave out the set, eg VESADLL=VESA_IBM
Vesatest.exe gives me a message that says "VesaInitialize failed".
About "markexe NOTWINDOWCOMPAT os2billy.exe" where is markexe? I have never tried it.
It should be included with the toolkit and likely other places. Run markexe.exe /? for usage.
Any other tips? Just trying to see if I can make os2billy.exe.
Regards
-
Hi
If you mean the Environment tab of the programs properties, leave out the set, eg VESADLL=VESA_IBM
Thanks, I noticed that the "Environment Tab" it automatically takes out the SET. I tried both without any improvements.
I'm still missing to give it a try to "markexe", I will see what happens.
Regards
-
Hi
"markexe NOTWINDOWCOMPAT os2billy.exe"
markexe was good to run os2billy.exe in full screen at once. Its nice to learn a new thing :)
But the game still does not run. I get this message.
Vesa ikke initialiseret.fatalfejl
engine.exit without initCEngine::exit() completed succesfully.
DosMonReg()=382
According to the DosMonReg documentation (http://www.edm2.com/index.php/DosMonReg) it is "382 - ERROR_MON_BUFFER_TOO_SMALL "
FYI: Here it the file list.
12-18-20 10:50a <DIR> 528 ---- .
12-18-20 10:45a <DIR> 10,144 ---- ..
12-18-20 10:49a 0 0 a--- aflus.log
11-24-20 7:44p <DIR> 529 ---- all
11-24-20 7:44p <DIR> 531 ---- baner
5-12-98 1:21p 518,283 405 a--- billy.exe
8-21-97 10:54a 27 420 a--- bosanski.bat
8-21-97 10:54a 25 418 a--- català.bat
11-24-20 7:44p <DIR> 532 ---- constr
8-21-97 10:54a 24 417 a--- dansk.bat
11-24-20 7:44p <DIR> 528 ---- db
8-21-97 10:54a 26 419 a--- deutsch.bat
7-15-97 11:30a 265,396 418 a--- dos4gw.exe
8-21-97 10:54a 26 419 a--- english.bat
8-21-97 10:54a 26 419 a--- español.bat
8-21-97 11:25a 271 421 a--- esperanto.bat
12-18-20 10:49a 116 0 a--- fejl.log
8-21-97 10:54a 27 420 a--- français.bat
8-21-97 10:54a 27 420 a--- føroyskt.bat
8-21-97 10:54a 25 418 a--- galego.bat
8-21-97 10:54a 27 420 a--- hrvatski.bat
8-21-97 10:54a 27 420 a--- italiano.bat
11-24-20 7:44p <DIR> 532 ---- jungle
8-21-97 10:54a 27 420 a--- magyarul.bat
8-21-97 10:54a 29 422 a--- nederlands.bat
8-21-97 10:54a 24 417 a--- norsk.bat
12-18-20 10:49a 614,404 420 a--- os2billy.exe
12-18-20 10:50a 1,582 0 a--- out.txt
8-21-97 10:54a 25 418 a--- polski.bat
4-12-97 12:25a 4,170 246 a--- readme
4-11-97 11:50p 2,769 284 a--- readme.os2
8-21-97 10:54a 25 418 a--- româna.bat
11-24-20 7:44p <DIR> 533 ---- samples
8-21-97 10:54a 26 419 a--- serbski.bat
7-15-97 11:30a 46,396 420 a--- setsound.exe
11-24-20 7:44p <DIR> 534 ---- settings
8-21-97 10:54a 25 418 a--- srpski.bat
8-21-97 10:54a 33 426 a--- srpskohrvatski.bat
8-21-97 10:54a 24 417 a--- suomi.bat
8-21-97 10:54a 26 419 a--- svenska.bat
11-24-20 7:44p <DIR> 508 ---- text
2-10-95 9:05a 32,090 248 a--- vesa.txt
2-16-96 2:35p 44,606 386 a--- vesatest.exe
2-06-96 5:56a 20,764 304 a--- vesa_all.dll
2-06-96 5:55a 19,176 303 a--- vesa_cl.dll
2-06-96 5:55a 51,996 304 a--- vesa_clh.dll
2-06-96 4:52a 11,965 304 a--- vesa_et4.dll
2-06-96 5:54a 19,178 304 a--- vesa_et5.dll
2-06-96 5:54a 20,736 304 a--- vesa_et6.dll
2-06-96 5:55a 19,688 303 a--- vesa_s3.dll
2-06-96 5:54a 19,178 304 a--- vesa_tr8.dll
2-06-96 5:55a 19,176 303 a--- vesa_wd.dll
Any tip to make os2billy.exe run is welcome. I'm trying it on a test VM, so I have no worries to experiment more things.
Regards
-
I get a very different error:
I get a trap in VESA_ALL.DLL (the only DLL that actually makes sense these days). It's trying to write to a NULL pointer.
The log file tells me it's because VESA_ALL.DLL thinks I am running 800x600, 8-bit color depth where I am running 1920x1080, 32-bit color depth.
This program is completely out of date. I guess, you would need to rewrite VESA.DLL but there is only an list on which routines it contains but not how these actually work. Seemingly, there used to be source code for the VESA drivers (by the author Johannes Martin) but it has likely vanished into thin air and forgotten in the myths of time.
-
Actually, I found the source code for the various VESA DLLs:
https://hobbes.nmsu.edu/download/pub/os2/dev/emx/contrib/vesa19.zip
-
The log file tells me it's because VESA_ALL.DLL thinks I am running 800x600, 8-bit color depth where I am running 1920x1080, 32-bit color depth.
The full screen session probably was running at 800x600x8. The question is whether your (and Martins) video bios or perhaps the driver, supports enough of the VESA stuff to run the game.
Running SNAP might help as Scitech got started by supplying a universal VESA driver for DOS games.
-
I tried this. With VESADLL=vesa_all.dll the vesatest program runs fine and seems to see all my video resolutions. Trying to run os2billy.exe gives the error "Unable to set videomode nr 65535" twice.
-
vesatest.exe also works on my system, that's not going to help.
By looking at the source code I can take an educated guess that it already traps on loading the DLL. I would need to build vesa_all.dll with the VAC toolset and debug into it. Maybe I will have the time to do that.
I don't think SNAP will make a difference: I am using GENGRADD which is also a GRADD driver and SCREEN01.sys provides basic video bios support that will hopefully suffice. Don't forget that this game was written when Warp3 was out, but Merlin and newer had added a lot of generic video support.
-
...as an example, VIDEOPMI.DLL offers support to execute any vesa bios interrupt call in real mode.
Maybe vesa_all.dll needs to be modified to use all that newer support.
-
Well, it never trapped here, just not initializing the correct video mode. My Bios supports some pretty high resolutions in VESA mode which usually aren't supported.
The gdb debugger worked pretty well with EMX, if rebuilding with current GCC, and the right flags (-Zomf -g) gcc builds can be debugged in the IBM debuggers. Whether the source will build with current GCC hasn't been tested but most EMX stuff with minor makefile editing does build.
-
Hi
vesatest.exe was not working for me.
I set the OS/2 Full screen session "VESADLL=vesa_all.dll" on environment as suggested. vesatest is now working showing that full list with numbers.
os2billy.exe says:
Drilling Billy demo V1.12 Apr 14 1997...
Unable to set videomode nr 65535.
Unable to set videomode nr 65535.
Just like it was reported.
Thanks for you help. This hacking is out of my knowledge, let hope something can be worked out.
Regards
-
Might want to reboot with 256 colours and test.
-
Might want to reboot with 256 colours and test.
I tried it as you told me. Set the colors to 256, rebooted, the desktop looked 256 awful :) , run OS/2 command line full screen with "VESADLL=vesa_all.dll".
OS2Billy gave me the same error:
Drilling Billy demo V1.12 Apr 14 1997...
Unable to set videomode nr 65535.
Unable to set videomode nr 65535.
Regards
-
Well, it never trapped here, just not initializing the correct video mode. My Bios supports some pretty high resolutions in VESA mode which usually aren't supported.
The gdb debugger worked pretty well with EMX, if rebuilding with current GCC, and the right flags (-Zomf -g) gcc builds can be debugged in the IBM debuggers. Whether the source will build with current GCC hasn't been tested but most EMX stuff with minor makefile editing does build.
Hi Dave,
are you sure that the VAC debugger can source code debug objects produced by EMX/GCC ?
As far as I understand, the -Zomf only creates object output in OMF format ("Microsoft") instead of ELF(?) ("Unix") which helps in using a different linker (for example the VAC linker or the WATCOM linker) instead of the EMX provided linker. But I think gcc still creates debug info that is incompatible with the CODEVIEW or HLL debug info that the VAC debugger can understand and interpret.
Or are you actually source code debugging Seamonkey and the like ?
-
Hi Dave,
are you sure that the VAC debugger can source code debug objects produced by EMX/GCC ?
Just tried with a cmd application (wpa_supplicant) and yes I now can source code debug with idebug. Thanks for the tip Dave.
-
Not sure about EMX/GCC but for kLIBC/GCC (basically all GCC versions above 3.3.5), yes it uses HLL debug info and mostly works in the IBM debuggers. I understand that there are slight problems at times with how the stack is handled and dmik had to work around GCC's object format of AOUT not having big enough fields for some of the HLL stuff creating warnings like,
20:00.87 emxomf warning: Input file 'K:\var\temp/ccTjZZujasXXXXXX' has more HLL
debug types than we can index in PUBDEF and EXTDEF records.
but it generally works in the debugger. Unluckily I don't really know much about using the debugger.