Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!kth.se!cyklop.nada.kth.se!news
From: d88-jwa@byse.nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.hardware
Subject: Re: LC video vs. SI video...
Message-ID: <1991Mar6.075054.13581@nada.kth.se>
Date: 6 Mar 91 07:50:54 GMT
References: <1991Feb25.131316.1@gacvx1.gac.edu> <1991Feb26.134342.25399@magnus.ircc.ohio-state.edu> <ingemar.667844721@stuart> <1991Mar6.094536.125@otago.ac.nz>
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 18

In article <1991Mar6.094536.125@otago.ac.nz> michael@otago.ac.nz writes:
>In article <ingemar.667844721@stuart>, ingemar@isy.liu.se (Ingemar Ragnemalm)
>> This only occurs when the running program is located in the lowest meg, 
>> thus sharing that meg with the video. A program running in a higher part
>> of the memory runs at full speed even in 8-bit mode. 

>This doesn't sound like the whole story. Surely the video image can't be
>sitting there in the middle of the heap (can it?). I understand Apple are

Nono, the logical placement of the RAM is uninteresting. It's
sharing the physical data lines of the memory capsules that makes
programs/data in the on-board video RAM slow.

						h+@nada.kth.se
						Jon W{tte
"The IM-IV file manager chapter documents zillions of calls, all of which
seem to do almost the same thing and none of which seem to do what I want
them to do."  --  Juri Munkki in comp.sys.mac.programmer