Hi all,

New to this board, and actually, quite new to repairing a Commodore PET 8032-SK.

I need to repair it, because it has an issue:

Actually, it has changed a bit now. Only the first line is beeing repeated now (the line with the basic version).

What I've done so far:
- Reseated all socketed chips
- Checked the board's voltages (they're ok)
- Recapped the board

When I leave it on for some time, there is no obvious overheating of certain chips.
I can hear the regular normal beeps when I turn it on.

This version has the universal dynamic board: 8032089

Does anyone have a clue on what could be causing this issue?
Any help would be appreciated.

Checked the voltage on all ICs. All good.
Also found a scratch on the board, but tracks seem to be intact. Conduction is still ok.

So, what could be a next step to check?
anyone?

Compare the ROM contents with a known good copy from a file on a Commodore site maybe

Is it getting to the BASIC prompt?

Does it respond to commands?

Mark

Nope, as shown in the image


So, as far as I can deduct...
1. This issue is not due to CharRom (I see clear chars)
2. This issue is not due to I/O
3. This issue is not due to RAM (it is/was showing n basic bytes free)
4. This issue is not due to CPU

So that leaves me with these possible failures...
1. Video (6545-1)
2. ROM

Ok, three questions:
a) I don't have an EPROM programmer. Should probably get one right? Which one though?
b) Does anyone know which socketed chips could be safely removed, while it would still bootup?
c) Is there any way to tell if the 6545-1 is broken using a multi-meter?

hello, Rednael

Welcome. It's interesting to see your problem posted here. Unfortunately, due to the holiday season you may find the responses fairly slow. Also, this forum focuses on 6502 in general... which includes Commodore, of course, but Commodore is not the main focus.

CBM Hackers, as you may guess from the name, does focus on Commodore, so you may wish to make your situation known to them. It is an email mailing list, so things are managed differently than here on 6502.org. You'll find an archive of the email topics here, as well as a Register link.

There's some great expertise there, and a willingness to assist. Some of the individuals are also members of the 6502.org forum. Good luck, have fun, and keep us posted!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I don’t think the 6545 is faulty, as you are getting a reasonable display. I’m not saying that it’s 100% good, but for it to display a stable video image with readable text, that means 90%+ of it is working.

I suspect, in this order: partial ROM failure, possibly partial RAM failure.

Although it’s managing to set-up the correct register contents for the 6545 (otherwise you would get a blank screen) and doing a memory test, obviously something is causing either an infinite loop or the CPU has been sent off to execute random code somewhere causing a crash...

Mark

Thanks, Mark. I agree -- this seems reasonable. Not sure what to recommend as the next step, though.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I am by no means a CBM expert nor do I have the schematics.

The only speciality I see is that the column where the RAM size text appear seem to be col 64 (leftmost column is 0). That corresponds to just one bit of an address line (data line less probably) - perhaps between 6845 <=> buffer/muxes/etc <=> video RAM?

Just an observation.


Cheers

Do you get the same issue if you power on the computer with the keyboard NOT attached?
I'm wondering if there are some stuck keys or dirt or something causing the keyboard to freeze up and cause garbage on the screen.

_________________
Cat; the other white meat.

Thanks all you guys for the help so far. My replies have been lacking, but that's due to the fact that I bought an oscilloscope and had to wait for it to arrive.


I've checked all the RAM (dynamic) and Video RAM (static) with my oscilloscope. I couldn't find any faults.


Yes, no difference. It has a detachable keyboard anyway, so I tried that even before I picked up the screwdriver.


Yes, this made most sense to me. So, what I see is that all Video RAM is active on all the datalines.

EDIT
Not on all address lines. I've read an incorrect datasheet. So, now I can see that column-lines on the MCM2114 static video-ram are all active. And that the row-lines only have 2 lines active as normal and 4 lines get some weird 50 Hz pulse (vsync)

Actually, I started out with checking the addresslines output from the 6545-1 (video chip). That chip can be configued to work in binary addressing mode or in row/column adressing mode. As the MCM2114 (static video ram) works with row/column addressing, my guess is that the 6545-1 is configured to do the same.
So what I learned from probing the 6545-1 addresslines, is that column-lines 0 to 6 are active and 7 is always low. This is to be expected as only 80 chars are displayed (and not the max of 90).
However, the row-lines 0 to 3 are always low, as is 5, and only row-line 4 is active. And, although row-line 4 is active, it only sends out a pulse of 50Hz. That's only once every VSync (not HSync).

All this still leads me to believe that the 6545-1 is faulty, because the same line is repeated over and over on screen. If the row selection is bad, this could be an expected screen output, would it not?

Hmm, but what if that asumption is flawed? In binary addressing mode, all chars are read sequentially from ram. 90x34 chars (maximum for the 6545-1) = 3060. That number takes 12 bits. The 6545-1 has 14 address-lines, of which the 13th creates the weird 50Hz pulse.

EDIT
On the video mem (MCM2114) chips this results in A0 to A5 beeing high, A6 to A8 beeing low and A9 has the pulse

Still, why does line 13 pulse at 50Hz? Is this on purpose or is this indicating a flaw? Couldn't find anything about this in the datasheets.

Hmm, another thought... It must be more then just a screen flaw.

Still, no difference. But when I do attach it and type chars and newlines over 25 times, new text should have been written in video memory. Still, no changes on screen. The system hangs completely.


Hmm, perhaps I should take a closer look to that ROM after all.

Two questions:

1. Does anyone know of a method of validating a ROM chip withouth having an EPROM programmer (and without having additional spare ROMs)?
2. Which EPROM programmer would be good for me? Remember I'm a starter, focussing on 8 and 16 bit computers.

Any suggestion would be helpful.

So about the EPROM programmer...
I figured out that to read the Kernel ROM (2316) or the Basic ROMs (2332) I can use most common programmers, but to write an equivalent (2516 and 2532) EPROM I need a programmer with a voltage of 25V. As those programmers are quite hard to find if you don't want to pay too much money, I'm looking for alternative EPROMs.

It looks like the 28C16A could be a stand-in (https://www.jameco.com/Jameco/Products/ProdDS/74691.pdf). The pins of the DIP package seem to match. The only thing I'm uncertain about is that it is specified as an in-system programmable EPROM. I do have a hunch on what that means, but... can I just programm it with a current common cheap EPROM programmer? For example with the TL866II Plus (http://www.autoelectric.cn/en/tl866_main.html)

As an aside, I have used a 27C256 in a Commodore 128 option ROM socket and was able to boot the machine with the ROM initialization code being executed during boot. The exact EPROM isn't critical as long as it has a JEDEC standard pin arrangement. You just ignore that ROM space that you don't need.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!