Hello NeXT community,
I'd like to bring back some active development on the Previous emulator. I'm sure there are skillful developers out there who can help out in fixing a few remaining bugs or adding useful features to the emulator.
Most development workflows happen on Git source repos nowadays -- we should move to either GitHub or GitLab. I'd have to ask Andreas, Gilles, and others for permission, uh... forgiveness, as I've already imported the source from SourceForge into
https://github.com/nextcomputers/previous (
https://github.com/nextcomputers/previous) (all branches and all commit history preserved), and subsequently forked into
https://github.com/kernelcoredump/previous (
https://github.com/kernelcoredump/previous)
My primary intent here is to get more developers visibly involved in the open source evolution of the emulator. We could use GitHub pages to host documentation. We could also use GitHub to host pre-built installation packages for several platforms, so others can readily download working binaries of the emulator, and open up the development for new NEXTSTEP/OPENSTEP applications.
As an example, I've set up a build workflow in GitHub that builds the emulator to run on latest/buster Raspbian (RPiOS)
armhf. See example build runs here
https://github.com/kernelcoredump/previous/actions (
https://github.com/kernelcoredump/previous/actions) for the
feature/fix-rpi-dialog branch.
The tar/zip file is currently an artifact of the build runs, but I'll eventually update the workflow to create GitHub release packages. If you own a Raspberry Pi 4, feel free to download the "previous-RPiOS" artifact from the build runs, unzip/extract the files, run the binaries, and see if there are any runtime bugs. There's currently a runtime dependency on the
libpcap0.8 Debian package so pre-install that package for now. Bugs and issues can be filed in GitHub and we can utilize the standard GitHub pull request process.
Any thoughts or additional ideas?
/pitz
Thank you for your efforts! There are quite some things to do. I think most important would be to update the CPU emulation core to the latest version from WinUAE/Hatari. Then there is some unfinished file sharing code that needs completion. Both are quite challenging tasks. Unfortunately i do not have the necessary time any more.
Really good to hear from you Andreas! I hope you are keeping well and safe!
Thank you, t-rexky! Yes, i am fine!
Hello!
Where would you like bug reports? I'm trying to create an AUR package for Arch Linux, and I'm having trouble in the final linking. It feels kind of cmake-y, and I'm not that skilled at cmake.
I've mentioned this in another thread (
http://www.nextcomputers.org/forums/index.php?topic=4547.msg26597#msg26597) on here, but Previous doesn't work out of the box on Apple Silicon. The best I've gotten so far is a black window with MacPorts' SDL2.
Ouch, it looks like Previous is just flat out broken with versions of SDL2 beyond 2.0.12 (on macOS; it seems to still work fine w/ .14 on Linux for example). Building against 2.0.14 on amd64 Big Sur results in the same crash I've been having on Apple Silicon with .14.
Quote from: dimbulb on December 21, 2020, 11:09:30 AMHello!
Where would you like bug reports? I'm trying to create an AUR package for Arch Linux, and I'm having trouble in the final linking. It feels kind of cmake-y, and I'm not that skilled at cmake.
I just now enabled the Issues feature on my fork
https://github.com/kernelcoredump/previous (
https://github.com/kernelcoredump/previous) where issues can be opened.
As an update, my fork generates GitHub releases
https://github.com/kernelcoredump/previous/releases (
https://github.com/kernelcoredump/previous/releases) for several target systems -- armhf (RPi or any Debian-based distribution), aarch64 (RPiOS 64-bit or any Debian-based distribution), x86_64 (64-bit Intel Debian-based distribution), x64_windows (Windows 10). These are self-contained releases built from a GitHub workflow. I will add a
macOS build to the workflow once I get a better grasp on the
macOS build process.
@dimbulb I will be installing Arch Linux on a VM to see how Previous builds. GitHub does not have an out-of-the-box build environment running Arch Linux, but it can always run a Docker container for the build step on the workflow. I am not looking at building AUR packages (nor DEB packages) in the near future, until we reach the point of some code cleanup and documentation on the repo. I kind of agree with Torvalds on his view that self-contained user applications (AppImages) may be what's appropriate for these types of applications, and we can eventually build a
pacman-based AppImage. Nonetheless, building the emulator locally generates a
dist folder that you can feed into
makepkg to generate an AUR package.
Running the latest Windows binary on one of my computers, latest Windows 10 Home, SLIRP networking works OK, altough needed to start Previous with the network interface turned off, otherwise it would crash. Next task will be to compile the new code in Windows, Mac and Linux (Arch).
Keep up the good work!
I have a possible contribution, (
http://www.nextcomputers.org/forums/index.php?topic=4469.0), wanted to ask about repos. I see so far
https://sourceforge.net/p/previous/code/HEAD/tree/https://github.com/kernelcoredump/previoushttps://github.com/nextcomputers/previousWhat's the purpose of the nextcomputers fork? is it a snapshot for a particular point in time?
Are changes making it back up to the Sourceforge repo?
My changes are atop the kernelcoredump fork, but they can be cherry-picked anywhere else.