Hi, I'm working on porting my old qed68 sound routine to the Voyage 200. While the code obviously works correctly on TI-92+, I noticed that on V200 it runs much, much slower - feels like it's running at around 7-8MHz, rather than the 12MHz it should be running at.

Does anybody know of any differences between the 92+ and the V200 that might explain this?

Hi utz, long time no see
Good thing I saw the topic notification on IRC.

By chance, was the 92+ you used for testing a HW1 model ? You'd tell that from F1 -> A (About) in the Home screen, or by opening your calculator and checking for the presence of a Plus hardware module: 92+ HW1 is effectively some 92 variant + a Plus module.
I'm writing that because from a glance at your code, there seems to be an unhandled sensitivity on the hardware revision. Namely:


Code:


As explained in the hardware reference, now long maintained in TIEmu - https://github.com/debrouxl/tiemu/blob/master/tiemu/trunk/docs/ti_hw/misc/J89hw.txt - HW1 (89, 92+) and HW2+ (89, 92+, V200, 89T) have different timing bases, and as such different values for 600017 are necessary... but I don't see any compensation for HW1 vs. HW2+ differences in your code. The HW1 timing base (OSC1) has a significant frequency range, only HW2+ have precise timing.

Other notes:
* a bit above that block: it's not just HW3+ which need saving and restoring the AutoInt3 vector. 89, 92+ and V200 running AMS 2.08 or later use that as a 1 Hz timer for the software clock. I'd just unconditionally save and restore that handler, it makes the program marginally smaller and irrelevantly faster.
* relatedly: running the program at SR > 0x0200 disables the software clock on 89 HW2, 92+ HW2 and V200, which is normally considered user-unfriendy;
* I haven't yet seen what the program does between interrupts. I'd have expected the usage of port 600005, but that address does not appear directly in the code, at least.
* another couple size + speed optimizations which seem to affect all core* blocks, but of course, I wouldn't want to mess with your timings:
move.b/.w #0,dn -> clr.b/.w dn
move.b #$ff,dn -> st.b dn

Hi Lionel, good to see you're still in the calculator game as well!

I can't check my 92+ right now because I'm snowed in away from home, but I'm pretty sure it's a HW2 since it's playing at the correct pitch using a frequency table derived from nominal values. Also the OSC2 timer interrupt is running at roughly the same rate on my 92+ and on the V200.

Between interrupts the program is busy generating sound, ie. it's somewhere in the core* blocks. It's that part of the code that is executing slower afaict.

Can't claim I fully understand the code 8 years after writing it, but I believe I didn't do those optimizations on purpose back then. With the current sound generation code, implementing those would require nop'ing out the timing differences, which presumably would negate any gains. Though with careful thinking it would very likely be possible to increase the sample rate a bit and/or double volume resolution.

I'll fix those issues regarding hardware clock and AutoInt3. Thanks for your suggestions, much appreciated!