I remember Adam Black saying in one of his latest videos that the reason we see a clean black screen with the Sad Mac icon is because the ROM directly controls the display at that point. It bypasses the RAM and writes to the screen itself. When we see the Sad Mac icon over something else , it means at least the Mac is able to write something to the screen using RAM access. So, its better when you see those vertical lines than nothing
Wow! I think you're almost there! It seems you're finally on the right track. Did you try smoothing or reinforcing the RAM-R/~W signal? It might be worth adding pull-up/down resistors to see if there's any change. At least, it would be interesting to see how it affects the number of bad pixels shown on the screen.
I wouldn't say my design works quite yet. I took nearly the entire design out of the circuit. Haha
Damn. They're right, and it applies to the Mac 512K as well. The truth table I posted in this reply shows that during video access, the DRAM is given row address values from VA0-VA7 for ~RAS (C2M high). If the video circuit cycles through these addresses in a counter, and we can assume the logic board's DRAM is refreshed in RAS only mode, then the DRAM is given 256 cycles for refresh. That lines up with what those folks said in that post as well as the datasheet for the 256K chips in the Mac 512K.
That could be an option. No refresh necessary but requires nearly 20 address lines. The speed is probably just fine though. They may even be fast enough to allow for some prop delays through latches if we wanted to continue using the RA0F-RA8F (or even RA9F) lines and use latches to save their state on the falling edge of ~RAS and ~CAS. That could save us from having to tap nearly 20 address lines off the CPU!
Could probably get away with just two of these bad boys right herr. We could use just two 8 bit latches for RA0-RA7 and forget about RA8. The benefit would be that it could be compatible with 128K boards. Although It seems like people are more interested in restoring them back to 128K than upgrading them. A17 and A18 would then require being tapped directly on the logic board as A19, A20, and A21 already will.
I think there is a problem, but not sure about the exact maximum number cycles is given to DRAM to refresh. Otherwise, the 1 MB SiMMS for the Mac Plus wouldn't work. Each SIMM have 8/9 ´44256 of 128KB (256Kb x 4 Bits), 512 refresh cycles / 8 ms. Those SIMM´s with an extra IC (9th) is for parity, which I believe read somewhere the early Macs ignores.
I’ll dig into the Mac Plus schematics a little deeper later, but at a glance it looks like the Mac Plus does provide 9 varying row addresses which would be sufficient for a DRAM with 512 rows to refresh. The Mac 512K and 128K only provide 8 varying row addresses which only refreshes 256 rows, which is compatible with the DRAM in the Mac 512K.
This seems like a possible approach with enough research and experimentation. Have you looked into hidden refresh? It looks like it’s pretty much the same as CAS before RAS except the data output remains valid on the DRAM outputs in hidden refresh. Not sure if that would be required or not.
I made a mistake calculating the quantity of DRAM IC´s. For 1.5 Mbytes, 3 IC´s (2 Mbytes including system DRAM). For 3.5 Mbytes, 7 IC´s
Did you mean to say most significant bit? The LSB would be RA0 corresponding to either A1 or A9 depending on C2M’s state. Or VA0 or VA8 if video is accessing memory.
Just for fun: If one were to stick with the original size DRAM ICs of which the Mac 512K consists, it would take a whopping 64 ICs! But the 16 ICs onboard could be kept in service, so only an additional 48 is needed. I think something from my notes in my first post was close to correct for creating the CAS lines. A required change would be to make it so that CAS0 derivatives could be asserted at the same time as CAS1 derivatives, rather than only one or the other at a time. It would then be 512K chunks as you said, not 256K chunks as I wrote.
