Jump to content

Smidge

New Members
  • Posts

    9
  • Joined

  • Last visited

Posts posted by Smidge

  1. On 8/5/2023 at 5:52 PM, SeaGtGruff said:

    I know this is a very late reply, but I saw this thresd and wanted to add a little to it since I spent some time several years ago trying to understand the TIA schematics and constructing an Excel spreadsheet to simulate the circuitry.

     

    Those asterisks are-- I believe-- the places where you have a signal feeding backward (or looping back) into a circuit, such that the state of the whatsit will be indeterminate or random when you first start feeding power into the TIA. That might be incorrect, but the reason I believe that that's what it means is because you see those asterisks throughout the schematics and they always occur at places where a signal from further down the line is being brought back to form a loop.

     

    When I was making my spreadsheet, each row represented a moment in time, and each column represented a transistor or gate or other thingy, beginning with the oscillator signal coming into the TIA, such that the value of cell A1 basically determined the values of the other cells on that row according to the logic associated with each column-- that is, the signal flow was A1, B1, C1, D1, E1, etc.

     

    My plan was to have each row start with a different or alternating oscillator value-- that is, A1 might be 0, then A2 would be 1, then A3 would be 0 again, etc. I actually decided to randomize the value of A1 so it could be either 0 or 1 to represent the uncertainty of what state A1 would be in at the moment the TIA powered up and started receiving the oscillator's signal.

     

    Most of the flow is in one direction, so it was easy to construct the logic for each cell. But as soon as I reached a point where a signal is being looped back I was faced with a quandry. How could I construct the logic for, say, cell H1 if one of its inputs is a line coming back from, say, cell P1, given that I haven't even coded the logic for cell P1 yet and determined its value?

     

    What I ended up doing was add a cell in front of H1 to represent the value of P1 from further along the signal flow, but actually coming from the row above, since its state had to have been determined during a prior moment in time-- that is, G2 was equal to P1, then H2 would be determined by whatever logic represented that particular circuit, then eventually I could determine what P2 was equal to and feed its value back into G3.

     

    The problem is, what to do about the very first row or moment in time? I decided to code the logic for G1 such that if we were on row 1 then we would randomly set G1 to a 0 or 1 given that we had no idea yet what its actual state should be, but if we were on any row other than row 1 then the value of G2 would be pulled from cell P1. As a result, I ended up with two rows for each state of the oscillator-- that is, rows 1 and 2 might begin with a value of 1, then rows 3 and 4 would be where the oscillator changed to a value of 0, etc. Thus, the odd-numbered rows represented the initial signal flow when the oscillator changes from 0 to 1 or vice versa, and the even-numbered rows represented the signal flow after any looped-back signals had changed their states and everything had settled down.

     

    When I did that, I noticed that everywhere I was randomizing the initial state of a signal because it was being looped back from further along the path and its value wasn't known yet, that was where those asterisks appeared in the schematics. I might be wrong about what they mean, but I genuinely believe they were put there to call attention to the places where random high/low states occur at the initial moment of powering up the TIA and the oscillator.

    That's a really interesting approach to studying the TIA and a cool find. What other observations did you make?

  2. I hadn't even heard of the Atari 7800 until I started getting into emulation and wanted to explore the games that came out from before my time. I started the 1st grade in 1995, and I had an NES I inherited from my brother, and many of my classmates had a Genesis or SNES. No one ever mentioned the Atari 7800 or the Sega Master System; it was like they didn't exist. Most of us had heard of "the Atari" as a game console from before our time, but that was definitely in reference to the 2600.

    • Like 1
  3. The easiest way to get the sprites and playfield would be to use the Stella debugger, which displays a disassembly of the binary of whatever ROM is loaded. The disassembler is smart enough to differentiate program code and graphics bytes, and it displays the graphics bytes in such a way that it is usually easy to tell which sprite is which. You could also use DiStella directly to do this since that's what the Stella debugger uses.

  4. I've finished my analysis of the output of the TIA audio circuit simulation provided by ChildOfCv and thought I'd share the results for others to reference in the future. My goal was to obtain the waveforms produced by each setting of the AUDC registers, which can be found below.

     

    How I obtained the waveforms:

    I used the logging feature of Logisim to record the output of the audio circuit for each clock. I ran the simulation at a high frequency (1 kHz) for about 10 seconds to make sure the waveform would repeat several times. I did this for each of the 16 possible values of AUDC. I then wrote a Python script to find the shortest repeating pattern of 0s and 1s for each waveform.

     

    How to read the waveforms:

    • The simulation encapsulates the audio control circuit (AUDC registers) of the TIA audio circuitry, which is positioned between the frequency divider (AUDF registers) and the volume adjustment (AUDV registers). Therefore the waveforms shown below do not include the effects of frequency division (effectively AUDF = 0, no division) or volume control (effectively AUDV = 1111, max volume). Each bit of a waveform is the output of the audio control circuit after receiving a clock signal.
    • The output is either low (0) or high (1).
    • The waveforms are the shortest repeating pattern of 0s and 1s. The period length is the number of 0s and 1s in the pattern.
    • The waveforms all start with the longest sequence of 0s in the pattern. It just came out this way because of how I wrote the Python script.
    • The AUDC values are shown in binary as D3 D2 D1 D0

    Other notes:

    • I trust the output of the simulation. I put the waveforms into my emulator and so far everything sounds like I would expect. However I doubt the games I've tested so far cover all of the possible AUDC values. I do get some occasional crackling but that's likely a problem with my implementation and not the simulation.
    • AUDC = 0000, which is described as "set to 1", sets the output to 0. Could be this means all the 0s and 1s are flipped (not that it really matters).
    • If there's anything I'm suspicious of it's the "set last 4 bits to 1" mode (AUDC = 1011) since all I got was 0s. It seems then to behave identically to the "set to 1" mode (AUDC = 0000).

     

    TIA Audio Waveforms

    AUDC = 0000 (set to 1), period length = 1
    0

     

    AUDC = 0001 (4-bit poly), period length = 15
    000011101100101

     

    AUDC = 0010 (div 15 -> 4-bit poly), period length = 465
    000000000000000000000000000000000000000000000000000000000000001111111111111111111111111111111111111111111100000000000000000011111111111111111111111111111110000000000000000000000000000000111111111111100000000000000000011111111111110000000000000000000000000000000000000000000000000000000000000011111111111111111111111111111111111111111111111110000000000000111111111111111111111111111111100000000000000000000000000000001111111111111111110000000000000111111111111111111

     

    AUDC = 0011 (5-bit poly -> 4-bit poly), period length = 465
    000000000000111110110000011010000000000001111110110000010010000000000111111000110011110110000001111111111011110010000100000011111111110011110010111100000111111111000111000010100000000111110000011111000010100000000111100111111110001110100000001111001111111000001000100000001111011110000000011011100001111111011100000001110010000001111110011000011111000110000001111110111000110000011100000001110000111001100111110000000001110111110001001100000000000111110111110001011

     

    AUDC = 0100 and 0101 (div 2: pure tone), period length = 2
    01

     

    AUDC = 0110 and 1010 (div 31: pure tone), period length = 31
    0000000000000111111111111111111

     

    AUDC = 0111 (5-bit poly -> div 2), period length = 31
    0000100101100111110001101110101

     

    AUDC = 1000 (9-bit poly (white noise)), period length = 511
    0000000001111100001000001110100011001101111101101011000100101110000110000011001001110101011011100011100100101010001110110011101110111111110111101110011110110001101010100111100100001011001000110111010111101010010110000001001101101101001000000110110010101100110011111110011100110101110010110100000001011101001110001010011010011000011100000100010111110010100100100010011111010010100000101010101111110101101010000110100010001111110001100010110110000101000101011101101111001100011110100001001001100101111000100001111

     

    AUDC = 1001 (5-bit poly), period length = 31
    0000011100100010101111011010011

     

    AUDC = 1011 (set last 4 bits to 1), period length = 1
    0

     

    AUDC = 1100 and 1101 (div 6: pure tone), period length = 6
    000111

     

    AUDC = 1110 (div 93: pure tone), period length = 93
    000000000000000000000000000000000000000000001111111111111111111111111111111111111111111111111

     

    AUDC = 1111 (5-bit poly div 6), period length = 93
    000000000011111100011111100001111111110000001111100000011110000011111111110000011100000001111

  5. 12 hours ago, ChildOfCv said:

    I created a sim of the entire audio circuit in Logisim.  I used the open-collector and transistor setup for the decoder grid.  You can see how the 2 upper bits of the AUDC register control the 4-bit register's feedback source while the lower 2 control the 5-bit register.

     

    Sound.zip 4.77 kB · 2 downloads

    That's awesome, thank you! Seeing the decoders wired up as you show them makes so much more sense. I see now that they're effectively doing NOR logic rather than AND or OR which does allow the output of that bus to be not just a constant 1 or 0. I've been playing around with the simulation for about an hour now, and I do have a few questions about how you implemented it if you don't mind.

     

    Q1. How did you know to implement each "D1" latch in the 5-bit poly as two connected D flip-flops?

    For reference, this is the first D1 cell from the schematics:

    image.png.c4a8183886447df93ef3862f4c11cea0.png

    and from the simulation:

    image.png.65878e15ae2f8d973fa0cd132f1caa4b.png

     

    Q2. What's up with this AND gate that doesn't do anything?

    image.png.7cef1f207404cc2ef569398c39cd6a5a.png

    This AND gate feeds back into the SR-latches in the 4-bit poly (I think the clock line for the latches?). By the design of the inputs it's always low. In the schematic this part looks like this:

    image.png.64ccd3981a12a425fdae39bfca56bfd5.png

    and to be honest I don't know what's going on with the lower inverter that has that extra line coming into it. The "E" indicates this part was added in a later chip revision; so did they for some reason just permanently disable this output?

     

    Q3. Why are these two transistor simulated with flip-flops instead of transistors?

    image.png.7c5d2f92c07e19c2d6eae72f29b24188.png

    image.png.90f417b9530ed3b31e9861a6747e2a63.png

  6. Thanks for the reply! Given that the circled connection represent either wired-AND or wired-OR logic and that the output of the AUDC registers are just the AUDC bits and their complements, I think I am still not reading the schematic correctly. Here is the audio bus with inputs and outputs labeled:

    image.thumb.png.6022a28f8337364c5839d48d80002ead.png

    • D0-D3 are the AUDCx bits
    • A prime ' indicates the complement (D2' = complement of D2)
    • P0-P3 are the inputs from the polynomial counter
    • Q0-Q4 are the outputs of the vertical lines (inputs to the top horizontal line)
    • S is the output of the top horizontal line

    The way I read this, assuming the circled connections represent AND logic, is:

    • S = Q0 & Q1 & Q2 & Q3 & Q4
    • Q0 = D0 & D1 & D2 & D3
    • Q1 = P0 & D2 & D3
    • Q2 = P1 & D2' & D3'
    • Q3 = P2 & D2' & D3
    • Q4 = P3 & D2 & D3'

    This doesn't seem right since S could never be 1. For S to be 1, all of the Qx must be 1. In order for Q0 to be 1, all of the Dx must be 1. But if all of the Dx are 1, then D2' = D3' = 0, and then Q2 = Q3 = Q4 = 0, and it must be that S = 0. The same issue appears if the circled connections are OR logic, but S would always be 1 and could never be 0. Where am I going wrong?

  7. I need help understanding how to read the TIA schematics, specifically the schematic for the audio circuitry (sheet 4 here). I'm struggling with some of the notation. My goal is to add audio support to my 2600 emulator, Tamera, by first recreating the audio logic in something like BOOLR so I can figure out how the cryptically named modes of AUDCx work (like wtf does "5-bit poly to 4-bit poly" mean).

     

    Question 1: What does the circle over intersecting lines mean?

    This notation appears all over the place. Here's an example:

    image.png.29c8dd00fbaed0910ed34000cc87d6f4.png

     

    Someone asked this a few years ago on Reddit and actually got a response from someone claiming to have worked on the 7800 at General Computer Company in the 80s. According to that person, the circled intersection represents a wired AND-gate as described here, with the "resistor to nowhere" being a pull-up resistor (effectively a hard-wired 1 to the wired AND-gate I think). Is it correct that these are just AND-logic?

     

    Question 2: What are the dual outputs of the audio control registers?

    Each bit of the audio control register (AUDCx) feeds into a black box with two outputs:

    image.png.36f47eb139fcb878f216100662b18724.png

    Black boxes such as these appear throughout the TIA schematics whenever a logical unit is replicated, and they are typically accompanied by a separate schematic off to the side. Examples can be found on the same schematic sheet as the audio circuit for the player graphics registers and the audio frequency registers. However there is no such explicit schematic for the audio control register. There is a similar sub-unit for the audio frequency circuit (1 input per bit with two outputs), but it is not clear whether it is the same sub-unit used for the audio control registers.

     

    Question 3: What are these, transistors?

    image.png.ac122f7424809281c3dfdc7a9d76ae90.png

    I'm referring to the two similar looking symbols that bump up and have a line over top. Are they transistors acting as switches here? Why does one have an asterisk? How can I tell if the switch is active low or high?

     

    Question 4: Why does this NOR-gate have wings?

    image.png.8c6833c25008b476fa9a47bb7e616b4e.png

    Do the extra bits that stick out on the sides have any special meaning or is it just to add room for more inputs?

     

    Question 5: Are the "5-bit poly" and "4-bit poly" circuits shown explicitly as separate units?

    The TIA documentation mentions the audio circuit uses a 9-bit shift register which does not appear to be in the schematic. However there is what looks to be a 5-bit polynomial shift register (the five D1 boxes under "AUDIO NOISE GEN.") and another 4-bit polynomial shift register on the bottom right (implemented with SR-latches). (The 5-bit feeds into the 4-bit which I suppose gives 9 bits). Are these two units the "5-bit poly" and "4-bit poly" which are mentioned in the documentation for the AUDCx registers?

    • Like 1
  8. Interesting, that means the example given in the Stella guide that setting TIM64T to 100 would cause the timer to take 6,400 cycles to reach 0 is inaccurate (it would need to be set to 101).

     

    I wrote a quick program to test this behavior on real hardware (source attached). It sets TIM64T to 1 and then immediately checks INTIM. If it's 0, the background is set to blue. Otherwise, it's set to red. I confirmed that in Stella and on real hardware the result is a blue screen. As expected my emulator incorrectly displays red, but it won't for long. :)

    timer-init-test.asm

  9. I've been writing a 2600 emulator from scratch and using Stella's debugger mode to help track down some timing issues, and I noticed something odd with how Stella handles the RIOT timer after it is initialized. In the game Dolphin, TIM64T is initialized to $30, and after the next instruction (LDY SWCHA, 4 cycles), the timer immediately decrements to $2f instead of holding the value $30 for 64 cycles. After that the timer is decremented every 64 cycles as expected. This I identified as the reason my emulator started drawing the first non-garbage frame of Dolphin one scan line later than Stella. I tend to trust that Stella is doing everything correctly, but is this actually the right behavior?

     

    To add more background, here is the relevant segment of code from Dolphin:

    f647 LDA #$30   ;2 cycles
    f649 STA WSYNC  ;3 cycles
    f64b STA TIM64T ;4 cycles
    f64e LDY SWCHA  ;4 cycles

    Immediately after STA TIM64T (scan cycle = 4), Stella sets TIM64T and INTIM to $30 and resets TIMINT and Total Clks to 0. INTIM Clks is unchanged from its previous value of 1.

    Immediately after LDY SWCHA (scan cycle = 8), Stella decrements INTIM to $2f. TIMINT remains at 0. Total Clks is now 4, and INTIM Clks in $3d.

     

    I checked another game (Adventure) and observed the same behavior. So who's right, me or Stella? (Okay obviously Stella's right, but why?)

     

×
×
  • Create New...