• Please review our updated Terms and Rules here

CBM 3040 Dual disk drive issues

C

commdoroughSxtyforugh

Member
Joined
May 19, 2025
Messages
31
Hi to all, after having finally resolved the problem with the 3032 PET, I am now trying to make it work with a 3040 Dual Drive. On the PET there is BASIC 3.0 (### on screen), so I tried to use the following commands:
OPEN 1,8,15:INPUT#1,E,E$,T,S:PRINT E,E$,T,S:CLOSE 1
This was giving the correct output in the beginning (DOS 2.0, Ok..) while now it gives random characters and only if I replace "INPUT#1,E,E$,T,S" with "INPUT#1,E$", otherwise all I get is a FILE DATA ERROR.
Formatting with OPEN 1,8,15:PRINT#1,"N0:TEST,01": CLOSE 1 seems to work fine (I can see the head moving from the external track to the central one) and the command ends without any error and the LED on the drive turns off at the end of the task.
Trying to load the directory with LOAD"$",8 or LOAD"$1",8 both get stuck and the status led turns on.

I then connected the 3040 to a ZoomFloppy interface and it seems to be recognized by it (in the device list, after I set the translation to "PETSCII UPPERCASE"). FORMAT seems to work as with the real PET, INITIALIZE seems to do something, but when I try to send a STATUS each time it shows me a string of unreadable characters and they changes each time.
DIRECTORY command fails, and obiovsly copying anything isn't possible (I'm using CBM-Transfer 2.0 GUI for CBM Control 0.4.99).

On the 3032 PET I have Disk-O-Pro ROM at $9000 and I tried some commands like DIRECTORY and it shows some garbage on the screen with a DISK:29 as last line...

Does anybody has any idea?
Best regards
 

Attachments

  • 8889f820-ed5c-4a7a-a8dc-2c5a7cf328e6.jpg
    8889f820-ed5c-4a7a-a8dc-2c5a7cf328e6.jpg
    251.4 KB · Views: 7
  • 49406597-2cec-438a-8f37-d4835caa59c1.jpg
    49406597-2cec-438a-8f37-d4835caa59c1.jpg
    205.3 KB · Views: 7
  • f341bc00-a3f2-4152-b496-bb734e0467f4.jpg
    f341bc00-a3f2-4152-b496-bb734e0467f4.jpg
    221.3 KB · Views: 7
Sorry Dave, forgot to mention it! Yes, I checked the IEEE488 port with the program listed in one of the threads about PET Drives and it seems to work.
 
Just checking...

So we know it is the cable or drive then.

You have the same buffers on the IEEE488 bus at both ends (the PET and drive), so I would start with those.

Dave
 
daver2 said:
Just checking...

So we know it is the cable or drive then.

You have the same buffers on the IEEE488 bus at both ends (the PET and drive), so I would start with those.

Dave
Click to expand...
Today I'll try to check the buffers.
I haven't explained that the IEEE cable that I used between PET and 3040 is not the same that I used between Zoomfloppy and 3040, because I had to solder directly to the Zoomfloppy board.
This thing makes me think that the cables are not the problem, I double checked the continuity of both and also the correct pinout.
I've read a similar problem in another thread that was solved substituting some transistors (Q1-Q8) but I checked the voltage on Q1-Q2-Q5-Q6 and there is about 11.48v, Q3-Q4-Q7-Q8 are at about 0.45V. Is this correct?
Thanks for all your help!
 
I'm referring to the 8 transistors on the analog board named Q1-Q8 on the schematic in attachment. I saw in another thread to check the base voltages for a similar issue.
 

Attachments

  • Appunti01.jpg
    Appunti01.jpg
    164.4 KB · Views: 5
Got you.

However, you have to measure the voltages on all of the three (3) pins of each transistor to understand whether it is working or not...

There is a +12V power supply feeding the emitters of Q1, Q2, Q5 and Q6. 0V is feeding the other transistors of the bridge (Q3, Q4, Q7 and Q8).

You need the voltages on the bases of each of the transistors to ascertain whether they should be conducting or not, and (by inference) what voltages should be measured on their collectors.

These transistors should only affect the operation of the head stepping - not the operation of the IEEE488 interface either.

Dave
 
Heads stepping seems to work correctly, when I tried to format a Disk, the head start from the external track and then step-by-step reach the inner one, then at the end of the sequence, it returns at the original track.
I see on the schematic 3 mc3446 buffers, but I'm not aware how to test them.
I have a logic analyzer which I can use to test them.
 
Last edited:
If the head steps, the transistors (and the controlling logic) are all fine...

Are UC1 and UE1 (6532 devices) in IC sockets by any chance?

Dave
 
Yes, that's what I tought, even from my low know-how...

Both 6532 chips are in sockets! I swapped them several times and what I got are several different behaviours: sometimes all LEDs stays always on, sometimes commands will be executed but status led turns on at the end of the command (IE: initialization). This leads me to faulty sockets. I'll change them as soon as possible and then I'll post the results of next tests.
 
Stop, stop, stop!

Your logic is suspect!

Our 'plan' is to work in a logical manner rather than jumping from one thing to another.

You should only replace something if we have some EVIDENCE that it is faulty.

My question regarding being in a socket is that these two ICs have the large majority of the IEEE488 signals wired to them.

The IEEE488 buffers are known to be a weak spot, hence the need to test them...

Dave
 
I am confused.

Why are we waiting for the PETTESTER ROM when we are trying to fix a 3040 disk drive?

The PETTESTER ROM is for testing the PET, not the IEEE488 bus or 3040 disk drive.

Assuming I have used the correct schematic, The IEEE488 buffers (MC3446 UB1 and UB2) are connected internally to the 6532 at UC1.

By removing the 6532 at UC1, we have internal access to the disk drive end of the MC3446 data buffers. The PET has access to the IEEE488 end of the bus buffers.

Does this make sense to you before we start digging into the details?

Can you also lookup the data sheet for the MC3446 (https://www.darisus.de/Elektonikshop/Datenblaetter/TI/MC3446.pdf) and see if you can understand how it works.

There are four (4) internal buffers. They are all the same - so we only need to understand how one of them works... I would suggest looking at the fourth channel (pins 12, 13, 14 and 15).

The 'B' (pin 14) is the IEEE488 bus pin itself.

The 'R' (pin 15) is the receive pin.

The 'D' (pin 13) is the transmitter pin.

The 'S' (pin 12) enables the transmitter.

With the 'S' (pin 12) LOW, the buffer is transmitting from D to B.

The receive pin (R) reads back what is on the bus (B).

With the 'S' (pin 12) HIGH, the buffer is receiving from B to R.

What we have to do is to drive the D pin (to transmit a signal), read it back on the R pin, and monitor the B pin using the PET.

However, we need to enable the buffer's transmitter. This is connected to the /ATN signal that is the inverse of the ATN signal from the PET. We can use the PET to drive the ATN pin HIGH, which will pull the 'S' pins of the MC3446 data buffers LOW, thus enabling the transmit buffers.

That is a 'helicopter' view of what we need to do. Is this understandable before I start giving you detailed instructions?

Dave
 
Last edited:
Two tangents:

are there any diagnostic/test ROM for the drives?

It would probably be handy to have a ROMulator or similar, with the adapter to a modern computer, to run any diagnostic/test program.
 
MiaM said:
Two tangents:

are there any diagnostic/test ROM for the drives?

It would probably be handy to have a ROMulator or similar, with the adapter to a modern computer, to run any diagnostic/test program.
Click to expand...

Here.

github.com

GitHub - piersfinlayson/cbm-ieee-disk-diag-rom: 🛠️ A diagnostic ROM for Commodore 2040, 3040, 4040, 8050 and 8250 💾disk drives which use the IEEE-488 interface

🛠️ A diagnostic ROM for Commodore 2040, 3040, 4040, 8050 and 8250 💾disk drives which use the IEEE-488 interface - piersfinlayson/cbm-ieee-disk-diag-rom
github.com github.com

And a video showing it in action here:


I've tried it ony 3040 but I seem to have a fault it does not identify easily.

Colin.
 
I had a further thought this morning whilst driving in to work.

We can test the MC3446 buffers just using the 3040 disk drive alone - and not bother about the PET.

With UC1 removed, and the drive IEEE4888 port disconnected, the MC3446 transmit buffers are enabled (ATN IEEE488 bus pin 11 is pulled HIGH via R5 (2.4K), This HIGH is inverted by UA4 pins 1/2 to a LOW and fed to the 'S' pins of the MC3446 buffers UB1 and UB2. This permanently enables the bus transmitters of UB1 and UB2).

By creating a little probe (consisting of a 1k pull-up resistor to +5V and a switch to 0V/GND) you can use the junction of the resistor and switch as a probe to connect to each DOn pins of UC1 in turn. With the switch open (logic '1') the readback signal into the corresponding DIn pin of UC1 should be logic '1'. With the switch closed (logic '0') the readback signal into the corresponding DIn pin of UC1 should be logic '0'. Repeat for all of the eight (8) data buffers.

The only thing we haven't tried is disabling the transmit half of the MC3446 buffers to ensure they can be disabled. We can do this by applying a piece of wire to the ATN pin on the IEEE488 connector if we need to.

If these are OK, we can have a look at MC3446 buffer UD2 - but this will be more problematic, as a couple of the transmit pins to UD2 are sourced from TTL logic.

I seem to remember writing a previous thread on testing these buffers a year or so ago...

Again, this is me writing my thoughts down. We can go through this slowly if you want to perform these tests.

Dave
 
First of all, thank you very much Dave for your kindness and your help! Me and my friend that are working on this thing on our free time are very grateful for all the info that you gave us for the 3032 and now for the 3040! Obiouvsly a big thank you to all other members that are helping us!! In a few times we learned a LOT of thing from this forum! Guys, you rocks!

I read your posts and I checked how the 3446 works, I think I understood the logic. Please note that I am not an hardware specialist like one of you, so I don't know a lot of things!
I think that we can go step-by-step testing these buffers in next weeks.

I mentioned the PETTESTER because we want to be sure that the 3032 works fine.

I forgot to tell that when I send a command like
OPEN 1,8,15
PRINT#1,"I0"
the drive does something (head rattles and drive 1 led turns on until the end of the job, and then the central LED turns on and stays on...

Do you think is a good idea to put sockets to the three 3446 in order to check them?

Again, thank you for your help and patience!
 
Absolutely no problem. The idea is to improve people's knowledge.

Understand where PETTESTER now fits into the equation...

Your little BASIC program drives the buffers largely in one direction (PET to DRIVE) whereas reading the disk catalogue relies on the buffers working in the other direction (DRIVE to PET).

I wouldn't put the MC3446 devices in sockets. This introduces the possibility of some damage occurring - unless you believe you have the tools and competencies to avoid this. I prefer to test things in-situ (as far as I can) and only replace ICs when I either have some clear evidence that something is faulty, or I have completely run out of ideas...

I will post some 'simple' instructions tomorrow for you (if that is OK). It is too hot here this afternoon!

Dave
 
We have a de-soldering station that works fine and I'm used to work with it (not a professional, but I can do the job without damaging anything, I changed a lot of RAM from a C16, changed 6502, 6522 and 6520 IC sockets on the PET, etc.).
I suggested to put the sockets on the 3446 to swap them and test the UD2 in the same manner of UB1 and UB2.

It's very hot here too, so it's better to go swimming than turn on the soldering tools...
 
You must log in or register to reply here.
Back
Top