Gemini IVC Problems

From GlassTTY
(Redirected from IVC Scope Images)
Jump to: navigation, search
The troublesome Gemini IVC Video Card.
Activity of D0 to D7 respectively
Using enamelled wire to desolder through hole connections.
IORQ pin being monitored after being bent out from the socket.
IORQ Signals following the data bus repair.

During my Gemini journey (see The Gemini 80-Bus Saga), I was originally thwarted by a faulty GM812 IVC video card which failed a couple of weeks after I purchased the machine in May 2019. I set about fixing it.

File:G812 Circuit.pdf

I started by testing the CRTC in a BBC Micro, and the Z80 in an Acorn Second processor, the CRTC worked fine, however, the Z80 failed miserably. I popped a replacement CPU (remarkably with a date code only 2 weeks from that of the original) into the IVC thinking that I had effected a repair only to discover that all I had, was different set of symptoms i.e. a different kind of flashing on the screen and still no video.

After going around the houses and few false starts, I isolated the issue to the strobe that is meant to activate a read or write to the CRTC, the problem was that there wasn't one. Things were getting technical, but by removing the CRTC and the CPU I had isolated enough connections to be able to manually test IC 31 a D-Type Flip Flop which under control of the clock strobes the CRTC, it wasn't working. As this was a soldered in chip, on went the soldering iron and out came the enamelled wire. If you are not familiar with this method of removing solder from through plated holes, here's how I used it when undertaking an Apple IIe RAM swap Apple_IIe_RAM_Swap_the_Easy_Way. Naturally a decent socket was fitted with a new SN74S74 D-Type Flip Flop, alas, the card was still not working correctly and I started to think that it had been hit by lightning.

In order to further test the IVC card, a test ROM was created designed to replace the IVC MON ROM. The code was designed to test the addressing and to create signals of the CPU's IORQ output, it is this output that strobes data into the CRTC. The idea came from multiple sources over on, the final code was provided by Neal Crook.

The memory map of the IVC system is as follows;

   0000 - 1FFF ROM            8000 - 9FFF KEYBOARD
   2000 - 3FFF VDU RAM        A000 - BFFF DATA PORT
   4000 - 5FFF CHAR GEN       C000 - DFFF STATUS (WR)
   6000 - 7FFF STATUS (RD)    E000 - FFFF RAM

And the code supplied by Neal is shown below.

   0000                    ;; in ROM and executes from reset. 
   0000                    ;; assume no stack/working RAM so no subroutines 
   0000                    ORG 0 
   0000 db 00      loop:   in a, (0)        ; should generate /CS to 6845. 
                                            ; Also, use as 'scope trigger 
   0002 21 00 20           ld hl, 0x2000    ; video RAM 
   0005 7e                 ld a, (hl)       ; read then write 
   0006 77                 ld (hl), a 
   0007 21 00 40           ld hl, 0x4000    ; char gen ROM or RAM 
   000a 7e                 ld a, (hl)       ; read then write 
   000b 77                 ld (hl), a 
   000c 21 00 60           ld hl, 0x6000    ; status read 
   000f 7e                 ld a, (hl)       ; read 
   0010 21 00 80           ld hl, 0x8000    ; keyboard 
   0013 7e                 ld a, (hl)       ; read 
   0014 21 00 a0           ld hl, 0xa000    ; host comms data port 
   0017 7e                 ld a, (hl)       ; read then write 
   0018 77                 ld (hl), a 
   0019 21 00 c0           ld hl, 0xc000    ; status write 
   001c af                 xor a 
   001d 77                 ld (hl), a       ; write 0 
   001e 21 00 e0           ld hl, 0xe000    ; workspace RAM 
   0021 7e                 ld a, (hl)       ; read then write 
   0022 77                 ld (hl), a 
   0023 18 db              jr loop 

Checking pin 20 of the CPU (IORQ) I should have seen a nice signal due to the IN instruction within the loop of the code. However, this was missing as a desperate measure I removed the CPU, bent out pin 20 and reinserted it, the idea was to isolate the IORQ output and negate any possible circuit board issues. Alas, still no signal, it looked like the code wasn't running.

Checking the data bus suggested that the code was running Once the ROM was installed and running, the first thing I did was check the data bus activity. The first block of images shows the activity of D0 to D7 respectively.

Checking things further shows more activity. The second block of images show the results of wandering around the various component with an oscilloscope and taken from left to right, top to bottom, they depict the following;

  • CRTC Pin 24 (R/S)
  • CRTC Pin 22 (R/W)
  • MUX ICs (10,11,12,15,16,17) Pin 1
  • Video Ram IC9 Pin 21 (/WE)
  • Video Ram IC9 Pin 20 (/OE)
  • CPU RAM IC 13 Pin 18 (/CS)
  • CPU RAM IC 13 Pin 20 (/OE)
  • CPU RAM IC 13 Pin 21 (/WE)

The scope images for Char Gen IC20 Pin 21 (/WE) are identical to Video Ram IC9 Pin 21 (/WE). The scope images for Char Gen IC20 Pin 20 (/OE) are identical to Video Ram IC9 Pin 20 (/0E).

The results suggested all was OK with the addressing and yet there was still an issue with the IORQ output. At this point I started to think that there was an issue with the data bus that was preventing the code when read from memory.

SiriusHardware over on suggested that ... when two adjacent data lines look identical with frequent half-logic levels as they do on the uppermost two images on that page, it suggests that the two lines are shorted together either physically (track short/solder splash) or by a fault in one of the devices on the bus.

I checked with a digital multimeter and sure enough D0 was indeed connected to D1. By wandering around the board with a digital meter measuring resistance it was fairly easy to identify the area with the least resistance. The issue seemed to be under the CRTC controller socket, and after lifting the socket slightly and much searching with a very powerful magnifying glass, there it was, a small sliver of copper from one track, touching the other. This was removed with a fine scalpel blade and hey presto I can see pulses on IORQ.

I replaced all the ICs and IVC Monitor and I now have a perfectly good IVC Video card, and to be honest I can't quite believe it.

My theory of how this all happened is that the original fault of the blown CPU and faulty IC31 is anyones guess, however, when I removed the CRTC to test it I suspect I either damaged the track slightly beneath the socket or disturbed some previous damage. Ho hum...

At this point I must extend my thanks to all those who chipped in Neal, John B, Julie and SiriusHardware over on, without you guys I would have given up long ago.

So here it is booted to a 32k CP/M Gotek disk image.