Moving beyond RMT ?

[Moving beyond RMT ?]

23 minutes ago, rensoup said:

So looking at the source, there's a AUDCTL setting per instrument which never varies...

you're saying it should also be part of the envelope, same as dist ?

 

I also see, that each instrument's AUDCTL value is mixed into the final AUDCTL value, right ?

Yeah, that's what I can think of. That seems to be what I understand too.
 

23 minutes ago, rensoup said:

Yes that's mostly what I mentioned in the first post... 

 

But I'm thinking a simpler (crappier too) solution may be possible: a text file that would override/ extend instrument parameters

 

Let's say I want to extend DISTORTION. Right now it's limited to 8 but I want a big number like 1024.

let's say the envelope length is 10, there could be something like:

 

[instrument0]

EnvelopeDistortionTable = $0028, $0196, $0214...  (10 values) 

 

it could be possible to specify the table format too (8 or 16bit) 

 

EnvelopeDistortionBitFormat = 8,16,8,...  (10 values)

 

the instrument text file would have the same name as the RMT file with a different extension and be loaded automatically when converting (if custom table option is selected)

 

The custom table file would contain all the tables

 

?

I imagine that could work?
That would only be part of the editor itself after all, right?
 

16 minutes ago, rensoup said:

so in layman's terms, 15khz sound provide lower frequency sounds than 64khz and 1.79mhz higher frequency ones ?

Yeah, pretty much  
 

16 minutes ago, rensoup said:

The AUDCTL settings are a little confusing: from https://en.wikipedia.org/wiki/POKEY

Quote

Bit 0
$01: (15 kHz), choice of frequency divider rate "0" - 64 kHz, "1" - 15 kHz

Bit 5
$20: (CH3 1.79), set channel 3 frequency "0" is 64 kHz. "1" is 1.79 MHz NTSC or 1.77 MHz PAL
Bit 6
$40: (CH1 1.79), set channel 1 frequency "0" is 64 kHz. "1" is 1.79 MHz NTSC or 1.77 MHz PAL

All frequency dividers (AUDF) can be driven at the same time by 64 kHz or 15 kHz rate.

Frequency dividers 1 and 3 can be alternately driven by CPU clock (1.79 MHz NTSC, 1.77 MHz PAL). Frequency dividers 2 and 4 can be alternately driven by output of dividers 1 and 3. In this way, POKEY makes possible connecting of 8-bit channels to create sound with 16-bit accuracy.

any way of rephrasing that more simply ?

From what I can understand, every channels can rely on the 15khz or 64khz clock, at once.

When channels 1 and/or 3 use the AUDCTL setting to be clocked at 1.79mhz, they are independent from the main clock (15/64khz).
When the join channel 1+2 or 2+4 bits are enabled, along with 1.79mhz, the 16-bit output happens in the channel providing the low order byte, while the 1.79mhz channel provides the high order byte.

There are also many more combinations that could be done for different results, but that's irrelevant for that question, right now  

I could also be mistaken too, so I would ask for anyone who knows better to clarify any information I got wrong  

[RMT2LZSS: convert RMT tunes to LZSS for fast playback!]

9 minutes ago, rensoup said:

Not sure when you say $60, you mean dist $6 right ?

Yeah. When I mention Distortions by their number, I mean the ones used in RMT, so Distortion 6 is this one, Distortion E is Bass Table 2, etc

 

11 minutes ago, rensoup said:

You're right... I think ?

 

I totally forgot about channels... 16bit table is only used when channel 1/3 have dist $6, for channel 0/2, dist 6 would use the 8bit table.

 

(I tend to number channels from 0 to 3, not 1 to 4... well not always!)

 

I don't understand what you mean with dist $C though...

Yeah that's what I mean. in RMT, Distortion 6 uses the bass table 1 when it is used in the channels that cannot output 16-bit, and switches back to the 16-bit tables on the compatible ones.

I compared 6 and C because both use the Bass Table 1, and in the .txt file, 6 and C can have their own table, that's what I was saying regarding that.

It's not useless  
 

14 minutes ago, rensoup said:

yeah like I said I don't really know how to test them 😏 but I can use your table for the next release if you want.

That's the reason I made a test .rmt module, it uses all distortions every pattern, so I can easily identify what is doing what, and was also able to get my table changes tests as well  

[RMT2LZSS: convert RMT tunes to LZSS for fast playback!]

Also $60 is not actually useless.
When used in channel 1 or 3, it falls back to whatever was assigned to it, and by my tests I was able to get 2 unique tables whenever C or 6 was used, 6 would simply use the 16bit tables when the supported channels are used, being 2 or 4

Edit: I can also confirm the new order now works exactly as expected

I only have 1 tiny nitpick, the default values used in these tables are not the correct one, but at least they can be changed  
I reused my test tables for $20 and $40 in this .txt file, and also wrote the real tables used by default in RMT 1.28, so at least it won't be weird when only 1 single table actually gets custom.

CustomNoteTables Vin V2.txt

[RMT2LZSS: convert RMT tunes to LZSS for fast playback!]

1 hour ago, rensoup said:

I guess the way I ordered the tables was totally confusing 😃. And to make things worse I just noticed that the Dist value is actually multiplied by 2 just so that it's more convenient to use inside the 6502 player... 

I also understand your comment in your table:

 

"//frqtabbasshi --- high byte order, uses the AUDC setting used for $60?"

 

which is actually right... when dist 6 is used, the player switches to AUDCTL_CH1_FASTCLOCK (1.79mhz) and AUDCTL_CH1CH2_LINK (16bit) for channel 1 (same with channel 3)

 

This means there aren't 8 8bit tables available but 7. 

 

So when I previously thought I could easily have a different 16bit table for 1.79mhz and 15khz, that's not actually possible unless I lose another 8 bit table

 

Hopefully I didn't miss any other sneaky code...

This is the original order (the index being the envelope distortion parameter)

            frqtabpure
            frqtabpure
            frqtabpure
            frqtabbass1 // sneaky 16bit override
            frqtabpure
            frqtabpure
            frqtabbass1
            frqtabbass2

 

but the tables are actually stored in the following order in memory:

frqtabbass1
frqtabbass2
frqtabpure

So I simply added new tables names like this 

            frqtabpureA
            frqtabpureB
            frqtabpureC
            frqtabbass1A // sneaky 16bit override
            frqtabpureD
            frqtabpureE
            frqtabbass1B
            frqtabbass2A

and added new tables data after the original ones in memory

 

frqtabbass1A
frqtabbass2A
frqtabpureA
frqtabpureB
frqtabpureC
frqtabpureD
frqtabpureE
frqtabbass1B

 

so 

envelope dist 0 is actually table 3
envelope dist 2 is actually table 4
envelope dist 4 is actually table 5
envelope dist 6 is actually table 0
...
envelope dist C is actually table 7
envelope dist E is actually table 1

 

That allowed me to remain compatible with the original RMT and made it easier for me to test that it actually worked...

I've changed it for v1.51 (grab it from the usual spot) so that the tables match the envelope dist param. and I've removed the names in the comments because they don't really make sense anymore.

envelope dist 0 is table 0
...
envelope dist E is table 7

 

I believe this should work but I don't really have a way to test it... Usually when making a change I just compare the newly output Pokey data with old known valid pokey data but in this case there's none

(Guess that happens when breaking new grounds 😁)

 

Awesome!
So I was not mistaken, the order really was weird lol

Thanks for rearranging it, this should make it a lot easier now.
If it weren't from trying out random order to find which table belonged to which, I wouldn't have been able to at least get my test to work at all  
I really was confused at first lol

[Trying to make some PoKEY music!]

1 hour ago, emkay said:

As he is mixing the relevant 2 channels you see the following (around 2:24)

 

 

 

You see a new waveform that is typically sounding more voluminous, as you also can get when listening to the tune. 

That's what I was talking about yesterday... this is not supposed to look like that 😏 At least not in a single channel.
But I digress, I got some cool ideas I wanted to try out, now with the new RMT2LZSS release, many things could be done in a much, much faster and easier way  

[Trying to make some PoKEY music!]

13 minutes ago, emkay said:

The relevant parts were about when channels use the same frequency, or directly one octave above or below. 

If one channel is using the bass generator, and another uses very high tones, doesn't add to the wave manipulation, but interferes the demonstration of the wave mix. 

 

 

 

This is one row of waves of a software analyzer recording .

 

The colors show the depending waves of used channels.

You might see  the three "pink" pointed waves having three different offsets .

The left one has the shortest offset, then the middle, then the right one with the longest offset.

Green: the left one has a longer offset than the right one.  

 

This is not filter interaction. This is the direct channel interaction. 

Normally when POKEY is doing music, musicians use the chaotic intervalls, to have some spacy sound.

It's also possible to control that, and to put controlled Ring Modulation everywhere, to make the tune sounding consistent. 

To get the right feeling for it, a visualisation of the relevant channels is recommended. 

 

 

 

 

This is why I like to have Altirra's oscilloscope for individual and all channels shown on screen, that way it's easy to see how the resulting sound looks like, usually with a good resonance (being in-tune in most cases) it will show a nice stable output, sometimes as totally new waveforms, which is a lot of fun to manipulate.

[Trying to make some PoKEY music!]

2 hours ago, emkay said:

 

Not really

 

You are about the joined channels using the "Filter". 

I'm about direct wave addition of two channels. 

That is best visualised when all channels are mixed together, mono output style!
In that case, I agree with you  

[RMT2LZSS: convert RMT tunes to LZSS for fast playback!]

Took me a bit to figure out, but I think I managed to find how to make use of the custom table feature... it was a lot of trial and error but now it worked.
I managed to identify what table belongs to what distortion setting, thankfully, and wrote my own comments.

It really wasn't the order I was expecting, it's a little messy but at least it works.

I only added tuning for $20 and $40, as a test, both require 1.79mhz, but other than that it behaves as expected.

Replacing the distortions in the first line also works exactly as expected, I left it unchanged for now.
 

I used the notes from synthpopalooza's tables spreadsheet to get the Distortion 2 and 4 notes for this test.
 

Distortion and Tables Test.obx CustomNoteTables Vin V1.txt Distortion and Tables Test.rmt

[Trying to make some PoKEY music!]

4 hours ago, rensoup said:

The sap file always contains the tune in its original format as well as the corresponding 6502 player, I added that option specifically to rip all the RMT tunes out of their sap format, you can point to whole asma sap archive and it will extract RMT tunes from those that contain one.

I know, this is why I used RMT2LZSS to extract his tune, and be able to run it in Altirra as well  
It's awesome how it just works, I've used the same method to rip .rmt modules out of executables too, lol
 

1 hour ago, emkay said:

If you only show one channel, you don't see the resulting modulation.

But yes, we will see it if it's actually properly emulated/exported? 🤨
That's literally what I explained in my previous message in the thread.

"Adding up 2 audio channels and show as 1 due to a rendering error vs show the resulting tone properly in each channel" are 2 entirely different things.
The high pass filter modulation is the most obvious in that regard, Pulse width modulation is shown in action instead of showing up 2 channels doing 2 totally different things.
The video of Things on a Spring was inaccurately emulated, and actually looked wrong as soon as a note switched down to 16-bit, it made everything following up wrong and copying what the other channels did, visually.

Here's an example of inaccurate high pass filter effect visualised in separate channels based on what I explained:
 

It looks like a normal square wave, because when it was exported, all channels are literally disabled, and so anything such as frequencies and AUDCTL bits are omitted, so listening to individual channels will expose everything wrong

Here's an example of 16-bit turning the entire visual in channels 2 of each POKEY side wrong in a few parts:  
 

    
The latter, this video, was exactly the same side effect that happened in the visualisation of Things on a Spring, due to the fact that disabling a channel entire really mess up everything depending on the other channels.
The best way to counter that is to simply set volume 0 on the channels that should be muted, but allow it to keep doing its thing, which was what I used for my own oscilloscope videos. 😜 

 

[Moving beyond RMT ?]

3 hours ago, rensoup said:

yes, the new RMT2LZSS should address that.

I knew the tuning work wasn't a waste of time after all!
Gonna be really useful just for that alone.
 

3 hours ago, rensoup said:

I'm not sure what all the frequencies mean... Every time I see 15khz mentioned, I know its the duration of a scanline but how does that relate to Pokey ? same with 64khz and 1.79mhz (yes I know it's the CPU frequency but again what does that have to do with sound ?)

15khz and 1.79mhz corresponds to the POKEY frequency divider clock, so each modes provide different pitches, and as a result, different tuning.
15khz is much lower, and 1.79mhz is much higher.
Something that works for 64khz (the normal mode) may not work for one another, and vice versa. 
We are lucky to get relatively good consistency with 15khz in the Distortion A, being about 2 octaves (and a bit) lower, because between distortions, modes and other AUDCTL settings (Joined 1+2/2+4, High Pass Filter, Poly9, combinations of several, etc) may not be as nice in that regard.
So essentially, a table for nearly every possible combination may be required, it really depends on a lot of things.
 

3 hours ago, rensoup said:

That I could actually do... 

 

If AUCDTL has linked channels and AUDCTL is 64khz -> use 16bit table A

If AUCDTL has linked channels and AUDCTL is 1.79MHZ -> use 16bit table B

 

?

That could work incredibly well regarding what I just posted above  
 

 

3 hours ago, rensoup said:

?

On 3/9/2021 at 10:46 PM, emkay said:

While all 8 bit  (and 16 Bit) instruments only need a fix note table, the PWM needs an editable note table.

 

?

I think what emkay means is regarding high pass filter, there is way, way more than "SID-like" sounds that could be done, and so I agree about it, 1 channel being a certain table, as a "Carrier", and the other using a different one, as a "Modulator" could make a LOT of things really easy to do.
High pass filter combinations and possible notes is something I have been experimenting a lot with recently, and I plan to properly document one of these days in the future, I can say for sure, there is a LOT of things possible with that alone.
So the "fixed" and "editable" statement is regarding the possibility of being able to have custom settings (something I believe was already mentioned in this thread anyway).
I think it is regarding how certain modulations require manual instrument envelopes, something that can be done for the most part already, and also have the ability to have specific tables loaded in memory for specific things, for example, 7 semitones apart the 2 channels create some distortion guitar tones at 1 octave lower, and the highest possible frequencies produce something much closer to actual high pass filtering... even I get lost trying to explain any of this, but I believe I understand the reasoning.

Could be summarised to: "Power to the user, allow them to have anything editable, and let them make their own tables for their own instrument design!"
At least, I hope I understand correctly, lol   
 

3 hours ago, rensoup said:

On 3/9/2021 at 10:46 PM, emkay said:

One of the real missing features in RMT is the possibility to adjust the resulting pitch on a single channel, when all channels were playing. 
It solves the tuning for particular single steps. 
This will help to remove cancelling or "clamped detuning" .

You mentioned that already... no idea what you mean... you'd to find a different way to explain it

Seems like something such as effect commands in tracker patterns could handle incredibly well.
For example, Famitracker uses the command Pxx (xx being the value of fine tune up or down) for that exact purpose, making all the fine tuning a simple command instead of several instruments edited for that purpose, even if they are used only once.

Honestly, effect commands alone could add a LOT of possibilities without requiring to bloat the instrument editor with hacked up instrument design to get shit working at all (and this is where I sit currently with my RMT usage LOL)



 

 

1 hour ago, emkay said:

 

Every "Mod" Tracker has this feature.

 

In RMT it is for now:

c-4 01 f 06

 

c-4 is the note

01 is the instrument

f is the "global" volume

06 is the speed

 

Well. There are additional features on any tracker to allow the Arpeggio setting on the patterns aswell.

 

So it might be

 

c-4 01 f ff 038 06

 

 

now the command row has 

ff to pitch the dedicated channel one up (command 00 might reset it +-12 values might be enough )

-It is useful, if at a dedicated time, the channels might cancel each other , or the volume adds by the resulting wave.

-it also can help to optimize filter sweeps, instead of generating several different instruments.  

 

038 is just an example for some arpeggio implementation.

This post pretty much says what I meant in the reply above, that is also something most tracker programs usually support by design. Some even support several commands at once, Famitracker, Deflemask, LSDJ to name a few.

[Moving beyond RMT ?]

3 hours ago, rensoup said:

Well I was hoping for something that showed clear differences between the settings but I guess that's not absolutely required and I can remain blissfully ignorant 😀

Ohh right, I understand now!
That should be pretty easy to do, a short demo using as many combinations as possible, of course, I'm dumb lol
 

2 hours ago, rensoup said:

Well you have 8 now so go on, impress us again 😀

That alone could make a lot of things faster for the statement above! haha 
Thank you very much for implementing the idea, it might not be the ideal solution, but a patient musician won't have problems exporting files often to hear their sounds as the song progresses.

 

3 hours ago, rensoup said:

But if distortion is part of the envelope, it should already be the case ?

 

Better instrument support doesn't seem very difficult it's just that there's no editor for it... It may be possible to have a very simplistic external instrument editor (which would be totally incompatible with RMT though).

 

Or perhaps have extra parameters coded in the instrument names ????

Yes, Distortion is pretty much already doing it, and with the new RMT2LZSS features that would turn this into something a lot better as well.
AUDCTL changes in the instrument envelope would be the only thing missing now.

Having extra parameters would be exactly what we need to improve a lot of things, but then it will make most things incompatible with RMT as a result.
So a format based on RMT, but improved in a potential new editor could turn a lot of annoying things into something relatively easy for the musician.

Even better, if a future format actually sees the light of existence, and was based on the RMT format, that could also make features such as "import RMT" something nearly painless to implement, only what was not supported would be missing since it wasn't used in the first place.



 

[RMT2LZSS: convert RMT tunes to LZSS for fast playback!]

Awesome! 
Let's see how I could make use of this new feature soon 👀

[Trying to make some PoKEY music!]

I had a lucky guess... for some reason Altirra refused to run your SAP files from the ASMA archive, but there was actually a RMT header inside, so I was able to convert it with RMT2LZSS to see it in action.
I was correct, there was inaccurate emulation, there are some notes that switched to 16 bit mode, and it looks like ASAP doesn't like it, because now all channels looked correct in Altirra.

Just for fun it uses my Alternate Tuning too... Sounds pretty good to me!

Thing_on_a_Spring.xex

[Trying to make some PoKEY music!]

57 minutes ago, emkay said:

The only bad part there is that the resulting interaction of the different channels isn't easily to get. Particular if you only record one channel.

This is true, especially with inaccurate emulation, or changing the content of the channel, instead of the volume. Disabling a channel entirely creates a lot of weird effects with the ASAP sound emulation.
Altirra gets it right when it mutes channels to isolate the resulting waveforms, and the same also works with the RMT2LZSS volume offset changes, or manually editing a RMT to force the content of a channel to output volume 0 while keeping the frequency.
It also obviously works as expected on real hardware, very easy to see in the Amberstar cover, the Pulses are modulated exactly as expected.

 

1 hour ago, emkay said:

Bayusumardi did once a recording of my "Thing on a Spring" edit. On the 2nd channel he really recorded the interactivity  of two channels for the resulting wave. 

So you actually see why the waves get more voluminous.

This is simply wrong... That's not how it should look like. It's like 2 channels were mixed into 1, then output in a different channel.
That's inaccurate emulation for sure.

[Trying to make some PoKEY music!]

10 minutes ago, emkay said:

OK. How are you doing the visualisation?

 

Is it really necessary to record all channels separated and mux them, or is there a more comfortable way?

I pretty much record the tune in 5 passes, from 5 different executables, then assemble the oscilloscope video from them.

 

RMT2LZSS makes it incredibly easy since I can use the volume offset setting and mute channels by setting negative 15 on them, so I make 4 different files using that method, 1 per audio channel, then record the full version as well as the master audio file.

 

Then i record the sound from my Atari, and assemble the files using Audacity to splice and amplify the sound, and make everything synced up for the visual part.

 

It's slow but incredibly satisfying to get authentic hardware recording in action

 

 

[Trying to make some PoKEY music!]

15 minutes ago, emkay said:

lol ... the forum has some probs

 

It always happens in this thread for some reason, lol

I hope I didn't break the site

[Trying to make some PoKEY music!]

15 minutes ago, emkay said:

lol ... the forum has some probs

 

It always happens in this thread for some reason, lol

I hope I didn't break the site

[Trying to make some PoKEY music!]

1 hour ago, emkay said:

dllz.obx 11.04 kB · 2 downloads

Recorded from my PAL 800xl
Sounds great  

 

[Trying to make some PoKEY music!]

1 hour ago, emkay said:

dllz.obx 11.04 kB · 2 downloads

Recorded from my PAL 800xl
Sounds great  

 

[Trying to make some PoKEY music!]

5 hours ago, emkay said:

@VinsCool

Would you like to do a recording of my latest 15kHz edit, for some comparision? 

Sure, I'll just need executable for that.

[Trying to make some PoKEY music!]

Oscilloscope video is up now!
 

Amberstar - Ode to Schnism (Atari PoKEY Cover, Recorded from Real Hardware, Alternate Tuning)

[Trying to make some PoKEY music!]

43 minutes ago, Schnurrikowski said:

You are a genius Thanks for that really nice tune! 

 

But will this work with Rings of Medusa title theme, too?

 

 

Thank you!
Nice tune, I don't see why it couldn't work, seems very much in the range of POKEY capability to sound nice.

Speaking of which, while the oscilloscope video is rendering, here's the real hardware recording of the Amberstar tune!
I recorded it from my PAL 800xl

Might just upload the video tomorrow, it's pretty late already lol

 

 

 

[Moving beyond RMT ?]

Yep, I agree with that

 

Raster really did a good job, it's just a bit disappointing how limiting some things were implemented, because the POKEY chip can produce some really amazing sounds.

 

Not lying here, when I did not understand the chip as much I can today, I thought many things were much more limited due to the way RMT was handling them.

I assumed high pass filter muted the modulator channel, same with 16-bit, or that the notes available were the only ones possible (and I think I was able to prove there was way more possibilities using custom tuning tables!).

So once I could actually know the secrets of the chip, I was pretty much facing a wall of hard coded limitations, that could be worked around manually using AUDCTL settings in instruments and manually playing the frequencies needed using commands 1 and 2, for example, or relying on Speed 1 patterns (Famitracker style!), Or custom tables, as shown by Analmux in RMT patch8, or even my own for tuning purposes, which was only intended as a personal use first but now I think there may be more stuff that could benefit from that, etc

 

having a new tracker which handle do everything RMT could do, but better, with LZSS, means we could do nearly anything, and hopefully having more control over the sounds would make certain things much easier as well, despite being a lot more complex on the get go.

 

note tables for example, are not an exaggeration for that alone, having support for more than 3 hardcoded tables would unlock a lot more power without relying on manually making instruments for 1 specific frequency, and would also avoid having to resort on using hacked versions as well.

 

so if instruments could also change more things on the fly, such as distortion, or AUDCTL alone, plus having support for custom tables, would mean quite a lot of things could be done, and once the hard work is done once for a certain thing (eg, a table of notes for a special setting), that makes things much easier to do once they are available.

 

POKEY Explorer has been incredibly useful for these experiments, so having a tracker that could let the user do nearly the same amount of stuff on the fly to make an instrument could make a huge step forward in creating really impossible sounding POKEY music, I believe

 

 

 

[Moving beyond RMT ?]

34 minutes ago, emkay said:

It's not AUDCTL only that needs different note tables , it'

For now RMT has a separated Note table for the AUDC(0-3) registers.

RMT currently only has 3 tables, and 1 16-bit table.
The 3 main tables are Pure tone, used for 0, 2, 4, 8 and A (which is very much incorrect, since they all need their own tuning to even work nicely), and 2 bass tables, these 2 are only used for Distortion C and "E" setting (E in reality is simply C with different tones on certain frequencies), Bass Table 1 is also used in "Distortion 6", the 16-bit bass setting, as a fallback when used on a unsupported channel.

16-bit is made of 1 high order byte table, and 1 low order byte table, one in each channel used for it. The tone is very much what "Distortion E" sounds like, but in reality way more 16-bit settings could be done, and they also need their own tables.
 

41 minutes ago, emkay said:

If now clocking 1.79MHz is used, the generators need ofcourse a new table. 

Particular gen. 2,4, and C

More than that, actually, 15khz, high pass filter modulation (not just SID-like sound, but many combinations!), and different combinations of several settings, AUDCTL bits, and most likely more, they really do need their own tables to get some very solid tones and notes being in-tune together.

 

44 minutes ago, emkay said:

And, well, VinsCool's latest edit shows that 8 bit resolution using the Pulse width feature plus some better pitch alignment(custom note table), reaches even a better resulting tone.

Which comes to my definition of "32 Bit" sound. 

The both "filter" channels do act together in a 16 Bit way. And there is the timing that allows to handle different types of waveforms and combination of ALSO 16 Bit. 

It's not a 32 Bit as such. 

I like to call all that high pass filter stuff "cheap FM" for the same reason, lol

 

45 minutes ago, emkay said:

It's like a square , where you can chose any position from x and y in combination. 

This means, the interactivity while POKEY plays music, allows to handle 8 bit sounds like 16 bit sounds. And it is possible to set any resulting wave form to it. 

But it is not all usable together.

And here comes a special Note Table into gameplay ;).

While all 8 bit  (and 16 Bit) instruments only need a fix note table, the PWM needs an editable note table.

One of the real missing features in RMT is the possibility to adjust the resulting pitch on a single channel, when all channels were playing. 
It solves the tuning for particular single steps. 
This will help to remove cancelling or "clamped detuning" .

And you lost me here, lol

[Trying to make some PoKEY music!]

Hardware recording coming a bit later
I really like how this cover turned into now.

Amberstar - Ode to Schnism Alternate Tuning Final.rmt Amberstar - Ode to Schnism Alternate Tuning Final.xex