Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site wanginst.UUCP
Path: utzoo!linus!wanginst!vishniac
From: vishniac@wanginst.UUCP (Ephraim Vishniac)
Newsgroups: net.micro.mac
Subject: Re: Re: 1.5 Meg Upgrade from MacMemory
Message-ID: <1201@wanginst.UUCP>
Date: Tue, 15-Oct-85 08:00:10 EDT
Article-I.D.: wanginst.1201
Posted: Tue Oct 15 08:00:10 1985
Date-Received: Wed, 16-Oct-85 07:08:57 EDT
References: <501@ihwpt.UUCP> <2092@amdahl.UUCP> <509@ihwpt.UUCP>
Distribution: net
Organization: Wang Institute, Tyngsboro, Ma.  01879
Lines: 30

> > ...  However, there are
> > a couple of items in the original article that puzzle me.
> > 
> > The more important item is the statement that the new Apple ROMs will
> > relocate the screen buffer to the top of the 1.5 Meg address space.
> > As address decode is a hardware, rather than software, function I would
> > want a full and convincing explanation of this claim before I purchased
> > the MacMemory upgrade.
> 
> 	It is my understanding that the location of screen memory is
> determined by a ScreenBase pointer that is placed in low memory.
> I'm not sure how it gets there, but I would guess that there is a ROM
> routine that figures out on boot up whether you have a 128K or 512K and
> then puts the appropriate value in the pointer location. I don't see
> why the Apple ROM couldn't figure out that you have 1 Meg, 2 Meg
> or whatever and calculate where screen memory should be. Obviously Levco
> does something like this with its ROM.

I think you're confusing cause and effect.  During startup, the ROMs size
memory.  (The existing roms do it very naively, choosing only between
128K and 512K.)  They then *assume* that the hardware has provided for the
screen to be a fixed distance below the top of memory.  Based on this
*assumption*, they set up the ScreenBase pointer.  If the hardware doesn't
put the screen there, you're up the creek without a paddle...


-- 
Ephraim Vishniac
  [apollo, bbncca, cadmus, decvax, harvard, linus, masscomp]!wanginst!vishniac
  vishniac%Wang-Inst@Csnet-Relay