dmsc Posted December 18, 2017 Share Posted December 18, 2017 Hi! That's an acceptable change IMHO. Still sounds good and almost the same. Here's 196 Changes the bass instrument slightly (sixth value played is now $c0 instead of $c2). Another possibility is merging pentatonic and chord, but that would change the lead melody, because the order of pentatonic would be different. Would save another 3 bytes. Edit: on the other hand, perhaps some people are already hearing something different than I do and the sv2k17 attendants did, because of a different ROM. The page that's played was selected for its melody from the 800XL stock ROM. I managed to remove 3 more bytes! - only read "bassc,x" one time, simplify *3/2 logic. now at 193 bytes... mus256.asm 3 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 18, 2017 Share Posted December 18, 2017 Cool. Love that thread even me never going down that deep in my code . Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 18, 2017 Share Posted December 18, 2017 (edited) the flavor of this is starting to change, not sure if it's going to far when the it starts sounding different like this... change in sound started before the last posted reduction. it is interesting how far you can take this before it either breaks or becomes different all together. Edited December 18, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
ivop Posted December 18, 2017 Author Share Posted December 18, 2017 I found the slightly longer hi-hat sound and slightly shorter bass sound acceptable (being the original "artist" of this song), but, for example, changing the order of the pentatonic table completely changes the melody and as such I found it not acceptable. It's indeed interesting where something becomes too different to be called more or less the same. 2 Quote Link to comment Share on other sites More sharing options...
F#READY Posted December 18, 2017 Share Posted December 18, 2017 Love it! Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted December 18, 2017 Share Posted December 18, 2017 now at 193 bytes... 188 bytes (merged drum and blues table as this is simpler than my suggested 2 bit per pattern compression) mus256.asm 2 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted December 18, 2017 Share Posted December 18, 2017 188 bytes (merged drum and blues table as this is simpler than my suggested 2 bit per pattern compression) Keep this up and you'll be running out of the 2600 RAM. Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 19, 2017 Share Posted December 19, 2017 186 bytes by using INC as RMW equivalent of storing zero. 185 bytes by reordering the delay loop to save the CLC. Means there is a difference of 1 frame for two of the channels - may the artist decide of that is acceptable :-) (Sounds the same for me, but hey, I released ISO on the VCS with 15 kHz humming and didn't even notice because I am too old for to hear that anymore ) mus256-186B.zip mus256-185B.zip 3 Quote Link to comment Share on other sites More sharing options...
dmsc Posted December 19, 2017 Share Posted December 19, 2017 Hi! 188 bytes (merged drum and blues table as this is simpler than my suggested 2 bit per pattern compression) I reordered the tables and restore the two table approach for the chords, now chords sound exactly as original and it's two bytes shorter, at 186. EDIT: I would merge the changes by JAC! now! mus256.asm 2 Quote Link to comment Share on other sites More sharing options...
Roydea6 Posted December 19, 2017 Share Posted December 19, 2017 All this needs now is a clear screen and return to Dos on exit.. Sound is good to my ear... @ 73 years. 1 Quote Link to comment Share on other sites More sharing options...
dmsc Posted December 19, 2017 Share Posted December 19, 2017 (edited) Hi! 186 bytes by using INC as RMW equivalent of storing zero. 185 bytes by reordering the delay loop to save the CLC. Means there is a difference of 1 frame for two of the channels - may the artist decide of that is acceptable :-) (Sounds the same for me, but hey, I released ISO on the VCS with 15 kHz humming and didn't even notice because I am too old for to hear that anymore ) Attached file incorporates your first change, giving 184 bytes. I did not add your second change as I think it sound different enough, and it's only one byte less. I tried interleaving the tables, changing the order of patterns, and many combinations, but could not get the code smaller. More eyes are necessary :-) mus256.asm mus256.xex Edited December 19, 2017 by dmsc 1 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 19, 2017 Share Posted December 19, 2017 (edited) The name needs to change with the bytes... MUS184B etc etc... Edited December 19, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
ivop Posted December 19, 2017 Author Share Posted December 19, 2017 Who would've thought, from 246 down to 184 Thanks everyone who contributed and commented! 3 Quote Link to comment Share on other sites More sharing options...
ivop Posted December 19, 2017 Author Share Posted December 19, 2017 ...now chords sound exactly as original and... Yes, besides the slightly shorter bass envelope and slightly longer hi-hat, the introduction of calculating arpeggio(n)=n*3/2 introduced another slight difference with the original. I forgot to mention that at the time. Two arpeggios were identical, but one was off by two. But now the tables are reintroduced and it's exactly the same again 2 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted December 19, 2017 Share Posted December 19, 2017 More eyes are necessary :-) 183 bytes: moved and reversed the (combined) blues pattern to the lower page boundary. No need for X initialisation any more. mus183.asm 6 Quote Link to comment Share on other sites More sharing options...
dmsc Posted December 20, 2017 Share Posted December 20, 2017 Hi! 183 bytes: moved and reversed the (combined) blues pattern to the lower page boundary. No need for X initialisation any more. Good idea!! Now, if you displace the blues pattern by tree and invert the drums patter table, you can join the last tree entries (that are zero) with the hat-closed instrument table. So, three bytes less, now it is 180 bytes. mus256.asm mus256.xex 5 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 20, 2017 Share Posted December 20, 2017 Reordered the assignment of channels and a different way to activate the melody after 12 bars. 178 bytes. mus256-178B.zip 6 Quote Link to comment Share on other sites More sharing options...
dmsc Posted December 21, 2017 Share Posted December 21, 2017 Hi! Reordered the assignment of channels and a different way to activate the melody after 12 bars. 178 bytes. As the code is shorter still, I could move the drums frequency table to zero-page (one byte less) and using a proper alignment of the tables replace the CLC+ADC with EOR (another byte less), so it's now 176 bytes! mus256.asm mus256.176.xex 5 Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 22, 2017 Share Posted December 22, 2017 X-mas is near, so I decided to use opcodes with more X's OK, they are considered illegal and unstable . But I rather see that as "not well documented and challenging". LDA:AND#:TAX optimized to LAX:ANX. I always wanted to try that out. Tested on real Atari 65XE to ensure my assumption about the stability is this specific case is correct.Because and A and X have the same value due to the LAX, environment dependent constant in "A = (A | CONST) & X & #{imm}" does not matter". 174 bytes. mus256-174B.zip 3 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted December 22, 2017 Share Posted December 22, 2017 (edited) The problem with illegal opcodes is that they work with one chip and not another based on manufacturer and timing edges.. please see visual 6502 page about this... progress is slow on mapping these out even to this day, most people don't have all the equipment to check everything out.... my stance is a real world answer should be good enough... so long as we have each chip in each Atari platform we can see what should and should not be used and deem opcodes that are stable by our Atari machines. to be sure only opcodes valid across all the working variations should then be considered accepted... another issue is the abuse to the chip when 3 things tie together repeatedly, really getting hammered so to speak.... that brings in a thermal dynamic also noted in a way on the site... If it fails in one or has thermal issues it should not be used... Edited December 22, 2017 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
dmsc Posted December 22, 2017 Share Posted December 22, 2017 Hi! X-mas is near, so I decided to use opcodes with more X's OK, they are considered illegal and unstable . But I rather see that as "not well documented and challenging". LDA:AND#:TAX optimized to LAX:ANX. I always wanted to try that out. Tested on real Atari 65XE to ensure my assumption about the stability is this specific case is correct. Because and A and X have the same value due to the LAX, environment dependent constant in "A = (A | CONST) & X & #{imm}" does not matter". 174 bytes. Good! About your comment in the source on running in real hardware, yes, some DOS don't disable serial I/O before running a binary. The attached ATR with BW-DOS can be used in real hardware to run the demos, as BW-DOS does clear POKEY registers. mus256.atr Quote Link to comment Share on other sites More sharing options...
+JAC! Posted December 22, 2017 Share Posted December 22, 2017 Nice. I was about to flash SDX, because that is what they use for the compo machine, too. And it appears to properly reset POKEY, too (or not touch it at all when loading from HDD). But this is even better. @Doctor: I'm well aware the nature of the different illegal opcode and in fact have been using them on different platforms for 3 decades "when I gets hard". In in fact I found exactly one occasion when one behaved differently on different boards for the same hardware. Some are well known and researched, some not. http://csdb.dk/release/?id=152327is the best reference as of today. 1 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted December 22, 2017 Share Posted December 22, 2017 OK, they are considered illegal and unstable .... 174 bytes. Sorry, no "like" this time as the 174 bytes are also reachable without cheating... Based on the version of post #43 I changed some self modifying code to PHA/PLA... mus174.asm 5 Quote Link to comment Share on other sites More sharing options...
ivop Posted December 22, 2017 Author Share Posted December 22, 2017 I'm not against undefined opcodes. That's what Bill Mensch calls them himself. Nothing illegal about them 1 Quote Link to comment Share on other sites More sharing options...
Heaven/TQA Posted December 22, 2017 Share Posted December 22, 2017 Me checking Oxyron page for illegals... And as they run on a8 6502c go and use it.... (and forget the 3 with 65816 boards ) 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.