Has there been any developments on bringing Commodore 64 to Libretro? I been wanting to get some Last Ninja on…
Awwww yea, I’d love to replace c64 memories with retroarch integration.
Also interested
Very interested on this, too! I think it’s the most important computer core that libretro is missing by now 
I too would love a C64 core in RetroArch. It seems like a nobrainer, but from the last I heard it wasn’t something the team wanted to do (I could be totally wrong). I hope it comes at some point, because I’ve never had good luck running any other C64 emulators and would love to play some of the old games I played as a kid through it.
I Wasn’t aware about c64 power!
my first computer was an 8bit Amstrad cpc464 , after I moved to the 16bit with Atari 520stf and later amiga500 . so I’ve completely missed the Commodore 8bit computer.
Sound was incredible for the time , and game was not bad at all !
The machine is so nice that I thinks I will try to port Vice on libretro when I have time. ( note the I will try and the when I have time 
)
on side note , I started an frodo-libretro port , as Frodo is quick and easy to port to libretro. the port as all inherent problems of Frodo but seem to be playable (at least on linux) . But remember it’s a debug version , that mean not free from bugs , maybe memory leak ect … , so for now only for dev not end users. You have been informed !
also thanks to diablodiab for testing/debuging .
+1 to VICE or anything that has accurate SID emulation available. The C64’s music is iconic to say in the least and anything less than the best emulation is a waste of time, IMO. Should be based off resid-fp: http://sourceforge.net/projects/sidplay-residfp/
1 Like
+1 for a VICE port. Frodo is far inferior… and VICE offers emulation for a lot of Commodore systems besides C64, like the legendary PET models!
Yeah would be great to finally get VICE in RA…cant believe its taken so long for it to get a release!
Yeah VICE is far superior to Frodo, in both accuracy and compatibility…
Frodo is better than nothing 
Seen some non constructive feedback here.
I agree that VICE is far superior in accuracy and compatibility, but Frodo is good enough to be here , aimed for low spec system.
edit: Vice port should be possible , with some time.
r-type: I am VERY sorry if my comment sounded non-constructive, really. I can imagine what an ammount of work porting cores take…I only did some graphics backend work on RA and even that took a considerable ammount of time, so I can just imagine the BIG ammount you must put in these ports.
Yes, FRODO is “good enough”, I agree on that. But there are some problems with the core that come from FRODO itself. For example, I couldn’t get it to load some games (Mayhem in Monsterland comes to mind), so I had the fear that FRODO would become the core of choice in the libretro library and maybe that’s why I wasn’t very positive towards it when I commented… sorry again, r-type.
If I am allowed to do some constructive comments for FRODO port, I’d like to do so now:
-Remap RUN/STOP to other key, having it on ESCAPE is not very good.
-Please add a core option to disable LEDs. Entering the internal emulator menu hangs it here (Raspberry Pi Linux). In fact, having all these options as core options instead of that custom menu would be ideal.
-An option to auto-launck disk games would be VERY usefull too, since RA is usually run in enviroments without a keyboard. And using the OSD keyboard would make me commmit suicide 
-The non-libco version has “pauses” each few seconds. The emulator stalls during a second or so and then continues. I saw it in “Forbidden Forest” for example.
I hope you can forgive and forget my previous non-constructive comment…
[QUOTE=vanfanel;30023]
Yes, FRODO is “good enough”, I agree on that. But there are some problems with the core that come from FRODO itself. For example, I couldn’t get it to load some games (Mayhem in Monsterland comes to mind), so I had the fear that FRODO would become the core of choice in the libretro library and maybe that’s why I wasn’t very positive towards it when I commented… sorry again, r-type.
If I am allowed to do some constructive comments for FRODO port, I’d like to do so now:
-Remap RUN/STOP to other key, having it on ESCAPE is not very good.
-Please add a core option to disable LEDs. Entering the internal emulator menu hangs it here (Raspberry Pi Linux). In fact, having all these options as core options instead of that custom menu would be ideal.
-An option to auto-launck disk games would be VERY usefull too, since RA is usually run in enviroments without a keyboard. And using the OSD keyboard would make me commmit suicide
-The non-libco version has “pauses” each few seconds. The emulator stalls during a second or so and then continues. I saw it in “Forbidden Forest” for example.
I hope you can forgive and forget my previous non-constructive comment…[/QUOTE]
Thanks for the feedback.
I will try to find my old pi next weekend to try Frodo on it . to look at non-libco behaviour.
the Majority of games that i have tested , were need “true emulation option” to be set.
For RUN/STOP , I always use retroarch with a hothey enable
a basic autoboot is mapped to ABT virtual key , maybe we could map it to some pad key.
that said , i agree nothing to do with vice autoboot feature 
I was also thinking about adding such core options for most.
by the way if only , the core opt engine could inherit some functions to deal file browsing ect … we could then do all GUI stuff through the same interface .
Now speaking of C64 emulation,
At first , for a profan like me (meaning not having c64 experience before), c64 emulation meant “load&play a classic game c64” frodo is good enough for that.
later when starting to know more about c64 hardware and power , Vice is required…
honestly the main drawback to reach the goal is the time. Frodo meant only few hours to achieve .
I’ve started to look at vice code , hack it to obtain a basic linux vice x64 libretro core working
but far away to having a proper vice port .
As said previously ,the main drawback is the time ,
And now , I spend my time to stay glued to my binary, watching/listening demo
instead of coding…
[QUOTE=vanfanel;30023]r-type: I am VERY sorry if my comment sounded non-constructive, really. I can imagine what an ammount of work porting cores take…I only did some graphics backend work on RA and even that took a considerable ammount of time, so I can just imagine the BIG ammount you must put in these ports.
Yes, FRODO is “good enough”, I agree on that. But there are some problems with the core that come from FRODO itself. For example, I couldn’t get it to load some games (Mayhem in Monsterland comes to mind), so I had the fear that FRODO would become the core of choice in the libretro library and maybe that’s why I wasn’t very positive towards it when I commented… sorry again, r-type.
If I am allowed to do some constructive comments for FRODO port, I’d like to do so now:
-Remap RUN/STOP to other key, having it on ESCAPE is not very good.
-Please add a core option to disable LEDs. Entering the internal emulator menu hangs it here (Raspberry Pi Linux). In fact, having all these options as core options instead of that custom menu would be ideal.
-An option to auto-launck disk games would be VERY usefull too, since RA is usually run in enviroments without a keyboard. And using the OSD keyboard would make me commmit suicide
-The non-libco version has “pauses” each few seconds. The emulator stalls during a second or so and then continues. I saw it in “Forbidden Forest” for example.
I hope you can forgive and forget my previous non-constructive comment…[/QUOTE]
If you’ve done some work on RA before then you’ll find it very easy to make your own modifications to the Frodo core while waiting. I’ve already hacked in most the suggestions you list in the core when I saw the r-type was working on it. It was very simple to locate in the source:
- assigned RUN/STOP to a controller button
- turned off LED and borders
- autoload disk images
(running on my Shield TV):
@diablodiab: of course most of those modifications are hacked into my FRODO compiled core, but I think they should be available to anybody, having them hacked in is not a solution 
But hey, how did you enable autoloading in disk images?? Exact string and file, if possible.
@diablodiab: thanks for that! Now I have my images autobooting, which saves me from loading manually
Also, what did you change to get Mayhem working well?? Here, the same release you’re using in the video only shows a black background on the tittle screen.
@r-type: after disabling the LEDs, I’ve noticed there’s a thick band of random pixels under the C64 screen. Have you seen that problem?
I compiled the core to be cycle correct (frodosc). This might not run well on Raspberry Pi with the limited CPU power.
[QUOTE=vanfanel;30161]@diablodiab: thanks for that! Now I have my images autobooting, which saves me from loading manually
Also, what did you change to get Mayhem working well?? Here, the same release you’re using in the video only shows a black background on the tittle screen.
@r-type: after disabling the LEDs, I’ve noticed there’s a thick band of random pixels under the C64 screen. Have you seen that problem?[/QUOTE]
yeah for autoboot , i don’t remember why i remove it in this clean-up commit but i used to set it in int init_graphics(void) , so avoid use of another variable like hack_autorun …
kbd_buf_feed("\rLOAD\":*\",8,1:\rRUN\r\0");
maybe you can try if works here ,so i will re-enable it .
@vanfanel yes i always disable LED, so I’m aware , minor thing to fix ,i think i should use like i use in vice , 384272 instead of 384288 when LED disable.
BTW, I stumble on two problem on vice , first it segfault at exit (after main_exit and retro_deinit ), second it failed on android/arm device , not sure about the pb , but seem float/double speed/sample-rate in resid part are interpreted as zero ;(’
For Mayhem , yes compile with EMUTYPE=frodosc should resolve the pb.