Krenath

1. Soldered in the rotary switch with the 0 facing the front edge of the board as shown. Thanks! 2. Moved my main crystal to the top two holes as pictured. I am curious, however: On the 1221 board, there are four holes rather than three in that area. If I move it to the top two holes instead of the middle and bottom hole, it appears that it ends up connected to the same traces on the back side, as the top hole and bottom hole are connected together: Please pardon the dirty board. I haven't cleaned off all the spattered rosin flux (and cat hair that sticks to it. yuck.) yet. 3. Working on removing the extra PAL components currently. 4. Thanks! When would that connector be used? Is it intended to be something like one of these? https://www.mouser.com/ProductDetail/Wurth-Elektronik/61201021621?qs=W%2B2sBeLta1a0dwX5pxbfXw%3D%3D&mgh=1&gclid=CjwKCAjwmqKJBhAWEiwAMvGt6EOFUq3Qi1xXUks9JieGirrPp_6bLTFBht4QQiMdvIe5XzPkYnGDnxoCh4YQAvD_BwE

Don't know if it's any kind of a clue, but those garbled shapes are the bit patterns for consecutive numbers. Wherever it's getting its character data from right now is just a bunch of 0 1 2 3 4 5 6 7 8 9 A B C D E F...etcetera

I've been idle for a while and just started working on my 130XE remake board. Here's my progress so far: Mine's a 1221 board so I feel a little like I might be missing out a little on the ability to use larger ROMs in the BASIC slot. And I don't have the convenient A5 pin, though I haven't noticed much else different. I had a nice time desoldering the entire J4 A/B assembly from my donor 130XE without damaging it. I noticed the right-angle cartridge connectors I had ordered didn't let the cart seat deeply enough once installed in the board, so they came out and the original entire J4 assembly went in. This one will be an NTSC board. I do realize that there are too many components installed in the PAL area. (I was in "Solder by numbers" mode when I was installing things, and was just putting everything in the holes labelled for them. The components that aren't needed for NTSC will be removed later.) It will eventually have Sophia 2 installed. The cable connector is pretty hard to find right now and I might end up de-soldering one from a Sophia DVI board I have handy. I find that I don't actually know what gets installed in the holes just below the words VIDEO SETUP... I'm also short some resistors and capacitors that were backordered. Also, when I ordered the Mouser shopping cart, I got some components that I think were intended more for the 1271 board, as I have some leftover resistors, capacitors, and chokes in values that don't correspond to anything on the 1221 board. I currently have the following extra components that came with the shopping cart order but don't have a slot on the board: 8 - 4.7K ohm resistors 1 - 180 ohm resistor 1 - 33K ohm resistor (Perhaps this goes in the 36K ohm slot?) 1 - 75 ohm resistor (Perhaps this is an alternate value for the 82 ohm slot?) 2 - 2.2uf 25v capacitor 1 - 10uf 10v capacitor 1 - 100uH inductor 1 - 47uH inductor (perhaps this goes in the 47MH slot?) Empty slots still on the board: 4 - 1K8 resistors 2 - 1K5 resistors 3 - 2K resistors 1 - 10K resistor 1 - 36K resistor Empty slots still in the UAV area: 1 - 10K pot 1 - 47MH inductor 2 - 1K24 resistors 1 - 10M resistor 2 - 2M2 resistors 3 - 10uF capacitors (backordered) 1 - 100uF capacitor (listed as not used and jumpered in errata file) 1 - GAL22V10 (on order) The rotary switch S2 on the back side of the RAM expansion will get installed as soon as I dig up a diagram or picture that shows me which orientation it goes in. If anyone notices any issues I haven't, I'd like to hear about them before this ever sees power

And if there's a way to avoid doing so...

Here are a few schematics I used that might help

I have a mighty need!

The official key spacing being in imperial measurements rather than metric or mils, I switched my PCB software over so that I could further divide the placement grid. In imperial measurements, a key space is 3/4" by 3/4". In order to get the right key offsets and wider key sizes, you basically need increments of 1/4 key width, and for some reason my PCB software wouldn't let me divide the 19.05mm value into grid squares 1/4 that size because it didn't like the number of decimal places. With a grid size of 0.1875" I found I could easily snap the key objects to the grid at exactly the spacing I needed, and then flip back over to mils or mm for everything else. The top two rows are 15 units wide, so 11 1/4 inches total width. The next two rows are a half a key unit narrower, indenting 1/4 unit on either side. So, 10 7/8" wide. The spacebar is 9 units wide, so 6 3/4" (My keyboard is different, as I found that it seems difficult to source a 9U spacebar, but I did find a 4U, which left me room for 5 additional keys (and potential room for more if I wants a 2U spacebar or just wanted to use keyswitches to stabilize the 4U bar.)

I've tried on my 800 with both the SCCC and a UAV I had ordered before the SCCC arrived. With the stock CPU card and stock video hardware, all of my 800s produce blue/green artifacts. I can get other artifact colors, but only if I completely mess up the normal colors. If the normal memo pad/BASIC screen is blue, the artifacts are always blue/green on any of my machines' stock video hardware. I even have an extra CPU card I ordered off eBay and it does the same blue/green colors as above. With the SCCC or UAV, the artifacts change to purple/green and no amount of fiddling with the delay/color pots can get it back to the original 800 colors. I've even tried modifying the SCCC to get back to 800 artifact colors, but it seems that the 800-style artifact delay is outside of the range of the SCCC/UAV color adjustment range.

Hard to tell from the pic, but it sort of looks like you're getting magenta/green on the artificial horizon ball. Interesting. If I try to adjust my 800 to get similar artifact colors, everything else looks really odd. The blue notepad/BASIC screen is far from blue. I don't seem to be able to get any of my 800s to display like that. When I run Flight Simulator on my 800s, the artificial horizon has blue sky and green ground. Faicuai insists that it should be blue and orange because he has a plane that has the same colors. I wonder just how much variance in tolerance in components there were back then, and how often they changed. The three operational 800s I have currently have different manufacturers of just about everything. Resistors, capacitors, even the main VLSI ICs are all over the map.

Of all the NTSC machines I've messed with: 400/800 artifact colors are blue/green. Games like Ultima III were designed with this in mind. XL machine artifact colors are purple/green. XE machine artifact colors are red-orange/blue. Games like Flight Simulator II were designed with this in mind. Of course, if you mess with the color pot, this can shift significantly. And, as we found out somewhat recently, if you put a UAV or Super Color CPU Card (which uses the UAV circuit) into an old 800, you'll change the artifacting from 800-style to XL-style. I haven't played with a PAL machine to see what artifacting looks like on those.

I've seen two kinds of Stackpole keys so far. Sometimes both on the same keyboard. They're interchangeable on the Stackpole plungers but might affect how the 3D printed adaptor holds them.

I wish I had noticed that beforehand. It would have saved me a good pit of soldering. But it did let me test with and without diodes. Both seem to work fine for normal usage. It is, however, fun to write code that can detect keycodes that everything else says can't be detected. I'm thinking about creating a new board layout where everything is mounted on a backplate with standoffs so the height of the keys can be adjusted. Soldering the switches directly to the same board as is screwed to the case doesn't leave a lot of room for adjustment. I used EasyEDA after watching some tutorials from a youtube channel by a guy named Ruthsarian. I'm beginning to think it's required. the PCB alone wiggles quite a lot. There needs to be a strong support to keep the center of the keyboard from flexing and there really ought to be a place to snap the switches into to keep them aligned properly. I was thinking of a triple layer of switch mounting plate, PCB, then support plate, but with some creative metalwork, it might be possible to use the mounting plate for the switches as the backplate and give it mounting ears to screw into the Atari case.

Just dropped into this thread but I noticed nobody else took a shot at this question. It swaps A and B without needing a third register.

I have found it incredibly convenient to remove the keyboard cable, solder right-angle pin headers in its place on the bottom side, facing backwards, then use an old IDE hard drive cable to connect the keyboard to the Atari motherboard. You just have to make sure you're using the same pins of both ends of the header, because it's two rows instead of one and is two pins wider than you need. The hardest part about soldering the pin headers is the fact that the keyboard PCB is single-sided and all the pads are on the same side you'll be putting the right-angle pin header on. I just solved this by removing the pins from the header strip, plugging them into a cable header to hold them straight, and soldering them that way. It gives you two ways to disconnect the keyboard when opening the case, and if anything else happens to the keyboard cable in the future, you can replace it with another IDE cable in seconds. Also, if you're using the computer out of the case, such as when installing mods, you can use a long IDE cable for convenience.

One, please.

(By the way, the above post is not intended to be strictly accurate. It's more of a generalization to get the idea across.)

Many of the shift control letter and number combinations do work, but a small number of them, the ones I listed above, do not. The only way they'd be detectable would be with an aftermarket keyboard. Something like a TK-II or other PC-to-Atari adapter might be able to send those codes. Because the PC keyboards have the diodes in them by default. It's not so much voltage levels, but the voltage path through the keyboard matrix while the 4051 chips are trying to decode the key matrix. The diodes just stop current from flowing the wrong way through cross-connections cause by holding down multiple keys. In doing so, it stops the 4051s from being confused by multiple keypresses, allows some of the key combinations the 4051s are capable of detecting but the keyboard hardware was previously incapable of sending, and stops 'ghost' keypresses like Ctrl+L+9 from being misread as other keys like Break. For those that aren't following along, (Not @_The Doctor__ I know he gets it. But someone else may want to know about this later) holding Ctrl+L+9 connects pins 1, 5, 9, and 13 all together. The system sees that pin 1 is (indirectly) connected to pin 9 through the green and red path and decided the Break key was pressed. Pseudocode for what the key matrix polling does: for row = 1 to 8 enable row pin for col = 10 to 17 // 9 is a special case connected to the POKEY chip directly. enable col pin is row connected to col? //register a keypress. disable col pin next col disable row pin next row (there are more things that key polling does, like once it sees a valid keypress, waiting for the key to be released, but that's not important right now) With diodes in place, current could not flow along the red line because it cannot flow backwards through the diodes in the Ctrl and L keys there, so it cannot detect the ghost Break key. Instead, it can tell which of Ctrl or L or 9 was pressed first and react correctly, ignoring the extra key(s). Pin 1 is connected to pin 13 so we could detect a 9 key. Pin 5 is connected to pin 9 so we could detect a Ctrl key (well, POKEY could) Pin 5 is connected to pin 13 so we could detect an L key. But pin 1 is not connected to pin 9, so we can't accidentally detect a Break key

Been a while since I posted about this, but I decided to take a second of my keyboard PCBs and solder it up. This time with diodes. The first keyboard, I installed jumpers in each of the diode positions because a stock Atari keyboard doesn't use diodes. Everything worked perfectly normally, and the Help and F1 through F4 keys were easily detected when the machine was booted up in XL/XE mode in Incognito. The only strange thing was that Ctrl+F2 seems to lock up the machine in XL/XE mode but not in A800 mode. This second keyboard with the diodes in it has some interesting benefits: If you look up information on the Atari keyboard matrix (such as from here: https://www.atariarchives.org/c3ba/page004.php), you'll be told that 16 control-shift-key combinations cannot be detected. The following keys share row lines with either control or shift and if you're holding both control AND shift, cause connections in the key matrix that the 4051 chips can't figure out: J K L ; + * Z X C V B F1 F2 F3 F4 Help Not only that, but there are some combinations you can hit that will be misinterpreted as other keys. For example, Ctrl+L+9 is misread as the Break key. With the diodes installed instead of jumpers in my second keyboard, ALL possible keycodes can be detected. Even the ones that were previously not working. You could write a program that used Ctrl+Shift+L and nothing at all would conflict with it because no preexisting software could possibly have expected it. The diodes also stop the false key detection (something often called 'ghosting' in modern keyboards). The diodes prevent current from going the wrong way and being detected as a different key when you hold three or more keys down. Ctrl There's also nothing stopping anyone from adding additional keys for the keycodes that currently do not exist. They can be detected by software that knows to check for it, and there are 6 slots in the key matrix for unused keys. With control and shift combinations, that makes another 24 functions that could be added to a keyboard. Not to mention you can use Ctrl+Shift+Help and Ctrl+Shift+F1 through Ctrl+Shift+F4 now. Once you have a diode-equipped keyboard, all you need to do to test that itr can detect the new keys and key combinations is write a small basic program like: 10 PRINT PEEK(764) : GOTO 10 And you'll be able to see the value change for the new keys on a modified keyboard where it won't on an unmodified 400/800/XL/XE. It does make me wonder exactly what Ctrl-F2 is doing to XL/XEs though... Edit: This pdf (http://mixinc.net/atari/books/XL-OS_Full_Searchable.pdf) says "CTRL-F2 controls the Screen Enable/Disable Direct Memory Access (DMA). It produces no ATASCII code. This key combination affects the operating system handling at the display function This key combination is not reassignable."

The Color pot isn't the issue. Standard colors are fine on the SCCC card. The Delay pot is the issue. Something about it is shifting the artifact colors and only the artifact colors from 800-style to XL-style (and, with some adjustment, somewhat XE-style).

I have a Retrotink on order, as well as a Hercules SVideo cable. I'm currently using some chinesium svideo cable and svideo-to-hdmi convertor. My computer monitor is an Asus MG28U from 2016. My LCD TV is a Panasonic Viera from 2013. Video "capture" has been through an iPhone that's constantly trying to 'correct' what I see in person. Testing on the LCD TV: Original A800 CPU Card: Ultima III Exodus: Blue border, green text. Blue water, green grass and trees. As It Should Be. LucasFilm splash screen from BallBlazer: Title is more brownish-gold than the iPhone wants to show here. Star Raiders shields: blue-gray shields. Flight Simulator II cart version: Artificial horizon is blue over green but a slightly different shade of each than the landscape. Colormap.com: Artifacts bars are deep blue and green. Band $01 is gold-brown. Same machine, Super Color CPU Card: Ultima III Exodus (without color invert jumper): Ugh. Yuck. Ultima III Exodus (with color invert jumper): The iPhone refuses to show it but the 'blue' here is every bit as magenta as in the title above. LucasFilm splash screen from BallBlazer: Gold on brown. No green tint in real life. Star Raiders shields: blue-gray shields. Flight Simulator II cart version: Screen refresh and the iPhone were fighting me here. The 'brown' is all the magenta-purple color. Colormap.com: Artifacts bars on left are magenta-purple and green. band $01 is gold-brown. It's not really as weird as it looks here, but I think the iPhone was having a stroke. Of course this would be a lot easier with an actual HDMI capture device. I'll look into an AV.io so I can stop fighting the iPhone's automatic adjustments.

I have located an LCD TV with color/tint settings that let me display LucasArts splash screens in brown and gold. I'm currently working on calibrating the colors according to Faicuai's LucasArts/Star Raiders/ColorMap benchmarks. Once that's done, I should be able to grab a metric ton of photographs of the screen using both the original A800 CPU card and the SCCC/UAV. (Something I should probably do in a separate thread instead of continually dumping into this one.) I fully expect to see that, no matter how perfectly I adjust the color/hue/tint settings to match Faicuai's standards between the LCD TV and the Atari itself, none of that will remedy the artifact settings from these adjustments alone. To get an Atari 800 with an SCCC card installed in it to render the Atari 800-style artifacts that an Atari 800 owner very likely expects, the SCCC delay pot needs a hardware mod to create a larger effective adjustment range.

On the SCCC card, there are two pots. On the UAV, there is only one and it's the delay pot. The blue pot at the top of the SCCC card is labelled DELAY POT and if you turn it, you'll notice that none of the normal colors change at all, but artifact colors do. You can adjust it through a range from the XL purple/green through the XE cyan/red but it won't go any further in either direction. If you load up COLORMAP from the Altirra Additions disk, you'll see that the two bands of artifact colors on the LEFT of the screen change but the matrix of colors on the RIGHT do not. The black pot at the bottom of the card is labelled COLOR POT. It doesn't change *every* color on the screen like a true hue/tint control would. If you load up COLORMAP, you can see when you make large changes to the Color pot position, the rainbow of colors on the RIGHT side will either grow until the whole rainbow won't fit in the 16 color bands or shrink until it starts to repeat multiple times. This vaguely changes the bands of artifact colors on the left side but only because those bands were created with columns of colored pixels rather than white ones. It's not because the color pot is changing the artifacts, but only because the artifact bands weren't created with white pixels. Those columns of pixels were created using colors the color pot *does* control, which adds some confusion. The UAV.XEX test program creates bands of artifact colors with shades of white so it's much easier to see how the artifacts don't change when the color pot does. It's my unproven theory that, if the range of the delay pot were great enough, you would be able to adjust through the entire rainbow to make the artifacts any color you wanted along with its opposite, and somewhere in that range are the colors the original 400/800 displayed.

YES. ABSOLUTELY. I have been trying to steer the topic back to this subject since the beginning. Yes. It's all about the artifacts phase. Yes, that's what I want to modify ON A HARDWARE LEVEL IF I HAVE TO. And I'm QUITE sure I will have to. I have been aware of this from the start. This side trip into hue/tint adjustments has only served to muddy the purple waters. Even if I dug up an old CRT that perfectly rendered LucasArts' splash screen in brown and gold and Star Raiders' shields in gray-blue and Band $01 in Colormap the precise shade of yellow-gold, the SCCC/UAV artifacts would still be XL-style purple/green and not XE-style red/blue nor the desired 800-style blue/green. Any machine the SCCC or UAV is installed in will currently be forced to display XL artifact colors, but the delay can be adjusted until it gets close to XE-style artifacts. The delay pot (not hue, not tint, not color pot) currently cannot be adjusted far enough in either direction to create 800-style artifacts, and THAT is what I want to change. This is a hardware issue that will only be solved by a hardware mod to the CPU card. Which I am trying to get to.

Even if I adjust the LCD or color pot settings to that, the artifact colors on the SCCC remain incorrect for an Atari 800. The artifacts remain purple/green on the SCCC and blue/green on the A800 card. And as a result, software that uses artifacts for color looks odd. But not as odd as XE artifacts. And, to be clear here, the only thing I am trying to adjust here, are the artifact colors. And they cannot be corrected by the color pot or lcd tint/hue settings. This is a color clock delay issue, not a tint/hue issue. I could go buy a different LCD or even an old CRT and adjust it all day long until I got just the right shades of brown and yellow-gold and *still* the artifact colors would be XL-style and not 800-style and Ultima III would have the wrong colors.

I am clearly NOT stuck. Without touching my LCD settings at all, one set of hardware can generate blue/green artifacts and another set of hardware can generate green/purple artifact colors. On the SAME LCD with the SAME picture settings. I am NOT going to try to fix this by adjusting the LCD color settings. That is entirely the wrong approach. I am going to fix this by adjusting the hardware such that it generates 800-style blue/green artifacts. Anything else would result in incorrect colors on the entire screen for every title everywhere.