I visited a Salvation Army center by house and they had tons of them
(the suitcase kind and they may be had a couple dozen or so) but I
cant testify to usability because they were all just laying on the
floor in the implicit "non working" section of the center. I can
see how much they cost if anybody is interested.
Louis
On Mon, 8 Feb 1999, Chad Page wrote:
>
> 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
> >
>
>
