"Port" the code to Open Watcom

volkertb / vbe-ai-sdk

VBE/AI SDK and example sources, source code published with permission of VESA

Other

4 stars 0 forks source link

"Port" the code to Open Watcom #1

Open volkertb opened 3 years ago

volkertb commented 3 years ago

Currently, the C/C++ code in this project is dependent on the far and pascal keywords as supported in Borland C++.

It would be nice to have it work with open source DOS C/C++ compilers as well, notably Open Watcom. By extension, that might eventually also allow this code to be built with gcc-ia16, since @tkchia intends to add Open Watcom compatibility to that compiler as well.

tkchia commented 3 years ago

Hello @volkertb,

Here is my first cut attempt at getting play.c and vesa.c to build under Open Watcom: https://github.com/volkertb/vbe-ai-sdk/compare/main...tkchia:e04f87ad0fa82091d7e5c4c077daa3b3de56e9bf .

Here are some of the changes I made:

I renamed the relevant files to lower case names, so that I could cross-compile the thing from my case-sensitive filesystem on Linux. 😐
I also have added a makefile play.ow which will invoke the OW compiler and linker to build play.exe. (There is also an existing makefile named PLAY, which seems to be meant to work with (?) Microsoft Visual C, or some such.)
It turns out that OW does recognize far, __far, pascal, and __pascal as keywords by default.
- For the .h files though, I thought it would be better to use __far and __pascal, instead of far and pascal.
- This is because the .h files might be used by outside programs, which may decide to use the identifiers far and pascal for other things. (In ISO C99 compliant mode (-zam), OW will indeed treat far and pascal as normal identifiers.)
  - I changed the "old-style" function definition for ErrorCallback(...) to a "new-style" function definition.
- For some reason, the code mixes "new-style" function declarations with "old-style" function definitions. This seems to be triggering some compiler bugs (?) in OW. I hope to report this soon.

Anyway, the play.c code now compiles, but I probably should find a way to test if it runs properly.

Incidentally, if you are curious, the "final draft" of the ISO C99 standard, WG14 N1256, is publicly available. I have found this to be a useful reference for some of the intricacies of the C language in general.

Thank you!

volkertb commented 3 years ago

Great work, @tkchia! :smiley:

You can test play.exe by launching and booting a (Free)DOS VM that emulates a Sound Blaster card (DOSBox, PCem, QEMU, VirtualBox, VMWare, whatever you prefer to work with, as long as it has reasonable SB emulation) and then loading the TSR SBWAVE.COM inside the VM. That's the VBE/AI wave driver for Sound Blaster and compatible sound cards.

There are basically two kinds of drivers: wave drivers for digital audio and MIDI drivers for music. It's not unlike the DIGPAK and MIDPAK drivers from The Audio Solution, if you remember those.

The SDK contains a few of those VBE/AI drivers, albeit only in binary form. (It would be nice if someone could dig up the sources for those somewhere eventually, but that's a different topic. Perhaps they're not too difficult to reverse-engineer using something like Ghidra.)

Anyway, once you have the TSR loaded, you should be able to run the play.exe you compiled to play .WAV files and you should hear them being played through the emulated Sound Blaster card (if your emulator or hypervisor and your host system are properly configured). You should just be able to run it like this:

play.exe file_i_want_to_play.wav

Run it without arguments to get the usage printed on screen.

You can also compare the behavior of the play.exe that you managed to compile with Open Watcom with that of the prebuilt PLAY.EXE that came with the SDK. It will also be interesting to see which of the compilers was more efficient in terms of resulting file size: Open Watcom or Borland. :grin:

You might also want to read through the VBE/AI 1.0 Specification a bit, if you need some more context. It contains some example code as well.

I'll try building the code and playing with the resulting binary as well.

Thanks again for your help with this! I really appreciate this. :relaxed:

tkchia commented 3 years ago

Hello @volkertb,

Thanks! I will try to read up more on VBE/AI 1.0.

Anyway, here is my second (working) attempt at porting the code to Open Watcom: https://github.com/tkchia/vbe-ai-sdk/commit/12770b197c352cd11ad9f0cbcdb0f95928e547b0 .

I tried building the new modified code and running

sbwave
play guppy.wav

under DOSBox. It seems that the new play.exe code is indeed working properly. :-)

The play.exe binary as compiled by Open Watcom is 24,890 bytes, while the PLAY.EXE that came with the SDK was 37,433 bytes.

It seems the original PLAY.EXE was compiled with a Microsoft compiler, rather than a Borland compiler --- there are Microsoft copyright messages in the binary.

Thank you!

volkertb commented 3 years ago

So it works! Splendid! And it's cool how the Open Watcom binary is so much smaller than the included binary. :grin:

I added one comment to your most recent commit. It's very minor, but I believe it's relevant.

So I guess it shouldn't be hard to apply the same (or similar) changes to the other sources in the SDK to get those to compile as well, right? If you prefer, I guess I could try applying your changes to the remaining source files to get the other EXE files in the SDK to build with OW as well, if you don't mind me bothering you with a question about it every now and then, as I run into issues. But if you prefer to finish that up in a complete pull request yourself, that's fine too. :slightly_smiling_face:

Regardless, Thanks again!

So has this work in any way been useful to you in terms of gaining insight in what would need to be done to enhance gcc-ia16 to be able to compile code like this?

tkchia commented 3 years ago

Hello @volkertb,

I guess I could try applying your changes to the remaining source files to get the other EXE files in the SDK to build with OW as well, if you don't mind me bothering you with a question about it every now and then, as I run into issues. But if you prefer to finish that up in a complete pull request yourself, that's fine too. 🙂

Thanks! I am fine either way. 🙂

So has this work in any way been useful to you in terms of gaining insight in what would need to be done to enhance gcc-ia16 to be able to compile code like this?

Not really, alas. Adding pascal support to gcc-ia16 will still likely involve touching the parts of GCC which are shared across all architectures; this is something I hope to avoid doing for now.

I am currently considering if I can work around the problem outside of GCC, perhaps by writing an extra C preprocessor to handle pascal functions, or some such.

Thank you!

volkertb commented 3 years ago

Hi @tkchia,

Which version of Open Watcom did you use to successfully build play.exe?

I checked out the play.ow makefile from your earlier commit to build your latest changes using a recent 64-bit Linux build of the Open Watcom v2 fork (making sure to source the owsetenv.sh file in the watcom folder first), but that resulted in the following errors when I ran wmake -f play.ow:

Open Watcom Make Version 2.0 beta Apr 23 2021 00:26:22 (32-bit)
Copyright (c) 2002-2021 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
    wcc -fo=play.o -bt=dos -ms -1 -oxs play.c
Open Watcom C x86 16-bit Optimizing Compiler
Version 2.0 beta Apr 23 2021 00:29:39 (32-bit)
Copyright (c) 2002-2021 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
$HOME/opt/watcom/lh/sys/types.h(189): Error! E1091: unknown platform
$HOME/opt/watcom/lh/sys/types.h(195): Error! E1055: Unable to open 'arch//sys/types.h'
$HOME/opt/watcom/lh/stdlib.h(387): Error! E1156: Assembler error: 'Cannot use 386 register with current CPU setting'
$HOME/opt/watcom/lh/stdlib.h(387): Error! E1156: Assembler error: 'Cannot use 386 register with current CPU setting'
$HOME/opt/watcom/lh/stdlib.h(388): Error! E1185: Invalid register name '__eax' in #pragma
$HOME/opt/watcom/lh/stdlib.h(389): Error! E1185: Invalid register name '__esp' in #pragma
$HOME/opt/watcom/lh/stdlib.h(390): Error! E1185: Invalid register name '__esp' in #pragma
$HOME/opt/watcom/lh/signal.h(116): Error! E1055: Unable to open 'arch//signal.h'
$HOME/opt/watcom/lh/signal.h(120): Error! E1055: Unable to open 'arch//siginfo.h'
$HOME/opt/watcom/lh/signal.h(122): Error! E1055: Unable to open 'arch//sigposix.h'
$HOME/opt/watcom/lh/signal.h(134): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(134): Error! E1116: An id list not allowed except for function definition
$HOME/opt/watcom/lh/signal.h(135): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(135): Error! E1116: An id list not allowed except for function definition
$HOME/opt/watcom/lh/signal.h(136): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(136): Error! E1116: An id list not allowed except for function definition
$HOME/opt/watcom/lh/signal.h(137): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(137): Error! E1116: An id list not allowed except for function definition
$HOME/opt/watcom/lh/signal.h(138): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(138): Error! E1009: Expecting ',' but found '*'
$HOME/opt/watcom/lh/signal.h(138): Error! E1147: Too many errors: compilation aborted
Error(E42): Last command making (play.o) returned a bad status
Error(E02): Make execution terminated

(NOTE: I replaced my actual home folder path with $HOME in the output pasted above.)

tkchia commented 3 years ago

Hello @volkertb ,

I am using wmake "Version 2.0 beta Apr 17 2021 00:26:10 (32-bit)" and wcc "Version 2.0 beta Apr 17 2021 00:29:03 (32-bit)".

Your Watcom setup seems to be getting include files from $WATCOM/lh/ rather than $WATCOM/h/ --- ~~perhaps the files needed for MS-DOS support were not installed properly?~~

My guess is that there was a problem with your Open Watcom installation. It is probably nothing serious, and you just have to re-run the installer to add some components. In particular you need to at least include "16-bit compilers", and also add "DOS" as a target operating system.

(Edit: I see that owsetenv.sh was indeed pointing $INCLUDE at $WATCOM/lh/, and I worked around this on my local setup. I guess I need to fix the play.ow makefile to add $WATCOM/h/ to the include path list --- I will do that.)

Thank you!

tkchia commented 3 years ago

Hello @volkertb,

I have added a fix to the play.ow makefile: https://github.com/tkchia/vbe-ai-sdk/commit/97e2b6d759911fd7cdd9acc57aa26ecb16407b0c . Thank you!

tkchia commented 3 years ago

Hello @volkertb,

Two issues I am currently thinking about:

On the gcc-ia16 front: I have managed to add (experimental) support for the pascal calling convention to gcc-ia16. However, the VBE/AI SDK code uses another feature which is not yet in gcc-ia16 --- namely, huge (or __huge pointers).
- The main problem here is how to properly implement huge pointer arithmetic, since huge pointers can refer to object with sizes bigger than size_t can express.
Separately: Since the VBE/AI SDK code is historically interesting, I am wondering if there is a good way to make changes to the various source files and still allow people to recover the original (1990s) code.

Thank you!

volkertb commented 3 years ago

Thank you for your work on this so far, @tkchia! :smiley:

Not only is the VBE/AI SDK code historically interesting, it has also been suggested as the standard sound API for FreeDOS. That's what has motivated me to dust if off and resurrect it. It was meant as a vendor- and hardware-neutral industry standard DOS sound API from its inception, and it's a shame that it was released too late in the DOS era to gain any industry traction. So why not give it a new lease on life and use it for its intended purpose, albeit within the much smaller remaining niche of DOS retro computing? :slightly_smiling_face:

I agree with you that it would be ideal if the SDK could remain compatible with the toolchains that it was initially developed for, while allowing them to be built with more modern (cross)compilers as well.

I guess if you manage to solve the huge pointers problem, gcc-ia16 will increase in usefulness within the retro DOS developer community. It might become an even more viable alternative to the Borland and (Open) Watcom compilers.

But perhaps there is a way to refactor the VBE/AI SDK code to no longer require the huge pointers, while still remaining compatible with those older compilers? The original source code will still be safeguarded in the Git log, so its original historic state would still be preserved, regardless.