Den Thu, 28 Sep 2017 19:14:02 +0200 skrev Francesco Messineo <email@example.com>: > Now for the real "funny" part: pettester.bin shows no error both on > VRAM and on the system RAM, but using the original kernel EPROM on UD9 > gives a garbage screen. I haven't had a look at the source code that dave_m just posted, but AFAIK the petester.bin can't tell if there is something wrong with the adress lines/decoding, only if some data bit is stuck. I.e. you'd need a test that fills memory with 0,1,2,3,4,... and afterwards check if they read back correct. Preferably only fill up to 254 instead of 255 as that would be good enough to catch problems even if A0-A7 are good. (Just filling all memory with 0-255 and mirror that on each page would of course not show any problem with A8 and the higher adress lines). Maybe it's kind of hard to do this without reling on any ram at all. Although without any reliable ram at all you might use the stack pointer as a temporary storage (TAS, TSA or whatever the instructions are called) and with a large enough rom you could unroll some loops so you don't need a loop counter. Or the tester code could start with a check if some screen ram or some main ram seems ok and use that as a temporary storage. (If access to main ram does bad things with screen ram or vice versa I think it would be hard to make the tester run at all). Ideally I think the test should run through all memory with 0-254 or perhaps preferable 0-255 but repeating one of the values, and run the test 256 times starting with a different number each time. That'd probably catch more or less all kinds of errors. One thing the tester could do is check if the I/O chips work and output it's state to the user port or use the user port data register as a temporary storage. I haven't looked that much at how the two popular tests for C64 works, but AFAIK one of the tests uses border color to send "flash codes" to tell if it detects bad ram (i.e. one flash and a long pause for fault related to D0, two flashes with short pause between them and then a longer pause for faults at D1 and so on). I don't know it it's possible to do anything similar on a PET. If it isn't possible to flash the screen somehow it might be possible to "flash" the tape recorder motor. However as you anyhow need some electronic skills to insert a test rom in a PET you might aswell use some dongle on some port to display results, i.e. a row of LED:s on some port. The tests that are available for C64 requires no electronic skills torun as they are usually placed in a cardridge that you just plug in (using the GAME signal with disables most on-board adress decoding so the cartridge is placed at the top of memory and the CPU will run the cartridge even if all ROM and RAM is broken in the C64. You just need a working CPU, PLA and partially working VIC and all other chips mustn't drive the bus when they aren't adressed, then the test runs). P.S. I'm one of the best at making up more or less good ideas and one of the worst at actually taking the time and energy to implement them :) -- (\_/) Copy the bunny to your mails to help (O.o) him achieve world domination. (> <) Come join the dark side. /_|_\ We have cookies. Message was sent through the cbm-hackers mailing listReceived on 2017-09-29 19:00:03
Archive generated by hypermail 2.2.0.