• Please review our updated Terms and Rules here

4032 PET with memory problems

JonB

JonB

Veteran Member
Joined
Jan 26, 2014
Messages
1,652
Location
South Herefordshire, UK
Hi VCFEDders

My Fat 40 PET is poorly (again!). I think it is memory - showing 15444 bytes free, so I guess the upper RAM is flaky. Is there a memory tester that plugs into UD11 like Dave M's pettester2 ROM? It's found here: http://www.zimmers.net/anonftp/pub/cbm/firmware/computers/pet/other/index.html

Main reason I ask is there are six ROMs on this machine and the only socketed ones are the editor and character set (as it's a 40 column PET upgraded to 80 columns). We've discussed this PET before and it was a bit flaky then. I fixed it with help but since that time it's been gathering dust. It's a universal board with CRTC.

I want to avoid having to socket all the RAM chips. Previously, I'd written a program in BASIC to test the RAM but when I run it it reports errors (at 16390, 16391, 16392 and 16394) then crashes - so I can't rely on it. POKEing 0-255 into any of these addresses then reading back the values results in no errors (the memory test just uses a single random number).

Thanks
JonB
 
No, you need daver2's new version called PETTESTE2V4 which you plug into the socketed Editor spot at UD7. I will dig up the link to download file and instruction manual.
-dave_m
 
Last edited:
There is my PETTESTER4. This tests the VDU memory, Pages 0 and 1, ROM checksums (for everything excluding the EDIT ROM) and then performs a full memory test (although it does a very quick and dirty test for memory at powers of 2 and will only test what it actually finds). This means that you need at least one byte of memory working (at least partially) at every power of 2 memory location.

To boot, this plugs in place of the EDIT ROM - so no desoldering. It does, however, assume that the reset vector and the first ten (or so) instructions of the Kernal ROM work.

I am on a works computer at the moment - so can't get to my Google drive to give you a link. I'll do that shortly (unless someone else beats me to it). I have also recently posted a link to it in another Commodore repair thread. EDIT: It looks like dave_m is going to beat me to it!

Dave
 
Yes, Greg is mostly right. A 2716, 2816 EEPROM or a 2516 are perfect matches for the E socket (UD7). And by a quirk of pinouts, a 2732 will do the trick without an adapter if the 2K contents are loaded into the upper 2K of the 4K EPROM ($0800 to 0FFF). Or just burn the data into both half's.

Also, since you have a universal board with the X8XX logic, a 2532 can be used as is with the data in the lower 2K ($0000 to $ 07FF)
-dave_m

EDIT: probably the cheapest part to find will be the 2732 EPROM or the 2816 EEPROM.
 
Last edited:
Jon,
While waiting for the EPROM, let's try a quick test using the info from the power up memory test. It stated that you have 15444 bytes free. Since the test starts at the beginning of user RAM (1025), let's add 1025 to 15444 to see what RAM location first went bad. 1025 + 15444 = 16469.
So first let's try for a bit stuck high.
poke 16469,0
print peek(16469)
If results is a non zero, we have a bit stuck high. Convert decimal result to hex or binary to help find the bad bit (chip).
If result was zero, then let's test for bit stuck low.
poke 16469,255
? peek(16469)
If result is not 255, then one bit or more is stuck low. Convert decimal result to hex to determine what bit is stuck, i.e., an 'FF' result means no bit stuck low, while 'FE' (1111 1110) means D0 chip in the upper bank is stuck low.
 
HI Dave and thanks for the advice. Let's try it!

Code: 
poke 16469,0: peek(16469)

returns 0


Code: 
poke 16469,255: peek(16469)

returns 255


Also:

Code: 
list

10 for x=0 to 255
20 poke 16469,x
30 if peek(16469)<>x then print "!";
40 next x
ready.
run

ready.

So all values come back from that address as poked, as if there was no defect at all.

I probably have some appropriate ROM chips somewhere, so by the time you read this I will probably have sorted the test chip out. Fingers crossed!
 
Right. As I thought, there were some 2716s lying about. I have a stack of other EPROMs, too, but can't find them! Luckily the 2716s are in a separate box and to hand. I burned PETTESTE2KV04.bin to a PROM and verified it. Then swapped the editor ROM for the newly burned test ROM and booted up. It got as far as memory test 0 then locked up, which seems to indicate a problem in Page 0 according to the documentation. Drat.

I'll have a look at the assemby file to see if I can work out what addresses it is using (for stack etc) but my 6502 assembly language knowledge is zero. I'm more Z80. But let's see... I think it places the stak at the srat of page 1 ($00FF) but if I reinstall the editor ROM and test around that point I see no errors.

I think I am going to have to pull the DRAM all out and install sockets, or at least the lower bank. Oddness in the editor / BASIC suggests lower bank is faulty.
 
Last edited:
JonB said:
It got as far as memory test 0 then locked up, which seems to indicate a problem in Page 0 according to the documentation.
Click to expand...
Previously it booted to 15444 bytes free which is $3C54 in old money. That would suggest that page 0 is actually OK... intriguing... (In a 6502 the stack is in Page 1... i.e. $0100-$01FF indexed using the S register. Early on in the RESET routine in the kernel ROM is it initialised to the end... LDX #$FF TXS); zero page $0000-$00FF is just normal memory but has the advantage of being accessible by addressing modes that have shorter operands (i.e. low byte only).
I'll get some popcorn.... this looks interesting.
 
Hmm, this will need some thought. I don't seem to be able to desolder the RAM chips with my desoldering station. The solder isn't flowing very well. I've reflowed the single DRAM I was trying to remove and it is back to 15444 bytes free. I really need to narrow this down to the affected RAM chip(s) as taking all of it out will be murder (on me, and the board no doubt).
 
JonB said:
I really need to narrow this down to the affected RAM chip(s) as taking all of it out will be murder (on me, and the board no doubt).
Click to expand...
Before you do... you should verify it isn't a decoding/refresh issue with high RAM... When you did your POKE/PEEK testing.... did you get anything reliable in high (beyond $4000) RAM?
 
You must log in or register to reply here.
Back
Top