Atari 800 character set
I've had this project planned for quite a while, but had to put it on hold due to the distractions of paid contract work.
Another reason for going public now is that other people have become interested in cloning the 800XL.Retromicro announced this underway as of 2004/08/31, but has not begun coding VHDL yet.
Fortunately for me, my previous project - the Polymorph - is a major head start. I purposely designed it to have the same cycle timing as the 800XL, and the video control logic is designed to be ready for gradual mutation into ANTIC compatibility.
It is significantly harder to do than the Atom, because it is a lot more complex. Many things have to be working before the firmware can begin to run the BASIC interpreter. So it is harder to implement things piece by piece.
Existing Features
Forthcoming Features
|
|---|
The original 800 series used a standard NMOS 6502A CPU. The later 800XL series used a custom tailored variant codenamed Sally. The latter are no longer produced, but are still available from a dwindling stock. The main hardware difference is that the address and data bus can be tri-stated. This allowed the system to share the bus with the video system, without multiplexing, and thus lower the manufacturing costs. The main software difference is in some of the undocumented opcodes.
For the moment, I am using the more common CMOS 65C02 CPU. I do not know if the standard firmware uses any undocumented op codes. I suspect it does not, but other software may well do so. If necessary, I can modify the project to use a real Atari CPU or a VHDL equivalent.
The Atari video address sequencer (ANTIC) is cleverer than most, because it can change modes and source address on a row-by-row basis. It reads this information from a display descriptor (Atari called it a called "Display List"). Note that 'row' is not the same as 'scan line'. A row can be one scan line high in the highest resolution mode, or it can be several scan lines high for other graphics modes, or text modes.
The Atom display sequencer has prepared for this by latching the display mode at the start of each row. This ensures that the graphic mode will not change until it has completed the currently active row. Therefore it will not disrupt the display with partially-displayed rows.
A major early step is therefore to get the sequencer to read a display descriptor from memory. The Atom firmware knows nothing of this, so it must be modified to have a default display descriptor to describe the display the Atom expects.
Display modes
The Atom can already drive the display in 32, 40 or 44 characters wide (equivalent to the Atari's Narrow, Medium and Wide playfields).
The display mode is latched at the start of every row of characters or pixels, and held throughout.
The video address simply counts sequentially from a base address. This has to be changed.
New display modes
Users have lamented the lack of an 80-column text mode. It should be possible to provide this, with some limitations. The Atari can only do enough memory cycles to access the character and font data for 40 characters per line. The Atom project has internal font memory, and so could be modified to access character data for 80 characters per line. The drawback is that one cannot instantly change fonts by simply changing a font pointer anymore, fonts must be copied into the internal font RAM. Rapid font change may be useful in games but not essential for a simple text editor.
80-column text is barely readable on a TV screen, so a monitor will be required. These tend to run at least twice the line rate, so a 'line doubler' will be needed. This would be a buffer loaded at the normal rate but read out twice to produce two monitor scan lines. This all increases the complexity of the design...
Palette
The Atari has 16 colours in 16 luminosities. The analogue luminance signal was generated by a simple 4-bit resistor DAC, and the chrominance by delaying the chroma carrier by one of 16 phase delays. Each pixel therefore needs only 8 bits to describe.
The current design has three 8-bit DAC chips, taking 24 pins to drive. It would be nice to regain 16 scarce pins.
The luma/chroma method is well suited to analogue TV, but phase-delay modulation of a 3.58 MHz sine wave is a bit tricky to do in an FPGA clocked at only four times that. It also is vulnerable to artefacting: that is, unintended colours. Modern digital video is often stored in 4-2-2 or 8-4-4 format, which refers to the number of bits assigned to luminance and two colour components. Some TVs accept these signals in analogue form ('component video') and avoid artefacting problems. In this case you only need one 8-bit DAC for luminance and two 4-bit DACs for the chroma components. In the Atari, the luminance need only be 4 bits as well. So one may well be able to use just twelve I/O pins driving three simple resistor DACs.
The best approach may be to have it so one can select an appropriate digital palette for the display in use (RGB or component video).
Sprites (Player Missile Graphics)
Sprites are very similar to the hardware cursors. However, the Atari had much simpler sprites and were mainly there to provide collision detection (which is a significant burden to do in software).
Font
As well as the standard Atari 8x8 pixel text fonts, it will also have the more elegant 12x8 pixel fonts from the Atom project, ISO8859 fonts, and teletext attributes.
Tape and Disk Interface
The Atari used a proprietary serial bus to talk to its peripherals, so as long as the SIO interface is implemented it should be able to talk to them. Since the peripherals are no longer made, they are usually emulated by the Atari Peripheral Emulator (APE). Alternatively, there are designs for Atari IDE interfaces. These allow you to boot up from a hard disk drive in a few seconds. A compact flash card would be even faster, silent and shock resistant.
SIO
This is a relatively simple clocked serial port. It foreshadowed the USB in this aspect.
The APE requires a TTL to RS232 level shifter. This could be built into the system.
USB
With the decline of RS232 and parallel ports, it seems reasonable to implement USB instead. My laptop has no RS232 ports at all. It may be possible to make a USB endpoint look like the Atari SIO, and talk to a PC that way. It would of course be much faster! USB slave behaviour is relatively easy, but getting a 6502 to do USB master behaviour is much harder. Fortunately some German guys are working on this already! They are using a chip (Cypress SL811HS) that gives them master capability. I currently have a USB module providing a slave interface.
POKEY
Right now it is as described on the Atom page. No Atari-specific features have been implemented yet!