I am not sure exactly what that model is, I couldn't find a schematic on Zimmers for it, but I will assume that it is the C-64C or what we used to call the C-64CR which we took to mean cost reduced internally, the half-height board. If that is the one you are talking about then I can tell some of the background of where CBM was with regard to DRAMS and the thought processes that went along with it. The C64C was done by an engineer out of the Tokyo office by the name of A. Katayama. He also liaised on the TED and C128 series and so was "in the loop" when it came to a system designed around correct DRAM timings from the start (TED) and what could be done to make the VIC chip live better with DRAMs (C128). So with regards to the question itself, I doubt that there would be anything in the logic to accommodate a part that pushes a margin such as too fast; it would happen often in the numbers CBM produced so it wouldn't be anyway a trend or batch would necessitate a change for a while, a logic change wouldn't accommodate a mixed batch (1 out of 8, 7 out of 8) which if it worked in those cases we would just make the change for as the better logic, There wasn't any methodology for "if this fails then rev the board", especially since the bigger source of issue was still the VIC chip. If something failed it was faster to recycle than scrap (Christmas time) and cheaper to limit repairs what could be done in a few minutes. So with all of that said, we assumed that an unknown state propagated in 0ns, actually -.5ns once you fudged for pin capacitance and layout differences. This assumes that the engineer is not just thinking in terms of 1's and 0's but also the intermediate unknown state of X. The best designs assume that the moment X hits one of the inputs that the outputs may have a certain amount of X in them. So in theory we wouldn't have something that was too fast for the design, we expected the worst already in that direction. It was also common place for a vendor to ship us all parts of speed or faster if we let them for them to make their quotas, it cost them more and we didn't care. So without seeing the schematic I would assume it was multiplexer logic to accommodate different control or MA line configurations. With regard to a gated R/W, that is a good observation that the TED had this feature and that it was desired. My memory is that in the C64 we used to wrap the signal back through the PLA to create a pseudo-latched version. It all comes down to the fact that the DRAMs were based on RAS and the processor on Phi. We were at the limit on making RAS look more like Phi due to things like RAS Precharge Time and other setup and hold times. Whereas address lines were latched, the /WE on a DRAM is asynchronous to the point where you could start a cycle as a read and then flip around and write without changing the addresses or strobes, I.E. a fast Read-Modify-Write. There were times when you could "lie" to the IC's but the /WE has to be kept honest. We also learned what DRAMS did when abused to some extent, one of the IC guys, Dave Andreas, had been a memory designer and once in response to a question he related how doing what I had asked would cause internal collisions in the DRAM as buffers would fight each other with the array in the middle. We also used to test for nearest neighbor bleed and substrate/ground poisoning as layout and noise were as prevalent as logic. Bil Herd -----Original Message----- From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Gerrit Heitsch Sent: Saturday, April 07, 2012 1:23 PM To: firstname.lastname@example.org Subject: U11 on a C64 board 250466 Hello, this was already discussed on the forum64.de, but since not everyone is reading that, I'll post it here too. If you take a look at a C64 board with the assy number 250466 (aka 'B3'), you'll notice that it uses 64Kx4 DRAMs and has an unused spot named U11 (plus C27 for the decoupling cap) next to the DRAMs. There is also J3 next to it. I always wondered what this was for and finally got around to check it out and map the signals. Another forum member determined that the pinout matches a 74LS139. J3 determines whether R/_W from the CPU is directly connected to the RAMs or routed through the 74LS139. The other signal supplied to the decoder (enable is tied to GND) is PHI0 and the ouput used will only go LOW if PHI0 is HIGH and R/_W is LOW, effectivly making sure that only the CPU can write to the RAM and a VIC read cycle will always be a read cycle even if R/_W from the CPU takes a bit longer to go HIGH again (which it does). I did put a 74LS139 at U11 (if you want to do it, you need to tie pin 13-15 to GND, otherwise they are floating), added C27 and cut J3, the board still runs as if nothing changed. To me it suggests the board designer suspected that some RAMs might be too fast and interpret a VIC read cycle following a CPU write cycle as another write cycle and wanted to make sure this cannot happen. Most RAMs don't seem to need it as I haven't seen a 250466 with U11 populated and repairing one with faster RAMs (100ns) still doesn't cause problems. This circuit does remind me of the GATE IN signal on the 8501 CPU in the 264 series. The later C64 boards (250469, using the 64pin PLA) no longer connect R/_W from the CPU directly to the DRAMs, they run it through the PLA, making me assume that this circuit (or similiar) was integrated there. Anyone here ever run into 'new RAM too fast' problems with a C64 board? Gerrit Message was sent through the cbm-hackers mailing list Message was sent through the cbm-hackers mailing listReceived on 2012-04-23 19:00:07
Archive generated by hypermail 2.2.0.