Menu

#150 x64 Cartridge Freezer/Banking Issue

closed-fixed
nobody
x64 (101)
2012-10-13
2010-12-10
Fungus
No

When using Action Replay (v5/5.1) PAL or NTSC, using the freezer while a piece of software is running (pick any game, I used Cyberdyne Warrior) using the cartridge freezer fails 90% of time, and ends up with PC = $980E (invalid return address from stack) The calling JSR is at $980C in the cartridge ROM. On a real C64 you can press freeze and continue execution nearly limitless times and very rarely will it crash like this.

It's also related to another bug when using the monitor (not in frozen mode) where the graphics displayed are just garbage from the AR rom. Scroll around in the monitor to see it, it's easily reproducible.

Vice versions tested where this occurs, all versions since 1.6 or so, including latest win32 svn build available from csdb link.

(note for groepaz, if my REAL AR exibited this behavior I would have tossed it out the window and never NTSC fixed anything.)

Discussion

  • gpz

    gpz - 2010-12-10
    • summary: Cartridge Freezer/Banking Issue --> x64 Cartridge Freezer/Banking Issue
    • assigned_to: nobody --> gpz
     
  • gpz

    gpz - 2010-12-10

    "Vice versions tested where this occurs, all versions since 1.6 or so, including latest win32 svn build available from csdb link."
    you didnt tell wether you have been using x64 or x64sc - i can only guess that you are talking about x64 :) i can reproduce this with x64, lots of crashing ahoi ..... however with x64sc, not a single crash when freezing/restarting a couple of dozen times (in the title screen of cyberdyne warrior). so the solution is: use x64sc :) you very much want to do this anyway, especially if you are doing ntsc fixes =P

    "It's also related to another bug when using the monitor (not in frozen mode) where the graphics displayed are just garbage from the AR rom. Scroll around in the monitor to see it, it's easily reproducible."
    no, this is completely unrelated - this is because vic fetches in ultimax mode are broken (and can not be fixed) in x64. it works better (although not perfect, this is work in progress) in x64sc. also its just a cosmetical issue with no impact on the emulation (other than visuals). it will get fixed 100% (in x64sc) as soon as a proper testcase arrives :)

     
  • Fungus

    Fungus - 2010-12-10

    Yes works in x64sc, thanks again.

     
  • gpz

    gpz - 2010-12-10

    lowering priority, wont fix for now, as it works in x64sc and likely might not be fixable in x64 at all

     
  • gpz

    gpz - 2010-12-10
    • priority: 5 --> 3
    • assigned_to: gpz --> nobody
    • status: open --> open-accepted
     
  • gpz

    gpz - 2011-01-11

    closing, as fixing it in x64 would probably require more than one super ugly hack. use x64sc :)

     
  • gpz

    gpz - 2011-01-11
    • status: open-accepted --> pending-wont-fix
     
  • SourceForge Robot

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).

     
  • SourceForge Robot

    • status: pending-wont-fix --> closed-wont-fix
     
  • Soci/Singular

    Soci/Singular - 2012-10-13
    • status: closed-wont-fix --> closed-fixed
     
  • Soci/Singular

    Soci/Singular - 2012-10-13

    Fixed in r26311.

    The problem was that the 3 cycle bank switch delay was triggered after the complete NMI handling if the interrupted opcode was only 2 cycles long. Because of this the fetched interrupt vector address was wrong.

     

Log in to post a comment.