>
>This is going to cause some problems because the segment at 32K is used by
>the BIOS disk driver. I think the driver only uses 1K as requests are only
>ever 1k, and we do not glob requests together. I am considering hard coding
>1k block requests into the kernel to simplify the request code,and reduce
>the size of drivers.
>
>Al
>
I suppose that might have something to do with my root mount problems also.
It certainly wouldn't help if video memory was stomping on the disk driver's
area. I didn't notice any of the screen weirdness as before with the kernel
loadig through the video buffer.
Any ideas as to a good place to stake out 16K in very low memory? The Racore
manual claims that the utility that came with my expansion unit will place
the buffer at 24-40K, but I have seen mentions in other books I am reading
that nothing below 32K should be used (these are all DOS oriented, however).
If there is a certain threshold below which the kernel definitely does not
venture, then I can try to squeeze this buffer in between there and whatever
is critical below it. I suppose the list of options basically is:
0 = 00-16K
1 = 16-32K
2 = 32-48K
3 = 48-64K
Any higher and its back into kernel space, and I know the BIOS won't allow
it to be placed anywhere above 128K. Actually, it seems to me that only the
first 2000 (80x25) bytes of the buffer should really be in use if the active
page is set to 0 and it is never switched. Perhaps I can find a way to
explicitly reduce the number of pages or just assume that anything else can
use the remainder of the segment with impunity.
I have also noticed that the kernel is saying I only have 112K of total
space on boot, which makes me think I am going to have to do something else
to notify the BIOS to reevalute its idea of 'top of memory' after moving the
buffer but before the kernel tries to get this number. (either that or add
some alternative memory detection code somewhere to handle the jr).
