1088XLD - Custom A8 Computer in 1050 Drive Case

[+DrVenkman]

1 hour ago, Simply_Graham said:

I dont think its the lines between as they are unlikely to be intermittant

Clearly you've never had a bad or damaged socket in one of your systems, or a cold solder joint.

[+mytek]

3 hours ago, Simply_Graham said:

I think both the Pokey's and the PIC have been swapped (and reprogrammed) and tested in an XEL and all proved fine. I dont think its the lines between as they are unlikely to be intermittant so I'm thinking there is a problem more with the Control lines of the Pokey something like the /IRQ line not being as it should. or maybe the address lines flacky going to the Left Pokey and reading the wrong registers when interupted to read the keyboard values. This would also cause issues with SIO, although PIA has control lines for SIO, that wouldn't cause the issue with keyboard read unless two faults.

So let's review a few things...

1. Both Pokey and the PIC that's being used for the TK-II has been swapped.
2. Solder points between those two chips has been checked.
3. I'm assuming that consistent responses are being seen when pressing combination key presses (ALT+F1, ALT+F2, ALT+INSERT).
4. Random garbled characters are seen from individual key presses or when TK prints config settings (ALT+F2).

As I mentioned in my previous post, there definitely looks to be a Pokey/TK-II sync problem, with a remote possibility of an intermittent connection.

 

Based on these parameters there remains a strong possibility that at least one signal path between the PIC and Pokey is not connected. As to what that is, it could be a broken trace, a bad via, or a bad socket as DrV suggested. Best course of action is to do a continuity check of all interconnections between these two chips going directly from the individual chip leads.

 

I'm  not rulling out a Pokey IRQ problem, although that would also affect other aspects besides the keyboard.

 

[Simply_Graham]

It could be either, I think the likely hood of it being those is a little lower that something affecting the way that the Left Pokey is operating over-all, taking into account the SIO not working along with the Keyboard random character generator.

RN4 especially as its the pull up for several of the Interupt lines.

I'm sure Cheverymad will go over all the connections with a soldering iron just to make sure.

 

Sorry typeing up Whilst Mytek replied . crossed over.

 

 

Edited April 24, 2020 by Simply_Graham

[Simply_Graham]

On 4/22/2020 at 5:22 AM, chevymad said:

Swapped pokeys and reprogrammed all pics. Will have to take apart XEL to do anymore swapping. The blue border on the ultimate screen flashes. The basic screen I typed the alphabet several times. Comes out different every time.

Hmm looking at the three typed lines. there is consistency with 'A' appearing twice with the same incorrect character Ditto J, K, and maybe U.

Checking Keyboard cross connects there dosen't appear to be any correlation , but of course I'm not taking into account the 4051's used before feeding the Pokey Lines.

[+DrVenkman]

28 minutes ago, Simply_Graham said:

but of course I'm not taking into account the 4051's used before feeding the Pokey Lines.

Those don't exist in the 1088 models. The PS/2 keyboard clock and data lines feed into the TK-II chip, which provides the data directly to (left) POKEY. 

As Michael suggests, and assuming the same keyboard is okay, there's something going on between the TK-II and POKEY.

[_The Doctor__]

11 hours ago, DrVenkman said:

I don’t think he’ll get a picture at all if the crystals are messed up - they feed GTIA directly, which then provides ANTIC with a base clock signal, which then gives Phi0 to SALLY which is used to create Phi2 and Phi1. That’s why many vintage Atari machines fail to a red or green screen - the clock is oscillating, and so GTIA is producing a video signal and ANTIC is trying to start, but with no display list data on the bus to process. 

I don't want to see the crystals themselves, I wanted to see whats in the general area around the crystals to see orientation and values, hence the even if the crystal are not installed portion of that post...

[StickJock]

59 minutes ago, Simply_Graham said:

Hmm looking at the three typed lines. there is consistency with 'A' appearing twice with the same incorrect character Ditto J, K, and maybe U.

Checking Keyboard cross connects there dosen't appear to be any correlation , but of course I'm not taking into account the 4051's used before feeding the Pokey Lines.

A clue!

 

Looking a bit closer, the control characters being displayed for the "ABC" are not random, they are actually the control-A, control-B & control-C characters.  Likewise for the J being replaced with a control-J.

 

So, at a guess, maybe the POKEY thinks that the TK-II is reporting the control key as being pressed?  Could be a pull-up issue?  Check the signal going to KR2 on the Pokey.

 

 

[Simply_Graham]

I was aware that the XEL & XLD don't have 4051's, I have built both, however the TK II has to map what the original keyboard cross map would be to the K0-K5 and KR1 & KR2 lines. I was trying to see If I could co-relate the physical output of the original Keyboard, via the 4051's to come up with a possiable line thats suspect,i.e  one of the K or KR lines , however I'd not posted the outcome as I've yet to work out what the lines from the 4051, send to pokey for each of the key presses. Only worked out KR lines sort direction of data KR1 associated with K0,K1&K2 to read the keypress and KR2 with K3,K4&K5 scan a row or line not sure which attached 800XL circuit to show what I was trying to get at, the TK II in effect is replacing the two 4051's

i.e. The TK II strobes /KR2, K3,K4,K5  The TK II read output, checked PS/2 keyboard, and adjusts output on KR1 K0,K1,K3 to give correct keypress that match the keybord matrix of the original. although thats in it's most basic form. hence somewhere 'A' will be given by a particular combination of input and output lines  across KR1,KR2, K0-K5. identifying one that is common to A,J,K,U was my goal to help Chevymad. 

 

Hopefully something I'll do in the morning as it's a little late here.

Edited April 25, 2020 by Simply_Graham

[+DrVenkman]

Posting 800XL schematics and a wall of text is not really helpful for troubleshooting here. There are no components in-line between the TK-II chip and the left POKEY keyboard lines. If the TK-II chip is good, and the keyboard is good, then you're down to basic continuity somewhere between the PS/2 keyboard jack, the TK-II and/or the left POKEY. 

 

 

[Simply_Graham]

If you say so. Thought it would have been useful to identify what line is likely the culprit.

[chevymad]

Tested continuity from the pins on pokey chip to pins on TKII chip. Everything looks good. Checked continuity from TKII to keyboard jack on IO board and also good. Removed chips and tested RN4. Also good. All RN's look to be in the correct orientation. Swapped U1MB, no difference. Noticed L1 seemed to have a chip out of it, so removed from board(assuming this is PAL only?). No change. Tried Star Raiders, black screen no sound, no action. As was noticed above, the characters aren't random when typing, they're control/atascII characters. Like the control key is being pushed. Type the same letter 5x and sometimes it will be the control character, sometimes the alpha. Also noticed that when left on a couple of minutes, the power LED will change from yellow to straight red.

Edited April 25, 2020 by chevymad

[AtariGeezer]

1 hour ago, chevymad said:

Tested continuity from the pins on pokey chip to pins on TKII chip. Everything looks good. Checked continuity from TKII to keyboard jack on IO board and also good. Removed chips and tested RN4. Also good. All RN's look to be in the correct orientation. Swapped U1MB, no difference. Noticed L1 seemed to have a chip out of it, so removed from board(assuming this is PAL only?). No change. Tried Star Raiders, black screen no sound, no action. As was noticed above, the characters aren't random when typing, they're control/atascII characters. Like the control key is being pushed. Type the same letter 5x and sometimes it will be the control character, sometimes the alpha. Also noticed that when left on a couple of minutes, the power LED will change from yellow to straight red.

Have you removed all chips and checked for shorts from adjacent pins on each IC Socket?

(1-2, 2-3, 3-4, etc...)

[+mytek]

1 hour ago, AtariGeezer said:

As was noticed above, the characters aren't random when typing, they're control/atascII characters. Like the control key is being pushed. Type the same letter 5x and sometimes it will be the control character, sometimes the alpha.

Ok based on this observation which I initially missed, I just thought of one other possibility that's worth checking.

 

From the TK-II Online Manual...

Quote

XEGS/XEL/XLD Mode (7800 XM included)
When the TK-II was originally developed, it wasn't known at the time that certain motherboards were missing the pull-up resistors associated with the key response (KR) inputs of the Pokey chip. Without these resistors, ghost key presses are possible. Normally this isn't a problem if the stock keyboard is still attached, but this would not be the case for the XEGS version. So in order to correct this, a mode was created that would change from a floating output for the KR lines coming from the TK-II, into something more like a TTL output that had both a high and a low output state. Since the first system encountered that needed this fix was an XEGS, this was the reason it initially got called the XEGS Mode.
 

Note: If the stock keyboard is to be used in parallel with the TK-II, then the XEGS Mode should be set to OFF. This feature is toggled by pressing CTRL+ALT+X, with the last setting retained in non-volatile memory.

Later on it was discovered that a 1200XL without it's stock keyboard attached was also missing the KR pull-up resistors for Pokey. So if you plan on using the TK-II on your 1200XL without it's stock keyboard, you should toggle this feature ON (CTRL+ALT+X toggles it).

When the 1088XEL and the much newer 1088XLD were being developed, this mode was also employed to simplify the design and minimize the component count.

So in other words you want the XEGS Mode = ON with your 1088XEL or XLD.

 

----------

 

AtariGeezer's suggestions to look for shorts between pins is also valid.

 

----------

 

2 hours ago, chevymad said:

Noticed L1 seemed to have a chip out of it, so removed from board(assuming this is PAL only?).

Yes that is part of the PAL color burst circuit and not required for your situation.

 

2 hours ago, chevymad said:

Also noticed that when left on a couple of minutes, the power LED will change from yellow to straight red.

This is normal if you have no CF to IDE adapter plugged into the IDE port.

 

1 hour ago, AtariGeezer said:

Tried Star Raiders, black screen no sound, no action.

Have you tried loading something from an SIO2PC or from a CF card? I'm thinking NO on that last one, because you probably don't have the adapter presently in use. Anyway I'm curious if you've tried something other than a cartridge to see if there are more or similar problems to what you are seeing with Star raiders not booting up.

 

Here's an ATR of Star Raiders to test either through SIO2PC or from a CF card: Star Raiders.atr

 

 

EDIT: Just noticed that I accidentally did a quote from within a quote which I can no longer edit, so all the quotes should actually be saying 'chevymad said:' instead of 'AtariGeezer said:' .

 

[Simply_Graham]

12 hours ago, StickJock said:

A clue!

 

Looking a bit closer, the control characters being displayed for the "ABC" are not random, they are actually the control-A, control-B & control-C characters.  Likewise for the J being replaced with a control-J.

 

So, at a guess, maybe the POKEY thinks that the TK-II is reporting the control key as being pressed?  Could be a pull-up issue?  Check the signal going to KR2 on the Pokey.

 

 

CTRL on keyboard on original matrix connect via a 430 ohm resistor to pull /KR2 low.  The cross connecting line is shown as 5 on the matrix and corisponds to K3,4&5 all being High. (output 7 on the connected 4051) so this would be the same on the TK II PIC  re check line K3,4,5 and /KR2 . check for shorts between /KR2 and +5v or any of the K lines.

Nice one StickJock,  something to check

[StickJock]

As an aside, I think that Atari really blew it when they laid out their keyboard matrix.

 

There are enough empty intersections in the matrix that they could have had the SHIFT key on it's own row.  This would have allowed for all single keys to work with SHIFT+CONTROL.  As laid out, you get ambiguity with the letters that share the rows, so those don't work.

 

Granted, this issue would have popped back up with the addition of the F1-4 keys on the 1200XL, but even that would only put two keys on the row, so four keys total could not be SHIFT+CONTROL'd.  Even then, they could have mitigated it if they had arranged the matrix so that the SHIFT row was empty and the remaining unused intersections are on the CONTROL row, then when they designed the 1200XL they could put the HELP, F1 & F2 keys on the CONTROL ROW, and then F3 & F4 keys on the SHIFT row in the same columns as the F1 & F2 keys.  That way, only the Fx keys could not be SHIFT+CONTROL'd.

 

Sigh.  Missed opportunities.  

 

 

[+mytek]

17 hours ago, StickJock said:

A clue!

 

Looking a bit closer, the control characters being displayed for the "ABC" are not random, they are actually the control-A, control-B & control-C characters.  Likewise for the J being replaced with a control-J.

 

So, at a guess, maybe the POKEY thinks that the TK-II is reporting the control key as being pressed?  Could be a pull-up issue?  Check the signal going to KR2 on the Pokey.

Yes good observation, and further suggests that the TK-II is perhaps in the wrong mode (floating KR signals vs. TTL switching). Normally following flashing of the TK-II firmware, the default would be to treat these signal lines in a TTL manner, where both states (high and low) are actively asserted. When in the floating mode, only the low is actively asserted and thus is entirely dependent upon a 4.7 K pull-up resistor on the KR lines to be present.

 

So simple test would be to execute a CTRL+ALT+X to toggle the mode and then see if that corrects the problem that is being seen.

 

A little speculation with why the TTL mode (XEGS MODE = ON) might not have been defaulted to... this could happen if a PIC chip was reflashed over an earlier version where the EEPROM bit got set during use, either intentionally or inadvertently. This is after all a nonvolatile setting, and will be restored upon power-up.

 

Edit: just to add to that last part about the EEPROM. The PIC chip has 3 memory areas: Flash Program Memory, RAM, and EEPROM. So program memory is what you flash or re-flash and contains the TK-OS. The RAM is used for temporary storage of variables and in the case of the TK-II a portion of it gets used as a ring buffer for all the key presses coming in, so that they can be acted upon at a slower pace without dropping keys. The EEPROM is an electrically erasable and writeable area of memory that TK-II uses for storing key sequence macros and also configuration bits. If you are using a JOY2PIC to flash your PIC, the EEPROM bits are left untouched, and will remain the same as before the chip was re-flashed. If using something like the PICkit2 or 3, the EEPROM bits are normally cleared during the re-flash unless you checked a box saying not to erase the EEPROM.

 

[flashjazzcat]

4 minutes ago, StickJock said:

This would have allowed for all single keys to work with SHIFT+CONTROL

A good proportion of keys do work in conjunction with SHIFT+CONTROL, though, so it's hardly a dead loss.

 

[StickJock]

11 minutes ago, flashjazzcat said:

A good proportion of keys do work in conjunction with SHIFT+CONTROL, though, so it's hardly a dead loss.

 

True, but it would not have cost them anything but layout/routing time to have full functionality.  Still, they got quite a bit of functionality out of an 8x9 matrix.  Not too bad for a 40 year old design.  Modern keyboards use 8x16 or 8x20 matrices. 

[flashjazzcat]

Just now, StickJock said:

True, but it would not have cost them anything but layout/routing time to have full functionality.

Yeah: and some of the combos which don't work are potentially the most useful, like SHIFT+CTRL+LEFT/RIGHT ARROW.

 

[+mytek]

Just now, StickJock said:

True, but it would not have cost them anything but layout/routing time to have full functionality.  Still, they got quite a bit of functionality out of an 8x9 matrix.  Not too bad for a 40 year old design.  Modern keyboards use 8x16 or 8x20 matrices. 

The TK-II produces CTRL+SHIFT equivalents for ALL of the keys, so it gets around this limitation.

 

[StickJock]

2 minutes ago, mytek said:

The TK-II produces CTRL+SHIFT equivalents for ALL of the keys, so it gets around this limitation.

 

Sure, but if you write code to use them, people using their vintage systems can't access those functions.

[+mytek]

Just now, StickJock said:

Sure, but if you write code to use them, people using their vintage systems can't access those functions.

I never suggested that the extra CTRL+SHIFT combinations that are TK-II unique be depended upon. Was merely pointing out that they do exist, and can be utilized if so desired. But other ways to do the same thing should be provided. This is kinda similar to the 1200XL function key dilemma. However TLW does support those extra function keys without the detriment to non function key systems. It simply adds alternatives to moving the cursor around screen, which lends itself very well to the TK-II having mapped those keys to Home, End, Page-Up, and Page-Down. Similar usage has been baked into FJC's U1MB Setup and Loader screens.

 

[_The Doctor__]

I wouldn't say exactly, myBios does some pretty nice key combinations as do some other utilities.... and I'd add, it's not like we can't upgrade our Atari's as well... just add the device...

Edited April 25, 2020 by _The Doctor__

[Simply_Graham]

On 4/24/2020 at 5:32 AM, chevymad said:

 

Upper picture shows  /XE/XL   =ON

Lower picture shows XEGS/L    =ON

So who knows, screen corrupt. 

 

[chevymad]

Those might have been 2 seperate TKII chips too. Tried the toggle, no discernable change. Though with the corrupted settings printout, I doubted it was just keyboard input problems. Something deeper happening. I'll be heading to work to my borrow the scope before they close for the weekend. If anyone has hints what signals to look at with one that'd be appreciated. I did do some testing of the pokey lines and didnt find any shorted together yesterday. Also wondering if this should be moved to it's own thread now. Was initially hoping for a quick fix, but we're rapidly adding to Myteks build thread. Can a moderator move this out?