Re: Gemini 80-Bus System
 

Thank you, I will check these as you suggest.

One other symptom I have just noticed is that with the IVC plugged in, the serial version of CP/M boots but does not show the A> prompt.

Re: Gemini 80-Bus System
 

The voltage across C44, once charged sits at at just over 4.7V. Shorting this does not seem to change things. I can see the reset signal on the CPU go low when I do this. Also I can see C44 charge back up to 4.7V. Just for fun I checked the HALT pin and the CPU isn't in a halted state.

I do have the option of emulating an eprom using a Dataman S4, although I have never done this before so it adds anther variable. Whilst I ponder that one, I will disassemble the IVC ROM.

Re: Gemini 80-Bus System
 

Disassembled IVC ROM, just in case you fancy some light reading... :)

Re: Gemini 80-Bus System
 

Hi John,
I think Julie's suggestion of a custom EPROM is a good one. The best Z80 debug tip I ever got was from someone at NASCOM when my '2 stopped working. He told me to hold RESET low and then follow the address bus from the CPU through address decode to the ROM, and follow the data (0x31 naturally) back from the ROM to the CPU. My test equipment was a TIL209 LED and a 270R resistor.

When I brought my '2 back to life last year, I used a similar technique (though with my 'scope instead of the LED)... turned out to be a bad socket, causing an open-circuit which a TTL gate was considering to be a 1, causing the address bus to skip. I'd almost forgotten about those TTL behaviours.

With some very short custom EPROMS you can toggle all of the address and data bits, do I/O writes to the other devices on the bus. If you just do (eg) 1 I/O write in your loop it will be easy to trigger a scope or analyser and work your way along the bus. Sounds like a fun project for a rainy afternoon (Hmm. Weather's getting hotter..)

regards,
Neal.

Re: Gemini 80-Bus System
 

Ok, thanks. I have been disassembling the ROM and learning Z80 assembler as I go as I spent all of my early days with 6502 assembler on Apple IIs and BBC Micros. When I switched to CP/M it was Pascal and C so I missed out Z80 assembler (apart from a space game on the ZX81, but I'll not count that). With that in mind and with a view to reducing the number of variables, do you have any suggestion as to what the code might be?

The memory map is divided into 8K blocks as follows;

I guess reading or writing from/to each of the blocks would allow me to pop a logic probe on the various chip selects.

The basic issue is that I don't really know what I am doing :). One thing I am fairly certain of though is that, in this case at least, it isn't a faulty socket as there aren't any :(.

Re: Gemini 80-Bus System
 

Oh, you fooled me good and proper! I'll have another look at the schematics over the weekend and suggest a tiny program.

Neal.

Re: Gemini 80-Bus System
 

John,

here is a simple program loop. If you have a 2-channel scope you should be able to trigger on /IOREQ. It should loop after <100 clock cycles.

If it's looping OK, you can use the other channel to probe around to see chip selects on each of the memories, on the 6845, on the buffers used for the kbd and status ports and on the latch used for the write status port. You should also be able to see the low 6 bits of the address bus toggling, and see the data toggling and propagating though the buffers.

I'm assuming you can figure out the details of what to look at on the schematic, but if you need more details, let me know.

The processor sub-system is very straightforward so if this code doesn't even loop there's a fundamental problem with the CPU/clock/reset/address/data signals. If that's the case the next experiment is to take the R24/D1 junction to GND (hold the chip in reset) then
probe to see:

/MREQ /RD both asserted
Address bus 0
ROM chip-selected
data bus reads 0xDB (if this ROM is fitted) or 0x31 if the standard ROM is fitted.

You should also check that you've got CLK on the Z80 and both CLK and E on the 6845.

regards,

Neal

Re: Gemini 80-Bus System
 

I use a PERL module CPU::Z80::Disassembler to explore/disassemble Z80 code. Given a binary and an entry point it traces all paths of execution through the code from that point. Using that result as a starting point you can give it hints of other entry points. As you explore the code the "hints" can get more and more detailed: giving names to labels and back-annotating comments, without ever modifying the binary or reassembling.

Here's a partial exploration of the IVC ROM using this tool. dis_ivc,txt is a PERL program that contains all of the hints, ivc.asm.txt is the result. I did a most of this "blind" in a couple of hours and then read the (excellent) software manual for the board and corrected some wrong guesses that I had made.

This code makes extensive use of the alternative HL/BC/DE register set. The exx instruction swaps between the two, but it's super-tricky to inspect the code and know which of the two sets is in use at any time. I expect the original source file/author had some "rules" about what was the default swap and how to handle use of exx but it would take more inspection that I have time for.

Another strange thing is that the code uses NMI from the vertical retrace. There is code at the NMI entry point, but there is no occurrence of RETN (return from NMI) anywhere in the code. Reading the Z80 manual, I conclude that RETN is not strictly necessary and that RET will do instead, PROVIDED that you never use interrupts (only the non-maskable interrupt) -- which is true for this code.

Neal

Re: Gemini 80-Bus System
 

Thank you so much. I am away this week but I will code up a rom with your code I do have a dual channel scope so I will do what you say.

CLK, seems to be good on z80, and IC31 where it seems to be gated with the iorq to provide crtc E, but as I am not seeing any change in iorq I am not seeing E change.

Thanks again for the time you have spent on this, I will post an update as soon as I have been able to try your code.

Re: Gemini 80-Bus System
 

Just a quick update, I have only been able to spend a few minutes so far, just enough time to see your code looping with IORQ triggering the scope. Will keep you posted.

Re: Gemini 80-Bus System
 

One thing that may be significant though is that the code only runs once I have grounded the reset on the CPU. It would not run from power up. I quickly replaced your ROM for the IVC MON and grounded reset, however this would not run.

Re: Gemini 80-Bus System
 

Well, it's progress and good news to know that the CPU can execute code and loop. Odd that the power-on-reset circuit does not work. As John Hanson suggested, maybe that capacitor C44 is leaky. If you are in a card rack with the rest of the working system you should also be able to do a reset by an I/O read or write to port 0xB3 (that would also be a way to do some kind of a test on the ?IC36? decode PROM.

While watching The Cure at Glastonbury (on TV..) I made more progress on the disassembly; it's a nice puzzle a bit like a crossword. I found the jump tables that search a list of escape codes and invoke a code fragment as a result, and I made a bit more sense of some other parts of the code. I'll post the result once I've checked that it assembles back to an identical binary.

Neal.

Re: Gemini 80-Bus System
 

Thanks Neal, really appreciate the help. I will swap C44 when I get back from Reading on Sunday (your neck of the woods if my memory serves me). I should have done this back when JBH first mentioned it.

Re: Gemini 80-Bus System
 

I have been able to spend some more time with the test code provided by Neil and have a few results. Before starting I changed C44 in the reset circuitry as suggested by John, following this, the code now runs from power up. I did retest the original ROM and a second that I now have with no success.

So with the test code running I had a probe around with the scope. This is what I found.

VIDEO RAM IC9
-------------
/CS was permanently low, this is correct as it is tied to ground.
/WE shows negative going pulses at around 33Khz

/OE shows positive going pulses at the same frequency

CHAR GEN ROM/RAM
----------------
/CS Low on the ROM and high on the RAM this is as I would have expected.

CRTC
----
/CS shows negative going pulses at around 33Khz as per the VIDEO RAM
/OE shows negative going pulses at around 667Khz
/WE shows pairs of negative pulses at around 250Khz

WORKSPACE RAM

/CS shows negative going pulses at around 33Khz

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. If that is the case from what I can see, which is quite limited, it all seems to be working as expected, or am I missing something?

Re: Gemini 80-Bus System
 

Sorry... Neal not Neil.

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.

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:

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:


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.

Re: Gemini 80-Bus System
 

Hi Neal, wow!, thank you for your assistance.

The anomaly around the CRTC is down to my notes being a tad messy. The /OE /WE stated for the CRTC were in fact the signals for the Workspace RAM. The IORQ is signalling the CRTC as expected.

I will check the MUX lines as you suggest and then move on to check the DOT clock and IC25.

I have the RP/M monitor installed in the main CPU so should be able to install and run some code to do some I/O on port 0xb3.

I will let you know how I get on...

Re: Gemini 80-Bus System
 

The RP/M monitor, as I am sure you know behaves like a cassette based CP/M and so the transient area starts at 0100. Would the following code, loaded at 0100h be enough to pulse the IVC's CPU reset from the CPU Board?

Re: Gemini 80-Bus System
 

No the port b3 is in io space. You need to do an in a,0b3h to do the reset.

also out (0b3),a will also work as a reset.

Re: Gemini 80-Bus System
 

OK, thanks, time to get my Rodney ZAKs books out I think...