Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


m00dawg last won the day on July 13 2021

m00dawg had the most liked content!

Recent Profile Visitors

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

m00dawg's Achievements


Newbie (1/14)

Very Popular Rare Week One Done One Month Later One Year In

Recent Badges



  1. Integrated the newest Conerto into the tracker! Copy/paste still doesn't work But I did consolidate down to 16 synth channels (and 1 DPCM) for now. This makes each 64 row pattern a bit over 5k and allows for either perhaps adding more effects/channel down the road or allowing for up to 96 row patterns (for 6/8 timed songs as I tend to prefer using rows of 96 vs 48 for those). This means old songs won't load right. Given the fairly alpha state of CT I'm opting not to worry about that all that much at present. Of course I still want to get copy-pasta working but it's honestly not my favorite thing to do This, plus the timing of the X16 being a bit uncertain has me not in a crazy hurry. On that note though, since @The 8-Bit Guy is working on his tracker, I will be renaming mine since his definitely deserves the CommandTracker title assuming he wants it. To fit with Concerto and the starting-things-with-C idea, I'm thinking of alternatives such as Crescendo Tracker (which I think might already be taken?) or Contra Tracker. But I might do something entirely difference. Maybe Xtreme Tracker (to keep with the 'X" theme) - I dunno. The name is a minor thing. Anyways huge props to @kliepatsch's work on Concerto there. Well worth checking out as it does basically all the heavy lifting and really shows what you can do with the hybrid PSG + FM sound. Fantastic work!
  2. @The 8-Bit Guy Heya David! I thought I'd point you to here. I saw you were working on a tracker and, while I'm sure you are a far _FAR_ superior programmer than I, you might be able to get some useful tidbits from this one. Notably @kliepatsch's Concerto engine, which I use extensively, may help get you further along on richer synthesis so you only have to concentrate on the UI, file-format, etc. Just a thought! Both are currently open source and you can find them: https://gitlab.com/m00dawg/command-tracker https://github.com/biermanncarl/cx16-concerto Klieptsch is working on merge PSG and FM so you can create patches that use one or the other (or both). I'm still stuck in copy/paste fun since that's a feature I used a ton with older trackers (and still use them on newer ones). My UI will be based around Impulse Tracker largely as I've been fond of that system. Even though the Fast Tracker style kinda won out (it's what Famitracker, Deflemask, and Renoise all seem to be based around), I was never nearly as fast at writing as I was with Scream and Impulse. I'll continue to work on mine. I took a bit of a hiatus since the X8 kinda made me think the X16 might be delayed longer than I hoped and have had other things going on. But my grand plan is to use the X16 as a tracker solution, optionally with some method of clock sync (even if just pulses on the controller port if not a full MIDI expansion card). Having expansion cards is one of the things I like most about the X16 since it enables these sorts of ideas which is great! My file format, you will notice, is horrendous. 1 pattern = 1 page in himem. I did it by design so I can focus on the most important parts of the tracker (I think) - the UI. I plan on moving to a sparse format once the tracker functionally works. And I expect those to be much smaller so a simple playback library could be included with games. CT is currently still using separate FM (not implemented) and PSG voices. Given what Concerto is doing I will flatten this out, I just haven't decided in what way yet. Probably 16 channels. I'd like to make that configurable (at least at song creation) but that's a future feature for now. Since Concerto manages the voices, the tracker just needs to support a reasonable number but doesn't have to support all 24 (ignoring DPCM for the moment). I don't expect composers to commonly use all 16 PSG voices and 8 FM separately given some of the rich features of Concerto. There could be some extreme cases for when wanting to do that (like tons of echo or something) but I think some of what had to be done manually via patterns can be done in Concerto. And what can't I was pondering having a macro solution for (so the Mxx affect might be calling macros - a bit like tables in LSDJ was my idea there).
  3. I don't have much to show for it yet but I did start work on the copy/paste - or more specifically the block selection routines. CMD-B and CMD-E now mark the start/end of the block and I have started work on highlighting the blocks in the pattern view itself. I plan on getting all that working before I tackle operations on the block. Marking the start/end of the block is easy enough - but drawing the highlighted area is much less trivial. This is partly because a single pattern doesn't fit in VRAM so when moving around channels, the blocked area has to get redrawn depending on what part of the pattern is in VRAM (specifically VRAM can hold all the rows, but not all the channels). To solve this I'll probably have a function that evaluates the start/end areas and highlights any part of that currently in the view which I can call whenever I need to. This is all to mark a block. Once a block is marked, I'd like to have multiple commands to operate on the block. This will include copy/paste but also can include other things like changing the octave of all the notes in the block, or inc/dec'ing the notes, etc. The copy/paste itself is still a bit of a mind exercise but I'll worry about that once I have block selection actually working. Another change is I broke the edit_pattern module out into sub-modules of its own, as it was getting pretty hairy having everything in one big file. I like this approach and will be breaking out the other routines into separate files to break up edit_pattern more into bite sized chunks.
  4. This has been in my mind for a few days now and is something I find super interesting. Essentially, placing the "main" memory onto the die as SRAM would let it run at the CPU clock speed. This would include the ZP (so I think solves the need to consider the ZP part of a register file and we can treat it the same as on, say, the X16) as well as the stack. We're well beyond the point of having external SRAM here in order to run at anything remotely close to 3.4GHz or whatever, but given Ryzen has 384kb of L1 cache, this seems in the realm of possibility. A 6502 running that fast is still going to run into processing limits of 64kb space. In that, it'd churn through data so fast that having such a small amount of memory would be pretty limiting (it already is on the X16, hence the himem stuff). I'm less sure about how to access external data and surely some level of caching or extra hardware to manage, say, modern DDR RAM, would be needed. Fetching data from DDR RAM would take longer than internal memory so, as was alluded to in other comments, there's going to be waiting going on and a need for some additional caching I suspect. I/O as well would have to be solved since on the X16 everything runs at bus speed and it's all good but there's far more complexity on modern systems to manage, say, the PCI Express bus. Even interfacing with our lovely YM2151 or the VERA would have to be very very different here. Not to mention the design requirements from the physical hardware standpoint (trace lengths for the mainboard, etc. etc.) all become very important at these speeds. At this point, it kinda breaks down on what the next step would be here. But it is kind of a fun exercise to think about, I thought anyway. I mean there is surely a reason why the T-800 uses a 6502 after all
  5. The long but interesting interview with Jim Keller on Anandtech comes to mind, specifically this quote: "JK: [Arguing about instruction sets] is a very sad story. It's not even a couple of dozen [op-codes] - 80% of core execution is only six instructions - you know, load, store, add, subtract, compare and branch. With those you have pretty much covered it. If you're writing in Perl or something, maybe call and return are more important than compare and branch. But instruction sets only matter a little bit - you can lose 10%, or 20%, [of performance] because you're missing instructions."
  6. It's a feature I'm actually quite glad to see, although not sure if/how it would work with multiple sound cards. Kevin mentioned above he thought it was unlikely there will be any sound cards given the YM and VERA but I actually think the opposite based on following the project. Given the DPCM on the VERA is a one-shot (non-looping) audio buffer, I could see (and half expect) someone is going to come out with a sample based card (ala GUS PnP perhaps) to enable sample-based trackers and music makins. That plus I'd expect someone to make a SID card because SID. Not sure how popular those might be but I'm expecting it. Though granted, at this point, I'm not planning on it in CommandTracker. Juggling the 2151 and PSG is enough for me to manage for now. All that said, I would think a system that's using multiple sound cards might be more of a rarity so I do wonder how that'd work. Just looking at the board layout I don't see say any resistors to form a passive mixer for each card slot. That might require sound cards having to consider the cases where there's more than one sound card being used with some solutions to manage that (like maybe jumpers for whether or not the audio goes through resistors first or something). This is the case where a pin header might be more useful as one can have a passive mixer board into the pins for the cases where there's multiple sound cards, but then that clutters things. Of course, there's always the option to just output the audio externally like most sound cards did and then folks can just use an external mixer.
  7. Wonderful news, thank you so much Kevin!!! Super cool to see PETSCII Robots running on real X16 hardware too, awesome!
  8. This is a fair point - I experience this with my band for sure. Marketing is quite nearly a full time job just to be seen and inevitably you have to do so much duplication (tools can only help so much here). But at the same time, I agree, this is indeed the official source and Proto 3 is a pretty darn big announcement well worthy of being posted here. Likewise, all content on FB is owned (and profited by) FB, not the X16 and not the people generating the content and conversations for sure. That is a problem, especially if FB is the first source of truth when it comes to project updates. That's concerning to me. Stefany is a good point where I have to be somewhat critical of the X16 project. They have such a huge scope and head start with marketing, synergy, "buzz", all that. In some ways I'm envious as that kind of exposure is just incredibly difficult. Sometimes I do feel like the project folks squander that. Harsh words, not meant to be, but just being honest. Stefany is a wonderful engineer (though I think the Foenix could perhaps use some project management as there is just a ton of feature and scope creep) but she doesn't have the audience David does. It frustrates me when I see the X16 team taking this for granted - even more so when I see them defend it. Again harsh words, and certainly it's easy for me to judge. But is also perhaps the most concerning thing about the success of the project. The X16 can really shake things up in the space and I really do feel will help provide an incredible and renewed interest in bare metal computing in a way that projects before it haven't done. There's just SOOOOOO much good to come from this project. Sometimes I feel like the team just doesn't know what sort of potential they have.
  9. Paging @Kevin Williams! Heya! Sorry to be that guy, but not all of us use FB for whatever reason. I heard the 3rd prototype board has been announced over on the FB discussion board. Any chance the passionate and devoted fan base here can get some info on it as well? I've only heard about it second hand but would love to get the deets from the source!
  10. Quick update, though nothing to show - sorry! It's summer so there's been plenty of other things to do but I also opted to slow down a bit and wait for the next update to the project. I'm not quite sure why the team hasn't posted the update here since it's a big deal I think, but apparently on the FB discussion group, prototype #3 has been shown off whee! I found out about it via the X16 unofficial Discord. That's good news and has me more excited about the project again and so I expect I'll start spending time on CT again in the coming weeks. Next feature is still copy/paste as that's just too big of a necessity before I work on the other stuff (like an instruments UI to configure the Concerto patches and provide a connection to/from it and the tracker).
  11. It would be yep! For me I wanna use it for clock sync to Command Tracker (which also uses Concerto) but yeah making the X16 more of a realtime instrument via Concerto would be really fun as well! I doubt many folks would use it but having the tracker do MIDI out could be interesting as well. Write tunes using YM2151, VeraSound and a SoundCanvas? Why not!
  12. This is perhaps my favorite feature of the X16. Small simple core but options to expand. I think the 8BG is generally right too but there are exceptions. Only musicians (and only a subset) might need a MIDI interface. Most folks won't for just playing games. Excellent feature for an expansion card. Also the nostalgia of what, I guess, we now call FOMO, can be relived in buying a game that requires an expansion card you don't have I'm still nearly certain someone is going to come up with a GUS PnP style sound solution on an expansion card. Network I/O also might be more of a subset of folks (for developing or bringing back the BBS experience, etc.). So all in all, super glad to see it. It's really what got me the most excited about the platform (though the cool banking thing is something I find really fun to work with, but I can't really quantify why).
  13. The C256 for me is a bit like triple chocolate brownie batter ice cream haha. There's just SOOOO much to it where I think I might like less over more sometimes. Which is why I like the X16 a bit more, though I'm warming up to the C256 (in part because it does exist as real hardware and she's very frequent with updates, at least on the Discord). Stephanie has now released two versions of this thing to buy in hardware and at a decent price largely by herself. It's a marvel! Sometimes I get a little frustrated with the X16 team over lack of updates because they have SUCH A GIFT with the exposure the X16 has whereas Stephanie has had to do it the hard way and she's a brilliant engineer but is perhaps in need of a marketer (which kinda sucks I have a distaste for marketing but if people don't know about your product....). I do feel, and I know it's a sensitive subject on the team, but the very sparse updates on the X16 - well I'll put it this way it tends to crush my momentum with my Command Tracker when I haven't heard much in a while. Doesn't need to be a lot, just a minor update. Peri's latest keyboard update being a fine example though that was a month ago. But even something smaller than that would be ok, even if it's delays (like inevitably supply chain issues). Just the feeling of progress. The X16 team seems to prefer a different philosphy and that's ok but caveat is I think it kills the momentum of the ecosystem. It bums me out whenever David rocks a video and doesn't mention a single sentence about the X16. I know he's on some big limitations due to the flooding (I'm in Texas and yep I get it) but just a quick update at the end would go A LONG WAY. Thing is, a lot of us I feel are pouring considerable effort and time to build the ecosystem and it can just be frustrating when we don't see don't really see anything from the team side. I write Command Tracker because it's fun, but I don't want to write it for a dead platform. It'd be nice to know the team has the project at heart and the easiest way to do that is to just say something, even if it's small. Compare that to the C256, which is available today (and of note, has a working music tracker, albeit only for the FM chips I think) - the smaller model isn't even far from David's price point. But she doesn't have the visibility and reach the X16 has. I just don't want the team to waste that.
  14. Read through this and hope I didn't miss it, but going back to the original topic, one thing I'd really _really_ like to see get used with part of this ROM space is something of a standard library / standard tables. Things like VTUI or similar, but also perhaps some math routines and, notably, a collection of LUTs common for games (e.g. sine and multiplication tables and what not). Perhaps a note to frequency mapping as well for using the PSG since nearly any app that wants to make music will inevitably need a table like this and it's just a bunch of duplication otherwise. A lot of these will be frequent additions to programs and games and, while they're not all big, having them right there and ready to go would be significant since soooo much of the ROM space would otherwise be unused if it was just for the kernel, GEOS, etc. I do think ROM should be a playground nor should app devs expect that end users will be flashing their ROMs just to use an app. But I do think having these nice to haves has a ton of benefits, among them is a core pillar of the X16 philosophy with making it an approachable computer to learn on. Even if that's a concept that isn't embraced by the core team, I would advocate for a community solution to be considered, at least for those of us that plan on getting the full size X16 which is meant as a development platform (so having x16edit in ROM there to me makes a lot of sense).
  • Create New...

Important Information

Please review our Terms of Use