Re: [stella] Reverse engineering the TIA (Was: Midified VCS...)

Subject: Re: [stella] Reverse engineering the TIA (Was: Midified VCS...)
From: Kevin Horton <khorton@xxxxxxxxxxx>
Date: Fri, 07 Dec 2001 00:23:16 -0500
At 11:20 12/6/01 +0100, you wrote:
Hello Mark!

I intend to redesign it using 74xx IC's (don't laugh...) . Preferably

Why not use HC logic? F logic draws craploads of power, gets hot, and can require tricky bypassing. HC draws almost nothing, is plenty fast, and has nice noise margins.

Well, i looked at the counters, and they indeed consist of 6 self-feedbacked
shift registers, driven by a two phase clock , using some kind of wired-and
logic to decode various states. Fortunately, J. Miner wrote at the H-Sync

Yeah, you should really use what they did since those LFSR's (linear feedback shift registers) outputs are synchronous. A ripple counter's outputs are not. Since you have to decode the same number of states anyways, it'll probably be easiest to use a shift register chip like a '164 or similar. Just tap off at the appropriate output for feedback and just don't use 2 bits.

The bus logic and sync decoding are not really a problem to do in TTL. The
Playfield registers are tricky. Could be replaced by latches and a flip-flop
chain, which is logically anded with the outputs of the latches.

You could do it with some 74299 which are bidirectional shift regs with parallel/serial I/O (tie for parallel in, serial out). 8 bits a pop so you'd only need 3.

Sheet 2 consist mainly of the Bus drivers, the collision detection, and the
address decoding. The adress decoding consist again of primitive wired and
logic. TO do it in an FPGA, you'll have to convert it to real AND gates (which
will significantly increase the gate count). I intend to use 4 plain 74154 4
to 16 address decoders... (yuck).

Using CPLD's, these are essentially "free".

In the last sheet, there are 4 7-bit registers for the color data. Above is
the priority logic, which selects the color register. My prototype will have
the color phase delay logic replaced by two PROMS, where the colors are
hardcoded (as i said).

Yeah, on my FPGA design this is what I was thinking of doing; either with an external EPROM or doing that right on the FPGA (it is possible to make small ROMs/RAMs on some FPGA/PLDs). 3 R2R resistor networks could produce RGB directly off the PROM/ROM/FPGA outputs and drive some form of chroma encoder for NTSC or you could just have an RGB output 2600. For the ultimate in clean 2600 video you could run those through some nice "stiff" buffers to get really sharp edges before going into the R2R DACs.

One other idea I had was using a "RAMDAC" chip off of an older SVGA card. It has 256 6 bit RGB palette entries (would be loaded before hand with say, a microcontroller, etc) and is made to drive an RGB monitor directly. Theoretically this could give very high quality results.

Archives (includes files) at
Unsub & more at

Current Thread