Gemini IVC Problems
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 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 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.
SiriusHardware over on https://www.vintage-radio.net 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 https://www.vintage-radio.net, without you guys I would have given up long ago.
So here it is booted to a 32k CP/M Gotek disk image.