Repairing CBM 2040 floppy drive

[grbrady]

I have a CBM 2040 drive that I'm trying to repair. I've made a little progress but am now stuck.

The logic board came with DOS 2 ROMS (901468-12 in L1, 901468-11 in J1, 901468-13 in H1 and a 6530-034 RRIOT in K3.) When I first got the drive all the lights would illuminate and not go off and one or the other spindle motors would run. No blink codes. I pulled the three ROMs in L1, J1, and H1 and read them in my programmer and they all seemed bad, although the failure mode gave me pause, the second 2K was all FF while the first 2K was what was expected. I burned 2532s and replaced them and was able to get a single blink out of them which indicates a failure of zero page in the two 6532 RIOTs. I swapped those and got 5 blinks, which indicates a problem with the 6530 or 6504. I tried some new 6504s of questionable provenance and also a 6502 with a socket adapter I made and got a similar result. I also built a 6530 replacement board using a 6532 and the design and Eagle files from Ruud's web page here: http://www.baltissen.org/newhtm/6530repl.htm. For the ROM I used a 2716 with the 901466-04 image from Zimmer's burned into it twice. Still the same 5 blinks behavior. Doing some probing, the 6504 comes out of reset and runs for about maybe a second and then crashes. I hooked up the logic analyzer to the data bus and looked for the value for the reset vector from the 6530 to come up and did not see it. However, if I prevent the 6502 from running by pulling it or its ROMs I do see the correct reset vector address come up on the data bus and the 6504 runs more or less indefinitely (no blink codes here because the 6502 is disabled.) There seems to be a bus conflict on the data bus that is killing the 6504 right out of reset.

Next, I read that another common cause for the 5 blinks problem is bad 2114 SRAMs, particularly in C4 and C5. I desoldered all of the 2114s and tested them using an Arduino and the method and code here: https://github.com/Danjovic/2114-Tester. I did indeed find two bad chips and they were the ones from C4 and C5 (also found a few bad ones in my stock of 2114s.) I put in sockets and repopulated the board with tested SRAMs. I still get the 5 blinks. I then considered that maybe the 74LS157 multiplexers at C3, D3, E3 and F4 could cause a bus conflict, although they looked ok when I probed them with the scope. I desoldered and socketed them and tested them with a TL866-II and they all test ok, and I also tried new ones in the board and still get the 5 blinks. I also pulled the 6522 it seems to work perfectly in my PET. On occasion when I'm running the machine without the main 6502 running one of the stepping motors will randomly turn a few steps, so it seems like something happens occasionally with the 6522 and 6504. I also tested the main 6502 in my PET with success. So now I'm stuck. With the exception of some ancillary logic, I've tested or swapped pretty much all of the parts on the data bus and address buses. Superficially all of the signal goings to the other logic look sensible, so I'm not sure where I should look next. The 5V and 12 V rails all look good and don't have much ripple.

Any thoughts on what to try next to debug this? Anything common that I should look at?

Greg

 

[iz8dwf]

You can't replace the ROMs in the 2040/3040/4040 CBM drives with any regular EPROM withouth active adapters.
The mask ROMs have two opposite polarity chip selects that are used to allow two CPUs access a common data bus during the two opposite clock phases.
It is also tricky to read the original ROMs in an eprom programmer, it needs to drive the pin 21 with the correct enable signal.
HTH
Frank

PS: the blink codes are at best a poor hint when troubleshooting these drives.

 

[grbrady]

Huh, well that's not quite as easy as I had hoped.

If I want to dump my old ROMs properly should just bend pin 21 out of the programmer socket and tie it low?

I'm also interested in building an active adapter like you suggest. To read the ROM from the 6502, I think CS2 = 0 and CS1 doesn't matter. To read from the 6504 CS2 = 1 and CS2 = 0. Does that seem correct? If so, then the enable would just be /E = CS2 AND CS1. In other words, feed pins 20 and 21 to the inputs of a 74LS08, and feed the output to pin 20 on the 2532 ROM.

Thanks for pointing this out to me. When I saw 2332 in the schematic I figured it would be as simple as replacing the ROMs in my PET was.

Greg

You can't replace the ROMs in the 2040/3040/4040 CBM drives with any regular EPROM withouth active adapters.
The mask ROMs have two opposite polarity chip selects that are used to allow two CPUs access a common data bus during the two opposite clock phases.
It is also tricky to read the original ROMs in an eprom programmer, it needs to drive the pin 21 with the correct enable signal.
HTH
Frank

PS: the blink codes are at best a poor hint when troubleshooting these drives.

 

[iz8dwf]

Huh, well that's not quite as easy as I had hoped.

If I want to dump my old ROMs properly should just bend pin 21 out of the programmer socket and tie it low?

I'm also interested in building an active adapter like you suggest. To read the ROM from the 6502, I think CS2 = 0 and CS1 doesn't matter. To read from the 6504 CS2 = 1 and CS2 = 0. Does that seem correct? If so, then the enable would just be /E = CS2 AND CS1. In other words, feed pins 20 and 21 to the inputs of a 74LS08, and feed the output to pin 20 on the 2532 ROM.

Thanks for pointing this out to me. When I saw 2332 in the schematic I figured it would be as simple as replacing the ROMs in my PET was.

Greg

In these drives, the mask ROMs have /CS1 on pin 20, active low and CS2 at pin 21 active high. This is the same select configuration used in 2001N and Universal PETs, except that on 2001N boards, the CS2 pin is tied permanently high, so a 2532 EPROM will behave correctly.
On Universal PET boards (CRTC PETs) the CS2 line is brought to the 6502 socket on an unused pin and labeled as /NOROM. This is useful to allow add-on daughter boards to disable all onboard ROMs if needed.
Back on the drives, both CS pins are needed for proper operations. And pin 21 must be high (5V level) for the ROM to be enabled.
The ROM is active when BOTH select pins are in the correct state, so 20 = low AND 21 = high. This is needed on these drives because both CPU share the same data bus.
One select pin is used for address decoding and the other is used for "phase decoding".
I have made adapters for these ROMs many years ago, but using all SMD parts (28C64 EEPROMs and small SMD gates).
I should also have a few original ROMs for these drives, but I don't remember right now what DOS version they are for.

Frank

 

[Ruud]

First: nice to see that someone uses my ideas

Second: I have no idea what could cause the 6504 not to run with the 6502 and ROMs in place. So I skip that for the moment.

The ROMs mean the 2040 has been upgraded to a 4040 drive. That is so fat so good as I have no good info on the 2040 except the schematics. But I'm not that good with the 4040 either, I am more or less specialized in the 8050/8250. You having the 11/12/13 version is good because it seems I have a PDF of the source listing. If interested, email me.

About the 5 blinks: if it was a 8x50, the two 2114RAMs C4/C5 could be blamed. OK, you said you replaced and tested them. To make a long story short: the access time of a device can increase in time due to age. How I ran into this phenomena is the long story. In my case an EPROM that ran fine with 1 MHz didn't one day but ran fine on 500 KHz. A C64 with an EPROMer would test this EPROM at equivalent of about 50 KHz and it would appear fine. An Arduino runs at 16 MHz so IMHO it can test the 2114 near the equivalent of 1 MHz. But this is still something to keep in the back of your head.

In the 8x50 a value is written to C4/C5 at $0400 by the 6502 of the floppy controller and read by the 6502 of the bus controller at $1000. If a wrong value is read, the LED is blinked five times. So a bad C4/C5 can cause the error as well.
But looking for the same routine in the 404 I ran into an interesting piece of code:

lda D_1000 ; read ID of the controller
ldx #$00
cmp #$0F ; is it a 2040?
beq A_D47F ; yes, ->

ldx #$07
cmp #$64 ; is it a 3040 or 4040?
beq A_D47F ; yes, ->

inc JTemp
jmp J_D304 ; blink LED [D304]

I have no idea where the numbers $0F and $64 come from, I assume from the ROM of the 6530, but what if it is the wrong 6530? Hmm, could you try the 901466-06? IMHO that is the correct "6530" ROM for the 11/12/13 set.

Good luck!

 

[grbrady]

Sure, I can try that, but I can't find 901466-06 anywhere. Could you confirm if that's the right number?

First: nice to see that someone uses my ideas

I have no idea where the numbers $0F and $64 come from, I assume from the ROM of the 6530, but what if it is the wrong 6530? Hmm, could you try the 901466-06? IMHO that is the correct "6530" ROM for the 11/12/13 set.

Good luck!

 

[grbrady]

Ok, so I think need to implement NOT(CS2) AND CS1 to give to the enable on the EPROM, I guess using a NAND or NOR chip. Using (more) modern parts seems like a good approach. Do you have any board files for what you built that you are willing to share? If not, that seems like a PCB layout project that would be within my skills.

Thanks,
Greg

Back on the drives, both CS pins are needed for proper operations. And pin 21 must be high (5V level) for the ROM to be enabled.
The ROM is active when BOTH select pins are in the correct state, so 20 = low AND 21 = high. This is needed on these drives because both CPU share the same data bus.
One select pin is used for address decoding and the other is used for "phase decoding".
I have made adapters for these ROMs many years ago, but using all SMD parts (28C64 EEPROMs and small SMD gates).
I should also have a few original ROMs for these drives, but I don't remember right now what DOS version they are for.

Frank

 

[grbrady]

Ok, I successfully dumped the three original 901468-11, 12 and 13 ROMs using my programmer with pin 21 bent out and tied high. The binary data on them agrees with the images that are on zimmers.net, so it seems like they're actually ok and not part of the problem. So, it's not critical that I put together replacements at this time (unless there's another fault with the ROMs that this method might not find.)

Greg

 

[iz8dwf]

Ok, I successfully dumped the three original 901468-11, 12 and 13 ROMs using my programmer with pin 21 bent out and tied high. The binary data on them agrees with the images that are on zimmers.net, so it seems like they're actually ok and not part of the problem. So, it's not critical that I put together replacements at this time (unless there's another fault with the ROMs that this method might not find.)

Greg

Good!
Anyway, since EPROMs need an active low CS, you would need something like /CS1 OR (NOT CS2) as a global select. Or if using a chip with both /OE and /CE like I did, you can simply feed /CS1 to /CE and NOT CS2 to /OE.
My files are available of course if you need them, it's a quite "universal" replacement, so it has lots of jumperable options depending on what you replace.
I think however you aren't going to need the adapters as the ROMs are just fine as I suspected from the beginning
The other possible fault you need to check on the original ROMs is that they go to high impedance if you tie pin 21 low. It's not a very common failure mode, but I've seen that happening a few times.
HTH
Frank

 

[Ruud]

Sure, I can try that, but I can't find 901466-06 anywhere. Could you confirm if that's the right number?

http://www.zimmers.net/anonftp/pub/cbm/firmware/drives/old/4040/index.html

 

[grbrady]

http://www.zimmers.net/anonftp/pub/cbm/firmware/drives/old/4040/index.html

That's where I was looking. There's 901466-01.bin, 901466-02.bin and 901466-04.bin but no 901466-06.bin. I'm currently working with 901466-04.bin on a 2716 EPROM.

 

[Ruud]

You are right, I was wrong. Something wrong in my own notes. 901466-04.bin is the correct one. Then I am out of ideas as well, sorry.

 

[Kakemoms]

I have two 8050 and one 2040 thats not working. I got one 8050 running for a short while through more or less the same problems you describe in the first post.
The main problem seems to be low voltages and poor driving. The layout of the board is quite horrendous and many og the lines are extremely long. I managed to help with this using a few extra caps, but its almost like you need to swap out all the ICs to get the thing working well again. I guess 40 years didn’t do these boards any good.

 

[daver2]

Also, 2114 devices come in multiple different access time ratings. If you have used too slow devices by mistake - then even though they work in a tester - they may not actually work in the application. Check the full part number of the original devices (to get the maximum access time for that device) and replace it with the same (or faster) part.

Dave

 

[grbrady]

I've made some good progress getting the 2040 up and running. Indeed the issue I was having had to do with the 2114 SRAMs. I took some more time and tested them carefully in my other machines and found a few issues. Now with all good memory the microprocessors seem to boot up. The LEDs turn on and then off again, the spindle motors spin and the heads seek to track zero in both mechanisms. I'm pretty happy about that. The only parts I had to replace are a couple of the SRAMs and one 6532. I cleaned the dust out of the mechanisms and lubricated the spindles, cleaned the heads and checked the spindle speed and all appears to be good there.

My PET seems to be able to talk to the drive over IEEE488, at least at some level. If I run this program

10 OPEN 15,8,15
20 INPUT #15,E,E$,T,S
30 PRINT E,E4,T,S
40 CLOSE 15

I get the desired DOS V2 response.

If I then try to load a directory using LOAD"$0",8 (I have BASIC 2.0 right now) with what should be a good floppy, the appropriate drive spins and I get a "LOADING" message on the screen. Then the drive stops spinning and the computer hangs at "LOADING" until I hit run/stop. The LED on the drive doesn't illuminate. Reading the output of the command channel as above gives a READ ERROR.as output. I get similar behavior if I initialize the disk (OPEN 15,8,15,"I0") before doing the load command, although I believe I shouldn't need to do this because I have DOS 2 ROMs in the 2040.

I haven't done any hardware troubleshooting on this read problem yet, other than checking the continuity on the heads. There is continuity between all of the 4 pins on the all of the heads, i.e. pin 1 seems to connect to 2,3 and 4. I'm not sure if that's normal, I was kind of expecting continuity between two pairs of pins.

Since I'm new to the PET drives, can anyone suggest a particular approach to diagnose this read error problem? Are there any further tests I should do with the PET? Should I just follow the signals from the heads back through the analog board and see if there are signals that look like data? Are there any common faults that might cause this?

Thanks,
Greg

 

[iz8dwf]

Let's understand what "basic 2" (not everyone agrees): is it the *** or the ### one?
Did you try the drive 1?
And yes, head's coils have one pin in common, the read/write coils have a center tap and the erase coil is single-ended but one end is connected to the r/w center tap too.

Frank

 

[grbrady]

Let's understand what "basic 2" (not everyone agrees): is it the *** or the ### one?

It's the ### one and what the machine had when I got it. I've been thinking about burning some BASIC 4 ROMs as well, but haven't gotten around to it. Do you think that's worthwhile?

Did you try the drive 1?

I did and got the same behavior. I should have mentioned that.

And yes, head's coils have one pin in common, the read/write coils have a center tap and the erase coil is single-ended but one end is connected to the r/w center tap too.

Thanks for the confirmation. After I posted I revisited the schematics and that's what I concluded.

Thanks again for any ideas as to what to try next,
Greg

 

[iz8dwf]

Ok, that basic works fine with the IEEE drives, I have it too on one PET and I don't even plan to upgrade it (I can run all versions of Basic on another PET if I need to).
So the issue points again to the digital PCB (likely) but at this point I can't suggest much tests that don't require an oscilloscope. Did you read the "GCR" ROM and confirm it's good?
Frank

 

[grbrady]

... I can't suggest much tests that don't require an oscilloscope.

I have a scope so please suggest away. I also have a cheap 16 channel logic analyzer and a logic probe if those are helpful.

Did you read the "GCR" ROM and confirm it's good?

I'm not sure if it's good or not. I tried reading it in my programmer as a 2716, but initially I got all FFs. I realized that this was probably because the chip select lines weren't being handled properly. I bent pins 18, 20 and 21 out of the socket and jumpered them to ground and was able to get some data out of it. However it doesn't agree with the bin file here: http://www.zimmers.net/anonftp/pub/c.../901467-01.bin. The first 1K are the same, but the second 1K disagree and it looks like they are a repeat of the first 1K. I don't know if that's a fault or a problem with how I'm reading it. I also burned a 2716 with the image from zimmers.net and tried that, but it didn't change anything. I realized that there might be a problem with the chip select lines/Vpp. It looks like 18 and 20 are tied low as desired, but so is 21 which could be a problem for a 2716. So, I bent 21 out of the socket and jumpered it to 5V. This also didn't change any behavior. Again, I'm not sure if I that was the correct thing to do.

Cheers,
Greg

 

[iz8dwf]

To read the "GCR ROM" as a 2716, just lift pin 21 and connect it to pin 20 on your programmer socket.
The content must match otherwise it's best to substitute it with a good copy. A 2716 can be used, you need to lift pin 21 of the 2716 and connect it to Vcc, so you seem to have excluded the GCR issue already.
First checks with the scope should be on testpoints TP1 and TP2 of the analog board (outputs of the LM592 amplifier). Best if done with two probes on a common trigger.
Frank