Kylearan

Heya pOke! Thanks! I have finished the code and the manual for version 1.0 now. The pitch guide creator works really well to get more usable notes if you roughly know beforehand what you need. Now I'm waiting for my musician to finish an example song before finally releasing the program. There's of course still a lot of room for improvement (like adding undo/redo, for example), but that has to wait for a future version, if there will be interest in that.

If I remember correctly, there is one minor feature where you cannot use forward declarations in K65 as well, but right now I forgot what that was exactly. Most of the time (function declarations, data sections etc.) it works. You still have to declare manually which functions/data sections you want to put into which banks. However, calling a function in a different bank is as simple as prepending the keyword "far" in front of the function call, like this: bank misc func doMagic { <insert code here> } bank main func myKernel { far doMagic // Calls doMagic in the other bank, then return here again } This will cause K65 to automagically generate the necessary code stubs in both banks that take care of switching to bank "misc", call function "doMagic", switch back to bank "main" and continue exection after the far call. If you later decide you want to put both functions into the same bank, simply change the "bank" statements accordingly, remove the "far" keyword and it will become a traditional JSR/RTS subroutine (or use the "inline" keyword in the function definition to inline it). You can still do bank switching manually if you want, like you'd do it with dasm. I've released the sources for "Ascend" and "Derivative 2600" if you want to have a look at a real-world example. Ascend uses the K65 built-in bank switching, Derivative 2600 manual bank switching. I have no idea since I don't know much about cc65. cc65 will have the advantage of using traditional 6502 syntax and thus will be easier to get into. I suspect k65 has a superior linker, it was specifically made for the VCS and it allows for much more compact code (it allows multiple instructions per line), but has a steeper learning curve as it uses its own 6502 syntax.

Do you mean RAM? You still have to declare RAM variables manually and have full control over everything, it's like in dasm but with a different syntax. K65 won't try to optimize anything in that regard.

One caveat: The problem in the case of k65 is that it uses a completely new syntax for everything, which comes with its own learning curve and might not be everyone's cup of tea. There are some "traditional" 6502 compilers (like the cc65 toolchain or, I think, 64tass) that also come with a linker, but I don't know how good they are or how well they play with VCS specific stuff.

Of course it can, that's exactly what a linker does. With K65 for example, you can specify explicit alignments ("align 256" for example) or, if really needed, absolute addresses for each section of code or data. Or you can mark a block of code, a loop for example, as "nocross", meaning that this block must not cross a page boundary but otherwise doesn't need to be aligned exactly. What the linker then does is try to find a configuration of memory locations for all functions and sections that satisfies these constraints. For example, it can place a section of code including a "nocross" loop in such a way that the space between that section and an adjacent section is exactly the size of a table of data or another section of code to squeeze in, wasting not a single byte. Especially when it comes to "nocross" sections which do not need to be aligned exactly, only not crossing a page boundary, this is extremely helpful. A computer can optimize such a complex scenario much better than a human. And not having to hunt for code caves or shift around code after each change saves A LOT of time. My first 32k demo TIM1T was written with dasm and manual optimization. My second demo, Ascend, used K65, and having a linker doing all the optimization work was like the difference between night and day.

That's what a linker is for, which can do it better and faster than a human in most cases. dasm doesn't have one, but AFAIK there are several 650x compilers which have. Personally, I use k65. It has an optimizing linker; you can simply use the "inline" keyword for a function to avoid JSRs; it has bankswitching built in; and much more. I realize that optimizing by hand can be fun, but at some point it always starts to feel like a chore, at least to me. Having a compiler who takes care of that for me can help productivity a lot.

Haha, thanks alex_79! I had forgotten about Stella's internal database *and* didn't know the music kit is in there. Good to know we haven't gone crazy... :-)

Since code and data are exactly the same between both binaries (except for that one byte that never gets accessed), including memory locations, the trace would be the same. That's why we think it's an emulator issue and not a VCS code problem. Plus, as I said, take a look at a zoom of the "M=..." screen area at the top in both binaries: At full speed, one flickers and one not, but if you step through frame by frame, both output exactly the same pixels (as expected given that code and data are the same). ...or what do we miss here...?!?

To elaborate a bit more on JAC!'s findings: You can compile the example yourself by downloading the original Slocum music kit 2 and inserting a "dc.b 0" in songmain.asm after the "include songplay.h". Now the measure display flickers. Change it to a "dc.b 255", and it no longer flickes. In fact, it flickers for anything other than 255. Due to the "org $FA00" after the dc.b, the code and data locations and sizes are exactly the same for both binaries. The only difference is that byte at memory location $F1F6, which will never be accessed (verify with a "trap f1f6" in the debugger). With the original musik kit, the contents of this memory location defaults to $ff (=no flicker). In addition, if you set the zoom position to the measure display and step through the binaries frame by frame, you will see that both generate exactly the same pixels each frame. And yet, running at full speed the $00 binary flickers and the $ff binary does not. What gives?!? That's on Windows, Stella 4.6.1 here.

I've been working as a computer scientist (IT security, not compiler architecture ) at a university for a couple of years. I've published several research papers and peer-reviewed for several research conferences over the years. My opinion on that matter comes from that experience. That's a bold statement I seriously doubt, especially when it comes to mature, well-researched scientific areas. Do you have any examples? Note that I don't mind the "non-academics" part of that statement. What triggered my initial reaction was the idea that it should somehow be better not to educate oneself on what's already been done. There are so many computer scientists competing for grants, publications and titles who all try to come up with a new revolutionary idea. Thanks to their solid education, they know what has already been tried, what worked and what did not work and most importantly, *why* it had worked/not worked. This vast community experience will more than outweigh the bias introduced by a field's traditions. Anyway, AtaC is a hobby project done for the fun of it, which is great! I'm surely be interested to see what Gip-gip comes up with, and the VCS scene has a lot of room for frameworks and tools which will be helpful even though they won't revolutionize science (they don't need to!). It's just the notion of "You don't need knowledge about a mature field to come up with something better, it might even hinder you" which really irks me. That's not how science and improvement works. Sorry to Gip-gip for derailing his thread!

Thinking that someone without much knowledge in a specific area of decade-old research can come up with something new by ignoring tried and true methods is hubris in my book. I mean, it's not like those generations of researchers with a solid education in the field who tried to think outside the box to come up with something new for their research papers have all been idiots. But hey, I'd be more than happy to be proven wrong.

The problem is that ideally, you'd want to have experience with both tracker software and the TIA limitations. I guess most people here know the TIA, but many have never used a tracker before. Contrast this with the fact that most chip musicians who use trackers routinely don't know the TIA chip, and we have a problem... Once the 1.0 version is finished (which will include a manual), I'll try to get some chip musicians I know to create some example tunes and instruments, which hopefully makes the learning curve less steep.

I needed a short rest after Revision and my talk, but picked up development again now. The pitch guide creator GUI and logic is almost finished, and I added some preset pitch guides optimized for different distortions. For those, the base frequency of A4 is chosen so that the number of in-tune notes for a given distortion is maximized. That doesn't necessarily mean the resulting available notes are super useful for a musician , but it's a nice improvement over the standard A4=440Hz, and the configurable pitch guide creator can be used for more individual configurations. The manual is 70% finished as well, so I'm crossing my fingers that I will be able to release a 1.0 version in the second half of May.

After a quick look at your sources, I can only echo ZackAttack here. Compiler architecture and design is a very well researched area with decades of experience in the community, and there are tried and proven methods as well as mature libraries and tools already out there which might save you a lot of hassle. You say one of your design goals for your language is clean code, so maybe doing a clean compiler underneath would be a good start. (I realize doing everything yourself from the get go can be a fun learning experience in itself and a nice hobby project, but from your vision statement it looks like that might come back and haunt you later on...)

Yes, it's already on my long list of things to try. This is a thing commonly done on other platforms; for example on the C64, multispeed tunes (2x, 4x, 8x or even more) are quite common. Basically I thought about two uses for updating the registers twice per frame: 1) Change parameters of an instrument, maybe allowing for more interesting effects. However, a chip musician told me that this would probably not improve instrument quality a lot, as it's mainly interesting if you have parameters like filters, which the VCS doesn't have. Still, would like to try that nonetheless. 2) Mix four "virtual" channels into two. To make this sound any good though, the time between audio register updates should be the equal all the time. So for example on a PAL system with 312 scanlines, the updates should happen after 156 scanlines respectively - which causes one update to happen in the middle of the display kernel. This is bad: You either need to call the music player during the kernel, eating a lot of scanlines, or pre-compute the audio register values and only copy them during the kernel which can be done quickly but needs at least 4 additional bytes of RAM. One day I'd like to try how it sounds if you do one register update at the beginning of overscan and the second at the end of vblank. But first I'd like to finish TIATracker 1.0. Updating the registers a lot more frequently to play samples has been done before on the VCS, for example here.

K65 sure has some questionable design, I have been annoyed by it more than once. But its greatest strength is providing a good layer of abstraction while at the same time leaving the developer in full control of everything if need be, which IMHO is key for the VCS with ist limited resources (RAM, ROM) and need for precise timing (cycles). Keep that in mind when developing your compiler, especially when it comes to "hidden bankswitching", "variable declaration inside functions" etc., which (without knowing exactly what you mean by that) look like dangerous candidates to be done wrong. I'll follow your project with interest in any case!

You may want to take a look at K65, a very powerful compiler and linker framework for the VCS: http://devkk.net/wiki/index.php?title=K65 It's not really C, but similar to it. It abstracts a lot of things (functions, loops, inlining, bank switching etc.), optimizes the placing of code and data segments for you during linking (aligned/unaligned) and has VCS-specific keywords like wsync, but still gives the programmer full control over everything if needed. Once you get used to its syntax and idiosyncrasies, it speeds up development considerably; especially the linker is a great improvement over having to do it manually like with dasm. KK, the developer, is also quite open to feature requests

Thank you! Thanks, will have a look/hear later! Interesting. I admit I made my research and the presentation purely from a demoscene point of view. I'm sure I've missed some great proprietary sound routines from the homebrew game scene, and maybe some publicly available tools from there as well. vwB is Virtual World Basic, right? Is it open source, and do you have a link?

Thanks for that; I had to look how a pull works first, as I've never used git before in a team. I don't like using IRC. It's just not compatible with my real life constraints (family + job). I rarely can do live communication, and only have sporadic, small stretches of time where I can work on my projects. (Had to take a break for a week now, for example...) Better for me would be an async method of communications with a real, usable archive function. I guess I'll send you an email soon.

At this year's Revision demoparty, I gave a presentation about music on the VCS with a survey on available routines and tools, some thoughts on how this might have influenced music culture (from a demoscene point of view) and finally introducing TIATracker, my new sound routine and sequencer. A recording is available on YouTube in case you're interested:

I'm making progress, yay! I have attached TIATracker version 0.8 to the first post, together with an example instrument. Most important new features: Switch between PAL/NTSC in the options tab Precomputed pitch guides for A4=440Hz and optimized ones for AUDC 4/12 which give you more in-tune notes to work with You can export a track to .asm now and feed the result to dasm as-is Some things are still missing, most notably the manual, an example song and the pitch guide customizer, but the current version should otherwise be usable already to make music and include it in your projects.

The shot looks like there's a one-to-one relation between passengers and destinations, so that every pick-up point will have the same delivery point every time. Why not define a number of pick-up points plus a number of delivery points and randomize the missions? Randomization is good for replayability. Looking forward to the game in any case!

It's awesome that Stella's sound emulation gets improved! Will the changes only affect TIASnd, or will other classes be changed as well? I ask because I use Stella's sound emulation for TIATracker and would like to port the changes once you're finished.

Echoing Omegamatrix here. I use Chrome 48, and "enter" won't accept my changes in the note entry editor like the description says. I can only close the editor window via "x", which discards my entries, but I have no way to enter a selected instrument/note into the pattern.

I'd be very interested in that as well, as for TIATracker I've simply taken the frequencies from RandomTerrain's web page without really understanding or checking them (yet). And since I plan to add a feature to optimize matching desired notes to frequency (similar to WebTune2600), having correct frequencies/formulas as foundation would be nice.