youngdahl@gacvx1.gac.edu (02/26/91)
Just a couple of quick and easy questions (for those that know the answers...) How does the SI's built in video compare in terms of expandability to the LC's? Have any of the LC owners out there had any "negative" experiences they want to share? (I'm deciding between the LC and the SI, and for cost reasons (as a student) the LC is looking much more attractive at the moment.) Thanks Ben Youngdahl youngdah@nic.gac.edu
gaynor@magnus.ircc.ohio-state.edu (Jim Gaynor) (02/26/91)
In article <1991Feb25.131316.1@gacvx1.gac.edu> youngdahl@gacvx1.gac.edu writes: >How does the SI's built in video compare in terms of expandability to >the LC's? Mac LC Mac IIsi Macintosh 12" RGB Display x (256 colors) x (256+?) Macintosh 12" Mono Display x (16 grays) x (256 grays) Macintosh 13" RGB Display x (16 colors) x (256) Macintosh Full Page Display x (4 grays) Some VGA Monitors x (16 colors) Note: There is an optional 512k VRAM SIMM for the Mac LC that will boost shades available to 32,000 on the 12" RGB display, and to 256 on all others supported. Note 2: The Mac LC uses independent VRAM for video, where the IIsi cycle-swaps memory from the CPU, resulting in severe performance degradation on the IIsi in 8-bit mode. Note 3: With optional NuBus card, the IIsi can use virtually any monitor, with the addition of the appropriate card. The LC needs cards desgened for specifically for it. >Have any of the LC owners out there had any "negative" experiences they want >to share? I have heard of none. >(I'm deciding between the LC and the SI, and for cost reasons (as a student) >the LC is looking much more attractive at the moment.) Be certain to note certain limitations inherent in the LC: o No external floppy port. o No Apple-supported provision for an FPU or PMMU o Unique expansion slot ('020 PDS). -- Jim Gaynor - Systems Analyst 1 + "This is Serious. He is Lost. The Ohio State University ACS-FM-OCES | We must begin the Search at once." gaynor@magnus.ircc.ohio-state.ed | -Rabbit, from gaynor@agvax2.ag.ohio-state.edu + "The House at Pooh Corner"
ingemar@isy.liu.se (Ingemar Ragnemalm) (03/02/91)
gaynor@magnus.ircc.ohio-state.edu (Jim Gaynor) writes: >Note 2: The Mac LC uses independent VRAM for video, where the IIsi >cycle-swaps memory from the CPU, resulting in severe performance >degradation on the IIsi in 8-bit mode. 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. When I want to run a time-critical application, I launch another first to take up some space in the RAM. Works nicely. (OK, "nice" isn't a good word when speaking about this design.) -- Ingemar Ragnemalm Dept. of Electrical Engineering ...!uunet!mcvax!enea!rainier!ingemar .. University of Linkoping, Sweden ingemar@isy.liu.se
michael@otago.ac.nz (03/06/91)
In article <ingemar.667844721@stuart>, ingemar@isy.liu.se (Ingemar Ragnemalm) writes: > 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 using the MMU to remap things, so presumably what we have is whatever portion of the 1 meg is left over from the video (716K in 8-bit mode) mapped somewhere into the main space and whatever other RAM you have in the other bank mapped around it. Presumably the MMU has the flexibility to put this slow RAM anywhere, so it would be interesting to know exactly what Apple have done and why. I hope they have picked a spot based on careful analysis of average memory use... Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand HASTINGS (pl. n.) Things said on the spur of the moment to explain to someone who comes into a room unexpectedly precisely what it is you are doing.
jcav@ellis.uchicago.edu (john cavallino) (03/06/91)
There are three (3) built-in video methods employed by Apple in Mac models. 1) The Mac IIci and IIsi: The frame buffer ALWAYS starts at absolute address 0, which is the first address in SIMM bank A. This is where the video contoller always looks. Depending on the screen depth selected in the "Monitors" control panel, there is a variable amount of RAM left unused in bank A. The MMU maps this RAM, along with any RAM in bank B, so that it appears contiguous in virtual space, starting at virtual address 0. It also remaps the frame buffer to appear in the address space corresponding to a NuBus card. The reason some memory is slow and some not slow is that sometimes the absolute address falls in bank A, which suffers contention delays with the video controller. If the absolute address falls in bank B, there is no contention and no delay. This is also why it is best to put expansion RAM in bank B first. 2) The Mac LC and the Mac SE/30: The video in these systems works differently, in that the frame buffer is stored in dedicated video RAM chips, not in the main SIMM memory. 3) The "classic" machines (128,512,Plus,SE,Classic): The video in these systems is similar to method 1, in that the frame buffer is stored in regular memory, but in these machines ALL memory suffers from contention delays (less so in the SE and Classic). -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
dbert@pogo.ai.mit.edu (Douglas Siebert) (03/06/91)
In article <1991Mar6.094536.125@otago.ac.nz> michael@otago.ac.nz writes: >In article <ingemar.667844721@stuart>, ingemar@isy.liu.se (Ingemar Ragnemalm) >writes: >> 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 using >the MMU to remap things, so presumably what we have is whatever portion of the >1 meg is left over from the video (716K in 8-bit mode) mapped somewhere into >the main space and whatever other RAM you have in the other bank mapped around >it. Presumably the MMU has the flexibility to put this slow RAM anywhere, so it >would be interesting to know exactly what Apple have done and why. I hope they >have picked a spot based on careful analysis of average memory use... > Nor does this sound like the whole story. The way I understand it, the reason for the slower execution is because when the on-screen image is refreshed the processor cannot access the same block of memory where the screen resides, thus causing the processor to have to wait during each time in which in the video circuitry takes over use of the memory for a cycle or two. Everyone is talking about the "low" megabyte in memory though....WRONG! Unless you have a 2M computer, you will be talking about the low FOUR megabytes of memory, since the 1M simms are banked together in groups of four, all sharing the same block. I know my terminology is probably not correct and likely confusing....perhaps someone else can explain it better than I....but I'm pretty sure this idea should hold. -- ________________________________________________________________________ Doug Siebert dbert@albert.ai.mit.edu MBA Student (2nd year) The University of Iowa
amanda@visix (Amanda Walker) (03/06/91)
dbert@pogo.ai.mit.edu (Douglas Siebert) writes:
Everyone is talking about the "low" megabyte in memory though....WRONG!
Unless you have a 2M computer, you will be talking about the low FOUR
megabytes of memory, since the 1M simms are banked together in groups of
four, all sharing the same block.
NOt exactly. Remember, on the IIsi, there's one megabyte that's permanently
soldered onto the motherboard. I believe that this is the only physical
memory that gets used for the screen... Someone posted the details about
how the memory gets remapped for internal video, but the article seems
to have expired from our site.
Amanda Walker
Visix Software Inc.dbert@pogo.ai.mit.edu (Douglas Siebert) (03/06/91)
In article <1991Mar6.011546.19535@midway.uchicago.edu> jcav@ellis.uchicago.edu (john cavallino) writes: >There are three (3) built-in video methods employed by Apple in Mac models. > >1) The Mac IIci and IIsi: >The frame buffer ALWAYS starts at absolute address 0, which is the first >address in SIMM bank A. This is where the video contoller always looks. >Depending on the screen depth selected in the "Monitors" control panel, there >is a variable amount of RAM left unused in bank A. The MMU maps this >RAM, along with any RAM in bank B, so that it appears contiguous in virtual >space, starting at virtual address 0. It also remaps the frame buffer to >appear in the address space corresponding to a NuBus card. The reason some >memory is slow and some not slow is that sometimes the absolute address falls >in bank A, which suffers contention delays with the video controller. If the >absolute address falls in bank B, there is no contention and no delay. This >is also why it is best to put expansion RAM in bank B first. I was under the impression that you couldn't, for instance, put 256K SIMMS in bank A and 1M or 4M SIMMS in bank B. Is it different for these machines? Also, if you purhcased a separate video card for the si or ci which included on-board VRAM, would the contention problem then go away? This would probably not be worth it if you only intended to get an 8-bit card anyway, but if you got a 24-bit card (which the on-board video doesn't support, correct?) then you would have better video and faster execution, all for only a few hundred dollars. Then I would see no real reason to purchase a ci over an si unless the extra slots were really important to you. Comments? -- ________________________________________________________________________ Doug Siebert dbert@albert.ai.mit.edu MBA Student (2nd year) The University of Iowa
d88-jwa@byse.nada.kth.se (Jon W{tte) (03/06/91)
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
jcav@ellis.uchicago.edu (john cavallino) (03/06/91)
In article <1991Mar6.043604.9943@mintaka.lcs.mit.edu> dbert@pogo.ai.mit.edu (Douglas Siebert) writes: >I was under the impression that you couldn't, for instance, put 256K SIMMS in >bank A and 1M or 4M SIMMS in bank B. Is it different for these machines? Yes. >Also, if you purhcased a separate video card for the si or ci which included >on-board VRAM, would the contention problem then go away? This would probably I BELIEVE (not sure) that if no monitor is connected to the internal video port, no memory is allocated to the frame buffer and the internal video circuitry is disabled, so there would be no contention for system RAM. On the other hand, if you use a video card then you must contend with the 10mhz bottleneck of the NuBus. No free lunch here, sorry. >not be worth it if you only intended to get an 8-bit card anyway, but if you >got a 24-bit card (which the on-board video doesn't support, correct?) then >you would have better video and faster execution, all for only a few hundred ^^^^^^ ^^^^^^^^^ -see above >dollars. Then I would see no real reason to purchase a ci over an si unless >the extra slots were really important to you. Comments? Well, the CPU clock rate is faster, the power supply is bigger, there is room for larger internal hard disks, the math coprocessor is built-in, there is a cache slot,... :-) -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
jcav@ellis.uchicago.edu (john cavallino) (03/06/91)
In article <1991Mar6.015922.6940@mintaka.lcs.mit.edu> dbert@pogo.ai.mit.edu (Douglas Siebert) writes: >In article <1991Mar6.094536.125@otago.ac.nz> michael@otago.ac.nz writes: >>In article <ingemar.667844721@stuart>, ingemar@isy.liu.se (Ingemar Ragnemalm) >>writes: >>> 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. > >Everyone is talking about the "low" megabyte in memory though....WRONG! Unless >you have a 2M computer, you will be talking about the low FOUR megabytes of >memory, since the 1M simms are banked together in groups of four, all sharing >the same block. I know my terminology is probably not correct and likely >confusing....perhaps someone else can explain it better than I....but I'm >pretty sure this idea should hold. Once again, in the IIci and IIsi, the RAM to which access is shared with the internal video circuitry is ONLY IN BANK A. This memory could total 1mb, 4mb, 8mb, 16mb, etc. with the appropriate SIMM sizes. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 "Opinions, my boy. Just opinions" | Telephone: 312-702-6900
peirce@outpost.UUCP (Michael Peirce) (03/07/91)
In article <1991Mar6.044427.10163@mintaka.lcs.mit.edu>, dbert@pogo.ai.mit.edu (Douglas Siebert) writes: > > I was under the impression that you couldn't, for instance, put 256K SIMMS in > bank A and 1M or 4M SIMMS in bank B. Is it different for these machines? Yes, it's different for these machines. They use the MMU to remap things so they look contiguous to the Mac OS. > Also, if you purhcased a separate video card for the si or ci which included > on-board VRAM, would the contention problem then go away? This would probably > not be worth it if you only intended to get an 8-bit card anyway, but if you > got a 24-bit card (which the on-board video doesn't support, correct?) then > you would have better video and faster execution, all for only a few hundred > dollars. Then I would see no real reason to purchase a ci over an si unless > the extra slots were really important to you. Comments? Yes, adding a NuBus video card to a ci or si removes the video contention with main RAM. Of course, even with an addition video card you could still use the on-board video to give you two screens if you'd like! There are two ways to boost the performance of a Mac IIci: (1) the addition of a NuBus video card and (2) the addition of a cache card. I've done both of these and there is really a noticeable speed increase - enough to keep me happy until the 68040 Mac comes out! :-) (I hope there is a small footprint '040 based Mac sometime soon after the tower comes out.) -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE