View Single Post
Old 7th Jul 2019, 10:46 pm   #136
NealCrook
Tetrode
 
Join Date: May 2019
Location: Reading, Berkshire, UK.
Posts: 51
Default Re: Gemini 80-Bus System

video RAM looks correct: it is output-enabled by default for access by the 6845 or for a read by the Z80, the /OE only negates to allow the data bus to be driven for a write, so the /WE short low pulse should correspond to the /OE short high pulse.

You should also be able to look at the MUX select on IC10,11,12 (pin 1) which should have 2 pulses per loop a bit like you show for the CRTC -- these pulses correspond to the Z80 taking priority over the 6845 and generating the address (once for the read and once for the write).

char gen rom/ram looks correct: you should also see /OE and /WE behave in the same ways as for the video RAM.

You should also be able to look at the MUX select on IC15,16,17 (pin 1) as for the video RAM

crtc: I'm not sure about your comments here because you refer to /CS, /OE and /WE. In the code loop there should be 1 read of the CRTC and no writes. That read should correspond to the /IORQ that you're triggering on. If you see it OK, change to trigger on /CS and use the other probe to look at E. You should see a pulse on E that is overlapping and out of phase with the pulse on /CS - generated by the 'flop IC31b.

workspace RAM: I would expect to see pairs of negative pulses on /CS - the first one matching a negative pulse on /OE and the second matching a negative pulse on /WE.

Quote:
I did notice that the DOT clock is all over the place and noticed that IC25 Pin 9 shows the same negative 33Kz pulses. Pin 9 seems to select either the crystal controlled clock or the VFO. I am thinking that this is something to do with the status port access of the test program.
I started out thinkng this was a problem, but then I realised this part is a 273 which is a transparent latch, and the CLK pin is only a decode of /MREQ and the address bus. The data bus might not be stable at the *start* of /MREQ so there could be a glitch on the outputs at this time, which stabilises before the latch closes. Not very clean but this port probably only gets written 1 time at startup so it would likely not cause a problem.



If IC25 is suspect you can use a dedicated test program like this:

Code:
        ld hl, 0xc000           ; status write 
loop:   ld (hl), a              ; write
        inc a
        jr loop
you should see square waves on the outputs of IC25, with pin 12 at the highest frequency and each next pin at 1/2 the frequency. However, if my guess above is correct you will also see a 33kHz "glitch" superimposed on some if not all of the signals.


What have we learned? Looks as though the CPU is executing code OK and the data but and at least some of the address bus is OK. The memory decoding seems OK.

I suggest

1/ putting the proper ROM back in and seeing if IC25/9 is static. OR blow a ROM in which you set its output to 1, which selects the crystal dot clock:


Code:
        ld hl, 0xc000           ; status write 
                    ld a, 0x02              ; crystal dot clock
                    ld (hl), a              ; write
loop:             jr loop
In either case, check that IC3/6 is stable 16MHz, While you're at it, take a look at the rest of the dot clock logic. With a 16MHz dot clock you should see 1/4 (4MHz) on IC4/21 and then, on the 74165 shift regisrer (can't read the IC number) you should see a 16MHz clock and a load pulse that blips once every 8 clocks.

2/ if you can do io reads and writes from the main CPU to this board, check that you can pulse the CPU reset by a read or write to port 0xb3.

3/ if all that looks OK, I think it would be worth trying to check out the communications between the main CPU and this board -- the logic in the top left quarter of schematic sheet 1.

BR,

Neal.

Last edited by NealCrook; 7th Jul 2019 at 10:56 pm. Reason: hit post too soon!
NealCrook is offline