Jump to content
IGNORED

RMT Hacking Ideas and Progress


Recommended Posts

Okay, I found a way to get it work with the trackn_audctl variables, now I can finally change it on the fly!
This is based on what Distortion is being used, and at most this will be able to avoid changing the clock when it is unwanted.

However, There is yet another problem I need to address now.
I can indeed control the AUDCTL being fed into memory to change the clock on the fly for Distortion 2, but my current method basically wipes out anything that may also exist within the trackn_audctl value in memory, so if I tried to use 15khz in 1 instrument, that also used Distortion 2, as soon as the contents being NOT Distortion 2 is detected, it's a full reset of the memory, so now I would be stuck with either, 1.79mhz clock + Distortion 2, or nothing at all, hahaha :D 

But hey, this is a bit of progress anyway.
I need to go out for a bit, so I'll come back to this later today with maybe a much better approach to it.
I honestly did not expect this whole idea to be trickier to execute, but here we are ?

 

Here's the binary I tested in the video above.
There was absolutely no instrument with AUDCTL bits, they all were handled by the hijack code, and it's certainly not the ideal way to do it, but it is at least sort of working, for a proof of concept.

Distortion 2 TEST2.obx

Edited by VinsCool
I can't English
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

18 hours ago, VinsCool said:

Just try searching for the Atari executable header in a hex editor, there will be 3 different player binaries in 3 different locations, the MONO and STEREO players are very close to each others, but other than that, there will be a lot of stuff between each one of them.

What kind of stuff? Other 6502 assembly or x86 code? If it's the former, there might be possibilties. If it's the latter, we are SOL.

 

18 hours ago, VinsCool said:

if MADS syntax produce code that is easier to read, I will for sure learn how to make use of it sometime.

Thanks!

18 hours ago, VinsCool said:

IFT... I only assumed this stood for 'if', because that is pretty much how it have behaved for me.

IFT -> 'If True'?

That seems logical to me, haha

My first thought was IF Then :)

  • Like 1
Link to comment
Share on other sites

46 minutes ago, VinsCool said:

Here's the binary I tested in the video above.
There was absolutely no instrument with AUDCTL bits, they all were handled by the hijack code, and it's certainly not the ideal way to do it, but it is at least sort of working, for a proof of concept.

Distortion 2 TEST2.obx 6.85 kB · 2 downloads

Now THAT is SOMETHING :)

This is really is the missing link to a lot tunes that wait for being converted :)

 

  • Like 2
Link to comment
Share on other sites

38 minutes ago, ivop said:

What kind of stuff? Other 6502 assembly or x86 code? If it's the former, there might be possibilties. If it's the latter, we are SOL.

Hmm, I see your player at offset 0x3ee00 up to 0x3f6dd. After that, there's some x86 code and a 16-bit unicode table. So we are so out of luck ?

 

Or maybe not completely. Perhaps you can share the exact blocks you patch, so I might find pointers to it (at runtime, not offsets in the binary). If pointers can be changed, we maybe can use the largest patchable block of consecutive memory that ends up in the 6502 emulation.

 

Now here's another idea. We can compile sa_c6502.dll from scratch, so we can add patches to the 64kB memory array there, too!

  • Thanks 1
Link to comment
Share on other sites

1 hour ago, ivop said:

What kind of stuff? Other 6502 assembly or x86 code? If it's the former, there might be possibilties. If it's the latter, we are SOL.

Yeah, that is pretty much what it looks like to me.

26 minutes ago, ivop said:

Hmm, I see your player at offset 0x3ee00 up to 0x3f6dd. After that, there's some x86 code and a 16-bit unicode table. So we are so out of luck ?

Ah well... I also pretty much expected something as such.

27 minutes ago, ivop said:

Or maybe not completely. Perhaps you can share the exact blocks you patch, so I might find pointers to it (at runtime, not offsets in the binary). If pointers can be changed, we maybe can use the largest patchable block of consecutive memory that ends up in the 6502 emulation.

 

Now here's another idea. We can compile sa_c6502.dll from scratch, so we can add patches to the 64kB memory array there, too!

Now that sounds like something interesting... Being able to have both the .exe patched, and the rmtplayr code from a .dll would seriously change a lot of that stuff.
I am unfortunately not qualified for that sort of gigantic task, so if you can find an entrypoint, it could flip the table upside down to a brand new surface to work on.

Link to comment
Share on other sites

1 hour ago, emkay said:

Now THAT is SOMETHING :)

This is really is the missing link to a lot tunes that wait for being converted :)

There is still an important element missing: I must figure out a workaround that would allow this hack to function, AND keep existing AUDCTL combinations in memory without conflicts.
Ideally, what would really change the game is an extra effect command in instruments that would set the AUDCTL as an envelope, and I can sort of see a way to attempt this, but I have know how I could even get such a monumental change to work at all.

Still, RMT2LZSS is the closest possible option available, with the .erti combinations, it can be done very easily there, but that is quite a pain in the ass to work with, I think I can speak from experience there lol

So for now, I'm back home, and this kept my mind busy, so I really want to prove this Distortion 2 thing can work, and I know how stubborn I am sometime, I will find a way lol

Link to comment
Share on other sites

8 minutes ago, VinsCool said:

There is still an important element missing: I must figure out a workaround that would allow this hack to function, AND keep existing AUDCTL combinations in memory without conflicts.
Ideally, what would really change the game is an extra effect command in instruments that would set the AUDCTL as an envelope, and I can sort of see a way to attempt this, but I have know how I could even get such a monumental change to work at all.

Still, RMT2LZSS is the closest possible option available, with the .erti combinations, it can be done very easily there, but that is quite a pain in the ass to work with, I think I can speak from experience there lol

So for now, I'm back home, and this kept my mind busy, so I really want to prove this Distortion 2 thing can work, and I know how stubborn I am sometime, I will find a way lol

For me it would be sufficient enough to have it basically working in RMT, and LZSS was adopting it.

 

LZSS would adopt it automatically (I guess) , if the RMT file has the correct AUDCTL value stored.  

  • Like 1
Link to comment
Share on other sites

13 minutes ago, emkay said:

For me it would be sufficient enough to have it basically working in RMT, and LZSS was adopting it.

 

LZSS would adopt it automatically (I guess) , if the RMT file has the correct AUDCTL value stored.  

Let's not get worried for now, I think I have an idea that could work.
I'm still learning how to code, but I was using a nice little 6502 emulator with assembler and disassembler, and I have come up with this rudimentary piece of code that seems to perfectly fit my problem :) 

LDY #$21
STY $0001
LDA #$20
BIT $0001
BNE good

bad:
EOR $0001
badloop:
LDX #$ff
JMP badloop

good:
EOR $0001
goodloop:
LDX #$00
JMP goodloop

The situation ending with a 'goodloop' is precisely what I want to get.
If I combine a BIT operation, followed by a branch, and a EOR operation, I can safely land on for the value I want to get rid of (here, the 1.79mhz clock value, that is either $20, or $40), and not risk breaking anything else.
So as long as I make sure to get the BIT branch correctly, and then EOR the value I tested before branching, I should end with that value removed without affecting everything else, and if it branched at the wrong place, the value would be added, instead.

That's worth giving it a shot for sure. 

  • Like 1
Link to comment
Share on other sites

Uploaded the fake and one real RMT standalone libraries to github.

 

https://github.com/ivop/rmt-sa-libs

 

The libraries to use to see how RMT calls its DLLs.

 

real/sa_c6502 is the real deal. The same library that has been distributed with RMT since 2003. But look how compilers have been improved since:

 

53248 Feb  2  2003 sa_c6502.dll

 

vs

 

24064 Aug 31 19:16 sa_c6502.dll

 

It's almost 55% smaller now with gcc -O3 :)

 

Oh, and yes, it works like before.

 

Now we can see if/how RMT changes memory between calls to sa_c6502. Does it?

And we could replace the memory with the player we want, no matter how big it is :D

Edited by ivop
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

Okay, finally, I figured out a method that is 100% guaranteed to work this time :D 
I was an idiot, I started over complicating the process, but I only had to be smarter than the code.

 

So to make a quick summary, here's what I finally stuck to after I realised how much I was on the wrong track:
- check for Distortion 2 for the first step
- proceed to the hijack like earlier (since that part did work perfectly fine after all)
- ORA the new AUDCTL value ($20 or $40) after the checks passed with trackn_audtl,x, then ORA with a new variable called v_dist2flag in the zeropage, then STA that value in v_dist2flag
- at the moment all 4 channel's own trackn_audctl are ORA'd together, include the v_dist2flag in the process, making all AUDCTL values written in memory
- once the step above is done, LDA #0, and STA into v_dist2flag to reset it for the next time the rmtplayr is called

Obviously, Stereo is not yet supported with this method, but that can be worked around very easily, in the same way the other hijacked code blocks duplicates were included when it was necessary.
So yay, I could have done this at the very beginning to avoid wasting my time, but now I know how this could work haha :P 

Distortion 2 TEST3.obx Distortion 2 TEST3.rmt

  • Like 5
Link to comment
Share on other sites

Alright, it's done.
I've tested it, everything seems to work exactly like it is wanted.
Now Distortion 2 will hijack the 1.79mhz clock automatically, there will be virtually no difference other than that :) 

This was based directly on the Patch 16 Beta5 code, but I had to comment out the entire 16-bit code because I was not able to fit everything together.
So the Distortion A and C 15khz automatic tuning adjustments is still there, and now there's the automatic Distortion 2 1.79mhz clock, just no 16-bit for the time being.
A loss for a gain :D 

In the .zip I included the .exe, .dlls, ASM code I edited, and prebuilt player binaries.


Now @emkay have a treat and show us what you can do! :evil:
 

RMT Distortion 2 Hack.zip

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

 

33 minutes ago, emkay said:

This is the most (and problably last really ;) ) relevant version. For sure. 

Nah I wouldn't say that.. as...

1 hour ago, VinsCool said:

Alright, it's done.
I've tested it, everything seems to work exactly like it is wanted.
Now Distortion 2 will hijack the 1.79mhz clock automatically, there will be virtually no difference other than that :) 

This was based directly on the Patch 16 Beta5 code, but I had to comment out the entire 16-bit code because I was not able to fit everything together.
So the Distortion A and C 15khz automatic tuning adjustments is still there, and now there's the automatic Distortion 2 1.79mhz clock, just no 16-bit for the time being.
A loss for a gain :D 

In the .zip I included the .exe, .dlls, ASM code I edited, and prebuilt player binaries.


Now @emkay have a treat and show us what you can do! :evil:
 

RMT Distortion 2 Hack.zip 3.25 MB · 3 downloads

I'm sure you'll find a way to make it all fit together and streamline everything, each time you've gone about this, be it hours, a day, a week... you come back with something better and leaner. It'll all fall in place when you see it.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

1 hour ago, rensoup said:

nope, I'd have to make another patch version to emulate Vinscool's, which will probably change every day for the next year ?

I've spent enough time beta testing this program I know the .erti features allow all of that very nicely and with incredible precision, assuming the user wants to spend the time and efforts for it, that is, haha

  • Haha 1
Link to comment
Share on other sites

6 hours ago, VinsCool said:

That sounds very good

 

It's just the first or second step to set to gen. 2. The sharpness of the tone adds to the rest of the instrument.

Also, as the main voice gets a steel touch , the rest of the sounds get a wooden character. 

 

Close your eyes and imagine a group of 4 people playing their instruments :D

  • Like 2
Link to comment
Share on other sites

17 hours ago, _The Doctor__ said:

Had a feeling we'd see you here!  ... pretty inspirational, are you playing with his work yet?

Haha, no I'm just going through threads I find interesting sometimes enjoying other ppl's results :)

BTW I always wanted to hack a HardBASS instrument into RMT, so if I wanted to spend time on that I'd surely check this thread out on how to hack RMT! ...but I don't think I'd have the time and dedication to do that TBH. So just enjoying what I see/hear in this topic as it's really nice.

  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...