Commodore64 core?

Libretro Cores
#34

[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 :smiley: -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 :wink: 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 :frowning: 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 :slight_smile: instead of coding…

#35

[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 :smiley: -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):

#36

@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 :stuck_out_tongue: But hey, how did you enable autoloading in disk images?? Exact string and file, if possible.

#37

Here is the patch: autoload.txt (795 Bytes)

#38

@diablodiab: thanks for that! Now I have my images autobooting, which saves me from loading manually :smiley: 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?

#39

I compiled the core to be cycle correct (frodosc). This might not run well on Raspberry Pi with the limited CPU power.

#40

[QUOTE=vanfanel;30161]@diablodiab: thanks for that! Now I have my images autobooting, which saves me from loading manually :smiley: 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.

#41

@r-type: I tried the EMUTYPE parameter with no success. I still get a black backgrong in Mayhem’s title. I build FRODO like this: “make -j8 -f Makefile.libretro NOLIBCO=1 EMUTYPE=frodosc”

EDIT: Got it, it builds a core with a different name and I was using the old one.

So are you going to move the “internal menu” options to “core options”? Did I get it right?

I have also noticed that a “ghost” file called .sram.bsv is created in the system directory when this core is run.

And yes, frodo_sc is a bit TOO heavy on the Pi1’s CPU :smiley:

Also, r-type, since you love the Atari 8-bit so much, have you tried porting this one? —> http://sourceforge.net/p/atari800/source/ci/master/tree This is a lightweight Atari 8-bit computer line emulator that would run on low-end hardware too and is pretty much accurate while not nearly as CPU-intensive as frodo_sc.

#42

[QUOTE=vanfanel;30247]@r-type: I tried the EMUTYPE parameter with no success. I still get a black backgrong in Mayhem’s title. I build FRODO like this: “make -j8 -f Makefile.libretro NOLIBCO=1 EMUTYPE=frodosc”

EDIT: Got it, it builds a core with a different name and I was using the old one.

So are you going to move the “internal menu” options to “core options”? Did I get it right?

I have also noticed that a “ghost” file called .sram.bsv is created in the system directory when this core is run.

And yes, frodo_sc is a bit TOO heavy on the Pi1’s CPU :smiley:

Also, r-type, since you love the Atari 8-bit so much, have you tried porting this one? —> http://sourceforge.net/p/atari800/source/ci/master/tree This is a lightweight Atari 8-bit computer line emulator that would run on low-end hardware too and is pretty much accurate while not nearly as CPU-intensive as frodo_sc.[/QUOTE]

For internal menu to core opts and the ghost file , yes i will look at when i ll have time , for now I’m on vice.

for Atari800 , yeah , i had ported it few year ago , I’m sure I had a libretro version somewhere … but I’m more 16bit ATARI computer than 8 bit :slight_smile: .

BTW , i finally find my problem with vice port , the crash at exit and the non working sound on android was due to a atexit failure ,now ,vice works better on linux and on android . I should finally get something with this Port …

#43

Hell yeah!, when can we expect a release of the VICE CORE please?

#44

Wonderful news, r-type! C64 is one of my most cherished childhood memories. Can’t wait to give it the proper RetroArch run.

#45

r-type: I’m all crazy about the 8bit Atari computer line, it was my first “own” computer (we had a ZX Spectrum at home before that but it was my aunt’s computer and not really mine). So could you please dig that Atari800 port? I would LOVE to have that, so if the work is already done…

And DON’T worry about Frodo core problems: if you’re into VICE, then it’s better! VICE is the way to go, I agree!

#46

If you’re porting VICE over to RetroArch, does that mean the core is also able to run Commodore 128 roms?

#47

Hell yeah!, when can we expect a release of the VICE CORE please?

If you’re porting VICE over to RetroArch, does that mean the core is also able to run Commodore 128 roms?

Not quickly anyway , for now it’s only a poc , core run fine but there are no option or menu added ,only quick gui hack to load cart/tap/disk , as a good vice port need the menu to be ported and all options available… I have no spare time for now to spend on it , so it can take long time before we had a proper vice port. For c128 , i ve tried some c128 d64 , but none of them works . i must have a broken things somewhere.

#48

[QUOTE=r-type;30505]Not quickly anyway , for now it’s only a poc , core run fine but there are no option or menu added ,only quick gui hack to load cart/tap/disk , as a good vice port need the menu to be ported and all options available… I have no spare time for now to spend on it , so it can take long time before we had a proper vice port. For c128 , i ve tried some c128 d64 , but none of them works . i must have a broken things somewhere.[/QUOTE]

Hi r-type,

Could I persuade you to upload your current poc version to your github? The menu is not important to me, and I would love to mess around with it.

#49

@r-type: what diablodiab said… and if you could locate that atari800 libretro port it would be nice, too :slight_smile: (sorry to insist)

#50

Sorry guy but no free time to work on it , so for now , it’s very limited and WIP . many things are missing ,input are broken , and the rest is good to be redone in a sane way.

For a800 , i have to find first the old hard drive where it reside.

#51

Thx for making the wip version available. I don’t really have time to fiddle around with it myself, but it’s nice to have the option at some point.

Btw, I’m having zero problems with the Frodo core, so far it has worked fine with everything I’ve thrown at it. So I’m not in a hurry with Vice, tbh :slight_smile:

#52

[QUOTE=diablodiab;30898]Thx for making the wip version available. I don’t really have time to fiddle around with it myself, but it’s nice to have the option at some point.

Btw, I’m having zero problems with the Frodo core, so far it has worked fine with everything I’ve thrown at it. So I’m not in a hurry with Vice, tbh :)[/QUOTE]

I’ve compiled both of r-type’s frodo and vice cores successfully, but they segfault when I try to run them on my Raspberry Pi and with retroarch from git. Anyone have any clues?

#53

I am using this core, but i have a problem:

  • .prg files do not work, the emulador do nothing…

  • d64, tap and crt files work great!

Any suggestion???