Hi, On Friday 29 August 2014 11:15:37 William Levak wrote: > > On Fri, 29 Aug 2014, A. Fachat wrote: > > What looks interesting is that the data I/O pins of the RAM even stays > > high > > when I write a zero into it! I.e. either the RAM is broken and pulls the > > line high, or the driver (or something else) is broken. However, I cannot > > see why the combination of address bits should create a driver failure. > > Internal short in the driver chip. I've run into this before. Only > certain combinations of bits produce the error. I've tried to trace the error a bit more. See some scope pics here https://www.flickr.com/photos/afachat/sets/72157646409152698/ What I find interesting is that the address lines are all stable and look correct, the /RAS and /CAS1 lines look clean, all looks like it should. Yet, of the two memory accesses (it's a STA ($11),Y in the BASIC POKE command), on a bad memory address it always reads "1" then writes a "0", on a good memory bit it also reads the "0" it had written there before. The data lines do not conflict - in my previous mail I only actually looked at the first access, the read. In fact the dRAM data lines directly connect to the CPU's data lines. So if it is not the RAM, what could happen in the driver - probably UE9 or UE10 here http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/univ/8032081-05.gif that causes this? Probably a slight delay in switching the line on or off? Is it probably a mixup of somewhat larger delay in the driver, and a specific low tolerance (high setup time) in this particular RAM chip? André Message was sent through the cbm-hackers mailing listReceived on 2014-08-31 15:00:03
Archive generated by hypermail 2.2.0.
