|
| |
Released At :
Unofficial Tiny SID Compo 2022
Achievements :
C64 256b Intro Competition at Unofficial Tiny SID Compo 2022 : #3
Credits :
SIDs used in this release :
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by ChristopherJam on 26 May 2022
| Oh this develops really nicely. Definitely worth sitting with it past the thirty seconds or so. 1:32 hits HARD :D |
User Comment
Submitted by DeMOSic on 18 May 2022
| Awesome tune! And only 255 Bytes? AWESOME! |
User Comment
Submitted by jab on 15 May 2022
User Comment
Submitted by Digger on 15 May 2022
User Comment
Submitted by iAN CooG on 14 May 2022
The fix posted by Deetsay is 100% compliant now; last byte at $10ff could be even shaved as it's unused, making it 255 bytes in total.
The only side effect is that the tune starts different now, but I guess it's another compromise we have to accept for having it in the compo, and a perfectly valid sid tune for HVSC =) |
User Comment
Submitted by deetsay on 14 May 2022
| Fix-version with eternal looping AND resetting all parameters on (re-)init is now provided for your consideration. |
User Comment
Submitted by vincenzo on 14 May 2022
| Compo compliant or not, this is epic. Thanky you Deetsay. |
User Comment
Submitted by deetsay on 14 May 2022
I can fix the runaway pointer/ending with just 1 extra byte (luckily there's TWO to spare). I thought it was funny that it had an ending, but didn't consider the implications... (After fix it should just run forever).
However, initializing all the player parameters to the beginning state in the init ruotine, is not going to happen in 256 bytes. And going 512 is not an option because that would be like giving up ;-). But I don't see any rule that says it has to play the same tune on every init? I realize that is not cool for a SID file to do that, but at 256 bytes there's going to be some... compromises.
If it is disqualified then so be it. But I'll fix the ending so it will hopefully stay within the legal memory limits as that was a clear violation and mistake on my part. |
User Comment
Submitted by Frostbyte on 14 May 2022
| @Tero I hope this is fixable (i.e. possible to make it adhere to the compo rules), and preferably before the deadline. This is fucking EPIC for 256b! |
User Comment
Submitted by Jammer on 14 May 2022
| Compo compliant or not - I LOVE it! <3 |
User Comment
Submitted by iAN CooG on 14 May 2022
| For the record, not even the init code inits correctly all the locations needed by the tune, you can test with psid64 and press 1 any time you want to restart. Definately not compo compliant. |
User Comment
Submitted by iAN CooG on 14 May 2022
There are a lots of problems in this code, at some point it starts reading outside its data, for example here, the byte at $10b1 isn't safeguarded enough so it get incremented until it starts reading outside datas, from $10fe
10B0 ADC $10FE
not counting this zp read that starts reading from $0000-$01ff, $1100-$11ff, $2900-2aff and even $f000-f10b because the pointers at $0b/$0c aren't really protected.
1096 LDA ($0B),Y
It happens after a certain number of frames, it's hearable with a period of silence followed by random noises
Maybe a timed execution, that restarts the tune after some precise number of played frames, can prevent all this and make the tune perfectly looped and valid for the compo. |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
