@Zane Kaminski Did you get around to benchmarking whether this mod had a measurable negative performance impact or not?
As per the
IIsi RAM-Muncher readme, applications loaded into the on-board RAM will run slower, since the CPU shares that memory with the video circuitry. Hence, logically if there's more on-board RAM, more applications will be loaded into that memory, and run slower. I could be mistaken, though!
I was thinking about trying out the same mod on my half-working IIsi (which I suspect has marginal RAM) but wanted to make sure it's not a path to getting a worse-performing system.
Yeah, the machine will definitely be slower in some cases and I would not make this modification if I was interested in obtaining the maximum speed. My motivation was just curiosity. As for benchmarking, I am pretty skeptical of the sort of "semi-synthetic" benchmarks that are often used on these Macs... Speedometer, etc. The meaning of the "CPU score" they come up with is not clear. In my opinion, assigning a lot of importance to that kind of result obfuscates the specifics of the speed question. I could conceive of a useful synthetic benchmark that would be almost completely unaffected by running from the "vampire video" RAM and another benchmark in which the IIsi would be half as fast.
What I can say with certainty is that at 640x480, 66.67 Hz refresh rate, 8-bit color, it takes 20.5 MB/sec of memory bandwidth to display video. Unencumbered by video accesses (i.e. with video disabled or using bank B), the IIsi reads from memory at the rate of one cache line (16 bytes) per 11 20 MHz '030 clock cycles or 29.1 MB/sec. The breakdown of the 11 clocks figure is 5 clocks to read the initial longword, then 2 clocks each to read the subsequent three longwords. Obviously with video enabled there's going to be some degradation of the maximum 29.1 MB/sec bandwidth, although probably not by 20.5 MB/sec. The RBV must be faster at accessing the RAM than the '030 but by how much? One useful synthetic benchmark would be to measure the actual RAM transfer speed with video enabled but we can estimate...
The RBV video chip runs from the same 40 MHz clock as the IIsi chipset so maybe it can do a burst access with a peak rate of one longword per two or three 40 MHz cycles, as opposed to one longword per four 40 MHz cycles (i.e. two 20 MHz cycles) as is the case for the '030. And maybe there is also a shorter initial access latency, maybe more like 5-10 clocks at 40 MHz instead of 10 cycles in the case of the '030. And maybe the RBV does a burst of more than four longwords (16 bytes) at once. Maybe it reads eight longwords per burst. So assuming 8 longwords (32 bytes) per burst but calculating over the range of 2-3 cycles per burst access and 4-10 clocks for the initial access, the bandwidth available to the RBV is in the range of 37-61 MB/sec. Therefore the 20.5 MB/sec video requires between 33.6 to 54.4% of the bank A memory bandwidth.
Consequently, with video enabled the '030's read bandwidth from bank A is reduced from 29.1 MB/sec to something in the range of 13.2 to 19.3 MB/sec. This analysis doesn't consider RAM refresh but its impact is pretty minor, just 2% or so. What impact does this have on performance? It's like the SE/30 vs. Classic II thing. Some apps are more affected, some less. Since '030 has internal caches the performance impact depends on the application's need for memory bandwidth that can't be provided by the cache. Moreover, a lot of the Mac OS is in ROM which is totally unaffected by the problem, although ROM bandwidth in the IIsi is somewhat slow (~16 MB/sec) anyway because the ROM can't do a burst access like the RAM.
So long story short, I wouldn't make the mod unless you really want to or have spare of 1Mx4 DRAM chips around (as opposed to the 256kx4 chips that came on the IIsi).
