Simply_Graham

Hi Simius I'll take at least one, may have to send back one of my original DVI version for re programming the resolution as well. ( I do have a working USB Blaster however so could do this if you are willing to release the POF's)

In regard 'Stressed' refering to the Q6 Transistor. not the low voltage levels

For Q6 the current,Voltage and Hfe specs arn't that stressed as it's used as a logic switch so hard on or off as 5V and very Low current. That of course is only for this specific use as Q6. And of course not to have failed (usually short circuit I've found)

OOPS Yes I was; even after I re read it So the sawtooth is in effect D7 via D14? I'm sorry I was misleading you . I guess you will see similar Data across all the Datalines so D0 to D6 should be fairly similar and back to your problems again. Although it may be worth lifting the top leg of D14 check the Bottom end D7 direct and the pad left only Q6 output assuming Pin 10 still lifted.

Thats Odd, Can you recheck U22 Pin 2 I expect the sawtooth, but why? Can you look as Pins's 1 Direction, Pin 19 /OE and pin 18 B1 the other side of the Buffer to Pin 2 (A1) As you can see this maybe affecting the D7 Dataline. You could also try bending out pin 19 and tying it to +5V to see if that stops the sawtooth as its active Low. All buffers to tri-state I think. It is tri state , Pin 1 Direction would also need to be Low for an output on Pin 2 so could also try tying this as well as /OE to +5V

I'll get out my scope and check what I'm getting, as that doent to me look right at all, I'd expect much cleaner negative going pulses on Pin 10, if the addresses in D1xx are called or a constant High when not. 1st Bend out pin 10 on U25 F138, check on the pin itself for the signal still a sawtooth or a bit cleaner, or hopefully just remains High and no pulses. 2nd if pulses seen go back through U26 enable circuit, Pin 4 of U25, F138, if seeing pulses (going Low) also check Pin 2 U26 for the same. 3rd again if seeing pulses power off and remove U11 another F138, and bend out pin 14, for completeness jumoer to the U11 pin 14 socket +5V, and place U11 back in making sure 14 not shorted to jumper. With all other chips back to normal back to pin 10 on U25, F138 , bend out pin 10 if need be but at this point it should remain at a constant High and never go low as you've tied the D1xx signal from U11 high. if your seeing anything other than a constant High, if Pin 10 still inserted on U25, bend out and re-check , and check for a backfeed towards the socket, easier to check top of D14 (the banded end) anything?

Hi Chevymad a Belated Happy Birthday I guess we could turn this on its head a little, so far the general rule has been to remove a chip to swap, change a pin status by leaving out of socket, and jumpering high or low, or drastically unsoldering the item's D14 & Q6 as an example. Maybe One of the way's I've approached trouble shooting in the past may help; this was to start with items removed, and gradually add them back in to circuit, checking in your case Keyboard, Cartridge & SIO as you go along. There are of course dangers in this as we are 'touching' the chips yet again I'm sure Mytek can drop in on this one and may concider the checks already done good enough, however looking through the schematic I think I'd remove the following, and why U23 F08 3 gates used to buffer CF connector address lines + 1 gate for Addressing U25 U26 F32 1 gate enables U25 ,another buffers /CS0 to the CF Skt ,another the /RESET Line to CF Skt, the last to buffer the red LED U25 F138 This will stop any interaction on its outputs. U22 F245 Removes any loading on D0-D7 due to incorrect enablement of Direction or /Output Enable U24 HCT00 Swap Latch Green LED Buffer and Logic from /DASP on CF socket. At this point is everything working or not, as only D14 & Q6 could have an effect on the rest of the computer by interfering with D6 or D7 There should be no interaction between D6 & D7 and in effect we have two back to back diodes in D14 & Q6 however we need to make sure Q6 doesn't turn on so need to ground the 'base' suggest using socket for U24 and adding a jumper link from Pin 7 Ground to either pin 3 or 4 I'm hoping you can add back the chips in the following order U23 Should be no difference but still need checking U26 Again no difference to operation but red LED maybe a bit crazy U25 This will now enable any of the read/writes at D1xx. This is a good time to check the outputs on Pin 7,9,10,& 11 with your scope they should all remain high (but you should be able to detect any negative pulses to ground which should not be happening...) U22 should be no change and everything works as normal. Last is U24 I think for now with pins 3 & 4 missing out allowing Q6 base to remain at ground (another ground point needed) Somewhere during this I'm hoping something should hopefully break and give us the answer to the issue. You may want to concider what you have done previously and only pick bitss out of this. One think I thought of; the voltage reading you get on Pin 10 of the F138, being lower, this could be a result of the F138 pin 10 going low. if you thing about it if it was Low for 25% of the time and High 75% the the voltage average would maybe about 3/4 of the supply voltage 3.75 V assuming 5V that why a scope is so much use in these circumstances.

Lots have been happening whilst I've been slaving away on a new garden shed. As Mytek stated, issue with [D1xx] line driving Low (enabling U25 via U26) when it should not; this is pin 14 of U11 that feeds into U26 of pins 2, 4 & 5 Please re-check if Pin 2 (or 4, 5) ever goes low with U26 removed (With your new scope whilst computer is on) D1xx only accessed by PBI BIOS as far as I'm aware (confirmation would be good here) so make sure PBI disabled in U1MB setup. If it ever goes Low (possible 74LS138/ U11 fault) or if its permanently Low with power disconnected pull U11 and check if pin 14 on U11 is short to ground or maybe with adjacent pin 13 (Pokey select thinking issues with SIO, Keyboard etc.) With a multimeter, leaving out U26 as well as this should isolate that track. Assuming something is found or not it's another part or track that's eliminated, but as Mytek mentioned there appears more than one issue. Has pulling all U22 to U26 been tried? Only issue would be D14 and Q6 state (as base floating) with all chips removed. I'll always agree with you on good test equipment!

It's great that your gradually working this through, just as a reminder that all bar the 40 Pin sockets and RN2 have been reused from the original board that exibited exactly the same symptoms. With that in mind I would think it unlikely to be a soldering issue, more like a component that is common to both builds that doing exactly the same again as it did in the previous board. One thing came to mind which may excluded a dodgy socket, when transfering over components, did the sockets get removed one at a time and soldered in the same place on the new board, or did you removal all sockets then reuse in any order. depending on what you did may eliminate the actual sockets themselves, and push towards a component. if it was a one out, reuse in same place then it could still be a dodgy socket. U11 Pin 14 is worth checking if this is permanently low, that would select the D1xx range, also U26 Pin 3, outputs to U25. Both D1xx (U26 Pin 2) and Address line 3 (U26 Pin 1) need to be LOW to enable the U25 Pin 4 (also LOW when enabled) These may have already been eliminated by test you have carried out prior. I guess checking if either one of Q6 or D14 being replaced may be the next move with D14 replaced does it fail, or only with Q6?

The only lines that connect directly to the Pokey & 74F138 are the buffered Phi 2 and the read/write line. Pokey 74F138 B02 7 6 R/W 32 1 Well its great that removing the 74F138 has allowed Keyboard and SIO to work, If the chip is faulty across either of these two lines, it would likely have caused problems or non booting so unlikely to be that. Looking at what else the 74F138 could effect :- Data line D7 I guess could be effected via pin 10 on the F138, via Q6 and a bunch of other logic controlling Q6 or Data line D6 Via D14 It was mentioned earlier in this post that D7 gives the effect of the control characters. If you use a 74HCT138 as a temp. solution, see if this screws up the SIO / keyboard the same as the 74F138, no Harm can come from this but it may push you to look at what else the 74F138 is connected too for the fault, if not the chip itself.

Sorry seems I mis-led you, Firstly I didn't read Chevymad's post properly , compounded by misinterpreting what I'd read. I was going by the 400/800 Hardware Manual . Page II-25 onwards and took this to be true of any data transfer. Perhaps I should have read on a bit longer ! "Transmitted data changes when the output clock goes true. Received data is sampled when the input clock goes to zero." I assumed 'true' was 'High' and 'Zero' was a 'Low' hence why they pulled up the CLK-IN line to a 'High' Re Running the board without the RN2 in place, As the circuit is entirely digital in nature, then no damage should occur, none of the lines affect the rest of the machine working, only the SIO would potentially fail. Although I'm sure someone won't agree

It's good that you were able to save all the components and reuse them, also gave you a chance to recheck any values as you went along, glad you like your new eyeball enhancers , Always nice to see what you’re doing properly. The RN2 Pin two pulls the CLK-IN line High, it's obviously there for a reason, I'd guess to make sure the Negative pulses on the clock line are clean; it is responsible for gating the DATA-IN line with the correct timing, so could corrupt the SIO towards the Pokey. It would be difficult to say for sure what effect this has without replicating. However it is the most likely cause you have found. I guess you can see what happens with your new board, with RN2 missing its unlikely the SIO will function, as none of the lines are pulled High, but the rest of the XLD should be just fine. Hope you get the other bits soon.

It was only a thought as you had mentioned the Keyboard programming was to be such a pain, I assumed getting to talk PS/2, which you have already sorted, And I agree if it make no sence unless it made it a LOT easier to implement. (and clearly not the case) Be nice to see the result, and I like the capacitive touch sensors.

Hi Michael Just a thought, as the programming in the XEGS keyboard CPU to convert to PS/2 would be a fairly complex; Would it make it easier to program a matching Pair of processors, a replacement for the TK II that matched a simpler Keyboard protocol, I do of course appreciate the only way to swap to using a PS/2 key board is to then swap the TK II chip, as I say just a thought.

It's just not fair, we all are getting older (58 in my case) along with our eyesight deteriating, and then they reduce the size of components even more !! Surface mount components seem to be getting ever smaller, but even through-hole components can be small and fiddly, 1/8w resistors, 1N914's I bought an Andonstar AD207 electronic microscope as a Christmas present to myself; which has it's own screen and a stand with two flexiable led lamps. Hand cordination with a fixed screen is a little odd and takes some getting used too, but does allow me to solder surface mount chips a tad easier, and more importantly a good inspection of any board after soldering. https://www.aliexpress.com/item/4000251219592.html Good luck with the repairs and fault finding

Upper picture shows /XE/XL =ON Lower picture shows XEGS/L =ON So who knows, screen corrupt.

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

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

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.

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.

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.

Hi Michael 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.

Apparently I took to long editing my previous post .. Agree, Only one clock in a NTSC computer so should be no issue as seeing a screen, wouldn't if clock incorrect as timing for video would be off. Trying a Cart a good idea !! Also realised you mentioned RN4 earlier, it is critical this is the correct way round, as pulls high both /IRQ & /NMI among others high. this WILL affect both SIO & Keyboardd Reads among other things. I've removed the SRAM from mine and taken a shot of the two Resistor networks, RN4 to the right of the picture, as you can see the information is hidden toward the CPU, I'd guessing that you should have the same. If you remove a whole bunchof chips You can isolate the RN4 resistor pack. need to remove CPU U9, 74F08 U12, ANTIC U7, Left Pokey U18, PIA U14 and finally the U1MB module. Right Pokey eliminated as /IRQ goes via Q5, so no connection. You should then test from a +5V rail to the CPU sockets pins 40, 39, 2, 4, 6, and on each see 3K3 or 3.3K ohms Between any two of these CPU pins 6K6 as goes to the 5V rail and back, seeing two of the resistors in series. Some but not all resistor networks can be checked in a similar way. see what the pins are connected too go through the Circuit diagram linking up all the labels. RN5 for instance requires every chip that uses the Data Lines D0-D7 to be removed to check. I hope this is of some help, and I'm not teaching you to suck eggs. As My XLD is only dropped into the case bottom, happy to supply photo's of each Resistor Network if it will help you, depends on the supplier as to how they are printed up.

Well your reducing what can be wrong so, although a bit of a slog, all the Pokeys & PIC have now been tested and known to work. the PS/2 lines to the I/O level 1 board must be good, so I think ignore them for now as Alt-F1, Alt-F2, etc. appears to work, only the K & KR lines on the left pokey not reading the TK II Chip correctly, that and the SIO I think maybe a common issue. You could try checking the lines for the K0-K5 & KR1,KR2 lines they are only connected to the Left Pokey & TK II, but not sure its a worthwhile check now. I'll check what happens during SIO, and Keyboard read/scan, and edit later on. Just realised you mentioned RN4 earlier, it is critical this is the correct way round, as pulls high both /IRQ & /NMI among others high. this WILL affect both SIO & Keyborad Reads among other things.

Hi Cheveymad I like Myteks route of checking the TK II by using it's output to the Left Pokey however if the Serial part from keyboard is playing up may not 'see the ALT, F!,F2 etrc Although you may have several faults on the XLD, certainly two maybe three at the moment I think it best to check the chips in the XLD one at a time in the known working XEL as eliminates all the components or dry joints / shorts on the XLD. Depending on what you may have found already, suggest TK II PIC, then each of the Pokey's checking Keyboard responce as well as SIO. if both Pokey's (check both in the Left Socket on XEL) work fine and still no SIO on XLD, check the PIA chip from the XLD in the XEL. Added a capture to help follow the TK II connections (highlighted). P.S I started this post last night (UK time so Dr Venkmen and Mytek have added posts that will hopefully have helped already, did adjust what I started .