List All Known RMT Driver Patches?

[VinsCool]

Hi there,

I would like to know any bit of informations regarding the various RMT driver patches that were created over time.

By this request, I mean, literally everything known to have been created for specific situations.

 

The reason I am asking this mainly is for a thing that needed to be addressed for a very long time: compatibility.

I'm currently attempting to get such improvement done for my fork of RMT, and getting as many patches as possible will help unify everything for once and for all.

 

A few patches have been added already, so this is where I will start the list: 

Quote

RMT 1.28 Unpatched by Raster
RMT 1.25 Patch3 Instrumentarium by Analmux
RMT 1.27 Patch6 by Analmux
RMT 1.28 Patch8 by Analmux

RMT 1.28 Patch Prince of Persia by VinsCool
RMT 1.34 Patch16 by VinsCool

 

In order to make everything work the best, I will need your help, for finding files, and also the most accurate information, if available.

There are many more patches that were created as far as I know, but I most likely never heard about them, or I simply have no idea how they were used.

 

Please let me know if you have anything that could help me with this project, I will really appreciate!

As long as there is a patched .exe somewhere, or even better, 6502 ASM sources with relevant changes highlighted in the code, it will be possible to add into compatibility.

Having a bit of information about how a patch could be used will make things easier for later, but if it's unknown, it won't be a problem either.

 

Thanks in advance, and have a good day everyone!

- Vin

[miker]

Also my "0a" patch with exchanged 16-bit bass table using one of custom tables by @Synthpopalooza

 

Edit @makary and @R0ger have done some "their" versions as well.

 

IIRC Makary has done freq-some patches for 15kHz, and R0ger made pure-sound more "fitting" 8-bit "C" table.

Edited February 3, 2023 by miker
update

[miker]

There is also  1.27 Patch4 by Analmux, a bit similar to Patch3.

 

 

As attachmets there seem to be gone, here it is with some examples: 

 

rmt127p4.zip

[VinsCool]

Nice, this one also seems very easy to recreate even from description alone.

I see another thread also linked from it, but even just a simple .xex from a demo tune will be enough to recreate it too.

Honestly, as long as patches are tables changes and a few patches on instructions it's very easy to swap.

it's when patches like my own things break apart because all the memory addresses no longer align lol.

It took a literal reverse engineering of the RMT .exe to fit larger and relocated binaries, before luck struck me and let me do it very easily in the original source code.

Thankfully, this kind of hardcoded approach is also on its way out with what I have been planning for later.

[ivop]

Here's a zip-file that countains a player exported from patch2:

 

 

I'm sure there's all numbers, i.e. 1-8 Perhaps emkay still has them, but he seems to be banned from AA?

 

Edit: the question is, do you need to support them all? Are there any files out in the wild that used them?

Edited February 4, 2023 by ivop

[VinsCool]

4 hours ago, ivop said:

Edit: the question is, do you need to support them all? Are there any files out in the wild that used them?

Do I need to? 

Well no, but if there is someone who absolutely want it, then, sure, why not.

And considering the current method I have got for using the patches is more or less functional, I see no reason why some of them could be omitted this time.

 

My reason is mainly for a final stretch before I break everything as soon as I get everything to work, because I plan to make a new git branch later which will essentially remove the entire procedure of using 6502 instrument routines inside the tracker.

So the idea right now is to fetch as many patches as possible to be able to import every possible modules that may have used them, for compatibility's sake.

Then once this is all in place and working, we could easily switch between the desired patch in the tracker while editing a module.

And at a later time depending how much work is left, add all of this stuff to the export of relocatable RMT assembly for all the patches and the edited lookup tables, then make a new release for everyone and hope that will do it for repairing the mess I created and made everyone upset.

 

In short, secure myself for branching to an entirely different setup, and not worry anymore about broken compatibility.

Forcing everyone to use LZSS caused more harm than good, and I don't want to repeat the same mistake this time.

More patches, the better.