Commander X16

59 minutes ago, TomXP411 said:

Thanks.



 



I was trying to build it myself, but not having much luck. I don't know which build tools I need for Windows, and the Visual Studio project I have doesn't build the current version of the emulator. If anyone else has built this on Windows, it might be nice to add a "How to build on Windows" doc to the repository. 

The Makefile is setup to do a cross-build, using MinGW to build a Windows .exe from Linux or iOS. The catch is, it is very specific to Michael's build environment, with hard-coded paths, at least one username, and other assumptions about the build environment, including a custom-built SDL2 implementation.

It should be possible to clean some of this up, but we'd want to coordinate with Michael to make sure we don't break his ability to create release packages. It would be almost ideal if someone were to create a CMake script, but again we'd want to coordinate with Michael.

In the meanwhile, there is no native Windows build configuration, nor a true cross-platform build configuration a la CMake. The best I can offer is that you can use the environment I setup for myself, using Visual Studio Community 2019:

• 
  git clone https://github.com/indigodarkwolf/x16emu-vs2019
  


• 
  Enter the x16emu-vs2019 directory
  


• 
  git clone https://github.com/commanderx16/x16-emulator
  


• 
  Open x16emu.sln
  


• 
  Press F5 to build
  

Note that if Michael accepts the PR that reorganizes the emulator code files, that VS2019 sln will need to be updated accordingly. It's not hard, though-- basically, just delete all the entries under "x16-emulator" and then drag all the source files from the emulator back into that folder in VS2019. ?

1 hour ago, TomXP411 said:

Thanks.



 



I was trying to build it myself, but not having much luck. I don't know which build tools I need for Windows, and the Visual Studio project I have doesn't build the current version of the emulator. If anyone else has built this on Windows, it might be nice to add a "How to build on Windows" doc to the repository. 

I currently do it using MSYS2.  A lot of people might not want to bother to download and set that up, however.  I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile.  Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

5 minutes ago, Ender said:

I currently do it using MSYS2.  A lot of people might not want to bother to download and set that up, however.  I like it because things compiled natively with it work natively in Windows, so you can just build with minimal changes to the code, and don't have to bother to cross-compile.  Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

I'll check that out, thanks. 

I can't use WSL because that installs and activates Hyper-V - which kills my ability to use VirtualBox (VBox still runs but switches to software virtualization, and no amd64 software will run.)

I'm installing a Linux distro on VirtualBox right now. The Raspberry Pi operating system didn't work, because I couldn't install the SDL development tools. Debian has other bugs that make it unusable on VirtualBox... so now I'm trying Mint Cinnamon. Not to start an OS flame war... but I'm baffled by why the Linux scene is so uneven... it's hard to get a distro to even work reliably on my machines, let alone use it for production tasks like software development. It would be nice if this could be built by Visual Studio, since that's the de facto standard on Windows systems - but I get why Linux-first and Mac-first developers wouldn't go to the trouble to build a VS solution.

 

 

 

6 minutes ago, Ender said:

 Maybe this is easy with WSL too, I haven't looked into it too closely.  It's been a while, but I think all I had to change in the emulator's Makefile were SDL2's path and maybe add some gcc flags to ignore some specific warnings.

I looked into this for a couple of hours the night the update was posted, it was not as easy as I'd hoped, and I ultimately fell back to using my VS2019 setup. ?

2 minutes ago, StephenHorn said:

I looked into this for a couple of hours the night the update was posted, it was not as easy as I'd hoped, and I ultimately fell back to using my VS2019 setup. ?

I tried the VS2019 project on Github, but it seems to require CLANG, which depends on another library, which I can't seem to get installed and working through NuGet. 

 

15 minutes ago, TomXP411 said:

I tried the VS2019 project on Github, but it seems to require CLANG, which depends on another library, which I can't seem to get installed and working through NuGet. 



 

Huh. It should be using the built-in Clang toolset. I'd open the Visual Studio Installer and check whether that's been installed under the "Desktop development with C++" section. Looks like it's grouped with optional components, maybe I manually added it in.

I remember moving to clang because I got tired of certain build warnings that msvc would glibly overlook, and then bite me when I submitted a PR. ?

14 minutes ago, StephenHorn said:

Huh. It should be using the built-in Clang toolset. I'd open the Visual Studio Installer and check whether that's been installed under the "Desktop development with C++" section. Looks like it's grouped with optional components, maybe I manually added it in.



I remember moving to clang because I got tired of certain build warnings that msvc would glibly overlook, and then bite me when I submitted a PR. ?

I will check. I probably didn't install CLANG since I do mostly c# development. 

** yeah, I had to dig into the Optional Components to explicitly install it. I'm doing that now. 

I also managed to get the Linux version and the ROMs to compile, so I'm just working on a Windows executable. 

 

Windows version is WORKING. I compiled the executable with the help of Steven's GitHub project file for Visual Studio 2019, and I built the ROMs on Linux. 

Here's a Zip with the executable and ROMs in it. This should tide Windows users over until the weekend. 

 

x16emu-2021-03-29.zip

I believe it's only necessary with rom.bin, but you also included basic.bin, dos.bin, and geos.bin. When packaging for Linux according to the Makefile it only includes rom.bin.



BTW I succeeded in building it for Raspberry Pi OS Buster on Raspberry Pi 4B and it works with all programs I tested with so far.

[Removed x16emu_linux-armhf-2021-03-29.zip since it is outdated. You can get a newer version from https://snapcraft.io/x16emu e.g. R39 or R41.]

 

Correct, you only need to include rom.bin. There are various symbol files generated by building the rom as well, but even though they've usually been included in the release packages, the emulator doesn't need them and can't load them besides (well, not until or unless the feature gets added).