DOS ain't dead - Sound library MIDAS for Freepascal/GO32V2

Laaca

Czech republic,
22.11.2020, 18:37

Sound library MIDAS for Freepascal/GO32V2 (Announce)

Just accidentaly I found a adaptation of sound library MIDAS 1.1.2 for Freepascal/GO32V2 version.
It uses a technique of using C-language (DJGPP) .A libraries from Freepascal code.
Look here.

However I face to few problems with this library. I wrote to the author but it is very interresting topic so the email with my complains might be useful for somebodz else too.

--------------------------------------------------------------------

For many years, maybe decades, I am looking for some sound library working with DOS/GO32V2 version of FreePascal.
Now I found your adaptation of MIDAS. Thank you!
However I had some difficulties with the compilation of your code.
To be the explanation between us easier I uploaded the directory with your FPCMIDAS to my site:
http://www.laaca.borec.cz/…zip

The main issue I had was the error message in the linking stage. After some investigation I found that the problem is in duplicite definition of variable "_crt0_startup_flags" which is defined both in MIDAS (file MIDAS.C) and in deep layers of Freepascal (file V2PRT0.AS - part of the RTL system for GO32V2 platform).
-- In the FPCMIDAS.ZIP archive I included a file "errormsg.txt" with generated error message.

I tried to recompile the MIDAS with deleted lines of code with referencing the "_crt0_startup_flags" but my DJGPP instalation did not manage to recompile this stuff. (maybe missing NASM?)

So I took the hexadecimal editor and inside the LIBMIDAS.A changed all strings "_crt0_startup_flags" to "_crt9_startup_flags".
After that there was no more namespace conflict and your code compiled fine.

However - the generated FPCMIDAS.EXE works OK only in pure DOS with alterante DPMI server without virtual memory (without memory swapping).
Under Windows98 (with own DPMI server with memory swapping) it is unstable. So it seems that the line
"int _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY;" is important.

So I modified your source a bit and wrote a new unit called DJGPPFNC.PAS and included it as a first unit in your FPCMIDAS.PAS
It should do exactly the same as the original C-code like "int _crt0_startup_flags = _CRT0_FLAG_LOCK_MEMORY;"

But... It still is not stable enough in environments with virtual memory.
So my quenstion is: how to effective switch off the virtual memory under FPC (better method than Lock_Code / Lock_Data) in way which is compatible with Windows98.

And does exist some better way for merging the DJGPP/C code with FPC code without need of hexaediting the .A library?

Maybe the original binary of MIDAS is compiled with some very ancient version of DJGPP and if it would be recompiled with some more modern version it would not be needed. I really don't know.

As a FPC environment I used the version 3.2.0, the version for GO32V2

---
DOS-u-akbar!

tkchia

23.11.2020, 18:08
(edited by tkchia, 23.11.2020, 18:20)

@ Laaca

Sound library MIDAS for Freepascal/GO32V2

Post reply

Hello Laaca,

> However I had some difficulties with the compilation of your code.
> To be the explanation between us easier I uploaded the directory with your
> FPCMIDAS to my site:
> http://www.laaca.borec.cz/…zip

http://www.laaca.borec.cz/fpcmidas.zip ?

> The main issue I had was the error message in the linking stage. After some
> investigation I found that the problem is in duplicite definition of
> variable "_crt0_startup_flags" which is defined both in MIDAS (file
> MIDAS.C) and in deep layers of Freepascal (file V2PRT0.AS - part of the RTL
> system for GO32V2 platform).

This actually looks to me like a FreePascal bug.

It should allow the user program to override _crt0_startup_flags simply by defining it --- otherwise there is not much point in having the variable. (The variable is read really early --- at program startup time --- so it most probably should be initialized before any code runs.)

For some reason though, FreePascal defines it in the same module as the rest of the startup code in v2prt0.as. This means the linker is forced to always link in the version that is in v2prt0.as!

I think a (more) correct fix here would be to modify FreePascal to factor out the _crt0_startup_flags definition from v2prt0.as, into a separate .c or .as module. There might also be other variables in FreePascal which should be moved out similarly.

Thank you!

---
https://gitlab.com/tkchia · https://codeberg.org/tkchia · 😴 "MOV AX,0D500H+CMOS_REG_D+NMI"

marcov

23.11.2020, 23:32
(edited by marcov, 23.11.2020, 23:50)

@ tkchia

Sound library MIDAS for Freepascal/GO32V2

Post reply

> I think a (more) correct fix here would be to modify FreePascal to factor
> out the _crt0_startup_flags definition from v2prt0.as, into a separate .c
> or .as module. There might also be other variables in FreePascal which
> should be moved out similarly.

Somebody apparently prodded people, since I had to merge a fix related to *flags in *.as on go32v2 today. Merge to the fixes branch, so will be in 3.2.2

https://twitter.com/chainq/status/1330737389824782339

Laaca

Czech republic,
24.11.2020, 01:06

@ marcov

Sound library MIDAS for Freepascal/GO32V2

Post reply

Yes, the author of MIDAS port urged to make such patch.
His response:

----------------------------------------------------------------------
Thanks for your interest in my hack. :) I understand the need for a sound library, actually I even did my own .XM/.MOD player back around 2000 in Free Pascal, when I couldn't get MIDAS working, because I didn't understand C well enough... :D This is why I did this hack at the end - now I had enough knowledge on how to integrate MIDAS and FPC finally, so I just got it running. But it was more-or-less just an experiment which I wanted to do for a long time. We can improve on it if someone like you needs it.

So long story short: the double definition of __crt0_startup_flags I knew about, and I wanted to commit a fix to Free Pascal's GO32v2 support (I have commit rights to the SVN), however, I simply forgot this after I published my MIDAS hack. However, your email now reminded me, and it's now committed in the SVN trunk. I will try to get it merged to the next 3.2.2 release.

You might want to patch v2prt0.as from FPC with this change, and recompile it yourself. You only need GNU AS for that, it should be trivial.

https://github.com/graemeg/freepascal/commit/56c03...5914ec4dce982aec1608a4d5b355360d6ef8c025ce3b99a

With this change in place, you don't even need the extra unit you created, I think, as FPC's startup code will handle MIDAS's request for a locked memory just fine.

About Windows 98 and its DPMI woes - I have no idea. I didn't even use Windows 98 back then (I used OS/2 Warp), let alone these days. :) However, I still see some instability with DOSBox too, which might be related to the problems you see. I don't know. I really only have a DOS PC, and DOSBox. I haven't even tried the code under real DOS yet, only on DOSBox. It's also possible that this problem isn't caused by the lack of memory locking, but somehow the interrupt handler which I hacked together is still broken...?

---
DOS-u-akbar!