Altirra emulation core for RMT

[phaeron]

Experiment of the day: Altirra's co6502 and POKEY emulation cores adapted for RASTER Music Tracker 1.28.

 

altirra-rmt.zip

 

People had been asking about this, so I decided to try it out. There are two modes of usage:

 

• You can use one of the DLLs without the other. There's probably no point in using sa_c6502.dll by itself, as the default one is perfectly fine at emulating the RMT player. Using sa_pokey.dll will give you only the Altirra POKEY emulation core, with register writes aligned to RMT ticks. You need to rename or remove apokeysnd.dll for this as RMT will prefer it to sa_pokey.dll.
• If you use both of them together, they will notice each other and the 6502 core will talk directly to the POKEY core, bypassing RMT's POKEY register handling. This gives cycle-precise write timing as well as access to other POKEY registers not normally mirrored by RMT (particularly SKCTL). There are still no interrupts or any other hardware.

 

Note that this is based on the Altirra 4.00-test core, so these DLLs will not work on Windows XP.

 

There are some gotchas due to quirks in the RMT DLL interfaces. RMT's sa_pokey.dll interface only allows 44.1KHz/8-bit sound output, so this sa_pokey.dll bypasses RMT's output and runs its own 48KHz/16-bit output. Somewhat more janky is that RMT is always running both the 6502 player and POKEY in stereo mode, but for a mono file it mirrors the $D200-D208 to $D210-D218 in between sa_c6502.dll and sa_pokey.dll. Thus, in linked mode, sa_pokey.dll has to detect whether RMT is running in mono or stereo mode and dynamically switch the second POKEY on and off. You may hear it take a moment to switch when changing songs with different modes. Finally, RMT seems to always init sa_pokey.dll with NTSC parameters, so pitches will be relative to NTSC clock. Song tempo will still be correct, however, as this is determined by how often RMT runs the player and requests samples.

 

To be honest, I don't know if I'll continue maintaining these DLLs, as this was an experiment and I had to do some really hacky things to work with RMT (like doing a cross-call to msvcrt.dll's atexit() to cleanup). I can't tell the difference from the ASAP core (apokeysnd.dll), though I'm no musician. But, I did get some code cleanup done and figured there might be some community interest.

 

[VinsCool]

Oh my god this came out of nowhere, just as I left my computer!

 

Thanks a lot, I will give it a try tomorrow

[EnderDude]

A dream come true!

@emkay the emulation wobbling days are over!

[ivop]

7 hours ago, VinsCool said:

Oh my god this came out of nowhere, just as I left my computer!

Secretly, I was hoping for this, as I saw Phaeron hanging around the RMT hacking thread and other Vinscool threads

 

1 hour ago, EnderDude said:

A dream come true!

@emkay the emulation wobbling days are over!

Definitely!

 

7 hours ago, phaeron said:

There are some gotchas due to quirks in the RMT DLL interfaces. RMT's sa_pokey.dll interface only allows 44.1KHz/8-bit sound output, so this sa_pokey.dll bypasses RMT's output and runs its own 48KHz/16-bit output.

Great! And it also fixes the timing problems between RMT and sa_pokey.dll.

 

Quote

Finally, RMT seems to always init sa_pokey.dll with NTSC parameters, so pitches will be relative to NTSC clock. Song tempo will still be correct, however, as this is determined by how often RMT runs the player and requests samples.

Yes, that is bug in RMT, but I have a patched version that sets the PAL parameters. https://atariage.com/forums/topic/291495-trying-to-make-some-pokey-music/?do=findComment&comment=4884698

 

Edited September 26, 2021 by ivop

[emkay]

Well, that's an early chistmas present. 

[ivop]

32 minutes ago, emkay said:

Well, that's an early chistmas present. 

Certainly. I have thrown a lot of .rmt files at it, and it's great! The whole timing mess of RMT calling Process() is eliminated, because RMT's audio pipeline isn't used.

 

You only need two Rmt.exe binaries. One with the NTSC resampling clockrate, and one with the PAL one. It is possible though to determine whether we are in NTSC or PAL land, by checking the frequency at which the 6502 player is called. I have done so in my "poking at Rmt.exe as a black box DLLs". Perhaps Phaeron can just ignore that parameter, and adjust it on the fly. Might take one or two frames to catch up, similar to his mono/stereo switching, but that's not a problem.

 

Edited September 26, 2021 by ivop

[emkay]

1 minute ago, ivop said:

Certainly. I have thrown a lot of .rmt files at it, and it's great! The whole timing mess of RMT calling Process() is eliminated, because RMT's audio pipeline isn't used.

 

You only need two Rmt.exe binaries. One with the NTSC resampling clockrate, and one with the PAL one. It is possible though to determine whether we are in NTSC or PAL land, by checking the frequency at which the 6502 player is called. I have done so in my "poking at Rmt.exe as a black box DLLs". Perhaps Phaeron can just ignore that parameter, and adjust it on the fly. Might take one or two frames to catch up, similar to his mono/stereo switching, but that's not a problem.

 

I'm using the gen 2 patch RMT, it's the most convincing version for me reight now. 

Your clue about reprogramming the RMT doesn't work there. How did you find the right position there to edit the base frequency?

[emkay]

Here a current test: 

 

[ivop]

3 minutes ago, emkay said:

Your clue about reprogramming the RMT doesn't work there. How did you find the right position there to edit the base frequency?

With hexedit on Linux Just search for the NTSC 32-bit clockrate value, and replace with the PAL clockrate. But I suppose you use an RMT 1.30 patch. I'm fairly sure that one can be patched in a similar way.

 

But better would be if phaeron detected it inside his library, which is possible, so we only need one binary.

[ivop]

Patching RMT 1.28 from NTSC resampling to PAL resampling:

 

00026840   44 00 55 68  44 AC 00 00  68 5E 4F 1B  00 FF 15 9C

 

00026840   44 00 55 68  44 AC 00 00  68 87 0F 1B  00 FF 15 9C

 

 

Patching RMT 1.30 from NTSC resampling to PAL resampling:

 

0002B3F0   5E 4F 1B 00  FF 15 38 6A  45 00 83 C4  34 C7 45 C0

 

0002B3F0   87 0F 1B 00  FF 15 38 6A  45 00 83 C4  34 C7 45 C0

 

Edited September 26, 2021 by ivop

[EnderDude]

So I'm trying to use it with some of the other patches, like patch 16 betas 6 & 7, and it seems that since the binaries were stripped from the main .exe, at least for now, they don't seem to work. Nothing's being written to any of the registers; all zeroes. At least that's what I believe is the reason why they don't want to work with the new 6502 and pokey .dlls.

Edited September 26, 2021 by EnderDude

[pps]

39 minutes ago, ivop said:

RMT 1.30

I have missed that somehow. Where to find this version? My latest is 1.28.

[EnderDude]

4 minutes ago, pps said:

I have missed that somehow. Where to find this version? My latest is 1.28.

It's a hack of 1.28 which lets you resize the window.
Here ya go:

rmt130.zip

Edited September 26, 2021 by EnderDude

[VinsCool]

15 minutes ago, EnderDude said:

So I'm trying to use it with some of the other patches, like patch 16 beta 6 & 7, and it seems that since the binaries were stripped from the main .exe, at least for now, they don't seem to work. Nothing's being written to any of the registers; all zeroes. At least that's what I believe is the reason why it doesn't want to work with the new 6502 and pokey .dlls.

This is because they made use of ivop sa_c6502.dll plugin, which includes a binary loader for the tracker part, something that doesn't exist in the Altirra based plugins.

I wonder if they could be merged at some point, otherwise you'd have to use the other sa_c6502.dll but keep the Altirra sa_pokey.dll, i imagine that would work pretty well, i have not tested anything yet, but this is very exciting!

[EnderDude]

Also, I just noticed something:
Since the Altirra pokey plugin is adjusted to play at 16-bit 48khz, if your computer's sound output is set to 16-bit 44.1 khz, the Altirra pokey emulation will still play, but the pitch will be multiplied by 44.1/48. Be sure to set your sound system to 48khz for proper playback if you can!
Unfortunately, my bluetooth headphones only go up to 44.1khz, so I might need to change the sample rate of the .dll to get a 44.1khz version
 

Edited September 26, 2021 by EnderDude

[emkay]

36 minutes ago, pps said:

I have missed that somehow. Where to find this version? My latest is 1.28.

Good to see you here in the thread

 

As for the next time, I'll use the Gen 2 Patch RMT, it would be great to have a runtime, that is working with your "Intro Package". 

As now it is possible, to create some "real stuff" , nice tunes might follow which need a small intro 

[pseudografx]

42 minutes ago, EnderDude said:

It's a hack of 1.28 which lets you resize the window.
Here ya go:

rmt130.zip 146.35 kB · 1 download

It's actually not a hack but a new version compiled from the original sources with new code.

[EnderDude]

One quick mod of the sample rate from 48000 to 44100 hz in sa_pokey.dll...

from this:

 

00002260     1C 00 00 00   00 C7 46 20   00 00 00 00   C7 46 24 80  

00002270     BB

 

to this:

 

00002260     1C 00 00 00   00 C7 46 20   00 00 00 00   C7 46 24 44 

00002270     AC

 

Works like a charm for my 44.1khz bluetooth headphones now!

Edited September 26, 2021 by EnderDude

[VinsCool]

15 minutes ago, pseudografx said:

It's actually not a hack but a new version compiled from the original sources with new code.

Man some people have the holy grail while some others are going mad with hacking from the inside don't they ? 

13 minutes ago, EnderDude said:

One quick mod of the sample rate from 48000 to 44100 hz in sa_pokey.dll...

from this:

Thanks a bunch, might help my side as well, also stuck to 44100hz output.

Not gonna lie the change in pitch was pretty amusing to hear in your example hahaha

[emkay]

Really stunning to get in RMT what you hear even outside

 

 

 

[VinsCool]

Sounds great, nice and crisp sounds.

If it were on the right key that would be even better

[emkay]

5 minutes ago, VinsCool said:

Sounds great, nice and crisp sounds.

If it were on the right key that would be even better

It's correct in key for the sentimental touch it has

[VinsCool]

I noticed an interesting oddity with the Altirra 6502 and POKEY plugins combination.

Muting individual channels seems to be ignored, not a big deal but it's worth pointing out.

 

Using the other sa_c6502.dll (here, Ivop's .obx loader version for my own patch) seems to work fine however.

Maybe not cycle exact in that context, but fully functional and still better for the sound quality, so this is really awesome

 

 

[VinsCool]

Man, I'm loving this so much.

I've been working on a new tune since a few days ago, only revisiting it again today in the tracker after a small pause re-creating the original .xex export player, and I'm having a great time playing with sounds.

 

I'm not yet using the full cycle accurate combo for technical reasons right now, but wow, I can tell this still really makes a huge difference over the apokeysnd.dll plugin I was using for a long time.

The sound improvement is pretty damn good!

I'm finally getting Altirra sound quality without the necessity to export binaries every 10 minutes, unless I absolutely need a 100% precise timing.

And that is really not a bad thing considering I'm using 1- mixed plugins 2- my own RMT player code, and yet everything works perfectly as far as I could tell  

 

Is there any chance to see the full source code of these plugins in the future? 

I could already imagine how combining ivop's .obx loader to the new 6502 emulation plugin would be a big hit in term of quality and accuracy  

[phaeron]

  altirra-rmt-1.01.zip

 

• 44.1KHz issue fixed, resampling factor needed to be recomputed.
• POKEY plugin now switches to PAL master clock if PAL-ish freq17 is detected.
• Added muting detection in linked mode. This is another case of RMT mucking with POKEY registers between the two plugins, which is bypassed by the link. Now it double-checks the registers received from RMT and toggles the channel enables. A bonus is that this means that in linked mode, muting channels in RMT doesn't affect the POKEY channel state.

Tracker loading should be doable but I'm not familiar with how that works, so I'd have to brush up on that.

 

5 hours ago, ivop said:

Certainly. I have thrown a lot of .rmt files at it, and it's great! The whole timing mess of RMT calling Process() is eliminated, because RMT's audio pipeline isn't used.

 

You only need two Rmt.exe binaries. One with the NTSC resampling clockrate, and one with the PAL one. It is possible though to determine whether we are in NTSC or PAL land, by checking the frequency at which the 6502 player is called. I have done so in my "poking at Rmt.exe as a black box DLLs". Perhaps Phaeron can just ignore that parameter, and adjust it on the fly. Might take one or two frames to catch up, similar to his mono/stereo switching, but that's not a problem.

My sa_pokey.dll does actually use Process(), because I couldn't make sense of the maxcycles values getting posted to C6502_JSR(). The only thing that worked in the end was taking the number of samples requested by Process() and turning that into cycle counts to advance the POKEY emulator.

 

14 minutes ago, VinsCool said:

Is there any chance to see the full source code of these plugins in the future? 

 

I could already imagine how combining ivop's .obx loader to the new 6502 emulation plugin would be a big hit in term of quality and accuracy  

 

Yes, eventually, it'll be a sub-build of the main Altirra source tree. I have to do some cleanups on the build setup and also formally relicense the code.