Hatari for Raspberry Pi

[Faucon2001]

Hi,

I am looking for HATARI 1.9 for Raspberry Pi.It's not available on HATARI site, the version on the repository for Pi is 1.8, and Google is deaf.
I don't know how to compile it, so do you know where I can find it? Ideally, one of the last build would be great.

Thanks,

Philippe

[fmh]

According to https://packages.debian.org/stable/allpackages Hatari 1.8 is the latest version.

[Faucon2001]

Logical, that's what I got with apt-get
And the last Hatari version is 1.9
http://download.tuxfamily.org/hatari/

[siriushardware]

The current stable/release version of Hatari is certainly V1.9.0 but it's not unusual for the repositories of Linux distros to take a while to catch up with what is current.

A few posts back in the thread about 'Hatari Midi Compatibility' there is an explanation of how to locate and download, and then compile Hatari from source - however, I don't know how CPU / system specific that source code is, and the source code referred to is for the PC / PC type processors, whereas the Raspberry Pi uses an ARM processor. I don't know whether the source code would have to have some tweaks made so that it could compile and run on the Pi.

[farvardin]

Hello,

I've just build hatari 1.9 on my raspberry pi. Here is the package (made with checkinstall so you can install it with "sudo dpkg -i hatari_1.9.0-1_armhf.deb":

http://dl.free.fr/bv9TbsrAS (the link should be online for at least 30 days)

I haven't launched it (remote compilation from a ssh connexion), but the configure was ok so I should work for you.
I've run ./configure, installed the missing packages, then run "make". I had all the gcc and cmake stuff already installed on my pi.

[Faucon2001]

Great! Thanks farvardin, I will test it tonight.
Have you compiled it with the old or new emulator core?

[farvardin]

Great! Thanks farvardin, I will test it tonight.
Have you compiled it with the old or new emulator core?

you're welcome. For the core, I don't know, I've just used the default setup.

[LaurentS]

You should compile hatari with the new core now.

The old core is kept for now just in case of, but should be removed one day.

[highway]

I will attentively follow this topic

[farvardin]

I guess the new core can be enabled this way:
./configure --enable-winuae-cpu

I don't know if it's in the default or not. I'm compiling a new version now with this option to be sure it's on.

[Eero Tamminen]

Hatari doesn't contain CPU specific code and it has worked fine on ARM devices for a long time.

I actually did first Hatari (v0.90) Debian package build for Nokia's (ARM) Linux internet tablet almost a decade ago:
http://tammat.mbnet.fi/hatari/index.shtml

On older/weaker RasPi versions you may want to use Hatari's oldUAE CPU core because it's a bit more lightweight than the WinUAE CPU core. Hatari manual's performance section gives more hints on masking it speedier.

[Faucon2001]

I have been testing your 1.9 version for arm on a RasPi3 and it runs fine, especially ST & STE mode. Thanks

I just have one issue, and I don't think it's related to this version as I had the same problem with Hatari 1.8.
With Tos 4.04 in Falcon mode all the resolutions look OK, but with TOS 1.62 or TOS 1.04 in respectively STE and ST mode (I have not tested others), only RGB monitor with low & Med resolutions is giving right colors. In mono or in VDI extended, colors are totally screwed.

In mono monitor, colors are blue on dark blue : funky !
Also the setup menu behave strangely, with some OK button only working if you press "return."

Could it be coming from my setup ? I use miniBian, in framebuffer mode, without X

Any clue?

[farvardin]

Strange, on the rpi, with the uae core, the compilation it much slower.

First it get stuck at this:
[ 23%] Building C object src/cpu/CMakeFiles/UaeCpu.dir/cpuemu_32.c.o

after 30 minutes computing, it went to
[ 24%] Building C object src/cpu/CMakeFiles/UaeCpu.dir/cpuemu_40.c.o

[farvardin]

here is the latest version with the new core:
http://dl.free.fr/oZ0My8tkn
(I don't have idea about your color problem, I'll test the binary soon)

[Faucon2001]

Thanks Farvardin, it's seems to work. I have not seen any performance change, gembench is consistent between both version.

Regarding the color issue, I have found some report on google but without solution. It could be linked to sdl lib version.
I have tried to change the -bpp switch, but it's the same : outside of low and mid rez, all the others resolutions have bad colors.
This is how looks like a mono screen

[Eero Tamminen]

My assumption about the problem is a buggy version of libSDL.

[xnonsuchx]

Thanks Farvardin, it's seems to work. I have not seen any performance change, gembench is consistent between both version.

Regarding the color issue, I have found some report on google but without solution. It could be linked to sdl lib version.
I have tried to change the -bpp switch, but it's the same : outside of low and mid rez, all the others resolutions have bad colors.
This is how looks like a mono screen

It's like STacy mono!

[spiny]

It's like STacy mono!

was just about to post this

[Faucon2001]

It's like STacy mono!

Yes and this is not a bug, this is a feature !!!

From what I read on the net it confirms Eero comment, libsdl for Pi has issues with the framebuffer, and I have not found a fix : so kind of dead end for now.

-> Farvardin : which distro do you use? Are you using Hatari with the framebuffer or X? I am interested in as you doesn't seem to have the same issue.
Regarding your different builds, keeping apart this SDL issue, the old UAE engine runs faster on the Pi than the new WinUAE. It's not noticeable on ST/STE emulation, but very clear on Falcon emulation.

[farvardin]

> Farvardin : which distro do you use?

I've compiled it with raspian. I haven't tried it yet, but obviously I'll use X, from a classical desktop (default one on raspian)

[Eero Tamminen]

Regarding your different builds, keeping apart this SDL issue, the old UAE engine runs faster on the Pi than the new WinUAE. It's not noticeable on ST/STE emulation, but very clear on Falcon emulation.

Couple of possible reason for difference in Falcon overhead:
- WinUAE CPU core emulates cache 030 instruction & data cache behavior, which OldAUE CPU core doesn't emulate at all
- Because of above (cache meaning things get executed faster on CPU side), DSP instruction execution loop is run more often, and DSP emulation is also heavier than CPU emulation (DSP runs at 32Mhz, CPU at 16Mhz)

[thothy]

It's like STacy mono!

Yes and this is not a bug, this is a feature !!!

From what I read on the net it confirms Eero comment, libsdl for Pi has issues with the framebuffer, and I have not found a fix : so kind of dead end for now.

You could try to use the latest development version of Hatari from the mercurial repository. Up to the latest public release 1.9, Hatari rendered monochrome resolution into an 8-bit palettized framebuffer, and this is what is likely not working in your version of the the SDL. In the development version, we now switched to non-palettized 16-bit or 32-bit framebuffers, just what is already used for ST-Low and ST-Medium, so you should see a difference with the development version on your Pi.

[Faucon2001]

I have finally learned how to build Hatari, and it works
The last build solve the mono / blue screen issue ; everything is working OK and Cubase 3 especially.
Thanks a lot Thothy.

[Faucon2001]

I have an issue with GEMDOS drive which won't mount at boot.
Hatari boots on emutos 0.9.6 with an ACSI disk image divided in 4 partitions C/D/E/F. AHDI 6 is used as hard drive driver and emulation is in STE mode mono.
I have declared a folder /Partitions containing 1 folder named /G as my GEMDOS drive and saved the config to hatari.cfg
After Reseting Hatari (reset machine), the G drive opens the host folder perfectly.
But when I quit Hatari and restart it, even though the GEMDOS drive is still configured the same, the desktop will complain that the drive is not present. If I change now the GEMDOS drive path to another folder and Reset Hatari, the drive G will open normally.

The build I use is Hatari 1.9-dev from July 10th 2016, build on RaPi minibian wheezy with SDL1.2 and in old UAE mode.

[Faucon2001]

Additional info : I don't have this issue on a build from June 20 made for Ubuntu 15.10 x86.
I then dug an old build for RaPi from the same period and the issue disappears.

Something has changed in recent builds?