Very impressive. My chiptune tracker only did 1 channel at the time.

Edit: It really is a pain to make music using a hex editor and converting notes by hand is not something a musician would like to do. I have experience with converting notes to hex values and hex values to frequencies which then had to be converted to hex. Is there a reason why you don't display the hex as musical notes? It could fit on the screen I guess.

Example:

It's a super cool project, i wish i could test it out or help out in some way. Maybe we could look for optimizations to the hex editor source?

Wow, that is pretty cool!
I wish I could try it out but I don't have a 82

Cool then, because I got a calc with 16.0 lol. I wonder if displaying both hex and the corresponding note (if applicable for the note in question) would be possible in the future for new musicians who are used to standard music creators?

Yeah true. Lightweight could be smaller and for older calc models, while the other would be for those who don't mind about file size. I still think that the note version should have hex too, though. Just a note selector that you can open if you hate manipulating this much hex by hand. We have to remember that it's a tracker, but some stuff for visual people wouldn't hurt (and would attract more users).

Another thing is that if this was done for the TI-84 Plus, it could possibly be used inside games, because the processor is 15 MHz instead of 6 and the calc has 480 KB of Flash memory. In fact, TI-Boy SE (Game Boy emulator) allows 3 sound channels at once.

By the way utz are the first two songs the only TI-82 songs on your SoundCloud account or were the others done with this program (and the other 82 program) as well?

Thanks y'all for your responses! I'm glad some people here are interested

Looks nice! How much space does the program take?

At the moment, the editor+sound routine are about 1.4 KB, plus 10 K for user data. It will be extended to use all available RAM once the multiload/save feature is done.

It's a super cool project, i wish i could test it out or help out in some way. Maybe we could look for optimizations to the hex editor source?

I'll release the source code as soon as loading/saving and copy/paste functions are done. Also if somebody wants to port this to any of the newer models, you're more than welcome to do so.

What I really need at the moment is a working on-calc RLE+LZ77 packer/depacker. It could be quite slow, as long as it's small in size and efficient enough.

I wonder why are all the more advanced calc trackers are only on the 82? Does it just have better hardware for sound or something?

I guess there's a simple reason for this - right now it seems I'm the only one developing 1-bit sound tools for the TI, and TI82 is the only model I own. TI82 isn't perfect, 86 would be the best of course

That said this seems very cool. I really hope  I can try this at one point. I have VirtualTI and the calc but I'm unsure if my ROMs runs it (my calc has 16.0).

Does anyone know how to send this to VirtualTI and WabbitEmu? It doesn't appear to support 82b files... (it just says transmission error on all 3 ROMs I tried)

VTI emulates the sound more or less correctly, but has a few problems with display timing. Also you need to switch off sound emulation before turning off VTI or it will go zombie. WabbitEmu's 82 display emulation on the other hand is totally broken as far as I can tell. both in recent and older builds. It'll also do the sound part right, though.

I think the readme says 16-19.0 are all fine, but 19.006 isn't supported.

Yeah I'll make a 19.006 version eventually, but it's not so high on my list of priorities. Personally, I think the 82CS sucks as a development machine - crap link port that wears out easily, and CrAsh 19.006 isn't exactly stable.


As far as the note/hex issue is concerned - this was one of the most difficult questions in relation to this project, and in the end I decided against it for a number of reasons:

- The conversion is rather arbitrary, so neither a linear nor a logarithmic function can be used for conversion. The only possibility would in fact be a lookup table for all 3,5 octaves. Also every 1-bit sound routine uses slightly different values, so in fact I'd need to make a table for every sound routine I implement.

- Atm the plan is to have at least 3-4 engines, with different functionality. Eg, there could be a 2-channel sound routine which uses the additional 2 channels for effect commands (timing, timbre, etc). Having a simple hex editor avoids the need to adapt the display driver to the sound routines each time.

- Since tuning is always a bit problematic with 1-bit routines, it is basically required to have a possibility for manually detuning the note data. So, if I were to make the input so it uses Note name + offset/detune parameter, I couldn't do the direct hex-to-RAM conversion anymore, which is the main secret ingredient for keeping the editor size down. Also, translating back the values is non-deterministic, since on higher octaves notes can be just 1 byte apart.

- Last but not least, if there were note names, how would you go about entering them? Either you type them in manually, which would be far less efficient than the current method. Or I tie notes to different keys, which would only be feasible if you turn the calculator sideways to edit. Plus, it would require a complex lookup considering the octave value must be taken into account.

That being said, someone has already suggested a useful feature that I'll probably try to implement somehow. Basically, it would translate the hex value which is currently highlighted by the cursor back into a note name, plus possible offset.



Concerning a port to later TI models, with or without added functionality, you are more than welcome to give it a try. As I said, I'll release the sources with one of the next updates. There are a couple of potential issues I see with it: The sound routine might need a major rewrite, unless it is somehow possible to slow down the cpu to the speed of a regular 82/83. Also reading song data directly from Flash will most likely be too slow. Well, I know zilch about the new models, so I'll leave it up to you to figure this out

In-game use is not a good idea, because 1-bit routines block interrupts as well as any running keyhandlers, and take up 99% of CPU time, regardless of clock speed. (You could use it for title screens though. In this case these routines might be a better choice though.)

Actually Keoni, one of my friends had an old graphing calc that was capable of producing beeps. The built in basic language even had support for it. It was pretty cool. His mom has been a math teacher forever, so that's where he got it from.