Jump to content

hatchcliff

Members
  • Posts

    102
  • Joined

  • Last visited

Profile Information

  • Gender
    Male
  • Location
    Edinburgh, UK

Recent Profile Visitors

6,448 profile views

hatchcliff's Achievements

Chopper Commander

Chopper Commander (4/9)

58

Reputation

  1. Zooming in on the 3rd photograph, is that a broken track running between pins 2 and 3 of U17? Can't be sure from the picture - but maybe worth checking.
  2. Anyone else having problems installing Pi OS Full on the Pi Zero 2? I tried a clean reinstall yesterday, and had multiple problems: The latest version of the Raspberry Pi Imager (1.8.4) offers only Bullseye for the Zero 2, but Bookworm is required for atari800 v5.2.0. I downloaded Pi OS Full 64-bit Bookworm from here, wrote the image to an SD card, but the Zero 2 would not boot from it. The splash screen came up for a moment, then nothing - just a blank screen. Tried Pi OS Full 32-bit with the same result. Thought my Zero 2 might be faulty, so tried another one, also different power supplies and SD cards - all with the same result. Both my machines work; they run Pi OS Lite 64-bit fine, but this is no good for atari800 because it requires the Full version. Something seems to go wrong with the first boot after installation. The Raspberry Pi website says that the Zero 2 can run Pi OS Full 32 and 64-bit, so I hope this is just a temporary software development glitch. There is no doubt that the Zero 2 can run atari800, the only challenge is getting Pi OS Full to run first. I eventually found a torturous way to do this, but I'm not recommending it - if anyone knows a better way, please let us know. Download Pi OS Bookworm 32-bit from here, and write the image to an SD card. 32-bit seems to be the only option - I had no luck with 64-bit at all. To get through the first boot, install the card in a different model of Pi. I used a Pi 4, but I'm sure a Pi 5 would also do, and possibly other models. Install the armhf version of atari800. Transfer the SD card to the Zero 2. It should now boot and run atari800 OK.
  3. No, there is no automatic setting, so it is necessary to adjust a few settings by hand in this situation. I do the same when I switch monitors occasionally.
  4. Atari800 v5.2.0 has been released, and is available for download from the GitHub Releases Area. Three Linux packages are provided for different computer architectures: atari800_5.2.0_amd64.deb for amd64 64-bit machines, including PCs with AMD and Intel 64-bit processors. atari800_5.2.0_armhf.deb for armhf 32-bit machines, including the Raspberry Pi 2 running Pi OS 32-bit. atari800_5.2.0_arm64.deb for arm64 64-bit machines, including the Raspberry Pi 'Zero 2', 3, 4 and 5 running Pi OS 64-bit. Installation Upgrade to the latest (Bookworm) release of Linux. Download the appropriate deb file for your machine. Some Linux distributions allow you to <Double Left Click> on the deb file to install it, or <Right Click> and select <Package Install> or similar. If these methods don't work on your distribution, use the command sudo dpkg -i <deb file name>. Look out for messages about missing dependencies. For example, if you are informed that libsdl1.2debian is missing, you will need to install it with the command sudo apt-get install libsdl1.2debian. During installation, any previously installed version is automatically removed. The configuration file .atari800.cfg in your home directory contains version specific information. If you are replacing an old version of atari800, it is usually possible to update the configuration file and retain your original settings. To do this, run the newly installed atari800 and select <F1>, <Emulator Configuration>, <Save configuration file>. This writes out the file with any obsolete information removed and new information inserted. Restart atari800 and check that it runs normally. If it does not, delete .atari800.cfg, let atari800 generate a default version the next time it runs, and work through the menu system to restore your settings manually. When installation is complete, Atari800 appears in the games section of the main menu. You can run it by <Left Clicking> on this or using the command atari800. Release Notes Screen Resolution Bugs Two related bugs have been reported during testing. Some systems have been found with one or both bugs, but others, including all the Raspberry Pis, have neither. Fortunately the bugs affect initial setup only, and effective workarounds have been found. The bugs are: If you run at reduced fullscreen resolution, the desktop's original resolution is not restored when atari800 exits, which usually renders the desktop unusable, requiring a reboot. The emulator really needs to be run at full monitor resolution because of the above bug, but the menu for setting this crashes. Changing the resolution on the fly seems to be the specific problem. The workarounds are just alternative methods of setting fullscreen resolution without crashing. You can either: Avoid changing the resolution on the fly. Instead, use the menu system to come out of fullscreen mode, change the fullscreen resolution to the maximum offered (at the bottom of the selection list), then go back into fullscreen mode and save the configuration file. or: Determine the resolution of your monitor and use a text editor to enter it directly into the configuration file .atari800.cfg. For example, if your monitor resolution is 1920x1080, search the file to find the keywords below and set their values as shown: VIDEOMODE_FULLSCREEN_WIDTH=1920 VIDEOMODE_FULLSCREEN_HEIGHT=1080 Desktop Scaling Some Linux distributions allow you to scale the desktop. This feature is primarily intended for use on laptops with HD screens, which are capable of displaying text in such fine detail that it becomes unreadable. Increasing the scale, to 125% say, makes the desktop easier to read, but tests with Linux Mint showed that this setup is incompatible with atari800's fullscreen mode. No other distributions have been tested, but it is assumed that they are likely to have the same problem. To run atari800 on these systems you either have to leave the scale at the default 100%, or run in Window mode only. Raspberry Pi Release Notes The Pi 1 and and the single core Zero are not supported. They can run atari800 in tiny windows, but nothing approaching full screen. Larger images overload their processors, producing choppy sound and video. The atari800 menu allows you to select the fullscreen resolution using <F1>, <Display Settings>, <Video mode settings>, <Fullscreen resolution:>. It defaults to 640x480, but you can increase it to obtain more accurate representations of Atari screens. The available selections go right up to the resolution of your monitor. However, you may find that you overload the processor on some Pis at a certain point, resulting in choppy audio and video. If this happens, back off to a lower resolution. To make full use of the screen and preserve the aspect ratio while you make these adjustments, set <Host display aspect ratio:> to match you monitor (or select <autodetect>), set <image aspect ratio:> to <authentic> and <Stretch image:> to <fit screen - full>. The Pi 2 cannot run atari800 at full speed in large windows, but fullscreen is OK. The Pi Zero 2 has only one USB port. If you buy this machine to run atari800 you will also need to buy a USB hub to allow simultaneous connection of the keyboard, mouse and joystick. Hardware graphics acceleration is not required, and should be turned off by default. It is effective in reducing CPU load on the Pi 3, 4 and 5, but is very detrimental on other models. Set <F1>, <Display Settings>, <Video mode settings>, <Hardware acceleration:> to <No>. The Raspberry Pi Imager offers Ubuntu Desktop 64-Bit as an alternative operating system, but it imposes higher CPU loading than Pi OS. Only the Pi 5 is powerful enough to run atari800 at full speed on Ubuntu.
  5. I've checked out atari800 with Pi OS Bookworm, and it runs OK. The screen resolution bug has been fixed, so it is worth upgrading. Here's how to get up to date: 64-Bit Systems, Pi 3, 4, 400, Zero 2 (and probably 5, but it is untested as yet) Install Pi OS Bookworm 64-bit. sudo apt-get install atari800 It is possible (but not recommended) to run Pi OS 32-bit on the 64-bit machines. If you choose to do this, you will need to follow the installation procedure for 32-bit systems below. 32-Bit Systems, Pi 2 and Others Running Pi-OS 32-Bit Install Pi OS Bookworm 32-bit. Atari800 is not in the Bookworm 32-bit repository, so you need to download atari800_5.0.0-1_armhf.deb from the Debian Project's Website. sudo dpkg --install atari800_5.0.0-1_armhf.deb Raspberry Pi Performance Limitations The atari800 menu allows you to select the fullscreen resolution using <F1>, <Display Settings>, <Video mode settings>, <Fullscreen resolution:>. It defaults to 640x480, but you can increase it to obtain more accurate representations of Atari screens. The available selections go right up to the resolution of your monitor. However, you may find that you overload the processor on some Pis at a certain point, resulting in choppy audio and video. If this happens, back off to a lower resolution. To make full use of the screen and preserve the aspect ratio while you make these adjustments, set the <Host display apect ratio:> to match you monitor (or select <autodetect>), set <image aspect ratio:> to <authentic> and <Stretch image:> to <fit screen - full>. Atari800 Requires Pi OS Full. It may run OK with Pi OS Lite on certain machine/monitor combinations, but in general it cannot support proper fullscreen images running at full speed. The Pi 1 and single core Zero are not supported. They are too slow. The Pi 2 cannot run atari800 at full speed in large windows, but fullscreen is OK. Hardware graphics acceleration is not required, and should be turned off by default. It is effective in reducing CPU load on the Pi 4 (and probably 5), but is very detrimental on other models. Set <F1>, <Display Settings>, <Video mode settings>, <Hardware acceleration:> to <No>. The Raspberry Pi Imager offers Ubuntu Desktop 64-Bit as an alternative operating system, but it loads up the CPU more than Pi OS, and cannot run atari800 at full speed.
  6. Performance is fine, but it probably wouldn't be everyone's first choice for running atari800 because of its single USB port. You have to use some kind of hub to connect the keyboard/mouse and joystick.
  7. The build instructions have been updated on GitHub, and two new packages have been placed in the Releases Area atari800-5.0.0-armhf.deb - for 32-bit Debian based systems, Bullseye. atari800-5.0.0-arm64.deb - for 64-bit Debian based systems, Bullseye. An efficient KMS video driver was introduced in Pi OS Bullseye, allowing it to run the stock Debian version of atari800 on a wide range of Pi models. Hence there is no longer any need for special Raspberry Pi versions. However, we now have 32 and 64-bit operating systems for the Pi, and we need two packages to cover these. The new packages run on the Raspberry Pi, and on all other armhf/arm64 Debian based systems. The Raspberry Pi Imager offers Ubuntu Desktop 64-bit as an alternative operating system, and the 64-bit package runs on this too. The original v5.0.0 release, atari800_5.0.0_rpi.deb, is still available, but it is a legacy version for Pi OS Stretch and Buster only. It was released in error, well after Pi OS Bullseye was launched. The purpose of the GitHub Releases Area is to to distribute new versions of the emulator quickly, usually making them available months before their official release by the Debian Project, but on this occasion we are playing catch up, because it took a while to identify the problems in the original release and to determine a better development route. Pi OS Bookworm was released last week. The above packages run OK on it. However, official atari800 Bookworm packages are available from the Debian Project, and it is better to use these, to ensure compatibility. I will post more information when I have had a chance to try them out. Raspberry Pi Performance Limitations There are some minor performance limitations as follows. I'm planning to document these on GitHub. If anyone discovers more, please let me know, and I will add them to the list. I think some of them might have been corrected in Bookworm, in which case the list may end up shorter. Atari800 Requires Pi OS Full. It will not run at full speed on Pi OS Lite. The Pi 1 and single core Zero are not supported. They are too slow. The Pi 2 cannot run atari800 at full speed in large windows, but fullscreen is OK. Hardware graphics acceleration is not required, and it is best to turn it off. It is effective in reducing CPU load slightly on the Pi 4/400, but it increases loading on all other models and is very detrimental. Set <F1>, <Display Settings>, <Video mode settings>, <Hardware acceleration:> to <No>. The atari800 menu item for selecting higher screen resolutions does not work with Pi OS. It is best to leave <F1>, <Display Settings>, <Video mode settings>, <Fullscreen resolution:> at its default value and play around with the other Video mode settings as usual to get the size and aspect ratio of the fullscreen image right. There is a problem with the fullscreen resolution in Ubuntu too. The menu works, but higher resolutions overload the processor, causing choppy sound and video.
  8. 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.
  9. 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.
  10. @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.
  11. 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.
  12. 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.
  13. 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
  14. 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.
  15. @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.)
×
×
  • Create New...