More on Video Memory
Even with the article we did on the IIsi and IIci video memory oddities, the issue remains murky to many people. Glenn Austin was kind enough to provide more detailed information which may further illuminate the matter, although for those of you who don’t speak hex, I recommend just ignoring the address information – I did and still got the basic idea.
Here’s the memory map under System 6 and 7 on the IIsi and IIci, assuming (for the sake of discussion) that there is 8 MB of RAM in the machine, 2 banks of 4 MB RAM each, and the machine is 256-color capable:
Where Description Size Logical address Bank A Video RAM $50000 $FBB00000 Bank A Main RAM $3B0000 $00400000 Bank B Main RAM $400000 $00000000
So the memory map looks something like this (in 24-bit mode, 32-bit is similar):
----------------- | Bank B | $00000000 (low) | RAM | | | | | | | ----------------- | Bank A | $00400000 (high) | RAM | | (above video | | RAM in phys. | | address) | ----------------- | ROM | $00800000 ----------------- | Video "NuBus" | $00B00000 ----------------- | NuBus slots | $00C00000 | $C - $E | $00D00000 | | $00E00000 ----------------- | I/O | $00F00000 -----------------
Whatever shares bank A with the video memory will run slowly because the video memory is accessed constantly. Therefore, you want to load items that the Macintosh uses relatively infrequently, such as the disk cache, into bank A. This was not as apparent with System 6, because applications load into low memory (bank B) under MultiFinder 6. (This was the main reason that MultiFinder was recommended for the IIsi and IIci under System 6.) Under System 7, applications load at the top of MultiFinder’s heap, (that is, in high memory or bank A). The System 7 Finder will load into that high memory in bank A – unless that memory is already occupied by something else, so if possible, you shouldn’t load the Finder (a frequently accessed item) in that part of RAM that has the most contention between two processes – CPU and video.
Apparently the disk cache uses high memory; MacsBug uses high memory; and some INITs use high memory. This helps explain why the machine runs slower under System 7 (because the Finder loads into bank A, which is also being used heavily by the video), and why increasing the disk cache size (or using MacsBug) can dramatically speed up the entire Mac. It also explains why System 7 can be proportionally slower on the IIsi and IIci than on other Macs and why a NuBus video card can dramatically improve performance. Of course, an accelerator doesn’t hurt either – an accelerated IIci (with the Magellan 040 board that Glenn works on) can show up to twice the video performance of a Quadra 700, which has built-in VRAM.
Obviously, it’s a lot easier to fill up bank A with the disk cache and MacsBug if you only have 1 MB in bank A, which isn’t a problem on the IIsi with its soldered-on 1 MB bank A. The IIci is more problematic, since you can easily put 4 MB or even 16 MB in bank A, thus making it virtually impossible to fill up bank A in order to increase the speed. Of course, if you can afford 16 MB in bank A, you can afford a cheap video card that will make this entire problem moot.
Glenn Austin — gla-aux![email protected]