Jump to content
IGNORED

RMT Hacking Ideas and Progress


Recommended Posts

23 minutes ago, VinsCool said:

Hah well, I think there's something that's not going too well.
running a tune without any input eventually desync, and the sound gets all messy o.o

Can you post a .rmt file that exposes this behaviour, and when?

 

The eventual desync is because of this I think: https://atariage.com/forums/topic/322655-rmt-hacking-ideas-and-progress/?do=findComment&comment=4902399

 

Rmt.exe almost never requests a full frame, always slightly more or less. As said before, its timing is way off. Perhaps, we should write a new tracker?   ;)    Hi @emkay :D

 

Edit: Or, maybe see if the apokeysnd.dll API is more stable as to the amount of cycles per processing calls. It might be...

Edited by ivop
  • Haha 2
Link to comment
Share on other sites

6 minutes ago, ivop said:

Can you post a .rmt file that exposes this behaviour, and when?

Could be anything, honestly.
It really happened at random, but the modules with complex sound design and very rapid effects going were the ones likely to wreck things the most ?

8 minutes ago, ivop said:

Possibly, that's certainly all related :D 

8 minutes ago, ivop said:

Rmt.exe almost never requests a full frame. As said before, its timing is way off.

No wonder if that desync happens, in this case! hahaha

9 minutes ago, ivop said:

Perhaps, we should write a new tracker?   ;)    Hi @emkay :D

Hahaha well I guess there's already many steps done with the rmtplayr that has been quite heavily edited lately :D 

  • Like 1
Link to comment
Share on other sites

As now the RMT offers a lot of missing features of the past, it is a really small step to adopt the correct stuff to the LZSS player. 

What's just missing is a compatible control .

As the LZSS Player is much less complicated, I still don't see why this should be a problem.

We only had the problem there with different programming and resulting different timings, but that was quickly solved. 

Link to comment
Share on other sites

Automatic tuning tables handler is not yet a LZSS player feature however ;) 
This one is a feature I was able to code myself and I am so fucking happy of the quality of life improvements this is all doing by itself.
Combined to LZSS it would be a killer functionality that would make half of the custom .erti functionality unnecessary in many situations, so much less time spent finely editing 1 value at the time :D 

There are many things that could still be done with the rmtplayr code alone, however, and I am more than excited to try doing even more mad scientist experiments in the near future.
That obviously includes the massive breakthrough by ivop there! A huge door was opened after being sealed for so long, and this is really fucking awesome where we are today.

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

The sa_c6502.dll code injector project eventually turned out great indeed, and I'm looking forward to what VinsCool is going to do with all the extra code space :)

 

The sa_pokey.dll libatari800 bridge project pretty much failed, even though I got sound out of it eventually :) Here's the main problem for the drift:

 

...somewhere while playing.....

Pokey_Process: 1498 bytes requested
Pokey_Process: added 1472 bytes to temp_buffer
Pokey_Process: added 1472 bytes to temp_buffer

........

 

Rmt requests 1498 bytes, we have to render two full frames to have enough bytes to feed back to Rmt. There's your drift. I don't think this can be mitigated for with the current libatari800 API. Rmt is just broken ;)

  • Sad 1
Link to comment
Share on other sites

18 minutes ago, ivop said:

The sa_c6502.dll code injector project eventually turned out great indeed, and I'm looking forward to what VinsCool is going to do with all the extra code space :)

 

I am also excited by all the possibility indeed!

I've got already a bunch of proof of concept functional like moved memory locations, extra tables, extra code, etc etc, so there's more that could be done for sure.
Being helped by the RMT Vizualiser side project for learning more advanced programming is really doing a difference too!
Only the code injector will allow a lot already, so the POKEY emulation is not a big priority, the current apokeysnd.dll I've included with the Patched RMT versions in this thread does a pretty good job already :) 

And who knows, maybe some other person would take a look at your github, and find a solution for the LibAtari800 bridge :) 
It does work as a proof of concept, so there has to be something possible from a different angle! 

  • Like 1
Link to comment
Share on other sites

1 hour ago, VinsCool said:

I am also excited by all the possibility indeed!

I've got already a bunch of proof of concept functional like moved memory locations, extra tables, extra code, etc etc, so there's more that could be done for sure.
Being helped by the RMT Vizualiser side project for learning more advanced programming is really doing a difference too!

? I was wondering, have you ever programmed in any other language before, or is 6502 assembly your first?

 

1 hour ago, VinsCool said:

Only the code injector will allow a lot already, so the POKEY emulation is not a big priority, the current apokeysnd.dll I've included with the Patched RMT versions in this thread does a pretty good job already :)

Agreed. apokeysnd.dll is good enough for composition.

1 hour ago, VinsCool said:

And who knows, maybe some other person would take a look at your github, and find a solution for the LibAtari800 bridge :) 
It does work as a proof of concept, so there has to be something possible from a different angle! 

That could happen, if somebody adjusted atari800 to be cycle based, instead of frame based. Internally it is somewhat cycle exact (but IRQs are triggered only per scan line, which is wrong), but the outside API from within the main() function, and hence the libatari800 API, is frame based. And there's no way to differentiate between TV-Mode exact Atari hardware, broadcast standard, and perfect 50/60Hz, like Altirra can. Libatari800 is always hardware exact, as far as I can see.

 

  • Like 1
Link to comment
Share on other sites

16 minutes ago, ivop said:

? I was wondering, have you ever programmed in any other language before, or is 6502 assembly your first?

I've tried multiple times over the years, and honestly never went further than "hello world" in most cases.
I had poked (no pun intended) some BASIC too at some point, but again, it was rather simple code with lots of syntax error for maybe 1 simple thing.

But my real first programming language where I really actually understand now, and have made things with, is indeed 6502 Assembler, which I only started to learn around the month of June when I was trying to port RMT Patch 8 into the .exe of RMT 1.30 :) 
Then things went snowball since.

  • Like 3
Link to comment
Share on other sites

19 minutes ago, ivop said:

Agreed. apokeysnd.dll is good enough for composition.

That could happen, if somebody adjusted atari800 to be cycle based, instead of frame based. Internally it is somewhat cycle exact (but IRQs are triggered only per scan line, which is wrong), but the outside API from within the main() function, and hence the libatari800 API, is frame based. And there's no way to differentiate between TV-Mode exact Atari hardware, broadcast standard, and perfect 50/60Hz, like Altirra can. Libatari800 is always hardware exact, as far as I can see.

That's... kinda not good, is it? ?

Link to comment
Share on other sites

12 minutes ago, VinsCool said:

That's... kinda not good, is it? ?

No, it isn't ?

 

Went back to the "fake" apokeysnd.dll:

 

Spoiler

APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6596 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2252 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=3298 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2172 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6555 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2252 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=3378 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6636 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=1126 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6555 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2132 depth=8

 

As you can see, it does not call single frames at the time. There's a really weird adjustment algorithm going on inside Rmt.xex, I think to sync to true 50/60Hz.

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

8 minutes ago, ivop said:

No, it isn't ?

 

Went back to the "fake" apokeysnd.dll:

 

  Hide contents

APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6596 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2252 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=3298 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2172 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6555 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2252 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=3378 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6636 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=1126 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=4384 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=6555 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=35468 depth=8
APokeySound_Generate: cycles=2132 depth=8

 

As you can see, it does not call single frames at the time. There's a really weird adjustment algorithm going on inside Rmt.xex, I think to sync to true 50/60Hz.

This looks so wrong indeed.

It's like it's trying to get as close as possible to the PAL cycles per frame (and off by 1000 cycles?) then have a very inconsistent numbers of what appears to be the VBI Immediate time?
That's odd for sure...

Unless the inconsistent numbers are the amount of cycles a single rmtplayr call lasts? Similar to the coloured rasterbar in exports?

Edited by VinsCool
Addendum
  • Like 1
Link to comment
Share on other sites

18 hours ago, VinsCool said:

This looks so wrong indeed.

It's like it's trying to get as close as possible to the PAL cycles per frame (and off by 1000 cycles?) then have a very inconsistent numbers of what appears to be the VBI Immediate time?
That's odd for sure...

Unless the inconsistent numbers are the amount of cycles a single rmtplayr call lasts? Similar to the coloured rasterbar in exports?

It's really weird. Multispeed is even weirder. The timing is just off, but we have to deal with it :) libatari800 experiment is a dead end IMHO, with either APIs. Have to make do with apokeysnd.dll :) And as long as the caller (read: Rmt.exe) is off, no library can fix that.

 

But, I have a new idea. Instead of having to constantly update RMT2LZSS to match the exact features you implement in the tracker player, we could have a SAP-R exporter builtin in Rmt.exe via sa_c6502.dll. IIRC RMT2LZSS can import SAP-R, too!

 

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

I am just hopeful that this is all still ends up with the avenues and abilities needed to put these into other products, projects and games with all of this intact. rmt2lzss being a very useful tool. I love stand alone music but having it play in the background is always nice too... just like we did with ST/Amiga/x86 (modz) :)

Link to comment
Share on other sites

4 minutes ago, _The Doctor__ said:

I am just hopeful that this is all still ends up with the avenues and abilities needed to put these into other products, projects and games with all of this intact. rmt2lzss being a very useful tool.

Yes, the end goal is the best possible RMT with code injection, proper tuned tables, and apokeysnd.dll to hear the least worst approximation, but run the end result through RMT2LZSS for a low cycle count player, and play on real hardware ;) Now if RMT's behaviour changes by the hands of VinsCool, Rensoup has to update his converter. My idea basically relieves rensoup from that duty :D

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

4 hours ago, ivop said:

But, I have a new idea. Instead of having to constantly update RMT2LZSS to match the exact features you implement in the tracker player, we could have a SAP-R exporter builtin in Rmt.exe via sa_c6502.dll. IIRC RMT2LZSS can import SAP-R, too!

Sure that would be a less painful process...

 

As I might have mentioned ?, the real solution would be to remove the whole embedded XEX  + patching malarkey and replace it with the RMT2LZSS C# player (translated to C++ if needed) which would communicate directly with apokey.dll/a800lib/altirra/..., then adding features and tables becomes much easier and player bloating is never an issue anymore. 

 

 

Link to comment
Share on other sites

40 minutes ago, rensoup said:

Sure that would be a less painful process...

 

As I might have mentioned ?, the real solution would be to remove the whole embedded XEX  + patching malarkey and replace it with the RMT2LZSS C# player (translated to C++ if needed) which would communicate directly with apokey.dll/a800lib/altirra/..., then adding features and tables becomes much easier and player bloating is never an issue anymore.

In theory, that sounds great, but in practice that won't work because of previously explained timing issues. Even with apokeysnd.dll API the overall pitch is off.

 

The only timing in Rmt.exe which is sort-off okay, is the timer that fires calling sa_c6502.dll to emulate one loop of the tracker player. If you hook in there, and start writing out pokey frames to a SAP-R file, you can convert it to LZSS afterwards. Might need to cut off some frames at the beginning, but then you're good to go.

Link to comment
Share on other sites

41 minutes ago, ivop said:

In theory, that sounds great, but in practice that won't work because of previously explained timing issues. Even with apokeysnd.dll API the overall pitch is off.

Of course, this could only happen if the RMT source was available!

42 minutes ago, ivop said:

The only timing in Rmt.exe which is sort-off okay, is the timer that fires calling sa_c6502.dll to emulate one loop of the tracker player. If you hook in there, and start writing out pokey frames to a SAP-R file, you can convert it to LZSS afterwards. Might need to cut off some frames at the beginning, but then you're good to go.

Yes I agree that works, you still have a 6502 player which is cumbersome to update, but it's definitely better than supporting another patch in RMT2LZSS. 

 

 

  • Like 2
Link to comment
Share on other sites

3 hours ago, ivop said:

The only timing in Rmt.exe which is sort-off okay, is the timer that fires calling sa_c6502.dll to emulate one loop of the tracker player. If you hook in there, and start writing out pokey frames to a SAP-R file, you can convert it to LZSS afterwards. Might need to cut off some frames at the beginning, but then you're good to go.

looping tunes aren't supported in SAPR btw, though you could potentially add some info in the header...

  • Like 2
Link to comment
Share on other sites

15 hours ago, rensoup said:

looping tunes aren't supported in SAPR btw, though you could potentially add some info in the header...

Yes, perhaps we need to expand the SAP-R format anyway. It does not support anything other than full frames, either PAL or NTSC, and IIRC it does not support stereo. And it lacks SKCTL. Probably call it SAP-R2 or something. And indeed a "loop back to location x" variable would be great, too. But for now, let's see if I can implement a simple mono 1x recorder, and perhaps some tools to remove the cruft at the beginning of the capture, and maybe the end. A SAP-R editor? :D

 

BTW even though the sa_pokey_libatari800 experiment failed, don't underestimate libatari800. If you want, you could link it with RMT2LZSS and play sound. At least for 1x PAL/NTSC players. Multispeed would need more work.

  • Like 2
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...