Mac IIfx SIMMs, Continued from about 1 year ago...

Leaving out a lot of stuff over the last year that probably no-one wants to read about, I finally built some 16MB SIMMs for the Mac IIfx. Suffice it to say that I took a circuitous route to getting my boards made and there were many layouts along the way. The IIfx uses an oddball 64 pin SIMM which is nearly identical to 30 pin SIMMs, *except* the data-out and data-in busses are separate. This allows the memory controller to latch the data for writes, signal the CPU that the transaction is complete in two cycles, and then proceed with the actual write to RAM. Since the write data is sitting in a little buffer-to-SIMM cul'de'sac it does not interfere with other use of the data bus. Memory chips which are X 1 memory chips (e.g. 16M X 1) have separate data in and data out pins, though in most SIMMs, they're simply tied together and run to the SIMM data bus. I had a small supply of 16M X 1 chips on hand, so first I built some 16MB SIMMs with eight 16M X 1 chips each. That was very straight-forward, no surprises and worked fine. That is not the interesting part. Next I built some SIMMs out of 16M X 4 memory chips, of which I have a much larger supply. The problem with 16M X 4 chips for this application is that they do not have separate data-in and data-out pins. They have combined D/Q pins. This presents a problem as simply tieing them together would mean that the buffered writes would interfere with other activity on the data bus. Most of the discussion a year ago was how to get around that problem. I finally tested it. This is the (I hope) interesting part. My first idea was to use a pair of octal buffers per SIMM, such as the TI SN74ABT241. Four of the eight buffers are controlled by an active_low OE and four of them are controlled by an active_high OE. This makes it convenient to use one buffer per 16M X 4 chip. I planned to use WE_ to control the buffers. The active_low buffers would route data from the D/Q chip pins to the SIMM data_in pins. The active_high buffers would route data from the D/Q chip pins to the SIMM data_out pins. Before trying it I realized that the flaw in this plan was that when the output of the memory chips is high-Z (high impedance/no signal) the buffer would still be trying to drive some deterministic output onto the data bus as long as WE was high. My next thought was to invert CAS and logically AND it with WE to control the data_out buffers. The data_in buffers would still be controlled by WE alone. That way the data_out pins of the SIMM would only be driven when there was actually a Read taking place. However, the timing on this looks wonky. Data out from a read is usually held a while after CAS goes high again, but this scheme would cut off the data_out signal (switch back to high-Z) very shortly after CAS goes high. My third idea was to ask this list if there was some component that would just pass the signal along, including high-Z signals. Someone pointed me at a family of components which led me to FET Bus Switches. So an octal bus switch such as the SN74CBT3244 looked like a good option. The only problem with the SN74CBT3244 is that both OEs are active low (each OE controls four of the eight switches). I wish there was a SN74CBT3241 with one active low and one active high OE. So, I simply controlled the OE for the data_in pins with the WE signal and controlled the OE for the data_out pins with the inverted WE signal. SC-70 packaged inverters are *tiny*. Ultimately, the SIMMS based on 16M X 4 chips with two SN74CBT3244 octal switches controlled by WE and inverted WE switching between data_in and data_out worked. The other two configurations using the SN74ABT241 octal buffers did not work. I tried both control configurations. I tried two different assemblies. And when the second one did not work, I converted it to the SN74CBT3244 configuration just to test whether the memory chips were good. After the conversion to the workable control circuitry the SIMM worked. So, unless I received a bad batch of SN74ABT241 chips, I'd say that the Bus Switching scheme works and the Buffer scheme does not work. When I tested my first SN74CBT3244 controlled SIMM I placed it in the D24 - D31 SIMM socket, while the other three SIMMs were the conventional ones built from 16M X 1 chips. It almost booted, but not quite. Moving the SN74CBT3244 controlled SIMM to any of the other three sockets resulted in it working, but it would not work in that one socket. Hoping that the problem had something to do with combining SIMMs of such different components, I built a second SN74CBT3244 controlled SIMM. With that one installed in the D16 - D23 socket, the original in the D24 - D31 socket and the other two sockets with 16M X 1 based SIMMs the machine booted and passed memory tests. Similarly the machine works fine with three and four of the SN74CBT3244 controlled SIMMs installed. Any idea why it would not work when just one SIMM was different and installed in that one socket? Much of the IIfx's peripherals seem to use only 8 bits and the 8 bits they use appear to be D24 - D31, so I would guess it has something to do with that. Also, I've always heard/read that when a machine needs four SIMMs at a time, one should install SIMMs of the same manufacture and composition. But why is that true, electrically and logically? If the SIMMs meet timing specification, shouldn't they work together even if they're built of wildly different components? What difference does it make if some SIMMs are 60 ns and others are effectively 70ns if the machine requires 80ns and so they're all meeting spec? Or why should it matter if some SIMMs have a bit more drive current or sink a bit more current on writes than others, as long as they are all within specfications? Yet it seems that it matters. Why? I could understand it if some memory chips were 13 X 11 addressed and others were 12 X 12, but these are *all* 12 X 12, so that is not the issue here. So why should combining SIMMs built from 16X1 chips with SIMMs built from 16X4 chips not work in some configurations? Yet when placed in like groups they work fine? Jeff Walther