• Please review our updated Terms and Rules here

CBM 8032SK's blank screen

Dave, do you think it would pay to piggyback a CRTC before going through the trouble to remove it?

Matt
 
KC9UDX said:
Dave, do you think it would pay to piggyback a CRTC before going through the trouble to remove it?

Matt
Click to expand...

Matt,
I was thinking of that too. It is probably worth a shot since both the vertical and horizontal signals are stuck high and can be pulled down with the new chip. It may be difficult to keep all 40 pins aligned. Perhaps if pin 1 and 21 of the piggyback were to be tack soldered on to the 6545 on the board?

I found your post of November 2014 on removing a chip:

I always use a socket, out of fear of overheating the chip upon soldering. I know full well that I can safely solder just about anything without frying it, but still do it anyway. Sockets are cheap, and you will be happy with yourself for using one.


I too have never had great success with desoldering braid. With the cheap (manual) solder sucker that Radio Schack sells, I can safely and quickly desolder any DIP chip without damaging it. Buy two of them though, they break easily.


The trick is in the technique:


1) Re-tin each pin before attempting to desolder.
2) Heat a pin just enough to completely melt the solder on it. This takes practice to get just right.
3) When the solder is melted, remove the iron, and quickly put the sucker all the way over the pin, squarely against the board, with pressure; and push the release button. If you keep the sucker squarely pressed against the board, and the tip of the sucker is in good shape, most, if not all, the solder will be removed.
4) Use a solder tool, or a screwdriver, to make sure the pin is mechanically free. If it's not, keep pressure on it, and apply heat with the soldering iron. When the pin comes free, wiggle it as the solder hardens so that it doesnt get stuck again.


This isnt as hard as it sounds, and can be done very well with patience. I have no trouble desoldering and re-using the most sensitive chips this way.


It will help if you cut the chip off the board first, but I usually don't bother. It's easy to damage a board doing this anyway.


Also, desoldering on a PCB should almost never be done with a heat gun or 250W soldering gun. I couldn't tell you how many times I've had to repair a board when someone else did that.
Last edited by KC9UDX; November 19th, 2014 at 08:30 PM.
Click to expand...
 
Interesting idea that of piggybacking; I'll try as soon as I get a replacement CRTC.

Thank you very much for they desoldering tips, guys. I still have some more questions though:

- Heat the pin instead of the solder, is that right? From the components side or the other?
- Pump from the bottom side I guess? What if using desoldering braid?
- And my main doubts: thick or thin tip and what's the best temperature? Too big/high and it might burn the PCB/lanes quickly... too small/low and it will require longer to melt the solder giving the heat more time to spread and cause more extensive damage.
 
I just received an UM6845 that I got from ebay and tried to piggyback it. I still don't get any sync signals.

I've tried to mount it on top and remove it a few times and as far as I know it's making good contact. I pushed the legs inwards using a flat surface, so they fit quite tight over the 6545's ones and the chip doesn't move the slightless. So it might not be the CRTC after all.

We'll know soon, when I check what initialisation instructions it's getting. I already received the logic analyser and the hooks must be about to arrive too.

I also received the sockets; the desoldering braid and flux should arrive soon. I only had lead-free solder, so I also ordered some leaded solder for both soldering and helping desoldering any components. That should arrive soon too.

In the meantime, I'd like to clean the monitor's PCB. It's quite dirty:

IMG_20150613_154306.jpg

When it was given to me I was told that this computer came from some kind of mechanical garage or workshop, so those deposits might even have metallic dust. And although I don't think they are causing any short circuits, I'd prefer to remove all the grime before connecting the monitor again (that is, if I manage to repair the computer's board).

But I don't have any experience with CRTs, so any clear instructions about discharging it and handling it safely would be more than welcome.

And I'd like to separate the monitor's metal frame from the base case, so I can give it a good wash like I did to the monitor's covers, which look now brand new compared to the rest of the computer. As I didn't remove the monitor's PCB yet I can't see how they're joined. From the bottom side I couldn't see any obvious way of separating both parts. Are they easy to separate and put together again?

Once again, thanks for all your guidance.
 
luismcv said:
I just received an UM6845 that I got from ebay and tried to piggyback it. I still don't get any sync signals.

I've tried to mount it on top and remove it a few times and as far as I know it's making good contact. I pushed the legs inwards using a flat surface, so they fit quite tight over the 6545's ones and the chip doesn't move the slightless. So it might not be the CRTC after all.

We'll know soon, when I check what initialisation instructions it's getting. I already received the logic analyser and the hooks must be about to arrive too.
Click to expand...
Did you notice any change at all? Any change means the chips are different. You don't necessarily get the correct result by piggybacking, but any change at all is significant.
attachment.php

But I don't have any experience with CRTs, so any clear instructions about discharging it and handling it safely would be more than welcome.
Click to expand...

You need a "chicken stick" which is simply a long conductor connected to the chassis, with an insulating handle. If you think you'll be doing this a lot, I highly recommend getting an analog high voltage meter instead. Otherwise you can improvise a chicken stick easily:

Get a long flat -blade screwdriver, preferably with a small tip. Also get a jumper wire with alligator clips on each end, these are sold at Radio Shack whilst they are still in business, else you can get them online. Finally, get at least one glove.

Clip one alligator clip (one end of the wire) to the metal chassis, or to a ground strap around the CRT, or the metal mounting ears of the CRT.

Connect the other end of the wire to the screwdriver shank, make sure it's electrically connected to the tip (some screwdrivers have plastic insulating the tip from the shank but this is rare).

Skip this step if it worries you, but I like to turn the monitor on at this point. Let it warm up a few seconds and then turn it off and unplug the power supply. Read on and I'll explain why.

Put one hand in your back pocket. With the other hand (in glove) grasp the screwdriver handle. The glove here in optional, but good practise. The plastic handles on the average screwdriver are not intended to protect you from high voltage electric fields. You shouldn't be in the circuit anyway, but at high voltages, these things get hairy. Don't panic though, nothing here will kill you.

Slip the screwdriver tip under the insulator around the 2nd anode button. That's the thing that looks like a suction cup. You will probably hear some snap crackle pop here. That's how you know you're doing the right thing. This is why I powered up the unit earlier. If the tube is discharged already, you'll never know if it really is, or you're just doing something wrong.

Use the screwdriver to pry up the rubber so you can see the metal clip underneath. Note how it is inserted so you know how to disconnect it later. Touch the tip of the screwdriver right to the metal clip and hold it there for a while. The longer the better. You may want to stop here, go have a snack, then repeat the process (certainly skip the part about powering up though! ) CRTs tend to recharge themselves after a while.

Put the screwdriver down, and with your other hand still behind your back,squeeze the second anode connector and remove it from the CRT. This is not at easy as it sounds and it's why you need to really get a good look underneath the rubber.

From here on the tube will no longer bite you.

You could also make a better chicken stick out of a wood dowel and finish nail. But if you're going to do this often enough to make that worthwhile you're better off (in my opinion) investing in a high voltage meter instead.
 
I would wash that bottom board at the same time as the frame. Spray it all with Scrubbing Bubbles and thouroughly rinse it in the shower.

Use a hairdryer, or air gun to completely dry it (be careful with the heat). It wouldn't be a bad idea to set it out in the sun for a day.
 
No, I didn't notice any difference. I measured both sync pins (39 and 40) and both showed the same HIGH values.

Thanks for such detailed instructions. It doesn't sound too hard.

Anything else to be aware of? Can any of the capacitors in the PCB hold a dangerous charge?

Wash the PCB? with water, really? Water here in London is quite hard, wouldn't it be bad?. I bought some isopropyl alcohol spray, would it better? Or wash it and then displace the water with the alcohol and leave it dry for a day or two (I don't have a hair dryer)?
 
Well, I "discharged" the CRT today and cleaned its PCB. With quotation marks because I didn't hear anything, so I'm not even sure it was charged to start with. I first tried without switching on the monitor (that had been off for a couple of weeks now). Nothing. Then I re-checked with the multimeter that there was a proper connection between the screwdriver tip and the metal frame of the monitor (I tried several points, even the "ring" around the front glass), I switched on the monitor for 15 secs or so (but disconnected from the computer's board), switched it off and tried again. No pop, sparks or anything. So, still with the thick rubber gloves on, I removed the suction cup and, just to be 100% sure, I touched the frame with the hooks. And once again, nothing.

Do this mean that the flyback transformer or any other componet related to it is damaged? I remember reading somewhere that some parts of the CRT's circuit don't get enabled without a signal, but I can't find anything now. Is the high voltage circuit one of them?

Anyway, I managed to clean the PCB with isopropyl alcohol, a brush and some cotton buds. Couldn't remove all the grime, but 99% of it is gone. I was also able to remove the CRT tube and all the parts and connectors from the case and give it a proper wash, which it really needed.
 
luismcv said:
Do this mean that the flyback transformer or any other componet related to it is damaged? I remember reading somewhere that some parts of the CRT's circuit don't get enabled without a signal, but I can't find anything now. Is the high voltage circuit one of them?
Click to expand...

The high voltage circuit uses the Horizontal Drive signal (20 KHz) as the switching input to the transformer. Until you get at the 6545/6845 initialized and running, you will not be able to tell if the CRT is OK. If the D6 ROM ($FXXX) happens to be on a socket, you could try the petest2 program there. If that does not work to start the video timing signals, it is pretty sure the 6545 is dead as petest2 does not depend on RAM or other ROMs to run.
 
Last edited:
Commodore 8032 Video Information

Commodore 8032 Video Information

luismcv,
I've got the last 10 pages from my Commodore 8032 Tech Manual as a .PDF. It should be a big help since it has the O'scope signals.

PM me with your email address, and I'll email it to you.


Thanks.

Larry
 
Today I received the hooks for the logic analyser and tonight I've been capturing the data.

I've just finished so I didn't have time yet to properly study it, but it'd seem that D1 and D5 are stuck high when the CRTC is being accessed (not the rest of the time). I'd help to know exactly what data it should be receiving, to compare the bits one by one. Does anybody know in which ROM is this part of the initialisation? Is its disassembled code available somewhere?

I'm sharing the data in case anyone is curious.

https://drive.google.com/folderview?id=0B9aiS8TBHDFzfnNnSXVTelpxUkgxZFR0WVRMUGZiWEswcFplbXNhWlp1Z3h0WmtPd2E0cG8&usp=sharing
 
luismcv said:
but it'd seem that D1 and D5 are stuck high when the CRTC is being accessed (not the rest of the time). I'd help to know exactly what data it should be receiving, to compare the bits one by one. Does anybody know in which ROM is this part of the initialisation? Is its disassembled code available somewhere?
Click to expand...

Great work. This would indicate a problem with data in the Edit ROM (UD7). Look at the table at the bottom of the disassembly for the contents for the CRTC registers.

Code: 
; Initialize CRTC -- Patch for BASIC 4 80 columns


 E07A    iE07A    LDA #$2A
 E07C        LDX #$E7
 E07E        LDY #$0E
 E080        BNE $E088




; Initialize CRTC --


 E082    iE082    LDA #$3C        ; this adress for 40 columns
 E084        LDX #$E7
 E086        LDY #$0C
 E088    iE088    STA $C7        ; Store address of CRTC constant table at C7 and C8 (low byte, hi byte)
 E08A        STX $C8
 E08C        LDA $E84C
 E08F        AND #$F0
 E091        STA $D1        ; Length of Current File Name; temp use of this location by CRT Init?
 E093        TYA
 E094        ORA $D1        ; Length of Current File Name???
 E096        STA $E84C        ; Selects lower case for business or upper case/graphics  
 E099        LDY #$11    ; Prepare to store 18 bytes (add 00 to 11H) from address E72A into the CRTC registers
 E09B    iE09B    LDA ($C7),Y    ; load next CRTC constant, indexed by Y register
 E09D        STY $E880    ; Store 6545/6845 CRT Controller Register Number (select the register)
 E0A0        STA $E881    ; Store 6545/6845 CRT Controller Register Data (transfer data into register)
 E0A3        DEY        ; decrement Y
 E0A4        BPL $E09B    ; If not finished, branch back to $E09B
 E0A6        RTS




; -    Video Chip Setup Table -- e07a        DATA BASIC 4 80 columns


 E72A        .byte 31 28 29 0F 27 00 19 20  ;R0 to R7 
 E732        .byte 00 09 00 00 10 00 00 00  ;R8 to R15
 E73A        .byte 00 00                    ;R16 & R17




; -    Video Chip Setup Table -- e08a        DATA BASIC 4 40 columns


 E73C        .byte 31 28 29 0F 31 00 19 25  ;1().1..%
 E744        .byte 00 07 00 00 10 00 00 00  ;........
 E74C        .byte 00                       ;.
 
Thanks a lot Dave. Did you disassemble the ROM yourself? Are all the ROMs (or at least more parts of them) disassembled and available for download somewhere? I tried to search on Google some of the comments and all I could find where your other posts in this forum.


I don't think I'll have much time for this at least until the weekend, but I'm not sure what to do next.

Unfortunately UD6 is not socketed. The possibly affected ROM - UD7 - is, though. As well as the CPU, UA3, UD11, UD12 and UF11.

I've been comparing the expected values with the ones received:

Screen Shot 2015-06-17 at 20.47.28.jpg

but I don't see a clear pattern here. Apart from bits 1 and 5 that seem to be stuck high, there are other bits that go high when they should be low and vice versa (just in case someone is wondering, yes, I noticed in the code that the registers are initialised in reverse order, starting by 17 and ending by 0). I'll probably capture this a few more times again to make sure the corruption is not some random, but I did the least significant bits twice the other day and both reads were identical.

I've been recommended to build a NOP generator and exhaustively test all the paths of the address lines, between every IC and every buffer. But to be honest, I find a bit difficult to believe that there is something wrong with the address lines. After all, the CPU seems to be loading and executing the CRTC initialisation code (albeit this is receiving the wrong register addresses and values).

If the data is corrupted when the CPU is reading it from the ROM it makes more sense that it's corrupted in the actual ROM than getting corrupted on its way to the CPU. After all, the instructions came from the same place and through the same way.

The corruption could also happen between the CPU and the CRTC, but there is a direct connection between them; no possible broken buffers in between. So it could be that the CPU is outputting the wrong values (rare) or that the CRTC is corrupting its data inputs when it's enabled (maybe actioning a read instead of a write?).

There is also the possibility that any other IC connected to the data bus is getting enabled and outputting data when it shouldn't, but somehow conditioned to some signals that are enabled when writing to the CRTC, as it's obviously not interfering at other times, like, once again, when the CPU is fetching code. Maybe I should get the logic analyser, hook it again to the 4 control lines of the CRTC and use the other 4 inputs to check that no other IC gets enabled during writes to the CRTC?

Or take advantage of the Edit ROM being socketed, buy a cheap eprom programmer and read and compare its content to a dump. I guess they're on zimmers? Also, I'm not sure how many content variants there are... I think I read that some ROMs were different depending on things like the keyboard's language; I don't know if this is one of those that change. This is a computer built in Germany (I guess, SERIAL NO. WG) with an QWERTY keyboard).

Other option I just though: These CPUs are very simple. I guess that they don't have any kind of caches, instructions pipelines or anything like that. So in theory, I should be able to see the instructions and data coming into the CPU as it's executing this code. Probably using the CRCT's CS as a trigger to find the right point in time.

Anything that I might be missing? Any other suggestions? What would you do next?
 
ACTUALLY, just after submitting the post I've realised that I was missing something: I don't think the ROM is corrupted. It it were, either the code wouldn't work at all, or only the data (if only that part of the ROM was affected) would be wrong. But the register addresses are generated by the code; at most, they could start by another value, but they should still be decrementing by exactly 1 on each step. The corruption must happen between the CPU and the CRTC.
 
luismcv said:
So in theory, I should be able to see the instructions and data coming into the CPU as it's executing this code. Probably using the CRCT's CS as a trigger to find the right point in time.
Click to expand...

Yes, trigger on the CRTC chip select and check a few of the data lines especially the one you think is stuck. As you know, the /CE are in pairs, first register address (from $11 to $00) to address $E880 and then register data to $E881.

From zimmers, here is some disassembly files

I'll mail you a 50 HZ EDIT ROM burned into a 2532 or a 2716. Use private message to send me a shipping address.

At Matt says using a NOP Generator to verify that the address lines increment correctly can not hurt.
 
Last edited:
The 8032 has all the CPU Address Lines {AB0..AB15} Buffered by IC's UD13 & UD14 (74LS244) making {BA0..BA15} that go to all IC's
on Sheets 2, 3, 4, 5, 6, 7, 8 & 10.

The 8032 has two types of Data Lines, Buffered and Un-Buffered. {DA0..DA7} are sourced from the CPU and go to UB10 & UB9 making
{BD0..DB7} going to Sheets 8, & 9 and Plug J4 Memory Expansion.

The Un-Buffered Data lines, {D0..D7} go to Sheets 2, 3, 4, 5, & 10 which has the 6545 CRTC and multiple other IC's:

1. Sheet 2 UB16 6520 – IEEE-488 Interface
2. Sheet 3 UB15 6522 – User Port
Sheet 3 UB12 6520 – PIA
3. Sheet 4 ALL ROMS
4. Sheet 5 ALL RAMS
5. Sheet 10 UB13 6545 – CTRC

Any of these IC's could be suspect of causing problems with the Data Lines, or it's also possible the ROM Select lines could be selecting
an incorrect ROM at times. The ROM/EPROM select Logic is on Sheet #1 of the Schematics and is a 4 to 16 Decoder UE12 74154 that goes to
Schematic Sheet #4. That would be a good place to start checking with the 4 to 16 Decoder IC's Logic. That logic is for /SELA, /SELB,
/SELC, /SELD, /SELE, /SELF, /SELS, along with the select x8xx on Sheet #1.

You might consider removing the 6502 CPU, then making a PULLUP Resistor for testing the Address Lines (+5.0 VDC through a 4.7K OHM)
to Probe {AB0..AB15} at the CPU's Socket, one at a time for Stuck Lines, as you pull it HIGH, then also jumper it LOW, and follow those Lines
throughout the Motherboard.

Likewise the Un-Buffered Data Lines could be Probed, one at a time for Stuck Lines, as you pull it HIGH, then also jumper it LOW, and follow
those Lines through Sheets 2, 3, 4, 5, & 10.

Once you locate the problem, it should make sense of what is going on.


Larry
 
dave_m said:
I'll mail you a 50 HZ EDIT ROM burned into a 2532 or a 2716. Use private message to send me a shipping address.
Click to expand...

Thanks for the offer Dave. But I don't think it will be necessary for now. Because the CRTC register addresses are also corrupted I think the ROM is fine and the corruption occurs between the CPU and the CRTC.

So I'm planning on doing this next:

- I've got a VIC20. If I remember correctly it had its CPU socketed too. If it does, I'm going to swap the processors. If both are fine, the VIC should still work and the CBM will still show the same symptoms.

- I've got an Arduino, so I'm thinking about putting it at work, by removing the CPU from the board and trying to initialise the CRTC from the arduino and see if I can get it to generate sync signals and/or check with the logic analyser if it's corrupting the data inputs.

Now... this is where my lack of knowledge about digital electronics at physical level shows up.

* I've read that the arduino can drive TTL circuits just fine by just connecting its outputs to the inputs. Is that right?

* The data lines can be controlled directly like the CPU would.

* RS could be controlled from the AB0 pin in the cpu socket, coming through a 244 buffer.

* R/W could be controlled from the R/W pin of the cpu socket, coming through a 7417 buffer.

* E could be controlled from the phi2 pin of the cpu socket, again coming through a 7417 buffer.

* CS. This could be more complex. Could the arduino safely pull it down despite being connected to the output of a NAND? From diagrams like this

https://upload.wikimedia.org/wikipe...4/TTL_npn_nand.svg/648px-TTL_npn_nand.svg.png

I'd say yes. The opposite, pulling up an output that is low could not be done. Am I wrong? If it's safe, this option is simpler and it will also prevent any other ICs getting enabled (if there is something wrong with the address bus logic) if I start enabling all the address lines that the CPU would.

If it isn't safe, or using the previous approach I don't see any corruption in the data lines, I could go all the way back to AB7 in the cpu socket and physically pull-up/down AB8-11 accordingly to get x8xx and AB12-15 to get /IO (although this one is probably low already).

* Can I pull down/up TTL inputs connecting them directly to GND/Vcc directly? The NOP generator does, so I guess it's safe. Or should I get and use some resistors?
 
You must log in or register to reply here.
Back
Top