Lawl... even though I can't really play this, I'm laughing off my butt just by the thought of it! Great job

Aww, thanks @pimathbrainiac for the shout-out, and thanks @unknownloner for the Osaka cover, you did well mate!

Making 1-bit sound in a DAW is indeed not so easy. However, there's a number of VSTs that can help with that. I'd especially recommend the 1bitstudio package from Shiru (one of the best 1-bit/8-bit toolmakers out there and also a great musician, check out his Player Alone album if you like VGM metal/hardrock).

welp... there goes my newly found appreciation for HP :o From the thread at hpmuseum I would guess HP is being a bit more cooperative now. So let's see how the saga continues.

Yep, that's right Never owned a Vtech Laser though. I do have a few old Vtech educational computers (Genius Leader series), but sadly those are quite useless for programming experiments because the OS is completely locked down, as in nobody has been able to break out of the BASIC and execute some machine code yet.

Wow, nice! I'm not a fan of Flappy Bird, but it's great to see someone do something on the Laser 200. Lovely piece of junk, I've got a user manual laying around somewhere but unfortunately not the computer itself.

That may very well be true. I was more on about the "fixing x, improving y, enhancing z" vs. TI's "look at this new great lockdown we got, preventing users from doing **** with their devices".

Thanks Lionel, I'll look into these.

Branches are auto-optimized via the .tpr, so they should always be short. But I can add the .s to make the code more portable. Forgot about re-enabling vector table protection, will take care of that.

I very much dislike macros. I do see why others find them convenient, but for me, they decrease readability of the code too much.  So since I'm the one who has to maintain this code, I prefer to keep the text bloat, sorry.

Edit: Changes done, latest test build for TI-89 attached.

Yeah, you're right. And those optimizations were not the problem, after all. Also I agree, not fiddeling with the return addresses would be nice, but I don't see how to do it without a major (unacceptable) increase in step-to-step transition noise.

So what was the problem? Well, I didn't realize that after running the timer detection loop, AUTO_INT_5 would fire immediately (ie. during TRAP #1). Which of course causes trouble when the AUTO_INT_5 vector has been modified 

Aaaaanyway... before I package a new release, would one of you be so kind to test the TI-89 build? (upload both attached files and boot with "qed68()")
Also, updated source is available at https://github.com/utz82/qed68 for further examination.

Wow, what a stark contrast with your average Nspire update. I envy the HP calc community.

I'm afraid at this point even Lionel can't help me... that bit of code by itself can't be causing the problem, as in effect it does nothing at all. I'm sure the problem must be elsewhere. I mainly needed to vent my frustration, so thanks for the consolidating words @DJ Omnimaga.

I've got a hunch about what's going on by now. My guess is that those stack-based size optimizations that Lionel proposed need some modification, because in their current form they will mess up the registers when an interrupt triggers between those 2-step instructions. But that I will investigate... tomorrow, maybe.

Man, things aren't going well today at all.
I've implemented the detection loop as follows:

PRG_getStart
lea.l ($600017),a0
bset #3,-2(a0)
\ne_loop
tst.b (a0)
bne.s \ne_loop
\eq_loop
move.b (a0),d2
beq.s \eq_loop


The result is that the sound routine will crash with an Illegal Address Error at some point. Mind you, I just have that bit of code in there, not actually using the result. Any ideas why? Also, why does tprbuilder refuse the "move.l xxx.w,dn" mnemonic?

I'm a bit unhappy because I'm spending hours after hour on this thing, when I could certainly do more useful things.

@Lionel Debroux: I'm in the process of implementing your suggestions. Two quick questions though.

Quote from: Lionel Debroux on April 07, 2016, 06:20:14 AM
I tend to use 0xCE instead of 0xCC on my 89 HW2 calculator, which yields 1024/51 Hz instead of 1024/53 Hz AUTO_INT_5 rate - an order of magnitude closer to 20 Hz. On my calculator running AMS 2.05, after changing the initial value in port 600017 and enabling AUTO_INT_3 until the next power off (port 600015, bit 2), the default APD time, as measured by AUTO_INT_3 ticks stored in the OS's internal variables, is ~299s, instead of ~310-311s.
You need to obtain the initial timer value through a waiting loop, then save and restore that. See PRG_getStart in intr.h, https://debrouxl.github.io/gcc4ti/intr.html#PRG_getStart .

So I can't just read out the value from port 600017? My limited (read: non-existant) understanding of C suggests that PRG_getStart does just that.

Second question is about AUTO_INT_3. In your last post you suggest redirecting it to a RET, but earlier you said I should only do that on HW3+. Which is correct? I mean if it speeds up things I'll gladly redirect it, but if that kills the clack feature I can probably live with not touching them, provided the original INTs don't clobber any registers.

Neat It'd probably be difficult to make the face not flat with the size of these voxels. But the hoodie (or whatever you call that thing) could be sticking out over his forehead. That'd give more depth even with a flat face.

Thanks again so much, Lionel. I'll definately incorporate your suggestions.

DJ, the version I posted was just a test to check if it would work in principle. For a proper 89T version, I'll need to make some changes based on what Lionel said, and possibly also adjust the converter to account for the faster clock speed of the HW3/4 models. I'll get back to it when I've finished my current project, which will take a few more days to complete.

Wow Lionel, thanks for your detailed feedback and bughunting! Very much appreciate it.
I'm currently working on another project, but I'll get back to this asap. First,  I have a few questions/remarks however...

Quote from: Lionel Debroux on April 07, 2016, 06:20:14 AM

• Bug report:
  

Code Select Expand

move.b #$cc,($600017) ;restore timer speed

Ah yes, I was simply too lazy to implement proper handling of $600017, and didn't really know how to do it either. Thanks for pointing me in the right direction.

Quote from: Lionel Debroux on April 07, 2016, 06:20:14 AM

• Bug report: setting the SR to 0x0400
  

I gather AUTO_INT_3 fires at OSC2/2¹⁹ on HW2, but how often does it fire on HW3/4? Any int firing at more than ~30 Hz would cause a parasite tone, and thus be unacceptable. Also, what's the proper way to detect HW3/4?

Quote from: Lionel Debroux on April 07, 2016, 06:20:14 AM

• Bug report: the AUTO_INT_5 handler starts by clobbering d0 and a6.
  

This is not a problem, since neither register holds any relevant values at this point. D0 is loaded with A0 on sound loop restart, and A6 just holds a constant pointer to the base of the jump table. I'll still consider your code though, as you hinted that would be faster.

Quote from: Lionel Debroux on April 07, 2016, 06:20:14 AM

• Minor optimization in the init code
  

Code Select Expand

move.w (a1)+,d0 ;skip ctrl word

Whoops, should've seen that one. Well, this is actually just my second 68k asm program (first was a simple PWM implementation quickly done when I got the calc a few months ago), so I'm still learning