Repairing a Commodore 8050 dual disk drive

[kakemoms]

I have started on the task of repairing my 8050 dual diskdrive. The unit was flashing the front lamp around 4 times which apparently is not used. So I recon it either flashed it 3 times or 5 times (it goes between red and green with a long green light, so I am not sure if its the red or green state that is "flashing on"). Anyway I replaced Both HIGH/LOW ROM which resulted in a long red light. Then replaced both 6502s with no change. So I replaced the UK6 ROM as well (a 2K 2316 which I replaced with a 2564 filled with 4 copies). The pin layout is compatible if you don't use pin 1,2 and 27,28.
Next step was to do some logic testing and there is clk2 on both 6502, and their data&address buses are actively running. Strange! It mostly looks like the unit is booting as normal, but there is no led flash codes. So at some stage it stops, or the circuit controlling the led is not working? Hopefully its not the RIOT which is a pain to get replaced (which is the only way I can think of actually testing if its not working). I have a broken 2040, but I doubt the 6530 in that have the same ROM.

Ideas anyone?

[BigEd]

I don't know about the specifics of the drive, but on general principles:
Are you sure you don't need to tie off the unwanted inputs? Putting four copies of the data means you don't care about the logic levels of the unused address inputs, but I'm not sure you can just leave things floating.
I checked the datasheet and the part looks like it's NMOS - unlike TTL, you don't get a free pullup.
http://www.jrok.com/datasheet/TMS2564.pdf

[kakemoms]

BigEd wrote:

I don't know about the specifics of the drive, but on general principles:
Are you sure you don't need to tie off the unwanted inputs? Putting four copies of the data means you don't care about the logic levels of the unused address inputs, but I'm not sure you can just leave things floating.
I checked the datasheet and the part looks like it's NMOS - unlike TTL, you don't get a free pullup.
http://www.jrok.com/datasheet/TMS2564.pdf

I made a socket adapter to test the pulldown of -CS1 and -CS2, but it didn´t help. I will do more ROM testing tonight, then see if there are problems with the 6522.

[KC9UDX]

I don't know if this is helpful at this point, but as far as I can tell, is the red "flashes" that count.

[kakemoms]

KC9UDX wrote:

I don't know if this is helpful at this point, but as far as I can tell, is the red "flashes" that count.

Ok. I think I counted 4 greens between the long green, so that means 5 red flashes.

I can also confirm that the DOS 2.5 ROM were fried when I finally managed to read them properly. First time I tried I set my BP CP-1128 to read "Texas Instruments TMS 2564" which is what I use as replacements. To be sure I was doing the right thing, I found my Vic-20 with socketed Kernal and read that ROM. As a TMS2564 it showed up as 8KB of $FF, so that meant I was not doing it right.. But then I remembered that I also had some MCM68764 which is fully pin compatible, so I set the device as "Motorola MC68764". The data then showed up correctly and I was able to burn a new 2564 with the read data, put it in my loose socket (with a pull-up resistor on pin 2 and 27) and restarted the Vic-20 and got the normal startup screen. Victory!

I then re-read the original roms from the 8050. Both the 901482-06 (plastic package) and 901482-07 (ceramic package) only showed $FF as their data (over the full 8KB range), but the 901467 (which is a 2K ROM) showed up correctly. Since I was reading it as a MC68764, I had to fill the last 6KB with $FF to verify that the data was the same as 901467-01.bin that can be found on the net (that file only fills the first 2KB with data, the rest is then assumed as 0 and not $FF... until I filled it in that is).

After that I made another socket-adapter with the same pull-up on pin 2 and 27, and put both 2564 with 901482-06 and 901482-07 into the 8050.

So now I know that all the ROMS are fixed and working. I still only get a constant red LED (no green flashing), so even if the original 5 flashes were correct about the ROM, there is another problem lurking somewhere. I am hoping its not the 6530, but knowing better I have already ordered 3pcs 6532 so that I can make a adapter-replacement for that (http://www.baltissen.org/newhtm/6530repl.htm).

Still, it might be other things, but since the flashing isn't starting (not even a green LED for a fraction of a second), my guess is that nothing is really running on the 65c02. While the logic analyzer shows data, a malfunctioning 6530 would probably mess that up. At least that is my guess.

I will go over some socket solders now, just to be sure..

Edit: Ah, I know I wrote pullup, but I actually used a pulldown. The -CS needs to be low for the 2564 to be active. I also saw some rather questionable soldering on the backside of the mainboard. E.g. at some point an engineer has replaced a few ICs (a 74LS157N has been replaced with a 74LS157PC, the LF353N is socketed, a SN74LS164N ++). I didn't have them all, but I rather replace these once more (and socket them!) to see if it fixes things than going more into the depth of the HW. Wonder what caused the originals to fail in the first place.

[kakemoms]

This must be the most broken 8050 ever. I have had to replace:

Two DOS 2.5 ROMS (put in 2564 as replacement)
Two 6502 - with one old MOS 6502 from a Vic-20, and one slightly modified WDC 65C02
LF353N
SN74N157
SN74N164

After reheating the solder on all sockets (ROM, 6502, 6532, 6530) I got the green light back, but only for a short while. It started blinking but only 1 blink. The service manual says it's the 6532 (one or both), so I replaced them with two 6532 from Atari components (CO10750 - 03 RIOT).

Now the disk drive gets to the point were it accesses the drive, but the LED goes back to red and no blinking. It means that the CPU has frozen up at some point.

To understand whats going on, I went into the DOS 2.1 code that can be found. It is simple to follow and one can see that the diagnostics routine is filling $0000-$00FF addresses, then increasing them and reading the location. If that fails at some point, it ends with the "one-blink mode". So this can also be due to bad memory (or possibly 6530) which will be my next thing to replace (I have some MM2114N coming from ebay).

The strange thing is that the 5 blinks also pointed towards zeropage (thats were I started), but towards 6530 and 6502. The code is a little confusing at that point:

Code: Select all

(from another file:
BUFS = $1100 ; START OF DATA BUFS
)

 		CPX #$D0 ;DONE ALL THREE ? (previous diagnostic routine)
 		BNE RM10 ;NO -> X=$D0 here
RCON1
 		LDA TABJMP,Y ;TRANSFER JMP TO WAIT LOOP
 		STA BUFS,Y
 		INY
 		BNE RCON1
 		LDA #JUMPC
 		STA JOBS ;SEND CONTRLR AWAY
 		INC TEMP ;ERROR # 5
CDELAY
 		INY
 		BNE CDELAY
 		LDA JOBS
 		BEQ CR20	; Exit loop
 		DEX
 		BMI CDELAY
 		BNE PERR2

If anyone here has an idea of what this does I would like to know. My guess is something about the 6530 or starting the second 6502?

Edit: I found the link to BUFS which suggests that this is some kind of buffer that is shared between the two 6502? "TABJMP" is a pointer to the start of the diagnostics routine, suggesting that the routine itself is copied into the buffer. The lower part of the code above is a simple delay, so my guess is that "STA JOBS" starts the other 6502 (I need to look further into this). "JOBS" is defined as $1003+15 and commented as "JOB QUE". "JUMPC" is defined as $D0 under a section thats described as "Controller Job types". The error code itself (in this section) suggests that "Controller" either means the 6530, the other 6502 or a combination of both.

Any further suggestions are welcome..

[BigEd]

With so many damaged chips, perhaps the unit suffered from some serious overvoltage - maybe a lightning strike or power supply failure?

As the code is storing a value to JOBS and then waiting for the value to change, it must be a location in shared memory which the other CPU is expected to modify - and it isn't modifying it before the countdown expires.

[ttlworks]

BigEd wrote:

With so many damaged chips, perhaps the unit suffered from some serious overvoltage - maybe a lightning strike or power supply failure?

To me, it also looks like it was caused by a lightning strike or a power supply failure.

Would suggest to check the +5V with an oscilloscope, and maybe to add something
like an overvoltage protection diode to the +5V supply...
...to prevent the new chips from getting "damaged by accident", too.

Sorry to say this: Maybe it would be less fuss to just replace _all_ of the chips on the PCB.
Background is, that if it was caused by a lightning strike, old chips that might appear to be working now
suddenly might stop working at some point...

BTW: I think it would be a good idea to mark the old chips with a drop of red nail polish or such,
just to be sure you won't be plugging some of them into any PCBs in a few years from now by accident.

[kakemoms]

Oh well, I haven't actually tested ALL the chips I took out, but when there were pairs, I just changed both (at least the parts with sockets). I will go through them and try to see if they work in some other machine (just to be sure). Since I re-soldered all the sockets, there was a problem with at least one of them. I have seen this before: old tin seems to form micro-cracks that give poor or no connection. Reflowing the solder (with some new) fixes the crack and things start working again.

All the AC lines from the transformer were ok, but its a good point to check the 5V more thoroughly. My Picoscope isn't working very well, but I can borrow an old 10MHz scope from a friend and test.

I'll keep you updated!

[dwight]

You might want to look into some of the methodology I'm using to
trouble shoot my KIM-1.
Easter egg hunting is a poor way to troubleshoot a uP.
You may even have more than a single part failing.
Unsoldering everything can be a second source of problems.
It is much better to unsolder the failing part only.
Dwight

[kakemoms]

Oh well, a short update:

I was waiting for some new caps, but they never arrived so I just ordered them again. Basically the 220uF and 10uF caps were not behaving so I wanted them replaced (since the 6502 seems to run for a while and stop, but at different points). I will also change all the 1uF and the 47uF caps once I'm at it.

Two 2114 RAM chips has been changed since my first error code was about zero page, and it keeps coming up. I also had a peek at the 0.1uF caps around that area and to my surprise found that the C42 cap was floating (there is no trace on the +5V side of that). I made a small correcting to a nearby chip.. not that it matters.

So when I get my new caps I have hope for the thing to start running smoother. If not, the 6530 is the next on the list.. once I can build a replacement of that custom chip (with ROM)..

You may ask why I haven't put the thing into the nearest bin, but this is quite interesting so I will keep to try to get it working.

[NivagSwerdna]

kakemoms wrote:

I can also confirm that the DOS 2.5 ROM were fried when I finally managed to read them properly...
After that I made another socket-adapter with the same pull-up on pin 2 and 27, and put both 2564 with 901482-06 and 901482-07 into the 8050...

I know this is an old thread but I would like to share an observation... I recently read the 901482-06 and 901482-07 ROMs on my 8050... and they don't match the binaries on http://www.zimmers.net/anonftp/pub/cbm/ ... index.html ! It seems the .bins are swapped?

[Dr Jefyll]

Welcome, NivagSwerdna, and thanks for posting. I can't confirm the binaries are switched, but mistakes do happen.

It seems to me you'd do better to direct your correspondence to Bo Zimmerman, the fellow who hosts the site. To contact him, look near the bottom of his home page here: http://www.zimmers.net/

cheers,
Jeff

[NivagSwerdna]

Dr Jefyll wrote:

It seems to me you'd do better to direct your correspondence to Bo Zimmerman, the fellow who hosts the site. To contact him, look near the bottom of his home page here: http://www.zimmers.net/

I have done that now and we have reviewed the .bins

Thanks

[kakemoms]

Oh, interesting!

I eventually disassembled the ROM code to understand more clearly what was going on with the flashes. For all the earlier CBM drives (2040/3040/4040), the flash codes are correct, but the 8050 behaves differently due to some very poor change in the code. In fact the error table (vs numer of flashes) is incorrect for the 8050 (if you look in the service manual).

I did get the drive up and running, but it died again quite quickly. The number of DIPs you have to desolder to get anywere is quite alot. Then one has to ensure that all the components work as intended before re-plugging them back into the 8050. Its a tedious job.

Maybe I will give the 8050 another try. I have two units, but none of them work at the moment.