I have made some progress getting ELKS up on my PCjr. When the BIOS (or
anything else) accesses the area of 0xB8000 on a PCjr, there is special
hardware which intercepts the access and redirects it to an arbitrary area
of one or more 16K pages somewhere in conventional memory from 0-128K. The
address used for this redirection to the 'real' video buffer is controlled
by a register on the 6845 display controller. The value of this register can
be obtained by reading location 0x48A and contains a defualt of 0x3F which
breaks out as follows:
7654 3210
---------
0011 1111
Bits 7-6 are 00 to indicate text mode (there are other values for graphics)
Bits 5-3 are 0x7 which indicates the base address of the video buffer used
by
the processor (BIOS int 0x10, etc.)
Bits 2-0 are 0x7 which indicates the base address of the video buffer used
by
the CRT display for refresh
The actual base address is found by multipying the number in one of these
sections by 16K to get the segment start of the area of memory. By default,
7 * 16K = 112K (leaving 16K for video buffer before the top of memory at
128K). Obviously, this is right in the path of the kernel as it loads in at
64K.
To change these base addresses, you can do an OUT to IO-Port 0x3DF. I have
gotten ELKs to boot alittle further by adding the following code to
bootsect.S right before the 'load_setup:' label:
mov dx,#0x3DF
mov ax,#0x12 ! places the new buffer in segment 2 (32K)
out dx,ax
Now I need to figure out some reliable method for detecting the PCjr at boot
time so that this can be excuted only when necessary. I also want to figure
out how to put the console in 80 column mode and maybe find a better place
in the boot sequence to put this code. I don't think it is interfering with
any other setup, but the screen remains blank when you would normally see
the 'ELKS boot....' message (the first message printed visibly is
'Calibrating delay loop..'), and I need to figure out how to perform the
redirection before those screen writes take place.
So, I now get a complete boot to the point of 'probing fd1' and then a
kernel panic due to inability to read the superblock of the Minix
filesystem. I think this is due to my lack of a proper floppy for writing
the root disk.