• Please review our updated Terms and Rules here

Commodore PET 8032 Boot up problems

M

magicappstore

Member
Joined
Nov 27, 2011
Messages
27
Hi Everyone,

This forum is my last hope of fixing my 8032 which I've had for a while but have only just got round to trying to get it to work.

When I first got it, it didn't do anything when powered on. However after replacing a couple of bad ROMs it now does the familiar sound when booting but nothing is displayed, the strange thing is, and rather concerning is that if I then power off and back on 5 seconds later there is no sound. If I leave it for a couple of hours or so and turn on again I hear the sound again, but there's still no display.

I'm guessing when I hear the sound, its getting far enough through the ROM code to make the sound but on subsequent boots its not even getting to the sound generation in the ROM.

I also have a working 4032 that I have used to verify certain chips are working:

All 4 static 2114s are verified and work
All ROMs have been replaced with EPROMs and verified and work
6502, 6522 verified and work
All RAM has been replaced with known working RAM

Does anyone know what else I can test? Is it possible it's not a chip problem but some other component at fault? Any suggestions would be greatfuly received!
 
I assume you've tried it with a good monitor and video cable?
Have you checked the reset line when it doesn't beep?

Do you have access to an oscilloscope?
 
The 6545 (CRTC) chip was bad on an 8032 that I repaired a while back. Similar symptoms, chirping on boot but no video. Trying a replacement for that chip would be a simple thing to check. Unicorn Electronics has them, I may also have a spare somewhere.
 
Thanks for the replies, after double checking the RAM chips, I found one of them was actually faulty (DOH!) so having replaced that I get the chirping sound every time I boot, though still no display. I replaced them all with 4116 2NS from a couple of spare Spectrums, though I notice the PET uses 3NS speed chips, I assume using faster RAM wont be a problem?

I have a working 4032 sat next to the broken 8032 and I am using the screen from the 4032 when I'm testing as I'm pretty sure the screen on the 8032 is dead. At the moment, with 4 known working 2116 display rams in there, all I get is a black screen, however if I put the original 4 2116's back in (they are all faulty from what I can tell) I get a load of animated garbage on the screen, so the display chip must be working to some degree?

Alas I don't have an oscilloscope, just a multimeter with a very basic knowledge of how to use it:( I've swapped out the display controller (6545) with the working one in the 4032 and it all checks out fine.

I measured the reset line on the 6502 an that is +5V is this correct?

I have an eprom burner, does anyone have or know of a test/diagnostics rom or something for the pet, something that can render something to the screen?
 
Both Eud and me wrote some simple RAM testing ROM programs, but I don't know if either supports a 6545 based PET. At least mine doesn't have any init code for that.
 
Hi Anders,

Ah that makes sense now, I've tried to use the PET Tester rom image that I found elsewhere on this forum with no luck so I guess, like you said, it doesn't support the 6545:( I'll keep looking, I'm determined to get this PET working somehow!
 
magicappstore said:
Hi Anders,

Ah that makes sense now, I've tried to use the PET Tester rom image that I found elsewhere on this forum with no luck so I guess, like you said, it doesn't support the 6545:( I'll keep looking, I'm determined to get this PET working somehow!
Click to expand...
Dave and I were working on a tester modified for a CRTC PET but real life intervened at my end; it should be ready to go, I'll try to test it later today.

Are all your ROMs in sockets now?

Do you have 2532, 2716 or 2732 EPROMs and does your programmer do them all?
 
Hi Mike,

Ah cool, yeah I had a go myself at altering the PET Tester ROM code with no success (My assembler knowledge is very rusty!) and I'm using assembler I found somewhere else to init the CRT chip:

LDA (No.sign)$09
STA $E880
STA $E881

Not sure if that's correct or not?

All the ROMs are socketed so switching them around is easy, my programmer should support 2532, 2716 and 2732 (I'll check actually)

I've replaced all the roms that were originally in there with 2532's that I've also verified on my working 4032.

Whilst I was doing a bit more poking about, I swapped the two 6520's around and to my surprise I didn't get the chirping sound when I booted, I would have thought these 2 chips were identical? I've since swapped them back and the chirping sound has returned. Maybe one of these is faulty, does anyone know what these chips (6520 x2) do? Could a faulty one prevent the PET booting?

Many thanks,

Dan
 
Have you tried blindly typing
? chr$(7)
or just holding the space bar for a few seconds? Maybe it's just a video problem in which case either of those should beep.

Theoretically any chip that's connected to the address and data bus can cause problems.

Sure sounds like one of the PIAs has a problem; AFAIK UB16 is only used for the IEE488 interface and can be removed; UB12 is used for the keyboard, cassette and user port but I *think* you'd still get video without it. Anything different if they're both removed?

Which version 8032 is it, i.e. what's the board number? Have you downloaded the schematics?

What voltages do you see on the video connector?

Have you closely inspected all the IC sockets?

Sorry, doesn't look like I'll have the time for a few days to look at the tester after all.
 
Last edited:
Regarding PET tester code... if it would help I could post the assembler source for my PETTESTER ROM, as long as there's a solemn promise from folks not to laugh at it. (It's the first 6502 code I ever wrote, and because of the design target of making it work without RAM lead to me failing to figure out how to make subroutine calls work without it it's basically a long string of very simple loops cut-and-pasted after each other.) It might be easier to hack the 6545 initialization into the source than into the binary?

"Real Life" has been way too busy for me to do much PET-ing lately, alas. :^(
 
Right then, I've tried a few things that have been suggested, blind typing ?chr$(7) and also pressing random keys for a decent length of time (enough to fill a line anyway) and nothing, no chirp sound. The board just says 80 Column CPU, not sure where to find the board number?

In my working 4032 I removed both 6520's and it still booted to basic okay (though without the cursor), so I removed both 6520's from the broken 8032 and still nothing on the screen, this is with good 2114's, if I put the original (broken) 2114's I do get random characters on the screen.

The voltages I see on the video connector are:

0.13v 0v 4.49v 0v 3.53v - 0v

Is there a pinout for this connector somewhere? Can there be anything wrong with the video connector as I do get random characters if I plug in some bad 2114's, the screen stays black if I use good 2114's:(

I've spent a bit of time with the multimeter testing the pins on all the roms, cpu and crt chip and they all seem to have some voltage going through them.

Regarding PET tester code... if it would help I could post the assembler source for my PETTESTER ROM
Click to expand...

That would be great if you could do that, your assembler can't be as bad as mine;) Though can you recommend a good compiler, I've been using a web based one that doesn't seem too great.
 
Eudimorphodon said:
Regarding PET tester code... if it would help I could post the assembler source for my PETTESTER ROM, as long as there's a solemn promise from folks not to laugh at it. (It's the first 6502 code I ever wrote, and because of the design target of making it work without RAM lead to me failing to figure out how to make subroutine calls work without it it's basically a long string of very simple loops cut-and-pasted after each other.) It might be easier to hack the 6545 initialization into the source than into the binary(
Click to expand...

Hi Eud,
I was looking for the source a while back, but only found an eprom image called "pettester.bin". Was that your latest program?

I disassembled it and added code to initialize the CRTC by loading it's registers with data for the 8032 80 column screen. I haven't tested it as my F000 ROM is soldered in.

Modified disassembly is HERE.

The binary 4K EPROM image file is HERE.
 
Hi Dave,

That's great, I put your modified pettester onto rom and fired up the pet and finally I get something on the screen. First it fills the top of the screen with the characterset and then fills them with 'g' characters indicating good enough good ram. I assume the pettester was designed for a 40 column display which explains why the bottom half of the screen is garbage?

So from this its safe to assume:

There is enough good DRAM
The SRAM is good
The CPU is good
The CRT chip is good
The first ROM socket is good

So assuming I am right in thinking the above is true, the problem must be either a faulty ROM socket or a ROM chip itself. Since I've verified all the ROMs are good as I have used them all in a working 4032, other than a dodgy ROM socket, is there anything else it could be? How do I go about testing if a ROM socket faulty? I used a multimeter to check there are voltages on all the pins on each socket, maybe this isn't the correct way to test them?

Thanks for all your help guys!

Dan
 
dave_m said:
Hi Eud,
I was looking for the source a while back, but only found an eprom image called "pettester.bin". Was that your latest program?
Click to expand...

There are several versions of it floating around, but if you used the one with "2k" in the filename then that should have been the latest version. (The very oldest version had a "defective" RAM test, in the sense it didn't have the correct pair of patterns to exercise every bit. I fixed that shortly afterwards. Then later I made another version that org'ed at F800 instead of F000 to make it easier to burn it into a ROM for an "original" PET, which was the "2K" version. In addition to org change I rewrote all the loops in that one to be more slightly more efficient, since I'd finally figured out a mistake I was making in conditionals. Whee... not that there still isn't some redundant code in there, like the unnecessary jmp-s scattered around in the loop initialization segments.)

Modified disassembly is HERE.
Click to expand...

I guess looking at your disassembly you used one of the older ones. I'll go ahead and attach the source for the latest version.

View attachment PETTESTER-2k.txt

For an assembler I've been using "xa":

http://www.floodgap.com/retrotech/xa/

It seems to work fine but it could certainly stand some improvement to its *very* minimal syntax documentation.
 
magicappstore said:
That's great, I put your modified pettester onto rom and fired up the pet and finally I get something on the screen. First it fills the top of the screen with the characterset and then fills them with 'g' characters indicating good enough good ram. I assume the pettester was designed for a 40 column display which explains why the bottom half of the screen is garbage?
Click to expand...

Yeah, it just works with the first 1k of RAM. (And video RAM). The reasoning behind only testing the first 1k was:

A: it was really quick-and-dirty to just do a 1 to 1 mapping between the RAM locations and the video RAM slots (quick and dirty was important since writing code for the 6502 that *only* uses its built-in registers is really painful), and

B: 1K of working RAM *should* get you to a BASIC prompt, so if you can get that far you have other options for testing the rest.

That's awesome that the hacked version of the tester with the CRTC initialization worked for you!

So assuming I am right in thinking the above is true, the problem must be either a faulty ROM socket or a ROM chip itself. Since I've verified all the ROMs are good as I have used them all in a working 4032, other than a dodgy ROM socket, is there anything else it could be? How do I go about testing if a ROM socket faulty? I used a multimeter to check there are voltages on all the pins on each socket, maybe this isn't the correct way to test them?
Click to expand...

Most of the pins on the ROM sockets are wired in parallel. (IE, they all have A0 through A11, which the exception of the EDIT ROM socket that only uses up to A10, and 8 data lines.) The only unique line to each one is a chip select. Try continuity testing between the matching pins on your F000 socket and each of the lower sockets. Perhaps you have a broken trace? I did on the 4032/2001 dynamic board I was repairing, between the D000 and C000 sockets. At least on the "Dynamic Board" the F000 is on the end of the traces "nearest" to the CPU, which allowed the tester to work even if all the other sockets were cut off. (I can't say offhand but it's very likely the same case for the 8032/Universal boards.)
 
How about adding some LDA/STA loops to the PETtester to display the first 40 bytes at $x000 and $x800 (for the old PETs with 2K ROMs) of each ROM on the screen (with the original F ROM in $A000); that should identify most bad data or address connections and you could probably even get and display signatures out of the PIAs & VIA somehow.
 
Last edited:
MikeS said:
How about adding some LDA/STA loops to the PETtester to display the first 40 bytes at $x000 and $x800 (for the old PETs with 2K ROMs) of each ROM on the screen (with the original F ROM in $A000); that should identify most bad data or address connections and you could probably even get and display signatures out of the PIAs & VIA somehow.
Click to expand...

Sure. I already have some half-baked code written to dump the first page worth of each ROM on the screen, it'd be easy enough to integrate a version of that after the "VRAM test" and "RAM test" loops. All it does, of course, is a "peek-poke" copy to VRAM, but that's good enough to see if there's a problem by comparing the results with a screen dump of the same area in an emulator.

The other test I've thought might be useful is some sort of "clobber detector" to sense if the system might have a stuck address line somewhere, since I ran into that myself, where you'd write a pattern into RAM and see if it were duplicated inappropriately somewhere else a binary multiple distance away when reading back. In my case it was A12 going to RAM that was stuck, which let the machine get to BASIC (with some strange behavior), but a stuck A0 through A9 in particular would cause all sorts of terrible headaches.
 
Most of the pins on the ROM sockets are wired in parallel. (IE, they all have A0 through A11, which the exception of the EDIT ROM socket that only uses up to A10, and 8 data lines.) The only unique line to each one is a chip select. Try continuity testing between the matching pins on your F000 socket and each of the lower sockets.
Click to expand...

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.

I noticed in the working 4032 that if I have only the first 3 ROM's in their sockets the PET will boot to some sort of monitor program, so having tried the same thing on the 8032 I get the same blank screen, so that narrows the problem down to the 2nd and 3rd ROM socket.

Is it possible one of these many smaller chips is damaged? Short of removing all of them and replacing them I'm not sure how I'd go about diagnosing problems with the smaller chips, other than maybe using the multimeter and compare the voltages with the same chip on the 4032 (as both boards are very similar)?

I think I'll have a bash at modifying your pettester code over the weekend to see if I can get it to dump out some ROM values to screen, it's been a while since I did any assembler but hopefully I can get something to work:)
 
You must log in or register to reply here.
Back
Top