when is AUDV0 read?

[+rbairos]

Hello.

Is the output volume updated exactly when AUDV0 is changed, or it latched only at a specific clock cycles?
(What about AUDV1 while on the topic?).

Thanks very much,
Rob.

 

[Thomas Jentzsch]

According to Stella immediately.

[DirtyHairy]

55 minutes ago, Thomas Jentzsch said:

According to Stella immediately.

... however: the current value is only considered for the next sample that is latched, which happens twice per scanline (cycles 37 and 149, to be precise). That's the current state of the audio code in Stella and 6502.ts, which is based on the code donated by crispy and which is supposedly also implemented in his FPGA TIA. However, at least to me, the schematics don't support this --- my impression when I last looked at them was that a change to AUDV0 does take effect immediately. However, I am lousy at reading circuits, so I may be wrong on that one. I guess this could be clarified with a test ROM.

[+rbairos]

It would simplify things greatly to not have to obsess when during a scanline audio is updated (though that's kinda the fun).
Assuming this may be different for different atari versions as well.
Cheers.
 

[+stephena]

12 hours ago, DirtyHairy said:

... however: the current value is only considered for the next sample that is latched, which happens twice per scanline (cycles 37 and 149, to be precise). That's the current state of the audio code in Stella and 6502.ts, which is based on the code donated by crispy and which is supposedly also implemented in his FPGA TIA. However, at least to me, the schematics don't support this --- my impression when I last looked at them was that a change to AUDV0 does take effect immediately. However, I am lousy at reading circuits, so I may be wrong on that one. I guess this could be clarified with a test ROM.

I agree that I can't really see where in the schematic this happens.  But I'd also add that doing it this way made a lot of ROMs sound correct compared to real hardware, and Stella/Stellerator are the only two emulators that currently do this.  As @DirtyHairy points out, we didn't do the research on this, but overall I feel it's the correct approach.  Maybe the exact cycles could be in question, but I think that something like this must be happening on real hardware.

[DirtyHairy]

11 hours ago, rbairos said:

It would simplify things greatly to not have to obsess when during a scanline audio is updated (though that's kinda the fun).

How? The current assumption means that any write to AUDV0 will only be picked up when the next sample is generated, but it doesn't force you to write at a specific cycle. The only implication is that, in case of multiple writes, the last write wins. If anything, I think that catering for an immediate effect of writes would be more complicated as the writes would have to happen at the same precise cycle each scanline in order to maintain equal distance between the individual PCM samples (provided you want to play PCM).

 

At any rate, I don't think this aspect varies among TIA revisions.

 

2 hours ago, stephena said:

I agree that I can't really see where in the schematic this happens.  But I'd also add that doing it this way made a lot of ROMs sound correct compared to real hardware, and Stella/Stellerator are the only two emulators that currently do this.  As @DirtyHairy points out, we didn't do the research on this, but overall I feel it's the correct approach.  Maybe the exact cycles could be in question, but I think that something like this must be happening on real hardware.

My interpretation of the schematics was that writing to AUDV0 immediately switches the various lanes in the resistor network that does the mixing. However, even though I am not sure whether the current emulation is correct, I think that it is definitely good enough. If writes to AUDV0 were to take effect immediately (and if we were to model this accurately), the emulation would have to produce a sample on every color clock (>300kHz!) and then downsample this stream, and the result would be virtually identical for almost every program.

Edited November 25, 2019 by DirtyHairy

[+rbairos]

1 hour ago, DirtyHairy said:

How? The current assumption means that any write to AUDV0 will only be picked up when the next sample is generated, but it doesn't force you to write at a specific cycle. The only implication is that, in case of multiple writes, the last write wins. If anything, I think that catering for an immediate effect of writes would be more complicated as the writes would have to happen at the same precise cycle each scanline in order to maintain equal distance between the individual PCM samples (provided you want to play PCM).

 

At any rate, I don't think this aspect varies among TIA revisions.

 

My interpretation of the schematics was that writing to AUDV0 immediately switches the various lanes in the resistor network that does the mixing. However, even though I am not sure whether the current emulation is correct, I think that it is definitely good enough. If writes to AUDV0 were to take effect immediately (and if we were to model this accurately), the emulation would have to produce a sample on every color clock (>300kHz!) and then downsample this stream, and the result would be virtually identical for almost every program.

Thats what I meant.
Having the samples fetched at regular intervals is easier to accommodate over having varying kernel routines reserve same cycle positions for it.

Good point about 300kHz sampling. Though I think in this case, real hardware could produce > 15.75khz content for example, were it immediate AUDV0 updates.

Luckily in my project, I think I can accommodate hitting AUDV0 once, at the same cycle each scanline, after much more fiddling.

-Rob









 

Edited November 25, 2019 by rbairos

[KK/Altair]

AUDV0/AUDV1 is definitely updated immediately on real hardware.

When writing my softsynth I tried use both registers separately to improve the output quality, because the volume addition is not linear in TIA.
E.g. when setting both channels as "High", volumes don't simply add up, and volumes 0+14 give different voltage than 7+7.
I was trying to use that feature to improve output quality, but even the 3 cycle delay in writing AUDV1 after AUDV0 gave audible buzz at 5kHz sampling rate.

 

And if anyone would like to update Stella with the AUDV0+AUDV1 mixing table, just PM me.
I have measured output voltage for all 256 combinations already and can share the table.

[Thomas Jentzsch]

15 minutes ago, KK/Altair said:

AUDV0/AUDV1 is definitely updated immediately on real hardware.

When writing my softsynth I tried use both registers separately to improve the output quality, because the volume addition is not linear in TIA.
E.g. when setting both channels as "High", volumes don't simply add up, and volumes 0+14 give different voltage than 7+7.
I was trying to use that feature to improve output quality, but even the 3 cycle delay in writing AUDV1 after AUDV0 gave audible buzz at 5kHz sampling rate.

Oh, that's unfortunate. I knew the human ear is very sensitive to timings, but I wouldn't have thought that it would notice a 3/1,000,000 sec delay.

 

Quote

And if anyone would like to update Stella with the AUDV0+AUDV1 mixing table, just PM me.
I have measured output voltage for all 256 combinations already and can share the table.

Thanks, but this is already in Stella (e.g. check the "effective volume" in the debugger). Maybe you want to verify your findings.

 

Also see here.

Edited December 9, 2019 by Thomas Jentzsch

[KK/Altair]

Oh, that's unfortunate. I knew the human ear is very sensitive to timings, but I wouldn't have thought that it would notice a 3/1,000,000 sec delay.

Human ear is very sensitive to anything happening regularity at 5kHz rate. And my player was giving randomly 3-cycle peaks and notches exactly at that rate.

 

Thanks, but this is already in Stella. Maybe you want to verify your findings.

Nice. And thanks, but I have enough confidence in my multimeter.
The only oddity here is that I failed to found any reasonable approximation for this circuit, but on the other hand the DAC resistances in TIA are not real resistances but rather half-open transistors, so that was to be expected.

[Thomas Jentzsch]

If you look into the linked thread, you will find the expression which calculates the resulting volume. It would be interesting to compare the calculated results with your measured table. So please post it here.

[Thomas Jentzsch]

4 minutes ago, KK/Altair said:

Human ear is very sensitive to anything happening regularity at 5kHz rate. And my player was giving randomly 3-cycle peaks and notches exactly at that rate.

I wonder what would happen if you update the registers in alternating orders (V0 first, then V1 first, then V0 first and so on). Maybe that would mask the regularity?

[DirtyHairy]

10 hours ago, KK/Altair said:

AUDV0/AUDV1 is definitely updated immediately on real hardware.

When writing my softsynth I tried use both registers separately to improve the output quality, because the volume addition is not linear in TIA.
E.g. when setting both channels as "High", volumes don't simply add up, and volumes 0+14 give different voltage than 7+7.
I was trying to use that feature to improve output quality, but even the 3 cycle delay in writing AUDV1 after AUDV0 gave audible buzz at 5kHz sampling rate.

 

And if anyone would like to update Stella with the AUDV0+AUDV1 mixing table, just PM me.
I have measured output voltage for all 256 combinations already and can share the table.

Thanks for the confirmation. The table in Stella is based on the idealized resistor network, so I actually am interested in the real values that you measured.

[KK/Altair]

2 hours ago, DirtyHairy said:

Thanks for the confirmation. The table in Stella is based on the idealized resistor network, so I actually am interested in the real values that you measured.

Well, that's the table. Measured on a PAL light sixer with a standard voltage multimeter. Of course much better measurement could be made (e.g. by better tools, or possibly automated with an Arduino or something), but this one was enough for my purposes. I tried matching these to a resistor network model, but the measurements failed to match any assumptions I tried, so I just used this table as it is.

 

Also if you'd like complete emulation of TIA sound, I have written complete cycle-exact implementation basing on the TIA internal schematics, including some not really obvious quirks (e.g. the fact that it's actually driven by two clocks). Sadly, it looks like you can't glitch the sound in any meaningful way by exploiting this, which is something I hoped for.

 

	AUDF0															
AUDF1	x0	x1	x2	x3	x4	x5	x6	x7	x8	x9	xA	xB	xC	xD	xE	xF
0x	4.91	4.88	4.68	4.53	4.28	4.13	3.93	3.78	3.53	3.39	3.22	3.09	2.91	2.79	2.67	2.56
1x	4.89	4.73	4.53	4.37	4.14	3.98	3.79	3.64	3.40	3.26	3.10	2.98	2.80	2.69	2.57	2.47
2x	4.69	4.52	4.33	4.17	3.94	3.78	3.61	3.46	3.22	3.10	2.94	2.83	2.66	2.56	2.45	2.36
3x	4.53	4.37	4.18	4.02	3.80	3.65	3.47	3.33	3.11	2.97	2.83	2.72	2.57	2.47	2.36	2.28
4x	4.28	4.13	3.93	3.78	3.56	3.42	3.25	3.12	2.91	2.79	2.66	2.57	2.43	2.33	2.24	2.16
5x	4.13	3.98	3.79	3.64	3.43	3.29	3.12	3.00	2.80	2.69	2.56	2.47	2.34	2.26	2.17	2.09
6x	3.93	3.79	3.61	3.46	3.25	3.12	2.97	2.85	2.66	2.56	2.45	2.36	2.24	2.16	2.08	2.01
7x	3.79	3.64	3.46	3.32	3.12	3.00	2.85	2.74	2.56	2.47	2.36	2.28	2.17	2.09	2.01	1.95
8x	3.54	3.39	3.23	3.10	2.91	2.80	2.67	2.57	2.41	2.32	2.23	2.16	2.05	1.99	1.92	1.86
9x	3.41	3.26	3.10	2.98	2.80	2.69	2.57	2.48	2.33	2.25	2.16	2.08	1.99	1.93	1.86	1.81
Ax	3.23	3.10	2.95	2.83	2.67	2.57	2.45	2.36	2.23	2.15	2.07	2.00	1.91	1.86	1.80	1.75
Bx	3.10	2.98	2.84	2.72	2.58	2.47	2.37	2.28	2.16	2.09	2.01	1.94	1.86	1.81	1.75	1.70
Cx	2.91	2.80	2.67	2.56	2.43	2.34	2.24	2.17	2.05	1.99	1.92	1.86	1.78	1.73	1.68	1.63
Dx	2.80	2.70	2.57	2.47	2.34	2.26	2.17	2.10	1.99	1.93	1.86	1.80	1.74	1.69	1.63	1.59
Ex	2.67	2.57	2.45	2.36	2.25	2.17	2.08	2.01	1.92	1.86	1.79	1.75	1.68	1.63	1.58	1.54
Fx	2.57	2.47	2.37	2.28	2.17	2.10	2.02	1.95	1.86	1.81	1.75	1.70	1.63	1.59	1.54	1.51

[DirtyHairy]

Thanks alot! I will compare this to the current formula in the emulator. As for the emulation, the current code is based upon crispy's FPGA implementation and is supposedly cycle accurate (apart from AUDV). Have you spotted any differences?

[Bruce Tomlin]

On 12/9/2019 at 5:28 PM, KK/Altair said:

Well, that's the table. Measured on a PAL light sixer with a standard voltage multimeter. Of course much better measurement could be made (e.g. by better tools, or possibly automated with an Arduino or something), but this one was enough for my purposes. I tried matching these to a resistor network model, but the measurements failed to match any assumptions I tried, so I just used this table as it is.

You meant AUDV0/AUDV1 in that table, right?