Compatibility issue: V-Max! protected retail games do not work

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.

    When loading V-Max! protected retail games from a real 1541, 1541-II or 1571 drive connected to the C64 Reloaded MKII, it will crash/restart the system back to the C64 main screen.


    The disks are NTSC but the issue happens with both NTSC and PAL chips. G64 images of these same V-Max! protected titles also occur while loading from Pi1541 and also Ultimate II+.


    Just for total closure this issue also occurs on all of the Ultimate 64 line of boards as well.


    The issue however does not occur on real C64 NTSC or PAL hardware . The issue also does not occur in VICE (NTSC or PAL) using G64 images.


    We have the latest C64R MK2 firmware installed.


    Can this or will this be fixed in a future firmware update (if there ever is one)?

  • Chaniyth

    Changed the title of the thread from “Compatability issue: V-Max! protected retail games do not work” to “Compatibility issue: V-Max! protected retail games do not work”.

    The C64RMK2 has a setting that lets you use the burst mode of a 1571 or 1581 drive. If this is turned on, it's likely that some copy protection mechanisms fail. Please make sure to have that all in original setting. Further, if you have an alternative ROM, this may also cause original software to fail, as some copy protection mechanisms go as far as refusing to work if they detect a non-standard machine (which potentially makes it easier to hack the program).


    Some copy protection mechanisms need a certain CIA revision to work. In order for us to reproduce (and possibly fix) this error, please take pictures of your chips, and also a screenshot of the remote control menu for the IEC settings.


    Do you have a 2nd SID installed? If so, what settings did you choose?

    Jens


    Burst mode is not enabled, everything on the board is the factory default. No custom/alternative ROM. No second SID.


    Attached are several pictures of the CIA chips and screens from the remote control menu.




    Is there a publicly available G64 image that we can try with a C64 Reloaded MK2 and a 1541U or a Chameleon in floppy mode? If so, I'd have Tobias reproduce and investigate it.


    The CIA chips you have are the non-A types - very early ones, probably taken from a Commodore 610 computer? These are known to have a different behaviour on IRQ confirmation, so this may already be the culprit. Do you have a 6526A to try?

    No, both my ASSY 250407 and ASSY 250425 C64 boards have these same exact chips, both C64's were purchased and shipped with these CIA's. Thank you for realizing these are the original 6526 by the date code I assumed they were A just without it marked, I'll definitely look into getting the A revision of these chips.


    I think I may have found the issue though, I have a Link232-Wifi cartridge plugged in, I remove it and the games seem to load and run properly. :)

    I have published a proper power filtering circuit for those ESP32-based Wifi modems years ago: This includes an inductor and a capacitor in the 5V rail of the user port. I don't know if this has been adopted by the vendors of those Wifi products. If they didn't, it's likely that it's a clocking issue: The Wifi modem injects enough noise into the 5V rail, which will confuse the PLL of the C64RMK2. In turn, more correction pulses will be executed, and the computer may run async to the floppy for a split second, which is detected by the V-Max algorithm.

    Well, this particular Wifi modem fits into the Expansion Slot (cartridge slot) of the C64, it's a Wifi clone of the Swiftlink and utilizes Bo Zimmerman's Zimodem firmware.


    Please, disregard what I said in my original post regarding the Ultimate II+ cartridge as I really think it's an issue with it's drive emulation that V-Max! protection just doesn't like.

    Expansio- or userport, both are pathways for noise injection into the 5V rail, which will ultimately reach the PLL circuit of the C64RMK2.


    Any ESP32-based board should properly decouple it's power source. So far, I haven't seen that this is being done as standard. It's more like "slapping parts together" instead of actual engineering. I'm happy to stand corrected - if you can open the case of your unit and take high-res pictures, I may spot the required filter components.

    - no inductor in ESP32 power rail

    - no caps on oscillator circuit - might drift or take unreasonably long to start stable oscillation

    - no series resistor in oscillator circuit - increased ageing of Xtal

    - no parallel resistor in oscillator circuit to burn DC bias - might lead to dying oscillation

    - tiny supply traces, might lead to instable operation



    Need I say more about engineering vs. slapping things together?

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • 8|
    • :cursing:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3