Last time I checked, the JEMM included in FreeDOS lacked GEMMIS support.
Hopefully the code from 386MAX can be used to add that support to JEMM.
Alternatively, completely replace JEMM with 386MAX...

if the source is anything like the other projects released ages ago, QLink and DPMIOne, the code is terrible to read and build.

Maybe that's why it was good? 😉
Terrible spaghetti code is the most efficient sometimes..

Jo22 wrote on 2022-07-02, 00:39:

Maybe that's why it was good? 😉
Terrible spaghetti code is the most efficient sometimes..

That really only should apply when the language or compiler doesn't support certain things like inlining a code block.

Because if you can inline or even call functions without having to pass any parameters (global variables), then spaghetti code should not be used... Aka, manual jumps to other blocks of code.

And if you are using a language that can use jump tables you are doing even better because directly mapping to a function via an array of functions instead of using case or nested if statements is pretty much the fastest way.

Manually optimizing the assembly code after that is about the only way to make the compiled code any faster IF the code is already the most efficient way to do things.

It looks like there are binaries under DISK/TMPOUT and LIB, and that those would now be presumably freely redistributable, so that's neat.

Glancing at it, there is something about a custom C runtime library (qlib) that doesn't appear to be here so the C-based components may not be buildable.

When there is an idiosyncratic build system like this with lots of batch files, makefiles, paths hardcoded, etc., the easiest way to understand it could actually be to parse the MAP files and load up the binaries in something like IDA.

jakethompson1 wrote on 2022-07-02, 23:41:

Glancing at it, there is something about a custom C runtime library (qlib) that doesn't appear to be here so the C-based components may not be buildable.

I can't find anything about qlib in the tree in commit 1edc33c, did you misread "qlink" (from the same author) or am I missing something?

Anyway thanks for letting us know digger!

Also, some trivia: this was included with Microsoft C/C++ 7.0; http://www.emsps.com/oldtools/mscppv.htm says it was version 6.02 that was included.

Ha, the last couple of days I have been messing around with 386MAX.

It appears to use low-level calls to the RAM and to get the disk geometry.
386MAX.sys will sometimes crash the VM on Arch Linux host (Virtualbox "Guru meditation", VMware hangs, QEMU/KVM seems to pause?) and QCache will complain if the disk is larger than 2Gb (maybe int21, 1ch?).
I need to find an old disk, I think I have one but not the laptop version. It seems that the laptop 2Gb drives are getting rare.

It will be nice to look at the code, but to be honest, it's probably beyond me at the moment.

doshea wrote on 2022-07-03, 07:44:

jakethompson1 wrote on 2022-07-02, 23:41:

Glancing at it, there is something about a custom C runtime library (qlib) that doesn't appear to be here so the C-based components may not be buildable.

I can't find anything about qlib in the tree in commit 1edc33c, did you misread "qlink" (from the same author) or am I missing something?

sorry, it's QDISP. from MAX.MAK as well as some of the others:

1# Needed only for C runtime (shared between projects)
2!if "$(CATROOT)" == ""
3  !error CATROOT is not defined.  Ex: SET CATROOT=c:\qdisp\
4!endif

Talk about good timing. I searched web just now and found this, just open sourced few days ago. 😁

So, it appears that 86Box doesn't suffer from the memory check problems when using 386MAX like VirtualBox does.
The bigger disk geometry still needs to be tested.
But at this stage it appears that 86Box sticks faithfully to the older low-level BIOS calls.

EDIT: Yep a 2Gb drive in 86Box with 386Max is ok.