Altirra emulation core for RMT

[ivop]

5 hours ago, VinsCool said:

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

That would work, but you'd miss the cycle exact emulation when phaeron's sa_c6502.dll and sa_pokey.dll work together. Better would be if phaeron replicates my tracker.obx loader:

 

https://github.com/ivop/rmt-sa-libs/blob/main/real/sa_c6502_inject/cpu.c

 

Code injection starts at line 245 (everything related is under ifdef INJECT_TRACKER_OBX).

 

TL;DR If the player's 6502 code starts with "TRACKER ", it loads an xex file that overwrites that memory, and possibly more for tables and extra code.

 

Edited September 26, 2021 by ivop

[ivop]

47 minutes ago, phaeron said:

POKEY plugin now switches to PAL master clock if PAL-ish freq17 is detected.

FTW 

[VinsCool]

1 hour ago, phaeron said:

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.

 

Awesome! Thanks a ton for this!

[VinsCool]

38 minutes ago, ivop said:

That would work, but you'd miss the cycle exact emulation when phaeron's sa_c6502.dll and sa_pokey.dll work together. Better would be if phaeron replicates my tracker.obx loader:

 

https://github.com/ivop/rmt-sa-libs/blob/main/real/sa_c6502_inject/cpu.c

 

Code injection starts at line 245 (everything related is under ifdef INJECT_TRACKER_OBX).

 

TL;DR If the player's 6502 code starts with "TRACKER ", it loads an xex file that overwrites that memory, and possibly more for tables and extra code.

 

I did test combining the Altirra POKEY and your 6502 plugin earlier, things worked perfectly good, even without the extra cycle accurate emulation  

[ilmenit]

On 9/26/2021 at 10:00 AM, phaeron said:

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.

 

Could you build also 64bit version of the DLLs? I was thinking of doing one project using the RMT audio libs but the UI framework (Avalonia, which is cross-platform version of WFP) that I wanted to use, does not have good 32bit support.

[emkay]

A bad and a good news.

 

The bad news: There is still some wobbling. 

The good news, it is not really disturbing the sound development, but can be irritating, if it happens. 

It appears mostly , if RMT runs in the background. 

So it must be some multitasking thingy. 

In Altirra it's still stable.

Edited September 28, 2021 by emkay

[ivop]

21 hours ago, emkay said:

The bad news: There is still some wobbling. 

Did you use the pair of DLL's Phaeron supplied, or did you use my code injection DLL with Vinscool's tracker.obx?

 

[VinsCool]

1 hour ago, ivop said:

Did you use the pair of DLL's Phaeron supplied, or did you use my code injection DLL with Vinscool's tracker.obx?

 

I've personally noticed wobbling mostly with the dll injection and the Altirra POKEY plugin, as expected.

It was more or less like before except the POKEY quality was crisper and better.

 

I got some audio crackling issues with the last version of the Altirra plugin for some reason, but I blame my WINE setup for that.

[ivop]

21 minutes ago, VinsCool said:

I've personally noticed wobbling mostly with the dll injection and the Altirra POKEY plugin, as expected.

It was more or less like before except the POKEY quality was crisper and better.

That was indeed to be expected. My understanding was that if you used phaeron's CPU emulation, the wobbling should be gone and it should be cycle exact to Altirra. The CPU emulation "talks" to the POKEY emulation. Now if only phaeron added an XEX loader to his CPU emulation...

 

Quote

I got some audio crackling issues with the last version of the Altirra plugin for some reason, but I blame my WINE setup for that.

Crackling can be because of several reasons:

 

1. RMT is still running its audio pipeline parallel to the new Altirra POKEY plugin's own audio pipeline. I assume that even though the Process() function is used to further the emulation, it returns a silent sound buffer?

 

2. Altirra DLL buffer size. A lot of times crackling occurs if the buffer that's been played underruns.

 

3. WINE buffer size in bridging win32 audio to alsa.

 

Edited September 29, 2021 by ivop

[VinsCool]

2 minutes ago, ivop said:

That was indeed to be expected. My understanding was that if you used phaeron's CPU emulation, the wobbling should be gone and it should be cycle exact to Altirra. The CPU emulation "talks" to the POKEY emulation. Now if only phaeron added an XEX loader to his CPU emulation...

 

Crackling can be because of several reasons:

 

1. RMT is still running its audio pipeline parallel to the new Altirra POKEY plugin's own audio pipeline. I assume that even though the Process() function is used to further the emulation, it returns a silent sound buffer.

 

2. Altirra DLL buffer size. A lot of times crackling occurs if the buffer that's been played underruns.

 

3. WINE buffer size in bridging win32 audio to alsa.

 

Yeah no idea really, it just sounded like a buffer underrun, but no option to change it makes it tricky.

At the end restarting the program fix it, and sometime it just randomly occurs.

Not the worst by any mean, just a little annoying when it happens.

I just know the first version was a little less prone to "crackle" during play.

[emkay]

2 hours ago, ivop said:

Did you use the pair of DLL's Phaeron supplied, or did you use my code injection DLL with Vinscool's tracker.obx?

 

I used the dll "package" . 

Which is the newest?

 

Btw. It's a real great thing already. 

For me it looks like the emulation is now really mono, and the timing isn't split into stereo channels, what gives the biggest benefit. 

[ivop]

11 minutes ago, emkay said:

I used the dll "package" . 

Which is the newest?

My question was not about the newest, but if you used phaeron's "package" or replaced the cpu DLL by my code injection version with Vinscool's tracker.obx.

But you answered the question. You used the full package

It's a pity it still crackles then. I assume you are on windows? Then perhaps Phaeron should increase a buffer size or two inside his code. So probably not Wine related for Vinscool and me.

 

Quote

Btw. It's a real great thing already. 

For me it looks like the emulation is now really mono, and the timing isn't split into stereo channels, what gives the biggest benefit. 

Oh yeah, that was a BIG fault in RMT, how mono was handled.

Edited September 29, 2021 by ivop
typoos and spelling

[emkay]

22 minutes ago, ivop said:

My question was not about the newest, but if you used phaeron's "package" or replaced the cpu DLL by my code injection version with Vinscool's tracker.obx.

But you answered the question. You used the full package

 

 

 

 

22 minutes ago, ivop said:

 

 

It's a pity it still crackles then. I assume you are on windows? Then perhaps Phaeron should increase a buffer size or two inside his code. So probably not Wine related for Vinscool and me.

It doesn't crackle here. 

 

[ivop]

2 minutes ago, emkay said:

It doesn't crackle here. 

Ah, I see. You said it still wobbled a tiny bit sometimes, not crackling.

 

The crackling is not constant though, like a badly tuned radio. It happens now and then. Like a hiccup. At least, that's what I experienced. Not sure about Vinscool. I'll look into WINE's buffering, even though I never needed to tweak that before.

[emkay]

Just now, ivop said:

Ah, I see. You said it still wobbled a tiny bit sometimes, not crackling.

 

The crackling is not constant though, like a badly tuned radio. It happens now and then. Like a hiccup. At least, that's what I experienced. Not sure about Vinscool. I'll look into WINE's buffering, even though I never needed to tweak that before.

Could be that some driver issue appears here. The crackling could be caused by the same problem than what appears here with some volume "wobbling". Possibly the interface between RMT and the new method of replaying the whole stuff?

Could be caused by the graphics device also. 

It mostly appears when RMT is running in the background. 

[ivop]

1 hour ago, VinsCool said:

Yeah no idea really, it just sounded like a buffer underrun, but no option to change it makes it tricky.

I've looked into WINE buffer sizes. Basically, there is no such thing, because WINE Is Not an Emulator. It's an API reimplementation. Buffer sizes are determined by the running application.

[EnderDude]

3 hours ago, VinsCool said:

I've personally noticed wobbling mostly with the dll injection and the Altirra POKEY plugin, as expected.

It was more or less like before except the POKEY quality was crisper and better.

 

I got some audio crackling issues with the last version of the Altirra plugin for some reason, but I blame my WINE setup for that.

That happens to me whenever I disconnect my headphones from my computer, setting it back to 48khz through my internal speakers, then reconnect them, setting it back to 44.1khz. After restarting rmt, it goes away.

[ivop]

Recently I set up a VM with Windows 10 and Visual Studio Community 2022 to do some work on a 64-bit build of RMT and hence I needed to recompile your DLLs. I stumbled upon a strange problem that also happens if I just do a win32/x86 build.

 

If I recompile the AltirraRMT solution, the right channel is silent for mono tracks. I tried 4.00 (with yasm and vcredist86 VC2010 for the missing msvcr100.dll), 4.01 and the latest 4.10. All present me with the same problem. If, on a working RMT setup with sa_pokey.dll that you compiled, I replace sa_pokey.dll with the newly compiled DLL, there's no sound on the right channel even though it was before the switch. @phaeron, do you have any idea what might be causing this? Something about my setup perhaps? All versions compile cleanly, without any errors or warnings. I have wasted several hours on this already, but perhaps you have an insight

 

Edit: attached non-working DLLs. Build with latest VS2022 and the latest build tools and SDK.

 

Edit2: also attached Debug x86 build.

 

not_working_dlls.zip

Debug.7z

Edited February 18, 2023 by ivop

[phaeron]

5 hours ago, ivop said:

If I recompile the AltirraRMT solution, the right channel is silent for mono tracks. I tried 4.00 (with yasm and vcredist86 VC2010 for the missing msvcr100.dll), 4.01 and the latest 4.10. All present me with the same problem. If, on a working RMT setup with sa_pokey.dll that you compiled, I replace sa_pokey.dll with the newly compiled DLL, there's no sound on the right channel even though it was before the switch. @phaeron, do you have any idea what might be causing this? Something about my setup perhaps? All versions compile cleanly, without any errors or warnings. I have wasted several hours on this already, but perhaps you have an insight

This sounds like an issue with stereo detection. Because the Altirra POKEY plugin does its own audio output, it doesn't know whether RMT is playing in mono or stereo mode, so it tries to detect by the POKEY register state. It sounds like RMT is sending non-zero values for the second POKEY for some reason. What version of RMT are you using? I'm not seeing this behavior with 1.30.

 

[ivop]

1 hour ago, phaeron said:

This sounds like an issue with stereo detection. Because the Altirra POKEY plugin does its own audio output, it doesn't know whether RMT is playing in mono or stereo mode, so it tries to detect by the POKEY register state. It sounds like RMT is sending non-zero values for the second POKEY for some reason. What version of RMT are you using? I'm not seeing this behavior with 1.30.

I'm using the latest 1.34 from VinsCool, located here:

 

https://github.com/VinsCool/RASTER-Music-Tracker

 

The Rmt.exe binary is in the RMT directory. It works correctly with the supplied AltirraRMT libraries, but not when I compile them myself with the latest VS 2022. Sending data to Process() is in XPokey.cpp, which is in the cpp_src directory. Looks like it initializes a single Pokey when in mono mode, unlike the original RMT.

 

My reasoning was that if nothing has changed in between, my compilation should work identical to his and yours, but strangely it isn't.

Edited February 18, 2023 by ivop

[phaeron]

Set a breakpoint on InitPokeys() in the plugin and see what path it is getting called from. If the C6502 and POKEY plugins are able to link, it will autoselect mono/stereo based on the shadow registers. If they aren't linked, then it will be relying on whether RMT tells it to init two POKEYs or not.

 

[ivop]

1 hour ago, phaeron said:

Set a breakpoint on InitPokeys() in the plugin and see what path it is getting called from. If the C6502 and POKEY plugins are able to link, it will autoselect mono/stereo based on the shadow registers. If they aren't linked, then it will be relying on whether RMT tells it to init two POKEYs or not.

Thanks.

 

In mono mode, it first gets called from RMT. MemToPokey() passes false as the boolean stereo variable. Slightly later, it gets called again, but as a side effect of Process().

 

Backtrace:

 

InitPokeys()                          // here stereo == true

OnScheduledEvent()              // the code here is within if(mbLinked) {}

ProcessNextEvent()

Advance()

Pokey_Process()

 

... which was called from RMT RenderSound1_50()

 

Had to type these over as I have not yet enabled clipboard sharing between guest and host in VirtualBox and I don't want to reboot the guest now I have debugging working with watches and all that

 

I noticed the @VinsCool supplied DLLs were compiled in December 2022, so I assume he compiled them himself. Perhaps he removed the stereo detection code from AltirraRMT?

 

Am I correct in deducing that C6502 and POKEY are linked? Going to try commenting out the memcmp() and wantStereo stuff to see what happens.

 

Edit: This worked marvelously! I have the feeling that I redid what VinsCool already did for his supplied DLLs. But I was impatient to wait for VinsCool's reply on my 3 days old pull request for the 64-bit build

 

Anyway, thanks @phaeron for pointing me in the right direction! And I improved my Visual Code skills a little in the process I have changed RMT to compile for 64-bit hosts and in combination with AltirraRMT compiled for 64-bit works like a charm now!

 

Edited February 19, 2023 by ivop

[VinsCool]

Hey there @ivop I apologise for the late response between Atari-Age and your Pull Request on Github, I have been busy with some things in real life, and I haven't even used my PC until a bit earlier tonight.

 

To answer the initial question, yes, I did supply an edited version of the Altirra plugins into the RMT repository, and the few changes done to them were a handful of workarounds really.

Things are currently made of hacked legacy sa_pokey code from RMT, edited Altirra plugins built to work around the outdated code, and a sprinkle of educated guesswork I most likely got incorrectly.

I am aware it's far from ideal, but since it worked mostly okay that way, I didn't worry too much about that for the time being.

This is something that must to be changed eventually, since there is just no point for keeping an outdated RMT plugins procedure in place, when there are better ways for getting everything functional.

 

I actually had a discussion about this situation with @phaeron a little while ago, but I chose to keep the current setup in stand by, because I was waiting for the final release of Altirra 4.10 at the time.

Other than that, I have not yet attempted anything to change the setup involved, because I don't know what would be the best direction to take, since I was not sure if anything I did so far was acceptable, on a license and permission point of view.

 

That said, it's a good thing you sorted the way RMT is built, I was not sure how to get it work in 64-bit, but I am very happy to know you figured it out already while I was not yet able to reply  

I noticed a few things were still missing from what was essentially assumed from my own changes, but this isn't a difficult fix, so don't worry about this part, it's not a lot to edit in practice.

 

 

Regarding the actual changes I made to the Altirra RMT plugins in order to get them work "better" with the outdated sa_pokey procedure, this is what I did on my side:

 

- Changed the way Stereo was detected from RMT, which forced a re-init to the plugins, added as a workaround to the outdated procedure, there is then a Boolean value passed to force it to initialise 1 or 2 POKEYs.

- Changed the way PAL/NTSC was detected from RMT, again as a workaround to the outdated procedure, the only difference was that I simply forced the plugin to use the FREQ17 values being passed, this should also be a Boolean to be honest...

- Changed the way Silenced channels were detected. The Altirra plugin used some sort of counter and comparison, similar to how the Mono/Stereo setup was detected, but this was no longer needed so I removed it since it causing more inconsistencies on the long run.

- Changed the volume level from 0.5f to 1.0f, to get the sound output virtually identical to what I can get from stand alone Altirra emulator with maximum volume level.

 

That's everything I can remember from memory...

I don't think I changed anything other than the credits text displayed on top of everything I mentioned above.

 

 

So yeah... things are a bit all over the place currently, I know how weird it is 😅

Hopefully, there will be a definitive solution for the RMT-Altirra combination, since I really do think this is by far the best Atari 8-bit emulation that could be used with the music tracker. 

 

To Phaeron: I apologise if I made the last PMs feel overwhelming to you with my 1000 questions regarding the use of Altirra emulation code with RMT, I really try my best to understand everything involved before changing anything critical, hahaha