Announcement

Collapse

Forum etiquette

Our mission ...

This forum is part of our mission to promote the preservation of vintage computers through education and outreach. (In real life we also run events and have a museum.) We encourage you to join us, participate, share your knowledge, and enjoy.

This forum has been around in this format for over 15 years. These rules and guidelines help us maintain a healthy and active community, and we moderate the forum to keep things on track. Please familiarize yourself with these rules and guidelines.


Remain civil and respectful

There are several hundred people who actively participate here. People come from all different backgrounds and will have different ways of seeing things. You will not agree with everything you read here. Back-and-forth discussions are fine but do not cross the line into rude or disrespectful behavior.

Conduct yourself as you would at any other place where people come together in person to discuss their hobby. If you wouldn't say something to somebody in person, then you probably should not be writing it here.

This should be obvious but, just in case: profanity, threats, slurs against any group (sexual, racial, gender, etc.) will not be tolerated.


Stay close to the original topic being discussed
  • If you are starting a new thread choose a reasonable sub-forum to start your thread. (If you choose incorrectly don't worry, we can fix that.)
  • If you are responding to a thread, stay on topic - the original poster was trying to achieve something. You can always start a new thread instead of potentially "hijacking" an existing thread.



Contribute something meaningful

To put things in engineering terms, we value a high signal to noise ratio. Coming here should not be a waste of time.
  • This is not a chat room. If you are taking less than 30 seconds to make a post then you are probably doing something wrong. A post should be on topic, clear, and contribute something meaningful to the discussion. If people read your posts and feel that their time as been wasted, they will stop reading your posts. Worse yet, they will stop visiting and we'll lose their experience and contributions.
  • Do not bump threads.
  • Do not "necro-post" unless you are following up to a specific person on a specific thread. And even then, that person may have moved on. Just start a new thread for your related topic.
  • Use the Private Message system for posts that are targeted at a specific person.


"PM Sent!" messages (or, how to use the Private Message system)

This forum has a private message feature that we want people to use for messages that are not of general interest to other members.

In short, if you are going to reply to a thread and that reply is targeted to a specific individual and not of interest to anybody else (either now or in the future) then send a private message instead.

Here are some obvious examples of when you should not reply to a thread and use the PM system instead:
  • "PM Sent!": Do not tell the rest of us that you sent a PM ... the forum software will tell the other person that they have a PM waiting.
  • "How much is shipping to ....": This is a very specific and directed question that is not of interest to anybody else.


Why do we have this policy? Sending a "PM Sent!" type message basically wastes everybody else's time by making them having to scroll past a post in a thread that looks to be updated, when the update is not meaningful. And the person you are sending the PM to will be notified by the forum software that they have a message waiting for them. Look up at the top near the right edge where it says 'Notifications' ... if you have a PM waiting, it will tell you there.

Copyright and other legal issues

We are here to discuss vintage computing, so discussing software, books, and other intellectual property that is on-topic is fine. We don't want people using these forums to discuss or enable copyright violations or other things that are against the law; whether you agree with the law or not is irrelevant. Do not use our resources for something that is legally or morally questionable.

Our discussions here generally fall under "fair use." Telling people how to pirate a software title is an example of something that is not allowable here.


Reporting problematic posts

If you see spam, a wildly off-topic post, or something abusive or illegal please report the thread by clicking on the "Report Post" icon. (It looks like an exclamation point in a triangle and it is available under every post.) This send a notification to all of the moderators, so somebody will see it and deal with it.

If you are unsure you may consider sending a private message to a moderator instead.


New user moderation

New users are directly moderated so that we can weed spammers out early. This means that for your first 10 posts you will have some delay before they are seen. We understand this can be disruptive to the flow of conversation and we try to keep up with our new user moderation duties to avoid undue inconvenience. Please do not make duplicate posts, extra posts to bump your post count, or ask the moderators to expedite this process; 10 moderated posts will go by quickly.

New users also have a smaller personal message inbox limit and are rate limited when sending PMs to other users.


Other suggestions
  • Use Google, books, or other definitive sources. There is a lot of information out there.
  • Don't make people guess at what you are trying to say; we are not mind readers. Be clear and concise.
  • Spelling and grammar are not rated, but they do make a post easier to read.
See more
See less

Repairing CBM 2040 floppy drive

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Repairing CBM 2040 floppy drive

    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

    #2
    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.

    Comment


      #3
      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


      Originally posted by iz8dwf View Post
      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.

      Comment


        #4
        Originally posted by grbrady View Post
        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

        Comment


          #5
          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:

          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!



          With kind regards / met vriendelijke groet, Ruud Baltissen

          www.baltissen.org

          Comment


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


            Originally posted by Ruud View Post
            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!

            Comment


              #7
              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

              Originally posted by iz8dwf View Post
              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

              Comment


                #8
                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

                Comment


                  #9
                  Originally posted by grbrady View Post
                  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

                  Comment


                    #10
                    Originally posted by grbrady View Post
                    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/c...040/index.html

                    With kind regards / met vriendelijke groet, Ruud Baltissen

                    www.baltissen.org

                    Comment


                      #11
                      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.

                      Comment


                        #12
                        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.
                        With kind regards / met vriendelijke groet, Ruud Baltissen

                        www.baltissen.org

                        Comment


                          #13
                          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.

                          Comment


                            #14
                            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

                            Comment


                              #15
                              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
                              Code:
                              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

                              Comment

                              Working...
                              X