hatari
hatari copied to clipboard
libretro
IPF Support
I've installed the IPF libraries/headers where they state they should be installed but Hatari still claims it was built without IPF support. I'm not seeing a configure switch for this so I can only assume it should be picked up automatically.
Does/should IPF support work on the LibRetro version?
Does/should IPF support work on the LibRetro version?
in short , for now with current makefile, no.
If you want IPF support , you have to tweak makefile.libretro to enable it. basically to set HAVE_CAPSIMAGE to 1and deal with the IPF include and lib dir.
I have tested with the 4.2 user distribution for linux found here http://www.softpres.org/download i tweak the makefile like here http://pastebin.com/MSs8k4LV and build with
make -f Makefile.libretro "IPFSUPPORT=1" "IPFDIR=../x86_64-linux-gnu-capsimage"
then IPF load fine .
Does it compile fine (albeit without IPF support) if you tell it to compile with IPF support but are missing the libraries? The reason I ask is this should really be on by default (but leave it up to the user to install those libraries themselves).
The IPF disk images are now the defacto for Atari ST it seems, so not including support to actually read them seems like a rather massive oversight.
I only post you a quick way to handle it for yourself if you need IPF support. Now if someone want to handle IPF support in a proper way ...
The IPF disk images are now the defacto for Atari ST it seems, so not including support to actually read them seems like a rather massive oversight.
This port is outdated and most user have msa / st / or stx image (like in TOSEC )
TOSEC has always been a bit of a mess (no-one needs 20 copies of games, especially broken or bad copies). The cleanest versions of Atari ST games available these days are from No-Intro and they only release IPF files from what I can tell, hence the question regarding support.
Notes that i m not against the IPF , as it appearing to me to be the best choice from preservation point of view .
I only said that most user have msa or st img (as they are easier to find ) , so they don't probably don't mind about IPF.
Also notes that personally i like more the intro than the games themselves , maybe i'm a bit notsalgic re-viewing all the atari crew ...
BTW when i ll have some free time , i plan to redone a port more up-to-date .
No worries, I was just concerned as I'd seem more IPFs than ST/STX files around lately so it seemed like something that was needed going forward.
I agree on the cracktro front, but I take a nicer collection over a TOSEC mess any day :P
I guess when someone gets the core, check it and update, it will surely be put on the support. This, like some others, remained stagnant in the initial ports and little was reviewed, I suppose due to lack of interest in these systems.
IMHO the best option is to clone this repository here https://github.com/simonowen/capsimage and compile all together. Capsimage5.1 is compatible with gcc9 and the issue would be fully resolved.
IMHO , the best option is to rebase/replace core with last hatari git version before change/add anythings here.
BTW, the ipf support in hatari-libretro work from years,it is just that the commit has not been push here!
IMHO , the best option is to rebase/replace core with last hatari git version before change/add anythings here.
BTW, the ipf support in hatari-libretro work from years,it is just that the commit has not been push here!
+1
If you are looking to compile your own Hatari (Atari - ST) core with support for IPF files, I've got the code: https://github.com/pkos/hatari
Unfortunately, RetroArch cannot distribute the Hatari core with IPF support files due to GPL license. However, a code update to the Hatari source should follow the footsteps of P-UAE source code in detecting if the user has downloaded the support library separately instead of just expecting it to be present.
https://github.com/libretro/libretro-uae/blob/11b34b3e2ec8a6c1585fcdb0a3008b71ed3d7a34/sources/src/caps/caps.c#L75
