Hello, >>> Remember what Jim said happenned when he tried to use the >>> dumper-in-RAM method: >>> >>>> 6570 would generate a bunch of 0xff, but the 6571 gave me nothing. >>> >>> Maybe, the 6571's RAM has failed. >> >> There is a blink code for failed RAM though. > > True. Yet we can imagine situations where this wouldn't work, can't > we? As I mentioned on the beginning - it's a long shot but as long as > the pinout and the ROM code are the same - what else? Maybe some I/O > port bits (which Jim didn't use)? With the same method jim read the rom content, we can test the ram, too. You remember, the pin is named test. ;-) On the other hand, we can analyze the startup sequence from the rom. There is an output pulse on pin PD7. This is for an external watchdog. So it's possible this puls is missing and the mpu was reset every time. The first program codes after reset clear PD7. After some cycles this pin is released to high. Martin Message was sent through the cbm-hackers mailing listReceived on 2014-08-27 03:00:03
Archive generated by hypermail 2.2.0.