Jump to content

m00dawg

Members
  • Content Count

    190
  • Joined

  • Last visited

  • Days Won

    7

m00dawg last won the day on July 13

m00dawg had the most liked content!

Community Reputation

149 Excellent

Recent Profile Visitors

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

  1. 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.
  2. 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
  3. 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."
  4. 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.
  5. Wonderful news, thank you so much Kevin!!! Super cool to see PETSCII Robots running on real X16 hardware too, awesome!
  6. 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.
  7. 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!
  8. 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).
  9. 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!
  10. 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).
  11. 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.
  12. 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).
  13. It's been a BUSY few weeks to find time to write code as of late, but hope to start working CT again soon. I was having trouble sleeping last night and was trying to work out the next big push I'd like to do - copy/paste. Having that, plus maybe some channel shift options (delete and shift up, shift entire channel up/down rows, etc.) would REALLY help the usability of the tracker. I was trying to figure out a decent approach for copy/paste and here what I've come up with. Could perhaps use some feedback from folks if there might be a better way: I will use similar keyboard shortcuts as with Impulse Tracker CTRL-A once, selects entire channel, CTRL-A twice selects entire pattern CTRL-B marks start of copy CTRL-E marks end of copy When we press CTRL-E, we evaluate the start/end points, redraw pattern view to show the highlight of what we selected I'm going to assume, for now, the start point will be the top-left point and the end the bottom right (Impulse Tracker lets you do this backwards but for now I was going to avoid worrying about that). Use 2 pages in memory (yes that means the max song length decreases by 2) Use a page of memory to store copied pattern. When user presses CTRL-C, copy entire current pattern to copy buffer Use another page to store the current pattern buffer, such that on a CTRL-V, we copy the entire current pattern to that buffer (this is so we can CTRL-Z if we pasted the wrong thing) The copy block will be stored as ranges in main memory, something like Start Channel # Start Row # End Channel # End Row # So, on a paste, we have to start at the current cursor of the pattern being pasted into (channel/row) and then roll through the copy buffer for the block desired. So if I originally copied say channels 2-3 from row x10 to x20, and I'm on channels 4 at row x00, the result will be channels 4-5 from rows x00 to x10 ends up with what we copied. This happens on the actual pattern so once we've done this, we redraw the pattern into VRAM If we don't like what we pasted, we undo it by pressing CTRL-Z, which simply copies the backup pattern into our current pattern, then we redraw the pattern These operations would be computationally more expensive than they could be, but the idea is to try and make the code simpler and more flexible. It's not a speed critical part of the tracker so trading speed for simplicity might be worth it here. Curious if anyone has ideas on how to make this simpler/better? I think once this exists, the tracker will become a ton more useful and I can start then thinking about things like the pattern effects and such.
×
×
  • Create New...

Important Information

Please review our Terms of Use