search

SvarDOS / edrdos

Enhanced DR-DOS kernel and command interpreter ported to JWasm and OpenWatcom C
http://svardos.org/
Other
38 stars 4 forks source link

Add SHELLHIGH support for config.sys #85

Open boeckmann opened 3 months ago

boeckmann commented 3 months ago

FreeDOS kernel supports SHELLHIGH in addition to SHELL to specify the shell. This currently is not supported by DR-DOS. According to the name, command.com is then loaded into high memory?!?

For the start it would be sufficient, if the kernel accepts it as normal SHELL command, so that it at least does not break the boot process.

mateuszviste commented 3 months ago

I'm not sure whether "HIGH" relates to actual high memory (HMA, >1MB) or simply upper memory (UMB, >640K), but in the case of SvarCOM it does not matter anyway since the shell that is loaded by the kernel is short lived. Might perhaps be a nice feature for SvarCOM for it to know how to relocate its 2K resident code into HMA. On the EDR side, I see in internals.md mentions of HIDOS, HILASTDRIVE, HIBUFFERS and HIFILES - are these the same as DOS=HIGH, LASTDRIVEHIGH, BUFFERSHIGH and FILESHIGH, respectively?

ecm-pushbx commented 3 months ago

Fairly sure shellhigh is only for loading into UMBs, if the program fits, ie the equivalent of using loadhigh to load the shell. Putting a process into the HMA is not possible because you can't address a PSP in the HMA using a segment, as the lowest HMA address would need segment = 10000h.

boeckmann commented 3 months ago

Yes will probably be UMB. For the start I will make SHELLHIGH an alias for SHELL, so that this does not break badly if encountered in a config.sys.

boeckmann commented 3 months ago

On the EDR side, I see in internals.md mentions of HIDOS, HILASTDRIVE, HIBUFFERS and HIFILES - are these the same as DOS=HIGH, LASTDRIVEHIGH, BUFFERSHIGH and FILESHIGH, respectively?

Yes, these are aliases. The HI... versions are the original ones. Then Microsoft came along and did it the Microsoft way, and Digital Research had to adapt.

mateuszviste commented 3 months ago

Yes will probably be UMB.

Then using SHELLHIGH with SvarCOM would be actually counter-productive. SvarCOM relocates its resident code as high as possible, so loading the transient SvarCOM into UMB is likely to produce a "hole".

boeckmann commented 3 months ago

Regarding the whole shell and HMA thing: It seems EDR kernel does some magic by reserving some space of the HMA for command.com?!? I did not have time yet to understand what is really going on, but that is something we should have a look at:

https://github.com/SvarDOS/edrdos/blob/4dbe13473d65b579e4c2cea4f5ca2016aed6567d/drbio/biosinit.asm#L840