Yazwho

This is featured on this weeks 'This Week in Retro'.

It's what I'm doing.

1160 View File Hope you enjoy this little intro! More on the audio player: Original mod by Archyx. See their other mods here: https://modarchive.org/index.php?request=view_artist_modules&query=69244 Thanks for looking. Submitter Yazwho Submitted 10/16/21 Category Demos  

The floppy constrains the coders to a set size and read rate, which imho is a good thing as it adds to the challenge. The X16's virtually unlimited and near instant read size of SD Cards does let you do things that aren't quite of the time.

Indeed, this is not a machine thats good at rendering things on the fly, but is that a bad thing? Were there any 8 bit era machines that were? When you think of VRAM as a stream of data it becomes very interesting, especially when your data structures are variable in size and/or larger than 256 bytes. Throw in the ability to set the step amount, and you've got the hidden power of the system.

Funny, I'd say 98% of the time I'm not using it to 'load stuff into VRAM'. Maybe you do, which is fine, but don't assume that is what everyone else is doing. Personally I find the idea of writing code that runs on all 6502 based machines boring. If I were writing a database or a spreadsheet then I guess so, but that's not where some people's interest is.

How very dare you.

The Mega 65 isn't available is it? Can't find anywhere to pre-order or anything similar?

I have browns, they're great and you can use them around people. I bought one of these https://www.aliexpress.com/item/33006060286.html?spm=a2g0s.9042311.0.0.6de84c4deCTALI and love it, apart from whatever is on the board which doesn't read some of the control buttons quickly enough! (I seem to always end up with an 's' when trying to hit ctrl-s) Oh, and it's not exactly well made, the layers don't exactly line up. Would be nice to get a better version. I looked at the Ultimate Hackers Keyboard above, but I _need_ function and navigation keys, as well as ANSI support. There doesn't seem to be much available in the not-at-all-niche 'UK 75% split' category.

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.

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

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.

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!

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.

Very cool!

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  

Hey now. If people start doing that there wouldn't be much of the thread left!

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.

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!

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.