• Please review our updated Terms and Rules here

8032-SK Restoration

I am currently working on a comprehensive memory test system (combination of hardware & firmware) specifically for the dynamic PET where the IC's are soldered in, so as to identify the defective DRAM IC's (with any kind of DRAM defect) and does not require any functioning DRAM to work and checks for refresh problems too, but it won't be finished for about a month.

Some simple observations though. There are essentially 3 common ways the DRAM can fail. A stuck high or stuck low output pin, or effectively an open circuit output pin equivalent to a non responsive IC.

Rarer problems include IC's which ignore ranges of addresses. I have been collecting a large number of 4116 IC's, especially defective ones for experiments and analysis. Failure to retain data over time, effective failure to refresh can be another problem. There are potentially more complex problems and interactions that can occur too.

In the 32k PET the outputs of pairs of the DRAM IC's (in the upper and lower banks ) are shackled together.

In the case where one IC of a pair contributing to the bit is non responsive, or effectively has an open output pin, it does not interfere with the other IC on that bit which it is connected to. If this IC is in the lower bank I, the computer won't boot because all bytes below $4000 are defective . If this bad IC happened to be in the upper bank though, the computer will boot and BASIC will report only 15359 Bytes Free (if the computer is otherwise working). Because when BASIC looked over the address range $4000, the memory returned defective values. An open output pin (or non responsive IC) is interpreted as logic high via the buffers, so this is reflected in the returned byte value and indicate exactly where the defective IC is in bank J.

On the other hand, if any of the DRAM IC's have a stuck high or low output pin the computer (in its normal state without a Pettester system) is disabled. And in this case, any kind of memory test system, can only resolve the defective DRAM IC in a 32k PET down to one of a pair of physical DRAM IC's in the same bit position of the upper and lower bank. Though, that pair is easy to identify from looking at the way the returned bytes have been corrupted and which bit is defective, stuck high or low.
 
Last edited:
What I'm having problems with is, PETTESTER is not finding any memory errors in either the DRAMS or the SRAMS, all the ROM's checksums are right and the EDIT ROM checks out on my programmer. The keyboard test works fine. When powered up, I get the beeps and the expected startup display.

Yet, when I type, sometimes I get characters, sometimes graphic characters, sometimes I press return and the CPU stops, sometimes I get syntax error, sometimes it just does a CR/LF.

Now as I understand it, as I type, the characters come in through the 6520 and the CPU using the EDIT ROM program transfers them into display memory, then when I press return, it goes into the BASIC area in DRAM as tokenised code.

It feels as if its to do with the screen editing function throwing errors. This is all done in SRAM I believe Dave ?
 
Just noted that one of the SRAM's I used to replace a faulty AM9114EPC is not a 200ns unit like the original but a SRM2114C25 which is a 250ns device. Didn't think it would be enough to cause a problem and it passes PETTESTER but do we think that could be causing the random errors ?
 
Last edited:
I would have thought a 250 ns part would be fine... I haven't run the maths though. If this is for the video RAM - I would have thought that you would have observed problems with a normal display.

Dave
 
Yes, it does seem unlikely but I am clutching at straws now.

I dont understand how it can crash when everything seems to work

I have a couple of PIA's & VIA's coming as spares anyway and will try them, and some SRAM

How does the PET work when editing a program ?
 
Replaced both 6520's, the 6522, the CPU and the Edit ROM (happen to have spares of each) and in each case it boots to ready but from then on its unpredictable. Most of the time now, a single character and return gives syntax error, but sometimes just locks. Typing a line of basic locks the machine as soon as enter is pressed.

Got some correct spec SRAM's coming very soon so will try them.

Dave, how extensive is the SRAM memory test ?
 
>>> How does the PET work when editing a program ?

>>> Now as I understand it, as I type, the characters come in through the 6520 and the CPU using the EDIT ROM program transfers them into display memory, then when I press return, it goes into the BASIC area in DRAM as tokenised code

To my knowledge this is basically correct. The PET scans the characters via firmware (within the EDIT ROM) and uses the 6520 to do this. The results are then displayed on the screen. If the character(s) on the screen are correct - then the character(s) from the keyboard must have been scanned correctly.

The EDIT ROM maintains a pointer to the current line that is being processed on the screen. This pointer (as all pointers are in 6502 land - with a few exceptions) are stored in page 0 DRAM. So if page 0 DRAM becomes corrupt - all bets are now off...

My PETTESTER VDU SRAM test is fairly crude (as is my initial testing of page 0 and 1). I have a much better test to implement for Version 5. This is guaranteed to identify many more errors in page 0 and 1 (before starting the MARCH-C DRAM test) and I will roll this out to the VDU SRAM test.

My initial assumption was that if there is sufficient VDU SRAM working to pass the crude test, any further faults within the VDU sub-system should manifest itself as an observable fault by the human as subsequent tests are performed.

Unfortunately, I have very little spare time available these days to actually do anything apart from answering posts on VCFED. I have a deadline to meet to clear our C&I stores at Barnwood before we move offices (no space in the new offices) and I have lots of work on at your site that is taking up most of my time!

Dave
 
I also keep getting 'out of memory' errors.

Corruption of zero page basic pointers ? Feels like memory error and zero page with all those BASIC pointers looks very vulnerable.

So, the plan is to modify the exit from the zero page test and make it continually loop that test and see if it throws any random errors.
 
This all smacks of a page 0 memory error, memory corruption - or the DRAM has amnesia...

A slow DRAM address multiplexer?

Dave
 
A slow multi should show up on the MARCH C test I would think ?

I am running page zero tests now repeatedly and just getting a screen of ggggggg

(thats after sticking my fingers into the mains compartment, ouch !!!!!!!! Good job I'm highly resistive)

Going to do a quick edit to continually loop between the video and page 0 tests (as I can't actually see if its still running ATM as the screen is static)

The HN462532G EPROM's were a good buy. My machine can program them fine.
 
A slow multi should show up on the MARCH C test I would think ?

I am running page zero tests now repeatedly and just getting a screen of ggggggg

(thats after sticking my fingers into the mains compartment, ouch !!!!!!!! Good job I'm highly resistive)

Going to do a quick edit to continually loop between the video and page 0 tests (as I can't actually see if its still running ATM as the screen is static)

The HN462532G EPROM's were a good buy. My machine can program them fine.
So with a slightly modified PETTEST running the SRAM & Page 0 DRAM tests, I dont seem to be getting any errors at all.

The amnesia bit ? I wonder if I have a refresh problem, but that would mean the memory test would have to run so fast as to effectively self refresh ?
 
>>> The amnesia bit ? I wonder if I have a refresh problem, but that would mean the memory test would have to run so fast as to effectively self refresh ?

It does...

They have just delivered a Merc. for me to get to site! Are you working tomorrow?

Dave
 
>>> The amnesia bit ? I wonder if I have a refresh problem, but that would mean the memory test would have to run so fast as to effectively self refresh ?

It does...

They have just delivered a Merc. for me to get to site! Are you working tomorrow?

Dave
Yep, I am in :)

Shift manager tomorrow so I can actually move around the station !

So the program could be self refreshing ?
 
I wish I could help more at the moment. I am building a type of memory tester for the Dynamic PET which finds faulty DRAM, but it also checks if the DRAM are losing data either because there are defective IC's, or because the external DRAM support circuitry is defective (call these internal or external refresh defects).

It works by replacing low DRAM with SRAM, by electrically deactivating the low DRAM (disabling reads below 0400h or 0800h) and substituting in SRAM on the expansion connector to ensure BASIC runs properly. Then an assembly language program installed just below 0400h running in SRAM checks the DRAM above 0400h, but in a certain way, so as to to pick up refresh problems or bank select issues.

SRAM of course runs independently and doesn't require all the DRAM support circuitry including the address multiplexers E3 to E6, or the circuitry that generates the /CAS0 and /CAS1 /RAS0 (more gates G1, G7, Flip flops H1 & multiplexer H4 etc) , so with the SRAM running all of that circuitry can be checked on the scope with a small read-write program loop running, crossing the address boundary 3FFFh, even though none of this support circuitry's outputs are then required to run BASIC with the SRAM supporting it, but the signals are still active for test purposes.

The thing about DRAM is; any memory test program that writes to it and reads from it with a narrow time interval won't find external or internal refresh problems.

It is good for a DRAM test protocol to fill the entire memory with FF, leave it some minutes, then fill alternate locations with 00. Again wait, then read the memory to the screen with the M/L monitor, any defects are easily seen in the pattern. This also allows for bytes at adjacent locations being altered when they should not have been. Then reverse the process writing 00, with adjacent bytes made FF over that later. Then another program where any desired byte can fill the whole memory and that can be checked for retention of data over a long time frame.

But I have been away (back now) so I can finish it in the next week or two.

(Out of memory errors can crop up at booting if BASIC goes to the DRAM memory to check its upper address so as to report it and finds no valid memory working above 0400h).
 
The good news was the the pcb's for my PET memory test system/project arrived in the post. They are Gold plated types, beautifully made. In this case the PCB maker was Storm Circuit in China. The owner, Mr. Kim Chan is super helpful and he was able to convert my old school .jpg artwork into Gerbers and make these boards.
He also gave me a cute pcb ruler with various track formations and sizes. His company also makes very highly detailed multi layer boards for various research institutes and Universities. And they have a very quick turnaround.
 

Attachments

  • PCB1A.jpg
    PCB1A.jpg
    132.4 KB · Views: 8
  • PCB2A.jpg
    PCB2A.jpg
    117.5 KB · Views: 8
Interesting

Will the Gerbers be available generally or would we have to order via storm ?

Dave, did you have a good day ?

I was snowed under. You might have heard the tannoys about problems with the Fuel Handling building H&V :)
 
I was somewhat busy as well...

We got a lot of work done, and I didn't do any of it! Must be destined for management...

I have to go back in tomorrow to the doc. centre, so I may see if you are available sometime later in the morning.

Dave
 
Interesting

Will the Gerbers be available generally or would we have to order via storm ?

Dave, did you have a good day ?

I was snowed under. You might have heard the tannoys about problems with the Fuel Handling building H&V :)
I'm not sure. I have not figured this out yet, if it is the pcb company makes the gerbers, if I own them or they do. I will ask. In any case it is a very simple pcb thankfully.
 
Back
Top