5 replies to this topic

[SeaGtGruff]

I'm not sure if this is the best place to post this, but here goes.

For several months now (perhaps even years), I've been studying the TIA schematics on and off to try to understand how to read them, and how the TIA works. I still have some questions about reading certain things in the schematics, but I think I now understand how to read most of the sections.

Many months ago I downloaded LTspice with the intention of trying to set up the schematics in it so I could run it and follow the action, but that was a bust, because I don't yet understand how to set up the different circuits (transistor parameters, etc.).

Much more recently I've started working on a spreadsheet to simulate the TIA. (Yes, I'm crazy.) I have most of sheet 1 of the schematics set up in a spreadsheet, with every inverter, NOR gate, AND gate, flip-flop, etc., implemented as a column. I've even added randomization for lines and nodes that might have undetermined values at startup, such that (for example) the horizontal sync counter now starts up with a random value, possibly even the illegal 111111 value. I don't know if the randomization is realistic, but it's kind of neat to see that the phi0 clock pulse might start out with an oddball pattern (such as 00001100111000) before stabilizing to 111000111000, and things like that.

The problem is, my spreadsheet is based on a delay of 0-- each row corresponds to a high or low cycle of the oscillator, with no rise time, no fall time, no propagation delays, no gate delays, etc.

If posible, what I'd like to do is create a software implementation that tries to incorporate rise times, fall times, gate delays, etc., so I can get a better idea of the timing for different events-- like, how long does it take after the SHB signal before the blanking actually kicks in, etc. But I'm not sure the best way to approach it. I'd like to simulate every individual gate and signal-- for example, simulating the inner workings of the divide-by-3 or divide-by-4 sections, or the horizontal sync counter LFSR-- rather than just reading the next value from an array. I'd like to use voltage levels rather than simple 1 or 0 values, but I'd be happy to start with simple 1 or 0 values as long as I could incorporate the delays at least well enough to get a rough idea of timing. (The old Stella programming guides do include tables and diagrams with timing values, so that helps.)

I'm *not* trying to write a full-blown emulator per se-- I have no interest in emulating the 6507, the 6532, the TIA, different cartridge formats, etc.-- I'm more interested in a "slow-motion simulator" to follow the inner workings of the TIA, the general timing of the signals, etc., rather than running a ROM image and drawing a video display.

Can anyone tell me how existing emulators work? What I mean is, do they account for things like the delay between the phi0 clock signal and the phi2 clock signal, or do they operate on a more simplistic 0-delay implementation that focuses on final results rather than the nitty gritty of all the gates and signals that produced those results?

[Rybags]

I would think it's more a case of building a line of pixels cycle by cycle (CPU). Register changes need monitoring on that basis, or in some cases possibly on a scanline or even frame basis (e.g. for rudimentary sound, just build a frame's worth of waveform based on current register values at the sampled time).

Then the emulator just has to cater for known behaviours, the obvious way is to reduce such things to the most simplistic "rule" possible to make the emulator efficient while still retaining accuracy.

[SeaGtGruff]

Rybags, on Tue Dec 20, 2011 11:23 PM, said:

I would think it's more a case of building a line of pixels cycle by cycle (CPU). Register changes need monitoring on that basis, or in some cases possibly on a scanline or even frame basis (e.g. for rudimentary sound, just build a frame's worth of waveform based on current register values at the sampled time).

Then the emulator just has to cater for known behaviours, the obvious way is to reduce such things to the most simplistic "rule" possible to make the emulator efficient while still retaining accuracy.

Yeah, I thought that was probably how emulators are functioning. The problem is, it can possibly lead to some inaccuracies. Sound is a good example. The way the TIA's frequency divider circuitry works, switching to a different AUDF0 or AUDF1 frequency value might not have an effect on the output for several scan lines, so alternating rapidly (from one scan line to the next) between different frequency values might produce a particular sound effect in an emulator but "fail" on real hardware.

[Rybags]

It's probably like Pokey in that regard - if you plug an AUDF value in, it doesn't take effect until the current divisor countdown finishes.

Wasn't there a TIA decap done? IIRC someone even did a Flash or Java simulator, or maybe I'm thinking of some other system.

[Thomas Jentzsch]

For the graphics you need at least to go down to the pixel clock which is 3 times the CPU clock.

[SeaGtGruff]

Thomas Jentzsch, on Wed Dec 21, 2011 2:58 AM, said:

For the graphics you need at least to go down to the pixel clock which is 3 times the CPU clock.

Yes, each row of my spreadsheet is half of the oscillator's cycle (hi/lo). If/when I create a program, I plan to get even smaller than that, since that's the only way to simulate the gate delays and rise/fall times of the signals. For example, an abbreviated portion of my spreadsheet looks like this:

|-----|-----|------|
| OSC | CLK | Phi0 |
|-----|-----|------|
|  1  |  1  |   0  |
|-----|-----|------|
|  0  |  0  |   0  |
|-----|-----|------|
|  1  |  1  |   0  |
|-----|-----|------|
|  0  |  0  |   1  |
|-----|-----|------|
|  1  |  1  |   1  |
|-----|-----|------|
|  0  |  0  |   1  |
|-----|-----|------|
|  1  |  1  |   0  |
|-----|-----|------|
|  0  |  0  |   0  |
|-----|-----|------|
|  1  |  1  |   0  |
|-----|-----|------|
etc.

This matches the pattern shown by the partial TIA simulation that C. R. Bond posted at http://www.crbond.com/tia.htm, but my spreadsheet doesn't show any delays.

My spreadsheet vs. C. R. Bond's simulation (and the old TIA timing diagrams):

Edited by SeaGtGruff, Wed Dec 21, 2011 8:16 PM.