Search options (Page 3 of 4)

@Frantic: Yes, 0200 is the "hard-cap" for 8580 and my current report is based on realC64 with 8580, but it behaves identically in emulated environment as well (Vice+reSID-fp). Because the tracker loses that feature after loading a file only (therefore it cannot be triggered from "clean start" in pre-load state), it leads me to rather strong conclusion that it's somehow part of the file operation issue. Once the "don't go below 0200" rule is broken, the behavior cannot be "healed" and C64 restart is needed.

I think SID chip detection is a bad guess. Even in emulator environment it's perfectly possible to switch between 6581 and 8580 without restarting and defMON reacts accordingly by applying 0000 "hard-cap" to 6581 and 0200 "hard-cap" to 8580 when playback starts (F1/F3). But once this feature becomes broken by loading the tune, again - there's no coming back and restart is needed.

That's pure gold, thank you for sharing. Obviously, there's very little reason to use them today, but the historical value is enormous. However, I still miss that white screen flashing with each new pattern, even though it delayed the display a bit. ;-)

Time goes by quickly as hell. I'd be happy to see any version older than 20090304. I know they are there. It's been great adventure through all these years. :-)

@Frantic: Sure, no problem. Here's .d64 with "inflated" sample tune from 20171026 build and then "healed" with 20141108 build.

I confirm the bug. Latest defMON build (2017/10/26).

Testing results: empty affected song has 65 blocks, but finished affected song has 76 blocks (all 00-7F sequences used, all 00-FF instruments used). This is only 11 blocks of difference between empty and maxed out song.

Unaffected songs usually have 2 blocks when empty and go up to 60 blocks when maxed out. This time it is 58 blocks difference.

It means that something is unnecessarily saved as if it was user data in affected songs, but still can be overwritten by the actual user data.

This is also true. Affected empty song has 16 blocks after saving it in RAW mode ($1000-$1F11). It feels super huge.

How often the bug happens? It is semi-permanent, in 75% cases I'm getting large files. Once the file becomes "affected", there's no going back. However, if you load "affected" song using older defMON build (eg. 20141108) and save it, the file will be "healed" from unnecessary data.

Where does the bug happen? Both on real C64 hardware and Vice 2.xx+3.xx emulators.
_____________________________________________________________________

PS. I know it won't change much, but the jump X times loop idea for instrument lines is a idea. Good directon. Useful to say the least. Would molest every here and there, 10/10.

Jump. Reset. Back. I was given specific instructions on how to do it because as I said I'm an utter boob when it comes to coding.
https://k2s.cc/file/ddaa7d523a8b7 (sorry for lame host - don't have any private FTP passwds stored here).

Tested with monoSID and stereoSID tunes, both in "from the scratch" state (clean reset) and after multiple save/load operations. Used all the dirtiest tricks to glitch the functions (incl. leaving gaps between pattern numbers to see how the "new" numbers are being assigned with both copying methods shift+N/+U, removing/misplacing red-dots to glitch the player and copying patterns afterwards, this includes setting multiple pattern loop markers with dead/bugged patterns including irregular loop positions on SID#1 and SID#2 just for sake of testing) and... everything works perfectly fine! Also tested multiple saving/overwriting/loading to see if bugged patterns are being "healed" consistently. Works fine as well. I was not able to glitch the player at all.

PS. There's only one "visual" bug that is here for ages. stereoSID mode - if only SID#1 uses pattern looping marker function (e.g. FF 04), but SID#2 doesn't mimic the same looping point, the patterns will loop, but the grey pattern position indicator for SID#2 will continue to go down the order list as though there was no pattern loop point set at all. (Doesn't matter at all, because in no real circumstances the tune should be edited like that.)

Now burning onto the cartridge as I did that three times today already. ;-)