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


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

Registered: Sep 2003
Posts: 1703
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 16:55
chatGPZ

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

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

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

Registered: Sep 2003
Posts: 1703
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 12:26
chatGPZ

Registered: Dec 2001
Posts: 11100
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 13:00
tlr

Registered: Sep 2003
Posts: 1703
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 13:25
chatGPZ

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

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

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

Registered: Dec 2001
Posts: 11100
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 14:37
tlr

Registered: Sep 2003
Posts: 1703
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.
2018-01-08 20:44
Mr.Ammo
Account closed

Registered: Oct 2002
Posts: 228
Quote: Would be super! If it works on RR/NR, maybe I can convince Gideon to add debouncing in 1541u2 and friends. :)

I have flashed it on a retro replay (revised revision october 2004). The current version that is. I can also flash the old version to it.

Any specifics you would like me to test and you want to know?
2018-01-08 21:14
tlr

Registered: Sep 2003
Posts: 1703
Fantastic!

I'd like to know if freezing and then unfreezing (X in the freeze monitor) is stable with the two versions (this needs to be repeated several times). On 0.5x it fails on 1541u2 most of the time. 0.5 works. The theory is that both 0.5 and 0.5x work on RR.

It should be sufficient to freeze the ready prompt but you could try something else. Note that some timer aspects have known problems (TOD and CIA2 interrupts).
2018-01-11 08:37
AlexC

Registered: Jan 2008
Posts: 293
I'm happy to report that 0.5 current works so far on both of my MMC Replay and RR (red board edition).
2018-01-11 19:30
tlr

Registered: Sep 2003
Posts: 1703
Great! Meanwhile I've gotten a mail stating both versions work on EasyFlash3 (CLPD Version 1.1.1). (thnx HTH!)
2018-01-11 20:05
chatGPZ

Registered: Dec 2001
Posts: 11100
on chameleon it freaks out in interesting ways, looks like in the reset screen (extended basic) it keeps resetting over and over. when i press run/stop i get the menu. kinda weird, what feature are you using there that no other existing RR rom uses? =) (v0.4 worked fine btw)
2018-01-11 20:44
tlr

Registered: Sep 2003
Posts: 1703
I guess the problem could be that I'm trying to do something Atomic Power like in the bank switching code. I switch in ram temporarily to preserve the state of $de00 and $01. (RAM contains more or less the same code as the ROM at $de00)

Something like this was introduced in 0.5:
.C:de5f  08          PHP
.C:de60  48          PHA
.C:de61  A9 10       LDA #$10
.C:de63  48          PHA
.C:de64  A9 22       LDA #$22
.C:de66  78          SEI
.C:de67  8D 00 DE    STA $DE00
.C:de6a  A5 01       LDA $01
.C:de6c  8D 86 DE    STA $DE86
.C:de6f  09 07       ORA #$07
.C:de71  85 01       STA $01
.C:de73  68          PLA
.C:de74  8D FC DE    STA $DEFC
.C:de77  8D 00 DE    STA $DE00
.C:de7a  68          PLA
.C:de7b  28          PLP
.C:de7c  60          RTS
Maybe worth to check rr-freeze on it if you haven't.
The $22 mode above might confuse things if NR is emulated instead of RR.
2018-01-11 21:19
chatGPZ

Registered: Dec 2001
Posts: 11100
wouldnt that mean it does the same also on nordic replay? (chameleon implements nordic replay)
2018-01-11 21:31
tlr

Registered: Sep 2003
Posts: 1703
Probably but I thought the $22 mode would be fine on both RR and NR as I only rely on the $de00 mapping part of the mode. Maybe I missed something?
2018-01-11 21:59
chatGPZ

Registered: Dec 2001
Posts: 11100
well technically the $22 mode doesnt exist on RR nor AR... anything could happen, if you want this ROM to work on all of them, you shouldnt use that mode - its nordic power (or NR) specific
2018-01-12 07:12
tlr

Registered: Sep 2003
Posts: 1703
Maybe not in the sw, but it _is_ documented in that inside replay document from Jens and does work on most of the implementations tried. I'd love an rr-freeze dump for the chameleon, at least for de01=40. It might be something else I trigger.

Please? :)
2018-01-12 18:32
Mr.Ammo
Account closed

Registered: Oct 2002
Posts: 228
Quote: Fantastic!

I'd like to know if freezing and then unfreezing (X in the freeze monitor) is stable with the two versions (this needs to be repeated several times). On 0.5x it fails on 1541u2 most of the time. 0.5 works. The theory is that both 0.5 and 0.5x work on RR.

It should be sufficient to freeze the ready prompt but you could try something else. Note that some timer aspects have known problems (TOD and CIA2 interrupts).


The superfluid-0.5x version's freezer is very unstable. Almost every time I freeze and return from freeze back to the c64 screen, it fucks up what was happening there. This even happens just with the C64 basic screen.

The Superfluid V0.5 version seems to work flawless (and thus stable).

I tested both on the Retro Replay revised edition October 2004.

A strange thing I noticed is that when I enter i*1000 or I*0800 in monitor, it will always start scrolling from address $A100 and for the other from $A080, etc. I must say I didn't read the manual, so I don't know if this is correct behaviour ;-)
2018-01-12 18:38
chatGPZ

Registered: Dec 2001
Posts: 11100
http://www116.zippyshare.com/v/TtZt1n0A/file.html (plain binary/no load addr)

its likely hitting something that isnt fully implemented... i remember at least some of the ram banking stuff isnt (no software using it...). but could be some other bug ofcourse =)

reminds me we still need to try this program on real AR and Nordic Power.....
2018-01-12 18:56
tlr

Registered: Sep 2003
Posts: 1703
Quote: The superfluid-0.5x version's freezer is very unstable. Almost every time I freeze and return from freeze back to the c64 screen, it fucks up what was happening there. This even happens just with the C64 basic screen.

The Superfluid V0.5 version seems to work flawless (and thus stable).

I tested both on the Retro Replay revised edition October 2004.

A strange thing I noticed is that when I enter i*1000 or I*0800 in monitor, it will always start scrolling from address $A100 and for the other from $A080, etc. I must say I didn't read the manual, so I don't know if this is correct behaviour ;-)


So my "trash less stack" approach is not very good in practice then. Will stick with the safe appoach until I get a better idea. Thanks for testing and reporting!

The monitor isn't based on the action replay one so no "I*" command. The "A" is from obviously not doing error checking of parameters very well. Noted.
2018-01-12 19:04
Mr.Ammo
Account closed

Registered: Oct 2002
Posts: 228
Quote: So my "trash less stack" approach is not very good in practice then. Will stick with the safe appoach until I get a better idea. Thanks for testing and reporting!

The monitor isn't based on the action replay one so no "I*" command. The "A" is from obviously not doing error checking of parameters very well. Noted.


I also tested both versions of the carts on my MMC Replay. Same behaviour as on the Retro Replay. The .5X version shows the same behaviour and the current .5 version works stable/flawlessly.

Ah, see? I should have read the manual. Although, now you know there's some missing error checking.
2018-01-12 19:08
tlr

Registered: Sep 2003
Posts: 1703
Quote: http://www116.zippyshare.com/v/TtZt1n0A/file.html (plain binary/no load addr)

its likely hitting something that isnt fully implemented... i remember at least some of the ram banking stuff isnt (no software using it...). but could be some other bug ofcourse =)

reminds me we still need to try this program on real AR and Nordic Power.....


Thanks!

It does have some strangeness with the $22 mode, see below, but nothing that is obvious to cause the problems you are seeing. Maybe it is something completely different...

I've built a variant that is identical to 0.5x, but uses $20 instead of $22 in the banking code. If you want you can try that and see if it changes anything: superfluid-0.5y.zip

      x01xx000 -> $DE00 (RAM)    x00xx000 -> $DE00 (ROM)
  9E: 0  1  2  3  0  1  2  3     A* B* C* D* E* F* G* H* 
  BE: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  DE: 0  0  0  0  0  0  0  0     A* B* C* D* E* F* G* H* 
  DF: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  FE: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
      x01xx001 -> $DE00 (RAM)    x00xx001 -> $DE00 (ROM)
  9E: 0  1  2  3  0  1  2  3     A* B* C* D* E* F* G* H* 
  BE: A* B* C* D* E* F* G* H*    A* B* C* D* E* F* G* H* 
  DE: 0  0  0  0  0  0  0  0     -  -  -  -  -  -  -  -  
  DF: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  FE: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
      x01xx010 -> $DE00 (RAM)    x00xx010 -> $DE00 (ROM)
  9E: A* B* C* D* 0  -  -  -     -  -  -  -  -  -  -  -  
  BE: 0  0  0  0  E* -  -  -     -  -  -  -  -  -  -  -  
  DE: 0  0  0  0  0  0  0  0     A* B* C* D* E* F* G* H* 
  DF: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  FE: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
      x01xx011 -> $DE00 (RAM)    x00xx011 -> $DE00 (ROM)
  9E: 0  1  2  3  0  1  2  3     A* B* C* D* E* F* G* H* 
  BE: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  DE: 0  0  0  0  0  0  0  0     -  -  -  -  -  -  -  -  
  DF: -  -  -  -  -  -  -  -     -  -  -  -  -  -  -  -  
  FE: A* B* C* D* E* F* G* H*    A* B* C* D* E* F* G* H*
2018-01-12 19:15
tlr

Registered: Sep 2003
Posts: 1703
Quote: I also tested both versions of the carts on my MMC Replay. Same behaviour as on the Retro Replay. The .5X version shows the same behaviour and the current .5 version works stable/flawlessly.

Ah, see? I should have read the manual. Although, now you know there's some missing error checking.


Again thanks for testing! I really hoped the .5X would work out but that settles it.
2018-01-12 22:41
chatGPZ

Registered: Dec 2001
Posts: 11100
0.5y indeed works on chameleon, so its that $22 mode. interesting :) i added the nordic power compatibility just recently, so perhaps its just a bit broken =P
2018-01-12 22:49
tlr

Registered: Sep 2003
Posts: 1703
Quote: 0.5y indeed works on chameleon, so its that $22 mode. interesting :) i added the nordic power compatibility just recently, so perhaps its just a bit broken =P

Brilliant! I believe we have a winning setup then! :)
2018-01-12 23:14
chatGPZ

Registered: Dec 2001
Posts: 11100
i'd prefer to fix the emulation, of course =D
2018-02-10 15:17
tlr

Registered: Sep 2003
Posts: 1703
A new release is out: Superfluid V0.6

It includes three different variants: Retro Replay, Nordic Replay and Retro Replay experimental.

The Retro Replay variant should work on all hardware variants and clones.

I've also included a small document detailing the expected cart mappings, derived from the actual Retro Replay and Nordic Replay hardware from iComp.
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
anonym/padua
Alakran_64
Yogibear/Protovision
Slaxx/Q/HF/MDY
sebalozlepsi
Mibri/ATL^MSL^PRX
Medicus
Guests online: 119
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 The Ghost  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 Wafer Demo  (9.5)
7 TRSAC, Gabber & Pebe..  (9.5)
8 Onscreen 5k  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.096 sec.