Hatari version 1.9.0

[lollo78]

Hi, there is a plan to upgrade the porting to the latest version of Hatari? Thx for all your hard work

[gingerbeardman]

2016-11-04: Hatari version 2.0.0

[r-type]

https://github.com/r-type/hatari2 done in the past for my own

[gingerbeardman]

@r-type any interest in doing a pull request?

[smithjd15]

@r-type Or better yet, a rebase onto hatari's github repo (https://github.com/hatari/hatari). It seems to mirror the repo on hatari's download page (https://hatari.tuxfamily.org/download.html), so it looks like hatari is comfortably git'ted.

[Shoegzer]

Seconded, with upstream on GH it should be slightly easier to rebase, and with Hatari upstream now at 2.2.1 this core is many versions (and over five years) behind. This would make an excellent core if it could be brought up to speed and we could put forth real testing efforts against it.

@twinaphex any chance you have a few free cycles to spare on this one, assuming it's not too tricky?

[Darknior]

Yes five years without any update and a debug port .... Really if some one can update this core to the last source code to male it better and faster we will like write @Shoegzer can take time to test it better and report bugs to make this core really usable on Libretro. I love ATARI and and if possible i really prefer to use this emulator in LR core than in standalone version .... more portable on many systems .... Thanks a lot

[Shoegzer]

Circling back on this, not much has happened other than a few commits to port to the Vita.

@r-type Any chance you could let us know your thoughts on rebasing, or maybe loop in someone who might have a look? Not sure if the situation is more complex than we're making it out to be, but thanks for any help you may have to offer.

[r-type]

you could take a look here https://github.com/r-type/hataritmp

[Shoegzer]

@r-type Cool, had no idea you were already on it! Can you merge that with this branch or are there blockers?

Also, compiling on this test system (gcc 9.3.0) gives me the this:

/home/shoegzer/Desktop/hatari/hataritmp/src/gui-sdl/dlgHalt.c:21:10: fatal error: gui-retro.h: No such file or directory
   21 | #include "gui-retro.h"
      |          ^~~~~~~~~~~~~

Any ideas here?

[r-type]

did you build with make -f Makefile.libretro ?

[Shoegzer]

Thanks, I had just run configure and make. This time though I got the following:

$ make -f Makefile.libretro 
cc -std=gnu99 -fPIC -fsigned-char -D__LIBRETRO__ -fno-builtin -funroll-loops -ffast-math -fomit-frame-pointer -DGIT_VERSION=\"" 4de5720e"\" -O3 -DLSB_FIRST -DALIGN_DWORD -DNEW_WCPU=1 -I./src  -I./src/cpu  -I./src/falcon -I./src/includes -I./src/debug -I./src -I./libretro -I./libretro/libretro-sdk/include -I./libretro/include -I./libretro/utils -I./libretro/new-cpu-pregen -Ilibretro/capsimg_linux/include -Ilibretro/capsimg_linux/ -DHAVE_CAPSIMAGE=1 -Ilibretro/capsimg_linux/LibIPF -I./libretro/capsimg_linux/Codec -I./libretro/capsimg_linux/Core  -I./libretro/capsimg_linux/Device -Ilibretro/capsimg_linux/CAPSImg -c -o libretro/new-cpu-pregen/cpuemu_0.o libretro/new-cpu-pregen/cpuemu_0.c
In file included from libretro/new-cpu-pregen/cpuemu_0.c:1:
./src/includes/main.h:11:10: fatal error: config.h: No such file or directory
   11 | #include "config.h"
      |          ^~~~~~~~~~

Thanks for your help.

[r-type]

my fault , .gitignore have an entry for config.h so my local config.h was never pushed to repo. can you pull and try again?

[Shoegzer]

Thanks @r-type. Got further this time, but I still fail to compile, with this:

src/ikbd.c: In function ‘IKBD_Info’:
src/ikbd.c:3192:20: error: expected ‘)’ before ‘PRId64’
 3192 |  fprintf(fp, " (+%" PRId64 ")\n", pIKBD->Clock_micro);
      |                    ^~~~~~~
      |                    )
Makefile.libretro:274: recipe for target 'src/ikbd.o' failed
make: *** [src/ikbd.o] Error 1
make: *** Waiting for unfinished jobs....

[r-type]

missing some header for PRId64, sould be fixed now. also i've updated new cpu pregen. you can build using new uae cpu (default) or old one (like actual libretro\hatari)

new -> make -f Makefile.libretro -> give nhatari_libretro core old -> make -f Makefile.libretro NEWCPU=0 -> give hatari_libretro core

[Shoegzer]

Thanks @r-type and yes, it compiles now and looks promising! Nice to see 2.2.1 as a core.

That said, joystick input doesn't seem to work properly (using a DS4 pad mapped as RetroPad). For example directions don't seem to work. I can toggle to mouse mode and then use the right analog as directions, but that's not using the joypad as intended. Also my L1 bumper toggles the onscreen keyboard even though it's mapped as the select button. Thoughts?

[r-type]

Yes the bug is there is 2 time RETRO_ENVIRONMENT_SET_INPUT_DESCRIPTORS https://github.com/libretro/hatari/blob/master/libretro/libretro.c#L484 https://github.com/libretro/hatari/blob/master/libretro/libretro.c#L646 with different descriptors.

I have removed one in my repo, so can you try again to see how it goes now.

the normal control should be like describe here https://github.com/r-type/hataritmp/blob/master/README.md

[Shoegzer]

Thanks @r-type. I tested a new build after your fixes but D-pad still doesn't work, and the L1 bumper still toggles the onscreen keyboard. I appreciate your working through this though and I'm happy to keep testing.

[r-type]

L1 should bring on screen keyboard SELECT should toogle mouse/joypad look here https://github.com/r-type/hataritmp/blob/master/README.md you can use L2 (status) to see if you are in DPAD or MOUSE mode.

[r-type]

BTW on which os are you ? I loose my head to find why joystick not working in some game like turrican or alien syndrome, i've done also a quick port of 2.2.1 hatarisdl-libretro using my sdl-libretro backend and here the joystick works fine in this game ! that drive me mad.

[Shoegzer]

Ah, I hadn't realized the option defaults changed so yes the show/hide vkbd is set properly now.

However, the dpad still doesn't work. When I had reported it earlier I should have said that I checked to ensure I was in "Joystick" mode and not "Mouse" mode, so it's still an issue.

I'm using Linux Mint 19.3 with kernel 5.3.

[r-type]

Does it not working on all games ? does it works at least with keyboard (up/down/left...) ? because it works fine for me with joy on my debian and on my pi3.

[INFO] Environ SET_INPUT_DESCRIPTORS: [INFO] RetroPad, User 1, Button "B (bottom)" => "Button opt config 1/mouse b2" [INFO] RetroPad, User 1, Button "Y (left)" => "Enter GUI" [INFO] RetroPad, User 1, Button "Select" => "Mouse mode toggle" [INFO] RetroPad, User 1, Button "Start" => "Toggle num joy" [INFO] RetroPad, User 1, Button "D-Pad Up" => "Up" [INFO] RetroPad, User 1, Button "D-Pad Down" => "Down" [INFO] RetroPad, User 1, Button "D-Pad Left" => "Left" [INFO] RetroPad, User 1, Button "D-Pad Right" => "Right" [INFO] RetroPad, User 1, Button "A (right)" => "Fire /mouse b1" [INFO] RetroPad, User 1, Button "X (up)" => "Shift ON/OFF" [INFO] RetroPad, User 1, Button "L" => "show/hide vkbd" [INFO] RetroPad, User 1, Button "R" => "Mouse speed" [INFO] RetroPad, User 1, Button "L2" => "Toggle m/k status" [INFO] RetroPad, User 1, Button "R2" => "Button opt config 2"

Btw if you want to try ths sdl-libretro version you can get it here https://filebin.net/95z0e8wl0eg9bz5m

[Shoegzer]

My apologies, I had been testing a game called "Typhoon Thompson" which, strange as it seems, only controls with the mouse as I recalled only after seeing its wikipedia article. Testing against another game (Karateka) I discovered the DPad is working just fine. Again sorry for the confusion!

With that out of the way, a few other questions for you:

1. Can the hataritmp changes be merged with the RA core or are there blockers remaining?
2. What features are missing from this core that exist with upstream Hatari?
3. Is there any way to port the settings exposed via the Hatari GUI into the RA UI? That would avoid having the drop the the Harari GUI to make those changes as they can be done natively within RA.

Thank again for working on this core!

[r-type]

sorry no many spare time....

1. i my point of view , no , hataritmp should be an another core. hatari 1.8 is suitable for low end device like vita ect... hatari 2.2.1 is more ressource demanding on even not work at full speed on vita for example.

2. many :)

3. yes it's possible , but it is an hard works. it's has been done for some other core like puae or vice. But first you should find someone who has time and want to do it (it's not my case).

BTW even if i have not much time to work on it , i have done an wip test branch for joystick implementation which should resovle game like turrican or alien syndrome. (for now you should go in gui joystick to activate ST joystick 1 as real joystick and choose PAD00.)

[Shoegzer]

Thanks @r-type for your thoughts. No worries about a lack of spare time - I think I can speak for others here that we just appreciate any time you can give.

1. I would respectfully disagree, I don't believe an older and very outdated version of a core should be maintained just because it runs faster on systems that won't even themselves be around in a few years. Your core is really the only way forward and important for long-term preservation efforts (and thank you very much for that!). Also, I doubt the few people who still own a vita would want to run an old atari computer on it, typing on a vkbd with keys a quarter the size of their fingernails. ;)

But whether it's a separate core or not, do you have a sense of when you can push your fork to libretro? It would be great to see as part of the buildbot super script, for example here.

2. Since the upstream hatari UI is available through the RA core, and assuming all its settings take effect in the core as well, wouldn't all the upstream features already exist in the core (even if moving those options to RA's UI would be better) - or am I missing something?

3. Again no worries at all, I understand and appreciate your lack of time. The puae and vice cores are great mostly because of the amazing work @sonninnos has been doing on them lately and continues to do. I'm not sure of his level of interest in atari cores but if not him, someone like him could do similar things here and really polish it up!

I just checked out your test branch with sdl_joystick and will check it out soon. Thanks!

[smithjd15]

Great work!

I had to rename nhatari_libretro.so to hatari_libretro.so to get it to function (RetroPie).

save / load state is not working for me. The state seems to be saved to disk, but load attempts result in an incorrect (previous) save state loading instead.

[smithjd15]

you could take a look here https://github.com/r-type/hataritmp

Are there any plans to start/complete importing this repo as this project's new active repository? The codebase has been growing ever beyond a "shallow fork" while this project's repository has not made way for the re-base on the Hatari GitHub repository.

[Shoegzer]

Would really like to see that and it would breathe new life into an important core with all these nice new features, at least IMO.

@twinaphex looping you in in case you know someone who can look into this, perhaps in the spirit of keeping cores up to date? Thanks if you can.

[Shoegzer]

Just noticed that the day after I posted the above message to this thread, upstream hatari had a fairly major update to 2.3 with lots of new features and fixes (see here). There's been one other update since. Not sure how challenging these updates would be to port but it would of course be great to see someday.

[tomconte]

Greetings! I am taking an interest in this issue b/c I worked on updating another "abandoned" libretro core recently (fuse-libretro) and thus I have some experience in the process :-) I noticed that the Hatari core was far behind the upstream release, and that is a shame indeed!

What is almost certain is that this libretro core and the upstream have diverged quite a bit with time. Many fixes and improvements have been made to this fork, and if we rebase to upstream, there is a high risk of introducing regressions, functional and non-functional (e.g. performance).

There is also a high risk of breaking the core on a number of platforms, especially the more "exotic" ones, like Vita, 3DS, etc. You might think not many people use those, but if the build is broken for these targets, then it's broken and it will need to be fixed :-)

So the question here is, if we pull in the fork from @r-type, do we have at least 2-3 people who can build and test the code on different platforms and help diagnose and fix the issues?

@twinaphex : if we open a PR here, will it be picked up by the libretro buildbot?

[bbbradsmith]

PRs do get built