Quote from: HerrNove on February 03, 2025, 02:19:37 PMSince I got the attention of the experts, let's try to squeeze some of their knowledge...
Last weekend I wasted a couple of hours by trying to alleviate the memory problems of my program. My plan was
* modify dseg.asm create an extra data segment, called fseg
* move the big containers for the runtime graphics data (polyinfoptr and co.) there
* add an `assume fs:fseg` directive so that the linker can keep using 16-bit pointers. Put some assembly at program start to load the FS register with the fseg segment address
The plan failed, but I think it's because I am not expert enough in assembly programming. In particular, when I put in a C file the assembly fragment to set FS, the Borland compiler complained that FS is not a valid name (this despite me adding the -3 option, that should compile for 386 processors). The linker also complained about "fixup errors"; changing the model to `huge` alleviated that but I think this is wrong since we should be able to keep working with 16-bit pointers.
Ideas are welcome.
thats a hard one,
Quote* modify dseg.asm create an extra data segment, called fseg
that should work if its at the very end - or before stack with some fixes for the stack start
Quote* move the big containers for the runtime graphics data (polyinfoptr and co.) there
1. works only if there are no non-symbolic offsets in the assembler(or C) refering to this data
2. the other (non yours) polyinfoptr and co. using code needs to use then fs instead of ds (or whatever register is use at that point to the segment)
big pain-point with restunts for me was always - there are offsets in the code that are non-symbolic