rensoup Posted September 4, 2021 Share Posted September 4, 2021 2 hours ago, emkay said: Btw. As now things have been changed tremendously. Could you suggest an Amiga Mod file to convert? Sure: checknobankh https://modarchive.org/index.php?request=view_by_moduleid&query=36330 Vite and Plack https://modarchive.org/index.php?request=view_by_moduleid&query=60535 wasteland https://modarchive.org/index.php?request=view_by_moduleid&query=158236 all of them please, and maybe a newer Elysium update too ? 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 4, 2021 Author Share Posted September 4, 2021 30 minutes ago, ivop said: I do a memcmp(previous_memory+0x3182, current_memory+0x3182, 2264), and detect that it has been altered in between 6502 emulation calls. Conclusion: bytes are changed within the player memory area in between calls to C6502_JSR(). Now find out which, and why I just thought about it now (playing in the code right now just for fun)... The program is asked to find the 'Tracker ' tag, and replace memory at that moment. Doesn't that mean it will just try to replace it infinitely? Since the RMT.exe is not overwritten, after all. Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 4, 2021 Author Share Posted September 4, 2021 22 minutes ago, VinsCool said: I just thought about it now (playing in the code right now just for fun)... The program is asked to find the 'Tracker ' tag, and replace memory at that moment. Doesn't that mean it will just try to replace it infinitely? Since the RMT.exe is not overwritten, after all. I think I may be correct. Got some mild success by adding the following at the start of the .c file: int inject_done=0; and changing the following: #ifdef INJECT_TRACKER_OBX if (inject_done!=0) { fprintf(stderr, "%s: tracker memory already injected, skipping...\n", __func__); } else if (!strncmp(g_memory+0x3182, "TRACKER ", 8)) { fprintf(stderr, "%s: TRACKER tag found, loading file at $3182\n", __func__); load_raw("tracker.obx", g_memory+0x3182, 6); inject_done++; } #endif Now the timing still somewhat off, but by doing this, and injecting the exact same 2270 bytes tracker binary, it does work okay, but I can tell things aren't quite right still Things sound a bit closer to what is expected now, at least Apologise for any bad code, I have no experience with C right now lol tracker.obx sa_c6502.dll 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 5, 2021 Share Posted September 5, 2021 1 hour ago, VinsCool said: I think I may be correct. Got some mild success by adding the following at the start of the .c file: int inject_done=0; and changing the following: #ifdef INJECT_TRACKER_OBX if (inject_done!=0) { fprintf(stderr, "%s: tracker memory already injected, skipping...\n", __func__); } else if (!strncmp(g_memory+0x3182, "TRACKER ", 8)) { fprintf(stderr, "%s: TRACKER tag found, loading file at $3182\n", __func__); load_raw("tracker.obx", g_memory+0x3182, 6); inject_done++; } #endif Now the timing still somewhat off, but by doing this, and injecting the exact same 2270 bytes tracker binary, it does work okay, but I can tell things aren't quite right still Things sound a bit closer to what is expected now, at least That's useless code IMHO. After the injection (load_raw()) the strncmp() never matches the TRACKER tag again, and will always skip the loading code. It is only triggered once, but after that the memory still changes between calls. I will investigate tomorrow. Been watching the full Zandvoort Grand Prix of 1963 right now The commentary is hilarious. The most safe circuit in the world. And people just walk along the circuit without any protection But, Jim Clark FTW! 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 33 minutes ago, ivop said: That's useless code IMHO. After the injection (load_raw()) the strncmp() never matches the TRACKER tag again, and will always skip the loading code. It is only triggered once, but after that the memory still changes between calls. I will investigate tomorrow. Been watching the full Zandvoort Grand Prix of 1963 right now The commentary is hilarious. The most safe circuit in the world. And people just walk along the circuit without any protection But, Jim Clark FTW! Ahh maybe you're right... I only blindly guessed over there, I saw the 'TRACKER tag found, loading file at $3182' line over and over in really quick succession so I assumed my idea to not do it again would help, but maybe not hehe. for now I'm trying to improve my earlier code in the 'hijack' block of rmtplayr... I think I might be able to re-introduce the 16-bit code alongside the Distortion 2 hack now (yeah yeah totally pointless but I know at least 1 person who would like it anyway) 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 5, 2021 Share Posted September 5, 2021 49 minutes ago, VinsCool said: Ahh maybe you're right... I only blindly guessed over there, I saw the 'TRACKER tag found, loading file at $3182' line over and over in really quick succession so I assumed my idea to not do it again would help, but maybe not hehe. Oh, but that's weird. I only see the 'TRACKER tag found, loading file at $3182' line once! After that, the tag is overwritten with the contents of tracker.obx (minus the first six bytes), hence the tag won't match anymore. 49 minutes ago, VinsCool said: for now I'm trying to improve my earlier code in the 'hijack' block of rmtplayr... I think I might be able to re-introduce the 16-bit code alongside the Distortion 2 hack now (yeah yeah totally pointless but I know at least 1 person who would like it anyway) Haha 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 I made a pretty interesting observation tonight with my hijack code in rmtplayr. I noticed that while my method around v_audctl works pretty well, it is also 1 frame late when it is detected and handled! That memory location will only be updated near the end of the Player execution, before being pushed into the actual AUDCTL register for the next frame, alongside the AUDC and AUDF ones. Now, the issue is, the trackn_audc and trackn_audf contents will always be updated before v_audctl, which makes very quick changes between frames obvious if you keep an attentive ear to the sound output. That is usually not a problem under normal situations, but when my own tables depend directly on the value in memory, this is a pretty big deal. I have tried to do a couple tests, and I have come to the conclusion that, I would have to literally move a bunch of blocks around in memory, which is absolutely out of question since I will break too many things if I do that. So I found a compromise for the time being looking like this: hijack_start lda trackn_audctl,x ; workaround tentative... if not 0, it may have the wanted value... ora v_audctl ; the old value will be combined to the new one, at worst, it will be 1 frame late tay ; backup to index y for quick transfer between steps And while this appears to help for a bunch of things, such as 15khz or 16-bit when the instrument itself has the wanted values, anything else will still be 1 frame late like before. Not ideal, but that seems like an acceptable workaround for the musicians who know what they are doing. I see this rough compromise as an hybrid of my older method, and the Patch 16 Beta5 improvements, pretty much So to make it short: if the instrument has the wanted AUDCTL value -> good, trackn_audctl has the value we need, go directly to the table hijack. if the instrument does not have the wanted AUDCTL value -> no big deal, the next frame will cover your back with v_audctl instead. Thank you for listening to my rambles, I just like to try dumb things out, if they work, I'm okay with that, hahaha 2 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 It fits and sits This time I did not need to sacrifice all my 16-bit code... more on that later. So yeah, that Distortion 2 hack can work with everything I did earlier, and fit in memory this time. There is only a few compromises over the code I have for the visual player, but it's really nothing major. If that works, why not Generator Evening.obx 7 Quote Link to comment Share on other sites More sharing options...
emkay Posted September 5, 2021 Share Posted September 5, 2021 (edited) Remember how often I was suggesting this missing link with gen 2? Finally someone was listening, see the result. The result needs less resources and leaves space for other stuff. Pitch correction is very timing friendly as well. Btw. Is the recording from the real thing? Edited September 5, 2021 by emkay 1 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 5, 2021 Share Posted September 5, 2021 (edited) Fixed some oversights from last night in my memory change detection code (I'll probably backport the unified return to the main sa_c6502.dll). C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: 00 loc 3183 cur: 52 prev: 00 loc 3184 cur: 41 prev: 00 loc 3185 cur: 43 prev: 00 loc 3186 cur: 4b prev: 00 loc 3187 cur: 45 prev: 00 loc 3188 cur: 52 prev: 00 loc 3189 cur: 20 prev: 00 loc 35fc cur: 60 prev: 00 C6502_JSR: TRACKER tag found, loading file at $3182 load_raw: read tracker.obx and skip 6 bytes load_raw: injected 2264 bytes C6502_JSR: $35FC = 4c Look, there's our $35FC again. Your stripped Rmt.exe does not contain that RTS instruction (its all zeroes after the TRACKER tag), but Rmt.exe overwrote it. It used to be $4C which is a JMP. I'll see with a different initial memory fill, if some bytes are set to zero, too. Otherwise, this could be our solution! Edit: C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: ff T loc 3183 cur: 52 prev: ff R loc 3184 cur: 41 prev: ff A loc 3185 cur: 43 prev: ff C loc 3186 cur: 4b prev: ff K loc 3187 cur: 45 prev: ff E loc 3188 cur: 52 prev: ff R loc 3189 cur: 20 prev: ff space loc 35fc cur: 60 prev: ff C6502_JSR: TRACKER tag found, loading file at $3182 load_raw: read tracker.obx and skip 6 bytes load_raw: injected 2264 bytes C6502_JSR: $35FC = 4c It seems it's the only byte overwritten by Rmt.exe. Edit 2: New version at https://github.com/ivop/rmt-sa-libs/tree/main/real/sa_c6502_inject It now patches the RTS back in after loading the tracker.obx binary. Does it sound better to you? It does to me Edit 3: If this fixes the previous problem, then I will implement a proper FFFF loader instead of the raw loader that's in place right now. That way, besides the current rmtplayr memory space, you can load new code or data anywhere you want, and make calls to that Edited September 5, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 3 hours ago, ivop said: Fixed some oversights from last night in my memory change detection code (I'll probably backport the unified return to the main sa_c6502.dll). C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: 00 loc 3183 cur: 52 prev: 00 loc 3184 cur: 41 prev: 00 loc 3185 cur: 43 prev: 00 loc 3186 cur: 4b prev: 00 loc 3187 cur: 45 prev: 00 loc 3188 cur: 52 prev: 00 loc 3189 cur: 20 prev: 00 loc 35fc cur: 60 prev: 00 C6502_JSR: TRACKER tag found, loading file at $3182 load_raw: read tracker.obx and skip 6 bytes load_raw: injected 2264 bytes C6502_JSR: $35FC = 4c Look, there's our $35FC again. Your stripped Rmt.exe does not contain that RTS instruction (its all zeroes after the TRACKER tag), but Rmt.exe overwrote it. It used to be $4C which is a JMP. I'll see with a different initial memory fill, if some bytes are set to zero, too. Otherwise, this could be our solution! Edit: C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: ff T loc 3183 cur: 52 prev: ff R loc 3184 cur: 41 prev: ff A loc 3185 cur: 43 prev: ff C loc 3186 cur: 4b prev: ff K loc 3187 cur: 45 prev: ff E loc 3188 cur: 52 prev: ff R loc 3189 cur: 20 prev: ff space loc 35fc cur: 60 prev: ff C6502_JSR: TRACKER tag found, loading file at $3182 load_raw: read tracker.obx and skip 6 bytes load_raw: injected 2264 bytes C6502_JSR: $35FC = 4c It seems it's the only byte overwritten by Rmt.exe. Edit 2: New version at https://github.com/ivop/rmt-sa-libs/tree/main/real/sa_c6502_inject It now patches the RTS back in after loading the tracker.obx binary. Does it sound better to you? It does to me Edit 3: If this fixes the previous problem, then I will implement a proper FFFF loader instead of the raw loader that's in place right now. That way, besides the current rmtplayr memory space, you can load new code or data anywhere you want, and make calls to that Incredible! Will give it a go a bit later today once I'm done with few things I need to do at home, and that improved Distortion 2 hack I will finish, after I showed it working alongside the currently in progress hijack improvements I rambled about last night. Being able to get all of the addresses under control should make all of everything working, and cross compatible with the more ambitious changes I wanted to do for some time now regarding the entire memory map involving the Visual Player prelimineray tests I was able to confirm were good. Remember the rmtplayr.a65 mentioning the memory addresses MUST be exactly what they were shown there? I can tell you this is not absolutely necessary, it is a recommendation more than a limitation, as far as I could tell, and I will prove it some time soon with a new re-arranged layout. Being able to use much larger memory pages will benefit a TON for a lot of things, mainly, the notes tables. No more getting stopped by the 256 bytes limitation (+128 bytes of my own from optimised volume table), I could easily point to any memory page and their respective high/low bytes if I wanted to 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 7 hours ago, emkay said: Remember how often I was suggesting this missing link with gen 2? Finally someone was listening, see the result. The result needs less resources and leaves space for other stuff. Pitch correction is very timing friendly as well. Thanks! I'm really happy how well this has been working so far. Much much better than anticipated when I began from very rudimentary hex edited tables without any real improvement compared to the RMT2LZSS results. Things have definitely branched outside of the original RMT code now, and maintaining backwards compatibility will become difficult as a result, but we will see. I have to say, manually setting the 1.79mhz clock for Distortion 2 worked very well already, but this hack really shows the power. Now if we had a way to literally create a new envelope specifically for AUDCTL, we'd be in absolute control, much like the .erti parameters from RMT2LZSS, except in a much more friendly music tracker interface with real time response. 7 hours ago, emkay said: Btw. Is the recording from the real thing? Nope, It was from Altirra emulator, but I am very confident this should sound much of the same. I can get a hardware recording for the sake of it later tonight just to see how that compares, but as far as I know, this will be very close to it That will also give me another shot at testing my custom Visual Player code on hardware and see if what I did is working correctly on Hardware, I believe it will be fine, but we never know. 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 5, 2021 Share Posted September 5, 2021 (edited) Here's the XEX loader: (we need it anyway ) C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: 00 loc 3183 cur: 52 prev: 00 loc 3184 cur: 41 prev: 00 loc 3185 cur: 43 prev: 00 loc 3186 cur: 4b prev: 00 loc 3187 cur: 45 prev: 00 loc 3188 cur: 52 prev: 00 loc 3189 cur: 20 prev: 00 loc 35fc cur: 60 prev: 00 C6502_JSR: TRACKER tag found, load tracker.obx load_xex: load tracker.obx load_xex: load 3182 - 3a59 load_xex: injected 2264 bytes load_xex: load 0600 - 060b load_xex: injected 12 bytes load_xex: load 0680 - 0693 load_xex: injected 20 bytes load_xex: load 3182 - 3a59 load_xex: injected 2264 bytes The tracker.obx in the git repo is Vinscool's player, "HELLO, WORLD" at $0600, "GOODBYE, CRUEL WORLD" at $0680, and the player again. Some segments are FFFF strt enda, and some later skip the FFFF marker, which is not needed anymore. Just feed it a proper Atari .xex file and it all should work Edited September 5, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 Alright so here's this Distortion 2 hack updated: - Optimised a bunch of the main hijack code, now there is Distortion 2 1.79mhz, Distortion A and C 15khz and 16-bit code fitting!* - Replaced the 16-bit bass tables for the Clarinet Reverse-16 setup, because this one especially harmonises nicely to the Distortion 2. * There were a few compromises in order to fit everything into the smaller possible binary (MONO player). - The 16-bit code was reduced to only check for Join1+2 or Join3+4 bits, but as long as the combination of Join and 1.79mhz is enabled in instruments, it will work just as good for Reverse-16 sounds. - v_audctl is still used alone for the main checks, so there will be a few occasions where a frame may be skipped, but this is barely noticeable in most situations anyway Now I'm going to try out that new .dll for the .obx loader and see how it goes RMT Distortion 2 Hack v2.zip 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 5, 2021 Author Share Posted September 5, 2021 (edited) 15 minutes ago, ivop said: Here's the XEX loader: (we need it anyway ) C6502_Initialise: memory is zeroed C6502_JSR: tracker memory changed (0) loc 3182 cur: 54 prev: 00 loc 3183 cur: 52 prev: 00 loc 3184 cur: 41 prev: 00 loc 3185 cur: 43 prev: 00 loc 3186 cur: 4b prev: 00 loc 3187 cur: 45 prev: 00 loc 3188 cur: 52 prev: 00 loc 3189 cur: 20 prev: 00 loc 35fc cur: 60 prev: 00 C6502_JSR: TRACKER tag found, load tracker.obx load_xex: load tracker.obx load_xex: load 3182 - 3a59 load_xex: injected 2264 bytes load_xex: load 0600 - 060b load_xex: injected 12 bytes load_xex: load 0680 - 0693 load_xex: injected 20 bytes load_xex: load 3182 - 3a59 load_xex: injected 2264 bytes The tracker.obx in the git repo is Vinscool's player, "HELLO, WORLD" at $0600, "GOODBYE, CRUEL WORLD" at $0680, and the player again. Some segments are FFFF strt enda, and some later skip the FFFF marker, which is not needed anymore. Just feed it a proper Atari .xex file and it all should work Man this is PERFECT! Now I cannot even tell anything is wrong in the playback! It's a perfect match to what is expected as far as my 5 minutes test seem to show me there Now I will finally be able to move some memory map around and use larger tables, fuck YES Thank you so much, this is a HUGE breakthrough! Soon I will no longer have to make stand alone versions like the Distortion 2 hack back, just swap in and out the .obx to use ? Edited September 5, 2021 by VinsCool 2 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 6, 2021 Author Share Posted September 6, 2021 (edited) Good news everyone. I've done some preliminary tests moving tables (notes, notes map, vibrato, volume, etc) to the $B000 location in memory, and so far it's working using the .obx loader. I've only got a small issue related to the AUDCTL values related to all of this, but I will figure it out a later time. For now it would just get stuck on FF, and manually setting 00 in the code makes it just stay 00... which is thankfully better than garbage for the time being, hehe That is pretty much the first thing I wanted to do for a while, and it does work, with few things broken, but I'll figure it out, hopefully. [Edit] Actually I just remembered I could just look at an earlier version .lst and go with the same addresses... This was the output from Patch 16 Beta 5, maybe I can try to get these addresses back?, hmmmm 1538 ELI STEREOMODE==1 ; L1 L2 L3 L4 R1 R2 R3 R4, STEREO (Mode 1) 1539 39C2 A0 FF ldy #$ff 1540 = 39C3 v_audctl2 equ *-1 1541 39C4 AD 64 31 lda trackn_audf+0+4 1542 39C7 AE 60 31 ldx trackn_audf+0 1543 39CA 8D 10 D2 sta $d210 1544 39CD 8E 00 D2 stx $d200 1545 39D0 AD 6C 31 lda trackn_audc+0+4 1546 39D3 AE 68 31 ldx trackn_audc+0 1547 39D6 8D 11 D2 sta $d211 1548 39D9 8E 01 D2 stx $d201 1549 39DC AD 65 31 lda trackn_audf+1+4 1550 39DF AE 61 31 ldx trackn_audf+1 1551 39E2 8D 12 D2 sta $d212 1552 39E5 8E 02 D2 stx $d202 1553 39E8 AD 6D 31 lda trackn_audc+1+4 1554 39EB AE 69 31 ldx trackn_audc+1 1555 39EE 8D 13 D2 sta $d213 1556 39F1 8E 03 D2 stx $d203 1557 39F4 AD 66 31 lda trackn_audf+2+4 1558 39F7 AE 62 31 ldx trackn_audf+2 1559 39FA 8D 14 D2 sta $d214 1560 39FD 8E 04 D2 stx $d204 1561 3A00 AD 6E 31 lda trackn_audc+2+4 1562 3A03 AE 6A 31 ldx trackn_audc+2 1563 3A06 8D 15 D2 sta $d215 1564 3A09 8E 05 D2 stx $d205 1565 3A0C AD 67 31 lda trackn_audf+3+4 1566 3A0F AE 63 31 ldx trackn_audf+3 1567 3A12 8D 16 D2 sta $d216 1568 3A15 8E 06 D2 stx $d206 1569 3A18 AD 6F 31 lda trackn_audc+3+4 1570 3A1B AE 6B 31 ldx trackn_audc+3 1571 3A1E 8D 17 D2 sta $d217 1572 3A21 8E 07 D2 stx $d207 1573 3A24 A9 FF lda #$ff 1574 = 3A25 v_audctl equ *-1 1575 3A26 8C 18 D2 sty $d218 1576 3A29 8D 08 D2 sta $d208 [Edit2] okay nevermind, it's fixed, I literally just ORG'd the 2 v_audctl values in the zero page, then loaded them directly o.o Well guess that's pretty much it, everything works, now I can go on the real fun: adding tuning tables! Finally Edited September 6, 2021 by VinsCool 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 6, 2021 Share Posted September 6, 2021 2 hours ago, VinsCool said: Now I cannot even tell anything is wrong in the playback! I was hoping for that! It took a few days to figure it out, and in the end it was just that single byte at $35FC 29 minutes ago, VinsCool said: Well guess that's pretty much it, everything works, now I can go on the real fun: adding tuning tables! Finally Looking forward to that! Most of the 6502 address space is free to use now 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 6, 2021 Author Share Posted September 6, 2021 1 minute ago, ivop said: I was hoping for that! It took a few days to figure it out, and in the end it was just that single byte at $35FC Glad this worked out indeed! 1 minute ago, ivop said: Looking forward to that! Most of the 6502 address space is free to use now I am in a really good mood right now with this stuff! So far everything works, I'm now loading all the RMT tables (used to be at $3182 to $33FF basically!) from $B000 without any problem as far as I could tell. 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 6, 2021 Author Share Posted September 6, 2021 BIG update right there! RMT Patch 16 Beta6: - Brand new sa_c6502.dll by ivop, featuring a built-in Tracker binary loader, simply drop a tracker.obx in the .exe folder and run! - Moved all tables to $B000, this will much more data to be available in memory, and future proof the space when it will be needed later - Rewrote the entire hijack code again, this time hopefully for a long with the current memory map - ALL modes can now have their own set of tables, making a LOT of the hijacked shit very easy to handle now, at a cost of extra memory - Currently, 64khz (default), 15khz, 1.79mhz and 16-bit (via AUDCTL $50 or $28) will have their respective tables handled automatically, with as many slots as necessary - All tables can FINALLY use the full 64 bytes when the tuning allows it, since the memory page is a new one between modes - Added a handful of new tables as a test, many will need retuning, but as a proof of concept, they seem to work perfectly - Preliminary support for these tables added: Distortion 2 64khz, Distortion A 1.79mhz, Distortion C 1.79mhz, Distortion E 1.79mhz - Improved the Distortion A and C 15khz tables to make the full 64 bytes of tuning available, that will get rid of the disappointing cut around C-5 to the next table in memory, making that one note unavailable - Improved the Distortion A and E 64khz to use the full 64 bytes of tuning each, with the best possible frequencies in the highest pitch, so there shouldn't be any random silence now - 16-bit currently only has 1 table as an example, the nice Reverse-16 Clarinet, like the earlier Patch 16 versions, use with the Join+1.79mhz AUDCTL bits, they will use the correct table automatically in the respective channels - Made several table slots dummy entries, due to missing data, but these will be added later, there is a bit of retuning to do for many combinations, aaarghhhh XD - Virtually, the user might not see any difference between this version and the Patch 16 Beta5 release, which is in my opinion, a good thing! I must say again, massive thanks to @ivop for the binary loader. None of this would have been possible without this breathrough! RMT Patch 16 Beta6.zip 6 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 6, 2021 Share Posted September 6, 2021 13 hours ago, VinsCool said: I am in a really good mood right now with this stuff! So was I when I finally found out how to get things working correctly. It was a real disappointment when it didn't work at first. Now I'm thinking about Pokey again 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 6, 2021 Share Posted September 6, 2021 (edited) Looking forward to what you are going to do with the new XEX loader. In the end it should sync with RMT2LZSS I suppose? As for Pokey, here are some options: 1. try to apply all patches since 2003 to sa_pokey.dll 2. start over with current atari800 pokey.c and pokeysnd.c About the same level of difficulty, and you'll end up, with circa 2014 atari800 pokey emulation. Considering the code base changes @Wrathchild already mentioned, I think option 2 is less work. 3. reimplement apokeysnd in C instead of Cito? Or learn Cito 4. try to extract the pokey emulation and resampling from Altirra. Extremely hard, and C++. 5. start all over from scratch, and use Altirra source code and hardware manual as a guide as to how implement everything. Or, something I have been pondering over for years, implement a "pokey bridge" to a running emulator, either atari800 or Altirra. Well, at first I thought about a full blown API to run code in the emulator, too, but that's not needed anymore. So just pokey. I imagine a "pokey bridge" as a local socket which receives commands to change the pokey registers. Like packets of 10 registers. $D200-D208 and $D20F. Once the emulator is running with pokey bridge enabled, you can connect to that socket from sa_pokey.dll, and send packets as soon as Process() is called. Process() itself returns a silent buffer, to not disturb the sound of the emulator. I can add this to atari800, but it would be better if @phaeron chipped in and implemented this in Altirra Edit: and it would need a way to accommodate for stereo. Perhaps the easiest "protocol" over the pokey bridge would be just FFFF start end, and then data. Could be FF FF 00 D2 08 D2 and nine bytes of data, but also SKCTL, or a second pokey. Always start with FFFF, on which you can sync, et cetera... Edited September 6, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 6, 2021 Author Share Posted September 6, 2021 I think an updated sa_pokey.dll would be a really good start. I'm actually curious to compare how it performs vs 2003 sa_pokey.dll vs Altirra vs Hardware Quote Link to comment Share on other sites More sharing options...
ivop Posted September 6, 2021 Share Posted September 6, 2021 1 minute ago, VinsCool said: I think an updated sa_pokey.dll would be a really good start. I'm actually curious to compare how it performs vs 2003 sa_pokey.dll vs Altirra vs Hardware You can hear how it would perform by running an RMT player binary, or an RMT2LZSS binary, on the current atari800. It is not as good as Altirra. Not by a long shot. @emkay says Altirra still doesn't match real hardware in some cases, but you have to ask him to explain where and when 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted September 6, 2021 Author Share Posted September 6, 2021 6 minutes ago, ivop said: You can hear how it would perform by running an RMT player binary, or an RMT2LZSS binary, on the current atari800. It is not as good as Altirra. Not by a long shot. @emkay says Altirra still doesn't match real hardware in some cases, but you have to ask him to explain where and when I've personally done hardware vs Altirra comparisons with my stuff, it's INCREDIBLY close as far as I am concerned. Atari800 I've only used a crappy free mobile port and it was pretty poor indeed, but I blamed this on the mobile port being poor more than the emulation itself. Now I'm actually curious to compare... 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted September 6, 2021 Share Posted September 6, 2021 (edited) 11 minutes ago, VinsCool said: I've personally done hardware vs Altirra comparisons with my stuff, it's INCREDIBLY close as far as I am concerned. Atari800 I've only used a crappy free mobile port and it was pretty poor indeed, but I blamed this on the mobile port being poor more than the emulation itself. Now I'm actually curious to compare... Well, clone https://github.com/atari800/atari800, install the proper SDL development libraries with apt-get, run ./configure, (check errors and install more libraries and -dev packages ), and run make. Or download a package from https://github.com/atari800/atari800/releases, although I won't just install one of them .deb packages. It might F-up your distro. If you don't want to compile from source and install in /usr/local/., I'd go for the win32 packages and run it in a wine sandbox. OR, perhaps your distro already has a pretty recent atari800 in its repo already. Likely. apt-get install atari800, and after that put the proper OS and BASIC ROMS in the right directory Edited September 6, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
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.