VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 10, 2021 Share Posted September 10, 2021 (edited) 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 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 September 10, 2021 by ivop 2 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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: The eventual desync is because of this I think: https://atariage.com/forums/topic/322655-rmt-hacking-ideas-and-progress/?do=findComment&comment=4902399 Possibly, that's certainly all related 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 Hahaha well I guess there's already many steps done with the rmtplayr that has been quite heavily edited lately 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted September 10, 2021 Share Posted September 10, 2021 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. Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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 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. 1 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted September 10, 2021 Share Posted September 10, 2021 29 minutes ago, VinsCool said: 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. That's pretty sure. 1 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 10, 2021 Share Posted September 10, 2021 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 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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! 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 10, 2021 Share Posted September 10, 2021 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. 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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. 3 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 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? ? Quote Link to comment Share on other sites More sharing options...
ivop Posted September 10, 2021 Share Posted September 10, 2021 (edited) 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 September 10, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 10, 2021 Author Share Posted September 10, 2021 (edited) 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 September 10, 2021 by VinsCool Addendum 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 11, 2021 Share Posted September 11, 2021 (edited) 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 September 11, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 11, 2021 Share Posted September 11, 2021 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) Quote Link to comment Share on other sites More sharing options...
ivop Posted September 11, 2021 Share Posted September 11, 2021 (edited) 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 Edited September 11, 2021 by ivop 2 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 11, 2021 Share Posted September 11, 2021 (edited) ah so it's a gentle tapping on Rensoup's shoulder... Now I understand. After POP of course... unless there is another composition of the music for POP ? all the best! Edited September 11, 2021 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted September 11, 2021 Share Posted September 11, 2021 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. Quote Link to comment Share on other sites More sharing options...
ivop Posted September 11, 2021 Share Posted September 11, 2021 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. Quote Link to comment Share on other sites More sharing options...
rensoup Posted September 11, 2021 Share Posted September 11, 2021 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. 2 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 11, 2021 Author Share Posted September 11, 2021 I'm okay with having a 6502 player, it's fun to work around the limitations (not in the tracker itself I mean, but to run on the real thing) 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted September 12, 2021 Share Posted September 12, 2021 2 hours ago, VinsCool said: I'm okay with having a 6502 player, it's fun to work around the limitations (not in the tracker itself I mean, but to run on the real thing) Yeah it can be fun manipulating relics but serves no practical purpose anymore ? 1 Quote Link to comment Share on other sites More sharing options...
rensoup Posted September 12, 2021 Share Posted September 12, 2021 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... 2 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 12, 2021 Author Share Posted September 12, 2021 1 hour ago, rensoup said: Yeah it can be fun manipulating relics but serves no practical purpose anymore ? Doesn't stop me regardless ? Not because something is old means it's not enjoyable to make use of once in a while, hehe :3c 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 12, 2021 Share Posted September 12, 2021 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? 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. 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.