RMT Hacking Ideas and Progress

[rensoup]

29 minutes ago, ivop said:

Emphasize mine again   What is an invalid AUDC0 combination? All 256 values are valid, unless we overload some of the volume-only combinations, right?

yes volume only and perhaps that noise bit ?

 

this is dmsc's code in the LZSS compressor

 

                  // Simplify patterns - rewrite silence as 0
                    if(tweakAUDC&&( (i & 1) == 1 ))
                    {
                        int vol  = val & 0x0F;
                        int dist = val & 0xF0;
                        if( vol == 0 )
                            val = 0;
                        else if(( dist & 0x10 )!=0)
                            val &= 0x1F;     // volume-only, ignore other bits
                        else if(( dist & 0x20 )!=0)
                            val &= 0xBF;     // no noise, ignore noise type bit
                    }
 

38 minutes ago, ivop said:

Creating such files could be done with atari800 (I'll add it to pokeyrec once we agree on the format), 

that'd be going backwards, it should come from the tracker directly at least... still clumsy though: no loop points for instance (could be added in the header though)

15 minutes ago, ivop said:

Glad we agree. As I said in the WebPokey thread, the SAP format is different from what RMT does. And what happens between RMT and RMT2LZSS stays in Vegas or something like that. If you can pack the tenth channel in one of the other nine in your LZSS stream, go for it!

It would be simple enough (just read the new channel and if the current value is different from the previous one override AUDC, right after the code posted above )... but right now there's no tune that uses it !

[rensoup]

49 minutes ago, VinsCool said:

If it works, why not? 

Most trackers do this, and that rarely was a problem, it only makes certain commands more difficult to memorise.

It's nasty practice ? 

 

It just creates multiple formats that are incompatible, the mod format is a good illustration of that: to load a mod properly, you can't just check a field, you must check all sorts of values in the headers and try to deduce which one it is...

 

58 minutes ago, VinsCool said:

There are many candidates for multiple usages, and that's why I was looking into earlier-- There's plenty of potential sitting in front of us right there  

HERESY ?

[ivop]

24 minutes ago, rensoup said:

yes volume only and perhaps that noise bit ?

 

this is dmsc's code in the LZSS compressor

 

                  // Simplify patterns - rewrite silence as 0
                    if(tweakAUDC&&( (i & 1) == 1 ))
                    {
                        int vol  = val & 0x0F;
                        int dist = val & 0xF0;
                        if( vol == 0 )
                            val = 0;
                        else if(( dist & 0x10 )!=0)
                            val &= 0x1F;     // volume-only, ignore other bits
                        else if(( dist & 0x20 )!=0)
                            val &= 0xBF;     // no noise, ignore noise type bit
                    }
 

Yes, here is exactly where you could use the volume-only values that are not $10-$1f to signal other things to the RMT2LZSS decoder and player.

 

24 minutes ago, rensoup said:

that'd be going backwards, it should come from the tracker directly at least... still clumsy though: no loop points for instance (could be added in the header though)

That's why I said:

Quote

and possibly a SAP writer inside sa_c6502.dll with the code injector. That would circumvent all the timing issues in RMT.

Luckily, RMT does call sa_c6502.dll properly timed. So we could write to a SAP-R or whatever file at the end of each call.

 

Still a bit clumsy, but perhaps we need a SAP-R editor to easily remove/add frames instead of using a hexeditor or dd. And indeed, if we create a new SAP type Q or R2, a header field could be added for loop points. That would be nice

[VinsCool]

13 minutes ago, rensoup said:

It's nasty practice ? 

 

It just creates multiple formats that are incompatible, the mod format is a good illustration of that: to load a mod properly, you can't just check a field, you must check all sorts of values in the headers and try to deduce which one it is...

Well, that's kind of the point, isn't it?

All tracker formats that were based on MOD eventually become their own thing when things could no longer be fully compatible.

 

If you were to try expanding a format in order to add new things, but then you find out all possible commands slots are used, what would you do?

I know of many tracker formats that used all letters of the alphabet, and all numbers, so they worked around it by combining several commands into fewer XY parameters.

That way, they did not need to create more values, and that was also fitting into the exact same number of slots already used.

All of which without breaking anything, since the new values were previously invalid parameters, so they were not going to exist in the first place.

 

Don't get me wrong, I agree with you, I prefer not to have commands full of multiple usages, but sometime, it's necessary, and if that design doesn't even penalise anything else, why not?

 

30 minutes ago, rensoup said:

HERESY ?

Are you taunting me? ? 

 

Joking aside, I already had something in mind, so unless it's failing miserably, I want to try things anyway.

 

Again, the words are: "why not?"

It kinda sucks there aren't more than 8 command slots, but to be honest, it was designed quite well, it blew my mind to find out how each Command Slot, Filter, and Portamento and Distortion were all making use of as many bits as possible inside of a byte.

 

When I realised why Filter was using Bit 7 for example, it suddenly made sense why, the workaround was simply because a negative number would always mean it is enabled.

[rensoup]

1 hour ago, ivop said:

That's why I said:

Quote

and possibly a SAP writer inside sa_c6502.dll with the code injector. That would circumvent all the timing issues in RMT.

Luckily, RMT does call sa_c6502.dll properly timed. So we could write to a SAP-R or whatever file at the end of each call.

indeed you said "possibly" so I stopped reading beyond that ?

[rensoup]

46 minutes ago, VinsCool said:

Well, that's kind of the point, isn't it?

All tracker formats that were based on MOD eventually become their own thing when things could no longer be fully compatible.

 

If you were to try expanding a format in order to add new things, but then you find out all possible commands slots are used, what would you do?

Yes because they were designed during the 20th century, because they had to run on the host machine hence had to make the best use of every bit! Nowadays tools shouldn't run on the target platform (which RMT still does in a hybrid form)

 

(Same reason you don't assemble your 6502 code directly on the Atari)

 

48 minutes ago, VinsCool said:

Don't get me wrong, I agree with you, I prefer not to have commands full of multiple usages, but sometime, it's necessary, and if that design doesn't even penalise anything else, why not?

Bloat! Raster designed RMT to strike a balance between features and CPU/RAM usage, as you've mentioned:

 

52 minutes ago, VinsCool said:

Again, the words are: "why not?"

It kinda sucks there aren't more than 8 command slots, but to be honest, it was designed quite well, it blew my mind to find out how each Command Slot, Filter, and Portamento and Distortion were all making use of as many bits as possible inside of a byte.

Exactly and with every new feature, CPU/RAM goes away... Is it important ? depends if you just want to play a tune on its own...

 

So it's all wrong but that's all there is for now and it's still great and exciting to hear these new sounds ?

[VinsCool]

I'm aware about the bloat.

 

What I want to do is to take full advantages of the machine for musical purposes, without feeling limited in what could be achieved, why else would I even bother otherwise?

My intention right now is to respect Raster's design as much as possible, but also allow more things at the same time.

All of the things I've tried to add or change into something I wanted to be able to use are intended to become optional, exactly the same as all the other features implemented in rmtplayr.a65.

 

Think about using a car, that has electronic components to limit the top speed and acceleration, even if you know it is capable of much more.

Wouldn't it feel frustrating to be limited by that limitation by design while you know how work around them?

That's precisely what I feel right now playing around with the tracker.

 

Programs like LSDJ, GoatTracker, Famitracker, etc etc are doing the opposite:

Allow as many things as you want specifically for the purpose of making music, think about optimisations later, OR start with a goal in mind and use minimal resources as early as possible in a project.

What feels the most frustrating? Being limited in what you can do when you KNOW it could be done? Or having all the "bloat" at your disposal, and cherry pick what you need and what you don't?

I don't know for most people, but I'm definitely part of Group 1 in that question.

21 minutes ago, rensoup said:

So it's all wrong but that's all there is for now and it's still great and exciting to hear these new sounds ?

My point is: could it be done? if a slight hint of yes is present, then I want to be able to do it.

What were the most requested features for RMT2LZSS?

Do you remember why they were even requested in the first place?

Do you also remember why it was frustrating to work with RMT and RMT2LZSS in parallel?

Do you remember who were the people involved and spent a lot of their own free time into it, because they really were interested by the entire project and its possibilities?

This is exactly what I am talking about.

 

It's frustrating to do things in the most uncomfortable setups, and I am too often upset about using some distortions in RMT, or even just 15khz mode, and be stuck with multiple things that sound wrong in the tracker itself.

Working around any issue either involved a 3rd party tool (RMT2LZSS) or to literally hack the tracker itself, all of this was why I've started to make all my own researches or even started learn how to code in the first place.

 

I will admit, I am a little upset right now, to be told what I am trying to do is either useless or wrong feels a bit insulting.

I care about what could be done, not what shouldn't be done because someone decided so.

 

There are plenty of demos around that showcase the most impressive graphics that hog all the CPU time, and sound is almost always an afterthought.

Most people just accepted that as the standard, but what exactly stops a person from doing intensive work for making music?

I'm all for a new tracker, and I would totally love to be the person who could make it happen, but unfortunately, this is not going to happen any time soon.

 

Is it really all wrong to instead turn to doing things I believe I have the ability to do instead?

[rensoup]

57 minutes ago, VinsCool said:

What I want to do is to take full advantages of the machine for musical purposes, without feeling limited in what could be achieved, why else would I even bother otherwise?

I understand that... the demo fan in me always thinks about music as part of a global show. Saying that music is an afterthought is a little extreme, every great demo is driven by music.

 

1 hour ago, VinsCool said:

Programs like LSDJ, GoatTracker, Famitracker, etc etc are doing the opposite:

Allow as many things as you want specifically for the purpose of making music, think about optimisations later,

I don't know LSDJ but from what I've seen GT is reasonable in its CPU usage (better than RMT 1.28 at least) and I'm going to guess so is FT but that could be due to the soundchips being slightly more modern and easier to set up. Generally all soundtrackers are written by coders with musical abilities ( more recognized for their coding than their music ) so they tend to be on the cautious side about resource usage.

 

1 hour ago, VinsCool said:

My point is: could it be done? if a slight hint of yes is present, then I want to be able to do it.

I'm not trying to prevent you from doing anything, but speaking from experience, I'm just thinking it may not be the best way... Hacking the tracker has that feeling of instant gratification which I totally understand but longer term it'll be harder/slower to update. Starting clean is certainly a lot more daunting but would pay off big time in the long run. 

I'm just saying it's not the right way (I'm sure of that but that shouldn't stop you) but it's never useless and the results have been super!

 

2 hours ago, VinsCool said:

I'm all for a new tracker, and I would totally love to be the person who could make it happen, but unfortunately, this is not going to happen any time soon.

If you've managed to pick up 6502 ASM, I think you could make it happen, maybe not just now, but sit on it for a while ?

[VinsCool]

Well anyway, here's a new test version  

Had taken things a too seriously earlier so I apologise for being a little upset.

 

Raster Music Tracker Patch 16 Beta7

 

Changelog:

- Removed a bunch of redundant or unused code now that it's confirmed to be unrelated to earlier issues. Saves a handful of bytes and CPU cycles.

- Added some disassembled code from the RMT executable as a workaround to some memory address jumps, this seems to fix most illogical problems that were caused by moving code to different places

- Updated sa_c6502.dll to its latest version, the changes above made the forced RTS write to $35FC unnecessary and likely to break other things anyway

- Experimental changes to Command 7 to turn it into an AUDCTL envelope, set bits using XY parameter, per instrument, (trackn_audctl,x), to still use Volume Only toggle, you must use $FF instead.

 

The Command 7 hack does work, but the same issues mentioned before remain: certain things won't be immediate, but be delayed by 1 frame due to the order of which instruments are processed in tracks.

Regardless of that frame lag, it is very usable as it is, so have fun experimenting with it! Just remember: immediate changes like 15khz and 1.79mhz will be delayed, and cause a few things to sound wrong during a frame.

Switching filter on the fly however isn't going to be a problem with this setup, and it works really well in my opinion. Toggling 16-bit also works but the same frame delay artifact exists, so be cautious.

A very easy work around for now is to simply mute the frame an AUDCTL change is toggled, or mask it in the mix with some other distortions, like white noise.

A better solution will require heavier changes in the rmtplayr code and it's not guaranteed I manage to do it yet without breaking everything.

 

Also I don't know if this is my brain tricking me or something, but I think my recent changes did affect the timing of a bunch of things.

I'm unsure if this is related to the earlier changes regarding the memory addresses that had something overlooked, or the cleanup of all the unused and redundant code affected things more than expected way.

That said, it's not different in a bad way, but anything that used PWM will... wobble differently than it used to? It's weird to explain, but things will sound different to me, while not sounding broken at the same time ?

More in-depth testing will be done later, so in the meantime, anyone who wants to play with the AUDCTL envelope, I'd love to hear things making use of it  

RMT Patch 16 Beta7.zip

[_The Doctor__]

Can you cheat by making the command 7 etc by insert one frame earlier on a person typing it in.... it will be in the right place for your eyes but the tracker puts it on the earlier frame internally? just to get by... it might not be a solution for your on the fly tinkering of a playing tune... but it would make it happen for a saved rmt or xex....

this of course is a hack until possible true fix / reorganization or some sort of 1 frame ahead buffering were implemented.. while the program is playing and your fiddling with values on the fly...

just ideas

[ivop]

18 hours ago, rensoup said:

indeed you said "possibly" so I stopped reading beyond that ?

Ah, like that If we agree on a new SAP type stream, I will definitely add a stream writer to sa_c6502.dll. It's very easy. I could probably even link in a (small) GUI library that creates a new window where you can press record and pause

[rensoup]

30 minutes ago, ivop said:

Ah, like that If we agree on a new SAP type stream, I will definitely add a stream writer to sa_c6502.dll. It's very easy. I could probably even link in a (small) GUI library that creates a new window where you can press record and pause

The thing is it would be only slightly better than recording in Altirra... in Altirra I start the recording, I just set a breakpoint on the end of tune check, run the xex then stop recording when the bp is hit...

 

Perhaps we should consider biting the bullet and start fresh...

[VinsCool]

4 hours ago, _The Doctor__ said:

Can you cheat by making the command 7 etc by insert one frame earlier on a person typing it in.... it will be in the right place for your eyes but the tracker puts it on the earlier frame internally? just to get by... it might not be a solution for your on the fly tinkering of a playing tune... but it would make it happen for a saved rmt or xex....

this of course is a hack until possible true fix / reorganization or some sort of 1 frame ahead buffering were implemented.. while the program is playing and your fiddling with values on the fly...

just ideas

Well... Not exactly, it would not work like that, so simply.

 

What I could attempt doing as a temporary workaround, only for the command 7 however, is to process the command as early as possible, then write the AUDCTL parameter to its associated channel, and then process the hijacked tuning tables using that early AUDCTL parameter to point the correct lookup table in time, instead of only catch it up 1 frame later.

 

That would still be far from ideal, but at least, command 7s would become immediate.

Compared to each other AUDCTL parameters, those will still be processed after every instruments were already initialised.

 

The real solution to that would be to change my method entirely, or when it is happening to be more specific.

Like, I know why the issue is present, but to work around it will be a mess without a total understanding of how instruments, tracks and notes are processed.

Lack of commented code and jumps all over the place really makes it difficult for me, but a thorough breakdown of every step using a debugger and some notes may help figure it out, it's just a question of time and dedication really.

 

But back to that question, yeah, that command 7 early workaround could definitely be done, and I will actually do it, since I had thought of it last night as a temporary patch too, haha.

 

Luckily for me, all the necessary information for commands processing is already in memory by the point I run into the Tuning Lookup Tables Pointer Hijack block of code.

So I simply need to add this command 7 check as soon as I reach the step of loading the AUDCTL value in memory (which was already written in memory a frame earlier), and use that XY value as a new AUDCTL value for that instrument when match is found.

 

Or something like that, doesn't matter what is exactly what but you get the idea.

 

A really ideal situation for my issue would be to know how exactly each instrument are initialised, to get their respective values as early as possible, but again, i don't yet know how to do that for now.

 

 

 

Edited September 23, 2021 by VinsCool
I'm an idiot who can't English

[ivop]

3 hours ago, rensoup said:

Perhaps we should consider biting the bullet and start fresh...

I have done some experiments in that direction already. It might be less daunting than it seems at first. Pattern and song editing is pretty trivial with qtcreator (Qt5, cross-compile to Linux, Windows, MacOS and Android). Derive a pattern class from qtableview with rmt import and export functions. Song data is similar. The difficult part is the instrument editor. That'll take some more time to implement.

 

[rensoup]

45 minutes ago, ivop said:

I have done some experiments in that direction already. It might be less daunting than it seems at first. Pattern and song editing is pretty trivial with qtcreator (Qt5, cross-compile to Linux, Windows, MacOS and Android). Derive a pattern class from qtableview with rmt import and export functions. Song data is similar. The difficult part is the instrument editor. That'll take some more time to implement.

 

Awesome!

 

It'd be great if you used C# because you could use my RMT player, but I guess I could convert it to C++ (some containers like Lists should be available for easy editing of tracks,...)

 

I should easily be able to export the RMT data to a readable text format and import it back, I can test that with RMT2LZSS. I already have a name: dxRMT for deluxeRMT unless someone has a better idea ?

From there, extra fields could be added to have per channel effects!

 

If we could convince mrk to join the effort and add his Pokey emulator, we'd basically have the player done!

 

Then you add a play button + very basic note editing as a proof of concept and we've got a tracker embryo!

 

( Then we dump it all on Vinscool ? )

 

Seriously if you could get it to play/edit notes, that'd be really exciting! Instrument editing could come later.

[VinsCool]

Ok well that was very easy to work around after all o.o

I've made many interesting observations too, my earlier code changes was done poorly from lack of experience, but I might be able to improve that now.

 

Anyway, this is still just a workaround specific for Command 7, but now it works nicely, especially to set 1.79mhz clock or 15khz on the fly, changes are immediate (for that instrument only).

Attached below is a ready to use .obx, just replace the one from Beta7 with this one.

Example .rmt attached, my edit of emkay's edit that toggles Distortion 2 at 1.79mhz on the fly.

Sounds a bit better now doesn't it?  

tracker.obx generator evening2.rmt

[VinsCool]

Alright so I learn new things everyday, and just did some things in a more efficient way.

Got rid of a large block of "stereo" exclusive code, because I sucked and did it wrong the first time, so here is the same thing but much less bloated.

 

 

I think now I'm on a really solid base to make a tune for real? It's been a while...

Having the (almost) absolute control will make a lot of things easier to do now  

 

Attached below, the newer tracker.obx, like before, just replace the one from Beta7. I'll make a proper update soon once I get everything I did wrong cleaned up  

Also attached, the generator evening module I edited again to a full stereo experience: just to show that my unified code does work as intended, including the CMD7 AUDCTL manipulation.

 

tracker.obx generator evening2 stereo.rmt

[ivop]

18 hours ago, rensoup said:

It'd be great if you used C# because you could use my RMT player, but I guess I could convert it to C++ (some containers like Lists should be available for easy editing of tracks,...)

I'd rather not mix .NET C# with Qt5. Two totally different frameworks, although there are .NET bindings for Qt. And, I have never done anything in C# before

 

Quote

I should easily be able to export the RMT data to a readable text format and import it back, I can test that with RMT2LZSS. I already have a name: dxRMT for deluxeRMT unless someone has a better idea ?

From there, extra fields could be added to have per channel effects!

Yes, if a new tracker editor arises (no promises), a new extended file format could be needed at some point. For now I am thinking about an RMT class that has a read and a writer function. The read function reads a normal rmt file and populates itself with arrays of PATTERN, INSTRUMENT and SONG class instances, that are derived from Qtableview, and can then be displayed at will. Add editing functions, and there's your rudimentary editor. Edit: and the write function retrieves its information from the internal data structures and writes out a new rmt file.

 

Quote

If we could convince mrk to join the effort and add his Pokey emulator, we'd basically have the player done!

Yeah, I'd love to see that emulator ported to C or C++.

 

Quote

Then you add a play button + very basic note editing as a proof of concept and we've got a tracker embryo!

Perhaps I even start with creating the play loop. As soon there's sound, the better! And the play loop should be properly timed from the beginning. We don't want to replicate Radek's bugs

Quote

( Then we dump it all on Vinscool ? )

LOL

 

Edit: and then Vinscool has to learn C/C++, too Luckily I use C++ as C-with-classes, and not all the cruft that has been tacked onto the language in the past 20 years.

Edited September 24, 2021 by ivop

[rensoup]

3 hours ago, ivop said:

Yes, if a new tracker editor arises (no promises), a new extended file format could be needed at some point. For now I am thinking about an RMT class that has a read and a writer function. The read function reads a normal rmt file and populates itself with arrays of PATTERN, INSTRUMENT and SONG class instances, that are derived from Qtableview, and can then be displayed at will. Add editing functions, and there's your rudimentary editor. Edit: and the write function retrieves its information from the internal data structures and writes out a new rmt file.

Derive song data from QT ? Shouldn't that be keept apart ?

 

I'm not sure why you'd want to keep using the original RMT format, it's irrelevant these days, it only existed because it had to fit in the A8's memory.

 

3 hours ago, ivop said:

Perhaps I even start with creating the play loop. As soon there's sound, the better! And the play loop should be properly timed from the beginning. We don't want to replicate Radek's bugs

 

You'd still want to use the 6502 emulation too ?

 

[ivop]

23 minutes ago, rensoup said:

Derive song data from QT ? Shouldn't that be keept apart ?

Not from Qt itself, but from the internal data structures where the pattern data is stored to be easily edited in the GUI. You can derive a widget from Qtableview and add member functions that load/save RMT data, populate the table, react to edits, et cetera...

 

Quote

I'm not sure why you'd want to keep using the original RMT format, it's irrelevant these days, it only existed because it had to fit in the A8's memory.

Hmm, that's a good question. I don't see any reason to stick to the original RMT format, too. But the tracker editor should be able to import them though.

 

Quote

You'd still want to use the 6502 emulation too ?

Good question. At first my idea was to sort of replicate RMT, but skipping the 6502 player is also an option, and then use your 6502 LZSS player when exporting a song for use in a game or demo.

 

Edited September 24, 2021 by ivop

[rensoup]

2 hours ago, ivop said:

Hmm, that's a good question. I don't see any reason to stick to the original RMT format, too. But the tracker editor should be able to import them though.

Well of course import is a given. 

2 hours ago, ivop said:

Good question. At first my idea was to sort of replicate RMT, but skipping the 6502 player is also an option, and then use your 6502 LZSS player when exporting a song for use in a game or demo.

By keeping the 6502 player/emulator (even if just on the tracker side) you would still be subjected to the same limitions as stock RMT... any new feature would have to be coded in 6502. A framework for something like effect per channel becomes challenging, and so would be implementing protracker like effects...

[ivop]

20 minutes ago, rensoup said:

By keeping the 6502 player/emulator (even if just on the tracker side) you would still be subjected to the same limitions as stock RMT... any new feature would have to be coded in 6502. A framework for something like effect per channel becomes challenging, and so would be implementing protracker like effects...

That's true. But I think for now, it's easier to run the existing 6502 player and a pokey emulator. Perhaps even in the same thread. With libatari800 you can both run 6502 code and request the pokey sound buffer. Timing will be perfect. It's a start, and the source will be open, so it can be improved upon later, and then skip the middle man (read: 6502 player).

 

Edited September 24, 2021 by ivop

[rensoup]

1 hour ago, ivop said:

That's true. But I think for now, it's easier to run the existing 6502 player and a pokey emulator

Timing is fine in WebPokey as far as I can tell. It only seems to be an issue in RMT so I don't know what makes you think you're going to have an easier task but fair enough...

[ivop]

13 hours ago, rensoup said:

Timing is fine in WebPokey as far as I can tell. It only seems to be an issue in RMT so I don't know what makes you think you're going to have an easier task but fair enough...

It makes it an easier task because I don't have to either port WebPokey to C++ or write the tracker in Javascript (out of the question). Using an existing backend (for now), I can focus on the play loop and the GUI.

Edited September 25, 2021 by ivop

[VinsCool]

Just for fun, while my Visualizer isn't quite ready for everyone, I've recreated the player used in RMT .xex exports  

I was able to recreate it entirely based on the disassembly from an original .xex export, and added a few things of my own.

A few things were taken directly from the Visualizer for the recreation of the Simple player, but overall, it should behave almost exactly like the original.

Simple RMT Player.zip

 

How to use:

Edit a handful of parameters like: STARTLINE, STEREOMODE, REGIONPLAYBACK, VLINE and rasterbar colour, edit your own lines of text (from 1 to 5), then assemble using XASM.

Make sure to have a 'music.rmt' in the same folder or it will fail to assemble.

 

The reason I've made this was because the lack of direct export feature in the last few RMT patch version without an easy way to build binaries annoyed some people, and this is perfectly valid criticism.

Instead of making everyone wait, they will have a way to get binaries very similar to what RMT used to produce.

 

It should also be very easy to use as a base player file; I made sure to have all the initialisation done before the .rmt is added at the end of the file, you could assemble, and swap .rmt files with absolutely no problem.

 

Some technical infos I found while I was playing with the disassembly:

$3E00 is the initialisation addresss for the Simple RMT Player

$3F00 is where the text data is located

 

I suppose this leaves a lot of possibilities if we want to make a functional replacement for the currently unusable exports.

For now, manual assembly of the player is required, but this is certainly better than nothing at all  

Edited September 26, 2021 by VinsCool
typo