VOGONS


First post, by ZanQuance

User metadata
Rank Member
Rank
Member

Hello everyone.
As a few of you already know, I've started reversing the Aureal AU30DOS.com TSR with great success so far.
What I'm after now is a C compiler which can target dos .com files, and ideally has some dos lib support files, IO access, port read/writes and whatnot.
I can just rewrite the TSR in assembly again, but I would like something a bit more maintainable, improvements and additions down the road is the target.
I'm doing all this is to update the Aureals OPL3 emu with SB16 support, and improve the generated audio.

There is also no reason other emulations cannot be brought over such as a munt MT-32 for dos for example, or the GUS perhaps.
I think the Vortex2 is a great target, it's very clean and is an awesome mixer chip, could even do HRTF in dos games (would that be a first?).
I would like to see it become a jack of all trades dos soundcard, no doubt the real hardware sounds better, but Aureal needs some lovin too.

Also if anyone knows about OPL3 emulation and can assist in identifying some of the used table data, it would be very helpful. I am learning about OPL3 as I go. 😀
Dev thread HERE
Should I blog my progress, screenshots and stuff? be nice to have a second set of eyes on some of the functions.

Reply 1 of 6, by alexanrs

User metadata
Rank l33t
Rank
l33t

Borland C++ 3 can do it, you just have to compile the project using the "Tiny" memory model ("-mt" parameter), then link it using the "/t" parameter in TLINK.

Reply 3 of 6, by Harekiet

User metadata
Rank DOSBox Author
Rank
DOSBox Author

For a more modern one you can just the open watcom compiler.
It can do .com, .exe and 32bit dpmi exe and should at least produce faster code than those ancient ones.

Reply 5 of 6, by idspispopd

User metadata
Rank Oldbie
Rank
Oldbie
ZanQuance wrote:

I can just rewrite the TSR in assembly again, but I would like something a bit more maintainable, improvements and additions down the road is the target.

Can you see if the TSR was originally written in assembly or C?
I suppose assembly would be preferable especially for lower memory usage (and also performance, although that shouldn't be too important here).
Assembly can be maintainable if you use proper names, comments etc.

Reply 6 of 6, by ZanQuance

User metadata
Rank Member
Rank
Member

I believe it was written with TurboC++ 4, but I am not 100% sure. I see a lot of routines which don't appear hand written.
I think it would be nice to have a version written in C so non-asm coders can understand this bit of soundcard history.
No reason we couldn't use ASM where it's needed most. It takes me less time to code in C than ASM, so I would like to stick with it for ease of use.