RMT Hacking Ideas and Progress

[phaeron]

3 hours ago, VinsCool said:

Sorry for tagging you here @phaeron but I thought this may interest you  

I remember you mentioned having worked around this situation when you created the Altirra plugins.

Do you think it is possible to allow the Altirra plugins to accept the calls for the CPU clock speed while still keeping cycle accuracy? 

From what I could understand, I had to only send 3 parameters: the CPU clock speed depending on which region is emulated (1789773 for NTSC or 1773447 for PAL), the output frequency (44100hz), as well as the number of channels (2).

It could, the issue is that stock RMT doesn't pass correct values for the frequency. It defaults to PAL configuration while sending an NTSC clock speed to the POKEY plugin regardless of the 50/60Hz setting (1789790), so the plugin currently ignores the incoming frequency value.

[VinsCool]

2 hours ago, phaeron said:

It could, the issue is that stock RMT doesn't pass correct values for the frequency. It defaults to PAL configuration while sending an NTSC clock speed to the POKEY plugin regardless of the 50/60Hz setting (1789790), so the plugin currently ignores the incoming frequency value.

Yeah, that is also of what I was able to observe too.

I my test earlier, I added both the correct clock for each region, and the actual toggle for either clock speed, so I believe this could potentially be compatible.

 

That's pretty much why I asked for the possibility of taking it into account, assuming there would only be some code related to the cycles/scanlines per second or framerate to adjust for it.

I would be interested to know how the Altirra plugin would behave if it took the clock into account, and ran with my edited RMT version, based on the successful test I ran earlier with the original sa_pokey.dll in my video.

[phaeron]

46 minutes ago, VinsCool said:

Yeah, that is also of what I was able to observe too.

I my test earlier, I added both the correct clock for each region, and the actual toggle for either clock speed, so I believe this could potentially be compatible.

 

That's pretty much why I asked for the possibility of taking it into account, assuming there would only be some code related to the cycles/scanlines per second or framerate to adjust for it.

I would be interested to know how the Altirra plugin would behave if it took the clock into account, and ran with my edited RMT version, based on the successful test I ran earlier with the original sa_pokey.dll in my video.

It'd generate samples at the appropriate rate for the NTSC or PAL system clock, with the associated pitch changes.

 

One thing I haven't checked is what rate RMT generates samples at. Although my version of the POKEY plugin has its own sound output, it has to generate samples at the rate requested by RMT since RMT controls the timing of the sound calls. If this rate deviates from the actual playback rate then it will have to drop or duplicate samples to compensate, due to generating sounds synchronously to the emulated system clock.

 

[VinsCool]

53 minutes ago, phaeron said:

It'd generate samples at the appropriate rate for the NTSC or PAL system clock, with the associated pitch changes.

 

One thing I haven't checked is what rate RMT generates samples at. Although my version of the POKEY plugin has its own sound output, it has to generate samples at the rate requested by RMT since RMT controls the timing of the sound calls. If this rate deviates from the actual playback rate then it will have to drop or duplicate samples to compensate, due to generating sounds synchronously to the emulated system clock.

 

It generates sound at 44100hz as far as I could tell, split into chunks derived from an arbitrary division based on the CPU clock I think? I forgot what was done exactly, I will have to check again later for that.

I remember having messed around with the buffer chunk size and numbers and got mixed results ranging from crackling audio, higher/lower pitched output, and duplicate/skipped audio frames, haha

 

---

Also unrelated to the sound generation I got more changes done into the TRACKS UI part, most things work properly again after my bigger changes, except the X coordinate for TRACKS lines, so the mouse control is all over the place as it is for that part alone.

TODO: fix the X coordinates in TRACKS hitbox, everything else works as expected.

I will save this also for later  I've spent almost all my week end on this so I'm getting exhausted, haha

[VinsCool]

Hey guys, I have another small update related to the sa_pokey.dll output.

 

You all probably remember how it would output an obnoxiously distorted sound, which also had a huge DC offset, making the speakers to "pop" and stay like that?

Well I looked again at ivop's RMT sa libraries code and I was able to fix the original sa_pokey.dll sound based on this.

Sure, this is not the most accurate emulation there is, compared the Altirra plugin, but it's still nice to know I was able to give a small improvement to it  

 

@ivop I've sent a pull request to your repo with my tweaks, it really wasn't a lot but that seems to have fixed for it for good.

So now, the old plugin can finally output sound the way it should be, and it will also recognise the experimental RMT clock speed changes when paired with it  

 

---

So now about RMT itself, I have yet to fix the X coordinates maths, still not done yet, but I will provide more infos about the changes I made soon.

I need to make myself some sort of reliable debug output so I can track where the rectangles are drawn, and where the mouse pointer is, related to it...

At least until I figure it out so the pointer and cursor clicks won't be all over the place, thankfully the Y axis is not a problem right now ?

sa_pokey.dll

[VinsCool]

Hey guys, it's me again, sorry for the triple post!

So I have run another test run, using the bugfixed sa_pokey.dll, which was combined to my work in progress RMT version, and this gave me surprisingly good results!

First noticeable emulation inaccuracy: POLY5 seems to be incorrectly emulated, so it has a "fuzzy"
sound.
In general things in high pitch seem to fuzz a bit, but it's not as bad as it used to be with the
obnoxious DC offset "pop"...

At least, the CPU clock is now correctly switching between PAL and NTSC.  
So the general "pitch" for each region is actually correct now.
This was a thing I had to add into the RMT code, as I mentioned in the previous posts.

The other thing I actually fixed was the DC offset bug in the old sa_pokey.dll code.
Nothing else was edited yet, so I was pretty surprised to find out it really wasn't that bad now!
It could get a lot of improvements, but still, it's pretty okay compared to what it was before...

I have to say, it works as good as I would expect, so far.
It's insane how such a small bugfix + a proper CPU clock value being passed from RMT to the .dll
can do!

I hope this feature could be added to the Altirra plugin, because it's the most accurate by far.
But hey, now we know the clock speed situation was due to a missing parameter from RMT itself, and I'm glad I was able to prove it
could be done now!
Even with the very old sa_pokey.dll code, it works, which feels really nice.

The pitch is also hardware accurate, I have made comparisons.

 

I hope I can finish my RMT patch version soon for a nice update full of changes...

I'm pretty surprised to hear the High Pass Filter emulated pretty well, despite using REALLY old
POKEY emulation code here.
I guess the DC offset bug really made the experience unpleasant, hah!

 

Stereo sounds fine too, which is a good thing since the output between left and right was inverted.
Another thing I fixed earlier, otherwise it would have been a very distorted on the RIGHT speaker.

Multispeed also appears to not be a problem either.

I also added the code to actually reset the sound entirely each time region is switched, in order to get the
proper CPU clock fed into the POKEY emulation, making the sound correctly pitched.

And here, due to emulation timing differences, all the nice PWM manipulation sounds broken, but this
is *not* a bug per se. Simply timing differences between the old POKEY code, and Altirra's plugin!

The old POKEY emulation is not cycle accurate, which definitely makes many things behave weird and often
hard to predict. Which is precisely why many tunes sound... off... All the PWM is random! hahaha.
I'd say apart from that, it still sounds pretty good, and that's what really matters.  

 

Another surprising discovery I made tonight testing the bugfixed plugin: it actually emulates the Two-Tone filter!!!
It's out of tune, and clearly wrong, but it's impressive that it was actually possible to generate it all that time ?

I really did not expect that!

 

 

[ivop]

15 hours ago, VinsCool said:

 

@ivop I've sent a pull request to your repo with my tweaks, it really wasn't a lot but that seems to have fixed for it for good.

Merged. Indeed amazing that this bug was not fixed for so long.

[_The Doctor__]

This might also help some games of old out if the replay being timed as such helps reduce usage vs vbi in one system vs the other... should be interesting to hear the difference and not game play also... perception is such a big part of things with music and sound effects setting the feeling or mood.

[VinsCool]

Some more work in progress
A video explains better than words, so here goes  

Unofficial RMT Version Test 8 + UI Update + POKEY Registers View + Chipster Harmony by PG

Suddenly feeling bluer too, big thanks to PG for helping me with the graphics and colours choice  

[VinsCool]

More progress has been done during the week end:

So now, there's frequencies display, all of which is calculated in real time!

The notes and cents display is still missing, but I will eventually add it too

 

Also, I was able to create formulae based on my tuning spreadsheet, and tonight I discovered an interesting pattern...

 

So... I am now able to compute the Distortion C frequencies, for 15khz, 64khz and 1.79mhz modes, in real time, without the need of lookup tables!

My code is also *smart* enough that it will automatically detect which AUDF value belongs to which Distortion C table

I also added Distortion 2 1.79mhz mode using the same principle, but the other modes are still missing (I am lazy hehe).

 

Since this is my own code I wrote from scratch, I'll share an example of what I did for Distortion C 64khz: ?

...
case 0xC0:
                for (int n = 0; n < 70; n++)
                {
                    x++;
                    y = (x == 4) ? 6 : 3;
                    if (x == 4) x = 0;
                    if (n == 68) y = 2;
                    if (n > 68) y = 1;
                    freq = freq - y;
                    if (freq == audf)
                    {
                        PITCH = (((float)FREQ_17 / 70) / (audf + 1)) / 2;
                        break;
                    }
                    else 
                        PITCH = (((float)FREQ_17 / 210) / (audf + 1)) / 2;
                }
                snprintf(p, 10, "%9.2f", PITCH);
                break;
...

So I figured out a very constant pattern of AUDF frequencies that will land in the Buzzy table here, so I made the code to output either that would apply, and sure enough, it works very well!

There's still the "invalid" frequencies that aren't taken into account, but thankfully I believe they're so few it isn't going to be a problem for now.

The same principle applies to a lot of things, so I'll make more in the next few days, including 16-bit, POLY9 (finally it will be musically useful?!), Distortion 4, etc.

 

This is so much fun, and I learn new things everyday!  

[VinsCool]

BIG improvements in my Registers View code, now Frequencies, Notes and Cents are displayed for a lot of modes already!
Playing back some soundtracks~

How about that: I have figured out a way to compute the fundamental frequencies, notes and cents, all from the good old POKEY, in real time.

No lookup table was used in the making of this experimental feature, the Registers View is 100% my own code, written from scratch, with several helpful ideas and suggestions from my friends Eulous and Puna, thanks a bunch you two for helping out a total noob like myself :3c

I am totally sleep deprived right now, but this was TOTALLY WORTH IT
Computing actual POKEY tuning in real from RMT when?! 
Someday maybe... ?

 

I remember someone told me a while ago this kind of stuff would have been impossible to make.

I'm happy to have proven it was totally possible with some dedication!  

[VinsCool]

A bunch more work has to be done, here, but I have some more to come, this time related to the entire UI ease to use.
editing more commands, where Transposition, Volume changes, Instrument changes, etc can all be done without the requirement of a Block Selection, REALLY useful for quick and easy edit of a single row, which itself is just a cleverly executed Block Selection at cursor position in order to make it work.

Of course, normal selections also work just as well! the keys demonstrated here are CTRL+SHIFT+LEFT/RIGHT to change instruments, +UP/DOWN to change volumes, CTRL+F1/F2/F3/F4 to transpose semitones down or up, then octaves down or up, and the last misc demonstration is the tweaks in the way Pastes are done, where a command to force deselecting blocks is done first so pasting where the cursor is located will always work, and the test of Paste Merge with CTRL+M, which works also just as good as the old CTRL+V paste

Not shown in the video are MANY optimisations in the general stability when keys are made use of, which fixed some tiny problems when the text was edited or Instrument/Infos were edited with the SHIFT key pressed, a total re-work of PROVE mode where navigation is now exactly the same as editing tracks/songlines, without the risk of overwriting those playing notes in real time.

Exception in Instruments and Infos line, which will still be editable and operate the same regardless of being in Editing or Jamming test mode...

I've also added a handful of new commands not shown here either, but I am pretty sure there will be many things you guys will be happy to use hopefully very soon now!

 

Now I need to address a broken feature I only discovered yesterday: TXT format.

It's not working properly anymore, making it load garbage data, and I couldn't really understand how the code for it works, so I took the risky decision to temporarily disable the support of loading and saving TXT files for the time being.

I wanted to be able to fix it, but considering the massive amount of work done, I believe that's a very small compromise over everything else done and still in the work right now.

Now, the TXT format, I hope I can fix at a later time, for now, I decided to leave it out behind an error message I added earlier today, so that would at least prevent anyone from using it and find out it doesn't work right.

 

That being said, I am almost done with the entire rework of keys, commands, and most of the UI parts that have their own little quirks, and even in this pretty unfinished state, I can tell you all things will work really well!

Even these few Tracks editor hotkeys alone make a HUGE difference, it changed the workflow of menuing and going through 3-4 steps to fewer keys and have much finer control over your patterns, all of which operating incredibly smoothly, due to the changes I applied in the input handler code.

CAPSLOCK also has a proper implementation but is only gimmicky for simulating a "REVERSE SHIFT" in the song/instrument name lines, I got rid of pretty much ALL conflicts between screens and functionalities, being testing keys with SHIFT, inputting text, typing text in uppercase, and regardless or where you moved the cursor or how you ended in a specific location, it should always return the correct output now, and finally you DON'T need CAPSLOCK to do all of that stuff either!

Also, the old NUMLOCK code is gone, same for the old CAPSLOCK code, multiple bugs from the original RMT up to 1.30 have been fixed, or worked around if I couldn't do better (see, TXT format), but in general, the UI gained a lot of improvements since I started learning C++ by exploring the program's internal structure.

 

There's still many things to edit but I hope I will have soon a new unofficial RMT version.

Even in its current form, it's very usable, in fact I keep getting carried over while testing it! So once I am satisfied and am sure I didn't break more things and finished my total revamp of keys and commands, I will only have to edit the menu/dialog strings to match the changes, and update the Manual so at least it will be a lot more clear to see what has been changed and what has been added or removed too!

 

Anyway, that's all I have right now, I hope I'll be right back soon for more updates!

[VinsCool]

NTSC timing test.
Apart from the obvious lack of NTSC pitch and the quieter volume compared to Altirra emulator, that turned out to work pretty well I think.

The method i used was pretty cursed, but hey the results are what matter right?  

 

 

Anyway, I think the time has come for a new unofficial RMT version, everything seems to work okay.
I have finished rewriting the manual to match my design in progress, also fixing a handful of bugs, adjusting some things here and there, basically polishing the current version to be as good as it could be before sharing.

So.... yeah, I will make a new thread in a bit and try to not disappoint everyone with my fork version.

I wanted to released it yesterday for Christmas but the manual took me a lot longer than expected, and then the NTSC experiment took my attention for the evening... So here goes nothing! lol

 

I'll be back soon with something I hope people may enjoy.

I have spent a lot of my free time into this project, and also worked really hard to improve and expand the original code into doing things I wanted to do  

[VinsCool]

And done, I've finally posted the release thread!

Enjoy!

 

I will still use this thread when I share more development rambles, but I will try to keep the other one for discussions, updates, and helping people if I can  

[VinsCool]

I guess my NTSC timing hack is close enough now.
If the Altirra plugins get updated to support my sa_pokey code to switch the CPU clock between region, it should, in theory, be identical to the emulator output.
Or at the very least, very close to it.

So right now, it's almost exactly the same as playing NTSC timing in PAL region, the tuning and speed of execution will be almost perfectly identical.
So I guess that's good enough, for now ?

[VinsCool]

So while I'm in the process of rewriting my Patch16 hack, I decided to experiment a little further about the instruments design as well.

 

There is a unused byte in all of them, and they're always set to 0, currently.

However, I was able to exploit this, and turn this into a proof of concept feature.

 

Let's see what I have been brainstorming so far with this:

;
; proof of concept:
;
; Manual Tuning Table Per Instrument
;
; format: .byte
;
;	$LM 	= LSB offset(s)/MSB offset
;	bit(s) 	7-6	= LSB, for 4 possible values ($0x, $4x, $8x, $Cx,)
;		5	= unused
;		4	= unused
;		3-0	= MSB, value from 0 to F (nybble)
;
; how to use:
;
; MSB offset: AND with $0F (%00001111), ORA with $B0, then write into nr+1
; LSB offset: AND with $C0 (%11000000), then write into nr
;
; The steps of $40 fit nicely into a division of 4, 64 possible values per subpage, and 4 subpages (tables) per page
; Bits 5 and 4 currently have no purpose but they could have some cool features too
;

This is only the theory, so far.

But I have been giving it a shot, and this appears to be functional, indeed.

 

Now there is also the method I have taken inside the (now restarted) rmtplayr.a65 patch.

 

I first created a new FEAT, called FEAT_TABLE_MANUAL, which will be useful for conditional assembly (obviously)

I also created a new variable, called trackn_pointertable, for each channel, addressable by index x, like usual.

That makes 4 (mono) or 8 (stereo) bytes added in memory, but let's not worry about this right now.

Then I made use of this stuff in 2 specific locations.

 

First, inside the instruments initialisation subroutine (SetUpInstrumentY2), below the FREQSHIFT byte code,since they're more or less in order, it makes sense to put this below it:

	IFT FEAT_TABLE_MANUAL
	ldy #11
	lda (nt),y
	sta trackn_pointertable,x	
	EIF

So far so good, this makes plenty of sense, and it is pretty easy to guess what was done here.

I've loaded the 12th byte of each instruments used during that track line, and stored it in memory for later.

 

Now, here is the interesting part, right in the same location I've originally used for the hijacked bloated code I had made before for loading tables based on the AUDCTL value:

	IFT FEAT_TABLE_MANUAL
	lda trackn_pointertable,x
	beq pp2sno
	tay
	and #$0F
	ora #$B0
	sta nr+1	;Bx00, where x is manipulated
	tya
	and #$C0
	sta nr		;B0x0, where is manipulated
	lda reg2
	and #$0e
	tay
	jmp pp2syes
	EIF
; here's the following code, since I had added labels there, to make more sense contextually
pp2sno	
	lda reg2
	and #$0e
	tay
	lda tabbeganddistor,y
	sta nr
pp2syes	
	lda tmp
	ora tabbeganddistor+1,y
pp2sdone	
	sta trackn_audc,x
    ...

...and that's it!

Tables now get loaded in memory based on the 12th instrument byte, and that is pretty much all there is to do.

On top of that, the distortion envelope essentially becomes its own thing, so you can create many combinations as well  

 

Unfortunately, there are some limitations as it is right now, but I believe there will be a way or another to work around it  

The most obvious one there is that you can't change the table in the instrument with this setup, simply because the distortion parameter won't be taken into consideration there!

The other obvious issue is that you cannot yet make use of it in RMT directly, since there is no code for editing that byte currently, lol

 

I had to edit my .rmt files earlier by hand to achieve it, and thanks to ivop's RMT format reverse engineering that was not terribly difficult, just a little annoying  

So yeah, quack ? I know the word, thanks for reading ?

[VinsCool]

I've figured out the Distortion C 16-bit pitch formulae.

 

Turns out most of the initial divisions come from the 1.79mhz counterpart, so in theory the same principle could apply on several other distortions.

 

Rambles below:

 

Distortion C : $031F = 148.0hz 
Distortion A : $1796 = 148.0hz

what could be the pattern???

Distortion A formula: (Master Clock / ((16-bit MSB/LSB AUDFs) + 7) ) / 2 = Frequency
Example: (1789773 / (($1796 hex or 6038 decimal) + 7)) / 2 = 148.04hz (a slightly sharp D-3)

So I must somehow do the same in reverse to identify the Distortion C value... well... 
How about using the same divisions from the 1.79mhz frequencies calculation? Maybe this is also the same...
Let's try...

Gritty: 7.5
Buzzy: 2.5

I already have a known value, so let's try it:
Example: ((1789773 / 7.5) / (($031F hex or 199 decimal) + 7)) / 2 = 148.04hz (a slightly sharp D-3)

...well fuck me, this was INDEED the same thing LOL

Amazing!

Distortion C Buzzy formula: ((Master Clock / 2.5) / ((16-bit MSB/LSB AUDFs) + 7) ) / 2 = Frequency
Distortion C Gritty formula: ((Master Clock / 7.5) / ((16-bit MSB/LSB AUDFs) + 7) ) / 2 = Frequency

And now... All there is to do is to identify the pattern of which is which...

That was a lot more straightforward than I expected.
So identifying the pattern shouldn't be very difficult based on the other instances I had calculated in 15/64/1.79 modes.

 

Buzzies also still follow the 6-3-3-3 pattern!
That will make this a LOT easier now.

Lowest Buzzy tone: $FFFE (65534), pattern constant appears to be 3-6-3-3...
let's calculate and see if we indeed land in them all correctly!

A potential of 4369 total buzzies sequences, where buzzies are 65534 and 2 included...
Now I need to find how many operations are needed. 
A Buzzy loop has 4 values, so: 4369 * 4 = 17476 total subtractions maybe?

This gives me a nice number indeed.
4369 * 6 = 26214
(4369 * 3) * 3 = 39321
39321 + 26214 = 65535

That seems like it may work.
let's go with 17476 times a subtraction runs inside the function loop.

Mockup code:

case 0xC0:
        if (16-bit)
        {
            x = 0;
            y = 0;
            freq = 65534;
            //insert here whatever code is needed to concatenate AUDF2+AUDF1 or AUDF4+AUDF3 into a 16-bit number...
            audf16 = audf2 + audf1;    //you get the idea => audf2audf1 
            
                    for (int n = 0; n < 17476; n++)
                    {
                        x++;
                        y = (x == 2) ? 6 : 3;
                        if (x == 4) x = 0;
                        freq = freq - y;
                        if (freq == audf)
                        {
                            PITCH = ((FREQ_17 / 2.5) / (audf16 + 7)) / 2;
                            break;
                        }
                        else 
                            PITCH = ((FREQ_17 / 7.5) / (audf16 + 7)) / 2;
                    }
                    snprintf(p, 10, "%9.2f", PITCH);
                    break;
        }

Looks like that's about it?
There are all the unstable MOD5 values still not taken into account, but let's not bother with them for now.

 

Also that whole for loop is not efficient at all, but at least the idea is here, to generate 65536 entries in memory, who could have thought this chip would be so complex despite its age?

Edited January 2, 2022 by VinsCool
Fucking automatic emoji insert, leave my ':' alone

[VinsCool]

Still working on the remade Patch16 code right now.

The better implementation of it gave a massive boost for the stability and performance, mainly by making the code a lot more compact and much less bloated, by replacing all the "AND/TYA" operations with BIT, making a lot of it waste a lot less cycles and bytes.

Also the Proof of Concept tables loading by using the 12th instruments bytes can still be executed as well, this one taking priority over the "automatic" approach when they are combined  

 

I also seriously took the conditional assembly approach with much more care this time as well, compiling using the FEATURES shouldn't be a pain in the ass compared to the bloated mess I made so far.

I've added few new FEATURES for assembly but it's a little too early right now for giving more details, but I will make sure to elaborate further soon.

Overall, I think did a much better job compared to the last time, I suppose I learn how to code more efficiently every day ?

 

Now the most interesting part is that I finally figured out a way to address the "delay by 1 frame" AUDCTL changes when the tuning tables depended on its value.

Well I've pretty much found a way to fetch the AUDCTL as early as possible, making the entire workaround method I had made before totally useless  

 

The best part is that I did not yet re-implement the CMD7 hack I made, so there is no AUDCTL envelope going there, and yet and I can still tell how much snappier it is already.

In fact, the entire CMD7 hack will need a different approach, because my "fetch AUDCTL early" code is too efficient!

I literally broke all the workarounds I had added before, including the CMD7 hack, which itself originall was a way to force the values as soon as possible ?

But hey, the improvements in the optimisations, and the fact I did not make a lot of shit code compared to last time made a pretty drastic difference, even in this unfinished state  

 

Have a test binary, I remember this one would always have some weird stutters due to lagging 1 frame every time it was trying to load tables.

This time, it's really punchy and aggressively bassy!  

phat phuk p16-2.obx

 

I should be done very soon now, I essentially have 80% of the Patch16 hack rewritten, and it's performing so much better than before.

All I need to do essentially is finish up the optimisations, find a way to still get everything compatible, re-implement the CMD7 AUDCTL/Two-Tone envelopes, and that's about it I think?

Hopefully I did not break anything this time, I remember the older hack was full of holes, even after the improvements posted in October, it was still a lot of holes.

[VinsCool]

Here's another test.

The instant AUDCTL values loaded in memory make a HUGE difference in the mix, since there is no delay anymore!

So yeah, I'm incredibly happy about the improvements so far  

Mr Tinnitus' Super Special Jukebox p16-2.obx

[VinsCool]

Done re-implementing the Two-Tone hack with the CMD7, all there is missing now is the CMD7 AUDCTL envelope as well

 

Progress:

Test binary with the CMD7 hack for Two-Tone: fake sid.obx

rmtplayr code I'm editing, a bunch of things are left to be done, and optimise what I added, but not much is left now. rmtplayr.a65

 

I'll continue another day, I'm pretty close to something now  

The AUDCTL early stuff still needs some testing, but seems like my initial idea was going way too aggressively, and so it killed both the CMD7 idea, and CPU cycles as well.

Seems like the alternative in the code that is not commented out was all I needed, but I must confirm it is indeed "frame perfect" before claiming this did the trick.

[VinsCool]

I think I am now done rewriting the Patch16-2 hack.

Here's some tunes I used for testing.

The main point of interest here is the performance and the "no delay" design, making everything sound very smooth this time!

[Warning, lots of flashing on the screen, be careful if you are sensitive]

Improvements:

- HUGE performance boost since my hijacked 6502 ASM code is not shit this time  

- A lot less bytes are also used since I found smarter ways to achieve most of the things I wanted to do, while still saving tons of CPU cycles in the process.

- Conditional assembly properly supported this time, making optimisations a lot easier and better to apply, and still remain compatible with my hack ( @pps, this one is for you!  )

- Figured out a more elegant solution around the AUDCTL manipulation, 1 frame delay when setting bits and using them in tuning tables is effectively not a problem anymore!

- Improvements with the CMD7 AUDCTL envelope, Two-Tone Filter toggle and Volume Only mode output, tweaked to waste a lot less cycles, and also work better as well.

- Support for 12th instruments byte, which can be used to manually chose what tuning tables to load, this is however not a RMT feature yet, so modules must be edited by hand right now. It does work, however!

 

I'm still touching it up and testing it to make sure I did not break anything by accident (ie I found out earlier I messed up the Stereo mode and loaded the Left POKEY AUDCTL values, oops!), but I'm really happy of the results right now.

I'll update the 6502 ASM Patch16 code on Github once I am done testing and I will also post a new RMT version update with these improvements.

 

I think the most important part here is the general performance boost, and getting it do things I wanted in a more efficient way too!

The ASM FEATURES being implemented properly with my design should be a lot less annoying this time too. 

Clearly, I did a lot of things wrong the first time, but I think this version will be a very good improvement   

I'm still learning as I experiment with this, so I knew I could do better, and most likely I will find a way to do even better later.

phat phuk p16-2.obx sketch 63 p16-2.obx sketch 64 p16-2.obx sketch 65 p16-2.obx chipster harmony p16-2.obx first festival of stars wip p16-2.obx bouncy bouncer.obx

Edited January 5, 2022 by VinsCool
added a warning for screen flashing

[pps]

It is not just for me But coders, like me, that know nearly about nothing about making music, will love this.

17 hours ago, VinsCool said:

- Conditional assembly properly supported this time, making optimisations a lot easier and better to apply, and still remain compatible with my hack ( @pps, this one is for you!  )

 

[VinsCool]

Tiny preview of what will come...

That's right, full 16-bit support, including some effects (which will need to be fixed a bit, but they do work!)
Also I know the Registers View is wrong... I did not yet add the code for 16-bit pitch lol

 

I pretty much have done much of my Patch16 improvement, and managed to find a reliable way to use 16-bit, so this is what I am working on right now  

It's the last major feature I will add for now, then I'll optimise the code my best I could do it, and finally post a new RMT version with it included, the ASM code I edited (it's no longer a mess!) 

I will also update RMT to support the 16-bit pitch accuracy display for that purpose.

 

Here's a test binary you can try by yourself, simply drop in the RMT Binaries folder of the latest RMT 1.31 version, and be wild!

Note there are a few bugs I need to fix, mainly related with effect commands, but other than that, it should work pretty well, but this time it will be easy to use like the original BASS16 code  

 

tracker.obx

[VinsCool]

Making some progress with the 16-bit improvements:
- Fixed Vibrato
- Fixed CMD2

tracker.obx

I'll fix the Table of Notes/Freqs next, since this is using more or less the same approach.

 

Had to think outside of the box for this one, but it's finally going to work properly, at least  

It's important to remember the original 16-bit code and mine are very different things right now, so adding support for effect commands is a lot more difficult as a result.

So I hope I can get the other effects functional later   

[VinsCool]

Alright so this is what I've got so far.

 

improvements since last time I posted here:

- Re-addition of Distortion 6 BASS16 using my own 16-bit code this time, which has a few improvements
- AUDCTL timing seems to be absolute now! I have not done a full in depth test so any tune with wobbly timing, may see a drastic difference here!
- Merged the GET_AUDCTL_EARLY and AUDCTL_CMD7 features, which now saves bytes, a lot of cycles, and multiple conflicts as well, something I had not noticed for a long time, actually.
- Properly reset the SKCTL registers when ESC is pressed, by adding few more instructions in the rmt_silence routine, in order to disable the Two-Tone filter if it was enabled previously.
- Also reset the swapped Sawtooth tables pointer, so the waveform won't stay permanently reversed
- Some code cleanup, as you can see, I am still in the process of optimising everything I was doing, and I can say with confidence by far the AUDCTL timing is a really huge improvement.
- Re-organising code as efficiently as possible to allow very compact conditional assembly using the FEATURE definitions, also still work in progress, and so far it's really getting good there.

 

So I know I did say I would have made the export binaries, but with so many things to improve, and sometime make discoveries out of nowhere to fix certain things even further, it's not yet ready as a result, but I promise this will be well worth the wait

By far the timing itself with instrument AUDCTL bytes drastically improved the stability of a lot of things, so it's worth giving it a shot on tunes that seem chaotic (or wobbling).

tracker.obx