Installing Atari800 v5.0.0 on the Raspberry Pi

[hatchcliff]

Thank you all who have contributed to this discussion.  We have three clear choices:

• A. The existing v5.0.0 system: a single package containing two binaries, one of which is selected manually at run time.
• B. An extended version of A such that the system looks to see which model of Pi it is running on and selects the appropriate binary automatically.
• C. The previous system, with two separate packages, each containing a single binary tailored to particular models of Pi.

The aim in v5.0.0 was to put everything needed for all Pis in one package.  This seemed a neat idea to me - but having been through the exercise and listened to the feedback, I think it was a mistake.  No support has been voiced for A, implying that users never had any difficulty identifying which of two packages to install.  Some people have suggested that the management of two mutually exclusive packages in the same repository is no great problem either, so the design may have been based on false premises.  I intend to write off A as a failed experiment.  I have issued a pull request on Github to revert to C.  This will take us back to a stable position that everyone was happy with, and provide a clean starting point for any future developments.  I will also build the C style packages for v5.0.0.

 

I would say that support for B and C is roughly equal.  This is reasonable because they are much the same from the user's perspective - they both present a single atari800 command on all models of Pi.

 

B was the original v5.0.0 intent, but when I started developing it I found some potential problems and eventually opted for simple menus instead of automatic selection.  Having dug myself into a hole with A, it is now impossible for me to proceed with the development of B, because I believe I would be digging myself in deeper.

 

With hindsight I think C was probably the best solution all along.  We are effectively dealing with two different hardware platforms, and C treats them as such - the same way we treat all the other target machines.  However, I continue to receive support from Petr S for variations on B.  I am bowing out of the debate at this point, because it has become too intense for something I do as a hobby.  I will carry on with all the other things I do to support the Pi and Linux packages.

 

[hatchcliff]

A little more detail on the problems I perceived in option B:

• It presents a maintenance problem when new models of Pi are released, because the system may fail to identify them.  Users would have to wait until the next release for a fix - or we could issue a patch, but that doesn't seem very satisfactory.  Perhaps there is a strategy that would work, such as identifying the architecture of the Pi Zero, 2 and 3 and defaulting everything else, but I was not confident I could future-proof this mechanism.  With options A and C, the problem does not occur, because the user can find the correct selection by trial and error.  Once found, the news would probably spread quickly via AtariAge and other channels, and we could update the documentation and menus on the next release with no urgency.
• The two binaries each maintain their own atari800 configuration file with their own specific content.  Users sometimes want to look inside these and copy them etc., but if we automate the binary selection it is no longer clear which one is in use, which may cause confusion.  This might sound like a small matter, but I can imagine users getting really exasperated by it on occasions.  In this respect B looks like a good way to make a simple thing complicated.  A is a little better because the selection is manual, and C is crystal clear because there is only one configuration file.

 

[zzip]

21 minutes ago, hatchcliff said:

It presents a maintenance problem when new models of Pi are released, because the system may fail to identify them.  Users would have to wait until the next release for a fix - or we could issue a patch, but that doesn't seem very satisfactory.  Perhaps there is a strategy that would work, such as identifying the architecture of the Pi Zero, 2 and 3 and defaulting everything else, but I was not confident I could future-proof this mechanism. 

I don't think this is an issue because if a new, incompatible pi model is released, the binary would not exist in the package anyway so people with that new Pi would not be able to use any package anyway until an update is released.   The updated package would add additional binaries as well as a way to detect if they are needed

 

24 minutes ago, hatchcliff said:

The two binaries each maintain their own atari800 configuration file with their own specific content.  Users sometimes want to look inside these and copy them etc., but if we automate the binary selection it is no longer clear which one is in use, which may cause confusion.

why is it necessary to have different configuration files for the different binaries?

[E474]

Hi @hatchcliff,

 

   Thanks very much for updating us all on this, I don't know enough about packaging to offer a lot of advice, but I think I would go with option C as it is putting the decision into the hands of the end user. I saw @HiassofT mentioned there was a split on RPi 0/1 using the old graphics architecture/driver, and there is also the Pi4 versus Pi3/2 architecture (64 v 32 bit), so maybe there are 3 packages to be built? Also, the Pi1 can be over-clocked, so it might be possible to get atari800 up and running, especially given the notes from Hias on the old versus new graphics driver, and being a bit brutal with removing installed packages, Window Manager and Desktop Environment, etc. (I guess?).

 

   I also think using the update-alternatives mechanism might simplify things, as it gives the opportunity to explain the context for the choices, using a uniform front end.

 

   Perhaps checking in the program if the package is actually correct for the RPi it's being run on, and issuing a (skipable) warning if it isn't, is the simplest approach, at least that way the user is notified if they have installed the wrong package, or if the package is running on hardware that has just been released, and is yet to be fully tested/supported. It also provides an opportunity for the user to install the package of their choice for people who have an unusual configuration, etc.

 

   I don't understand why there are 2 different configuration files, isn't it better to just ignore configuration options that don't apply?

 

   Also, sorry to hear you aren't enjoying the packaging process, I wasn't very happy about not having an atari800 executable on the Pi, but it's not so good when people don't enjoy the situation to the point where they no longer want to get involved. I remember the RespeQt developer also stopped work on that project as it stopped being fun, I'm sure other people have also stopped for similar reasons, and I think we are all the poorer for that.

[HiassofT]

I'd say keep it as simple as possible regarding packaging.

 

An atari800-rpi package (with the legacy proprietary driver) that conflicts with atari800 package should do fine, I guess.

 

I'm not really sure if there are much use cases where having both versions installed at the same time would make too much sense - and differences in config files can cause headaches. Pre-built images and switching the same SD card between RPi0/1 and 2/3/4 are the only ones I can think of ATM but I guess these are really rare cases.

 

atari800 then could use the standard debian packaging already present (though not updated to 5.0.0 IIRC) and is nothing you need to worry about - except running dpkg-buildpackage on arm and arm64 ?

 

so long,

 

Hias

[hatchcliff]

On 6/8/2022 at 4:36 PM, zzip said:

why is it necessary to have different configuration files for the different binaries?

 

On 6/8/2022 at 9:15 PM, E474 said:

 I don't understand why there are 2 different configuration files, isn't it better to just ignore configuration options that don't apply?

The configuration files created by the two binaries contain a lot of fields in common, but also some that are unique to each.  If you swap the SD card  between a Pi 3 and a Pi 4, for example, saving the file on the Pi 3 will erase all the settings that are unique to the Pi 4, and vice versa, if a single file is used.  Two separate files avoid this.

 

We could run the two-binary package with a single configuration file if we chose to support one type of Pi only, and didn't allow swapping of the SD card to the other types, but we then end up with a package that installs an extra binary that will never be used on every machine and is therefore more complicated than it needs to be - better to revert to separate packages in my opinion.

Edited June 11, 2022 by hatchcliff

[E474]

Ah,

 

   OK, wouldn't a settings buffer solve this, just update any changed values, and write out the whole buffer on save (I assume this isn't done with the current code, though)?

[+DjayBee]

7 hours ago, hatchcliff said:

The configuration files created by the two binaries contain a lot of fields in common, but also some that are unique to each.

Why don't you use one file with subsections per "binary" like in Windows INIs using [Square Brackets]?

 

[Main]
foo = bar

[RPi3]
videomode=15

[RPi4]
videomode=16

[RPi99]
videomode=brainplug

 

Edited June 11, 2022 by DjayBee

[hatchcliff]

@E474and @DjayBee

 

This is getting a bit off topic.  The discussion so far has been all about packaging, but changing the way the configuration files are handled would be a coding issue.

 

I don't think there is anything wrong with the configuration mechansim as it is.  The binaries for all target machines recognise settings that are appropriate for the hardware they run on.  Buffering and grouping wouldn't alter that fact.  (Actually, the system is already buffered.)

[+DjayBee]

8 hours ago, hatchcliff said:

This is getting a bit off topic. 

IMHO not really.

You complained that you need two configuration files because both binaries keep platform-specific information in it/them.

I (believe to have) showed you way around this problem.

 

But it certainly is your project and therefore you decide.

[zzip]

On 6/11/2022 at 5:37 AM, hatchcliff said:

The configuration files created by the two binaries contain a lot of fields in common, but also some that are unique to each.  If you swap the SD card  between a Pi 3 and a Pi 4, for example, saving the file on the Pi 3 will erase all the settings that are unique to the Pi 4,

Is it common to share SD cards like this?   Both my Pi2 and Pi400 have their own SD card, and it never occured to me to try swapping them.

 

Anyway, if that's the concern, it seems like the approach of making atari800 a script that determines the correct version to run and passes in the correct conf file might be the best way around this.

[hatchcliff]

I suspect that swapping SD cards between different models of Pi is not very common, but even if it is, I think we should drop atari800 support for it.

 

I know opinions vary, but my preferred option is to revert to separate packages for different models, for reasons outlined in post #26.  I think this is a good solution for all parties: users and package maintainers.

[akator]

I'm having strange troubles with the latest Atari800 on a RPi3B.  I just installed the latest version of RPi OS Full Desktop yesterday and succeeding in installing and compiling tons of other software and emulators.

 

Except for some strange reason, Atari800 is giving me trouble.  I don't get it because I've had it running plenty of times before on many different systems (and OSes) with no problem.

• When I tried to install from the .deb by double clicking and it gave missing dependency error but without specifying what.
• So I could get more info, I installed with

  sudo dpkg -i atari800_5.0.0_rpi.deb

  Which resulted in

  Selecting previously unselected package atari800.
  (Reading database ... 201268 files and directories currently installed.)
  Preparing to unpack atari800_5.0.0_rpi.deb ...
  Unpacking atari800 (5.0.0) ...
  dpkg: dependency problems prevent configuration of atari800:
   atari800 depends on libreadline7 (>= 6.0); however:
    Package libreadline7 is not installed.
  
  dpkg: error processing package atari800 (--install):
   dependency problems - leaving unconfigured
  Processing triggers for gnome-menus (3.36.0-1) ...
  Processing triggers for mailcap (3.69) ...
  Processing triggers for desktop-file-utils (0.26-1) ...
  Processing triggers for man-db (2.9.4-2) ...
  Errors were encountered while processing:
   atari800

• So then I tried to install with

  sudo apt-get install libreadline-dev

  Which resulted in

  Reading package lists... Done
  Building dependency tree... Done
  Reading state information... Done
  libreadline-dev is already the newest version (8.1-1).
  You might want to run 'apt --fix-broken install' to correct these.
  The following packages have unmet dependencies:
   atari800 : Depends: libreadline7 (>= 6.0) but it is not installable
  E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).

• Any attempts to fix broken packages resulted in the same error.

I then removed everything and tried to install 4.2.0 again from the RPi OS software app and that wouldn't work, either.

 

Any suggestions?

[TGB1718]

I had some issues installing RetroPie on my RPI3B, again it was when trying to install some packages.

What fixed it for me was something I came across via Google.

 

Usually you do "sudo apt-get update"

then "sudo apt-get upgrade"

 

but the fix was 

do "sudo apt-get update"

a second time, then re-boot and it was all fixed.

 

This may not help you, but probably worth a try.

[hatchcliff]

7 hours ago, akator said:

So then I tried to install with

sudo apt-get install libreadline-dev

 

libreadline-dev contains development files that are needed to compile the emulator, but not to load it precompiled from a deb file.

I think the package you need is libreadline7:

sudo apt-get install libreadline7

 

[akator]

Thanks for the replies.

Package libreadline7 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source

I researched this further and libreadline7 has disappeared from repositories.  There's 6 and 8 but no 7.  I followed something on a another site for another package that suggested making a symlink for libreadline.so from 8 and successfully did that but it still didn't work.

 

Just to make sure, I installed synaptic and libreadline7 isn't there.

[akator]

I searched sourcearchive.raspian.org and there's no libreadline7 there, either.

 

EDIT: This libreadline7 error started when I installed Atari800 5.0.0 from the deb package.  It is only after not being able to install the deb that I tried to build from source.

Edited July 9, 2022 by akator
Details

[hatchcliff]

I haven't been able to replicate this problem.

On my system libreadline7 is present, and available in the repository.

I tried a clean install of PiOS Full on my Pi 3 using the Raspberry Pi Imager V1.04, and I let the system update itself from the default repository on the first run.  This standard setup shows several libreadline packages available, including run-times libreadline5, 6 & 7.

pi@raspberrypi:~ $ apt-cache search libreadline
cupt - flexible package manager -- console interface
libreadline-dev - GNU readline and history libraries, development files
libreadline-gplv2-dev - GNU readline and history libraries, development files
libreadline-java - GNU readline and BSD editline wrappers for Java
libreadline-java-doc - API docs for readline/editline wrappers for Java
libreadline5 - GNU readline and history libraries, run-time libraries
libreadline5-dbg - GNU readline and history libraries, debugging libraries
libreadline6 - GNU readline and history libraries, run-time libraries
libreadline6-dbg - GNU readline and history libraries, debugging libraries
libreadline7 - GNU readline and history libraries, run-time libraries

libreadline6 & 7 were installed by default.

pi@raspberrypi:~ $ dpkg --get-selections | grep libreadline
libreadline6:armhf				install
libreadline7:armhf				install

atari800_5.0.0_rpi.deb installed and ran with no problems.

 

My interpretation is that the root cause of the problem on your system is not linked to atari800_5.0.0_rpi.deb, but to the absence of libreadline7.  Is this how you see it too?

The puzzle is what happened to libreadline7, and why can't you find it in the repository.  I don't know the answer, but it is clear that we must be doing something different.

If you have a spare SD card, perhaps you could try a clean install as above, and see if that works.

 

[HiassofT]

@hatchcliff Are you maybe running the old Buster RPiOS? Default on current Bullseye is libreadline8 (8.1.1). libreadline5 and 6 seem also to be available (not sure why though), but not version 7.

 

pi@raspberrypi:~ $ apt-cache search -n libreadline
libreadline-dev - GNU readline and history libraries, development files
libreadline-gplv2-dev - GNU readline and history libraries, development files
libreadline-java - GNU readline and BSD editline wrappers for Java
libreadline5 - GNU readline and history libraries, run-time libraries
libreadline5-dbg - GNU readline and history libraries, debugging libraries
libreadline6 - GNU readline and history libraries, run-time libraries
libreadline6-dbg - GNU readline and history libraries, debugging libraries
libreadline8 - GNU readline and history libraries, run-time libraries
pi@raspberrypi:~ $ apt-cache policy libreadline-dev
libreadline-dev:
  Installed: 8.1-1
  Candidate: 8.1-1
  Version table:
 *** 8.1-1 500
        500 http://raspbian.raspberrypi.org/raspbian bullseye/main armhf Packages
        100 /var/lib/dpkg/status
pi@raspberrypi:~ $ cat /etc/apt/sources.list
sources.list    sources.list.d/ 
pi@raspberrypi:~ $ cat /etc/apt/sources.list.d/raspi.list 
deb http://archive.raspberrypi.org/debian/ bullseye main
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
#deb-src http://archive.raspberrypi.org/debian/ bullseye main
pi@raspberrypi:~ $ cat /etc/apt/sources.list
deb http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi
# Uncomment line below then 'apt-get update' to enable 'apt-get source'
deb-src http://raspbian.raspberrypi.org/raspbian/ bullseye main contrib non-free rpi

 

EDIT: BTW RPi Imager 1.04 seems ancient, current version is 1.7.2 - maybe that's downloading old versions?

 

so long,

 

Hias

Edited July 9, 2022 by HiassofT

[hatchcliff]

Thanks @HiassofT, that was indeed the problem.  I did not know that the Imager was not automatically updated, or that older versions of it were linked to older distributions.  So I have been stuck on Buster for some time without realising it.

Thank you @akator for raising this issue, and apologies for the incorrect response in my previous post - it seems that the problem is with atari800_5.0.0_rpi.deb after all.

As well as libreadline7, some legacy Broadcom libraries upon which the Pi Zero, 2 and 3 versions of atari800 depend also seem to have been dropped from Bullseye.  I will check the details and see if I can build new Pi package(s) for possible re-release.

 

 

[HiassofT]

I had a quick go at it and built a deb package for RPiOS bullseye on my 3B+ - only change was bumping the version in debian/control https://github.com/HiassofT/atari800/tree/debian-5.0.0

 

When running atari800 from console it can't use OpenGL ES as the ancient SDL1.2 doesn't know anything about it (you'll only get GL when run from a desktop environment).

 

BUT: there's now sdl1.2-compat providing a 1.2 compatible wrapper around SDL2 (which knows about GL ES and works fine from console) and it's already packaged for Debian Bookworm (aka testing). Building it on Debian or RPiOS Bullseye is straight forward and from a very quick test it seems to be working fine on my 3B+.

 

I've attached the debs, you won't need libsdl1.2-compat-dev unless you want to compile atari800 from source, and after installing them with sudo dpkg -i you also need to run "apt-get -f install" to pull in the libsdl2 and other dependencies.

 

Beware: libsdl1.2-compat-shim replaces libsdl1.2debian so that may break other packages - run apt-get install libsdl1.2debian to remove the compat libs and get back the real SDL1.2 libs.

 

EDIT: forgot to add, you should be running full kms driver (i.e. have dtoverlay=vc4-kms-v3d in your config.txt, as is the default now) and performance will most likely completely suck on the original RPi 1 or the 0 (RPi 2 and up and also RPi zero 2 W should be fine). RPi 0/1 only provide acceptable GL performance with the old proprietary libs which offload some of the heavy lifting in GL to the videocore GPU. You could still give it a try but my experience with kodi was terrible (that's why we dropped RPi0/1 support in LibreELEC) so you have been warned ?

 

so long,

 

Hias

atari800_5.0.0-1_armhf.deb libsdl1.2-compat_1.2.52-4_armhf.deb libsdl1.2-compat-shim_1.2.52-4_armhf.deb libsdl1.2-compat-dev_1.2.52-4_armhf.deb

Edited July 9, 2022 by HiassofT

[hatchcliff]

@HiassofT, thank you so much for this.  You have thrown a lot of light on a situation that had become very confusing, to me at least.

 

I've been reading about Bullseye.  The development of the new Linux standard KMS video driver is good news.  It promises much greater consistency than we had in Stretch and Buster, with their mix of standard and non standard (Pi specific) graphics libraries.  I don't know if I'm reading too much into this, but I wonder if this development completely obviates the need to release multiple atari800 packages.  Could a single Debian package serve all supported models of Pi in future?

 

The special version produced for the Zero, 2 and 3 in the past looks like a legacy item now, because it depends on the Pi specific Broadcom libraries lbrcmGLESv2 and lbrcmEGL which have been dropped from Bullseye.

 

I'm currently testing the Debian version of atari800 with Bullseye on all the different models to confirm which can run it.  So far it's looking good on the Pi 3 and 4.  I'm not sure about the Zero and 2 yet.  This will take a while because I want to check the performance fairly thoroughly - I will post the results when I have them.

 

[HiassofT]

Yea, the move to standard libraries/API is an awesome thing, finally not having to worry about RPi specifics and being able to compile+run programs like on x86 PCs without having to jump through lots of hoops or patching stuff is a great relief.

 

I guess a single package/binary will be fine in the future (OK, two, as there's also 64bit RPi OS).

 

As for performance I guess RPi2 and RPi Zero 2 W should be fine, they are pretty much in the same ballpark as RPi3B/3B+ - and it RPi2 has some margin for overclocking if stuff is a bit on the edge.

 

RPi 1 and the first RPi1-based RPi Zeroes will be interesting. It could well be that performance with KMS isn't that bad as with kodi as kodi GUI is quite taxing on GL (lots of elements/textures displayed on screen etc) whereas I think atari800 pretty much just blits it's small texture to screen (upscaling to fullscreen is pretty much "free" as it's done in hardware).

 

If RPi1 performance with KMS is't too great the big question will be if it's actually worth to jump through hoops to build atari800 with legacy library support and how viable that would be long term. And, most importantly, if there's actually demand for it.

 

In LibreELEC we dropped support for RPi1 in our last release, 512MB simply is too tight to properly run current kodi and as mentioned before GUI performance sucked (roughly half or even less FPS than with legacy proprietary driver).

 

This wasn't a huge deal and - a bit surprising - we didn't even receive complaints about it. RPi0-4 make up roughly 80% of LibreELEC userbase (total across all LE versions), but RPi0/1 only accounts for about 1-2% total - lots of users have moved to newer RPi models and also lots of users of older RPis are sticking to older LibreELEC releases - sure, if it's working fine then there's no pressing need to update.

 

So, even if RPi0/1 performance completely sucks with KMS/Bullseye a viable way would be to provide a Buster RPi1 build with legacy support (if there's actually demand for it) for some time.

 

Happy testing and keep us posted about the results, I'm quite interested in the performance measures!

 

so long,

 

Hias

[hatchcliff]

To recap, the currently released v5.0.0 atari800 Raspberry Pi package contains two binaries for different models of Pi, in contrast to earlier versions which were released as two separate packages.  There was a lot of discussion about this, but it was all rendered irrelevant by the discovery that the package had been accidentally built for Pi OS Buster, not the latest Bullseye.  Bullseye has a new Linux standard KMS video driver, which is good news because it promises much greater consistency, and possibly eliminates the need for multiple binaries or packages.  However, it was not known initially whether it would perform well enough to support atari800 on a good range of Pi models.

 

I've been running performance tests, and the results are encouraging so far.  It appears that the stock Linux version of atari800 runs well with Pi OS Full 32-bit Bullseye on the Pi 2, 3, and 4.

 

Here is the experimental package used in the tests:

atari800_5.0.0_rpi_bullseye32_exp1.deb

 

It is built from from atari800-5.0.0-src.tgz, and is the same as atari800_5.0.0-1_armhf.deb posted by HiassofT except for the addition of a menu and icon.

 

Please give it a try if you are a Pi user, and let me know if it runs well for you or not.  I am particularly interested to hear from anyone who has a quad-core Pi Zero 2 W or a 400, because I don't have these available for test.  CPU loading varies with different monitors etc., so it is useful to check all the models with as many different setups as possible.  If the feedback is positive I will try to get the package released officially.

 

To install, copy the deb file to your Pi and <double click> on it.  You don't need to load anything else, because all dependencies are included as standard in Bullseye.

 

Performance is good with video hardware acceleration turned off in atari800's menu (<F1>, <Display Settings>, <Video mode settings>, <Hardware acceleration:>, set to <No>).

 

One limitation I have found is that the Pi 2 cannot run the emulator at full speed in large windows.  However, full screen mode works fine.  Bearing in mind that previous releases for the Pi 2 ran permanently in full screen mode, I don't think this is a problem.

 

I have also run the package on the Pi 1B and Zero W, but it overloads these machines.  They can support tiny images, but nothing approaching full screen.  The Pi 1 was dropped from the support list in v4 for this reason.  Now it seems that we have to drop the single-core Zero too, which is a shame - but probably just another step in an inevitable progression.

 

I have had no success running the package on Bullseye Lite.  Lite does not contain the KMS driver by default, and although it can be installed easily using raspi-config, it does not work properly with atari800 - I don't know why.  The solution is to use Full.

 

See the attached pdf for detailed results of the performance tests, including the effects of hardware acceleration and the SDL2 wrapper provided by HiassofT.

Pi Test Results.pdf

 

@HiassofT, I've reported the results as I found them, but I don't have explanations for them all.  I'm not clear on the limitations of SDL1.2 (running without the wrapper).  Loading goes down on the Pi 3 and 4 when acceleration is turned on, which is good, but I don't understand how this happens if SDL1.2 knows nothing about acceleration in full screen mode.  Another thing that surprised me was that the SDL2 wrapper increased CPU loading in all cases, the opposite of what I had expected.  Let me know if you can see anything wrong with my test method, but for the time being I'm not planning further tests with the wrapper, because performance is good without it.

 

[hatchcliff]

The instructions for building the Raspberry Pi version of atari800 are out of date on GitHub.  I'm planning to update them soon, to make them work with the current Bullseye release of Pi OS.

 

No problems have been reported with the experimental package released in my previous post, so I'm hoping to make this the basis for the update.  If anyone did find problems, please let me know, and I will see if they can be fixed or at least documented.

 

Bullseye contains a new standard KMS video driver which appears to be efficient enough to support atari800 on a good range of Pi models.  This is very promising because it means we can potentially start to treat the Pi as a standard Linux platform, and stop trying to keep up with quirky Pi-specific developments that appear and disappear without notice in successive releases of Pi OS - all these quirks seem to have been dropped from Bullseye.