Herr Otto Partz says you're all nothing but pipsqueaks!
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.
Quote* modify dseg.asm create an extra data segment, called fseg
Quote* move the big containers for the runtime graphics data (polyinfoptr and co.) there
Quote from: HerrNove on February 02, 2025, 03:07:42 PMQuote from: llm on February 01, 2025, 03:10:00 PMproblem with IDA is: we used the commercial version of IDA in the beginning and everyone needs to have the same IDA version user with older or freeware versions are not able to open the IDA file
I am a beginner with Ghidra and not so willing to (pirate and) learn a different debugger, so I will be pragmatical: after I cleanup the code I will submit my labelings made with search-and-replace. This will put the .asms out of sync with the IDA database, but one can always adjust that at a later time.