I’m having issues with the core segfaulting RetroArch. I am not sure what the path to the BIOS Files should be. I am running Mageia Linux 5.1. What should the BIOS Path be on Vanilla Mageia Linux?
I have been trying this core out and I can get single disk games to load but loading multi disk games are my roadblock right now. I have been trying to use the .cmd file method as described on the guthub page but no luck. I get a clack screen with some Japanese text in the middle of it.
Is there something I am supposed to press at this point to progress further ?
I am using the Castlevania game for testing.
Very happy to see this core being developed as well, thanks for this.
Edit: I got the multi disk problem sorted out, just had to change up the .cmd text a little to
px68k “H:\Emulation\Roms\X68000\Akumajou Dracula (1993)(Konami)(Disk 1 of 2).dim” “H:\Emulation\Roms\X68000\Akumajou Dracula (1993)(Konami)(Disk 2 of 2).dim”
You’ve got the menu when pressing F12 to select disks.
Yeah that works but I got things worked out. Now I just need an easy way to generate .cmd files for my 2 disk image games lol.
Maybe you should also use hdf for multi disk game .btw for now only sasi hd supported (40mb max)
I cannot take any credit for this at all. A user from the Launchbox Discord channel by the name of Neilk1 did all the work. Here are a couple of bat files to generate .cmd files for games that have 2 disk images.
This first one is just for one game at a time, drag and drop 2 disks on the bat file and it will generate the .cmd file will a proper name.
@echo off setlocal ENABLEDELAYEDEXPANSION set f2=%1 set raw=%1 set f3=!f2:Disk 1 of 2=Disk 2 of 2! echo px68k %1 %2 > “!raw:~0,-18!.txt”
This second one will bulk generate your .cmd files from a folder of disk images. It will only do this for games that have 2 disk images only. Place this bat file into the folder with all your disk images and run it, you will then have .cmd files for all the 2 disk image games
@echo off setlocal ENABLEDELAYEDEXPANSION for /R “.” %%f in ("*(Disk 1 of 2).dim") do ( set f2=%%f set raw=%%~nf set f3=!f2:Disk 1 of 2=Disk 2 of 2! echo px68k “%%f” “!f3!” > “!raw:~0,-13!.txt” )
2 Likes
Got an idea to save us that step of messing with disks outside of Retroarch.
A core option named “Extract every disk contained in an archive.” could be made. When launching a game every disk would be extracted in the cache folder. Then, if you enter it as your start folder in keropi/config, this would give you direct access to all of your disks in the F12 menu. Disks would be removed on core exit.
Finally managed to save with Aquales.
Start with disk3, enter a blank disk in FDD1 to make it your user disk.
Then you have to reset and start with system disk in fdd0 and that user disk in fdd1.
If it’s not from the start (before the title screen is loaded) it won’t work. 
edit: Finished Aquales, great game. 
Made a 55.45Hz resolution in my nvidia panel, made a core config with that refresh (video_refresh_rate = “55.45”). Now retroarch switches to that when playing on px68k and revert back to 60Hz when I quit. No more stutters. Awesome.
OK. Where does RetroArch store information about what Floppy disks are installed where? Is there a way to bring up the F12 Menu without a keyboard?
I was trying to add F12 as a retropad button and check other stuff, but I can’t build on windows.
Is there a special command? Error log.
I saw that the Bios files went public domain. Perhaps they can be included?
Yes binding F12 to a joypad button is easy to deal and will be a good option in my opinion (we have to choose then which button to bind to F12 )
For the build problem , I know this issue on windows native compilation , @twinaphex report me this error some days ago. it’s seem all compile fine with cross-compilation but stuck for ever with native windows , seem to be a common pb with the c68k core.
At this point , @twinaphex try to fix compilation using -DC68K_NO_JUMP_TABLE ,it build fine but freeze on exec (at least on linux not tested yet in windows i will try ) .
Another solution seem to repeat what is done with yabause core (for the c68k cpu core) and build it with special rule to use no optimisation -O0. not tested yet , as i don’t know if it will have an impact on performance. maybe you can test it and report if it has an impact on the speed as i don’t use Windows OS for RA purpose.
taken from https://github.com/libretro/yabause/tree/master/libretro have to adapt for px68k makefile
C68KEXEC_SOURCE := $(SOURCE_DIR)/c68k/c68kexec.c
C68KEXEC_OBJECT := $(C68KEXEC_SOURCE:.c=.o)
...
$(C68KEXEC_OBJECT): $(C68KEXEC_SOURCE)
$(CC) -c -o $@ $< $(CFLAGS) -O0
Nope, still the same problem: compilation locks up after a while. Anything special to run it?
I tried: make -j4 make -j4 -f Makefile.libretro make -j4 -f Makefile.libretro platform=win make -f Makefile.libretro platform=wincross64
can you try make -f Makefile.libretro WINDOWS_BUILDFIX=1 ? it cross compile in less 15 sec for me on linux (+2min without WINDOWS_BUILDFIX=1)
Nice that worked!
Akazukin Cha CHa CHa 550~600fps vs 700~750fps before. So -20% perf.
that’s what i feared.
Can you try to build this one normally ( without WINDOWS_BUILDFIX=1 ) and see if it build fine and if yes, if perf is the same ?
I re-generate c68k with -DC68K_GEN -DC68K_NO_JUMP_TABLE. -DC68K_GEN -DC68K_NO_JUMP_TABLE and replace the file (old are in 1c68k , new in c68k).
Thought it was bad again, it stayed on that line that is usually stuck for a while…
But it managed it! 
Back to 700~750fps range.
Great work! 
that’s what i hope.
I’ll remove previous hack , push commit with new change and enough for today
@Tatsuya79 , I forgot thanks for your testing and report!
No problem.
Don’t hesitate to ask.