> The display funniness would be caused by ELKS being ignorant about
>clobbering the video memory. The kernel would have to be told not to use
>the memory (might be tricky if it's in the area where the kernel is loaded
>- quite likely since it's loaded at 64K unless that's changed). I dunno
>about the kernel panic, although that stack dump feature looks interesting. :)
>
I have been reading the various manuals that came with the machine like the
_Guide to Operations_ and _Compute's Mapping the IBM PC and PCjr_. I believe
you are correct, and that sure looks like what is happening. After I
scattered a bunch of printk()s throughtout init.c and sched.c, it looks like
the kernel gets all the way to the first call to schedule() in
kfork_process(). I am guessing that since the kernel is getting dumped into
the video buffer it is being corrupted by the subsequent writes to this area
from printk(), etc. and this results in the eventual crash.
The _Guide_ goes on about a utility to be used with the Racore expansion to
relocate the video buffer from the 112K - 128K region (its normal location)
to a lower position at 24K to 40K (which it says is right after DOS). The
_Guide_ says that this will allow DOS to recognize the full memory capacity
of the machine with the expansion (which it could not if the buffer were
left in the middle of memory at 112K). I have also been wandering through
the boot loader code and config.h and have found a define called
DEF_SETUPSEG which is 0x120, so I am just wondering now which of the two
following approaches would be best:
<> Change DEF_SETUPSEG (or some other parameter, I'm really not sure exactly
what I'm talking about yet) to make the kernel load into a different area of
memory. I don't know what the full implications of this are, and am not
really sure where would be best to move it.
<> Put together some little assembly language routine that could be called
to 'move the video buffer' in a manner similar to the utility the Racore
manual talks about. I am guessing that there is some BIOS call I could make
early on in the bootloader code to accomplish this. I am not sure yet how
The kernel is figuring out where video memory is for the purpose of doing
pokeb() to it (in direct console mode), so I don't know if doing this would
confuse the kernel and result in a blank screen later on.
If no-one has any better guesses, I think I'll try the second approach
first.
