Commodore PET 8032 Boot up problems

[magicappstore]

Okay, slight update, so I've taken Eud's pettester code and *borrowed* and changed it a bit and with Dave's CRT init code I've got it to dump out the first 240 bytes of the 4 non-kernal ROMs to screen and after careful comparison I get the same output as I do from an emulator using the same ROMs. So I guess it's safe to say the ROM's and their sockets are all okay if I can read from them.

Which leaves me wondering what is happening in the kernal ROM after the chirping sound but before it displays the BASIC stuff that is stopping the 8032 from showing anything at all?

 

[crock]

Hi Dan,

I've got it to dump out the first 240 bytes of the 4 non-kernal ROMs to screen and after careful comparison I get the same output as I do from an emulator using the same ROMs. So I guess it's safe to say the ROM's and their sockets are all okay if I can read from them.

Although a good indicator, you can't assume that for certain. Reading only the first 240 bytes only tests the lower 8 address lines. A better approach is to checksum the entire rom.

Which leaves me wondering what is happening in the kernal ROM after the chirping sound but before it displays the BASIC stuff that is stopping the 8032 from showing anything at all?

Maybe calculating the bytes free, but I would not expect this to crash unless unless the bottom 1k was bad which I think you have already demonstrated is OK. The other possibility is that you have a RAM addressing fault which is causing writes to higher locations to overwrite the lower 1k area. My best guess would be this or that you still have an undetected ROM issue.

Rob

 

[MikeS]

Hi Dan,
Although a good indicator, you can't assume that for certain. Reading only the first 240 bytes only tests the lower 8 address lines. A better approach is to checksum the entire rom.

Good point; Eud's idea was to avoid using any RAM which would make a checksum pretty challenging, but presumably after the memory test completes that's no longer an issue, especially if you use video RAM.

 

[dave_m]

Okay, slight update, so I've taken Eud's pettester code and *borrowed* and changed it a bit and with Dave's CRT init code I've got it to dump out the first 240 bytes of the 4 non-kernal ROMs to screen and after careful comparison I get the same output as I do from an emulator using the same ROMs. So I guess it's safe to say the ROM's and their sockets are all okay if I can read from them.

Dan,
With the ROMs starting to look OK, I think you should run Eud's latest RAM test if you haven't already. In my patch, I mistakingly used his first version which I think only tested RAM with a $55 pattern which does not exercise data lines in both states. Perhaps you should run with his latest version which includes the complement test pattern of $AA. Don't forget to add the CRTC Init to his code.
-Dave

 

[Eudimorphodon]

Yeah thanks for the info Eud, I've checked the voltages and the pins pretty much all match up except for pin 20, for that I get 0.07V on the first ROM and 4.2V on all the other ROM's, but having tested the pins on the working 4032 I get the same values so that pin must be okay.

What I was thinking was an even simpler power-off check: turn off the machine, put your VOM into "continuity test" mode (if it has a beeper that's useful), and holding one end of the probe against a pin on the F000 socket make *sure* you get a beep from the corresponding pin on the other sockets. The "unique" pin on all of the sockets is pin 20, which goes to the chip select circuitry, but all the others are wired in parallel. A break is sounding less likely since, as your later post points out, that at least the data lines and the lower 8 address lines are okay, but it's still worth a shot. Try it with the chips seated and the probe against the IC legs, to make sure the sockets aren't the issue.

(If you really want to be double-sure you could trace the upper order address lines from the sockets to the 74LS244 buffer in UD14. But I suspect this is a dead end.)

 

[magicappstore]

Right then, I'm having difficulties compiling the updated pettester ROM. Ead, is there any chance you can post the latest binary file and I'll add in the crt code to that?

In my patch, I mistakingly used his first version which I think only tested RAM with a $55 pattern which does not exercise data lines in both states.

You're right, using the out-dated pettester code has hidden a problem with the RAM.
I have written a simple bit of code to write the following values to the 1st 1K of RAM and then re-read it all and output it to the display RAM:

0000-00FF = 1
0100-01FF = 2
0200-02FF = 3
0300-03FF = 4

And have seen there is most definitely something wrong with the RAM, this is a screenshot from an emulator:

http://www.magicappstore.com/pet/ram-test-emu.jpg

And from my broken 8032:

http://www.magicappstore.com/pet/ram-test-8032.jpg

As you can see the values that get written to the upper 1K end up going in the lower part in this strange pattern. I'm not sure what this means, I guess there's a problem with the address lines on the RAM?

As I mentioned earlier in this thread I've tested all the RAM chips in a working ZX Spectrum (which uses them for the display RAM) and they all checkout fine. I'll double check them again though. Out of curiosity, what is the minimum amount of RAM you need in a PET? Just 1 4116 in UA4 and the rest empty which would give it 2KB?

I thought it was too good to be true when this 8032 seemed to pass the original pettester with no problems!

Although a good indicator, you can't assume that for certain. Reading only the first 240 bytes only tests the lower 8 address lines. A better approach is to checksum the entire rom.

Yep, good point, I'll certainly do some sort of checksum function to test the ROMs fully, but since I've found this RAM problem I'll get that sorted first.

What I was thinking was an even simpler power-off check: turn off the machine, put your VOM into "continuity test" mode

Yep I will give this a try now, I guess with the RAM problem I have now found that there may well be an issue with the address lines somewhere.

 

[magicappstore]

At last I have it working! Not being too sure of the cause of the problem I decided to remove UE8, 9 & 10 (74LS244) and put sockets in there with 3 known working chips and bingo, it finally works! In the end one of them turned out to be faulty, the other 2 were okay.

So to summarize the problems with this PET:

3 Broken ROMS (Kernal, Display, Basic 1)
4 Broken 2114 display RAMS
1 broken 4116 main RAM
2 broken 6520's
1 broken 74LS244

Luckily I had a spare Motorola 6821 sitting around which is directly compatible with the PET 6820 so I've added that to get the keyboard to work, I'll have to get another from somewhere.

So now I have the main board working I need to get the screen working (I've been using my 4032 display up until now) but I think that may be a bit much for me, unless there are any suggestions, at the moment when I boot up with pettester in the rom there is, for a split second, something on the screen and then.... Blank..... I may need to find a local specialist for this one.

 

[dave_m]

At last I have it working!

You have done a great job so far, congratulations!

-Dave

 

[dave_m]

So now I have the main board working I need to get the screen working (I've been using my 4032 display up until now) but I think that may be a bit much for me, unless there are any suggestions, at the moment when I boot up with pettester in the rom there is, for a split second, something on the screen and then.... Blank..... I may need to find a local specialist for this one.

Do you get a glow in the CRT neck which would indicate that the tube is getting high voltage? If not, perhaps the voltage regulator on the video board is broken or a capacitor needs replacement. Hopefully it is something that can be easily fixed. If it is the high voltage transformer, that may be another matter.

 

[Eudimorphodon]

Hey congratulations!

I was just comparing your screenshots to the schematic and scratching my head, and if I had to take a wild guess I'd say the problem was *probably*... either UE8 or UE10?, but I'd have to put this down on paper and think about the logic for a while. (This is why the tester needs some sort of clobber-detection loop, which is what you did there.)

This really should motivate me to dig into my broken 8032. Like yours I'm pretty sure both the motherboard *and* the monitor have some faults, and fear of the monitor innards have kept my tinkering mostly confined to the PETs with working screens.

 

[magicappstore]

Do you get a glow in the CRT neck which would indicate that the tube is getting high voltage?

When powered on the tube does indeed glow. I checked the brightness control and made sure that was on full but still no display.

This is why the tester needs some sort of clobber-detection loop, which is what you did there.

Ha! Yeah, I had an idea it was to do with the address lines so just took a guess and removed all the chips to see.

This really should motivate me to dig into my broken 8032. Like yours I'm pretty sure both the motherboard *and* the monitor have some faults, and fear of the monitor innards have kept my tinkering mostly confined to the PETs with working screens.

Yep I hope you do have a go fixing your 8032, I was just lucky I had a working 4032 to test a lot of the chips otherwise I'd have probably given up long ago! I don't really want to be messing inside the monitor bit either so will probably try and find someone locally who can repair old TVs to take a look.

Thanks guys for your help getting this crazy mixed up PET working again!

 

[jac_goudsmit]

Do you get a glow in the CRT neck which would indicate that the tube is getting high voltage?

To be precise: the glow is the filament which does NOT run on high voltage but on something like 6V. In other words, if you don't see the glow it's definitely a sign that something is wrong, but if you DO see it, it's not a sure sign that the HV is working.

when I boot up with pettester in the rom there is, for a split second, something on the screen and then.... Blank.....

That sounds like basically the monitor circuit is working but it turns itself off or something. I have NO experience repairing anything with CRT circuitry (I'm too chicken to play with high voltage) but as I understand, the FAT40 hardware included some protection circuit in the CRT circuitry to prevent the "killer poke" from destroying the screen. I imagine that that's probably implemented as a monoflop (e.g. a 555) that turns large parts of the circuit off if there's nothing coming in on the hsync and/or vsync lines. Sorry I haven't looked at the schematics so this is probably not very helpful. But if you see a flash on the screen and it's not simply a dot in the center but it has a horizontal and a vertical, then "most of the monitor" is really working but the beam is just not being turned on and off. That probably means it's not too hard to repair. In theory.

===Jac