Michael W. Shaffer writes:
>
> > 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.
>
I think the second approach is going to be easier to implement. Modifying
the kernel to load at a higher address will cause all osrts of problems,
and mean that we will have to mess about with memory allocation and other
stuff. With the kernel loaded at 128K, occupying up to 320K it will start
getting very tricky to allocate reasonable sized chunks of RAM for user
programs, worsening the already quite severe mamory fragmentation problems.
Al
