EricBall's Tech Projects

You are changing AUDxx once per frame, correct? How much better would it sound to go to two or three times per frame?

You are changing AUDxx once per frame, correct? How much better would it sound to go to two or three times per frame?

It might, but I don't think it will get much better unless you instead bang on AUDF and do 4-bit PCM instead. (Of course, that chews up ROM really, really quick.)

 

Double the data rate, double the ROM required (or half the time). But that also doubles the lowest frequency which can be determined using my method*. I suspect this would also pick up more high-frequency false noise.

 

 

* Note for those interested, there are 123 NTSC TIA AUDC/AUDF combinations which have a fundamental frequency of less than 60Hz.

Hm... it sounds like putting a C64 tape into an audio cassette player. Until you said so in this message, I'd never even thought it's supposed to be music, let alone "Get Ready for This" ...

Hm... it sounds like putting a C64 tape into an audio cassette player. Until you said so in this message, I'd never even thought it's supposed to be music, let alone "Get Ready for This" ...

Yeah, my wife said the same thing. Once she knew what it was, she could hear the similarity. 'Twas an experiment.

ignoring phase, since it's virtually impossible to control the phase of the TIA audio waveform

 

Is the TIA audio not deterministic, with the main input getting hit exactly twice per scan line? I should think that it should be possible to control the phase precisely on a real 2600 (at a worst-case cost of about 17 scan lines per frame)

ignoring phase, since it's virtually impossible to control the phase of the TIA audio waveform

 

Is the TIA audio not deterministic, with the main input getting hit exactly twice per scan line? I should think that it should be possible to control the phase precisely on a real 2600 (at a worst-case cost of about 17 scan lines per frame)

Oh, yes, it's deterministic, just not easy to control / predict. A collorary would be the digits of pi - the sequence is always the same, but it's impossible to predict the next digit even if you know the previous digits. The problem with the TIA is changing AUDC/AUDF doesn't reset the state of the LSFRs or counter - they continue from the state they were in.

 

The TIA audio generator has three main sections. First is the frequency divisor - a 5 bit up counter which is reset to 0 when AUDF is reached. The problem is if the current value of the counter is greater than AUDF, then it keeps counting up before wrapping around from 31 back to zero. So, to know the phase of the output, we have to track the exact value of the counter.

 

The next two sections are the LFSRs - a 4 bit and a 5 bit which can interact with each other. Again, changing AUDC doesn't impact the state of the LSFRs, but unless the state of the frequency divisor is known exactly, there's little point in trying to track the LSFR state.

 

So for simplicity sake, it doesn't make sense to try to determine the exact phase of the output waveform. For although it might be possible to predict the phase of the output, controlling would be much, much more difficult.

 

And from an desired output it doesn't make much sense either. If the TIA is 90 degrees out of phase from the sample waveform, then it won't match; even though it might be otherwise correct. Finding frequency matches is tough enough without worrying about phase.