SeaGtGruff

Guilty as charged! It was part skill (being able to get through the skill-and-action mini-games using a stock Atari joystick) and a whole lot of luck. Those were some pretty awesome and fun times back then. It's hard to believe some 30 years have gone by since then.

Yes, that's what I'd thought after some people suggested the same thing in another thread. Thank you for verifying it. It's good to hear from someone who's knowledgeable on the subject, including the differences between the 2600's sound and the NES's sound!

Certainly I might have made a mistake in my test, and I'm not sure whether I was doing it in Stella or just making WAVEs, because at one point I was reading about the WAV file format and I wrote some test programs for generating WAV files. Anyway, it shouldn't matter whether it was a WAV file or a 2600 program, since we're talking about speaker behavior in both cases. I'll have to make some more tests, and if I get any strange (unexpected) results, I'll post the code. Until then, just assume that I was having auditory hallucinations!

If all you have are the chips then I'm not sure how you'll do it. The TIA (NTSC version) requires (expects) the following inputs to be connected to the following pins: Ground -- connected to pins 1, 21*, 22, and 24* (see Note 1) +5 volts power -- connected to pins 20 and 23 Color delay -- connected to pin 10 Oscillator signal -- connected to pin 11 (see Note 2) Data bit 0 -- connected to pin 14 Data bit 1 -- connected to pin 15 Data bit 2 -- connected to pin 16 Data bit 3 -- connected to pin 17 Data bit 4 -- connected to pin 18 Data bit 5 -- connected to pin 19 Data bit 6 -- connected to pin 33 Data bit 7 -- connected to pin 34 R/W signal -- connected to pin 25 PHI-2 clock signal -- connected to pin 26 (see Note 3) Address bit 0 -- connected to pin 32 Address bit 1 -- connected to pin 31 Address bit 2 -- connected to pin 30 Address bit 3 -- connected to pin 29 Address bit 4 -- connected to pin 28 Address bit 5 -- connected to pin 27 Input bit 0 -- connected to pin 40 Input bit 1 -- connected to pin 39 Input bit 2 -- connected to pin 38 Input bit 3 -- connected to pin 37 Input bit 4 -- connected to pin 36 Input bit 5 -- connected to pin 35 Note 1: Pins 21 and 24 are chip selects connected to two of the 6507's address lines, but if you aren't using a 6507 and have the TIA connected to something else, you could just connect these two pins to ground so the TIA will always be ready to receive instructions. Note 2: For normal operation the oscillator cycle should be 3579575 Hz. If you use a different ocillator rate it will affect the rates of the TIA's two audio clocks. Note 3: The oscillator signal is "divided by 3" to produce the PHI-0 clock signal, which the TIA sends to the 6507 via pin 4, then the 6507 sends back the PHI-2 clock signal via pin 26. So in addition to feeding an oscillator signal to pin 11, you'll also need to feed a PHI-2 clock signal to pin 26, with PHI-2 being one-third the rate of the oscillator. You should be able to ignore pin 10 (color delay) and pins 40 through 35 (the input bits), since they have no relation to the audio circuitry. And if you're going to always be writing to the TIA instead of reading from it, then you might be able to connect pin 25 (R/W) to ground so it's always set to write (I think). However, you'll need to use the address pins and data pins to set the TIA's internal audio registers to the values you want. If you're wanting to produce your own waveforms instead of having the TIA generate them, you should set AUDC0 and AUDC1 to 0, which will tell the TIA to output a steady stream of 1s for the audio bits. Then you would need to repeatedly set the AUDV0 and AUDV1 registers to form your own waves by varying the volume. On the other hand, if you're wanting the TIA to generate the waveforms then you'll need to use AUDC0 and AUDC1 to select the desired waveforms, use AUDF0 and AUDF1 to select the desired frequencies, and use AUDV0 and AUDV1 to select the desired volumes. The only way to set these registers is to send the appropriate address values over the address lines and send the desired data values over the data lines. Presumably the only output pins you'll be interested in are pins 13 and 12 (AU0 and AU1, the two audio outputs). In the console these go to a modulator.

I had actually gotten that impression from your original post! Which begs the question, how do you handle the cases where the paddle is transitioning from a horizontal edge to a vertical edge or vice versa? It would be cool if the paddle bends like an L in those cases.

Yes, it's still broken with the parentheses. The variable has to come first or the compiler doesn't handle it correctly. Here's an example: include div_mul.asm a = 5 b = 10 * a score = 0 for c = 1 to b : score = score + 1 : next scorecolor = $0E loop drawscreen goto loop The score displays 90. include div_mul.asm a = 5 b = a * 10 score = 0 for c = 1 to b : score = score + 1 : next scorecolor = $0E loop drawscreen goto loop The score displays 50 as expected. Here's the compiled assembly code for 10 * a: .L02 ; b = 10 * a LDA #10 ; <--- here's where the problem is asl asl clc adc a asl STA b Here's the compiled assembly for a * 10: .L02 ; b = a * 10 LDA a asl asl clc adc a asl STA b

Granted. I *am* updating only once each frame-- I'm not trying to split it smaller than a frame. I was just counting in color clocks per frame and then comparing it to color clocks per second to try to keep things on an integer basis. But since I don't know whether the 3579575 Hz value is rounded or truncated or whatever, I guess trying to stick with integers is pointless. How's this instead? The fraction represents 59736 / 3579575 stored as a 32-bit FP number in little-endian order-- or really 40 bits, since it's just the portion after the decimal, with the other 8 bits being the byte of RAM for the seconds. CLC LDA counter ; LSB of a 4-byte counter in RAM, stored little-endian ADC fraction ; LSB of the fraction (see below) STA counter LDA counter+1 ADC fraction+1 STA counter+1 LDA counter+2 ADC fraction+2 STA counter+2 LDA counter+3 ADC fraction+3 STA counter+3 LDA seconds ; the 5th byte ADC #0 ; only the carry is added STA seconds CMP #60 BCS Increment_Minutes JMP .Main_Loop Increment_Minutes LDA #0 STA seconds INC minutes LDA minutes CMP #60 BCS Increment_Hours JMP .Main_Loop Increment_Hours LDA #0 STA minutes INC hours LDA hours CMP #24 BCS Clear_Hours JMP .Main_Loop Clear_Hours LDA #0 STA hours JMP .Main_Loop fraction ; 59736/3579575 HEX 6D AA 45 04 ; 4/256 + 69/256/256 + 170/256/256/256 + 109/256/256/256/256 I don't trust my math right now, but I think this might be accurate for 1200+ years? Assuming the fraction is correct and the frame rate is steady.

This is slightly off-topic from the original question, but I just wrote a little batari Basic program for the Atari 2600 with some inline assembly to count and display seconds, minutes, and hours based on the number of color clocks per frame and color clocks per second. The inline assembly routine is applicable to the Atari 8-bit computers. I chose color clocks because I don't think floating point numbers are (generally speaking) as accurate as mixed numbers with integer parts-- e.g., 5.33333333 is an imperfect expression of 5 and 1 / 3. And rather than deal with whole frames and a fraction of a frame, I decided it was simpler to just use color clocks per frame and color clocks per second. This assumes (rightly or wrongly) that the oscillator rate shown on the Atari 2600 schematics-- 3579575 Hz-- is an exact integer value, as opposed to having some fractional part that's been rounded or truncated. I use two 3-byte values stored in ROM-- the number of color clocks per frame (59736) and color clocks per second (3579575), both stored in little-endian order. I use three bytes of RAM to count the number of color clocks after each frame, and three more bytes of RAM to store the seconds, minutes, and hours. After a frame is drawn I add the clocks per frame to the counter, then compare the result to the clocks per second. If the counter is equal to or greater than the clocks per second, I subtract the clocks per second from the counter and increment the seconds, adjusting the seconds, minutes, and hours as needed. I haven't run it on a real console yet to see how accurate it is, but it seems accurate enough in an emulator (although it's slightly fast because the emulator draws each frame at 60 Hz rather than at the actual frame rate of circa 59.92 Hz. For PAL the numbers for the Atari 2600 should be 71136 (color clocks per frame) and 3546894 (color clocks per second). I'm not sure what the numbers should be for the Atari 8-bit computers-- most of the references I've seen online say the oscillator for the NTSC model is 3579545 Hz (presumably with a .45 repeating 45 after that), although one post at AtariAge says "the 400 schematic clearly shows 3,579,575 MHz" (sic). I haven't seen the Atari 400 schematics (or 800, etc.), but if Atari used an oscillator rate of 3579575 Hz for the NTSC 2600 then I suppose they might have used the same rate for their NTSC 8-bit computers. Anyway, here's the inline assembly portion of my program with a few comments, in case anyone wants to try it for the 8-bit computers. Adjust the color clock values as you deem necessary: CLC LDA color_clocks ; LSB of the counter ADC per_frame ; LSB of the color-clocks-per-frame STA color_clocks LDA color_clocks+1 ADC per_frame+1 STA color_clocks+1 LDA color_clocks+2 ; MSB of the counter ADC per_frame+2 STA color_clocks+2 CMP per_second+2 ; MSB of the color-clocks-per-second BCS Check_Color_Clocks_1 JMP .Main_Loop ; not yet equal or greater, so exit-- .Main_Loop was too far away to branch to so I had to reverse the compare and jump instead Check_Color_Clocks_1 BNE Reduce_Color_Clocks ; greater, so no need to check the other bytes LDA color_clocks+1 ; equal, so need to check the next byte CMP per_second+1 BCS Check_Color_Clocks_2 JMP .Main_Loop Check_Color_Clocks_2 BNE Reduce_Color_Clocks LDA color_clocks CMP per_second BCS Reduce_Color_Clocks JMP .Main_Loop Reduce_Color_Clocks ; subtract the clocks-per-second from the counter SEC LDA color_clocks SBC per_second STA color_clocks LDA color_clocks+1 SBC per_second+1 STA color_clocks+1 LDA color_clocks+2 SBC per_second+2 STA color_clocks+2 INC seconds ; now increment the seconds LDA seconds CMP #60 BCS Increment_Minutes JMP .Main_Loop Increment_Minutes ; adjust for 60 seconds LDA #0 STA seconds INC minutes LDA minutes CMP #60 BCS Increment_Hours JMP .Main_Loop Increment_Hours ; adjust for 60 minutes LDA #0 STA minutes INC hours LDA hours CMP #24 BCS Clear_Hours JMP .Main_Loop Clear_Hours ; roll the hours LDA #0 STA hours JMP .Main_Loop per_frame ; color clocks per frame (NTSC) HEX 58 E9 00 ; 59736 in little-endian per_second ; color clocks per second (NTSC) HEX B7 9E 36 ; 3579575 in little-endian Obviously that's a lot of work if you don't care about keeping exact time-- much simpler to just count frames!

I don't know if this has been reported yet, but there's a bug in the handling of complex math statements. The following doesn't work correctly: tens = number / 10 ones = number - 10 * tens Specifically, "10 * tens" doesn't compile correctly. You have to flip it around like so: ones = number - tens * 10

It would, but it might be simpler to just simulate the logic of the audio circuitry. I've been using Excel to simulate portions of the TIA at the gate level with a spreadsheet-- an interesting exercise in self-induced madness, perhaps, but more convenient than using paper and pen, and quicker for me than writing an emulator from scratch. I've completed most of the first sheet of the schematics-- I got up through the playfield drawing but put it aside partway through the HMOVE logic-- and I've also done all or most of the audio logic. I'll see what I can find out by plugging in different starting values. Regarding the question of whether inverting a wave pattern makes a difference, I doubt it makes any appreciable difference for complex waves, but I'm not so sure about simple waves-- in particular, a pulse wave where the duty cycle isn't 50%. A year or two ago I wrote a simple program to generate a single frequency using a pulse wave. Then I varied the duty cycle of the pulse wave. I wanted to see how the duty cycle affected the sound (in terms of subharmonics), but I was also curious whether two pulse waves that are inversions of each other-- say, with duty cycles of 20% and 80%-- sound the same. If I remember correctly, the inversions did sound alike, but there was a noticeable difference in sound volume. However, the TIA doesn't generate any pulse waves with such an extreme difference in duty cycles. The AUDCx=6 wave has a duty cycle of either 41.9% or 58.1% (it's one of the waveforms that can definitely be seen to flip-flop between 18-13 and 13-18 in the recording I made), but that probably isn't extreme enough for any appreciable difference in sound volume.

It's good to see you posting here! I was thinking the same thing about the toggling, because of the way some of the other patterns in my recording were inverted when I played them at different frequencies. But other patterns were always the same. Although come to think of it, that's probably because they're always preceded by AUDCx=0 or AUDCx=11 in my test program, so they're always starting from a previous output of 0.

I think the emulation of the clocks can be simplified if it's assumed that a RESET PHI-0 signal has already occurred. What I've seen via my spreadsheet is that the PHI-0 clock can start up "out of step" on the very first scan line after powerup-- i.e., as if it's marching left-right-left when it should be marching right-left-right, to use an analogy. The two audio clocks can also be out of sync on the very first scan line due to the randonmess of the horizontal sync counter at powerup. And the initial state of the horizontal sync counter can be unrelated to the second state, since the two gates driven by H-PHI-1 and H-PHI-2 inside each bit of the LFSR have separate random values on powerup. When the first RESET PHI-0 signal occurs-- triggered by the horizontal sync counter being reset-- the PHI-0 clock is forced into the proper sync, which can result in one or two hi/lo phases being temporarily longer or shorter than usual-- like a soldier momentarily either prolonging his steps or quickening his steps to get into time with everyone else. Since the first RESET PHI-0 signal will (I think) occur no later than 227 color clocks after powerup (depending on the second state of the HSC), and since most games perform an initialization routine on powerup anyway, it's okay to assume that everything is already in proper sync at powerup. I think the place where emulating the clocks as accurately as possible will be most critical will be with the audio clocks, along with emulating the frequency dividers and audio LFSRs accurately.

I think the biggest issues you're running into with the audio are that changes to the frequency registers can take a while to propagate in some cases, and changes to the control registers might also take a few bits before the new pattern starts to get output-- the frequency being the larger issue.

I honestly don't know how to answer that-- it's way beyond my limited area of expertise!

I can't offer any hardware or technical help, but there has been at least one MIDI interface for the 2600-- possibly two, although I can't find any solid information about the second one. I think the schematics and such for the first one (which is listed in the AtariAge store) were posted on the guy's web site after he decided to discontinue selling it-- if you search for MIDI and Atari 2600 together you should be able to find it. That interface used a standard MIDI plug, then connected to the 2600 via the two controller ports, since the two joysticks are read from the same address and by reading the two joystick inputs together you get an 8-bit value ranging from 0 to 255.

When I assemble your attached code and run it in Stella, the Stella debugger shows that player0 is positioned at pixel 15 ($0F) and player1 is positioned at pixel 23 ($17), which are 1 pixel to the left of where you said you wanted them. I also see that when you call the sprite positioning loop you're saying you want player0 to be at position 28 and player1 to be at position 36. So there's a 13-pixel difference between the position you have to feed to the positioning routine and the actual screen pixel position that will result. If I change the positioning values to 29 (16+13) and 37 (24+13), the Stella debugger shows that the sprites are at pixels 16 ($10) and 24 ($18), and the 48-pixel sprite is displayed as intended. But this raises the question-- when you said you wanted the sprites to be at positions 16 and 24, did you mean those to be the pixel positions (pixel 0 being the first visible pixel after a normal HBLANK) or the positions that get fed into the positioning routine?

The "seconds" will be off a little bit due to the Atari's frame rate. It's close enough for casual work, but if you're trying to keep accurate time then you'll need to adjust the seconds every so often keep it in sync with "real world" clocks.

I like the idea of a gate-level emulation, although it wouldn't necessarily need to emulate *every* gate-- for example, there are places where there are two or three inverters in a row, with the second and third usually forming a "super inverter" if I understand correctly, so there's no overall effect on the logic, just on the signal level and/or rise-fall timing (again, if I understand correctly). I've actually been piddling around off and on (no pun intended) with a spreadsheet simulation of the TIA, so I've had to teach myself how to read the schematics-- but sadly, that means my teacher only knows as much as I do! It would be interesting to emulate the TIA at the core level, because then the randomness of its initial state could be emulated as well. For example, my spreadsheet has helped me to see that the phi-0 output doesn't "settle down" to a proper signal until the horizontal position counter gets reset and triggers a "reset phi-0" signal (which explains why that "reset phi-0" signal line is needed in the first place). Also, the first two states of the horizontal sync counter (and likewise the other counters) can be disconnected or out-of-sequence-- by which I mean the second state isn't determined by the first state, since each "bit" of the counter is driven by an H-phi-1 gate and an H-phi-2 gate, with each gate having a separate random initial state, hence the first pattern of bits (determined by the random settings of the H-phi-2 gates) and the second pattern of bits (determined by the random settings of the H-phi-1 gates) don't necessarily follow the normal sequence, although the sequence does proceed normally from the second bit pattern onward. However, there's a possible problem with a gate-level emulation-- namely, signal delays due to cumulative gate delays, plus the delay between the outgoing phi-0 signal and the incoming phi-2 signal. This can probably be worked around by using the TIA timing diagrams for the critical spots, but the point is that some of the signals will be out of synch with each other, since they don't change states at the same times. To be accurate, I think the emulation should simulate all of the TIA's inputs and outputs. I see there's been mention of the graphics objects, but don't forget the blanking signal, sync signal, lum signals, and color signal, as well as the two audio signals, plus the ready signal, etc.

What I'd like to do is put the wave in (expansion) RAM so new waveforms can be created dynamically, such as combining different harmonics.

I don't know if "freeform" is quite accurate, because as I understand it you must define the waveform first.

Let me know if my proposed .spriteLoop works out for you. I forgot to mention, you'll need to set tempY to the number of lines you want to draw (presumably 8 ) before entering the loop for the first time, since the loop decrements tempY rather than incrementing it. And since it stops when tempY reaches 0, you'll need to start your data tables with a dummy byte, since the loop as written will draw the data from offset 8 through offset 1, but not the data at offset 0, if you follow me. An alternative is to change the last line of the loop to a BPL instead of BNE, which will keep looping through tempY = 0 but stop when tempY = 255. If you do that you won't need to start the data tables with a dummy byte, and you can initialize tempY to 7 instead of 8. The only reason I used BNE was because it works better in cases where your data tables are 129 bytes or longer, since initializing tempY to 129 or higher will get you through the loop once but then it will exit when tempY decrements from 129 to 128 (or from 130 to 129, etc.), since 128 (or 129, etc.) is considered to be a negative value since bit 7 is on. In your case, BPL is okay, since tempY would be initialized to 7 if you want to draw 8 lines. But should you decide you want to draw a really tall 48-pixel sprite-- 129 lines or taller-- then you'd want to use BNE.

I haven't tested it, but I think the following loop should handle it. This assumes that player0 is positioned at 16 and player1 is positioned at 24, that "Color" is a table of colors stored in ROM like you've got the sprite data, that the colors and graphics data are stored upside down (since the loop decrements the index), that no page crossings occur, and that you enter the loop at cycle 49. .spriteLoop ; 49 ldy tempY ; 3 ; 52 lda Color,y ; 4+ ; 56 sta COLUP0 ; 3 ; 59 sta COLUP1 ; 3 ; 62 lda Graphics1,y ; 4+ ; 66 sta GRP0 ; 3 ; 69 lda Graphics2,y ; 4+ ; 73 sta GRP1 ; 3 ; 00 lda Graphics3,y ; 4+ ; 04 sta GRP0 ; 3 ; 07 lda Graphics4,y ; 4+ ; 11 sta temp2 ; 3 ; 14 lda Graphics5,y ; 4+ ; 18 tax ; 2 ; 20 lda Graphics6,y ; 4+ ; 24 tay ; 2 ; 26 lda temp2 ; 3 ; 29 sta GRP1 ; 3 ; 32 stx GRP0 ; 3 ; 35 sty GRP1 ; 3 ; 38 sty GRP0 ; 3 ; 41 dec tempY ; 5 ; 46 bne .spriteLoop ; 2++ ; 48++

The error is saying that the "processor 6502" line has an error in it-- there's a backslash at the end ("processor 6502\"). Remove the backslash and try assembling again. Note that different computer operating systems (Windows, Unix, Mac, etc.) may use different line termination characters. If you take a text file that was created in one operating system and try to use it in another operating system, you may need to use some kind of conversion program to change the line termination characters. For example, DOS and Windows use a carriage return-line feed (CR-LF) combination, hex characters $0D and $0A. Unix and Linux use line feed (hex $0A) by itself. I think Mac uses carriage return (hex $0D) by itself. When you try to use a text file from one operating system and try to use it in a different operating system, the extra (or missing) characters can create problems, such as lines that run together rather than being separated properly, or extra characters that show up at the end of each line. I don't know if this is part of why you're having trouble, but if you open the clock.asm file and it doesn't look right (it should be just a simple text file), try converting it to use the Mac's line termination characters. There are lots of little utility programs out there for that. Also, make sure you're using the Mac version of dasm.

I'd guess this is related to the scrolling of the playfield in gyvolver, and/or to the size of the playfield rows.

I guess it must be a combination of things, then. There are a lot of other differences between the three versions, so it's hard to know exactly what's causing it. Could you post a binary of the ROM so we can follow it in Stella's debugger?