Commodore PET Monitor not working

[SiriusHardware]

Sorry I misdirected you over the UB9 / UB10 buffers based on what seemed like a good hunch at the time, but they do commonly fail so you may yet be grateful for their already being in sockets when that time comes.

Colin's last PET repair had a very similar 'final fault' on one of the DRAMs which the Tynemouth diagnostic didn't pick up but Pettester did. I think Colin was considering sending that chip off to the chap who makes the Tynemouth Gadgets to see if he wanted to try to 'harden' the RAM test so that it would pick that chip up - the fault on your UA12 sounds very similar, maybe you could send that one over to Tynemouth software as well.

This thread benefited a lot from Colin's experience and knowledge gained from using these tools, I noticed.

[ScottishColin]

Any time. Glad I could help.

My first PET repair here had 1,839 posts so it seems some of the help I got then has stuck.

Have you put the extra RAM (to make it an 8096) back in and is it working?

Colin.

[centrespot]

Originally Posted by centrespot

Well what do you know, UA12 was faulty.

I now have a working PET 8096

I have learnt a lot, from not relying on the Tynemouth devices to gaining a bit more knowledge on the way a Commodore PET works.

Thank you both for your excellent help and advice.

May have been a bit hasty, I have a working Commodore PET 8032, yet to test the expansion board.

[centrespot]

When the expansion board is fitted it shows the standard 32k on boot up, it doesn't boot giving the extra 64k, apparently this is correct and normal.

Is there any way of testing the extra 64k of RAM by maybe pokeing and peeking.

[ScottishColin]

I've not seen one and can't find a great deal of information. It seems that very few programs supported the extra 64k anyway.

The best I have is below:

http://primrosebank.net/computers/pet/repairs/pet_repairs_ext_ram.htm

where it seems that loading a version of Zork will show whether the RAM is recognised or not.

Dave at primrosebank.net (contact webmaster@primrosebank.net) has always been very responsive to me in the past over email if you wanted to ask him any further questions.

People helping out is one of the good things about the vintage computer scene for me - most are responsive and helpful and want little or nothing in return.

Colin.

[SiriusHardware]

Also an article here on where else but the Tynemouth site explaining how user-unfriendly the memory expansion is:-

http://blog.tynemouthsoftware.co.uk/2024/07/commodore-pet-64k-128k-ram-boards.html

...Not really of course, it's just that due to the way it is implemented the extra RAM is 'paged' and to easily make use of it you need to be able to interact with the machine at hardware / assembly language level. When the extra memory is swapped in, the BASIC ROMs are swapped out so BASIC can't use that memory.

This is roughly similar to the same dilemma on other machines where 'enhanced' official versions of the machine or third party memory add-ons added more memory than there was space for in the original memory map - even the ZX81 had a 64K (and possibly even bigger) RAM expansion available from the likes of Memotech but BASIC could only 'see' 16K of that so it was rarely utilised much by commercial software which tended to be written for the lowest common version of the system so that it could be sold to the maximum number of users.

Does anyone know how much software even used more than 16K of PET RAM?

[centrespot]

Sorry but I'm in need of a bit more advice.

I switched the 8096 PET on again this morning and it booted up but some of the on screen characters are not right.

I've socketed and tested all of the 4116 RAM just in case that was the issue and I've swapped out all of the 6502/6522/6520 and the ROM chips.

Can you explain why characters are not as they should be, for instance the 'i' is showing as 'a' and the 'k' is showing as 'c'

When I press the keyboard letter 'i' several times it displays

iaiaiaiaiaiaiaiaia

and the 'k' displays

kckckckckckckc

[ScottishColin]

Here's a screenshot of PETSCII (the Commodore version of ASCII).

https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg...mdoZDAbK1sy/s1600/Business+mode.jpg

What I think is happening is that you're 'losing' 8 bits:

i is hex 09 and is showing as a - hex 01
k is hex 0b and is showing as c - hex 03

So there's a problem with address D3 (either even or odd ram):

https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-09.gif

https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-08.gif

So I think it's either UB4 or UB6. Or perhaps UB10 as both of UB4 and UB6 are common to UB10.

https://www.zimmers.net/anonftp/pub/cbm/schematics/computers/pet/8032/8032029-01.gif

What we need now is Sirius to tell us how to check....my last 8032 had a very similar problem and it was the common chip - in this case UB10.

Colin.

[SiriusHardware]

I'm very busy at work and have to be somewhere for most of the rest of the evening so I'm afraid you'll have to forge ahead -

The first thing you need to work out is whether it is only even, only odd or a mixture of both columns which are affected.

Remember we decided to count the columns starting from column '0' at the left hand side across to column '79' at the right hand side which makes columns 0, 2, 4, 6, 8, 10.. etc the columns which are rendered from the 'even' screen RAM and columns 1, 3, 5, 7, 9, 11... etc the columns rendered from the 'odd' RAM.

Centrespot needs to look carefully at the characters which are being 'transformed' and and count across the screen from column 0 to decide whether all the 'wrong' characters are in 'even' columns, or all in 'odd'columns, or in a mixture of both.

What does the Tynemouth diagnostic gadget say about the state of the odd and even video RAM when this fault is present?

[ScottishColin]

The Tynemouth diagnostics board should show Video RAM issues. The attached example shows errors in Even video RAM (8000-87FE is even RAM, 8001-87FF is odd RAM).

If the Tynemouth board shows the D3 error in both even and odd then I would be suspicious of UB10. If it only shows it in one of the lines, then I'd be looking at the D3 even or odd RAM chip, depending on which line it is in.

Colin.

[centrespot]

I socketed UB4 & UB6, UB9 & UB10 were already done

Tested all 74LS244 chips

Still the same issue

[centrespot]

It looks like they are all 'even'

[ScottishColin]

Are you able to replace UB10?

Colin.

[centrespot]

Originally Posted by ScottishColin

Are you able to replace UB10?

Colin.

UB10 is socketed and I've already swapped chips, no change.

[ScottishColin]

Need someone with more problem determination experience than me now.

[SiriusHardware]

Still busy, but UB10 / UB9 are common to both banks so would not affect only even or odd columns. If the video RAMs are all socketed try swapping the odd and even pairs over to see if that makes the fault move to the odd columns. If not then it's likely to be one of the buffers associated only with the even RAM, Colin should be able to figure out which one given that you have identified the likely faulty bit.

[SiriusHardware]

Sorry if I'm suggesting going over ground which has already been covered, I don't have access to the diagrams at the moment.

[centrespot]

Originally Posted by SiriusHardware

Still busy, but UB10 / UB9 are common to both banks so would not affect only even or odd columns. If the video RAMs are all socketed try swapping the odd and even pairs over to see if that makes the fault move to the odd columns. If not then it's likely to be one of the buffers associated only with the even RAM, Colin should be able to figure out which one given that you have identified the likely faulty bit.

I swapped the odd and even 2114 chips and the fault crossed over to the odd columns. I systematically changed each 2114 video RAM chip and found that one of them was the culprit.

Frustratingly it tested fine in my RETRO-chip-tester.

Is there anywhere I can read up on what each circuitry does because I had no idea that the video RAM chips worked in pairs and control the odd and even columns.

[ScottishColin]

Here's a start - I'm sure there are other places. The Tynemouth blog assumes a level of knowledge but has quite a lot of good practical PET stuff.

http://blog.tynemouthsoftware.co.uk/2017/08/commodore-pet-video-ram-faults.html?m=0

I've had RAM chips that test ok but fail under load on the PET so it seems the best tester is the PET itself.

Have you got 31743 bytes free back again?

Colin.

[centrespot]

Originally Posted by ScottishColin

Here's a start - I'm sure there are other places. The Tynemouth blog assumes a level of knowledge but has quite a lot of good practical PET stuff.

http://blog.tynemouthsoftware.co.uk/2017/08/commodore-pet-video-ram-faults.html?m=0

Thank you, I will have a look.

Originally Posted by ScottishColin

Have you got 31743 bytes free back again?

Yes, all seems ok for the time being. I am planning on connecting a commodore double disk drive unit next, that may throw up more issues.