Difference between revisions of "Gemini IVC Problems"

From GlassTTY
Jump to: navigation, search
m
m
(One intermediate revision by the same user not shown)
Line 3: Line 3:
 
[[File: IVC1-7.jpg|thumb]]
 
[[File: IVC1-7.jpg|thumb]]
  
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. This tied in nicely with obtaining a working CP/M disk, except it didn't, as the CP/M version required the IVC Doh! Thankfully, as described earlier, CP/M could be patched to use the serial port for TTY by changing a couple of bytes so I was off and running. However, in parallel with using a serial terminal to talk to the Gemini CP/M, I set about fixing the IVC card.
+
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 a BBC 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 were different symptoms i.e. a different kind of flashing on the screen and still no video.  
+
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 ther 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 (see image fo how 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.
+
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. The idea came from multiple sources over on https://www.vintage-radio.net, the final code was provided to me by Neal Crook.
+
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                    ;; in ROM and executes from reset.  
Line 39: Line 48:
 
     0025
 
     0025
  
==Data Bus Activity==
+
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.
  
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 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.
  
==Address Everything Test==
+
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;
 
 
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
 
 
 
 
 
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 24 (R/S)
Line 67: Line 66:
 
The scope images for Char Gen IC20 Pin 20 (/OE) are identical to Video Ram IC9 Pin 20 (/0E).
 
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.
 
 
The results suggested all was OK with the addressing. However, during this activity I noticed that a clock signal referred to the DOT clock was not the frequency I was expecting. Further investigation showed that of the two DOT clocks (VFO and crytal controlled) available on the card, the incorrect clock (VFO) had been selected. Following this discovery, a second ROM was burnt that included code designed to explicitly select the crystal controlled clock.
 
 
 
    ld hl, 0xc000          ; status write
 
    ld a, 0x02              ; crystal dot clock
 
    ld (hl), a              ; write
 
    loop:  jr loop
 
 
 
Just for good measure, more code to check the functionality of IC25:
 
 
 
    ld hl, 0xc000          ; status write
 
    loop:  ld (hl), a      ; write
 
    inc a
 
    jr loop
 
 
 
And finally code to test the IVC Reset via RP/M. The code loops with a small delay reading from port B3h, this causes multiple resets to the CPU on the IVC card.
 
 
 
    loop:  in a,(0b3h)
 
    loop2:  djnz loop2
 
            jr loop
 
 
 
This can be entered or pasted into RP/M as follows...
 
 
 
    S100
 
    DB B3 10 FE 18 FA
 
    .
 
    G
 
 
 
Monitoring Pin 9 of IC35 (PROM) on the IVC card allowed the reset pulses to be seen and gave some confidence that the PROM was working. These pulses were also seen at pin 26 of the Z80 CPU (IC21).
 
 
 
So all looks good until the correct IVC ROM is being used. I have a couple of versions of these ROMs all of them show the same symptoms.
 
 
 
Time to look more deeply into the IVC Monitor ROM code.
 

Revision as of 20:31, 12 July 2019

Activity of D0 to D7 respectively
IVC1-7.jpg

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                     
   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 
   0025

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.