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 |
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 I then programmed up a rom to test the dot clock e.g. Code:
ld hl, 0xc000 ; status write 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) |
Re: Gemini 80-Bus System
Code:
0100 db b3 loop: in a, (0xb3) Neal. |
Re: Gemini 80-Bus System
Thanks, I will try it tomorrow.
|
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. |
Re: Gemini 80-Bus System
Good idea!
|
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? |
Re: Gemini 80-Bus System
Just for the record, this was the code compiled...
Code:
0100-DB B3 25 ( 11) loop: in a,(0b3h) Code:
S100 |
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 |
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:
|
Re: Gemini 80-Bus System
Yes, sorry. Autocorrect on my phone!
|
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? |
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?
|
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.
|
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 |
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. |
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. |
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 Code:
0000 ;; in ROM and executes from reset. |
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.
|
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.