Previous on Raspberry Pi 3B+ Anyone Try it?

Has anyone ran Previous on a Pi 3B+

Ive compiled it and get it to launch but I have video issues if i launch it directly from the command line,   when the pi desktop is up and running I lose the video glitches but the main menus wont close,  They just stay stuck open. 

Anyone got any tips to getting this working right? 

Thanks

I snuck in a couple of hours to look for that bug where the emulator dialogs/menus won't close.  Got it fixed on my fork in GitHub https://github.com/kernelcoredump/previous (https://github.com/kernelcoredump/previous)

I've also got an RPi AppImage release from a continuous integration build of the master branch.  Download the AppImage, change the properties to executable, and run.
https://github.com/kernelcoredump/previous/releases (https://github.com/kernelcoredump/previous/releases)

At worst, you can clone the repo and rebuild the binaries.  There are two feature branches ahead of the master branch with work-in-progress code.

Hi pitz,

your RPi AppImage runs very well on a Pi400 in fullscreen, color and with sound :)
Excellent work, thanks alot.

As next step I want to try to activate networking.
Cheers, Nuss

I've been busy trying several SOC devices over the past few weeks.  One of them was the Orange Pi Zero2 http://www.orangepi.org/Orange%20Pi%20Zero2/ (http://www.orangepi.org/Orange%20Pi%20Zero2/) which is equivalent in processor power as the Raspberry Pi 3B+, but in a smaller form factor, and runs 64-bit Debian.



I have enabled a 64-bit arm64/aarch64 AppImage build on GitHub https://github.com/kernelcoredump/previous/releases (https://github.com/kernelcoredump/previous/releases).  Good news is that it runs on the Orange Pi Zero2.



Not so good news is that, as I suspected, the processor power is not enough for a usable Previous experience. I pulled out my RPi 3B+ to confirm, and it does have the same result as the Orange Pi Zero2.

It does seem that the minimum requirements for a usable experience would be the RPi4 for now.  The arm64/aarch64 AppImage should also run on the beta RPiOS 64-bit.

I might eventually start taking a look at the emulator code to see if it can utilize all cores on the RPi; it looks like some multithreading improvements can be made to make it usable on the RPi 3B+. As you may have noticed, Previous uses up 100% of one of the processor cores when it is running, and I'd first like to see if this can be mitigated.

Quote from: pitz on October 11, 2020, 04:29:19 AMI snuck in a couple of hours to look for that bug where the emulator dialogs/menus won't close.  Got it fixed on my fork in GitHub https://github.com/kernelcoredump/previous (https://github.com/kernelcoredump/previous)

I've also got an RPi AppImage release from a continuous integration build of the master branch.  Download the AppImage, change the properties to executable, and run.
https://github.com/kernelcoredump/previous/releases (https://github.com/kernelcoredump/previous/releases)

At worst, you can clone the repo and rebuild the binaries.  There are two feature branches ahead of the master branch with work-in-progress code.

Given that Previous 2.3 was just release and there are even a few repo commits after that release, did you ever push your changes back into the main code repository, or is there a need to somehow merge your changes back in there?

https://sourceforge.net/p/previous/code/HEAD/tree/

Ooh, how small of an object can run NEXTSTEP?

To get a baseline, a build on Pi 3B runs at 30-50% speed emulating a 25MHz 040.  Under X, it uses all 4 cores continuously at idle and triggers the temperature warning.

On Pi 4 under X, we can get 100% speed, using 1.5 cores continuously at idle.  No temperature alert.

Used Previous 2.2 with all the optimizations i know of applied.

To remove X from the equation, tried getting SDL to draw OpenGL to the Linux console framebuffer directly (that's how lots of emulators run on the Pi).  Had to tweak the code remove image tearing but eventually it does draw with framebuffer scaling to 1080 pixels high.  Curious what the idle CPU utilization is, need to get the status bar to work again and add some stuff.

Looking for a picture...

https://drive.google.com/file/d/1ezI8fvRT1fryUH5cqxVW_7B00nV7Zn5c/view?usp=sharing

Hope ppl can reach that.  That's 3.3.  And realized that i can just SSH into the Pi to look at the CPU utilization.

Additional ideas:
* Look at the latest state of Hatari and see any speed improvements could be brought over.
* Print the cube that Nina made and put a Pi into it.  It'll be a little cooler than Nina's since it actually runs NEXTSTEP!

Great! If you have any optimizations that are not specific to the platform please send them to me and I'll add them to the upstream.

All of the optimizations are ARM-specific compiler flags that i can nonetheless send you, understanding that upstream may not want to detect specific platforms and special case them.  Keeping a fork for Raspberry Pi might be a good way to express these specifics.

The change for Linux console framebuffer will apply to most machines running Linux, that may be more interesting.  I broke X behaviour a little but it looks fixable if the statusbar handling is altered a little.

Is a pointer to something on GitHub effective?

Oh, just saw that Previous is probably hosted on SourceForge.  I can post a patchfile and some text in a bit.

Oh pfft

>  I have video issues if i launch it directly from the command line

@slabowner1701 this console change i mentioned might be the fix for your problem, if the display was tearing diagonally and the startup NeXT logo was displayed multiple times but distorted.

The GCC flags i used for a Pi 4 target:

-O3 -mcpu=cortex-a73 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits


It's unquantified how much speedup came from this, but it didn't make anything worse observing the result as a user.

WRT to the console fix, i was going to push it to GitHub but before i create YAF (Yet Another Fork) i want to understand the roles of the existing forks and how they relate to the upstream on Sourceforge.  Will pose that in another thread on that topic.

@andreas_g @pitz i sent a diff for console support to you by PM.
The diff is based on svn trunk [r988].
In essence, the guest (NeXT) framebuffer is sized without using the host (SDL) window size, which isn't always the dimension passed in; for framebuffer console it's the console mode (eg 1920x1080).  SDL will resize the guest to the host while maintaining aspect.  Under X11, host and guest dimensions match.

The change works under Ubuntu/X.  I can't build for Windows*.  Given time i'll test macOS.

Since Sourceforge, the nextcomputer fork and the kernelcoredump fork look divergent i won't make another GitHub fork.

* What system setup is used to cross-compile for Windows?

Thank you for the patch! Seems to work on my Mac (10.11.6).

Building on Windows is possibly broken. Some porting efforts will be required to port the latest NFS/netboot code in branch_filesharing to other platforms (for now only works on macOS).

Update: There was a minor bug in the patch. Statusbar height was not set. I have fixed it. My working branch on sourceforge is branch_softfloat.

Moved Windows topic:
http://www.nextcomputers.org/forums/index.php?topic=4667.0

Hi, Does Previous (NS 3.3) run any faster with sound disabled and in 4 colours only on 3B+ ?

Quote from: pomosapien on September 07, 2021, 05:23:05 PMOoh, how small of an object can run NEXTSTEP?

To get a baseline, a build on Pi 3B runs at 30-50% speed emulating a 25MHz 040.  Under X, it uses all 4 cores continuously at idle and triggers the temperature warning.

On Pi 4 under X, we can get 100% speed, using 1.5 cores continuously at idle.  No temperature alert.

Used Previous 2.2 with all the optimizations i know of applied.

To remove X from the equation, tried getting SDL to draw OpenGL to the Linux console framebuffer directly (that's how lots of emulators run on the Pi).  Had to tweak the code remove image tearing but eventually it does draw with framebuffer scaling to 1080 pixels high.  Curious what the idle CPU utilization is, need to get the status bar to work again and add some stuff.

Looking for a picture...

I realize this is an old message, but I just built Previous 2.9 for Raspberry Pi and it seems to be working well inside X. I'd love to get it working directly on the console, but so far haven't had any luck getting it to operate in that mode.

I'm hoping you can share what you had to do to get it working and the code you changed to remove the tearing. As a test, I was able to run the kmscube demo app with sdl2 without X as well as a couple of other test programs, so I know the underlying capability (or at least part of it) is there.

Quote from: jpasqua on January 01, 2024, 07:15:59 PMI realize this is an old message, but I just built Previous 2.9 for Raspberry Pi and it seems to be working well inside X. I'd love to get it working directly on the console, but so far haven't had any luck getting it to operate in that mode.

I'm hoping you can share what you had to do to get it working and the code you changed to remove the tearing. As a test, I was able to run the kmscube demo app with sdl2 without X as well as a couple of other test programs, so I know the underlying capability (or at least part of it) is there.

following the links in the signature of @pomosapien one can download a binary named Previous-r1077-rpi4-raspios32.tar.gz

this might potentially be what you're looking for..? I did not test this.

http://retro.haleblian.com/next/emu/previous/

I _think_ that wasn't my build, just a repost, i suspect it's for SDL/X11.  Sadly i didn't attribute it in the README up there.  There might be a clue somewhere in this forum...

Y'all bring up a good point about whether console-mode still works now.  When i can i'll try 2.9 with the console; if it works i'll upload something.  With X11 being mucked up by Wayland, console-mode may become even more desirable.

I'm not getting any rendering in console mode with a fresh build.  This might change, some research needs doing.  Thanks for the KMS pointer, it makes me wonder what has changed on Pi/RaspiOS in the interim.  The `kms*` demos are working for me.  SDL seems to know a little about KMS...

BTW IIRC the tearing fix got back into upstream at one point but we may need to verify it's still there and even needed anymore.

For me, a build from trunk with rendering threads turned off gets Previous drawing again, but only black in console mode.  Wayland works.

Maybe ppl could check their mileage using

    http://retro.haleblian.com/next/emu/previous/experimental/previous-2.9-e1-piarm64.zip

1. does this draw anything in console mode, even a blank screen?
2. can you make it work in sway?

Caveats: this is a 64-bit build, probably won't work on 32-bit RaspiOS.

To try this with Wayland/sway:

    sudo apt install sway
    cp /etc/sway/config .
    echo "exec ./Previous" >> config
    sway -c config

where you put Previous in the current directory.

If you get into sway, You can Windows-shift-E to exit sway.