Lucho fixed, as final public developers's work for his part, the 'remainig' -> 'remaining' cosmetic bug.
now only this strange bug of why DISPLAY loads high if MEM is first run,
and loads low (and atapicdd/cdrcache load high instead) if MEM isn't run.
Keyb seems alright afterall, but I thought 1) 'keyb partially loading --> unnamed block eating UMB' 2) 'keyb loaded with valid parameters' --> MEM /C shows alright.
My conclusion then: must be KEYB. Conclusion now: must be MEM displaying something wrong (as Bart indicates).
no idea if the DISPLAY binary has been UPX'd, and if that has any affect.
Bart, I'm not distributing a 386/BorlandC/Apack kernel, this was just an experimental bootdisk image to show some troubles I experienced.
bootdisk will be 8086+, and I hope the SHSUCDX/SHSUCDHD parts can also become 8086+
in no way is this a full-featured usable bootdisk, but it does show how to load the various drivers.
I'm still confused by syntax for DISPLAY/MODE/KEYB.., so it's good to have working examples at hand.
I'm planning to use a 8086/Openwatcom/UPX version of either Jeremy's or Lucho's sources, and to distribute a 2035A (the conservative tree) as kernel for harddisk.
Haven't figured out why not everything (except UDMA ofcourse due to lack of VDS) loads high. Plenty of UMB space (48K).
perhaps I should test against official 2035, to see if self-UMB-loading programs work there.
All my testing is done in VMware 4.5.2, btw. No Bochs/Qemu/DosEMU/VirtualPC etc.
Bernd
------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
