• Please review our updated Terms and Rules here

Commodore CBM 8032 video display problem

Here's a direct link to the post in my (about a year ago) first epic thread about trying to repair a PET where, once I got it to get to the debugger, discovered what was wrong with the BASIC ROMs:

http://www.vintage-computer.com/vcf...Ts-(2001-8-4032-and-8032)&p=183901#post183901

The screenshot in that post shows the ML command I used to discover the problem; if you have another identical working PET or access to the VICE Commodore emulator you might be able to narrow down very quickly whether this is a bad ROM chip or possibly a bad socket/trace.

Use the "M" command to display a range of memory near where the PC halts, which in your case is "c5b1". A command like "m c5b0 c5f0" will give you a nice bite-size chunk of data to look at. On your working Commodore or the VICE emulator from BASIC run "sys 1024" to jump to the monitor, run the same command, and compare the contents. Examining that can clue you in whether you're dealing with a dead ROM chip, or if there's a "stuck bit" pattern that could mean a bad trace or line.

(In my case, doing a few dumps revealed that I had a broken trace affecting all the ROM sockets from C000 down.)

If the "M (16 bit hex number) (16 bit hex number)" command *really* doesn't work then you do indeed have a more complex issue.
 
From your original post:
The computer beebs when you fire it up, and there is movement on the screen when I press keys. I also get an error beep if I hold the space bar down etc. So I'm pretty confident it's not an issue with the CPU. I've cleaned all the dust off the PCP/tracks and checked for dry joints. I plan to re-seat the seated chips later tonight to see if that helps.
Click to expand...
Sounds like this is no longer the case, if you're in TIM but typing does nothing; any possibility you forgot to put back a swapped chip or undo some temporary test mod, or accidentally disturbed something? Replacing the 2114s should not have caused this.
 
MikeS said:
Sounds like this is no longer the case, if you're in TIM but typing does nothing;
Click to expand...

His screen shots show him typing BASIC code into the monitor, and the monitor's response to them seems normal. (IE, it's sticking question marks after the first character of the line number saying "what?".)
 
Eudimorphodon said:
His screen shots show him typing BASIC code into the monitor, and the monitor's response to them seems normal. (IE, it's sticking question marks after the first character of the line number saying "what?".)
Click to expand...
Oops, sorry, didn't look closely at the pics (using dial-up) and somehow understood that typing TIM commands like 'M' didn't work but it looks like he hasn't actually tried it and is trying BASIC commands instead. So, let's see if TIM commands work.

And JIC, does it in fact still beep when starting up and/or holding the space bar?
 
Thx guys!

A few Q and A's before I begin today.

1) One important bit of info which I wasn't aware of until now (as I've never seen a working 8032). When I switch on the computer, I get one series of beeps as it goes straight to the MCL screen. There's no series of events that lead to it, so I'm presuming it only makes it to 'step one' in the initialisation process stage. As soon as the crt comes on, you see the MCL screen.
2) I don't have access to another working 8032, and it won't respond to MLC commands (but you can type from the keyboard as seen in my other pics). So I'm presuming I would only be able to fix this problem by replacing chips?
3) So...if that's the case, which chip/location would you suggest I start with? Or should I be checking for something else (via DVM) before doing that?

I'll start with researching your suggestion...

Jules (Lovin the learning Curve!!)
 
Juleshsmith said:
2) I don't have access to another working 8032, and it won't respond to MLC commands (but you can type from the keyboard as seen in my other pics). So I'm presuming I would only be able to fix this problem by replacing chips?
Click to expand...

What commands specifically have you tried?
 
I think most of the common ones (found a PDF on commodore MCL) plus just random letters...

What's interesting is if I put down a MCL command like "M" then hit enter, it will just go to the next line, but if it's a non MLC command (eg "U") it will put a "?" after the character (eg "U?") and go to the next line. So it's sort of recognising what's MLC, but doesn't do anything with it.

Does that help Eudimorphodon?
 
BTW Eudimorphodon, I actually read your forum on DOA pets last week in hope of understanding my issue! Couldn't get the image of all these pets just sitting there, in the warehouse dump. They are really rare in Australia. You would only see one locally on ebay maybe once a year tops. I bought one locally that was really really DOA (using for my spares), but still paid over $400 (it also came with a dual 4040 drive which is my next challenge).

The one I'm working on now, I actually got shipped over from the USA (postage was twice as much as the computer), but it's been a blast trying to fix it!
 
Nah, nothing happened with "R" at the dot prompt or "G FD16". Basically not responding to any commands, so I think that avenue is closed.

If it's not getting past stage one in the startup, does that indicate a specific ROM issue in the chain (eg UA9 etc)?

Does the piggyback technique work with ROMs Dave?
 
So typing "m(space)1234(space)1256 (enter)" (lowercase "m" is fine) literally has no effect? (Screenshot?)

If that's true the next guess I'd probably hazard is a zero page RAM problem?
 
Ok here are some interesting clues...

I went through every letter at the prompt and hit enter.

Three letters showed some activity

Every time I type "X" [return] I get the start up MCL info but the "xr" value changes each time (eg "e2" "de" "ea" etc). The other values don't.

Likewise with "G" the "pc" value changes (eg "c5b2" "c5b3" etc)

But what's most intriguing is when I hit "L" it asks me to "press play on tape #1" ! Seems to be the only command it's reponding to.

I have a vic 20 C2N tape player which I understand can be used on the 8032? If this is the case, could this be an opening if I had the right program to re-set RAMs etc?

EDIT: C2N tape player is compatible. Might see if I have a simple vic 20 program (which I understand can work) to test out... worth a shot!

UPDATE: Plugged in C2N. Tape 'plays' but nothing changes on the screen (don't think the 8032 is communication with the tape player yet). So may not be a way in.
 
Last edited:
Eudimorphodon said:
So typing "m(space)1234(space)1256 (enter)" (lowercase "m" is fine) literally has no effect? (Screenshot?)

If that's true the next guess I'd probably hazard is a zero page RAM problem?
Click to expand...

Yes, a zero page RAM problem would cause havoc with the BASIC system variables. But does it explain the problems once in the machine monitor code? Of course a page one problem could cause corrupted stack data. That will screw up all the subroutine return information. I agree that Jules should now worry about his low RAM. Perhaps a piggyback test there might get lucky?
 
Juleshsmith said:
So, in "I'm not really great with electronic" terms, does that mean UD9 is the culprit?
Click to expand...

Not necessarily, but it's an important suspect. As others already noted, there are many other things that might cause similar problems: a bad contact such that one bit from the ROM is always 0 (it takes only one bit to change a JSR ($20) into a BRK ($00)) or a borked address decoder that enables chips at the same time when it's supposed to enable the C000 rom.

but how would I "dump the ROM areas to screen and compare the output to known values"
Click to expand...

I know there is information online about how to use the MLM. A quick Google shows me that a good command to start with would be: "M C5A0,C5FF" without the quotes; then post another screen shot. Note the comma (not space) between the start and end address.

With "known values" I meant ROM dumps which may be available online or can be generated by others. Also, "known values" means known opcodes. I know many people (like me in a distant past) were so familiar with 6502 machine language that they can disassemble the instructions in their heads, or at least see patterns in the hex dump, or, if anything, the absence of patterns.

Note, the MLM is pretty simple; I don't even think it has a disassembler. The most important commands it understands are:
.M XXXX,YYYY (memory dump)
.: XXXX YY YY YY... (change memory)
.R (display register)
.G (go)
.L (load)
.S (save)
.X (exit to Basic)

In true Commodore style, the monitor works together with the editor. For example you can do a memory dump of a RAM memory area and then just change a value by going to the line with the cursor key, modifying the value(s) and hitting Return, because the output format of the M command is the same as the input format that you use to change values.

You mentioned that you don't think the monitor is working, but I think it is; You tried typing Basic lines into it, and it put question marks (for "syntax error") behind each line number (and ignored the rest of the line). Then you typed "RUN" and it interpreted the R as the Registers command.

Doing "X" to exit to Basic is not going to work of course: Basic is clearly broken. The changing X register (value under "XR") on each try of the X command is irrelevant. If a cold start ends in a BRK, a warm start is probably not going to work unless you replicate the work that the Basic ROM normally does between the cold start and the warm start.

Also, because the cold start of Basic never finished, there's really nothing you can conclude from any values you find in the Zero page, because it may not have been initialized yet.

Anyway, let's see a screen dump of the area where the BRK occurred and we might know more: try "M C5A0,C5FF" without the quotes from the MLM prompt and let's see what you're getting. Meanwhile, if anyone else has an 8032, maybe they can tell us what that hex dump SHOULD read?

===Jac

PS: I just thought of something: I (and others) wrote the commands in upper case (force of habit). But the 8032 initializes in lower case character set mode. I'm not sure if the MLM is case sensitive but you should enter the commands without using the shift keys, regardless of whether you see upper or lower case on the screen. I wonder if that's why the M command didn't work :)
 
Good call Jac! I put in the "m c5ao..." command and it worked (see pic). What does this tell you???

M c5ao.jpg

Heading out for bout an hour. I know it's probably really late over where you are, but if you can leave me some suggestions I can work on, that would be awesome!

Til then...

BTW Jac, I have been entering the MLM commands in upper case, so I may go back to the MLM pdf and try the commands in lower case. Thx again!
 
Last edited:
Couple notes:

jac_goudsmit said:
I know there is information online about how to use the MLM. A quick Google shows me that a good command to start with would be: "M C5A0,C5FF" without the quotes; then post another screen shot. Note the comma (not space) between the start and end address.
Click to expand...

I didn't use a comma, so I decided to test this on VICE. It turns out that the MLM genuinely doesn't *care* what the deliminator between the two hex numbers is. You can use a space, a comma, a random letter, it's all the same.

PS: I just thought of something: I (and others) wrote the commands in upper case (force of habit).
Click to expand...

Yeah, I was wondering about that myself which is why I put a lowercase "m" in that "try typing exactly this" comment a couple lines back. Testing with VICE confirms, it hates an uppercase M on an 8032.
 
Juleshsmith said:
Good call Jac! I put in the "m c5ao..." command
Click to expand...

The "o" in your command there should be a zero. But it doesn't matter, your screenshot still tells us what we need to know. That screenful of zeros means your C000 ROM is completely kaput for some reason. Run a few more commands:

"m d000 d02f"
"m c000 c02f"
"m b000 b02f"
"m a000 a02f"

And post the results. The first is a sanity check, as is the last. The two in the middle might help us figure out if it's a bad ROM or a broader issue.
 
You must log in or register to reply here.
Back
Top