Jump to content

Yazwho

Members
  • Content Count

    61
  • Joined

  • Last visited

Community Reputation

55 Excellent

Recent Profile Visitors

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

  1. This has been updated to support commands\effects. I've added Slide Up\Down to the note, and Pitch Shift Up, as well as Silence which forces the volume to 0. Now the framework is done, its relatively easy to add something new. Working on the demo track, and will update the upload once done.
  2. For my player, it's not triggered from its own interrupt. You call the audio routine once per frame, that's it. It's up to the callee to save anything that is needed, but as you control it you'd try to time it so you didn't need to. Not at all
  3. I don't know the YM well enough. Just going on what I've read. eg https://ayce.dev/emptyx16.html#9f41h---ym2151-register-data-w--status-r No idea if the emulator handles it correctly.
  4. I've uploaded the source for the PSG audio demo to github. The code is awful, and I highly suggest you don't bother. If you really want to try, you will need Visual Studio 2019, cc65, the X16 emulator, a MIDI input device, and I'd also suggest Visual Studio Code. Oh, and a whole lot of patience! With all of that, you'll be able to create the .prg that I uploaded previously. https://github.com/Yazwh0/BitPlayer In terms of updates, my aim is not to write a tracker, but to have one to use for what I want to do. So I'm only expecting to ensure its functional for my own goals. I don't want to make and maintain a 'ProTracker'! Good luck!
  5. I'm not sure what you mean. Where would any contention come from? The purple line at the top is the CPU time that the playback is using. I've not measured, but looks to be around 1% CPU usage for 7 voices. So once done should come under 2% w/o PCM. In this example the audio uses ~3k VRAM and ~2k RAM. Compared to typical audio usage of the 80s, this is minimal; as a comparison in RMCs interview with Rob Hubbard, he said audio was typically given 10% of both CPU and memory. (It's a good book, you can grab a copy here: https://rmcretro.store/ ) The YM audio is a bit of a pain to use, given the clock speed difference you have to wait 144 CPU cycles between each write. You can of course do other things waiting for the ready flag, but that makes it much harder to integrate into an application. Napkin maths of 144 cycles and 7 voices would be around 1% of CPU usage.
  6. PSG Audio Test or Why We Only Need Vera. View File As has been pointed out recently there is tooling for the X16, especially in terms of trackers. There have been a few great examples of music on the forums, either playing a Amiga\C64 mod, or via a X16 tracker. And these are great. That said, I did think maybe the community was missing a trick. If the goal is to make music for the X16 do we need to be able to run the tracker on it? Doesn't that make writing everything harder? If you have a modern machine, it would be easier and quicker to create a tracker on that. UIs are easy. MIDI keyboard integration is a mere nuget package away. Can hand edit json files if you want. IO is trivial. That's not to say writing a tracker for the X16 is wrong, it's just a different goal. So that's what I did. Apart from the emulation of the X16's PSG which took a while to get going, it wasn't so bad to do -- WPF aside. I've ended up with an application which lets me produce X16 music. It can export an .asm file which can be imported into ca65, making integration into a project really easy with just two calls. It only uses single digit worth of cpu lines and 32 bytes in the ZP, so is pretty lean. That said, it does not yet support PCM audio not commands. The music from file attached is sourced from part of a demo file that comes with FamiTracker. What did occur to me while doing this, is that VRC6 ( https://en.wikipedia.org/wiki/Memory_management_controller#VRC6 ) music is pretty damn good. In fact I'm sure a player for .ftm files could be written. (Given how long it took to get just the first 3rd of a demo file working, I might write a pattern importer myself..!) For me, the audio quality demonstrates that Vera's PSG and some form of PCM is all that's needed for audio on the X8/16. (Sharpen your pitchforks!) It just needs to be a bit louder! What next? Like all projects that have gone from 'Proof of Concept' to 'Production' in one step, has resulted in some of the code being a bit crap. Especially on the WPF side! If anyone is interested, I'll try to shore the code up and will post with an explanation of how it works soon. For now the display shows the four counters. Counters for Frame, Line, Pattern, and the Next Line. Source is the VRAM address (I use VERA to stream out the data for the patterns, as it makes life much easier. I can't understate how useful this feature is.) The bottom table is: VERA registers Address of the instrument data Instrument Position Command Note Number Instrument Repeat Command 2bytes Parameters Submitter Yazwho Submitted 09/08/21 Category Demos  
  7. 26 downloads

    As has been pointed out recently there is tooling for the X16, especially in terms of trackers. There have been a few great examples of music on the forums, either playing a Amiga\C64 mod, or via a X16 tracker. And these are great. That said, I did think maybe the community was missing a trick. If the goal is to make music for the X16 do we need to be able to run the tracker on it? Doesn't that make writing everything harder? If you have a modern machine, it would be easier and quicker to create a tracker on that. UIs are easy. MIDI keyboard integration is a mere nuget package away. Can hand edit json files if you want. IO is trivial. That's not to say writing a tracker for the X16 is wrong, it's just a different goal. So that's what I did. Apart from the emulation of the X16's PSG which took a while to get going, it wasn't so bad to do -- WPF aside. I've ended up with an application which lets me produce X16 music. It can export an .asm file which can be imported into ca65, making integration into a project really easy with just two calls. It only uses single digit worth of cpu lines and 32 bytes in the ZP, so is pretty lean. That said, it does not yet support PCM audio not commands. The music from file attached is sourced from part of a demo file that comes with FamiTracker. What did occur to me while doing this, is that VRC6 ( https://en.wikipedia.org/wiki/Memory_management_controller#VRC6 ) music is pretty damn good. In fact I'm sure a player for .ftm files could be written. (Given how long it took to get just the first 3rd of a demo file working, I might write a pattern importer myself..!) For me, the audio quality demonstrates that Vera's PSG and some form of PCM is all that's needed for audio on the X8/16. (Sharpen your pitchforks!) It just needs to be a bit louder! What next? Like all projects that have gone from 'Proof of Concept' to 'Production' in one step, has resulted in some of the code being a bit crap. Especially on the WPF side! If anyone is interested, I'll try to shore the code up and will post with an explanation of how it works soon. For now the display shows the four counters. Counters for Frame, Line, Pattern, and the Next Line. Source is the VRAM address (I use VERA to stream out the data for the patterns, as it makes life much easier. I can't understate how useful this feature is.) The bottom table is: VERA registers Address of the instrument data Instrument Position Command Note Number Instrument Repeat Command 2bytes Parameters
  8. Hey now. If people start doing that there wouldn't be much of the thread left!
  9. Probably for the same reason some in the community would rather discrete components over a single FPGA. Personal preference. If there was a 'CPUWay' I'm sure the designers would be looking at it. You can of course use the same logic about a computer based on 40 year old tech, vs what $100 can buy you today.
  10. I'm not sure this thread will be helpful to anyone. This is the internet, someone will always be unhappy. As someone else said, should just go with your gut and that be it. I kinda feel there are two groups, those who want to make and ticker with the hardware so want expansion ports and the like or to be able to build their own machine. And those who are more software focused, so just want an interesting piece of hardware to code against. Personally 'phase 2' is best for me, as I don't own a soldering iron. That said anything is fine. As a developer I'd spend 99% of the time using the emulator anyway. The X8/X16 question does trouble me a bit. Just to quote the original post: VRAM access is fundamentally different. There is a 256 byte window into the VRAM which is mapped to a section of base RAM. You can move the window around. This is actually more efficient than what we do with the X16 and is only possible because it is all inside an FPGA. This does mean software written in assembly language will need to be tweaked to be compatible. The Vera is more or less the same. All of the same registers. Same PSG sound features too. But, programs that use more than 64K VRAM would need to be modified. There is no Yamaha sound chip. However, as we've seen already. The 8-voice sound system in the Vera is pretty darned capable! This is worrying as I'm not sure can say the Vera is more or less the same given it uses a completely different way to address it, as well has having half the voices and who knows what other differences. (Someone said it would only have one layer for example -- this may or may not be true. Only a handful of people would know this.) My guess is if the X8 is released now, and the Vera isn't 100% compatible, it will mean the X16 is unlikely to happen. You can't change something as fundamental as how you address the VRAM between two machines and expect software to be written so it is compatible. I really like how the X16 accesses VRAM with DATA0/1 with the marching, there is so much fun things that can be done as a developer there. But I also see the advantages of the framed VRAM in the X8. (The reduced RAM\VRAM doesn't bother me, it just makes it all the more challenging and so interesting to develop for. An X8 with the X16's Vera sounds great to me, but that wasn't an option.) tldr; Ignore this thread. Do whatever you think is best, everyone wants something different, you can't please us all, and ignore any negative noise when you do decide. Heh, good luck!
  11. Yazwho

    Modplayer

    Sounds amazing. Whats the cpu use?
  12. Ah, so I had a problem with my sheet as I was trying to visualise this. Its rebasing the volume. Given its an unsigned int8, surly you could just -32? Anyway, all makes sense now.
  13. I was looking through the emulators code to see how the PSG works. Even with my pretty terrible C knowledge, I understand most of it. Apart from the section below. I think I understand the syntax (xor the volume with $20, if the 6th bit ($20) is set, or the volume with $C0), I dont get why it's doing it. It kinda feels like it's meant to cap the value at 63, but it doesn't do that and there are surly better ways to achieve it anyway. So I was wondering if anyone else knew? https://github.com/commanderx16/x16-emulator/blob/master/src/vera_psg.c int8_t sv = (v ^ 0x20); if (sv & 0x20) { sv |= 0xC0; }
  14. My personal and theoretical ultimate 8 bit machine, would have at least a second 6502 as a coprocessor. This could serve many functions within the system, but the presence of the processor would make the development for the machine quite a bit more interesting. It would probably be far too complex, especially if it involved shared memory space, but it is fun to think about.
×
×
  • Create New...

Important Information

Please review our Terms of Use