#514 TOD alarm condition incorrect

v2.4
closed-fixed
gpz
None
2016-02-27
2014-04-06
Marco Baye
No

The game "slurpy" behaves differently in VICE and on real hardware, and the reason seems to be the initial TOD alarm time:
On real hardware, when the player takes too long to finish a level, rocks start falling from the ceiling.
In VICE, those rocks start falling right away at the start of the level. POKEing the TOD alarm time of CIA 2 to 9:09:09.9 before running the game inhibits this behaviour.
Our guess (!) is that the game relies on the default TOD alarm time, and that a real CIA chip does not use the value 0:00:00.0 (as used by VICE).

This bug was found by Roboklotz 4711 and Cold Sewers, I'm merely the messenger...

Discussion

  • gpz

    gpz - 2014-04-07

    did you try a nightly build? some TOD stuff was fixed a while ago...

    it would also be very helpful if you could provide a simple testcase (simple basic program is perfectly fine) - or provide a link to that game :)

     
  • Marco Baye

    Marco Baye - 2014-04-07

    No, I used my x64 compiled in february. ;)
    The game can be found at http://csdb.dk/release/?id=24209

     
  • gpz

    gpz - 2014-04-07

    i have tried this one: http://csdb.dk/release/?id=24209 in recent snapshot and it works just fine

     
  • gpz

    gpz - 2014-04-08

    grmpf it didnt work... here is a possible fix. a decent test program would still be nice :)

    edit: bah, that patch doesnt do the trick 100% either :(

     
    Last edit: gpz 2014-04-08
  • CS

    CS - 2014-04-13

    Hi there,

    Here are two more ToD-test programs that might be suitable for the test repository:

    I tried to find out whether the 50/60Hz counter is running freely or is reset to 0 upon writes to the ToD-registers.

    "hzsync0" writes to all registers, stopping the clock in the meantime
    "hzsync1" only writes to the 1/10 sec. register while the clock is running

    According to Vice the counter is never reset, according to my C64 it IS reset when all registers are written, but not when only the 1/10 seconds are written while the clock is running.

    I also noted some rather erratic results on the first test-pass in Vice when reRUNning the program multiple times from the basic-prompt.

    On my real C64 OTOH I noted the occasional odd results when only the tenths are written, my guess(!) is that the counter tried to update the tenths register just when the test prog wrote to it and thereby the update attempt was ignored.

     
  • gpz

    gpz - 2014-04-13

    great, added to repository and fixed ciacore accordingly (r28032) - still didnt fix slurpy however =P

     
  • CS

    CS - 2014-04-15

    Hi again,

    here are some additional tests for the 50/60Hz counter to see the effects of

    1) writing to seconds/minutes while clock is running
    2) omitting those writes while clock is stopped
    3) changing the input frequency while clock is running
    4) stopping the clock for a few frames, then restaring it (to see if the counter is reset by write to hour reg, but still running while clock is stopped)

    results (assy 250407, old cia):

    1) no reset
    2) counter still resets
    3) no reset
    4) counter is either not running while clock is stopped or reset when clock is restarted (which pretty much has the same outcome).

    best regards

     
  • gpz

    gpz - 2014-04-27

    added also the "slurpy" tests of yours now... its getting weirder ... =P

    (http://sourceforge.net/p/vice-emu/code/HEAD/tree/testprogs/CIA/tod/ for anyone who wants to give it a try...)

     
    Last edit: gpz 2014-04-27
  • gpz

    gpz - 2014-10-28

    thanks to fabbo, this should be fixed in r28653 - please try again :)

     
  • Marco van den Heuvel

    • status: pending-fixed --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks