New demo uploaded: PSG Audio Test or Why We Only Need Vera.

[Yazwho]

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
  
  
  

 

[Snickers11001001]

This is awesome!  Great work. 

How well do you think this can mesh with using vera moving sprites, moving/scrollling tiles, and updating lots of vid data?   I think that's been my concern about using VERA for music and not just sound effects:  Contention and resource traffic jams especially for doing a game.   The nice thing about the YM chip it has seemed to me in theory was the possibility of having some nice interrupt driven music that did not need to use a  bunch of cycles each interrupt storing and restoring all the VERA registers and state information.    

I'll be following this with interest!

[ZeroByte]

To me the #1 reason I like the YM chip is that it sounds like it does.

I like the fact that both the FM and PSG sounds can work together could make for some truly great stuff.

[Squall_FF8]

This project seems very promising! 

In general I agree - the productivity on a contemporary computer is much better then using directly x16, even if it is emulator.



So you made a tracker for a PC that can produce a demo like included file. Where can we see that tracker? Screenshots, video, the tracker itself?

Also how did you produce the music in the .prg file - did you transform/decode existing format or you manually loaded the values in your tracker?

[Squall_FF8]

6 hours ago, Snickers11001001 said:

The nice thing about the YM chip it has seemed to me in theory was the possibility of having some nice interrupt driven music that did not need to use a  bunch of cycles each interrupt storing and restoring all the VERA registers and state information. 

From all that I have read, YM has a major flow - writing to a register require the YM to be ready. That ready state on real hardware is around 156  CPU cycles at current configuration.  I bet even with all extra VERA overhead PSG writes takes less then that ? 

[Cyber]

10 hours ago, Yazwho said:

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?

If the goal is just to make such music, that can be played by X16, then it is totally fine and your solution is great. And many people will follow along and will be grateful. Besides even in old days some commercial software for some machines were created on different more powerful machines.

And for example if we are talking game consoles (say Atari 2600 or NES) there is absolutely no way of writing code or creating graphics/music directly on the system. So it is totally fine approach to use separate capable system.

But when we are talking about computers, there are some people who wish to create everything for the machine directly on this same machine. It's kinda part of fun. )

[kliepatsch]

12 hours ago, Snickers11001001 said:

How well do you think this can mesh with using vera moving sprites, moving/scrollling tiles, and updating lots of vid data?

I think this is a very lightweight music player in terms of CPU. If you leave the graphics of the demo away, I would guess you barely notice that the X16 is doing something. It boils down to how Yazwho implemented the instruments.

Well, and there's the fact that graphics and music both mess with the VERA registers. But if at an interrupt, you save the vera address at the beginning and restore it at the end, music and graphics should work flawlessly next to each other.

[Yazwho]

 

14 hours ago, Snickers11001001 said:

How well do you think this can mesh with using vera moving sprites, moving/scrollling tiles, and updating lots of vid data?   I think that's been my concern about using VERA for music and not just sound effects:  Contention and resource traffic jams especially for doing a game.   The nice thing about the YM chip it has seemed to me in theory was the possibility of having some nice interrupt driven music that did not need to use a  bunch of cycles each interrupt storing and restoring all the VERA registers and state information.    

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.

[AndyMt]

4 hours ago, Yazwho said:

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.

Wait! Im confused - because I don't do this in my games and music works nevertheless. I write as fast as possible to the YM until there is a KEY_ON command - or I have to yield because of a delay. This then is synced with the vsync interrupt. So yes, for sure there is more than 144 CPU cycles between each KEY_ON command, but not between each write. 

[Yazwho]

6 minutes ago, AndyMt said:

Wait! Im confused - because I don't do this in my games and music works nevertheless. I write as fast as possible to the YM until there is a KEY_ON command - or I have to yield because of a delay. This then is synced with the vsync interrupt. So yes, for sure there is more than 144 CPU cycles between each KEY_ON command, but not between each write. 

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.