Authentic sound and game play

[Mr SQL]

I think one difficulty in emulating TIA sound is that the analougue oscillators can only be simulated; this seems similar but not as severe as c64 SID emulation where the filters too can only be simulated.

 

I suspect the other noticeable differences between emulation and gameplay/feel compared to playing on a real Atari 2600 are due to other portions of the system architecture that can only be simulated and not emulated.

 

If we were playing 1972 Odyssey games on current hardware it would be 100% simulation despite the best programming efforts. Conversely we can play N64 games in an emulator with a very close feel to the original with differences limited only by the skill of the programmer.

 

I think Stella is fantastic and does a great job of reproducing the 2600 experience with a very authentic feel, but that there is no such thing as an Atari 2600 emulator

[+stephena]

I agree to a certain extent, but probably not for the reasons you're thinking. There's nothing 'magical' about the original hardware that can't be properly emulated given enough time, knowledge, and the proper environment. There are two main things acting against Stella (or really any emulator) in this area; experience and environment.

 

For the former, I can honestly say that in some areas of the emulation I've reached my level of experience. This is particularly true for sound reproduction. I make no claims to be an expert in that area. In fact, I'm a neophyte when it comes to sound, and partly tone-deaf. So any improvements that will happen in that area will have to come from someone else. But I think there can be improvements, up to the limit of the hardware you're using. Which leads to the second point.

 

Emulating a real-time console on a non-real-time OS will always be a series of compromises. And emulating a system at the logic level vs. the transistor level will always be inadequate unless you're willing to devote massive resources (both in developer time and a faster computers) to the task.

 

Anyway, I could go on for pages about how Stella could be improved if we had more developers, more time, and more control of the end-user environment. For the latter in particular, Stella generally performs better in Linux than in Windows, so right off the bat that's proof that the OS complicates things. I have many ideas on how to improve the emulation, but unfortunately will never have the time (and in some cases skill) to implement them all. But IMO many of the things that cause Stella to be 'not quite right' are due to the environment you're running in, and compromises that had to be made in the code due to that environment.

[Mr SQL]

stephena,

excellent post and many great points except environment; a programmer can't throw this card today. Maybe 20 years ago when some users still had a 386 running at 33 mhz. But todays slowest windows systems processors all run over 1000 mhz and any end user with a web browser is all too keenly aware that just about any app can easily enter kernel mode and ursurp 99% of the CPU making the system look and feel like OS9 (the apple one that locks up and doesn't share the MPU, not the cool multi-tasking OS for the 6809)

 

I agree with all of the rest of your points, these in particular:

"Emulating a real-time console on a non-real-time OS will always be a series of compromises. And emulating a system at the logic level vs. the transistor level will always be inadequate unless you're willing to devote massive resources (both in developer time and a faster computers) to the task."

 

Too true; if we look to the SID example, synth design later branched from subtractive analougue and only recently have synthesizers become powerful enough to match digitally what the SID could do with it's analougue parts.

No serious artist wants a moon machine because you can't emulate a SID (at least not without an inordinate amount of processing power) so what you get in practice is simulation.

Today's chart topping recording artists know how to steal borrow SID's to incorporate that phat sound into their music, but they all use the Electron SIDStation which is rare as it's no longer mfr'd due to chip scarcity. Electron tries to push their moon machine simulator but it's just not the same - your other points apply here though as well: throw enough processer power and developers into the mix and they could design a really expensive supercomputer to emulate the sid.

 

This won't happen anytime soon and I still enjoy SID simulation, but a 6581 device is on my list to acquire. PlaySID and TinySID are really cool too and I listen to SID's with them on various devices including a walkman (RockBox has TinySID) but I still want a real SID chip because it has a phatter sound.

 

Likewise I enjoy playing games in Stella - it's fantastic and tremendously cool because it brings the 2600 to so many platforms! Like with the SID though the real hardware has phatter sound and gameplay

[RevEng]

I think one difficulty in emulating TIA sound is that the analougue oscillators can only be simulated... [snip] ...there is no such thing as an Atari 2600 emulator

 

I think your premise here is flawed... TIA sound isn't based on analogue oscillators, it's based on digital counters.

 

There are some complications to emulating the sound, but it's not impossible.

[Mr SQL]

I think one difficulty in emulating TIA sound is that the analougue oscillators can only be simulated... [snip] ...there is no such thing as an Atari 2600 emulator

 

I think your premise here is flawed... TIA sound isn't based on analogue oscillators, it's based on digital counters.

 

There are some complications to emulating the sound, but it's not impossible.

RevEng,

I disagree; TIA sound is generated from oscillators; these resonant circuits are analougue despite being digitally controlled (waveform, frequency and volume). The digital control aspects can be emulated but baring immense resourses the analougue circuitry will only be simulated like with the (entire) Odyssey.

[+stephena]

stephena,

excellent post and many great points except environment; a programmer can't throw this card today. Maybe 20 years ago when some users still had a 386 running at 33 mhz. But todays slowest windows systems processors all run over 1000 mhz and any end user with a web browser is all too keenly aware that just about any app can easily enter kernel mode and ursurp 99% of the CPU making the system look and feel like OS9 (the apple one that locks up and doesn't share the MPU, not the cool multi-tasking OS for the 6809)

 

This isn't a cop-out. I don't mean the raw speed of the computer; I was referring to the non-real-time aspect of it. If I want something done 2 milliseconds from now, and the system responds 3 milliseconds later, it doesn't matter that it can do 10 million things before the next timeslice. Real-time is concerned with guarantees, not raw processing speed. It's more a matter of timing than raw computation speed. If speed were the only issue it wouldn't be a problem, since Stella originally ran on a fast 486. The jitter you see when playing a game in Stella with software rendering is because the screen refresh isn't synchronized to the monitor refresh rate. In other words, a timing problem. And when something starts in the background and visually interrupts Stella, again a timing problem. Then there's reading from USB controllers; latency is introduced, which again is timing.

 

If I ask for (and absolutely need) a dollar right now, and you respond that you can give me $1000 1 minute from now, then for all intents and purposes that's useless. What I can get in the future is irrelevant if I can't get what I need right now.

 

If I could take control of an environment, lock out all other programs, tie the emulation to the underlying 60Hz refresh rate of the monitor, and directly read from controllers, I can almost guarantee that many (most?) people would never know it was emulation. The fact that Stella can perform better in one OS environment than another (Linux vs Windows) is proof that the environment is an important variable. I'm not sure exactly why, but I suspect that Linux can respond to requests faster than Windows; again, a timing issue.

[RevEng]

RevEng,

I disagree; TIA sound is generated from oscillators; these resonant circuits are analougue despite being digitally controlled (waveform, frequency and volume). The digital control aspects can be emulated but baring immense resourses the analougue circuitry will only be simulated like with the (entire) Odyssey.

 

TIA sound is based on the system clock being fed into frequency dividers and a combination of LFSRs. There are no analogue oscillators, digitally controlled or otherwise.

[Mr SQL]

RevEng,

I disagree; TIA sound is generated from oscillators; these resonant circuits are analougue despite being digitally controlled (waveform, frequency and volume). The digital control aspects can be emulated but baring immense resourses the analougue circuitry will only be simulated like with the (entire) Odyssey.

 

TIA sound is based on the system clock being fed into frequency dividers and a combination of LFSRs. There are no analogue oscillators, digitally controlled or otherwise.

RevEng,

the system clock is also an oscillator, quartz analougue

 

And as per the wiki entry:

 

The TIA is capable of generating different flavors of pulse and noise out of its two oscillators (or channels) AUD0 and AUD1. Each oscillator has a 5-bit frequency divider and a 4-bit audio control register which manipulates the waveform. There is also a 4-bit volume control register per channel.

 

http://en.wikipedia....terface_Adaptor

[SeaGtGruff]

RevEng,

I disagree; TIA sound is generated from oscillators; these resonant circuits are analougue despite being digitally controlled (waveform, frequency and volume). The digital control aspects can be emulated but baring immense resourses the analougue circuitry will only be simulated like with the (entire) Odyssey.

 

TIA sound is based on the system clock being fed into frequency dividers and a combination of LFSRs. There are no analogue oscillators, digitally controlled or otherwise.

Don't forget, the audio output from the TIA is fed into a frequency modulator before being output to the TV. The actions (or results) of the frequency dividers and LFSRs can be emulated quite easily, but I have no idea how easy or difficult it is to emulate the effects of the frequency modulator. Also, changing the frequency division and the LFSR controls don't necessarily have an "instant" effect in the TIA, whereas (I think) emulators probably change the frequency or LFSR output immediately upon executing an instruction.

 

Getting back to issue of analog versus digital, I'll repeat something I'd mentioned in other threads about TIA sound. Last year I wrote a simple batari Basic program that plays all possible AUDF0/AUDC0 combinations at full volume, each sound being held for (IIRC) 7 seconds before changing to the next sound. For design reasons I went through all the AUDC0 settings for each AUDF0 setting, then switched to the next AUDF0 setting and went through all the AUDC0 settings again. This worked out great for my purposes, because it's easy to see where the AUDC0 changes occur. Then I played the program on my 2600 and recorded the output on a DVD at the highest audio sampling rate. Then I ripped the audio from the DVD to WAV files on my computer. Finally, I used the free version of WavePad to look at the WAV files.

 

I was initially surprised to see that the waveforms aren't pulses as I'd expected, but instead are curves. I don't know if this is the result of the audio signal being processed by the frequency modulator, or perhaps some effect of the recording process, but it made perfect sense when I thought about it. For example, consider AUDC0=0 and AUDV0=15. In theory, the audio output is a constant high (bit 1) at the highest possible amplitude, but in reality the resulting output is-- silence. Not right away, since there's a tiny moment of sound when you switch from AUDV0=0 to AUDV0=15; but then the sound fades to silence, so quickly that you can't even tell there *was* a sound-- although in WavePad you can see the signal jump up when the sound begins and then "slowly" (over several fractions of a second) fade to 0. So inside the TIA you have a constant signal of 1 (or 15, if you multiply it by the volume setting)-- but outside the TIA you get no noticeable sound.

 

The same applies to the waveforms from the LFSRs. For example, if you use AUDC0=4 to get a "pure" sound, the internal waveform is 101010101 etc.-- a perfect square or rectangular pulse wave. But when you look at the result outside of the TIA, the change from 0 to 1 makes the signal jump up, but it starts to decay the longer the 1 is held; then the change from 1 to 0 makes the signal jump down below the middle line, but it starts to decay (move back toward the middle) the longer the 0 is held; then it jumps up again when the 0 changes to 1; and so on. So what you actually see when you look at the waveform of the output (not the internal TIA signal) is a series of rounded waves. The actual shape will vary depending on how long each 1 and 0 are held-- the waveform may look almost like a sine wave, or it may look more like a rectangular wave with rounded corners, or it may even look more like a sawtooth wave. Furthermore, the amplitude of each crest and trough can vary depending on how long the 1 or 0 was held-- the longer it's held, the greater the jump when it changes from 0 to 1 (or from 1 to 0); and likewise, the shorter the duration, the smaller the jump when it changes.

 

I honestly don't know how this translates to emulation. I haven't tried creating a WAV file with a constant high, but I presume that it would be "silent" as well, since the pressure on the speaker is constant rather than pulsating, and it's the pulsations of the speaker that creates the sounds. But I imagine that there's some sort of audio difference between two WAV files, where one WAV file is a steady variation between 0 and 255 (true pulse wave), and the other WAV file is a steady sweep between 0 and 255 (like the output I got from my DVD recording).

[Mr SQL]

stephena,

excellent post and many great points except environment; a programmer can't throw this card today. Maybe 20 years ago when some users still had a 386 running at 33 mhz. But todays slowest windows systems processors all run over 1000 mhz and any end user with a web browser is all too keenly aware that just about any app can easily enter kernel mode and ursurp 99% of the CPU making the system look and feel like OS9 (the apple one that locks up and doesn't share the MPU, not the cool multi-tasking OS for the 6809)

 

This isn't a cop-out. I don't mean the raw speed of the computer; I was referring to the non-real-time aspect of it. If I want something done 2 milliseconds from now, and the system responds 3 milliseconds later, it doesn't matter that it can do 10 million things before the next timeslice. Real-time is concerned with guarantees, not raw processing speed. It's more a matter of timing than raw computation speed. If speed were the only issue it wouldn't be a problem, since Stella originally ran on a fast 486. The jitter you see when playing a game in Stella with software rendering is because the screen refresh isn't synchronized to the monitor refresh rate. In other words, a timing problem. And when something starts in the background and visually interrupts Stella, again a timing problem. Then there's reading from USB controllers; latency is introduced, which again is timing.

 

If I ask for (and absolutely need) a dollar right now, and you respond that you can give me $1000 1 minute from now, then for all intents and purposes that's useless. What I can get in the future is irrelevant if I can't get what I need right now.

 

If I could take control of an environment, lock out all other programs, tie the emulation to the underlying 60Hz refresh rate of the monitor, and directly read from controllers, I can almost guarantee that many (most?) people would never know it was emulation. The fact that Stella can perform better in one OS environment than another (Linux vs Windows) is proof that the environment is an important variable. I'm not sure exactly why, but I suspect that Linux can respond to requests faster than Windows; again, a timing issue.

stephena,

all excellent points again; Windows users very often have their system cluttered with apps that do as you described, suddenly taking the lions share of the CPU. Programs that follow proper design protocol are preempted but it is possible for the user (via task manager process list) to designate Stella as "master control" giving it priority over all the other apps.

 

I don't doubt Linux has a more responsive USB polling driver; one way to get around this in Windows write your own faster low level USB driver in Assembly or load the existing kludge driver into your process space so it can join master control like Sark

 

I think stella is fantastic and by far the best 2600 experience aside from an Atari.

[RevEng]

the system clock is also an oscillator, quartz analougue

 

I guess the 6507 should be reclassified as an analogue CPU then.

 

IMO the wikipedia article is wrong to say that TIA has two oscillators. They're channels, and the system clock is the source of oscillation, if one wants to say anything is. Really, since clock division and LFSRs are digital operations it doesn't even seem right to say that much.

 

Even if I grant the oscillator definition that the wiki entry uses, it doesn't mention anything about the analogue oscillators you were speaking of.

 

 

Don't forget, the audio output from the TIA is fed into a frequency modulator before being output to the TV...

 

For sure... this is one of the complications I was thinking of, in my original post. I see it as analogous to the issue of emulating NTSC and CRT video effects. I guess one could write something like the blargg filters except for audio, or run their emulator audio through an FM modulator+demodulator for authenticity.

 

Regarding pulses being curved off, I'm wondering if you're not just seeing the effect of DC filter caps in the audio chain... that's what it sounds like.

[SeaGtGruff]

Don't forget, the audio output from the TIA is fed into a frequency modulator before being output to the TV...

 

For sure... this is one of the complications I was thinking of, in my original post. I see it as analogous to the issue of emulating NTSC and CRT video effects. I guess one could write something like the blargg filters except for audio, or run their emulator audio through an FM modulator+demodulator for authenticity.

 

Regarding pulses being curved off, I'm wondering if you're not just seeing the effect of DC filter caps in the audio chain... that's what it sounds like.

I don't know anything about DC filter caps (capacitors?), so I can't say. But the effect I'm seeing makes sense to me as far as what (little) I know about sound, so I figured it's because I recorded the auditory result of the wave (or something like that), and not the original signal itself-- if that makes sense.

 

Here are some screenshots from WavePad to show what I'm seeing. The program ran for about an hour-- 7 seconds per combination, times 512 combinations (32 AUDF0 settings times 16 AUDC0 settings), is 3584 seconds-- and I let it start repeating (I recorded until the DVD filled up at the 1-hour quality). The program starts with AUDC0 at 0 but also with AUDV0 at 0 (both set to 0 by batari Basic in the zero-page-clearing routine), then when you press RESET it sets AUDV0 to 15 and begins cycling through the combinations. The batari Basic code is provided in case anyone is interested.

 

  rem * TIA Sound Test, by Michael Rideout
  rem *-------------------------------------------------------------
  rem * Play 7 seconds of sound for each AUDC/AUDF combination.
  rem * The total time required is about 1 hour.
  rem * A black screen indicates it hasn't started yet.
  rem * Press the RESET switch to begin.
  rem * A green screen indicates it's the first time through.
  rem * A red screen indicates it's repeating (so stop recording).
  rem * The score shows the AUDC setting (the first two digits),
  rem * followed by the AUDF setting (the next three digits),
  rem * followed by the seconds (the last digit).
  set romsize 2k
  dim frms = a
  dim secs = b
  dim audc = c
  dim audf = d
wait
  if switchreset then begin
  drawscreen
  goto wait
begin
  COLUBK = $C6
  scorecolor = 15 : AUDV0 = 15
loop
  AUDC0 = audc
  AUDF0 = audf
  score = 0
  if audc > 0 then for i = 1 to audc : score = score + 10000 : next
  if audf > 0 then for i = 1 to audf : score = score + 10 : next
  if secs > 0 then for i = 1 to secs : score = score + 1 : next
  drawscreen
  frms = frms + 1
  if frms = 60 then frms = 0 : secs = secs + 1
  if secs = 7 then secs = 0 : audc = audc + 1
  if audc = 16 then audc = 0 : audf = audf + 1
  if audf = 32 then audf = 0 : COLUBK = $46
  goto loop

 

Anyway, this first screenshot shows the moment at which AUDV0 is first set to 15 with AUDC0 set to 0, so the output is going from waveform 11111 (all 1s) at amplitude 0 to 11111 at amplitude 15. You can see the line jump up, but then it immediately starts to decay and even swings below the central line before leveling out at silence. All this happens very quickly-- as you can see by the labels at the bottom of the window, each tick is 0.01 seconds apart.

 

 

The next three screenshots show AUDC0=2, which has a waveform like AUDC0=1 (the 4-bit LFSR pattern), but each 0 or 1 in the wave pattern is held for either 13 or 18 audio clocks-- which averages to 15.5, or "division by 15" as the TIA manual describes it. You can see how the overall pattern repeats, but alternates between two variations depending on which bits are held for 13 clocks and which are held for 18 clocks. The first screenshot is AUDF0=0; the second is AUDF0=1; and the third is AUDF0=2. You can see that the longer the output is at 0 or 1, the more the wave starts to look like a curved triangular wave. You can also see that the amplitude of each crest or trough varies depending on how long the previous value (0 or 1) was held.

 

 

 

 

The last three screenshots show AUDC0=4, which has the 101010 waveform ("division by 2"). The first screenshot is AUDF0=0; the second is AUDF0=15; and the third is AUDF0=31. You can see that at AUDF0=0 the amplitude is so low that you can barely see the wave. (All the screenshots use the same level of magnification both vertically and horizontally.) At AUDF0=15 the waveform looks a bit like a tight sine wave. But by AUDF0=31 the peaks and valleys have lost their sine-like curvature and show some decay.

 

 

 

[Thomas Jentzsch]

Those are some quite interesting results. If they would be used in Stella, that would probably improve the sound emulation quite a bit.

 

Did you have a chance to verify the results with other consoles/models (what model were you using?)? And have you verified that those decays are not resulting from recording?

[RevEng]

I don't know anything about DC filter caps (capacitors?), so I can't say. But the effect I'm seeing makes sense to me as far as what (little) I know about sound, so I figured it's because I recorded the auditory result of the wave (or something like that), and not the original signal itself-- if that makes sense.

 

Based on your screen shots, I'm very sure it's just DC filtering capacitors in the audio chain. Generally speaking, most consumer grade audio devices have capacitors in series with the inputs and outputs, to filter out DC bias.

 

 

DC bias is bad because it can cause amplifiers to do work when they don't need to, it will reduce the headroom in a signal and cause clipping with stronger signals, and if DC bias makes it to speakers it can cause them to burn out. (speaker coils are cooled by movement)

 

The thing is, a series capacitor acts like a high pass filter, so it will roll off lower frequencies along with the DC current. This is exactly what I'm seeing in your screen shots... the lower frequency square waves are missing their fundamental frequency and you're only seeing harmonics, while higher frequency square waves are only suffer a small bit of attenuation of their fundamentals.

 

(it helps to think of a square wave as it's constituent sine waves with this stuff)

 

In any case, if it's not the filter caps it's other part of the chain attenuating your low end frequency response.

 

All this happens very quickly-- as you can see by the labels at the bottom of the window, each tick is 0.01 seconds apart.

 

So the space between each tick would represent ~100hz. It seems like you're getting full attenuation of frequencies around ~120hz and under, which isn't great, but is unsurprising with consumer gear.

 

You'll probably get a bit of a better result recording directly from TIA to your sound card, but even then your sound card will have filtering caps and some lower limit to the frequency response.

 

I don't think there's anything to emulate here. If Stella puts out square waves, it's lower end response will be similarly attenuated by caps in the signal chain, the small speaker hooked up to your computer, etc.

[solidcorp]

Excellent test and interesting topic...

 

Have you captured both Stella PC output and the 2600 and compared the outputs?

 

Are those scope traces from Stella or from an actual 2600 Audio signal, and if they are from a 2600 how are they demodulated from the composite TV signal (are they coming through a television)?

 

If you look at the audio output circutry of the 2600 (left center of this schematic) you will see that the audio output from AU0 AU1 is coupled to the modulator through a series 47pf cap (ignoring the effect of the other audio output circuitry). Has anyone on the Stella project tried to account for the analog circuitry in the audio output and video modulator sections of the schematic. It would be interesting to remove the TIA and use a spectrum analyzeer to measure the frequency response to the autio output circutry or simulate the electronics using SPICE to determine what color that circuitry may impart to the digital output of the TIA before it gets converted to FM in the modulator.

 

This all amounts to the output being passed through a high pass filter and my suspicion is that ultimately the low frequencies that are lost are too low to be heard, but who knows?

 

In my experience, audio output is typically coupled capacitively so I suspect you'd measure similar non square wave results from both your PC and an actual 2600, but again this is just a suspicion.

 

As far as reproducing it perfectly, I'd like to share this only somewhat related experience:

 

Some time ago I made a laser light show that could use audio inputs to control the x and y position of the beam. I wrote PC software that would allow the user to create artwork that would get processed into a 16 bit WAV file. It converted the time sequence of X and Y positions into left and right channel volume levels. The WAVs could be played as frames or strung together to make animations. The problem I ran into was that the output from the sound card on the PC could not hold a DC level, it was capacitively coupled somewhere, probably in the output amplifier. When I connected the audio outputs directly to my osciloscope X and Y inputs and looked at test patterns the distortion was clear. Circles looked great, diamonds were ok, but squares, shapes where one axis was supposed to hold a constant DC value while the other moved showed that same characteristic distortion or decay towards zero. I tried recording test patterns onto a CD which is purely digital and playing them back on stereos and TVs but coudn't find any device where the audio output circuitry could hold a DC level. I added some code that would attempt to correct for it by gradually increasing constant signals but sooner or later I ran into the limit in the volume space and when the signal clipped the distortion returned. Every output device was different so there was no one size fits all solution. It was still a pretty cool project and great learning experience.

 

 

[edit] I forgot to mention that Stella is absolutely awesome and I have been really impressed with how well it reproduces sound as well as graphics.

Edited February 21, 2012 by solidcorp

[SeaGtGruff]

Did you have a chance to verify the results with other consoles/models (what model were you using?)? And have you verified that those decays are not resulting from recording?

I used a heavy sixer. If I remember correctly, I had to go from the 2600 to a VCR using the coaxial connector, then to the DVD recorder using standard AV cables, since the DVD recorder doesn't have coaxial inputs. I wanted the best possible audio sampling rate, so I used the 1-hour recording speed and the highest audio setting (I forget the exact specs), since the TIA's audio clock has an oddball rate.

 

I don't know the source of the decays, but WavePad isn't an oscilloscope type of program, so for all I know it may be a result of how WavePad displays sounds, rather than anything in the raw data itself. I'll comment more on that in a reply to RevEng's post.

 

However, when I play the DVD recording it sounds just like the program did playing "live" on my heavy sixer-- at least to my ears. And when I play the WAV files that I ripped from the DVD recording, they sound like the DVD recording.

 

Also, before some of WavePad's "premium" features were disabled after my trial period ended and I elected to keep the free version, I used the frequency analysis on many of the sounds and they showed peaks at the expected frequencies.

[SeaGtGruff]

Based on your screen shots, I'm very sure it's just DC filtering capacitors in the audio chain.

As I said in my reply to Thomas Jentzsch, WavePad isn't an oscilloscope type of program (as far as I know-- I'm no engineer or audio specialist), so I don't know if that might have any bearing on what it's showing. And I don't know exactly what WavePad *does* show-- but I take it the central horizontal line represents "0 decibels," or something like that, such that a flat line signal hugging the central line indicates silence.

 

Regardless of whether there's any filtering going on, the screenshot of AUDC0=0 does make sense to me when I think about it, because there should be some kind of sound at the instant AUDV0 goes from 0 to 15, but if AUDV0 stays at 15 with AUDC0=0 then a steady stream of 1s should result in silence, since there's no variation in the signal to create pulsations or frequencies. So as I understand it, WavePad is showing the resulting sound, not the raw signal as it might appear on an oscilloscope or other device that could show the electrical signal.

 

One thing I'm thinking of trying is to create a WAV file with true pulse waves-- like 0,0,0,0,0,255,255,255,255,255,0,0,0,0,0,255,255,255,255,255, etc.-- and then look at the WAV file in WavePad to see if it shows true pulse waves or otherwise.

[RevEng]

Regardless of whether there's any filtering going on, the screenshot of AUDC0=0 does make sense to me when I think about it, because there should be some kind of sound at the instant AUDV0 goes from 0 to 15, but if AUDV0 stays at 15 with AUDC0=0 then a steady stream of 1s should result in silence, since there's no variation in the signal to create pulsations or frequencies.

 

Except there's signal changes added by the "decay", and an absence of signal changes where the trailing edge of the square wave would be.

 

If it helps to see it empirically, here's what a square wave looks like processed with a high-pass filter...

 

Here's a 60hz square wave wav file as well, so you can check your wavepad display...

60hz-square.wav

[SeaGtGruff]

Have you captured both Stella PC output and the 2600 and compared the outputs?

No, I haven't tried to capture Stella's output, but that's a good suggestion for comparison.

 

Are those scope traces from Stella or from an actual 2600 Audio signal, and if they are from a 2600 how are they demodulated from the composite TV signal (are they coming through a television)?

As mentioned in my reply to Thomas Jentzsch-- actual 2600, connected to VCR by coaxial input, connected to DVD recorder by AV cables. Then I ripped the audio from the DVD to WAV files. I tried to keep the sampling rate as high as possible since there's no sampling rate in the audio/PC world that matches the TIA's audio clock rate of about 31400 Hz, and I wanted to be able to see the 0s and 1s for AUDC0=4 and AUDF0=0, which gives the highest TIA frequency (about 15700 Hz, or half the sample rate since it takes two samples-- 0 and 1-- to make one full cycle of a wave). If I zoom in on that part of the WAV file in WavePad, I can see the peaks and troughs that correspond to the 1s and 0s, but it looks like the samples in the WAV file are about 1.5 times the TIA audio rate-- that is, it looks like the WAV file sample rate is 48000 Hz, which in fact is what WavePad shows when I choose the "convert sample rate" option.

 

If you look at the audio output circutry of the 2600 (left center of this schematic) you will see that the audio output from AU0 AU1 is coupled to the modulator through a series 47pf cap (ignoring the effect of the other audio output circuitry). Has anyone on the Stella project tried to account for the analog circuitry in the audio output and video modulator sections of the schematic.

That's one of the things I was trying to suggest in a roundabout way in an earlier post. As far as I know, the TIA sound routines that are used by most (if not all) of the emulators are based on emulating the raw signal that the TIA generates, rather than what actually gets sent to the TV after the TIA's output goes through the modulator. Being no engineer, and having no training in how to read schematics, I haven't been able to make heads or tails of that schematic (and believe me, I've puzzled over it more than once). I *have* been able to figure out most of the TIA schematics, with hints and guidance from others at AtariAge. I've even started making a spreadsheet to "emulate" each step in the TIA schematics, gate by gate. But the schematic you linked to still eludes my poor attempts to comprehend it!

 

Getting back to the original question of analog versus digital, we may tend to think of the TIA as being digital in nature, but of course the signals flowing through it are really analog. That is, the signal doesn't change from 0 to 1, or from 1 to 0, but rather increases or decreases in voltage until it passes some threshold and is perceived by the gates as being a "0" or a "1." Not that any of this matters from the perspective of emulation, since we're effectively dealing with 0s and 1s (or in the case of the tristate gates, "0" or "1" or "off"). But I *am* curious how the circuitry outside of the TIA affects the resulting audio signal.

 

In my experience, audio output is typically coupled capacitively so I suspect you'd measure similar non square wave results from both your PC and an actual 2600, but again this is just a suspicion.

Getting back to what I was saying about the signals inside the TIA, I don't know that a true square wave is possible, given that (as I understand things) the signal will always have some kind of rise time and fall time. But I suppose this is quibbling over the "zoom factor," since the clock signal may actually look trapezoidal as depicted in datasheets for the 6502, but if we "zoom out" a bit then the rise and fall times are imperceptible at that "zoom level." Even the timing diagrams in the TIA manual show the pulses as being trapezoidal in some pictures, but then as square pulses in other pictures where the scale is different.

 

Circles looked great, diamonds were ok, but squares, shapes where one axis was supposed to hold a constant DC value while the other moved showed that same characteristic distortion or decay towards zero.

I didn't really follow what you described about your project-- although it sounds like it was really cool!-- but the part about the constant DC value sounds like what I was trying to say about the difference between a depiction of a raw electrical signal versus an audio signal.

 

Let's say I send a square wave signal with a frequency of 0.05 Hz, where the raw signal is high for 10 seconds, low for 10 seconds, etc. (20 seconds for each full square wave would be 0.05 Hz, right?) To human ears the effect would be silence, although I wonder if it's really silent-- well, I know it would be a sound, but I admit that sound is something of a mystery to me. (Oh, I know about frequencies, and wave forms, and harmonics, and additive versus subtractive synthesis, etc.-- but what do I *really* know about sound?) If we could *see* the resulting sound, would it look like the square wave that created it, or would it look like what WavePad shows for AUDC0=0-- a series of very brief and rapidly-fading "clicks" or bursts occuring at 10 second intervals?

 

So I guess what I'm saying/wondering is that maybe there's no way for an *audio* device to hold a constant DC value for very long, given the nature of sound? Going back to my 0.05 Hz example, we don't hear a noise for 10 seconds, followed by silence for 10 seconds, followed by a noise for 10 seconds, etc.-- instead, we don't hear *anything*. And if we could, I'm thinking we'd hear tiny bursts or clicks of noise at 10-second intervals. I'm thinking it's not so much that we can't *hear* the sounds, but that they're too tiny for us to notice, although perhaps some animals might be able to perceive them. So, given that a 0.05 Hz square wave is "silent," should a device that can show sounds (as opposed to electrical signals), or a program like WavePad, show the signal as a square wave? I'm thinking the answer is no. My understanding of WavePad is that the distance of the signal line from the central line is an indication of its decibel level, so I figure the screenshot of AUDC0=0 is exactly right, irrespective of the effects of any caps or filtering.

[SeaGtGruff]

If it helps to see it empirically, here's what a square wave looks like processed with a high-pass filter... Here's a 60hz square wave wav file as well, so you can check your wavepad display... 60hz-square.wav

Hmm, WavePad does show a true square wave for that WAV file! So it looks like you're 100% correct about the filtering. And given the way I obtained my WAV files-- 2600 to VCR to DVD recorder to computer-- there's several places where the filtering could have crept in.

 

What I'm wondering is whether the 2600's modulator circuitry adds any of that filtering? As I was alluding to in my original reply, I've been thinking that the waveforms I'm seeing in WavePad are mainly the result of that modulation circuitry. I hadn't considered that the VCR and DVD recorder might be altering the signal, too.

[solidcorp]

What I'm wondering is whether the 2600's modulator circuitry adds any of that filtering? As I was alluding to in my original reply, I've been thinking that the waveforms I'm seeing in WavePad are mainly the result of that modulation circuitry. I hadn't considered that the VCR and DVD recorder might be altering the signal, too.

 

The modulator circuit is probably not imparting too much colorto the sound, the circuit is a very straight forward FM modulator (link to Atari 2600 schematic). Its simplicity may introduce nonlinearity, but that really shouldn't matter for a high pass filtered binary wave form. If you are interested in how the cable carries the color TV picture and audio see wikipedias NTSC and PAL links, for more detail you can look here video signal details

 

I'm not an EE, just a hobbiest, there are probably others who could really shed some light on this.

[Mr SQL]

What I'm wondering is whether the 2600's modulator circuitry adds any of that filtering? As I was alluding to in my original reply, I've been thinking that the waveforms I'm seeing in WavePad are mainly the result of that modulation circuitry. I hadn't considered that the VCR and DVD recorder might be altering the signal, too.

 

The modulator circuit is probably not imparting too much colorto the sound, the circuit is a very straight forward FM modulator (link to Atari 2600 schematic). Its simplicity may introduce nonlinearity, but that really shouldn't matter for a high pass filtered binary wave form. If you are interested in how the cable carries the color TV picture and audio see wikipedias NTSC and PAL links, for more detail you can look here video signal details

 

I'm not an EE, just a hobbiest, there are probably others who could really shed some light on this.

 

Lots of great replies on this thread!

 

solidcorp,

IMO the mixing oscillator impacts both sound and video to the extent that something is lost with a composite mod (I prefer ferrite).

 

SeaGtGruff,

very cool analysis!!!

 

RevEng,

good point about the caps - their involvement and discharge is part of the relaxation oscillator circuits comprising the sound channels; this is different than the harmonic oscillator circuit (the quartz crystal) which drives all of the other oscillating circuits.

 

Also a good point about the digital stepping; these can be emulated like the 6502 but both are acting on analougue circuitry! To conceptualize this in EE consider the following ASCII representan of a relaxation oscillator circuit under digital control:

 

.......I........I..........I...

--/\/\/\/\/\/\/\/\/\/\/\/\/\/\--CAP---

 

The I's are the taps in the coil under digital control; I've drawn three but there could just as well be 31

Which ever tap we digitally switch to doesn't matter, we're left with an analougue resonant circuit pushing out analougue frequencies and imparting analougue ideosyncrasies.

 

Stella is a fantastic and tremendously fun Atari 2600 experience and the emulation for the digital parts is spot on; stephena has raised an excellent point that actual emulation of the analougue components would be a massive undertaking requiring a great many developers and tremendous computing power.

 

Since this is not practical, the stella development team is doing the next best things with these parts; IMO this makes stella a hybrid emulator/simulator. I agree with Thomas that the wavepad graphs could be used to improve simulation aspects and bring Stella closer still to the 2600. I'm impressed by the related efforts of the stella dev team in this direction in implementing phosphor trails, psychedelic interference patterns, et al.

 

Interesting discussion aside, Stella plays so well that I like it more for it's subtle differences than if the gameplay and sound were exactly the same - it means there are two excellent Atari 2600 game playing experiences to be had

[SeaGtGruff]

What I'm wondering is whether the 2600's modulator circuitry adds any of that filtering? As I was alluding to in my original reply, I've been thinking that the waveforms I'm seeing in WavePad are mainly the result of that modulation circuitry. I hadn't considered that the VCR and DVD recorder might be altering the signal, too.

 

The modulator circuit is probably not imparting too much colorto the sound, the circuit is a very straight forward FM modulator (link to Atari 2600 schematic).

I said it wrong-- I really meant all the stuff that comes between the TIA and the modulator, not the modulator circuitry itself. On sheet 1 of those schematics, the signal from the TIA passes through a bunch of stuff I don't understand (resistors and such) before it goes to the M in a pentagram that says "to modulator (sheet 3)." I looked at a schematic of a simple high-pass filter last night and it used resistors, too, so I assume all those thingies on sheet 1 are doing *something* to the audio signal. It's also interesting that to the right of the pentagram M, where it links to the modulator schematics on sheet 3, is a coil or something that says "sound adj." I see it has an arrow next to it. Does that indicate some kind of potentiometer for sound adjustment?

[SeaGtGruff]

SeaGtGruff,

very cool analysis!!!

After I posted my lengthy comments last night I was thinking, "Wow, that sounded really dumb!" Of course we already have devices that let us see sounds, and it doesn't matter what scale is involved (what frequency the sound is). I was admittedly being quite a bit loopy, and I don't think I did a very good job expressing what I was trying to conceptualize. I thought about it some more afterward, and the best idea I could come up with is to put it in terms of air pressure and vibrations. If a square wave is acting on a speaker and the speaker is being pushed in and out, a sustained "out" phase doesn't mean the air pressure is sustained as well, right? I mean, the moment at which the speaker first pushes out will compress the air a bit, but then the air pressure normalizes, right? That's really what I had in mind-- the changes in the air pressure that result in the sound traveling through the air, and the way an increase or decrease in the air pressure as the speaker pulses in and out. The speaker may be held in for a sustained period, and then pushed out for a sustained period, as a consequence of the square wave that's driving it, but the air pressure will normalize after each pulse.

 

Anyway, I now recognize that WavePad does show square waves as square waves, and that the decays I'm seeing in the WAV files is from high-pass filtering. So now the question is how much of the filtering is coming from the 2600 itself and how much is being inserted by the circuitry in the VCR, DVD recorder, TV set, etc.

[SeaGtGruff]

By the way-- as Googlers already know-- today is Heinrich Rudolf Hertz's birthday.