Kylearan

484 bytes, to be precise. I've looked it up last week, because Coke Zero is one of several data points for my Revision talk where I will point out that VCS demo coders allow much less room for audio than coders on other platforms.

It's only a convenience feature for the composer, not a technical one. Since AUDC values 4 and 12 have the same timbre but different pitch ranges, TIATracker allows to create a "virtual" instrument for these two waveforms with 64 frequencies. That way, when the composer edits his song, he doesn't need to switch between two different instruments for high (AUDC 4) or low (AUDC 12) notes. He only uses this one combined instrument for composing, and when the tracker exports the track to .asm, it actually creates two different instruments with the same (shared) envelope and takes care of assigning the notes to the correct instrument.

Awesome! I'm really glad somebody *finally* releases a (usable) tracker for Paul Slocum's music player. My music player and tracker have a slightly different goal (more flexible and powerful, but at the same time needing a bit more resources), so having multiple options is always good! I will give a talk on VCS music, player routines and trackers at Revision demoparty during Easter (announcement is here, scroll down a bit), and I'll make sure to include your tracker in the overview of available tools.

One motivation to develop TIATracker was to have a tool for my musician so he can create music for my upcoming 4K demo. I have reserved around 600-700 bytes for audio (player routine plus music data) in that demo, so size-efficiency was indeed one of my primary design goals. It needs more ROM than Paul Slocum's music player, but I also wanted to have something more flexible and powerful, so this cannot really be avoided. A couple of posts above I provide a detailed breakdown on the resources needed for a song. I use very densely packed data structures. The download in the first post contains a "player" folder with the source code of the music player and the data structures; it's richly documented, so you can have a look if you want. There will be a "For the coder" section in the manual that provides a breakdown on that, but for this you will have to wait until Easter. Note that unrolled loops can actually be desired, if speed is your concern instead of ROM size (been there, done that...) - and actually there will be a version of the player optimized for speed or RAM in the future. But right now, it's optimized for minimal ROM usage. Rest assured that I know a thing or two about size-coding.

I attached a new version to the original post. The info tab now provides a detailed breakdown of how much ROM and RAM each component of the player and the tune needs Mute channel and loop pattern implemented Small improvements and bugfixes A growing list of todos, thanks to some feedback by Thomas Jentzsch :-) Next up: Export to .dasm, and the option to switch between PAL and NTSC (the logic for that is already implemented). I also realize that right now, without the manual or an example song, it's not easy to understand the concepts of this tool. I'm working on that!

The logic is already there, only the "options" tab where you can select this is not yet finished. I'll release a new version with a working info tab and .asm export this weekend, and will do the options tab next.

Just a quick update: The tracker is almost finished, and the thread with current updates and downloads can be found here.

That's a great idea! Cheap and easy to implement as well. Will add that as an option, thanks!

Whoops, I forgot to add the "player" folder again after fixing a bug and creating the archive a second time... sorry. Here it is. tt_player.zip

Current status of resources used is: Size of player: 164 - 232 bytes (depending on features used, see comment at the top of "tt_variables.asm" for a detailed breakdown) RAM: 9 bytes permanent, 2 bytes tmp, 2 bytes stack. This is fine for my current project, but I already have ideas how to reduce this at the expense of ROM Each melodic instrument needs 5 bytes plus 1 per envelope frame. Instruments can share the same envelope (like for combined AUDC 4+12 ones) Each percussion instrument needs 3 bytes plus 2 per envelope frame Each pattern needs 3 bytes plus 1 per note The song itself needs 2 bytes plus 1 per pattern to play per channel

EDIT: Updated to version 1.3 TIATracker is a tool for making Atari VCS music on the PC and a new sound routine for the VCS. It features ADSR envelopes, up to 7 melodic and 15 percussion instruments, customizable pitch guides for optimizing the number of in-tune notes, a size-optimized and configurable replayer routine and much more. The Windows binaries for version 1.3 as well as the manual are attached. Included are also three example songs, a few basic instruments and an example pitch guide. For Linux and OS X, use "wine" or compile the sources (they use Qt and SDL). The sources can be found here. Pouet link is here. I'm open for bug reports, feature requests or curses. TIATracker_1.3.zip TIATracker_manual.pdf

Haha, I had coded that part at the party at 3 o'clock in the morning only a couple of hours before the deadline and thus didn't test it on real hardware. I remember wondering while it ran on the bigscreen during the compo why the left side looked so blocky, but never got around to investigate it further. Thanks for the explanation of that mystery; I live and learn... and good to know current versions of Stella have fixed this.

Thanks for posting, this is quite good - and has awesome music, too!

That's a relief to hear! Thanks everybody.

Hi, I have a mirrored playfield (bit #0 set in CTRLPF) and try to change PF2 mid-scanline exactly in the middle, to get different pixels on the left and right sides of the screen. If I do a "STA PF2" at cycle 45 (finishing at cycle 48), it works fine in Stella and on my real VCS: All bits from the original PF2 value are displayed, and all new ones just written to PF2 get then displayed immediately thereafter, without any loss/bleeding/duplication. Since the timing is so tight on this one: Does anyone know if it works reliably for all/most VCS revisions out there (Chinese chipset, ...)? (I cannot use an asymmetrical playfield in this case, as I'm relying on the symmetry for what I want to display.) Thanks in advance!

Wow, that's very nice, indeed one of the best 2600 tunes I've heard so far! Not only good percussion fx, which is easy to do on the VCS, but also a good lead and even chords! My absolute personal favorite tune on the 2600 is from the demo Saigon, though: http://www.pouet.net/prod.php?which=56384

It's making steady progress. The editors for melodic and percussion instruments are finished and I'm working on the pattern editor/sequencer right now, and I'm really optimistic that I'll be able to release a first version at Easter.

Typical guest-to-host escapes exploit bugs in a communication mechanism between guest and host, like accessing guest hardware via a driver, or sending signals to the host for a shared clipboard or similar things. These bugs rely on the fact that the host code has to parse some (complicated) structures the guest can construct, or that the guest can provide and fill a buffer of variable length. You won't find something like that in Stella's VCS emulation. It's "only" parsing 6507 opcodes and emulating registers/output. You cannot via 6507 code signal anything to Stella, nor can you trigger some kind of buffer allocation or complex structure parsing in Stella from 6507 code. I'm pretty sure Stella is full of bugs since security never was a concern when it was developed, but I'm also pretty sure you cannot trigger them with 6507 code in a controllable way, much less in a way that afterwards, the host's program counter points into the emulated VCS ROM/RAM. Have you any experience with guest-to-host exploits in other environments?

Right now I'm in the process of writing a new sound player and accompanying music tracker which both will be released as open source Easter this year. The sound player supports ADSR envelopes for instruments, patterns of variable length (individually per channel), percussion instrument "overlaying" a melodic instrument (similar to auto-hihats in the Slocum player but with arbitrary percussion instrument envelopes), and more. The player is finished already. The tracker supports a virtual combined "pure" instrument (AUDC 4 and 12 combined, which gets automatically split when exporting the track to .asm), visual "pitch guides" showing which notes are available and how much off they are, and uses Stella's sound emulation routines for output. Instrument and percussion editors are finished, and right now I'm doing the pattern editor/sequencer. Here's a screenshot of an early version of the instrument editor: Contact me if you're interested in trying it out when a roughly working alpha version is finished, which will hopefully be around early March.

Ahahaha, that's hilarious indeed.

I've used Robert M's excellent bankswitching macros for dasm in my demo TIM1T. While they are not minimal ROM-wise, they are very easy to use and might save you some fiddly and time-consuming work.

Me too. And the 6502 and 68000 reverse engineering/cracking and assembly skills I acquired back then now serve me well when analysing Windows malware or exploits. Absolutely! That works for almost any area. Just yesterday I went back to optimizing my VCS music player after leaving it for a couple of days to get some creative distance, and lo and behold! I was able to shave off another 8(!) bytes, even though I previously thought this impossible.

Yep, tricks like having several "cmp #$c9" instructions to use as a slide to jump into for cycle-exact kernel positioning, are also very similar to some obfuscation techniques, and in fact often confuse disassemblers in a similar way.

For those interested, here's a write-up (not by me!) of cracking the obfuscation techniques for a 6502 version of Burger Time from 1982 (cracked in 2015 ): https://ia801505.us.archive.org/33/items/BurgerTime4amCrack/BurgerTime%20(4am%20crack).txt Some techniques I mentioned above are used there: Jump into middle of instructions, opaque predicates and decryption on the fly.

Thank you! I suspected as much, and this spares me the work of having to fiddle around with the RESP trick myself to test it.