• Please review our updated Terms and Rules here

Fat 40

Ah damit.

Brushes now sat on commutator but motor still doesn't always start. Give it a flick and it will run but then after a few goes, it fails to start again.

Windings checked and one pair are shorted :(

Damn, I'm never going to rewind a multipole motor like this so its for the scrap. Time to find a spare drive.
 
So, spare motor fitted and drive now runs and I can format, but as soon as I try to get a directory, it hangs with a drive light on.

I have another drive with these Micropolis drives and swapping the drives and the analogue card over, everything works fine. So the CPU board isn't quite working properly.

It does have a different ROM set but zimmers seem to indicate that thes can go with the pressed steel frame Micropolis drives.

So as I have three spare working boards (well, spare as they are in good drives) I might try some chip swaps.

Lots of chip swaps done and the only one that stopped my good board working was inserting the ROM at UK6

Now putting that back in the faulty board I get a flashing error code. The code appears to be 4 flashes, but thats listed as Unused ?

Is the code read as the number of red flashes ?
 
Last edited:
This is going to turn into a disk drive diagnostic blog, oh well

I think one of the white sockets is defective as the drives diagnostic sometimes reports errors but a firm push on all the sockets usually fixes it, so they will have to all be changed, however

Drive responds to commands but wont write anything back.

Opening the error channel and doing an input shows 0 0 0 rather than 0 OK 0 0

Sending "UI" and reading the error channel, gives the same rather than 73 8050 CBM DOS 2.5 0 0 so it looks as if it isn't sending any data back on the bus.

Scoping the DI and DO lines, I can see DI's pulsing as expected but absolutely nothing on the DO's. All the DO's come from port B of the 6532 at UC1 but I know that cant be it because they have both been swapped with ones from a known good board. All the DO's are high at +5, but I notice that while the DI's pulse +5 to 0, the bus lines are pulsing +3v to 0v which is odd as thats sourced from the PET.

I wonder if the buffers are not switching, but that would mean two and why would the ports not pull down ? Of course the RIOT might not be being addressed but it works for input ok. Odd.

Humm.

Might need to write some diagnostics, Dave ? ;)
 
So what an interesting circuit.

The 6532 I/O ports run the IEEE through MC3446 bi-directional buffers which seems simple and straightforward, however the Not Ready For Data (NRFD) and Not Data Acknowledge (NDAC) aren't just simply run from the ports then through the buffers, but also by some discrete logic driven partially by the Attention signal (ATN) from the PET and the bi-directional buffer is hard wired as input (in which case, any signal on the D line is driven on the B & R lines). This must be because the IEEE-488 standard for response from a listener is to pull NDAC low within 14uS and I suppose the 6532 wasn't fast enough and it looks as if the circuit is an add on to make the initial operation work.

Having swapped the 6532's with a good board and the fact I am seeing no reply to data transfers from the disk but the disk is responding to messages sent to it, I'm assuming the transaction is getting stuck waiting for one of the signal lines to change. Checking NRFD & NDAC I can see that the disks internal RFD output to pin 11 of UD2 should be mirrored on pins 9 & 10 however I am not seeing anything on pin 9 so the MC3446 is suspect.

Hopefully that is stopping the handshaking but without looking at the software its a guess, but it is an actual fault and it is part of the handshake in this operation so its probably it.

MC3446's though are hard to get for a good price.
 
New MC3446 fitted at UD2 and drive now responds correctly :)

One niggle left, drive 1's green light is now permanently on where it did respond before. Need to check the board to see if I have picked up a solder blob but at least its now functional.
 
So edging closer.

With the new buffer chip, the drive responds to all commands and can read a disk but not format, which is strange at is was running the format before just hanging on the completion due to the handshake failure on the GPIB.

Swapped back to the known good digital board and it all works fine so its not the drives or the analogue board.

Now this board has also thrown flashing errors which go away with a bit of chip reseating so I might have some bad sockets (I know all the socketed chips are actually ok as they work fine in the good board). Gave the 6522 a squash in its socket and now its formatting fine.

This board has the white sockets which do seem to cause issues in some PET's and this drive has also suffered some corrosion so I think my next move is to replace the sockets with some good quality dual wipe ones. The drive light was being caused by a bad contact at pin 21 of UE1. Leg of IC cleaned and its working again, but I still think new sockets would be the way to go.

But on the whole its almost there. Quite fun, the 8050 is like a PET on steroids.
 
Last edited:
Does anyone have a simple BASIC program to change the ID of a 8050 disk drive. I don't want to cut a pad or bend a leg but the M-W instruction I just can't seem to get to work.

Anyone ?
 
Never mind

Found one, (I was putting a comma between each character)

However, still cant get CBMCommand to copy between devices

10 REM************************************
11 REM*
12 REM* CHANGE 8050 VER1.0 4/14/80
13 REM*
14 REM* THIS PROGRAM CHANGES THE 8050'S
15 REM* DEVICE NUMBER TO THE NUMBER THAT
16 REM* IS GIVEN BY THE OPERATOR. THIS
17 REM* CAN RANGE FROM 9 TO 15. THIS IS
18 REM* A SOFT CHANGE; THUS A RESET OF
19 REM* THE 8050 WILL CAUSE IT TO RESTORE
20 REM* TO THE HARD DEVICE NUMBER.
21 REM*
22 REM* THIS PROGRAM IS APPLICABLE FOR
23 REM* ANY 8050 OR 2040 WITH DOS 2.X.
24 REM*
25 REM************************************
99 PRINT"♥"
100 INPUT"OLD DEVICE NUMBER";DO
110 IFDO<8 OR DO>15 THEN100
150 INPUT"NEW DEVICE NUMBER";DN
160 IFDN<8 OR DN>15 THEN150
200 OPEN15,DO,15:REM COMMAND CHANNEL
210 PRINT#15,"M-W"CHR$(12)CHR$(00)CHR$(2)CHR$(DN+32)CHR$(DN+64)
220 CLOSE15
230 END
 
Digital board fully functioning.

But the analogue board has a fault. I think its something in the Read/Write enable circuit. Getting nothing at the diff amp U2 during a read even though I know the heads on the drives are fine. As it happens with both drives, need to have a look at the common components.

Noticed that the output from the transistor array U5 is pulsing. Collector & base steady but the emitter is pulsing from 0 to ~7V and with the heads unplugged it just goes down to earth through a 12k resistor. So it looks as if its breaking down, odd. Its a quad pnp in a 14 DIL, Q2T2905 and there are not many about, same with the equivalent NTE2322, so I might have to take a risk with a China import :(

MPQ2907 looks like an equivalent on a brief check.
 
Last edited:
Dont quite know how I thought the base of the transistors were steady, but the digital board does indeed pulse them on standby. Odd.

So its not the transistor array.

Back to basics I think.

Format a disk with the good analogue board then try to read it with the bad and see if I can see any data at the test points after the diff amp.
 
New diff amp fitted. and signal now passing through both stages to the flipflop

Still won't format

Analogue board fitted into the working drive and it formats fine. So, the digital board has been repaired and now so has the analogue board. Next link in the chain are the drives themselves. Obviously I have cleaned the heads and the coils seem to be intact.

Have to think about this one and do some testing.

But another step forward.
 
Ah Ha !

The facia mounting is cracked. This is allowing the latch to rise up which means the disk is not being held in contact with the disk, so that won't help. The mounting is a bit flimsy and the plastic is a bit brittle so it will need some buttressing and stiffening but with any luck it should be almost there.
 
Disk drive repaired and formatting fine, analogue board working, but the digital board, though now responding to IEEE instructions, wont run a format.

Data is being sent to the disk ok, but its not coming back. The circuit seems a bit odd around the data return as it has a series of analogue switches that when I try to test them on the working board, the signal is affected by the scope and stops it working so I cant see what good looks like, but the bistable arrangement in UP6 is running, following the data back, it goes into a shift register, and the first 4 bits are changing, but the higher 4 bits of UN5 aren't and it also means nothing is reaching UP5 either.

So some 74164's on order.

Why do I keep getting these multichip failures. I am reasonably careful with static precautions and it is only bipolar logic so it must just be bad luck :)

Almost there !

I hope.
 
Humm (again)

Shift register replaced and thats now working but it still wont format. With a formatted disk, it almost reads, but the last line is corrupt and a save almost works.

Not sure where to go next.
 
Investigation into the way the read circuit works

Data comes in to a flipflop which holds the data for reading into the shift register then in though some 74LS157 buffers
1688307715063.png
Then there is a strange circuit which appears to feedback to the clock input of the shift register and I surmise that it runs in sync with the data stream

1688307910376.png
 

Attachments

  • 1688307705804.png
    1688307705804.png
    297.3 KB · Views: 0
Ah ha !

So I formatted a disk with the good board then attempted to read it back and got back on the last line


bdgccs instead of blocks

Reading out the binary for the ones that are wrong, in each case, bit 3 is 0 and should be 1 :)

ie, a 'd' is 01000100 in PETSCII and the correct 'l' is 01001100

So I need to trace bit 3 back through the shift register & buffers to the ROM at UK6.
 
Of course, the data from the disk clocked into the shift registers is not simple binary, but GCR encoded data and the single bit difference between 01000100 and 01001100 for the letter d rather than l is not a single bit in GCR, but two bits, ie 111001110 against 111001101 which seems less likely.

That suggests that the fault isn't in the bit that takes the serial data into a shift register then takes that parallel data into a ROM to decode the GCR, but afterwards.

The next piece in the chain is a 6522, but swapping that with a good unit doesn't fix it. I did check the leg to track continuity on the input ports but also need to do it on the data pins D0 to D7, then as the IEEE port is working, I think the next step is to test the RAM as I think I have a diagnostic program to do that.

The adventure continues.
 
And reading from a disk suddenly works. The single bit error got me looking back at the IEEE interface, touched the relevant bit on the transceiver with my scope to see what was happening and it sprung into life so probably needs a run over with the iron.

But it wont write properly. Wont format and saving to a pre-formatted disk almost works but with small errors suggesting something wrong in the logic of the write circuit which implements GCR in 74 logic and a shift register.

I have drawn out the read and write circuits separately with extraneous logic removed to help testing. Just need the time (day 79 of a reactor shutdown maintenance period at work has taken over two months of my life !)
 
Back
Top