I completed a new smaller VSync mixer:
https://github.com/Jubatian/uzebox/tree/vsync_mixer
This new VSync mixer has almost 256 bytes less RAM usage normally while largely retaining compatibility with the original kernel. Where compatibility is missing are applications which depended on the 2 x 262 byte layout of the mix buffer, this can be restored with the new MIX_BANKED flag for those. The games & demos in the master seem to be working all right with the new mixer.
New features:
The MIX_WAITVSYNC compile time flag moves audio processing into the WaitVsync() function instead of its normal location, the VSync interrupt. This reduces the size of the mix buffer even further as with this it is only necessary to cover the video frame's duration. It also makes the music & effect processing synchronous with the main program, eliminating potential interrupt hazards. Some of the games on Master work fine with it, some lack audio (those which don't use WaitVsync() to time themselves). If you use the WaitVsync() function, you can turn it on for these benefits.
The USER_AUDIO compile time flag removes the complete kernel audio engine, allowing you to write an own. You have to provide a definition of the new Process_Audio_Segment() function to fill the mix buffer yourself (it has one parameter, a pointer to the sample buffer to fill, you have to put MIX_SEGMENT_SIZE samples in it). This function is special in that regard that you can clobber all registers when you are writing it in assembler. (This USER_AUDIO flag is different to the original kernel's ENABLE_MIXER flag as the latter keeps the no longer functional music engine and all the associated allocations, while it leaves you with the bare mix buffer to work with).
You can also define MIX_BUF_SIZE and MIX_SEGMENT_SIZE on your own, for example combined with MIX_WAITVSYNC and the knowledge of the vertical size of your video frame, you can use these to select the smallest functional mix buffer size for your game. For example with a 200 rows tall screen, you may need 216 bytes for the mix buffer with a segment size of 8.
What is not yet included but could be is adding the UART code to the HSync processor. This would be useful if you use the VSync mixer with a video mode having room for the HSync part, allowing for example to create a networked game using the ESP8622. Modes like Mode 1, 40 or 41 could offer sufficient CPU resources for such.
Also I verified that the noise channel works fine in the new inline mixer (as I ported that to this VSync mixer), so I will likely merge that pull in soon.
New smaller VSync mixer
Re: New smaller VSync mixer
Wow, so many improvements!
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: New smaller VSync mixer
Nice work. You are an unstoppable programming machine.
Re: New smaller VSync mixer
I did some further generalizations.
It seems like it would be possible to allow for user audio even replacing the inline mixer (actually that would mean ripping off a little more of the kernel, in the VSync mixer + USER_AUDIO, you get the mix buffer and a convenient fill routine which you can supply, in the inline mixer, you have to create your own UpdateSound(), a HSync mixer).
However there are some noncritical problems in the kernel which would be better fixed before that. I now did a commit which resolved naming convention problems (now the functions which the user may interface with are CamelCase without underscore), and a timing bug in VSync (it was a cycle off and was compensated for within the mixer codes, already fixed in FoaD long ago).
I also would like to redo the video signal generation in a similar manner to Flight of a Dragon, using GPIOR0. This would affect the inline mixer removing the need for supplying the location of the sync edge in ZL (and thus finally 5 channels + UART would actually be possible to be used in the inline mixer!).
Another not so tightly coupled location of interest is the defines.h file which is rather messy, notably it contains properly documented compile-time flags intermixed with kernel internals which shouldn't ever be touched. I would split that into two files for good (so you would have a file which contains the flags you can provide with documentations, and another you don't need to touch or even look at ever if you don't care what is in the kernel).
Anyway, what will likely follow if you agree:
I would merge this in (it SHOULD work, but test with your games and report if not!). Then after this is in, I would continue with the aforementioned enhancements which are essential if you wanted to actually create some customized audio solution (they are essential as they become an interface, so should be fixed before anyone created anything too elaborate relying on it).
It seems like it would be possible to allow for user audio even replacing the inline mixer (actually that would mean ripping off a little more of the kernel, in the VSync mixer + USER_AUDIO, you get the mix buffer and a convenient fill routine which you can supply, in the inline mixer, you have to create your own UpdateSound(), a HSync mixer).
However there are some noncritical problems in the kernel which would be better fixed before that. I now did a commit which resolved naming convention problems (now the functions which the user may interface with are CamelCase without underscore), and a timing bug in VSync (it was a cycle off and was compensated for within the mixer codes, already fixed in FoaD long ago).
I also would like to redo the video signal generation in a similar manner to Flight of a Dragon, using GPIOR0. This would affect the inline mixer removing the need for supplying the location of the sync edge in ZL (and thus finally 5 channels + UART would actually be possible to be used in the inline mixer!).
Another not so tightly coupled location of interest is the defines.h file which is rather messy, notably it contains properly documented compile-time flags intermixed with kernel internals which shouldn't ever be touched. I would split that into two files for good (so you would have a file which contains the flags you can provide with documentations, and another you don't need to touch or even look at ever if you don't care what is in the kernel).
Anyway, what will likely follow if you agree:
I would merge this in (it SHOULD work, but test with your games and report if not!). Then after this is in, I would continue with the aforementioned enhancements which are essential if you wanted to actually create some customized audio solution (they are essential as they become an interface, so should be fixed before anyone created anything too elaborate relying on it).
Re: New smaller VSync mixer
I updated the branch combining it with the most current Master, so also with D3thAdd3r's streaming music. It seems to be working all right. I dunno if it will ever get into Master, anyway, it could be a nice thing for people using the VSync mixer (releasing ~256 bytes of RAM).
The MIX_WAITVSYNC flag however could be useful on Master, eliminating the interrupt hazard related to the Vsync interrupt firing while the main program is doing something with audio (if your game design can accept this change, hence the flag which can enable it).
The MIX_WAITVSYNC flag however could be useful on Master, eliminating the interrupt hazard related to the Vsync interrupt firing while the main program is doing something with audio (if your game design can accept this change, hence the flag which can enable it).
Re: New smaller VSync mixer
These are great features to have, kudos for the development behind all this!
Re: New smaller VSync mixer
Awesome! Removing the interrupt hazards is a great thing.
Re: New smaller VSync mixer
I understood some of the words you said
Nice work though in all seriousness
I do have a question though. Where you say:
EDIT: I see this is actually quite an old thread, so feel free to ignore my comment. Asking more out of curiosity then anything.
Nice work though in all seriousness
I do have a question though. Where you say:
Would this not run the risk of dodgy sounding audio when frames are skipped? So in other words, if the Vsync doesn't occur at exactly 60fps, would the audio not sound off? Sorry if it's a silly question. Just wandering if I understand the workings here. I guess it's only an option anyway, so saving memory vs risk of sound issues with a slow framerate. Options are always a good thing.The MIX_WAITVSYNC compile time flag moves audio processing into the WaitVsync() function instead of its normal location, the VSync interrupt
EDIT: I see this is actually quite an old thread, so feel free to ignore my comment. Asking more out of curiosity then anything.
Re: New smaller VSync mixer
Yes, audio would suffer then, that's why it would be optional. If you can design so you can call it appropriately, then you gain stability for your game. Normally the existence of interrupt hazards are not so apparent as in a typical sprite heavy Mode 3 game the CPU time after VSync is taken away the blitter, and game logic (including audio manipulation) is short enough to fit before that.
That the topic is old doesn't mean it is obsolete: I aim to maintain what I started as these are useful and might eventually more or less make it into Master.
Re: New smaller VSync mixer
Very useful. This makes the VSync mixer realistic to use in games, where before your common case of Mode 3 games, I think just about everyone threw it out of consideration the moment the inline mixer existed. Definitely balances out the cost and benefits, since theoretically in some cases, you can have full PCM sound tracks and effects with it. Hi-Fi, if one considers 15Khz 8 bit as an audiophile platform
I definitely will always be for more options at any rate.
I definitely will always be for more options at any rate.