Previous on Raspberry Pi 3B+ Anyone Try it?

Started by slabowner1701, June 23, 2020, 10:42:59 AM

Previous topic - Next topic

slabowner1701

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


pitz

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

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

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.

nuss

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
DON'T PANIC

pitz

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/ which is equivalent in processor power as the Raspberry Pi 3B+, but in a smaller form factor, and runs 64-bit Debian.

20201225_152205.jpg

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

20210115_162807.jpg

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.

rcfa

Quote from: pitz on October 11, 2020, 02: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

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

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/

pomosapien

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...


pomosapien

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!

andreas_g

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.

pomosapien

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?

pomosapien

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

pomosapien

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.

pomosapien

#11
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.

pomosapien

@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?

andreas_g

#13
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.