Kylearan

I had thought about that, something like C64 multispeed tunes (2x, 4x, 8x register updates per frame). But a musician told me that this would not be that useful on the VCS as you don't have a lot of meaningful parameterts to update, like filters on the C64 and so I've dropped the idea for now. Updating each scanline is certainly possible and actually has been done already, but that's out of the scope of TIATracker and you'd need a dedicated player for that.

No, unfortunately not. I'm aware that copy/paste (and undo/redo) are very basic functions we expect all programs to have, but this project was big enough as it is already and I had to cut out some things to be able to finish this at all in a reasonable amount of time. It's definitely on my list of things to add in the future, though. Having the same instrument sometimes start in attack/decay and sometimes in release is not possible [without a major overhaul], as I don't have any bits to spare to specify this in a row - the data format is very size-optimized. But if you are willing to create two different instruments for that, it should be possible. I think I could add an option in the instrument editor that specifies if that instrument should start in Release mode or not. Would that work for you?

TIATracker version 1.1 is finished, fixing some bugs and adding new features: Improved timing precision of the tracker replayer. It should match what you hear in Stella now even on slower systems. Added ability to export the VCS player and song data to K65. Added ability to export song data to .csv (I need this for syncing music and demo effects). Fix: "New..." now properly clears meta-data (author, name, comment, used pitch guide). Fix: "Play" in the tracker with channels having varying pattern lengths now starts replay at the correct position for channel 1 and no longer crashes. I've updated the first post with the new version. Also, yet another demo using TIATracker for music has surfaced.

That spreadsheet idea is really neat! Fortunately the complexity of 6502 instruction timing is on the lower end, and after doing cycle counting on a couple of kernels manually I no longer need to look up any details, as the fundamental rules are quite simple as Omegamatrix said. So in the end I think a dedicated tool would not be worth the effort.

Since I know all cycle counts by heart I prefer doing it in the source itself, as close to the code as possible (i.e. by using comments) but I know SvOlli has written a small tool that according to him has helped him a lot planning cycle-exact kernels. It displays a grid, 76 cycles wide, and allows you to place and move instruction chunks of different widths (i.e. different amount of cycles needed) around. It also marks the start of the visible area, etc. You can find it here.

That's really odd. I'll try to find a Win7 64 bit machine for some more testing, as I'm unable to reproduce the problem here or see any issues in the relevant code... That's really nice! I like VCS tunes with longer notes; a lot of tunes only have very short "blib" sounds in their melodies, probably so they can stuff in more drums and bass in the same channel. Yours is different, and good! In other news, I've squashed another bug that occured when you hit "play" and had non-aligned patterns. I've also reworked the replayer thread in the tracker which should be much more precise now and produce no more jitter, i.e. the sound should be much closer to how Stella sounds on slower machines. And finally, I've added the option to export to .csv, which I need for syncing demo effects to music. It's only in the repository right now; I'll release a new binary version in a couple of days when I've finished the ability to export to k65.

Turns out it wasn't a critical bug after all. "New song" forgot to clear the meta-data (author, name, comment, pitch guide) so it carried over to the new track, but no old data was ever overwritten. I've fixed this in the repository already but will wait with the release until some other features are finished.

Unfortunately you cannot change the font size. I realize that's a problem for users of 4k monitors, but the development overhead to implement this is too big for such a small hobby project for me, sorry about that! I don't know batari Basic and have no idea if it could be done, but would be happy to try. Is batari Basic still maintained?

That's indeed something nobody else ever reported, not even close, so it might be related to your system. What system do you have?

Ouch, that's indeed a bug, and one that can have terrible consequences as you've experienced - sorry about that! Will fix that tomorrow! What exactly do you mean with "groove settings"? Overall tempo? How instruments sound? Something else? If the problem is easy to reproduce, could you maybe send me an example .ttt file with a short explanation where exactly the problem is? There's one known issue at the moment. VCS/Stella playback happens at exactly 50/60 Hz per instrument update, but on slower PCs the replay routine in the tracker has some slight jitter, i.e. sometimes an update happens 1 or 2 ms later than intended. I'm planning to improve that for the next release; it's a bit hard to debug because my PC is quite fast. This might be the cause of the problem you hear.

Awesome, thanks!

Oooh, those macros sound nice! Do you have a link? I (quickly) tried to do them myself some time ago and failed...

Version 1.0 is finished! I have edited the first post accordingly, including a link to the sources. Besides lots of bug fixes, it now includes an example song, the ability to enter meta data (author, song name and a comment) and more precise timing during song replay in the tracker (not yet optimal, though).

You're right, that would be the sensible behavior. The reason I did it differently is that you can save 2 bytes in the replayer routine by not using goto and that the default configuration of the tracker is for minimal ROM usage. I realize that it's probably a rare case where you don't want to use goto, but still...

Thanks! Considering I wasn't sure if anyone at all would use the tracker, I'm quite excited to see so many people expressing enthusiasm for it. What exactly is not working? Both seem to work fine here on my end (and for a musician friend as well). I'll release a v1.0 version this week; maybe you could test again and if it still doesn't work, send me an example .ttt? You can use the "Export complete player to dasm..." menu item and use dasm on "<songname>_player_framework.asm" to produce a .bin. I had thought about a "Compile and start in Stella..." menu item, but in the end didn't really see the need for that, considering you'd rarely use this and it's so easy to do manually. If you have a good use case for it, I could add that of course! Some good stuff! You can hear Paul Slocum's player in most of the tunes.

For anyone who is interested, here is a new beta version of TIATracker. Unless those people who are already using it find critical bugs, the only thing still missing is Juice's example song (which has already been enhanced some) and I'll add that and release v1.0 next week. I have already a long list of possible improvements, but that will have to wait for a future version. Some sceners surprised me by finding my repo, cloning it and already using TIATracker to make music for a small VCS demo released at the French VIP party this weekend! They have uncovered some bugs in the VCS replayer routine while doing so, which I've fixed by now. I haven't heard the song yet however, but I'm quite excited that people are already using the tracker even though it's not even finished yet.

Indeed, that was a great read - many thanks, Thom! I love that kind of historical stuff.

Yep, that's a known problem and one of the two big things to fix before the 1.0 release. I'm on it. The 6502/VCS version of the replayer code of course does not drop frames, but the Windows replayer routine has annoying jitter in the audio code which on weaker systems might even cause frame drops. The replayer thread does not get woken up at a constant 50/60 Hz as intended - that's a problem with the timer I currently use. It sounded a lot more accurate in the documentation than it seems to be in reality. :-/ Right now I'm in the process of implementing a different method which should be more reliable. You can call the replayer code anytime you want: VBLANK, Overscan, during display, no problem. It only needs a couple of scanlines to execute, depending on the options used in the song. Slicing up the replayer code to interleave it with standard Kernel display code is theoretically possible of course, but might be challenging to do in practice. There are quite a few conditional branches in there; also, a lot of the time all 3 registers are in use at the same time, which makes interleaving standard display code hard to do.

Your pioneering music driver was the only reason people have been able to produce VCS demos for the demoscene, so I'm looking forward to your new version of Loopcart to see what you come up with! And maybe TIATracker can draw some inspiration from it.

Yeah, sadly the work-in-progress version of TIATracker posted here is very old and still full of bugs. :-( That's wonderful! There are some nice effects in there, and it's unsually complex for a VCS song. I like it! That you did this with such an early version of TIATracker is amazing! Now I'm feeling really sorry that I never posted newer versions for so long. :-( When I'm back from my business trip in a couple of days, I'll release the almost-done-version I currently have! Among lots of new features (being able to customize your own pitch guides being the most important one), it also has a lot of bugs fixed, in particular the assembly one.

I'm very happy! Juice, a chip musician who has volunteered to create an example song to go with TIATracker, had a first test run with it and after only one hour of work, produced a very short and simple loop to familiarize himself with the program. I've attached the ROM in case you're interested. Of course it's only 7 seconds long for now, but considering he had no previous experience with the VCS and used my tracker for the first time, I'm really excited that he still came up with something nice-sounding in such a short timeframe. This supports my hope that if actual musicians are given access to the right tools, the VCS can do a lot better music than many people believe. Of course my program being used for real for the first time also uncovered several annoying bugs I had missed, hrmpf. I have to fix those first before finally releasing version 1.0, but I think I should be able to do this during the next two weeks. Until then I've also attached the manual which is finished already, for the curious. simple_loop.bin TIATracker_manual.pdf

RAM definitions are essentially done the same way as in dasm, i.e. without any automation for RAM re-use. You have to plan and define vars by yourself unfortunately. Those look quite useful!

No runtime library required, as K65 has none. You only need the compiler itself (found here) to compile Ascend. (Caveat: I think there was a slight change in syntax after Ascend was finished, so it might be you need to do a small change to the source to make it compile with the current K65 version. Contact me if you actually want to do this.)

I think developing demos and games is quite similar, at least when it comes to resource needs. In demos, especially 4K, you definitely cannot waste any ROM, as effect code, tables, music etc. just need a lot of space. So any cost of JSR etc. are definitely a concern. So I'd like to reiterate that K65 is *not* a framework in the sense that it provides any run-time libraries or routines. It's just a compiler for a language that directly corresponds to 6502 assembly. Yep, same here for demos. The difference between demos and games I guess might be that you can spend an intense, short time frame on one effect and then take a rest before tackling the next effect, as effects usually are independent from each other (with the exception of global flow and sync to music). I guess a game is a more coherent whole that might be harder to split into independent pieces (levels perhaps?). True. I guess the demographics of 2600 coders has changed a lot since the early days (older people with more complex lives and less spare time), resulting in different development needs. Modern tools can help there. But I'd wager that modern tools would have helped productivity in the olden days as well, only they haven't been invented/built yet. If modern tools and the way you develop software with it is more fun is a different matter and depends on individual tastes. I like both, and switch between them. Writing TIATracker was a very modern process (IDE, GUI designer etc.), so the 4k demo I'm developing at the same time is using dasm again for a change.

Sorry for misunderstanding you at first. Sure, you can use K65 for 4K projects just fine, as it does not impose any overhead at all. Every 6502 instruction has an exact representation in k65, and optional convenience stuff like conditional blocks, loops or functions are compiled straight to assembly exactly the way you would expect it to with no overhead. Only the in-built bankswitching adds overhead you cannot directly control, but you can always opt to not use it and do it manually (like you would do it with dasm), and for 4K it's not needed anyway. In the end it's all about having fun, and if you're more comfortable with the old-school approach and enjoy that more, then that's great! For me it's a bit different. I have way too many ideas for demo effects and not enough spare time, and using a more modern framework like k65 allows me to be more productive and write more code more efficient in less time. Even if it automates away some of the manual old-school fun, for me it's even more fun to see if my demo effects can be realized on the VCS or not.