plans for a totally custom smps driver (also a chance to learn how it all ticks)

I have plans on writing a purely 68k based SMPS driver because the sonic 3 driver is not compact enough in my opinion. I have gotten it working with basiegaxorz, but not with sega cd iso output. before I begin though, I am asking the community for their opinion on how the end product should be. The driver will (obviously be) open source, due to being in asm form, but a project this big would require a lot of careful planning. I just have one big problem: I cannot make up my mind on what direction I should go with it other than size and portability. So please answer the poll questions so that I can at least know what others would want in it.


Edit: didn't I say for Other, reply with your other category suggestion? I am seeing other show up but no reply...


How must I know what the community wants without that reply in such cases?


for features:


virtual pan would mean, DAC would be set up in stereo mode, and an invasive field interlieve would be done so that it appears on the left, right or in between


virtual volume means that the values of the sample fields would be increased or decreased to make it higher or lower. these would utilize pan/ams/fms flags if implimented and/or extra header space after DAC pointer (usually 0x0000)


multiple banks means having the voice pointers point to multiple groups of voices (thus theoretically allowing up to 65,536 voices in a song instead of 256) which can be used to sort out your voices, i.e. pianos in one bank, guitars in another, or a bank per channel. This would mean the voice pointer to point to the voices and the driver to load a byte 1 less than the voice pointer's value and get the bank size info from it, otherwise all banks would be assumed 256 voices in size.


Edit: I know I tend to make a lot of post edits, but I add things I either forgot to add, or I add a point people are missing.


For playlist, I am referring to song selection by number versus address. No playlist sceme means all music and sound effects would be called by the raw address in the rom versus a number. If the user wanted to use the number (like most smps games do) then they would need to program either a pointer list or an offset index and have it either start at 0 or 128 based on which scheme the end user wanted.

 

Correct me if I'm wrong, but from what I read, the "little endian absolute" addressing was used in S3K because the driver was written for the z80, so if you're going for a 68k based driver, that's already one question answered for sure.


On other matters, I'm all for everything that can improve flexibility and ease of use.

 

The issue I have with this is that if it's gonna be all MC68 custom, then you won't catch me using it anytime soon. The MC68 has to run the entire game which includes; Draw code, parallax deformation scrolling, animated tiles, palette cycling, object routines, sprite preparing/building, V-blank transfers (and H-blank if required at the current time). To get it to process routines to write data to sound chips as an addition can put that little bit of presure on the MC68 that is likely needed to do something else more awesome like animated parallax scrolling, or special extra effects as seen in say S3&K, thereas if you had the Z80 to process routines to write data to sound chips, this will open up that bit of extra processing time the MC68 might need, and well, considering the Z80 isn't doing much just sitting there (also not to mention that it was designed for music data transfering), then you might as well use it!


Though I will admit, the SMPS MC68 music routines don't seem to take too much processing time when I ran some tests of removing it in BroTro.

Spoiler

.. I needed the extra processing time for both Sonic and Manic on screen at the same time, wasn't fun =(

 

I would like to see how everything turns out in the final version.