Building Altirra Emulator and RMT Plugins?

[VinsCool]

Hey guys, I wonder if anyone could help me a little, and I did not want to flood the Altirra thread, so I started a new one here.

 

I'm in the middle of testing some things with the RMT code that are intended for timing improvements, and as such I would need to be able to build the plugins to see if all the values I pass through are correct.

Any help for building would be appreciated, because at the moment the instructions require me to install multiple things and I couldn't understand most of it, and it's a little annoying if I mess all my setup just to build 1 program, if you see what I mean.

 

I also don't actually need to build the entire solution, only the plugins themselves will do the trick  

Phaeron, or everyone else who is familiar with the emulator, if you can lead me in the right direction, I will appreciate it!

[phaeron]

The build instructions are in the BUILD-HOWTO.html file that is linked from the main .sln file. You haven't said what you have done or are running into problems with, but if you try to deviate from or skip required base toolchain components listed in that file you can expect some failures, even for the RMT plugins. Altirra 4.00/4.01 requires VS2019 and 4.10-test requires VS2022.

 

 

[VinsCool]

5 minutes ago, phaeron said:

The build instructions are in the BUILD-HOWTO.html file that is linked from the main .sln file.

Yeah, that was the thing I tried to follow, without much success unfortunately. 
Apparently I am too dumb set a PATH for some of the requirements ?

7 minutes ago, phaeron said:

You haven't said what you have done or are running into problems with, but if you try to deviate from or skip required base toolchain components listed in that file you can expect some failures, even for the RMT plugins. Altirra 4.00/4.01 requires VS2019 and 4.10-test requires VS2022.

So far, I have been trying to build with VS2019, but now I just realised I attempted to build something from Altirra 4.10-test... I hope that may have been what caused the errors like "no such file or directory" or "missing dependency", even if I could have sworn following the instructions, or having added things to PATH.

 

I have a VS2019 setup at the moment for building RMT, so I am a little conflicted to risk messing it up so I guess I will keep trying and build 4.00 for now, or make myself a new VM to install VS2022 later.

 

Thanks for the explanation, I knew I'm an idiot after all! haha  

[phaeron]

VS2022 can be installed side by side with VS2019. That's the configuration I have on my system. To precise, it's the VS2022 compiler toolchain that 4.10-test switched to (v143); you can try backing it down to the v142 toolchain in PlatformSetup.props but then you're on your own if there is something incompatible. The project/solution files themselves will open in VS2019.

 

The errors you're seeing are probably from missing YASM. You don't need to add it or the other tools to PATH, but you do need instead to set up a YASM.local.props file to point to it. MADS you can probably go without, the emulator won't build without it but the RMT plugins should.

 

[VinsCool]

34 minutes ago, phaeron said:

VS2022 can be installed side by side with VS2019. That's the configuration I have on my system. To precise, it's the VS2022 compiler toolchain that 4.10-test switched to (v143); you can try backing it down to the v142 toolchain in PlatformSetup.props but then you're on your own if there is something incompatible. The project/solution files themselves will open in VS2019.

 

The errors you're seeing are probably from missing YASM. You don't need to add it or the other tools to PATH, but you do need instead to set up a YASM.local.props file to point to it. MADS you can probably go without, the emulator won't build without it but the RMT plugins should.

 

Okay, thank you!

Yeah, that was pretty much what happened before, and yes YASM was causing me pain, until it finally worked but died somewhere else.

it looks like the compiler did not want to be v142, so now I know I simply did not do things properly.

 

Good to know I can actually install both side by side, I was worried that one would overwrite the other!

I might be able to figure it out now, thanks again sir.

 

---

While we are here, I would like to ask: what is the exact data specifically needed for the RMT plugins in order to work as good as possible?

 

So far I am pretty sure now I can send the proper MAXSCREENCYCLES and FREQ17 values, and hopefully could handle the entire MONO/STEREO setup differently as well.

As far as I could understand, it looks like the POKEY plugin specifically was hardcoded to ignore the FREQ17 value entirely, and use 1773447 regardless, that is actually the reason I wanted to build the plugin in the first place.

For the 6502 plugin, I did not seem to notice if it overwrote the MAXSCREENCYCLES value used during the 6502_JSR() calls, so I hope this part can be correct now.

[VinsCool]

Ok good news, I gave it a shot with Altirra 4.01-src and this time I was able to build the plugins  

YASM was also a pain, but I figured out what was wrong now.
I needed to use YASM-1.30-win32.exe specifically, otherwise it would fail.

 

Now that I can build the plugins, I can finally test the things I wanted to test, I cross my fingers  

[VinsCool]

I have been playing around with the code from both RMT and AltirraRMT and so far I think I have got some good progress done.

I am a bit unsure about how this could be shared, since I changed a few things in the AltirraRMT code, as well as RMT itself to get the results I wanted.

 

For now the following has been figured out:

 

- Stereo is detected properly by AltirraRMT POKEY

This is based on what data is sent from RMT to sa_pokey PROC in the first place, which is then detected by the Altirra plugin instantly.

That also means the timer used by the plugin to compare memory is no longer necessary as well.

The side effect of this is now the old sa_pokey and possibly apokeysnd plugins are most likely going to be broken, until they get the updates accommodating the changes I did in RMT's code.

I also removed the "duplicated" POKEY registers write entirely from RMT, so ONLY a STEREO setup will have the 2 sets of registers written to.

This is also detected automatically by RMT before writing to the POKEY registers, so if the number of channels read is not the same as the last known one, it will force a POKEY re-init command.

 

- FREQ_17 could be used directly by AltirraRMT POKEY

That means the machine tuning is finally the one that is expected between PAL and NTSC.

As far as I could tell, this was bypassed by forcing a value of 1773447, regardless of what RMT was sending.

 

- 6502_JSR PROC could use the correct number of MAXSCREENCYCLES based on which region the machine is set in RMT

I don't know if there is anything else to do for this part?

As far as I could tell, things seem to behave correctly, since these values are changed between the machine region through RMT itself

 

- Tweaked the NTSC timing hack from RMT a little more

This has nothing to do with the AltirraRMT plugins, but this seems to help stabilise the timing for the NTSC region when the sound rendered.

 

- Tweaked the sound buffer code from RMT with appropriate parameters between regions

This does seem to help reduce, even get rid of the lag/stutter when the sound is buffered then played.

As far as I could tell, this seems better that way now.

 

- Changed the AltirraRMT POKEY volume from 0.5f to 1.0f

This one is just a personal preference. 

I always found RMT to be quiet with the plugin, and this pretty much boosted the levels to a more comfortable one, so mixing the sounds in RMT would not be awkward due to the volume levels mismatch between Altirra emulator and RMT making using the Altirra plugins.