On 2012-10-09, at 07:55, Kajtár Zsolt wrote: >>> http://dl.dropbox.com/u/58002657/cbm/c64/rom_adapter_0.png >> >> Looks OK to me... Please check in your circuit if the direct connection >> of pin 13 of the LS00 and pin 3 of the LS11 to +5V is there > > Does not look good to me. A12 is routed through 3 LS gates (from CHAROM) > while CE only on 1. I'm almost sure the address is changing _after_ the CE > was activated. Yup, timing-wise this seem to be the only thing that comes to my mind ATM. The last three address bits and especially A12 are definitely delayed against the remaining twelve. In the worst case indeed they can be switched later than _CS is activated but does it generate problems? I can imagine one scenario where it could: 0. First 12 address bits change, A12 (13, 14) remains invalid 1. _CS goes LO, A12 (13, 14) remains invalid 2. Addresses are read and are being processed by the EPROM, A12 (13, 14) remains invalid 3. A12 (13, 14) changes 4. Correct addresses are read and start being processed, all address bits valid 4. Data pops up on the data bits (as per state in point [2.]) --> ERROR! 5. Next data show on data bits (as per state in point [4.]).. The question is how the EPROM behaves when addresses are changed within tACC - will it first deliver the data according to original addresses and then according to the new or will it discard the original and deliver the new only (albeit later)? > Are you sure there are no hazards there? I was not sure but I tried to take A12 processing out of the equations by removing LS00 and delivering A12 directly to the EPROM (sockets of pins 2 and 6 shorted). Result: machine even less stable (sic!) > Using CHAROM twice on different levels looks not so good. What do you mean by that? > Try more delay for OE/CE as a workaround. I tried putting various caps on this line. I also tried passing the signal through the remaining LS11 gate (2 pins tied to VCC). All of those made the symptoms only worse :-( -- SD! Message was sent through the cbm-hackers mailing listReceived on 2012-10-09 11:00:07
Archive generated by hypermail 2.2.0.
