Fixing a Superbrain up

[jonb]

And so...

Superbrain rides again!

Once the new CRT8002-003 turns up, I will be able to fix the font.

[jonb]

Now we have to return to the PSU, or the monitor.

As I said, today the monitor started turning itself off for a period of time, then turning back on. I wonder if this is caused by the power supply failing - at least, the 21v, 15v or 12v line collapsing.

Since the main board still works when the monitor shuts down, I think the 12v line is OK. I need to put a meter on the other two rails. While I do that, is there anything in the monitor schematic that looks like a crowbar or other safety shutoff?

Superbrain video board schematic

[1024MAK]

At first glance, I can't see anything obvious.

I do recommend that you carefully check the LOPT and surrounding components, including Q414 and surrounding components for cracked or dry solder joints.

Also it looks like the lost of the horizontal sync signal will cause similar symptoms, so check the connections in this circuit.

Putting the 'scope on pin 3 of the 555 monostable (U402) would be good

If the picture slowly comes and goes (fades in and out), check the heater circuit to the tube.

It may also be worthwhile checking the pins on the tube base and the socket pins.

Mark

[jonb]

It looks and sounds as if it is powering off. I get the usual CRT static and the image collapses (although not immediately, takes about 200ms) it clicks sometimes too, and the image jumps occasionally. I'll take the board out and give it a good checkover. Could be there is a loose connector, it's been off and on a few times. The LOPT is is an odd looking beast (old fashioned), remote mounted on the chassis, and there are two HT leads coming out of the cap. The end not connected to the flyback is grounded via a long resistor (looks like). Is this to (slowly) discharge the tube when it's not in use?

[1024MAK]

It is the horizontal/line sync that controls the LOPT, which in turn powers the HT. So loss of drive to the LOPT will cause the HT to collapse. So worthwhile checking the horizontal/line sync. circuitry.

I have only seen LOPTs with HT cables going to the tube.

Mark

[jonb]

I have only seen LOPTs with HT cables going to the tube.

Me neither, but there it is:

It is the horizontal/line sync that controls the LOPT, which in turn powers the HT. So loss of drive to the LOPT will cause the HT to collapse. So worthwhile checking the horizontal/line sync. circuitry.

Righty ho. First off, get the little board out and check for dry joints / reflow it.

[jonb]

You must be prescient, Mark..

LOPT connector

That's the bottom of the LOPT connector. With cracked joints....

[jonb]

Quick reflow (plus some other likely candidates) and we are back in the game. I have left it on to perform a soak test, but so far (10 minutes) there have been no problems, and the picture seems fairly solid.

[Edit: It's been on for a couple of hours now. No problem, other than some brightness / contrast fluctuations. Must be a dirty wiper on one of the trimmers.]

Again, Mark: Thank you for advising me.

So, what's left to do with this Superbrain?

• Fit a CRT8002-003 to fix the on-screen font (on order, seemingly via the slow boat from China).
• Diagnose and fix the Tandon floppy drive (may be nothing but the wrong format disk inserted). Needs the "motor off" hack, as it runs constantly.
• Diagnose and fix the hard drive interface.
• Fit uIDE and write a driver for it. May need an interface board to connect it to the expansion port connector, because the z80 shim probably won't fit under the case (assuming I am going to use CPU2 for this - I need to see how the ACT Winchester interface is driven first).

We are getting there...

[jonb]

More problems..

• I discovered that the Superbrain won't format an emulated disk (in the HxC device) properly. it goes through the motions of formatting and verifying, but on completion (with no errors) the disk is exactly as it was prior to "formatting" began.
• I need to transfer some files to it via serial. I have just discovered that the Main port is broken.

So let's begin with this serial port. The Superbrain uses an Intel 8251 USART (marked as "Z59" on the schematic) with MC1489 (Z63) / MC1488 (Z66) level shifters for input / output respectively. All very classic. I set the serial port on the Superbrain and PC to 2400-8-N-1, connected the main port to a PC via a null modem cable and USB serial adapter, loaded a terminal emulator on the PC and monitored the serial line (using the command PIP con:=rdr:).

No characters appear on the Superbrain's screen when I enter keystrokes into the PC's terminal emulator. So, to the electronics. Using a logic probe I checked the RX input of the MC1489 (pin 4). I can see the probe pulsing with the keystrokes from the PC, so the RS232 wiring is OK for RX. However, the signal goes no further, as the output of the level shifter (pin 6) is stuck high. So it appears I need to swap this out...

[1024MAK]

Jon, are the power supply (+5) and ground connections to the MC1489 good (pins 14 & 7)?

If yes, and you get +5V between the pins, yep, a new MC1489 needed.

Mark

[jonb]

5.08v

I have a spare here, I'll fit it and see.

This is not the first time I have seen problems with these level shifter chips. The P2000C uses them, too. Are they a common failure point?

[1024MAK]

Well... if you read the data sheet (and various manufacturers made them), they are supposed to be able to handle anything that RS232 can throw at them. But, they are the first point of failure, so it's a case of did it just die, or did a high voltage (static charge) get in????

Mark

[jonb]

New chip has fixed Rx, but still nothing on-screen..

Oh, hang on. I used TTY: as the input in the PIP command but it should have been RDR: (logical device). Now it is receiving bytes nicely, but not sending (via PUN:). Sounds like the other level shifter Z66 needs a look see, but it is OK - and I can't see anything coming out of the USART (pin 19, Tx)

Errm... maybe the AUX port will work?

LST: is the output device for the AUX serial port, and it is sending. But which is the input device? It may not be implemented, although there is an AUXIN routine in the BIOS. I've tried all of the devices in the CP/M manual..

[jonb]

I think I've had enough for one session! I pulled a known good 8251 from the P2000C (which now has that plus 2 banks of RAM missing!) and fitted it into the Superbrain's MAIN port circuit (Z59). As before, PIP pun:=[text file] enables the chip, but nothing is coming out of its Tx pin. So something else is not right. It is receiving data from the PC though, which is a step in the right direction.

So, I have AUX: sending and MAIN: receiving. Pity I can't get each to do the reverse!

[jonb]

Further tests with a terminal emulator:

• It's a a CP/M program called ADM3A.COM. No prizes which terminal it is emulating...
• Receives text from the PC fine at 2400 baud.
• Will not send at all (expected).
• After first send attempt (single character) the program stops receiving, but I can see the /CE line is still pulsing (it is polling the Rx port), so I think it hasn't crashed; however it cannot be exited using ^A (it says that this is how you exit it).
• ^A does work immediately after the program is launched and after receiving characters from the PC.

So, somehow the transmit is locking things up. The port is set for 2400-8-N-1 with no handshake, and as we can see the PC is sending successfully, so I think the settings are correct. I found another terminal emulator that doesn't lock on send attempts (it's receiving fine) but again, nothing is coming out of the USART's TxD line.

[hoglet]

A couple of things to check wrt the main UART not sending (you probably have done these already...)

1. Check there is a clock on pin 9 of the UART

2. Check that flow control is set appropriately (maybe try looping RTS back to CTS).

Dave

[jonb]

hi Dave

There is a clock on Pin 9 - pulsing nicely.

Re: Flow control, the port is set to Asynchronous mode, which I assume means "no hardware handshake". If flow control is enabled, shouldn't it fail to receive? I note also that /RTS and /CTS are both high when attempting to send.

[hoglet]

I think "Asynchronous mode" refers to the overall mode of operation (8251's support Asynchronous and Synchronous modes), rather than flow control.

It might just be worth trying to force CTS low (bend the pin out and tie to 0V).

Another thing to check during transmission is what happens to the following pins:
- TxRDY - pin 15
- TxEmpty - pin 18
- TxData - pin 19

Alternatively, do you have any way to peek and poke the UART to try sending characters manually?

Dave

[jonb]

Well done, Dave!

It seems the Main port expects CTS/RTS handshake. Gosh. And there is no way to turn it off... With CTS held low it sends!

So, in TeraTerm, if I set handshaking to "hardware" it seems that it is all good.

[hoglet]

[jonb]

Now, now Dave, it was your suggestion that did it! <- That's for you!

Next problem is some floppy disk writing oddness.

At the moment, the machine is connected to the HxC floppy emulator. It boots and reads files, executes programs. However, when I attempt to write anything, I am getting odd behaviour.

For example, when copying a file on the same disk using PIP, it performs the copy repeatedly, like it is retrying over and over again. Resetting the machine and looking at the directory shows the copied file plus another with a $$$ extension (this is a temporary file that PIP creates to make a copy; when done, it renames the $$$ file to the correct extension). Seems it is doing this repeatedly.

This behaviour may be caused by a difference between the number of tracks on the drive vs. the number the BIOS recognises. Superbrains had several different drive types as well as after market BIOSes that extended this. The disk image currently in the HxC is 42 tracks (very odd), whereas the BIOS expects a 35 track (double sided).

Example 2: When transferring a file to the machine using PIP, I am getting an empty file (so the directory track is updated, but there is nothing in the file).

Example 3: No format program seems capable of formatting the (emulated) disk. It goes through the motions of format and verify, but when I look at the disk, there is no change.

This could be down to the disk format, the BIOS version, etc. The FDC is new.

[jonb]

I've had a chance to try a few more things, all with the HxC.

• Swapped out the eBay sourced FDC for a known working one. No change.
• Tried three different formatting programs, using DS SD, DS DD, SS DD type formats. No change.
• Tried more PIP tests. No change. PIP b:=a:pip.com[v] (copy with verify) results in oddness. The screen clears and it says INVALID FORMAT: qIC {o which looks like some sort of corruption.
• Doing ERA *.* on a disk seems to work (although it crashes the machine occasionally).
• Tried various other disk (images), none of them would format.

I'm thinking there may be a problem between the FDC and the floppy drive connector that is causing random write errors that the FDC doesn't detect. is it likely to be the "write precomp" circuit at Z94 (including Z72)? Some data is getting to the disk, but not all of it. Never any format information, and usually only directory info. I can hear the HxC seeking when it should (it clicks to simulate head movement). I did manage to copy a file MBASIC.COM to A: though. Once. I just tried again, and got screen corruption that cleared immediately (this does happen fairly often when writing to the FDD). All memory tests check out OK, though (including the disk buffer memory check).

FDC write circuit

Any thoughts? Maybe the memory switching logic is bad? But then, there are no read problems at all.

[1024MAK]

If you unplug the FDC (Z93) and use some very thin solid core wire, you can set the voltage levels on the output buffer chips and confirm that the output pins of the buffer chips work correctly.

As a final check, you can remove your temporary wiring, put the FDC back in, connect a dual channel 'scope with channel 1 connected to a buffer input pin, and channel 2 connected to the output of that same channel. You can then get that circuit to operate, and confirm on the 'scope that the buffer is working.

With the write data line, if Z94 is in a socket, do the same.

Z94 is a counter, so check/test all the inputs, including the clock input pin. There is a datasheet here (PDF). It's worth having a read

Mark

[jonb]

There may be some noise on the outputs of the 7406. I have ordered a new one, as well as a 74LS161 because they are reasonably cheap.

One thing I'm nut sure of - the outputs are 30v? Yet I see 5v output from the buffer's write line.

I also discovered defective RAM (where before it was all good). Fixed the low RAM bungle and I can write to disks now.

The ICE reports no problems with the other banks apart from bank zero, where there seem to be quite a few errors. There's a pattern to the addresses though, and I suspect it is caused by the bank "switch" not being in the right position. Addresses in the range 0000-3FFF ending 00 and 80 are returning FF and that doesn't look like bad RAM to me, because it's unlikely that every DRAM chip in Bank 0 has a broken bit at the same place.

I'm running the Intertec RAM test to be sure (although it is very, very slooooooooow....)

[1024MAK]

The 7406 are inverting buffers with open collector outputs that can switch external voltages of up to 30V. They are unable to source (output) any voltage themselves (they can however "sink" 40mA to 0V/GND). In the disk drive circuits, there are either pull-up resistors to the +5V line in the computer, or in the disk drive (terminating resistors). Link to datasheet.

Mark

[jonb]

Today, the long awaited CRT8002-003 IC arrived from China. As I said before, the -003 designation indicates the font is 7x5, and here it is in action!

Font sorted!

[jonb]

So... I'm waiting for these two logic chips to replace the floppy drive output circuit chips.

Meanwhile, I thought I'd have a go at sorting the HDD out. As I have fixed the RAM it should be reasonably test-worthy. I discovered that I'd got the cbles to the adapter card the wrong way round, so switched them back. I have a hard disk test program to hand, so I powered it up and booted the machine.

It won't boot off the HDD.

However, the test program was able to move the heads and perform some other tests on the interface. It all looks peachy. Problem is, it has no way to read the drive (it wants to do destructive read/write tests), so I will have to write something to do this, probably based on the boot code...

[jonb]

A bit of CP/M hackery - read the boot sector from the hard disk.

Code: Select all

;
; Quick program to pull the boot sector from an ACT HDD on a Superbrain
;
; JonB 2017
;
BDOS   .EQU   05h

HDCMD   .EQU   0C8H      ; Hard disk controller command port
HDSTAT   .EQU   0C8H      ; Hard disk controller status port
HDTRK   .EQU   0C9H      ; track number
HDHEAD   .EQU   0CAH      ; head number
HDSEC   .EQU   0CBH      ; sector number
HDDATA   .EQU   0CCH      ; data buffer
HDDRV   .EQU   0CDH      ; drive number

HD_READSEC   .equ   01h   ; read sector command
HD_HOME      .equ   06h   ; Home disk command

   .org   100h
   
   XOR   A      ; a=0
   OUT     (HDDRV),A   ; Drive 0
   OUT     (HDTRK),A   ; Track 0
   OUT     (HDHEAD),A   ; Head 0
   OUT     (HDSEC),A   ; Sector 0

WAIT_R:   IN      A,(HDSTAT)   ; Wait ready
   ADD     A,A      ;
   JP      P,WAIT_R   ; loop back if not zero
   
   LD      A,HD_HOME      ; Issue Home disk cmd
   OUT     (HDCMD),A   ;
WAIT_H:   IN      A,(HDCMD)   ; wait for home bit (guess)
   RLA           ;
   JP      C,WAIT_H   ; if bit 7 unset, loop back
   
   LD      A,HD_READSEC   ; issue READSEC command
   OUT     (HDCMD),A   ;
WAIT_S:   IN      A,(HDSTAT)   ; get status
   ld   (status),a   ; save down
   AND     82H      ; AND 10000010
   JP      M,WAIT_S   ; Negative (bit 7 set), loop back
   JP   NZ,ERR_RD   ; read error
   IN      A,(HDDATA)   ; else it's Zero, get first byte
   LD      HL,buff      ; Copy 256 bytes from the drive to the buffer
SEC_B:   IN      A,(HDDATA)   ; get byte from drive
   LD      (HL),A      ; copy to DMA buffer
   INC     L      ; next byte
   JP      NZ,SEC_B   ; if it's < 256 loop for next byte
   
   ret         ; back to CCP

ERR_RD:   ld   a,(status)   ; get status value
   ld   l,a      ; ..into L
   ld   de,hbuff   ; set up hex text buffer
   call   Num2Hexb   ; convert to hex
   
   ld   hl, rderr   ; and print it
   call   pstr      ;
   
   ret         ; ..done
   
;-----------------------------------------------------------------------------   
; print null terminated string pointed to by hl
pstr:
perr:   push   bc      ; save context
   push   de      ;
   
pstr1:   ld   a,(hl)      ; get character
   inc   hl      ; advance pointer
   or   a      ; check for null
   jr   z,pstr2      ; return if so
   push   hl      ; save pointer (BDOS call ahead)
   ld   e,a      ; char to be printed
   ld   c,2      ; conout
   call   BDOS      ; go
   pop   hl      ; restore pointer
   jr   pstr1      ; loopback for next char
   
pstr2:   pop   de      ; restore context
   pop   bc      ;
   ret         ; and return
   
;-----------------------------------------------------------------------------
; Number in HL to ASCII HEX
;Input: HL = number to convert, DE = location of ASCII string
;Output: ASCII string at (DE)
   
Num2Hex   ld   a,h   ; 16 bit hex
   call   xNum1
   ld   a,h
   call   xNum2
Num2Hexb:      ; 8 bit hex
   ld   a,l
   call   xNum1
   ld   a,l
   jr   xNum2

xNum1   rra
   rra
   rra
   rra
xNum2   or   0F0h
   daa
   add   a,0A0h
   adc   a,40h

   ld   (de),a
   inc   de
   ret
   
   
rderr:   .text   "\r\nRead error: "
hbuff:   .text   "00h\r\n\000"

status   .db   0      ; read status

buff:   .db   256      ; sector buffer

   .END
;-----------------------------------------------------------------------------   
; EOF
;-----------------------------------------------------------------------------   


Darn that code tag, does not work with tabs!

The program returns 76h as an error. Not sure what that is at this time (most likely a bit code), but it's definitely not a successful read. NOPping out the JP NZ,ERR_RD instruction, I get data back but it looks like garbage - it's supposed to be executable code but it doesn't make a lot of sense.

Incidentally, this read routine is a copy of what is in the HDD boot ROM:

Code: Select all

c3A3 AF        XOR   A      ; a=0
c3a4 D3CD      OUT     (0CDH),A      ; Drive 0
c3a6 D3C9      OUT     (0C9H),A      ; Track 0
c3a8 D3CA      OUT     (0CAH),A      ; Head 0
c3aa D3CB      OUT     (0CBH),A      ; Sector 0
c3ac DBC8      IN      A,(0C8H)      ; Wait ready
c3ae 87        ADD     A,A      ;
c3af F2ACC3    JP      P,0C3ACH      ; loop back if not
c3b2 3E06      LD      A,06H      ; Issue Home disk cmd
c3b4 D3C8      OUT     (0C8H),A      ;
c3b6 DBC8      IN      A,(0C8H)      ; wait for home bit (guess)
c3b8 17        RLA              ;
c3b9 DAB6C3    JP      C,0C3B6H      ; if bit 7 unset, loop back
c3bc 3E01      LD      A,01H      ; issue READSEC command
c3be D3C8      OUT     (0C8H),A      ;
c3c0 DBC8      IN      A,(0C8H)      ; get status
c3c2 E682      AND     82H      ; AND 10000010
c3c4 FAC0C3    JP      M,0C3C0H      ; Negative (bit 7 set), loop back
c3c7 C230C3    JP      NZ,0C330H   ; Positive (bit 1 set), poll keyboard again
c3ca DBCC      IN      A,(0CCH)      ; else it's Zero
c3cc 2180C7    LD      HL,0C780H   ; Copy 256 bytes from the drive to C780
c3cf DBCC      IN      A,(0CCH)      ; get byte from drive buffer
c3d1 77        LD      (HL),A      ; copy to machine buffer
c3d2 2C        INC     L      ; next byte
c3d3 C2CFC3    JP      NZ,0C3CFH   ; if it's < 16 loop for next byte
c3d6 C380C7    JP      0C780H      ; done. Jump to the code

[jonb]

Well.. I have no idea how it happened, but I'm back to having floppy disk write fails again.

A:>PIP b:=a:pip.com leaves PIP.$$$ on B: as before.

And I have replaced the 7406 to no avail. No memory errors detected.

Grrr.

[jonb]

In my experience, 2114's frequently fail. Probably the number one cause of a dead atom.
But check the chip select first before ripping it out.

Since the /CE is working, I've replaced these two SRAM chips. The format is still failing, and so is PIP. I htink format goes through the motions because it is not checking the error status properly (but then, how could it successfully verify?)

I think that some sort of spurious error condition is coming back from the FDC. Sometimes, I get a BDOS Error: R/O error. I tested the /WRT_PROTECT circuit and it's behaving properly. I can see it changing state when a write protected floppy is accessed, so that's not the issue.

In the schematic, it has /WF (pin 33) tied to +5v, yet every Superbrain motherboard I have seen has this pin cut off (so, floating?). Accordingly, mine is bent out so as not to touch the pad on the socket. I have checked it anyway and it is high all the time. To be safe, I bent it back down so it is forced high by the motherboard. This made no difference.

What's bothering me here is that PIP is crashing all the time when copying from A: to B:. Yet the memory is fine.. so I am beginning to wonder if it is caused by the ROM (which has all the FDC routines in it) having a 40 track setup but the CP/M BIOS only using 35. These are known things with the Superbrain - from the factory the machine did 35 tracks, but there were 3rd party BIOSes that allowed 40. The Tandon drives are 40T DS DD or SS DD, but still 40 tracks. Hmm.

Interesting thing: The ACT ROM (for the HDD) has a higher seek rate baked in. I just swapped it for a QD 3.1 ROM and I can hear the heads moving slower (simulated noise by the HxC).