ivop Posted August 30, 2021 Share Posted August 30, 2021 (edited) Also looked over your rmtplayr source. Looks nice! It could be beneficial to increase the readability slightly with indentation within the if/else/endif blocks of code, and perhaps "upgrade" to mads syntax. And I have a thing for lines always being less than 80 characters BTW nice that you added the Microsoft DLLs to the archive. No need for winetricks to run it in a sandbox Edited August 30, 2021 by ivop 1 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 6 hours ago, emkay said: Hm... Is it possible to set gen.2 for one position on the Envelope, and AUDCTL gets turned from basic clocking to 1.79MHz clocking for that time? This is possible, actually, and probably very easy to achieve, in fact. All I need to do is add a few lines of code during the initial hijack phase, to detect slot 2, then jump ahead and ora the 1.79mhz value needed into trackn_audctl, or maybe v_audctl directly, and that should in theory allow the use of Distortion 2 with 1.79mhz clock automatically. This also reminds me how I need to find a more elegant solution for handling 16-bit code in a more robust way, i suppose I could just re-introduce the Distortion 6 approach and run the checks from my code, but that would also cause some other things to break again. So I am not sure for now... Now the main problem, however, is that I currently wouldn't be able to fit any extra code in the rmtplayr due to how the .exe itself is built, but that should work without any problem if I had no limitation for that part. That brings another thing that I really want to understand: how could I expand the .exe without breaking it, in order to fit larger player binaries? Currently, I am limited to 2270 bytes for each one of TRACKER and STEREO binaries (they are virtually identical except for 1 specific thing that breaks the tracker side if omitted), and 2002 bytes for the MONO binary. 4 hours ago, ivop said: Are the MONO, STEREO and TRACKER binaries in consecuetive memory in the Rmt.exe binary? If so, perhaps you can merge them? Yes and no, unfortunately. That was something that I would totally do if I was able to, but that would absolutely require the full RMT source code, something that is not available to the public as far as I am aware. For now, my best bet is hacking everything from the inside out, by hex editing player binaries back into the .exe once they were built. 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 2 hours ago, ivop said: Also looked over your rmtplayr source. Looks nice! It could be beneficial to increase the readability slightly with indentation within the if/else/endif blocks of code, and perhaps "upgrade" to mads syntax. And I have a thing for lines always being less than 80 characters Thank you! This makes me happy to read, since I am still much of a beginner programmer. I am well aware there is a lot of improvements that are possible. There is a lot of the original code from Raster I did not touch either, so this is the main reason why so much syntax and format difference exists currently. I plan to get in a more indepth cleanup sometime, and add comments to all the code I could be absolutely sure I can understand, but for now, it does work as it is No idea yet for MADS syntax, I have been using XASM since my earliest dabs at code (around the month of June, actually!), and I am still learning a lot of the logic behind programming itself, as well as some more advanced tricks to achieve the things I want. Not published yet but the RMT Visual Player I am also working on has gone through a much more indepth rewrite, but is still work in progress, and I have learned a lot from it alone. I will continue with this one too in due time, and hopefully I could make more code to be easier to understand. I have become pretty familiar with the way RMT work now to hopefully find new approaches to get some things done in a different way, only time will tell Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 3 hours ago, ivop said: BTW nice that you added the Microsoft DLLs to the archive. No need for winetricks to run it in a sandbox I am personally a WINE user so I figured this would save some time to most people who attempted to run it on their Linux/Mac machine. Once all the necessary files are present, I can confirm RMT works perfectly through WINE 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted August 30, 2021 Share Posted August 30, 2021 10 minutes ago, VinsCool said: Yes and no, unfortunately. That was something that I would totally do if I was able to, but that would absolutely require the full RMT source code, something that is not available to the public as far as I am aware. For now, my best bet is hacking everything from the inside out, by hex editing player binaries back into the .exe once they were built. So that means, yes they are in consecutive memory, but no you can't merge them? If that's the case, we might be able to find the pointers and length variables in the binary, and point them all to the same player. 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted August 30, 2021 Share Posted August 30, 2021 (edited) 17 minutes ago, VinsCool said: No idea yet for MADS syntax, I have been using XASM since my earliest dabs at code (around the month of June, actually!), and I am still learning a lot of the logic behind programming itself, as well as some more advanced tricks to achieve the things I want. @tebe's mads assembler is compatible with xasm syntax, as far as I know. I always compile the rmtplayr source file with mads. From the manual: IFT [.IF] expression ELS [.ELSE] ELI [.ELSEIF] expression EIF [.ENDIF] between brackets is the mads syntax. And http://mads.atari8.info/mads_eng.html#warun And indentation to increase readability Edited August 30, 2021 by ivop 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 3 minutes ago, ivop said: So that means, yes they are in consecutive memory, but no you can't merge them? What I mean is, they are in consecutive order in the .exe, being: TRACKER, MONO then STEREO binaries. But they are NOT one right after the other. There are things sitting between each ones of them, including the simple player used for XEX and SAP exports, that literally just slap either one of the MONO or STEREO binaries it iself, and finally slap a stripped .rmt module at the end of the file. That is simply to deep to dig from a hacking perspective, especially from my own level of skills that is not very advanced yet. 8 minutes ago, ivop said: If that's the case, we might be able to find the pointers and length variables in the binary, and point them all to the same player. That was precisely what I had in mind! Nice to see we think alike The only problem, is to find how much the .exe could be expanded to get more information being held into it, without breaking the entire program. If we could just have a buffer of 1kb larger per player binary, this would make things a lot more easier to manage and add. I have to admit, however, I do enjoy the challenge of getting my code to fit in the smallest amount of space available, it really had made me think outside of the box to get my code fitting. My first iteration of the new hijack code that I first used in my visual player last week was about 50 bytes larger, I really was impressed by the optimisation I was able to do for it Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 (edited) 11 minutes ago, ivop said: @tebe's mads assembler is compatible with xasm syntax, as far as I know. I always compile the rmtplayr source file with mads. From the manual: IFT [.IF] expression ELS [.ELSE] ELI [.ELSEIF] expression EIF [.ENDIF] between brackets is the mads syntax. And http://mads.atari8.info/mads_eng.html#warun And indentation to increase readability I see, so it would make a bunch of the IFT ELS EIF blocks a lot easier to read if I understand? I personally am okay right now with the way it is done currently, but I agree it would be very nice to be able to get a more readable block of code on the long run. These conditional assembler conditions are pretty nice to have, honestly. This made working around the specific set of features between TRACKER, MONO and STEREO binaries very easily. In the near future once I update the Visual Player again, I will add more IFT statements for the parts that are specific for the player as well, so that should then become much easier to manage as a single project Edited August 30, 2021 by VinsCool typo 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted August 30, 2021 Share Posted August 30, 2021 11 minutes ago, VinsCool said: What I mean is, they are in consecutive order in the .exe, being: TRACKER, MONO then STEREO binaries. But they are NOT one right after the other. There are things sitting between each ones of them, including the simple player used for XEX and SAP exports, that literally just slap either one of the MONO or STEREO binaries it iself, and finally slap a stripped .rmt module at the end of the file. So if I understand it correctly, there's a block of 6502 code in the Rmt.exe binary that has all the players, including players for export? And the Rmt program either runs or exports parts of it? 11 minutes ago, VinsCool said: That is simply to deep to dig from a hacking perspective, especially from my own level of skills that is not very advanced yet. I might be able to find the pointers and lengths in the binary. 11 minutes ago, VinsCool said: I have to admit, however, I do enjoy the challenge of getting my code to fit in the smallest amount of space available, it really had made me think outside of the box to get my code fitting. My first iteration of the new hijack code that I first used in my visual player last week was about 50 bytes larger, I really was impressed by the optimisation I was able to do for it Yes, that's the joy of sizecoding I'm really impressed by how far you have come from starting your "Trying to make some Pokey music" thread up to now. You even learned 6502 assembly 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted August 30, 2021 Share Posted August 30, 2021 18 minutes ago, VinsCool said: I see, so it would make a bunch of the IFT ELS EIF blocks a lot easier to read if I understand? IMHO, yes 18 minutes ago, VinsCool said: I personally am okay right now with the way it is done currently, but I agree it would be very nice to be able to get a more readable block of code on the long run. I'm not trying to persuade you to use a different assembler, but I just think mads syntax is more readable. IFT. Why the T? What does it mean? 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 35 minutes ago, ivop said: So if I understand it correctly, there's a block of 6502 code in the Rmt.exe binary that has all the players, including players for export? And the Rmt program either runs or exports parts of it? That is, more or less, what I understand, yeah. They just are scattered all over the place. 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. 37 minutes ago, ivop said: I might be able to find the pointers and lengths in the binary. That would honestly be pretty awesome, if we can then be able to insert binaries without size limits imposed by the current .exe format, I would be able to experiment with even more things very easily. Having used the Visual Player for some time helped a lot to test several features, but being able to truly experiment in real time within the tracker itself would be even better. 40 minutes ago, ivop said: Yes, that's the joy of sizecoding I'm really impressed by how far you have come from starting your "Trying to make some Pokey music" thread up to now. You even learned 6502 assembly Thank you very much! I never expected I would have gone this far after only a few years, and that makes me even more excited to push the limits even further, since I can actually code some things myself now 31 minutes ago, ivop said: IMHO, yes I'm not trying to persuade you to use a different assembler, but I just think mads syntax is more readable. IFT. Why the T? What does it mean? Okay, that makes sense I am still learning how that stuff works, so I don't know what will happen next. if MADS syntax produce code that is easier to read, I will for sure learn how to make use of it sometime. 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 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 30, 2021 Author Share Posted August 30, 2021 So I pretty much confirmed the Beta5 code is all functional, I'll now port it back to the visual player project, and finally merge them for once and for all Before I do so, I wanted to share the code I did make first for the Visual Player, before compacting things as much as possible for fitting inside of RMT.exe. That was quite a lot more to process for sure, but at the moment I wrote that part, it made sense to me, and worked about as good as expected. There was no Stereo support yet, so the way this worked was limited to a single POKEY, but it still worked fine for that purpose. Also I can show the magic behind the Two-Tone Filter when I did make use of it, it really was not very complicated to implement, but that part is exclusive to the visual player currently As you can all see, this certainly did the job, but it had a lot of things that could have been compacted to take less space, right? That also was too large to even fit the rmt.exe player binaries limitation either, so I had to come up with a better way. pp2scont sta tmp lda reg2 and #$0e sta tmp2 ; temporary register used for the next part ; Start of hijack mess... again pp2scont_check_skctl cmp #$06 ; "Distortion 6", or rather, Slot 6 bne skctlskip ; Skip the hijack, and runs the failsafe code to make sure it does not keep incorrect data in memory lda #$8B ; Two-Tone mode, affects Channel 1 and 2 jmp skctlstore skctlskip lda #3 ; Failsafe to make sure the SKCTL register is always in normal mode in any case skctlstore sta v_skctl IFT STEREOMODE==1 sta v_skctl2 ; Continue like normal from here EIF pp2scont_check_channel_order lda v_audctl ; Load AUDCTL value into the accumulator tay ; backup to index y since it's available cpx #$03 beq hijack_ch4 ; x=03, Channel 4, unique AUDCTL features priority: Join ch3+4 cpx #$02 beq hijack_ch3 ; x=02, Channel 3, unique AUDCTL features priority: 1.79mhz ch3 cpx #$01 beq hijack_ch2 ; x=01, Channel 2, unique AUDCTL features priority: Join ch1+2, hipass filter ch2+4 cpx #$00 beq hijack_ch1 ; x=00, Channel 1, unique AUDCTL features priority: 1.79mhz ch1, hipass filter ch1+3 jmp pp2scont_normal ; No hijack, carry on like normal, a failsafe jump in case shit goes wrong hijack_ch4 and #$08 ; Join ch3+4? beq hijack_15khz_check ; no, skip the next check as well hijack_ch4_p2 tya ; load AUDCTL backup and #$20 ; 1.79mhz Ch3? beq hijack_15khz_check ; no, skip to 15khz check bne hijack16bit_hi ; yes, continue hijack_ch3 and #$20 ; 1.79mhz Ch3? beq hijack_15khz_check ; no, skip the next check as well hijack_ch3_p2 tya ; load AUDCTL backup and #$08 ; Join ch3+4? beq hijack_15khz_check ; no, skip to 15khz check bne hijack16bit_lo ; yes, continue hijack_ch2 and #$10 ; Join ch1+2? beq hijack_15khz_check ; no, skip the next check as well hijack_ch2_p2 tya ; load AUDCTL backup and #$40 ; 1.79mhz Ch1? beq hijack_15khz_check ; no, skip to 15khz check bne hijack16bit_hi ; yes, continue hijack_ch1 and #$40 ; 1.79mhz Ch1? beq hijack_15khz_check ; no, skip the next check as well hijack_ch1_p2 tya ; load AUDCTL backup and #$10 ; Join ch1+2? beq hijack_15khz_check ; no, skip to 15khz check bne hijack16bit_lo ; yes, continue hijack_15khz_check tya ; load AUDCTL backup and #$01 ; 15khz mode? beq pp2scont_normal ; nope, no hijack, carry on like normal lda tmp2 ; load RMT slot backup tay ; keep in memory for later parts cmp #$0A ; Distortion A? beq pp2scont_hijack15khz ; yes, continue cmp #$0C ; Distortion C bne pp2scont_normal ; nope, no hijack, carry on like normal pp2scont_hijack15khz_C lda #>hijacktab ; Move the tables pointer to the hijacked location, in order to load the right values sta nr+1 ; This is exclusively for the Distortion C 15khz table since it is outside of frqtab currently tya ; load RMT slot backup pp2scont_hijack15khz lda tabbeganddistor_extra,y sta nr lda tmp ora tabbeganddistor_extra+1,y jmp pp2scont_finished ; Continue like normal right there hijack16bit_hi lda tmp2 ; load RMT slot backup tay ; keep in memory for later parts cmp #$0A ; Distortion A bne pp2scont_normal ; No hijack, carry on like normal lda #>junktab ; Move the tables pointer to the hijacked location, in order to load the right values sta nr+1 ; This is exclusively for the Distortion A 16-bit tables since it is outside of frqtab currently lda tabbeganddistor_extra-2,y sta nr lda tmp ora tabbeganddistor_extra-1,y jmp pp2scont_finished ; Continue like normal right there hijack16bit_lo lda tmp2 ; load RMT slot backup tay ; keep in memory for later parts cmp #$0A ; Distortion A bne pp2scont_normal ; No hijack, carry on like normal lda #>junktab ; Move the tables pointer to the hijacked location, in order to load the right values sta nr+1 ; This is exclusively for the Distortion A 16-bit tables since it is outside of frqtab currently lda tabbeganddistor_extra-4,y sta nr lda #0 ; mute ;lda tmp ; PoP exclusive hack: keep volume value for Reverse-16 output ;ora #$C0 ; PoP exclusive hack: change the Distortion from A to C for the Clarinet ora tabbeganddistor_extra-3,y jmp pp2scont_finished ; Continue like normal right there ; End of hijack mess pp2scont_normal ldy tmp2 lda tabbeganddistor,y sta nr lda tmp ora tabbeganddistor+1,y pp2scont_finished sta trackn_audc,x So this is the revised code I ended up doing to fit inside the limits from RMT.exe, this may look a bit all over the place, but hopefully, most of the same process was done for the tables hijacking, and it works pretty much as good as expected. This is definitely not perfect either, I admit, but this is still a lot more compact than my earlier code above, and achieves pretty much exactly the same thing, at the end IFT STEREOMODE==1 pp2scont sta tmp ; backup the volume value txa and #4 ; second POKEY? The value of index x would be between 4 to 8 included beq pp2scont_mono ; it is not, therefore, the first chip is being updated jmp pp2scont_stereo ; jump to the stereo version of the next steps ELS pp2scont sta tmp ; backup the volume value EIF pp2scont_mono lda reg2 and #$0e ; clear everything but the RMT slot value sta tmp2 ; temporary backup cmp #$0A ; slot A? bne hijack_p6 ; nope, skip the 16-bit checks entirely hijack_start lda v_audctl ; global AUDCTL value tay ; backup to index y for quick transfer between steps hijack_p0 and #$08 ; join 3+4? beq hijack_p3 ; nope, skip to the next step hijack_p1 tya ; get the AUDCTL backup in the accumulator and #$20 ; 1.79mhz ch3? beq hijack_p3 ; nope, skip to the next step hijack_p2 cpx #$03 ; channel 4? beq hijack_p10 ; yes, jump straight to the next part cpx #$02 ; channel 3? beq hijack_p11 ; yes, jump straight to the next part hijack_p3 tya ; get the AUDCTL backup in the accumulator and #$10 ; join 1+2? beq hijack_p6 ; nope, skip to the next step hijack_p4 tya ; get the AUDCTL backup in the accumulator and #$40 ; 1.79mhz ch1? beq hijack_p6 ; nope, skip to the next step hijack_p5 cpx #$01 ; channel 2? beq hijack_p10 ; yes, jump straight to the next part cpx #$00 ; channel 1? beq hijack_p11 ; yes, jump straight to the next part hijack_p6 lda v_audctl ; load the global AUDCTL in the accumulator, again, in case the initial checks were skipped ldy tmp2 ; load the RMT slot backup in index y and #$01 ; 15khz? beq no_hijack ; nope, skip the entire hijack process hijack_p7 cpy #$0A ; slot A? beq hijack_p9 ; yes, skip the pointer hijack hijack_p7a cpy #$0C ; slot C? bne no_hijack ; nope, skip the entire hijack process hijack_p8 lda #>hijacktab ; hijack the pointer for lookup tables to load sta nr+1 ; write the high byte in memory ; used for both distortion A and distortion C 15khz tables, the latter one uses an hijacked pointer hijack_p9 lda tabbeganddistor_extra,y sta nr lda tmp ora tabbeganddistor_extra+1,y bne pp2scont_finished ; bne is used since it's 100% unlikely to be 0 ; used for distortion A 16-bit, high byte hijack_p10 lda #>junktab ; hijack the pointer for lookup tables to load sta nr+1 ; write the high byte in memory ldy tmp2 ; load the RMT slot value lda tabbeganddistor_extra-2,y sta nr lda tmp ora tabbeganddistor_extra-1,y bne pp2scont_finished ; bne is used since it's 100% unlikely to be 0 ; used for distortion A 16-bit, low byte hijack_p11 lda #>junktab ; hijack the pointer for lookup tables to load sta nr+1 ; write the high byte in memory ldy tmp2 ; load the RMT slot value lda tabbeganddistor_extra-4,y sta nr lda #0 ; volume 0 for the 16-bit low byte channel (1 and 3) ora tabbeganddistor_extra-3,y bne pp2scont_finished ; bne is used since it's 100% unlikely to be 0 ; back to the original RMT code by Raster, nothing is hijacked no_hijack lda tabbeganddistor,y sta nr lda tmp ora tabbeganddistor+1,y pp2scont_finished sta trackn_audc,x ; write the new combined value in memory IFT STEREOMODE==1 jmp InstrumentsEffects ; last step is finished, jump straight to the next part ; most of the stereo code is identical to the one above, but some slight differences are present, could be optimised a lot better, but fits well in memory... pp2scont_stereo lda reg2 and #$0e ; clear everything but the RMT slot value sta tmp2 ; temporary backup cmp #$0A ; slot A? bne hijack_p6_stereo ; nope, skip the 16-bit checks entirely hijack_start_stereo lda v_audctl2 ; global AUDCTL value tay ; backup to index y for quick transfer between steps hijack_p0_stereo and #$08 ; join 3+4? beq hijack_p3_stereo ; nope, skip to the next step hijack_p1_stereo tya ; get the AUDCTL backup in the accumulator and #$20 ; 1.79mhz ch3? beq hijack_p3_stereo ; nope, skip to the next step hijack_p2_stereo cpx #$07 ; channel 4? beq hijack_p10 ; yes, jump straight to the next part cpx #$06 ; channel 3? beq hijack_p11 ; yes, jump straight to the next part hijack_p3_stereo tya ; get the AUDCTL backup in the accumulator and #$10 ; join 1+2? beq hijack_p6_stereo ; nope, skip to the next step hijack_p4_stereo tya ; get the AUDCTL backup in the accumulator and #$40 ; 1.79mhz ch1? beq hijack_p6_stereo ; nope, skip to the next step hijack_p5_stereo cpx #$05 ; channel 2? beq hijack_p10 ; yes, jump straight to the next part cpx #$04 ; channel 1? beq hijack_p11 ; yes, jump straight to the next part hijack_p6_stereo lda v_audctl2 ; load the global AUDCTL in the accumulator, again, in case the initial checks were skipped ldy tmp2 ; load the RMT slot backup in index y and #$01 ; 15khz? beq no_hijack ; nope, skip the entire hijack process jmp hijack_p7 ; jump to the final steps from here EIF ; End of hijack mess And so that's what I wanted to share, I'm learning more and more by trying different things, and this is definitely not the definitive version of my hijacked code There are a lot of improvements still possible, only the future will tell! Hahaha ? 2 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 (edited) RMT Visual Player has now been updated, rmtplayr is now merged into both projects, seems to run perfectly fine still! Now the only real problem is the notes tables, there are missing entries in the high pitched range, so it leaks into a different table as a result. This is something that could easily be worked around by moving all the data in a different memory page, but not without making the rmtplayr incompatible with the tracker itself. So that's a thing to be careful about still. [EDIT] Lol, as soon as I posted this, I found a bug related to my timer code. Turns out I forgot to properly set the value used by the frame counter to calculate correctly, so running this file in NTSC speed was too fast, because it updated once every 50 frames... Oops. Makary - Prehistoric Tale.obx Edited August 31, 2021 by VinsCool 3 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 31, 2021 Share Posted August 31, 2021 does that mean you fixed the timer ntsc thing and re uploaded it already or will that be in another post? Quote Link to comment Share on other sites More sharing options...
tane Posted August 31, 2021 Share Posted August 31, 2021 4 hours ago, VinsCool said: So I pretty much confirmed the Beta5 code is all functional Is there an automated way to convert old .rmt files (and its instruments) to the new player "Patch 16 Beta5"? Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 1 hour ago, _The Doctor__ said: does that mean you fixed the timer ntsc thing and re uploaded it already or will that be in another post? I did not re-upload it but I will post a fixed version in this post now that I fixed the timer bug It really was a dumb mistake from me, hehe, that bug shouldn't have existed, but I forgot I moved the moment my timer ran into the VBI, so it did not need the older adjustments. 1 hour ago, tane said: Is there an automated way to convert old .rmt files (and its instruments) to the new player "Patch 16 Beta5"? Depending on what module we are talking about, there is a good 95% chance there would be no change needed to get it working. The only thing that would be obvious is if 16-bit bass was used, which will require manual adjustments. Other than that, I specifically went all the way to make sure to keep as many things compatible as possible Makary - Prehistoric Tale.obx 2 Quote Link to comment Share on other sites More sharing options...
tane Posted August 31, 2021 Share Posted August 31, 2021 7 minutes ago, VinsCool said: Other than that, I specifically went all the way to make sure to keep as many things compatible as possible I'm thinking that someone could open a .rmt with player "A", but such file was created for player "B", and ended thinking "what a bad rmt", but actually is good if it's played with "B". Maybe some metadata inside each .rmt indicating which player was created from. 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 26 minutes ago, tane said: I'm thinking that someone could open a .rmt with player "A", but such file was created for player "B", and ended thinking "what a bad rmt", but actually is good if it's played with "B". Maybe some metadata inside each .rmt indicating which player was created from. That is exactly the reason why I tried as much as possible to keep things compatible. If a module was created with RMT 1.28/1.30 or earlier, it should be fine in most cases. The major exception would be anything that uses the 16-bit bass from Distortion 6, but I added a failsafe to it, the regular Distortion C bass will be used instead for those, so things should still sound fine, just not exactly like intended. 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted August 31, 2021 Share Posted August 31, 2021 10 hours ago, VinsCool said: This is possible, actually, and probably very easy to achieve, in fact. So , feel free to add this feature quickly. 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 15 minutes ago, emkay said: So , feel free to add this feature quickly. Fine, I'll try later, that really shouldn't be difficult, lol 1 Quote Link to comment Share on other sites More sharing options...
emkay Posted August 31, 2021 Share Posted August 31, 2021 9 minutes ago, VinsCool said: Fine, I'll try later, that really shouldn't be difficult, lol For the possibility of using gen. 2 at standard clocking, it would be ok to have that feature on channel 1 only, if that makes things easier . Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 1 minute ago, emkay said: For the possibility of using gen. 2 at standard clocking, it would be ok to have that feature on channel 1 only, if that makes things easier . The channel isn't going to be a problem, actually. It's only a matter of checking the index x for values of either 0 or 2, being channels 1 or 3 respectively. So if it returns neither of those, there would be no 1.79mhz clock forced to prevent channel 1 and 3 outputting unwanted high pitched sounds. So essentially, I can break down the idea into this simple explanation: - check for RMT slot (Distortion) 2 - if true, continue, else, skip the hijack - compare the index x to either 0 or 2 - if neither is true, skip the hijack - if 0 is returned, ora the 1.79mhz clock for channel 1 into trackn_audctl,x, then finish the hijack, OR, if 2 is returned, ora the 1.79mhz clock for channel 3 into trackn_audctl,x, then finish the hijack - continue with whatever code coming after the hijack If I have not lost you with these technical details yet, you probably noticed this is, more or less, almost exactly the same approach I did for Beta5, because it pretty much exactly is If you wonder why I did not go with v_audctl instead, there is a simple explanation for it. It would have been overwritten with the 4 channels being ora'd together, so storing into trackn_audctl,x would solve that issue effectively. So yeah, it really isn't going to be difficult to do, since I already have 99% of the logic already in place Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 Hmmmm, so @emkay looks like things did not exactly go like I was planning. I have a proof of concept, but I will need to work around it a little bit more to get a fully functional Distortion 2 hack. So here's what works so far: - forcing an AUDCTL value with Distortion 2 does work. - stores in memory just fine and happens in the correct channels, like I expected. And here's what did not work as I anticipated: - forcing an AUDCTL value into trackn_audctl,x will only work once, and then, it will stay the same as long as the same instrument is still playing, while the idea was to have it activated only when Distortion 2 was detected. - and just as I suspected earlier, forcing it into v_audctl directly will get overwritten by the 4 trackn_audctl,x being ORA'd then STA'd back into v_audctl. I did not set any AUDCTL in the instruments, so, at least, I know for sure it was set automatically by the code, and is functional, but not fully to be able to control when the clock is changed. What I did not expect however, was that an instrument would keep the same trackn_audctl,x value in memory as long as the instrument is being sustained, it looks like it will not change again until a new note is played. That may not be too difficult to find a workaround, so I'll continue testing a little bit. Here's the current test binary if you are interested. Distortion 2 TEST1.obx 1 Quote Link to comment Share on other sites More sharing options...
Sandor / HARD Posted August 31, 2021 Share Posted August 31, 2021 11 hours ago, VinsCool said: RMT Visual Player has now been updated, rmtplayr is now merged into both projects, seems to run perfectly fine still! Now the only real problem is the notes tables, there are missing entries in the high pitched range, so it leaks into a different table as a result. This is something that could easily be worked around by moving all the data in a different memory page, but not without making the rmtplayr incompatible with the tracker itself. So that's a thing to be careful about still. [EDIT] Lol, as soon as I posted this, I found a bug related to my timer code. Turns out I forgot to properly set the value used by the frame counter to calculate correctly, so running this file in NTSC speed was too fast, because it updated once every 50 frames... Oops. Makary - Prehistoric Tale.obx 8.23 kB · 2 downloads Wow, that's a pretty complex sounding tune for a single Pokey! Keep going 1 1 Quote Link to comment Share on other sites More sharing options...
VinsCool Posted August 31, 2021 Author Share Posted August 31, 2021 Just now, Sandor / HARD said: Wow, that's a pretty complex sounding tune for a single Pokey! Keep going Credits to Makary for the awesome tune! All I did was playing it back through my hacked code 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.