Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


kliepatsch last won the day on February 16

kliepatsch had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

kliepatsch's Achievements


Enthusiast (6/14)

Conversation Starter Rare One Year In Dedicated Very Popular Rare Reacting Well

Recent Badges




Community Answers

  1. Hi all, just wanted to drop a note here on the current status of Concerto. Since my life has changed in the past months and will further change in the next couple of months, I have much less time to spend for hobby projects like this. (Read: got a job, will get married). It's great to see things moving again, and the emulator being developed further to better match the X16 expected hardware. If anyone is interested in getting Concerto to work for newer releases of the emulator, feel free to drop me a message, and we can discuss. I don't think it's much work, but right I am not doing it for the sake of it (also there is always the option to fork it) All the best!
  2. Now I'm glad that I saw that one 8-bit show and tell video about how to make random mazes in Forth Besides, welcome to the forum, @Alan!
  3. Yes, both YM2151 and PSG channels are used. PCM outputs no sound, at all, but instead generates a timer (see post above). The YM2151 is generally the more useful sound chip. It has better sound quality and it's much more versatile, and yes, it's mainly used for the "melodic" instruments. The PSG channels are mainly useful for percussion, and only some of the instruments. It requires a little more creativity to put them to proper use. The kick and snares are done with a combination of YM2151 and VERA noise channels.
  4. The YM2151 and the VERA PSG are outputting sound. PCM outputs no sound, but the Concerto sound engine currently abuses it to generate a custom timer that is faster than 60 Hz by hijacking the AFLOW interrupt generated by the PCM channel. It may be possible to use the VIA in the future to generate the timer, though, which would free up the PCM channel to do other things. The VIA timer isn't currently implemented in the emulator. I don't know, actually It depends strongly on how much is going on in the music. I am guessing about 25% of CPU. There was another song made with Concerto, that ZeroByte ported to R39 so that it could be run in Box16, which has really nice debugging features. In the debug screen it looked like 20-25% to me, and this composition here may be in a similar region. So there's still plenty of CPU to do other things! The MP3 actually contains the same song two times in a row. I thought it was interesting enough that people would listen to it twice without getting bored So it's rather 2 min. The 27 kB split into: 7 kB sound engine, 4 kB instrument configurations (of which less than half were actually used), 16 kB music data.
  5. adding an mp3 recording of it x16_funk.mp3
  6. It's not my first composition for the X16, I have done two with Dusan Strakl's Music Player Library (MPL) and another simple one with Concerto. But this is the first one where I am pulling all the stops that I know of. Although composing by scripting in Python is definitely tedious, I am actually having a ton of fun It's still unfinished, but reasonably complete to share it here. I hope you enjoy! Runs in the official R38 emulator. TUNE.PRG
  7. I have started 6502 assembly with this website: https://skilldrick.github.io/easy6502/ (Although I've had previous experience with x86 assembly.) I think if you know how to use an ordinary programming language, the most important new aspects in assembly are Processor registers. You cannot simply operate on as many variables as you like (imagine writing a command like a=b+c*d). Instead, you have to work with a limited set of processor registers, which are essentially variables that are constantly reused for new purposes. Processor flags. These are essential for program flow. Instead of writing "for i=1 to 10 do something" or "if a=b then do something", you have to use processor flags and conditional jumps ("branches") to control the program flow. I think when you understood those things, you are good to go Edit: when I wrote this, I was in a hurry. What I meant was, that these two concepts are the extra challenges, anyone coming from a higher programming language should be extra aware of. You should read about these things and get at least a rough idea about them, before proceeding to learn about assembly instructions.
  8. I appreciate the amount of thought you put into this! One little remark from my side: if it's not too much of a hazzle, would it be possible to put the key combinations that are used often (like copy/cut/paste) into a place where one could do the combination with a single hand easily? I've found that using Ctrl+P, Ctrl+U is awkward to use compared to Ctrl+C, Ctrl+V. Just one little feedback
  9. I think I'd wait for your generator That way, Concerto can serve as a test case for your generator.
  10. I see your point, leaving decay away limits the musical use. So the question boils down to whether the intended use includes music or only simple sound effects.
  11. Well, rje has been talking about an ADSR manager for a while now, and I was interested in his wishes specifically. My impression was that he doesn't want a second Concerto, but rather address a simple problem: currently you cannot make a sound with a single line of code (or two). I may be wrong ...
  12. I'm not sure if I understand the difference between the two approaches. You are developing a general purpose generator that can be plugged into any software, and I could either wait for that or write my own routines that exports ZSM? Is that what you are saying?
  13. Would anyone be interested in a C wrapper around Concerto, so you can use it in C programs with CC65?
  14. Hi all, recent progress on Concerto led to the release of version 0.5.0-alpha. Find the source code on Github together with ready-to-execute precompiled examples that show you a glimpse of what you can do with Concerto (and how it's done in the example source files): https://github.com/biermanncarl/cx16-concerto Additions to the functionality: Concerto now includes a player module. The entire sound engine can be automatically controlled using a new data stream format. The format is specified alongside the source of the player. CC65 assembly projects can use the player by simply including the source file of the player. Vibrato and volume automation have been added and are available in the API (and can of course also be controlled by the player) Timbre data can now be included at compile time. This can save a lot of annoying file operations at runtime when all you want is to statically load a certain set of sounds. Simply include the "bank" file that can be exported from the Concerto UI, which contains 32 sounds. (Note that you still have to get this file off the SD card image. Concerto can't save files to the emulator's host file system) The user API has been made simpler and more secure. This also introduced several breaking changes. API calls now do not use any of the R0-R15 pseudo registers for passing parameters. Instead, parameters are passed using CPU registers wherever possible, and Concerto's own registers anywhere else. This is to prevent the "public" R0-R15 registers getting messed up by Concerto. From now on, it is not necessary to include a separate file for the zeropage segment. Instead, Concerto handles the assignment to the correct segments itself (and restores the previously active segment using CC65's .pushseg/.popseg directives). It is now not necessary anymore to call SEI/CLI before/after certain API calls. Simply calling the subroutines is enough. The VERA address registers are backed up and restored by Concerto's interrupt service routine. It is now safe to use the VERA alongside Concerto, even without calling SEI to prevent Concerto messing with the VERA. This was highly due!! The way Concerto dumps / restores timbres got changed. Other changes include: Bugfixes Reasonable default/center pitch when pitch-tracking is deactivated System requirements: about 11k low RAM (19k with UI) 15 bytes ZP usage (21 with UI) stack usage: 20 bytes of stack headroom should be safe (a couple more with UI) CPU usage: almost nothing up to most of it, depending on song and timbre complexity. For a normal song, expect something like 20%. I am also thinking about facilitating recording to the ZSOUND stream format, which will be less CPU intensive for playing back songs. I am guessing the resulting song files will be huge, but we still need to try this out. Maybe it is very well worth it Now, since there is a song player with Concerto, it would of course be nice to be able to compose music for/with it. I have written a couple of Python scripts that help me with generating binary data for the player (which is how I composed the above demo). But this process is very tedious and not enjoyable. I am still thinking about how to improve this situation.
  • Create New...

Important Information

Please review our Terms of Use