SuperSparky

You used to be able to, back when monitors like the Nec Multisync were in the early generations called stuff like "Multisync 2A" (or something like that). Those old monitors would match the low horizontal scan rate of 15.75khz (or something like that) which is necessary to show graphics from old computers like the ST/Amiga. Some time (a long time ago) they all moved to higher and higher frequencies and (for some reason) they all pretty much simultaneously dropped the ability to scan low enough for these dinosaur computers. I haven't the foggiest notion WHY they would drop the lower ability; perhaps one of our technically-inclined friends here can chime in!!! With LCD's it's just a matter of firmware and most don't have the software to sync to the "old" frequencies. However, for CRT's the problem is with the horizontal output transformer. Extra relays and special horizontal output transformer windings had to be switched to for the lower sync frequencies. These extras cost money, as well as the extra circuitry to support those scan rates. The simple answer is cost versus demand.

Woah now! As someone who happens to love both Atari and Spectrum, but also knows a thing or two about hardware, let me enlighten some people about 8 bit CPU's. The 6502 is what is referred to as a "RISC" processor. It doesn't have much in the line of op-codes and registers, but it makes up for it in raw speed. It also had a drawback of only having memory address space, which meant that peripherals took up valuable memory addresses. The Z80 has a lot of op-codes and a hearty amount of registers. It does have some powerful and fast memory block transfer, BCD math, and register functions that are quite fast. However, most instructions, due to their complexity, require numerous clock cycles to complete. The Z80 also had the advantage of port addresses in addition to memory addresses. This meant peripherals didn't have to take up memory addresses. They had their own unique I/O port addresses, 256 of them (really 65536 if you used the sneaky C register related port op-codes). However, it's like comparing apples to oranges. The 6502 was relatively cheap to manufacture, and it's zero page mode made up for its lack of registers. However, 16 bit operations were cumbersome and it generally took a lot more code to get things done. However, a good programmer could code some very fast code, BUT it would generally be more memory space used up by the code than the identical program optimized for the Z80. For memory block transfers, the Z80 has the 6502 beat simply because it's all register driven and memory is only accessed for the block data itself. Four lines of assembly is sufficient to copy any sized block of memory very very quickly. The 6502 is certainly speedy, but because of its RISC nature it is not memory friendly. The Z80 could have quick and compactly written code simply because of it's larger instruction set. There is no simple comparison, however, for the equivalent commands (op-codes that essentially do the same thing on both processors), the 6502 beats the pants off the Z80, even at four times the clock speed. The Z80, nevertheless, is a more powerful and advanced CPU than the 6502, and code written for it is generally more compact when compared as a whole program. It is documented that the 6502 was used in the Atari's because it was cheaper than the Z80, and that was it. The Z80 was still living high on the hog of CP/M and was priced higher. Jay Minter exploited the qualities of the 6502 with the surrounding support chips and created quite a monster of an 8 bit computer with some excellent graphics capability. Clive Sinclair designed his computers with a different philosophy. He found it was cheaper to use a Z80 for his designs as it meant more compact code and thus smaller RAM and ROM requirements. His computers would be slower, but they could have a lot more programming power crammed into their ROMs and there was also the advantage of the Z80 having a separately accessed port bus, which meant the only thing that required memory mapping was the display RAM. The Spectrum's wacky method of handling display RAM pretty much limited its speed when display RAM was accessed. The Atari could move the display around memory and thus never have to worry about CPU/display collisions. The Spectrum just stopped the CPU clock dead in its tracks until display RAM was available IF display RAM was being accessed during a display refresh. Moving the display was impossible, it was fixed at 16384 period. Only future models had banking ability to avoid this. So enough of the willy wagging. Frankly, in my opinion, if someone coded a 3D renderer that was only bit mapped in mode 8 on the Atari, I'd say it would be just as fast, if not faster because page flipping could occur AND drawing could be done outside of the display RAM.

Candle has class and I know he won't ask this, but if you're from the USA, please add 4% to your total if sending via PayPal. The exchange fees etc. take 4% out of his share. He does a great job in doing these batches, let's make sure he is properly compensated for his hard work.

It's hard to play any game when it's vomiting rainbows on your screen every 3 seconds. Jeff is the kind of programmer that is very very talented, but is in dire need of direction. Anyone that has worked on video games will tell you the most important member is the director, as he keeps the talent in check so the game is fun and playable. It reminds me of someone who has discovered how to make web pages via their WYSIWYG web page editor, and decides to use every special effect it has available in its library. All this does is make one very annoying web page. Jeff Minter can still have his signature games, but he must take into consideration playability over special effects. Just because you can have a bunch of unicorns vomiting a rainbow of colors all over the screen, doesn't mean you should.

Is there anything like this available for a TT?

You could use a simple capture card (or USB) and use your PC to display. You could also use a USB TV card and re-purpose an old laptop. Simply use the composite or S-Video inputs on these devices. The GTIA generates an S-video specific signal no matter what, so you aren't going to get anything better. Besides, not many monitors now days do NTSC/PAL horizontal refresh rates, unless it's a TV specific monitor. A TV card and a computer that you already own is much cheaper than a converter box that averages $100 US.

The silicon diode 1N4002 is a poor choice for video, especially the chroma output. It's switching voltage is 0.7 volts! Use a germanium diode instead. A 1N34A should do. Not only is its switching voltage 0.3 volts, but it's also designed to switch at high frequencies. Silicon diodes are best left to rectification. Germanium diodes typically have glass cases, and you'll notice your Atari has a lot of them. The silicon diodes are only in the power circuits. Fortunately, if you've already made this mod, and don't want to risk damaging the PC board by removing the 1N4002 diode you previously installed after removing a resistor (XE boards are delicate), then simply "piggy-back" the 1N34A diode over the 1N4002 and all will be well. Your color on edges should be more accurate, especially the screen edge.

Put me on the list for two of each.

Here are some possible causes: Not enough power from the power supply. Lack of sufficient current can cause the analog circuitry to get "upset". RAM interface wiring possibly crossing the video circuitry and causing interference. Poorly done RAM expansion. Perhaps missing the 33 ohm resistors? The monitor is perhaps the one with the problem, not the XL. This sort of problem is also a poor power supply, but this time in the monitor. Try it on a modern TV (if not already).

The 520ST only uses one bank of RAM and the MMU is capable of controlling two banks of RAM. There is a RAS and two CAS for each bank. All that is needed (essentially) is to piggy-back the second set of RAM chips onto the existing ones, bend up the RAS (pin 4) and CAS (pin 15) pins and leave the rest soldered to the chips below. Wire together all the RAS pins of the chips on top, and route, via a 33 ohm resistor, it to the "RAS1" of the MMU (pin 18). Now wire the first eight chip's CAS lines together and then route them via a 33 ohm resistor to the "CAS1L" of the MMU (pin 21). Wire the CAS of the other eight chips together and then route that via a 33 ohm resistor to "CAS1H" of the MMU (pin 22). PLEASE DOUBLE-CHECK PIN NUMBERS, as I am sleepy writing this! I highly recommend DRAM of a more recent design with a lower power drain in interface impedance. This will have less of a load on the MMU and system in general. However, they shouldn't be faster than 100ns and no slower than 120ns. Make sure you use as little wire as possible (keep them short). Solid wire wrap wire works best. If the system has stability problems, then do the following, testing between each step, and stopping if stable at that step: On the RAS tree, parallel a second 33 ohm resistor across the existing one, effectively making it 16 ohms. If still unstable, parallel another 33 ohm resistor on both CAS trees, effectively making each 16 ohms. If still unstable, remove the RAS resistors (or short across) removing them from the circuit If still unstable, replace the CAS resistors with 10 ohm resistors If still unstable, and absolute worst-case, remove all resistors and run wire direct. NEVER DO THIS on an original 520ST, but the FM's and STE's MMU can handle the load. You can, if you want to, buffer the CAS and RAS signals with logic 74LS style buffer chip. Just to be safe, you can install 33 ohm resistors on the CAS signals of the primary bank as well. The resistors serve two purposes. They ease the load of the MMU slightly, but they also smooth out any overshoot and undershoot of the signal coming over dangling wires. Click here for a better howto than mine written in 1988

HOLY COW! IT SOLD FOR... $31,600!!!!! My friend and I were watching it. First $16,700, then $17,000, then it suddenly jumped to $30,000 in the last few seconds, when the winner jumped in with $31,600 at the last second. I never had so much fun watching an auction on eBay! Congratulations on the that! It almost beat the Nintendo Summer Games record.

I learned Z80 Assembly as my first foray into CPU assembly, and I think it ruined me for the 6502. I was spoiled with the incredible power and ease of programming the Z80 that when I tried to do 6502 I'd get so frustrated. Something I could do in three of for simple commands on a Z80 would take considerably more coding for a 6502 to do. The 6502's limited register set and it's heavy use of page zero as a substitute really frustrated me. I'm sure had I learned 6502 before Z80, my outlook on things would have been different. The 6502 is certainly an 8 bit "RISC" chip compared to the Z80. What the 6502 has going for it is high efficiency (as do all RISC style processors). Sure it may have take 32 op-codes to do what a Z80 can do in four, but the 6502 did it incredibly fast. A 1.8 MHz 6502 could typically keep up with a 4 MHz Z80 in most cases. I would like to get back to learning 6502, as I'd like to write my own customer handler code for my own projects, but only time will tell. Good luck Z80Guy (I like the name, by the way).

Sorry, my two NTSC's are for: One 65XE One 130XE

I need 2 for NTSC please. I would also like two of the other boards on your web site as well. What else do I need to do? I have a verified PayPal account. Just tell me how to get this finalized.