Difference between revisions of "Gemini IVC Problems"

From GlassTTY
Jump to: navigation, search
Line 1: Line 1:
[[File:G812-IVC.jpg|thumb|The troublesome Gemini IVC Video Card.]]
[[File:D0-D7.jpg|thumb|Activity of D0 to D7 respectively]]
[[File:D0-D7.jpg|thumb|Activity of D0 to D7 respectively]]
[[File: IVC1-7.jpg|thumb]]
[[File: IVC1-7.jpg|thumb]]

Revision as of 20:39, 12 July 2019

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.

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.

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 creat 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 https://www.vintage-radio.net, 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.