8032-SK Restoration

[Gary C]

Humm

MUX A is dead. UE2 has activity on pins 10 & 11, but pin 9 has nothing.

Taken out of circuit and shows error in the tester (thanks Dave, your recommendation to buy one when I was fixing the Apple ][ was spot on, I have used it times without number)

Shame I dont have a spare on me.

 

[daver2]

>>> What I also dont get, it writes $00 to say address $0000 and gets back an @ in inverse, what bit pattern is that. @ is $40 or 0100 0000 but in inverse ?

Don't forget we are talking about PETSCII here - not ASCII...

An '@' (in PETSCII) is $00. An inverse '@' is $80.

If you fit a reset button and video the screen when you do a RESET (or read my documentation for PETTESTER that indicates what a video screen RAM pass should look like) you should be able to discern the '@' and inverse '@' and (from their character position) ascertain their PETSCII code.

Yes, the problem is almost certainly down to either data line 7 or a multiplexed address fault.

Be aware that Commodore did a few 'tricks' with the main DRAM multiplexing... For example, on an 8032, DRAM A0 is multiplexed from BA0 (via UE9) but BA13 (via UE10)! Because the CPU reading and writing is commutative (it doesn't matter where it writes to or reads from within the DRAM array - providing it is unique and consistent) then this doesn't (actually) matter - until you need to diagnose a fault! You may be looking at BA7 and it is BA13...

Perhaps use a NOP generator to debug the main DRAM address multiplexers?

Dave

 

[Gary C]

Don't forget we are talking about PETSCII here - not ASCII...

An '@' (in PETSCII) is $00. An inverse '@' is $80.

Ahh, I was looking up the PETSCII set and I miss read it. This link seemed to show a normal video '@' as $40

 

[daver2]

Yes,

You have to remember we are dealing with the PET at the 'bare metal' level - so whatever is programmed into the character generator is what is displayed on the screen without any interfering software.

Dave

 

[Gary C]

Thanks, thats a useful picture, now saved. Worth adding to the PETTEST manual ?

 

[Gary C]

Woo hoo !

As reported in the last update, I was seeing no activity on MUX A which is used on the RAS & CAS address buffers. Following this back it came from UE2 which was a 2 input multiplexer which was showing a Low output on pin 9 (MUX A) no matter the activity on the input pins.

Chip swapped and PETTTEST now running past the Page 0/1 test and onto the DRAM test which is running with no errors as I type this.

With MUX A low all the time, it would mean that the CAS buffer was never selected and RAS buffer always was so when CAS was low, it wasn't getting the right address

 

[daver2]

Chalk up another fix for the PETTESTER...

But still requires some "wetware" to interpret the results and identify the culprit. At least the PETTESTER points us in the right direction...

I was supposed to be on site next week - but currently "holed up" in the spare bedroom recovering from a positive Covid test last Sunday. No major symptoms though.

Dave

 

[Gary C]

Ahhh, hope you don't feel too bad. I've not had it yet (or more likely, had it and not noticed. Just remembered I was called 'patient zero' in 2020 !,but I was only ill for a day and didn't have a cough).
The DPS system performed well during the heatwave, fortunately all the chillers were working. It was the UPS systems that were complaining. In the control room though, we were shivering a little as the A/C was running a little too efficiently. Must have been the only cold people in the country.

Yes, without PETTESTER it would have been very very difficult to identify the fault. Its a superb tool.

Its happily running DRAM tests now but (there is always a but)

With the Edit ROM back in, booting gives the normal message but pressing return causes it to crash, sometimes keys give what you would expect, other boots they give graphics characters. Though that could be a keyboard problem, all keys seem to respond as expected within PETTESTER.

All the installed ROM's during PETTEST give the right checksums (4168 5960 a425 & cf19), so I'm assuming they are ok. Will need to test the Edit ROM to make sure that is ok.

I believe that typing is done in screen memory then tokenised and moved to main memory on pressing enter ?

Edit ROM check first then any ideas ?

I will probably burn a copy of the 901474-04 program into a 2532 EPROM as well (but, doh, of course I can use a 2716 for this as well )


LATE ENTRY

The DRAM test is now throwing up an error after running sometime with the case closed. Showing error

Initially showing
"Mem fail 3 1 4558 10 10!"
now consistently showing
"Mem fail 3 1 4558 10 1f!"

So in the upper 16K bank of the memory and bitmask of 0001 0000 so bit 4 so probably UA10 has gone south. Dave, whats the significance of the 'faulting data byte' and that it changed from 10 to 1F ?

 

[Gary C]

Would it be an idea to amend PETTEST to calculate the checksum of the ROM in one of the spare sockets so the Edit rom could be put there and tested as part of the diagnostics ?

 

[daver2]

The fault finding byte is the actual data itself that was read from the RAM. The MARCH-C memory test treats the RAM as an array of bits - not bytes - so the value is interesting - but not too informative unless you look up the specific MARCH-C memory test that failed. The presence of other set or clear bits may indicate further potential data faults to follow...

Normally, the MARCH-C test would sweep 'up' or 'down' memory either setting or clearing bits - so an isolated '1' bit (as in $10 = 00010000) looks suspect in a byte containing all other bits clear.

I think you are on the money regarding the upper bank data bit to go for - although I haven't checked your IC reference.

I will think about adding another ROM checksum display but (of course) it will be a 4K device instead of a 2K device...

Dave

 

[Gary C]

I will think about adding another ROM checksum display but (of course) it will be a 4K device instead of a 2K device...

Dave

Couldn't you calc a checksum on the first 2k and the whole 4k and display the results for the user to interpret from what chip they know is fitted ?

BTW, does it seem likely that its an Edit ROM problem with the way its failing when I press return ?

Anyway, UA10 removed but tested fine, but then again it had had time to cool down so new chip soldered in and.......

its passing the ram test.

 

[daver2]

You should have done this test yesterday in all of that heat!

Dave

 

[Gary C]

I have verified the Edit ROM with one of the files from Zimmers (the 9014747-04 one with the comment "An alternative version of the above. Which one is correct?", anyone know how to contact the host of Zimmers and let them know that file matches an 8032-SK Edit ROM with the date code 0283) and it passes so it doesn't look like the Edit ROM is faulty

I suppose its possible that the failing RAM chip was throwing it out, but it only started failing quite a while after. Still, thats the next test, to put the Edit ROM back in with the new RAM chip.

 

[daver2]

Yes, go to the bottom of http://www.zimmers.net/ and all will be revealed.

You could be experiencing a problem with a PIA or VIA?

Dave

 

[Gary C]

Ok, will try removing them.

But am wondering what part they play ?

 

[Gary C]

When I reset the unit it always comes up with the title screen but sometimes pressing a key gives a graphic character, sometimes a normal one, sometimes pressing return gives 'syntax error' sometimes I just get a CR/LF and most of the time it just crashes (ie pin 7 no activity)

When its printing graphic characters, the GRAPHIC line from the VIA is high, when its printing lower case its also high.

So, poking around, I note that the BCD decoder UC11 has activity on the input A B C D pins, but nothing at all on pins 1 to 11.

Which seems highly odd that I am seeing anything at all when I type.

UC11 is fine but cant work out why the 'outputs' from the device are always low until you press a key ?

Also, if you hold repeat down, then a key, when it comes to the end of the line, it plays a little tune ?

Help !

 

[daver2]

>>> UC11 is fine but cant work out why the 'outputs' from the device are always low until you press a key ?

Be aware that the outputs from the UC11 are open collector. You would only get volts at the output of UC11 due to the following action:

1. The pull-up resistor pack UB11 on the INPUTS to the PIA on port B.
2. A key is pressed in the key matrix.
3. The associated output from UC11 is NOT active (i.e. not being pulled low by UC11).

You should (however) observe low-going pulses on the input of the PIA on port B - coincident with the key press and the scanning of the key matrix as a result of UC11.

The open collector nature of UC11 outputs causes much confusion! Of course, you can use a temporary pull-up resistor to +5V to see if the UC11 outputs are actually working. Just stick the pull-up resistor on the end of your oscilloscope probe...

Dave

 

[Gary C]

Ah, makes sense. Didn't really think it was the problem

Here is something odd.

If I type "10 m" then "LIST" I get "22.7901599 m" back as the program (used m so it didn't tokenise it). Suggests a fundamental memory problem thats not being picked up by diagnostics ?

Am I right in saying that as you type, the text is put in the static RAM memory, then when you press return its interpreted and moved to DRAM ?

 

[Gary C]

Would suspect one of the ROM's if the checksum's in the diagnostic weren't right

 

[daver2]

Most likely RAM.

Don't forget that the tests are 'poor' for refresh-induced faults. So if the refresh counter or MUX or the DRAM itself is faulty in this area - you will have latent issues.

Dave