Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

np2kai: init at 0.86rev22 #68328

Merged
merged 2 commits into from Jun 7, 2020
Merged

np2kai: init at 0.86rev22 #68328

merged 2 commits into from Jun 7, 2020

Conversation

OPNA2608
Copy link
Contributor

@OPNA2608 OPNA2608 commented Sep 8, 2019

Motivation for this change

Adding Neko Project 2 kai: A feature-rich, cross-platform PC-98 Series emulator.

Includes 2 versions:

  • a cross-platform SDL one and
  • a Linux-only X11 one.

I assume the non-Linux SDL versions compile fine, I can only test the Linux one.

I'm not sure on the stdenv.hostPlatform.isXXX stuff, or how strict I should define the platform.

Tested with proper BIOS files + a hard drive image, appears to run fine.


The repo (as well as libretro fork) includes a libretro port of the emulator, how would I go about to add that?

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nix-review --run "nix-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

@OPNA2608
Copy link
Contributor Author

After #71108 gets merged, I'll rebase and add the libretro port to the list of available cores.

remmina_VM 5900_139 18 11 230:5900_20191014-175538,489602
remmina_VM 5900_139 18 11 230:5900_20191014-17570,248269

Never used Retroarch before, but the emulator seems to run as expected afaict. I'm just missing the system files on my VM, hence it doesn't get far into the startup process in the screenshot.

@OPNA2608 OPNA2608 changed the title np2kai: init at 0.86rev20 np2kai: init at 0.86rev21 Dec 31, 2019
@OPNA2608
Copy link
Contributor Author

Updated to 0.86rev21 and added the NP2kai core to retroarch.

@ofborg ofborg bot requested review from edwtjo, hrdinka and MP2E December 31, 2019 01:14
@OPNA2608 OPNA2608 force-pushed the package-np2kai branch 2 times, most recently from 9630fdf to 2d33131 Compare April 8, 2020 18:08
@OPNA2608
Copy link
Contributor Author

OPNA2608 commented Apr 8, 2020

Fixed the merge conflict, reworked some parts of the derivation.

@OPNA2608
Copy link
Contributor Author

Updated to 0.86rev22, added some more settings to the derivation, added support for building with SDL1 and formatted the derivation with nixpkgs-fmt. Would welcome a critical look at everything, in case i overcomplicated something.

@OPNA2608 OPNA2608 changed the title np2kai: init at 0.86rev21 np2kai: init at 0.86rev22 May 22, 2020
@nixos-discourse
Copy link

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/prs-ready-for-review-may-2019/3032/175

@hrdinka
Copy link
Contributor

hrdinka commented Jun 4, 2020

This is already lying around for some time, sorry for this. It is a bit hard to follow, guess that is the reason why.

My feedback so far:

  • Is there a reason to still support SDL v1?
  • The derivation does a lot of manual stuff, like using install, autogen/configure and individual make files, while the upstream documentation simply uses cmake with a few flags. Is there a reason to not use cmake with the default flags and commands?

Edit I see, cmake was just added recently and is not part of rev.22. In this case it might make sense to use the current master version with cmake instead. There haven't been to many other changes either.

@OPNA2608
Copy link
Contributor Author

OPNA2608 commented Jun 4, 2020

No problem, the derivation has been kinda growing over time sadly.

  • Is there a reason to still support SDL v1?

It has been requested and re-introduced upstream with rev22, I wanted to support it just in case anyone needs it. Feature request in question here.

  • Is there a reason to not use cmake with the default flags and commands?

I'm afraid you're looking at the current master, which hasn't found its way into a tagged release yet. Rev22 still uses all the manual configure & makefile kerfuffle. I'll gladly look into simplifying everything with cmake once a rev23 is released ofc!

@hrdinka
Copy link
Contributor

hrdinka commented Jun 4, 2020

I'm afraid you're looking at the current master, which hasn't found its way into a tagged release yet. Rev22 still uses all the manual configure & makefile kerfuffle. I'll gladly look into simplifying everything with cmake once a rev23 is released ofc!

Yeah, I have noticed it right after posting it and I have edited my previous post :) It's also fine to keep it like that until rev23.

SDLv1 support makes less sense with nix, since it will never use any system libraries. However supporting it is fine as well, in regard of a more feature complete derivation. Give me some time to test this locally and to try out a few things.

@OPNA2608
Copy link
Contributor Author

OPNA2608 commented Jun 5, 2020

It is a bit hard to follow, guess that is the reason why.

I'll try to explain the expression abit, maybe that helps with evaluating it.

The emulator has separate 16-Bit and 32-Bit build options. The bitness relates to the range of system models that are being emulated, with 16-Bit software not always supporting being run on a 32-Bit model, and the other way around never being an option.

It can target multiple graphical frontends, currently packaged are SDL (1 and 2) and X11 on Linux with GTK2 (3 is broken upstream). Each frontend can be targeted by either bitness build. The expression isn't completely flexible, picking 16-Bit SDL and 32-Bit X11 for example isn't possible.

Additionally, the X11 version has an optional build that uses HAXM virtualization to improve performance. The build for this succeeds and launches, but it segfaults very quickly. I assume that's due to the HAXM kernel module missing, as mentioned in the comment. It might work on a non-NixOS system with the appropriate kernel module, but I haven't tested this. I don't know how to package third-party kernel modules, maybe someone could point me into the right direction.

The SDL build is cross-platform (Windows, macOS, Linux), I've personally only been able to verify that the Linux builds & retroarch core works. I walked a friend through the Nix installation on macOS and they told me the SDL one worked as well.

I tried to accommodate as many of those options as possible. I've been using this expression (the stand-alone one, not the retroarch build) since I initially opened the PR and everything works as expected.

Proper execution requires compatible BIOS images, a ROM / compatible bitmap replacement for the onboard chip responsible for onscreen text and, depending on the selected sound hardware, some samples from a rompling component in the version-specific configuration directory (e.g. X11 32-Bit -> ~/.config/xnp21kai/). This should be able to launch into either the on-board BASIC environment or an error screen (centered kanas) telling you that no bootable medium was found. A hard drive, floppy disk or CD images to run on the emulated machine would let you test the entire functionalities of the emulator. If this is unviable for you, I could take screenshots or a video to show that it works, with the right local configuration.

Edit: Here are some screenshots.
SDL, 16-Bit, BASIC ROM
NP2kai-BASIC
X11, 32-Bit, Game
XNP21kai-game

@hrdinka hrdinka merged commit 355eed4 into NixOS:master Jun 7, 2020
@hrdinka
Copy link
Contributor

hrdinka commented Jun 7, 2020

Thanks a lot for all the extra information, that’s definitely something new to nerd into :)

I have tested it locally and everything seems fine. The derivation will for sure get much simpler due cmake with the next version.

Thanks for all the work 👍

@OPNA2608
Copy link
Contributor Author

OPNA2608 commented Jun 7, 2020

Thanks for the review & merge! 😄

@OPNA2608 OPNA2608 deleted the package-np2kai branch September 27, 2022 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants