My first computer was a PcJr (I was a wee munchkin) and I wouldn't think that they would be very common with 640k, because in the first place they weren't particularly popular, and in the second, getting the 640k upgrade involved shipping it back to the manufacturer to be worked on. Also, the people at IBM disabled DMA on the PCJr, so it wasn't quite as good as the equivelant PC >From [EMAIL PROTECTED] Mon Feb 08 10:36:02 1999 >Received: from [128.214.248.27] by hotmail.com (1.1) with SMTP id MHotMailB88867EC43B9ED101709680D6F81B0CD546; Mon Feb 08 10:36:02 1999 >Received: from vger.rutgers.edu ([128.6.190.2]:30010 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <14966-5334>; Mon, 8 Feb 1999 20:34:09 +0200 >Received: by vger.rutgers.edu via listexpand id <154218-27300>; Mon, 8 Feb 1999 13:15:08 -0500 >Received: by vger.rutgers.edu id <154189-27300>; Mon, 8 Feb 1999 13:15:02 -0500 >Received: from alpha.matrixinet.com ([205.254.232.10]:43643 "EHLO alpha.matrixinet.com" ident: "TIMEDOUT") by vger.rutgers.edu with ESMTP id <154218-27302>; Mon, 8 Feb 1999 13:14:49 -0500 >Received: from beach.silcom.com (beach.silcom.com [199.201.128.19]) > by alpha.matrixinet.com (8.9.1a/8.9.1) with ESMTP id KAA07610; > Mon, 8 Feb 1999 10:32:32 -0800 (PST) >Received: from localhost (cpage@localhost) > by beach.silcom.com (8.9.0/8.9.0) with SMTP id KAA15463; > Mon, 8 Feb 1999 10:32:37 -0800 (PST) >Date: Mon, 8 Feb 1999 10:32:16 -0800 (PST) >From: Chad Page <[EMAIL PROTECTED]> >To: Alistair Riddoch <[EMAIL PROTECTED]> >cc: "Michael W. Shaffer" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >Subject: Re: Boot success on PCjr >In-Reply-To: <[EMAIL PROTECTED]> >Message-ID: <[EMAIL PROTECTED]> >MIME-Version: 1.0 >Content-Type: TEXT/PLAIN; charset=US-ASCII >Sender: [EMAIL PROTECTED] >Precedence: bulk >X-Loop: [EMAIL PROTECTED] >Return-Path: <[EMAIL PROTECTED]> >X-Orcpt: rfc822;linux-8086-outgoing > > > 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 >> > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
