Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user fredrikr ! (Registered 2018-01-18) You are not logged in 
CSDb User Forums


Forums > CSDb Entries > Release id #161259 : Superfluid V0.5
2018-01-05 17:27
tlr

Registered: Sep 2003
Posts: 1144
Release id #161259 : Superfluid V0.5

I tried to make a freeze function with a little less stack corruption than usual for this but it seems it didn't work well on 1541u2. Thanks to insane for reporting this!

In the original (old) freezer implementation I more or less acknowledge the freeze immediately to allow switching in cart ram. This way timing critical stuff can be preserved directly to cart ram instead of pushing it to stack. This works _sometimes_ on 1541u2.

In the revised implementation (0.5) I do the regular, push to stack, then wait ~250 ms, then ack freeze. This works fairly reliably on 1541u2.

I guess the problem arises from some double trigging of the NMI but I'm not 100% sure. Looking at the 1541u2 source there doesn't seem to be any debouncing of the button in the FPGA at least. The specification for RR/NR states that the freeze button is digitally debounced so I was hoping that would be the same in all implementations.

REQUEST:
I don't have an actual RR or NR to test on but I did build one 0.5 variant with the original freezer and was hoping someone would be willing to test both that and the original one on RR and/or NR. Any takers?

original (old): superfluid-0.5x.zip
revised (current): Superfluid V0.5
2018-01-05 17:55
Groepaz

Registered: Dec 2001
Posts: 8367
iirc the original AR freezer also does wait a bit, for exactly the same reason :)
2018-01-05 18:00
tlr

Registered: Sep 2003
Posts: 1144
It does, but that requirement is supposedly loosened (or even gone) in RR/NR due to the debounce.
2018-01-05 18:26
Groepaz

Registered: Dec 2001
Posts: 8367
that is correct, i think
2018-01-07 11:38
tlr

Registered: Sep 2003
Posts: 1144
BTW: Nordic Replay does have the feature of enabling RAM at $a000-$bfff directly during freeze but there is from what I can see no way of creating a Nordic Replay .crt.

Without this possibility it's sort of tricky to use Nordic Replay specific cartridges in 3rd party carts as it always require manual cart type configuration. This is probably one of the reasons 1541u2 and others haven't implemented support for it yet.

I filed a "bug" about that here: https://sourceforge.net/p/vice-emu/bugs/969/
2018-01-07 13:26
Groepaz

Registered: Dec 2001
Posts: 8367
its just a variant of the action replay really, there is no need for an extra crt type. just add the extra mode to the emulation, its fully backwards compatible. (chameleon has had support for a while, 1541u is the only one that does not =P)

that said, there is a crt type for nordic power/atomic power already. this is what you want to use.
2018-01-07 14:00
tlr

Registered: Sep 2003
Posts: 1144
Quote: its just a variant of the action replay really, there is no need for an extra crt type. just add the extra mode to the emulation, its fully backwards compatible. (chameleon has had support for a while, 1541u is the only one that does not =P)

that said, there is a crt type for nordic power/atomic power already. this is what you want to use.


Sure, but Atomic Power emulation in vice doesn't accept 64Kb carts. I was contemplating using the Nordic Replay modes to improve freezing and the Retro Replay isn't compatible with that so any cart image would break unless you manually select that option.

Anyway, still hoping for some help on testing the images above. Would be appreciated!
2018-01-07 14:25
Groepaz

Registered: Dec 2001
Posts: 8367
(lets keep the discussion regarding crt files on sf... :))

i have to dig up my NR. its... somewhere. perhaps. :=)
2018-01-07 14:36
tlr

Registered: Sep 2003
Posts: 1144
Would be super! If it works on RR/NR, maybe I can convince Gideon to add debouncing in 1541u2 and friends. :)
2018-01-07 14:45
Groepaz

Registered: Dec 2001
Posts: 8367
i'm actually seriously worried about that there is no debouncing... there is no reason for not doing it, always, and on all buttons.
2018-01-07 15:37
tlr

Registered: Sep 2003
Posts: 1144
I couldn't find it in the VHDL implementation but it's quite a few hierarchies to go through so I may have missed it. There may be debouncing outside the FPGA too.
 
... 19 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
hedning/G★P
c0zmo/BLiSS
Dymo/G★P
MP Software
ΛΛdZ
Andy/AEG Soft
Holy Moses/Role
Poison/Singular Crew
V-12/Tropyx
Powerslave/Triad
Guests online: 69
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 Coma Light 13  (9.6)
4 The Shores of Reflec..  (9.6)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 Incoherent Nightmare  (9.5)
8 Wonderland XII  (9.5)
9 Comaland  (9.5)
10 Wonderland XIII  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.6)
2 FMX Music Demo  (9.6)
3 Merry Xmas 2017  (9.5)
4 Synthesis  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Dawnfall V1.1  (9.5)
7 Dawnfall  (9.4)
8 Treu Love [reu]  (9.4)
9 Field Sort  (9.4)
10 Pro Memoria 4  (9.3)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.3)
4 The Judges  (9.3)
5 Crest  (9.3)
Top Fullscreen Graphicians
1 Veto  (9.8)
2 Joe  (9.8)
3 Mirage  (9.7)
4 Jailbird  (9.6)
5 Hein  (9.5)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 1.127 sec.