tf_hh

You´re using the 800XLF mainboard. This one has three problematic points: - Exchange the both 470 uF electrolytic capacitors found on the mainboard. One on the right side near the RAM chips, the other one in the lower left corner of the O.S. ROM. Although most Atari 8-Bit mainboards hasn´t issues with electrolytic caps, THIS mainboard has. For sure. - The both inductors (upper left corner at your picture, L3 and L4). Remove them and use a little piece of wire each for replacement (or a 0R resistor). - The missing smoothing cap for Freddie causes a lot of white noise at the CPU´s buss. Check out my mod in this thread.

PM sent!

Yes - and no. IMHO this is a nice, but only academic test. Using this way would force you to set $EA (op-code for NOP) constantly at the databuss. In a good case the address buss is increasing with every SYNC = high by 1. But without monitoring every single addressline bit you can´t be sure, that the CPU is working well. I´ve had several defect CPUs (it´s - after DRAM - the 2nd most part with issues) with one or two defect address lines, constant high or low for example. Next: Even if this test runs fine, you can´t be sure that the register (A, X, Y) are fine. Or the status-register (S). Or maybe there´s only a fault when the CPU has to branch or jump, with or without condition, executing any address index method, ... Regarding the effort to build such a test facility, manual "hands-on time" and just a test of a very basic function it´s easier and cheaper to buy a new "NOS" CPU for around 12-15 Euros incl. shipping (see posts above).

Yes. I forget to mention that, I know some guys build this solution in the 80s, but most times the effect was... crap. Another way is to halt the CPU using RDY or HALT, but in both cases you get graphical disturbations quickly - and ANTIC´s timing went wrong - picture garbage.

It´s affected to all Sys-Check versions... but, with Sys-Check "XL" there´s no problem at all, and Sys-Check XE has the concerned capacator at a different place. Will sent a picture in the evening.

Yes, good point. I´m pretty sure that this mainboard revision has "anything" different. Yesterday I see that some XE mainboards have an extra diode around the NE555 chip, some not. When I´m remember right, I´ve also seen a factory-added (manually) diode soldered over the NE555. Maybe that´s the reason for different behavior of this issue.

If you haven´t the possibility to take a working system for test etc., then I would offer to repair your mainboard. You´ve to pay the shipping costs, of course

I didn´t about such a ready-to-use, external solution (but maybe one exist). But several schematics floating around... Find something similar here (it´s in german, but the schematic is easy).

I have two GTIAs in my "defects drawer" with problems in collision detection. Both GTIAs will be detected bad by the SuperSALT diagnostic cartridge - you don´t need the external fixture for the GTIA test. One of the GTIAs is also detected bad by SysInfo utility. So first test is SysInfo, then SuperSALT

Hi, I discovered a (very little) issue with all Sys-Check V2.2 PCBs ever produced and shipped out until mid of July 2018. In some rare cases an Atari XE computer (only XE models are affected) won´t boot anymore when Sys-Check is attached. You get a red/brown screen after powering the machine on, and nothing happens. Sometimes you can press RESET and the machine will start (if it´s ok anyway), but most times it hangs. When Sys-Check is removed, the machine starts normal. Again: Only XE models are affected. And until today only 3 examples from 2 different users are reported. The reason is simple: I add an wrong capacitor at a special point. After having some discussions during the prototyping of the Turbo Freezer 2011 Hias found out, that sometimes the Xilinx CPLD will detect a RESET even when there´s none. Reason is the flaky RESET line in most Atari XL/XE computers. Standard parts like 74xx TTL chips, CMOS 40xx chips or GALs are too slow to be affected by these spikes, but a fast CPLD or FPGA is influenced. The solution is easy: Just put an additional 100 pF capacitor between RESET and GND in the near of the RESET signal´s input to the CPLD/FPGA device. Although Sys-Check only uses GALs and 74HCT logic chips, I decide to add this one, too. Just to be safe in all circumstances. But I made a mistake: I wrote "100 nF" in the silkscreen, not "100 pF". I use always own part descriptions instead of using the one from Eagle. So all Sys-Check´s until today are assembled with the wrong capacitor at this place. If you have an Atari XE with this behavior, the easy fix is to remove the capacitor being the source of trouble. Until today I didn´t found out why only a few XE systems are affected. Maybe there´s a little difference in the NE555 delay circuit for RESET. Personally I didn´t own any system with problems using Sys-Check, but I got reports - and the removal of the capacitors helps in all cases. You can replace it with a 100 pF SMD ceramic capacitor in 1206 or 0805 (imperial) package, but it´s not mandatory - just leave the pads empty and Sys-Check will definitely work flawless! Here´s a picture of the bottom side of Sys-Check V2.2 to show the capacitor which must removed: All shipped Sys-Checks from now on will have the correct value (100 pF) capacitor. Best regards, Jurgen

Hi, I think somebody didn´t read the manual by Claus carefully enough I see the standard 64 KBit DRAMs soldered directly into the mainboard. No other DRAMs visible. When I´m remembering right, you have to remove the 64 KBit (4164 or similar) DRAMs and exchange them to 41256 DRAMs (256 KBit), which will result in 64 KByte base memory and 192 KByte expansion memory. All other wires etc. looks good - except the changed DRAMs. Today I wouldn´t recommend one of these solutions - most modern games or demos requiring a memory expansion need 256 KByte expansion memory. Second thing, the banking scheme of such solutions is also special, so another amount of programs won´t work. And you´ve to desolder all existing DRAMs. Just my 2 cents...

PM sent

This results in the fact, that the last both XL OS revisions can test the additional XE memory of 64 KByte banked RAM. When you´ve had an 130 XE, four long rectactles appear over the 48 blocks indicated 16 KB of extra memory each. But the routine in the Selftest only works with the 130 XE banked ram (different access between CPU and ANTIC etc.). This behavior happens with other expansions, too. But in fact that Rev.2 is the most compatible XL/XE OS version for "all day life", I think it´s an acceptable "fault"

Charlie Chaplin reported me this behaviour some days ago. I´ve analyzed "Tapper" and locate a subroutine at the beginning of the game which writes zeros to the I/O area (the XL OS does it the same during coldstart HW initialization) - the machine language routine writes these zero backwards, it starts at $D3FF down to $D300. Because it´s backwards, the following things will happen: - $00 is written to PBCTL. Which enables the setting of the DDR (Data Direction Register) for Port-B. Next write access to PORTB selects output (1) or input (0) of each pin - $00 is written to PORTB. All eight bits of Port B are now inputs. This is done after the game is loaded. For the most important signals (Portbit B0 for OS/RAM selection, PB1 for BASIC on/off and PB7 for Selftest-Mirror on/off) are pull-up resistors at every XL/XE mainboard. Even when Port B is set as inputs completely and they´re floating - PB0, PB1 and PB7 will be hold at high-level through these resistors. So OS will run further, BASIC is further switched off and also Selftest... ... but not the memory expansions made by me (this includes Sys-Check). All these solutions grab any write access to $D301 everytime and store the result in a latch. I made this, because no six wires must be soldered to the PIA like with older expansions - and Sys-Check can´t work another way. But this kind of the game´s programming is one thing where the old expansions are more safe: They have also pull-up resistors for the PB4 and PB5 inputs, so a PIA configured as input won´t select any banking pages either. In this special case less is more Sad to say, but there´s nothing I can do. The Ultimate 1 MB is not affected, also the Turbo Freezer 2011 not. Simple reason: They use CPLDs for complete emulation of the PIA - such intelligence in a simple GAL is not possible. As far I know only Tapper (and now the second one) affected. When you run (for my internal expansion) the MOFF.COM to disable the memory expansion, then also Tapper etc. works fine. Using Sys-Check just switch the memory expansion off. Best regards, Jurgen

Hmm. Regarding Gyruss I´m pretty sure that only a 16 KB version exists. The unpatched version makes trouble with VBXE (black screen), but without this point it´s an absolute 08/15 standard 16 KB game cartridge. Star Raiders... I know only "Star Raiders II" (sometimes called "The last starfighter?" I´m not sure...), this is a 16 KB ROM, too. When the game was originally 8 KB, then it should run as a BASIC replacement.

Star Raiders and Gyruss take 16 KB. That´s impossible as a replacement for the BASIC-ROM. The MMU decodes only 8 KByte address range when PB1 is set to low (BASIC enabled) in the area of $A000-$BFFF. Even when you add the needed A13 addressline and use a 28128 or bigger EPROM, the system always only would access the 8 KByte.

I always use the upper side of the capacitor left beside the cartridge port, because it´s closer to the power jack than the OS-ROM / BASIC-ROM. But by default this shouldn´t make any difference. Look here for an example...

IMHO this *is* the most important argument against such a solution: After more then 10 years (!) of VBXE the count of games etc. supporting VBXE is a very manageable amount. XEP80 was only a character-based serial attached solution, which was cool stuff in the 80s, but from a today´s view... very lame. To use such a videochip Matej mentioned it must be realised as a buss solution (PBI / ECI) with a lot of supporting chips to make it useful, fast and give added value. Then the final price will be in the range of VBXE - or above, when a nice case is applied etc. At the end it´s the same question like using VBXE, Rapidus and so on... if you want to have graphics and speed doubled or more than a stock Atari XL/XE, take an Amiga

IMHO you can stop to writing such taunting comments in this and other threads. My suggestion: Make a project like this and make it better. Then we can talk.

Of course some Atari dealer exchanges the Basic to a "C" one. But then, the chip already was in a socket (easy) or they remove the old one and solder a new one in (I hope with socket, but...). Anyway, this mainboard has - except the solderjob by it´s owner - no manually solder handling. All pads of OS-ROM, BASIC-ROM etc. are done by a solder bath, not any hand soldering. So it´s like the factory does.

The 600XL mainboard is already on it´s way back to the owner, but there´s no serial number or any other marking then the one I pictured already. I got only the bare mainboard, no case.

Yes, these Chelco labeled 800XL I´ve also seen a few times (PAL and NTSC ones). But no 600XL with rubberfoam until today.

Hi, I´ve a PAL 600XL for repair and was surprised about the fact, that only GTIA, ANTIC and CPU were in sockets - all other parts are directly soldered in! Until today I never have had an Atari 600XL seen with a mainboard, where NOT all chips are in sockets. Not dependent if it was a PAL or NTSC 600XL mainboard. I´ve made some pictures... (Both DRAMs, both 74LS158, the 74LS375 and 74LS32 were desoldered and sockets placed in by the owner - originally these chips were also directly soldered in) Also not common: Basic "C" - I never found a Basic-C version in an Atari 600XL. Datecode "1284" is very late for 600XL...? Also I never saw such "rubberfoam" at the PBI´s connector (bottom, solder side). Any comments? BR Jurgen

Indeed. I´m sure it´s the same. The file "1050 Home made upgrade pic 3.jpg" shows the EPROM from bottom side, and the chip below the EPROM is not an EPROM, it looks like a standard 6264 chip - 8 KByte trackbuffer.

I´m pretty sure the 8K trackbuffer RAM is soldering below the EPROM as shown in one of the first pictures. I´ve done such updates in my bad years also with the Speedy 1050