• Please review our updated Terms and Rules here

PET 8032 - No Chirp, No Cursor

When you have finished testing your RAM, you could make the ROM from my article and run the programs from it (you won't need the hardware adapter now BASIC is running). Two of those programs work by writing the whole memory with a checkerboard pattern. First (one of them) fills the whole memory from 0400h to 7FFFh with byte 00. Then after that it writes over alternate address locations with FF. (the other program does the reverse FF then 00). The idea behind this is to check that writing into memory cells doesn't alter byte values at other locations. Also, because there is a delay in inspecting that programmed pattern (done with the M/L monitor) it also helps confirm that the memory retention is good and that the DRAM IC's all have a normal refresh function , as this is another way that DRAM IC's can fail, aside from the other 4 ways their outputs can be defective.
Yes, I am absolutely going to do this. Thanks! I'll let you know how it goes.
 
>>> But that makes me wonder about what you said about a marginal device elsewhere

This is highly unlikely if there are no errors in the first bank of 16K - all of the data buffer and address multiplexers are common to both banks of 16K.

You could be really unlucky and have a set of RAMs in the lower 16K that work OK with (say) the data buffers - but a set of RAMs in the upper 16K that don't (even though the RAMs themselves are within specification). This is an unlikely scenario though (but not impossible). It is more likely that you have a bank of RAM that was all made at the same time (same batch numbers) that are all failing for a similar reason.

Dave
 
>>> But that makes me wonder about what you said about a marginal device elsewhere

This is highly unlikely if there are no errors in the first bank of 16K - all of the data buffer and address multiplexers are common to both banks of 16K.
Ok, good to know. I assumed there were different support chips for each bank.
You could be really unlucky and have a set of RAMs in the lower 16K that work OK with (say) the data buffers - but a set of RAMs in the upper 16K that don't (even though the RAMs themselves are within specification). This is an unlikely scenario though (but not impossible). It is more likely that you have a bank of RAM that was all made at the same time (same batch numbers) that are all failing for a similar reason.

Dave
Wow, that's crazy. Well, we'll see what the results are when I get home from work. This machine almost HAS to have taken a power hit. So far, I've replaced 9 RAM chips (admittedly, a couple of the ones in the upper bank may not have been necessary), BOTH 6520s failed, the 6522, one 7417, the Edit ROM. I think that's everything....
 
>>> Ok, good to know. I assumed there were different support chips for each bank.

Checkout http://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-05.gif. Everything (apart from the /CASn signals) are common - unless you have a faulty PCB track of course...

>>> This machine almost HAS to have taken a power hit.

I think it is just the luck of the draw. Some machines are an easy fix, others are more challenging (shall we say).

Some machines also could have been 'pushed' rather than 'jumped' by their original owners just turning them on after 40 years + of storage without any testing or precautions. They don't work, so they just get sold as seen. Before they switched the machine on they may have been an easy fix. Afterwards...

Usually, this is accompanied by the letting out of the magic smoke - but not always...

Dave
 
Up to pass A6....so I think we might have it! Next will be to replace the bad 6520 for the disk drive, and see if I can load anything from tape and/or disk.
 
Long weekend, and very little time to play with my retro stuff. But I finally got some time to load up some programs and demos last night, and everything looks good! I can't thank you enough for your help!
 
When you have finished testing your RAM, you could make the ROM from my article and run the programs from it (you won't need the hardware adapter now BASIC is running). Two of those programs work by writing the whole memory with a checkerboard pattern. First (one of them) fills the whole memory from 0400h to 7FFFh with byte 00. Then after that it writes over alternate address locations with FF. (the other program does the reverse FF then 00). The idea behind this is to check that writing into memory cells doesn't alter byte values at other locations. Also, because there is a delay in inspecting that programmed pattern (done with the M/L monitor) it also helps confirm that the memory retention is good and that the DRAM IC's all have a normal refresh function , as this is another way that DRAM IC's can fail, aside from the other 4 ways their outputs can be defective.

Hugo, when you said 'make the ROM from my article', I assumed there would be a .bin file or something. Is it just that little snippet of code in the article? I've never assembled a ROM from scratch before, though it might be interesting to try.
 
Hugo, when you said 'make the ROM from my article', I assumed there would be a .bin file or something. Is it just that little snippet of code in the article? I've never assembled a ROM from scratch before, though it might be interesting to try.
Here is the .bin file . I wasn't sure how to put that in the article I wrote as a link, so I just listed the bytes. The instructions how to run the 4 programs (using SYS commands) in it and examine the memory using the M/L monitor are in the article.

We cannot upload files here on the forum with the .bin extension, so I changed it to .pdf, you will have to change it back to .bin to use it in your programmer. If all is well when you inspect the file in your programmer (or in a Hex Editor program) it should exactly match the bytes in the article.

(Generally if I want to make a small file by hand I do it in the Hex Editor program entering them one by one which is fairly easy though it would take a while for a big program). I use the readily available GQ-4x programmer.
 

Attachments

  • nnn.pdf
    4 KB · Views: 2
Just a hint for the future, you can put all sorts of files including .BIN files into a .ZIP file, which is considered a legitimate attachment type. The advantage of doing so is that you don't have to temporarily rename, then un-rename the file(s) in the .ZIP file.
 
Back
Top