I don't have any exact figures, but I'd figure that PCjrs upgraded
to 640K are somewhat rare. OOTB they came with 128K or maybe 256K.
_However_ some people bought the later versions - after upgrading they
were like regular PCs but cheaper. I'd figure that they would cost even
less now because people don't know what they are. :)
- Chad
On Mon, 8 Feb 1999, Alistair Riddoch wrote:
> Michael W. Shaffer writes:
> >
> > 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
> >
>
> 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,a nd reduce
> the size of drivers.
>
> > 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.
> >
>
> You would eliminate many possible faults by not using a 1.2M drive to write
> 360K floppies.
>
> How common are these PCjr machines? If they are quite rare it may only be
> worth including support for them as an option. If there are alot about,
> then we should support them out of the box.
>
> Al
>
