+rbairos Posted November 23, 2019 Share Posted November 23, 2019 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted November 24, 2019 Share Posted November 24, 2019 According to Stella immediately. Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted November 24, 2019 Share Posted November 24, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
+rbairos Posted November 25, 2019 Author Share Posted November 25, 2019 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. Quote Link to comment Share on other sites More sharing options...
+stephena Posted November 25, 2019 Share Posted November 25, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted November 25, 2019 Share Posted November 25, 2019 (edited) 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 1 Quote Link to comment Share on other sites More sharing options...
+rbairos Posted November 25, 2019 Author Share Posted November 25, 2019 (edited) 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 Quote Link to comment Share on other sites More sharing options...
KK/Altair Posted December 9, 2019 Share Posted December 9, 2019 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. 3 Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2019 Share Posted December 9, 2019 (edited) 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 1 1 Quote Link to comment Share on other sites More sharing options...
KK/Altair Posted December 9, 2019 Share Posted December 9, 2019 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2019 Share Posted December 9, 2019 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. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted December 9, 2019 Share Posted December 9, 2019 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? Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted December 9, 2019 Share Posted December 9, 2019 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. 1 Quote Link to comment Share on other sites More sharing options...
KK/Altair Posted December 9, 2019 Share Posted December 9, 2019 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 7 2 Quote Link to comment Share on other sites More sharing options...
DirtyHairy Posted December 11, 2019 Share Posted December 11, 2019 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? Quote Link to comment Share on other sites More sharing options...
Bruce Tomlin Posted December 14, 2019 Share Posted December 14, 2019 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.