My Klyball 600D build

[ronin47]

So with it being difficult to describe what I'm currently seeing, I thought it best to provide a video:


https://www.youtube.com/shorts/r9WOA8zI3Sw


Incidentally it also does this on my 5" B&W TV.

The two images also sort of hint at it as you can see the image is flickering meaning a photo captures just a part of the screen:

IMG20240326195219.jpg (5.17 MiB) Viewed 256 times

IMG20240326195132.jpg (3.45 MiB) Viewed 256 times

I have been round every key switch and tested with a multimeter and none appear stuck, however if I hold down each key singly, the screen becomes normal with one exception - REPEAT.

I presume the function is to cause auto repeat of the keys when held down in combination? I have changed the switch, but no different, the same when its removed. However when I hold keys down they do repeat without the need to hold down the REPEAT key.

I am convinced this is a keyboard issue, though what I do find odd is that REPEAT does share rows and columns with other keys that work OK.

I think next I should check all the pull ups for the rows and columns. Any other ideas welcomed.

EDIT: I did find a bad diode, but it didn't help when I replaced it.

[Mark]

What you are seeing is the momentary blanking that occurs whenever the CPU access video memory. When accessed continuously, the screen shimmers like that. Normally that only occurs during screen scrolls or constant video access and stops when the scrolling/access ends.

The keyboard decoder code doesn't process repeat at all, but it is on the same row as ctrl esc and the shift keys which are applied to the decoded key. Holding down a regular key will start autorepeat.

But what I think you're seeing has to do with the keyboard/video selection circuit. It seems that accessing the keyboard also causes the screen to blank.
Could there be a short between /RVE /RKB or /WVE /WKB or a bad 74LS138 U20?

There was some discussion about something similar to this here (Maybe not an issue with Rev D boards).
viewtopic.php?f=3&t=793&p=4831&hilit=blanking#p4831

If you can enter the monitor, try typing the following .0300/4C<return>00<return>.0300G That will prevent all KB & screen access.
<RESET> to exit.

Next try
.0300/20<ret>00<ret>FD<ret>4C<ret>00<ret>03.0300G That will poll (R/W) the keyboard continuously.

Isolate to read or write access
.0300/AD<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will read the keyboard continuously

.0300/8D<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will write to the keyboard continuously

Finally
.0300/20<ret>00<ret>FD<ret>20<ret>2D<ret>BF<ret>4C<ret>00<ret>03.0300G That will scan the keyboard & send keys to screen.

Good Luck!

[ronin47]

What you are seeing is the momentary blanking that occurs whenever the CPU access video memory. When accessed continuously, the screen shimmers like that. Normally that only occurs during screen scrolls or constant video access and stops when the scrolling/access ends.

The keyboard decoder code doesn't process repeat at all, but it is on the same row as ctrl esc and the shift keys which are applied to the decoded key. Holding down a regular key will start autorepeat.

But what I think you're seeing has to do with the keyboard/video selection circuit. It seems that accessing the keyboard also causes the screen to blank.
Could there be a short between /RVE /RKB or /WVE /WKB or a bad 74LS138 U20?

There was some discussion about something similar to this here (Maybe not an issue with Rev D boards).
viewtopic.php?f=3&t=793&p=4831&hilit=blanking#p4831

If you can enter the monitor, try typing the following .0300/4C<return>00<return>.0300G That will prevent all KB & screen access.
<RESET> to exit.

Next try
.0300/20<ret>00<ret>FD<ret>4C<ret>00<ret>03.0300G That will poll (R/W) the keyboard continuously.

Isolate to read or write access
.0300/AD<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will read the keyboard continuously

.0300/8D<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will write to the keyboard continuously

Finally
.0300/20<ret>00<ret>FD<ret>20<ret>2D<ret>BF<ret>4C<ret>00<ret>03.0300G That will scan the keyboard & send keys to screen.

Good Luck!

Thanks Mark. I've already replaced U20 with a new IC and that brought the keyboard to life (I had a dead IC) and will re-check for shorts, but I will try your suggestions with the monitor tomorrow and let you know how I get on.

I did also check the line at U2,3,4 & 5 to see what the voltage were to be sure the pull ups were working. Most were around 4.8v but some were around 2.5v-3.4v. Low but still effectively a high in TTL land.

BTW if I remove U5, the keyboard obviously won't work, but the flickering goes away.

Cheers

Jon

[ronin47]

If you can enter the monitor, try typing the following .0300/4C<return>00<return>.0300G That will prevent all KB & screen access.
<RESET> to exit.

Next try
.0300/20<ret>00<ret>FD<ret>4C<ret>00<ret>03.0300G That will poll (R/W) the keyboard continuously.

Isolate to read or write access
.0300/AD<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will read the keyboard continuously

.0300/8D<ret>00<ret>DF<ret>4C<ret>00<ret>03.0300G That will write to the keyboard continuously

Finally
.0300/20<ret>00<ret>FD<ret>20<ret>2D<ret>BF<ret>4C<ret>00<ret>03.0300G That will scan the keyboard & send keys to screen.

Good Luck!

Hey Mark, with respect to the 5 tests above the results are as follows:

Test 1 - The shimmering stops completely.
Test 2 - No difference, the shimmering continues.
Test 3 - No difference, the shimmering continues.
Test 4 - No difference, the shimmering continues.
Test 5 - Keyboard input is sent to screen, but the shimmering continues.

If nothing else, it's taught me how to drive the Monitor a little!!!

I'm not sure what these results mean so any insight you might have would be very helpful. I've come so far it would be a shame to fall at the last hurdle!

I've built many projects, but this one is proving the most difficult to finish successfully.

Since U20 is a brand new tested replacement BTW. What other components form part of the keyboard/video selection circuit?

Not sure if it makes a difference but the RAM I have is 100ns.

Many thanks

Jon

[Mark]

So it really is any access to the keyboard @DFxx causes the screen to act as though you are accessing video RAM. D000 - D7FF

I can't explain how removing U5 stops the problem though, unless there is some sort of short. And why not U4?

When accessing the video RAM, the 8T28's that switch between the video address lines and the CPU address line are activated via U15
U21 U79 U56, but U20 is the common denominator

Hmmm maybe U23 ('138) is bad causing the /V line to be active? No clue, I'll have to think about this...

Schematics at https://osiweb.org/manuals/C1P_sams_jf_600dpi.pdf
and https://osiweb.org/manuals/600revD.pdf

[ronin47]

So it really is any access to the keyboard @DFxx causes the screen to act as though you are accessing video RAM. D000 - D7FF

I can't explain how removing U5 stops the problem though, unless there is some sort of short. And why not U4?

When accessing the video RAM, the 8T28's that switch between the video address lines and the CPU address line are activated via U15
U21 U79 U56, but U20 is the common denominator

Hmmm maybe U23 ('138) is bad causing the /V line to be active? No clue, I'll have to think about this...

Schematics at https://osiweb.org/manuals/C1P_sams_jf_600dpi.pdf
and https://osiweb.org/manuals/600revD.pdf

Thanks Mark.

So just to reiterate, when I boot I get the fuzzy screen and pressing a key causes the screen to behave normally.

If I remove U5 the fuzziness disappears, but obviously the keyboard doesn't function.

If I remove U2, U3 or U4 the problem remains, though again the keyboard is non functional.

Removing U6 & U7 (the 8T28s) also makes no difference. I also swapped them with U24 and U25 and no change.

Am I right in thinking U6 and U7 are only used for the 610 though? Even so swapping them with U24/U25 made no difference.

I have checked the WKB and RKB signals at the IC's that use them (U2 & U3 and U4 & U5 respectively) and they look normal and react when keys are pressed.

I have also looked at the inputs on U2/3/4/3 and there was nothing that looked odd, similarly the outputs looked fine, which suggests no key is actually stuck down, and I can say for certain that keys are all fine having tested with a multimeter.

Very weird.

I have replaced U20 thru U23 with new tested ICs, no change either.

One last thing, I noticed that in BASIC, if I turned off shift lock, holding down the L&R shift buttons gave odd results, for example it didn't always give a shifted character, sometimes it gave a different character. For example, if I turned shift lock off, and held down left shift and Z, I got a lowercase j instead of an upper case Z but right shift & Z worked as expected. I saw this sort of thing for multiple keys.

I'll go back and check for shorts but I'm confident it's clear.
Not sure if that is OSI weirdness though as with shift lock on, shift + other keys seems to work as expected.

Thanks

Jon

[Mark]

Upon RESET, the OSI is accessing the keyboard continuously, so due to your problem the fuzziness is expected.

The different behavior of the shift keys without shift-lock is normal for OSI. I don't think there is a problem with the keyboard per se, although I can't explain U5 behavior.
Yeah, U6 and U7 are only needed for expansion.

V is generated from the 3 upper address bits and is active for C000-DFFF.
It's then used to further break down the address space of DXXX into 1K chunks with U20

Next question is does it involve all of the address space that V decodes? Here are some test to try:

.0300/AD<ret>00<ret>D7<ret>4C<ret>00<ret>03.0300G - Read D700 continuously.

.0300/AD<ret>00<ret>D8<ret>4C<ret>00<ret>03.0300G - Read D800 continuously.
(Or just change the value at 0302 from the 1st test with .0302/D8.0300G )

.0300/AD<ret>00<ret>DC<ret>4C<ret>00<ret>03.0300G - Read DC00 continuously.
(Or just change the value at 0302 from the last test with .0302/DC.0300G )

.0300/AD<ret>00<ret>C0<ret>4C<ret>00<ret>03.0300G - Read C000 continuously.
(Or just change the value at 0302 from the last test with .0302/C0.0300G )

Have you tested U56 74LS20 which generates the VA signal on pin6? Perhaps a connection between pin 4 & pin 6 or maybe it's bad?
Is pin2 of U56 connected to +5 or /A10 (pin8 of U21 7404 ?)
Could VA be bridged/shorted somewhere?

[ronin47]

Thanks so much for this Mark, I'll work through it and get back to you on what I find.

I'll get all the ICs checked out too.

I very much appreciate the help here.

Regards

Jon

[ronin47]

OK, so it's fixed.

IMG20240328134336.jpg (5.06 MiB) Viewed 196 times

The solution? I replaced the 74LS04 at U21 with a 74S04.

According to the build doc I have it should be an an LS, but as soon as I swapped it out, the problem went away. I then looked at other schematics and BoMs and all state an LS04.

I tried a bunch of LS04's and the results were always the same, fuzzy screen.

Any thoughts Mark? I can only assume it's a timing issue when using the LS04.

Regards

Jon

[Mark]

Well that's great that you have it working!

I wonder if it was the speed or drive current (or both) that fixed it? Perhaps it's a side effect of using 100ns RAM?
Hopefully this will help someone in the future that runs into a similar problem.
Good Job!