StickJock

Did you ever do some tests to make sure that all of your RAM is OK? I had a 16Kx1 RAM chip go out on one of my boards back in the early 80s. What I did to diagnose it at the time was to try them out one at a time, with no RAM in the last two slots. So, try to boot it with no drives to MEMOPAD as a 16K computer. Swap out the RAM board in the 1st slot to verify that they all work. If you find, as I did, that one doesn't work, then you can swap out the individual RAM chips with ones from another board until you find the bad one(s). I had a single bad chip, so I ordered two from Jameco way back then. More recently, a couple of years ago, on another 800, I had a similar issue and tracked it down & fixed it the same way. Amazingly, I was able to locate the spare 16Kx1 chip that I had ordered back in the 80s, that had gone through 5 moves!

The Atari drive is not using the index hole, whereas the Kryoflux is. The index hole is the small, round hole in the jacket near the hub. The disk itself has a single hole that will pass by the index hole in the jacket once per revolution. If you flip the disk over, the sensor will never see the light go through the hole, since the hole is no longer in the right place (it's on the other side of the read/write hole).

Necromancer. Bill Williams was a creative genius!

Did you try it out with the chips swapped? That will tell you right away if they are the issue (bad keys change) or if the issue is upstream, such as the kb (bad keys remain the same).

I've updated my spreadsheet to add the 800 & 800XL pin mappings. Interestingly, Atari moved one column from pin 9 to pin 19 on between the 1200XL and the 800XL, and then added pin 24 to replace the previous pin 19 mapping. Also, it is clear here that they preserved the pin mapping from the 800 to the 1200XL, just adding the console keys & LED. They probably did this in order to use existing 800 keyboards during development? Edit: I made this chart based off of various sources that I found online. I'm not home, so I am not able to verify the 800 & 800XL mappings that I added by testing them on my systems. If anyone finds an error, please let me know and I will update it.

So here is what you reported marked on the matrix in red. It looks like you have three columns out (no help key on 800), but the ESC is an outlier. You put a ? by it, so does that mean that you are not sure about it? I would suggest swapping the two 4051 chips as that is the easiest thing to do (they are socketed on the 800). If the missing keys move around on you, then you have your answer. If the behavior does not change, then it is likely the signal going to them, so maybe the KB cable or connector?

Were you checking for the key matrix row & columns or the physical rows & columns of the keys as they appear on the keyboard? Here's the key matrix (looks better in Excell, sorry): 1200XL Pin# 16 15 12 17 10 14 11 13 9 20 21 22 23 19 18 130XE Pin# 17 11 8 16 19 10 4 9 20 21 22 23 24 2 3 Scancode Row:Col 7 6 5 4 3 2 1 0 Start Select Option Reset LED Ground 6 18 7 A S G Caps D H F 1 13 6 > < 8 Del 7 0 9 Break 4 15 5 Q W T Tab Y E R 7 5 4 Inv / M N . Space , 2 14 3 1 2 5 Esc 6 3 4 8 6 2 Z X B F4 F3 C Help V Shift 3 12 1 = - I Ret U P O 5 7 0 * + K F2 F1 ; J L Ctrl Here's what it looks like in Excell: Edit: This table is arranged in the scan code order, so it looks different than the usual ones posted in pin ordering on the XL. But as such, it serves a dual purpose - the pin mapping to the keys as well as showing the 6-bit scan code for the keys (in octal, but you can't have everything!).

It looks to me like one of the green wires is soldered to the top of that resistor. As for the SIO port, those are capacitors, not resistors. The clipped one may be to allow for higher speeds.

Both ends should definitely be connected.

The color on the label may be closer to the original than the color on the plastic On the 130 pictured, the label color appears to match the plastic better than the label on the ST.

I recall making some sort of audio capture device back in the 80s. I'm sure I've still got it somewhere. It was a pretty simple circuit, and I plugged a microphone into it and it into the joystick port. I don't remember at the moment if it used the paddle or stick input, but I remember writing a tight loop to read it (don't recall if it was in Basic or Assembly), and I think that I had to add delays to the playback loop to get it to have it play back at the same speed. It may have played back using the internal console speaker, so maybe it was the stick (or even button?) digital input. I probably got the design from a magazine (Byte, Antic or Analog would be good candidates).

Do any of the things that you have tried change the behavior? For example, the "working" keys move to different keys, or they report a different result? One of the things that you can do is to remove the KB, and then short the row & column pins on the keyboard connector in order to get different keys. If this works, then the problem is "upstream", likely the keyboard mylar or cable. Here is the keyboard matrix. Shorting, for example, pins 1 & 10 together should report that the '7' key is pressed. If you can't get any keys reported in this manner, check that you have good conductivity from connector to socket/pins, etc.

Done.

Darn it! I missed the last one (which, from all accounts, absolutely rocked!), and I can't make that weekend. Oh well, hopefully the next one will align better with my schedule....

You may want to clean off the corrosion on that one cartridge port pin....

That's a nice idea. I suspect that it would require the board to be changed for the footprint of the encoder. Or, you could find a spot in the case with enough room, drill a hole & glue the encoder in place, and then connect it to the pins on the existing PCB with wires.

Yeah, that's how mine behaves as well. It appears to be normal.

Atari of Theseus? Atareseus?

I'd be down for some discount kebabs, but shipping kills the deal! ?

Unless whatever is at $859E is depending on the value of A or the flags, you can save a couple of bytes here by replacing the LDA $01 STA $e965 instruction pair at $E972 with a single INC $E965 since the previous two instructions (LDA $E965 BNE $E97F) mean that both A and $E965 must be 0 at this point. The LDA + STA take 6 cycles, the same as the INC, so there is no CPU time savings, but hey, two bytes is two bytes! Again, this optimization depends upon whatever is at the destination of the JMP $859E. If it does not rely on A or the flags, then this is a safe code change.

Atari 810 & 1050 floppy drives should be set to 288 RPM.

This reminds me of a bug I had back in the 80s, where I had an INY instead of an INX. Or maybe it was the other way around. It took me forever to find it. As I was reading the code, over & over, I kept reading the INY as an INX, since that is what I meant to use. So even though it said INY on the screen, my brain kept interpreting it as an INX! When I finally realized my error, I felt like such a fool. The lesson, and one that carried over into my professional career later, is that one should always have someone else review your code! You know what you mean to do, so it is easy to overlook typos like this. The "eyeball pressure" of multiple people looking at the code causes the bugs to pop right out!