UK Vintage Radio Repair and Restoration Discussion Forum

UK Vintage Radio Repair and Restoration Discussion Forum (https://www.vintage-radio.net/forum/index.php)
-   Vintage Computers (https://www.vintage-radio.net/forum/forumdisplay.php?f=16)
-   -   Gemini 80-Bus System (https://www.vintage-radio.net/forum/showthread.php?t=156106)

john_newcombe 8th Jul 2019 3:59 pm

Re: Gemini 80-Bus System
 
I checked the Mux ICs (10, 11, 12, 15, 16, 17) and I can see the negative going pulses on pin 1 in each case.

Turning my attention to the clock, I re-inserted the original ROM and checked pin 6 of IC 3. The clock frequency was 9.38 Mhz and is clearly coming from the VCO as I could adjust the frequency with RV1. Pin 11 of IC 7 was High (6 Low) and as expected given pin 11, no output on pin 10. Just for fun I adjusted the VCO to 16Mhz however, no change.

I will quickly check with the second IVC ROM before coding up a ROM as was suggested by Neal, e.g.
Code:

        ld hl, 0xc000          ; status write
        ld a, 0x02              ; crystal dot clock
        ld (hl), a              ; write
loop:  jr loop

This should give me something concrete to work with.

john_newcombe 8th Jul 2019 5:47 pm

Re: Gemini 80-Bus System
 
More like mud than concrete....

First I programmed up a ROM with Neal's code designed to test IC25.

Code:

        ld hl, 0xc000          ; status write
loop:  ld (hl), a              ; write
        inc a
        jr loop

I checked the outputs of IC25, pins 2,16,19 showed a square wave with some 'glitchiness'. On the others, a more sinusoidal waveform of a higher frequency.

I then programmed up a rom to test the dot clock e.g.

Code:

        ld hl, 0xc000          ; status write
        ld a, 0x02              ; crystal dot clock
        ld (hl), a              ; write
loop:  jr loop

With the above code, it was necessary to reset the CPU many times (10+) before I saw pin 9 of IC25 go high and select the 16Mhz Xtal dot clock. This seems to be the case at each power up.

I have little idea of what this all means as yet....

Next up is to check the reset via port B3, the code I have to do this is as per John e.g.

Code:

loop:  in  a,($b3)
        out ($b3),a
        jr loop


NealCrook 8th Jul 2019 7:32 pm

Re: Gemini 80-Bus System
 
Code:

0100 db b3              loop:  in a, (0xb3)     
0102 c3 00 01                  jp loop    ; sorry, can't assemble relative backward jumps in my head

so, this should do it - you should see pulses on the left end of R24. However, the loop is probably so fast that you will not see a clean reset on the other side.

Neal.

john_newcombe 8th Jul 2019 7:53 pm

Re: Gemini 80-Bus System
 
Thanks, I will try it tomorrow.

JohnBHanson 8th Jul 2019 9:34 pm

Re: Gemini 80-Bus System
 
you might try
loop: in a,(0b3h)
loop2: djnz loop2
jr loop


That will add a delay and allow (hopefully) the IVC to come out of reset.

NealCrook 9th Jul 2019 7:26 am

Re: Gemini 80-Bus System
 
Good idea!

john_newcombe 9th Jul 2019 5:10 pm

Re: Gemini 80-Bus System
 
I have now entered and run the code supplied and I can see the reset signals on Pin 9 of IC35 (PROM) and on the /RST pin of the CPU. I guess this gives us some confidence that the PROM is doing its job.

I am not sure how to proceed except that I know that from the time the IVC was working, it displayed the 'IVC Monitor...' message irrespective of the whether the IVC was being used or not (i.e. irrespective of the the setting of pins 6 and 7 on link LKB1 on the CPU board). Perhaps it's time to get back into the ROM code to try and get a clue as to why the message is not being displayed and why the Xtal dot clock is not being selected.

I am also wondering how confident we can be about IC25? I know that its outputs showed signals during the code that looped through accessing the various components, however, this was less than conclusive when the output was explicitly set in code. It seemed as if the CPU needed to be reset multiple times, could that be a red herring?

john_newcombe 9th Jul 2019 9:50 pm

Re: Gemini 80-Bus System
 
Just for the record, this was the code compiled...

Code:

0100-DB B3            25 ( 11) loop:  in a,(0b3h)
0102-10 FE            26 ( 8+) loop2:  djnz loop2
0104-18 FA            27 ( 12)        jr loop

This was entered manually at the RP/M prompt as follows...


Code:

S100
DB B3 10 FE 18 FA
.
G


NealCrook 10th Jul 2019 9:08 am

Re: Gemini 80-Bus System
 
Well, it's good that you can blip reset successfully from the host.

Your comments about getting the IVC message even when the board is not selected suggest that the local cpu should initialize the display even without any encouragement from the host, so that suggests there is little benefit (yet) in worrying about that blob of circuitry in the top left corner of sheet 1.

I am puzzled why the dot clock is not being selected reliably by the tiny test program.

I suggest going back to my original select everything in turn rom and taking a look at the crtc CS and E signals per my earlier post

If they look ok then I suggest going back to the proper to. And having a probe around..

- is the crystal dot clock selected
- are any outputs from the crtc toggling.. particularly the address and row select lines going to the chargen and display rams
- if yes to both the above then guess that the cpu has set everything up ok. So look at the final shift register load/clock pulses as I mentioned before and follow the video data and hsync vsync logic through to the output.

- you can also check that the other outputs of the latch look correct.. like the display enable and reverse video.

Neal

john_newcombe 10th Jul 2019 1:01 pm

Re: Gemini 80-Bus System
 
OK, I will look again with the dot clock test program installed and confirm the behaviour before re-checking the CRTC with the select every thing test.

Quote:

Originally Posted by NealCrook (Post 1159227)
If they look ok then I suggest going back to the proper to. And having a probe around.

... did you mean the proper ROM.

NealCrook 10th Jul 2019 5:33 pm

Re: Gemini 80-Bus System
 
Yes, sorry. Autocorrect on my phone!

john_newcombe 10th Jul 2019 9:23 pm

Re: Gemini 80-Bus System
 
This is starting to get a tad embarassing...

I have retested the IVC card with the 'address everything' test ROM and I am seeing slightly different results than I saw previously. I have photographed the images and posted them here https://glasstty.com/wiki/index.php/IVC_Scope_Images.

The short of it is that I see activity in all places I expected except /IORQ where the condition is a permanent high on pin 20 of the CPU and at the i/p of IC31 (pin 12). The output of IC31 (pin 8, connected to CRTC E) is permanently low.

The behaviour is different from that experienced during the previous tests with this ROM in that the signals were generally much narrower negative and positive going spikes and the same signal did seem to appear on the /IORQ. Clearly I have been doing something wrong/different between the two tests sessions, however, I am at a loss to explain what is different.

Just to be safe I checked the ROM's contents just to make sure I hadn't labeled it incorrectly or mixed it up with another. And so I am left thinking that perhaps I had a bad ground connection on the scope or some other probing issue. Or perhaps I am doing something wrong now, like I said, it's all a tad embarrassing :-/.

I also checked the dot clock select again and I am now happy that this is working correctly with the Xtal clock being selected each time the 'clock test' ROM is used. This is also the case when the original IVC Monitor ROM is used.

At this point in this particular test session, the issue seems to be that with the 'address everything' test ROM (and the original ROM come to that), there is no signal present on IORQ despite the IN statement being in the loop.

Just for completeness I swapped the CPU for a known good CPU (different to any tried before) without any change in behaviour. I also removed IC35 (socketed) and the CRTC in order to leave the IORQ line isolated and there was no still signal on either /IORQ pin 20 CPU or pin 12 of IC35 socket.

So if all of this is correct and I haven't gone mad, what could be preventing the IORQ from strobing IC31 when there is a perfectly good IN statement in the code?

JohnBHanson 10th Jul 2019 9:38 pm

Re: Gemini 80-Bus System
 
Looking at the scope images - it appears that you are triggering the scope on IORQ. If that is the case have you got a delay setup on the scope so that the in a,(0) instruction is off the left of the display?

john_newcombe 10th Jul 2019 10:01 pm

Re: Gemini 80-Bus System
 
No not triggering on /IORQ as /IORQ is permanently high. Just using Auto on channel A with channel B disabled.

NealCrook 11th Jul 2019 7:35 am

Re: Gemini 80-Bus System
 
This is puzzling. With the board powered down I suggest buzzing out the pin to look for a short to power/gnd and to look for a short on adjacent pins of the cpu or crtc.

Next step in desperation is to bend the cpu pin (about 45 degrees) so that you can insert it without it touching the socket pin then probe it like that. If it doesn't toggle then I might admit to being extremely puzzled.

(I am away on vacation and I didn't pack the schematics so that's my best guess for now)

Neal

john_newcombe 11th Jul 2019 9:19 am

Re: Gemini 80-Bus System
 
Ok thanks Neal have a great vacation and don't think about IORQs and the like anymore :).

In terms of bending the pin, no need as removing IC31 from its socket etc. effectively does the same thing. However.....

I have just noticed that /NMI on the CPU is permanently held low presumably by IC 19 pin 15 (LK4 is connected A-B). My understanding is that /NMI is used to indicate the blanking period. With /NMI low would that not prevent IORQ from doing its thing, leaving me with a blank screen into the bargain.

john_newcombe 11th Jul 2019 11:01 am

Re: Gemini 80-Bus System
 
Having read a little more I can see that /NMI is triggered on a negative edge and that the signal is generated from the VSYNC of the CRTC which is what is holding it low and presumably not pin 15 of IC19 which is an input to the tri-state buffer.

So I am thinking that this is all a red herring and that I should investigate further why I see no IORQ despite the IN instructions within the code loop.

john_newcombe 11th Jul 2019 3:29 pm

Re: Gemini 80-Bus System
 
Taking Neal's advice I checked IORQ with pin 20 of the CPU (IORQ) bent out from the socket (https://glasstty.com/wiki/index.php/File:IVC-IORQ.jpg), the output on this pin is a very stable high. This was checked with a scope and a logic probe that can detect pulses. It doesn't change even when the system or card is reset.

I re-checked the ROM Code here is the dump...
Code:

>LOAD 2732A
 00000-0007F#00000
>DUMP 00000,50
 00000  DB 00 21 00 20 7E 77 21  [.!. ~w!
 00008  00 40 7E 77 21 00 60 7E  .@~w!.`~
 00010  21 00 80 7E 21 00 A0 7E  !..~!. ~
 00018  77 21 00 C0 AF 77 21 00  w!.@/w!.
 00020  E0 7E 77 18 DB FF FF FF  `~w.[
 00028  FF FF FF FF FF FF FF FF 
 00030  FF FF FF FF FF FF FF FF 
 00038  FF FF FF FF FF FF FF FF 
 00040  FF FF FF FF FF FF FF FF 
 00048  FF FF FF FF FF FF FF FF

...which ties in with the code that Neal suggested, e.g.

Code:

  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

With this ROM code I can see the activity as before on the various /CS /OE /WR etc. but no IORQ. I am at a loss to understand what is (or isn't) happening. I think I probably need a vacation.

john_newcombe 12th Jul 2019 10:44 am

Re: Gemini 80-Bus System
 
Ok, so a swap of CPU for yet another, reveals the same symptoms. Then it dawned on me... what if there is a minor issue with the data bus such that the IN instruction is corrupted to something else.... hmmm vacation over.

john_newcombe 12th Jul 2019 9:51 pm

Re: Gemini 80-Bus System
 
I have just posted images of the data bus (first block of 8 images). D0 and D1 seem rather odd. Any thoughts...

https://glasstty.com/wiki/index.php/Gemini_IVC_Problems


All times are GMT +1. The time now is 12:37 pm.

Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.