Development environment for the menu core

[ForestOfCedars]

Hey everyone!

I've just gotten on-board with the mister train, and I couldn't be more delighted, it's a wonderful little thing. And I wanna help it out and contribute to make it even better! Unfortunately I'm not a hardware developer and probably never will be (though the MiSTer is certainly making me reconsider), but I do have many years of experience with C and C++, as well as UX and interface design. I was using the menu core and thinking "this works great, but there's some minor tweaks here and there you could make", so I'm thinking of getting my hands dirty and digging in and maybe make some pull requests.

I've looked through the main MiSTer repo in GitHub and found the menu.cpp file there, as well as the various makefiles and things, but I was wondering if there was any good information about setting up a good development environment for the MiSTer menu core. Is the way to do it to use the build.sh script to recompile everything and move it to the MiSTer? Or can you set up a dev environment on the computer itself (and you know, attach debuggers and stuff)? Any information would be greatly appreciated

Thanks again for this awesome thing!

[Sorgelig]

There is no debugger for MiSTer in it's traditional form where you can step the debugged app. Even if it would, it wouldn't be helpful as Main tightly coupled with FPGA side and any delay will simply break the communication channel.
gdb is probably available on MiSTer (i think i've included it) but it's not useful at all.
Main debugging way is to print into console (USB console port). So simply print as much as you want from debugged function (but don't forget to remove all these printfs before PR).

I use Visual Studio 2017 for developing Main. It calls msys with gcc to build the binary and upload it to MiSTer.

[ForestOfCedars]

Thanks for the quick response!

After sending that message yesterday, I spent all evening setting up a dev environment for the MiSTer. I'm on macOS, and I had a hell of a time getting an ARM compiler to work, but finally got it all running using this docker image with the relevant compilers I found on the wiki, which was a very easy solution: https://github.com/misterkun-io/Toolchain_MiSTer. The makefile and build.sh script were very helpful for getting my mind around how to set everything up for rapid development.

I got basically it all running and I spent all night digging into how the menu works (specifically the menu.cpp file). I'm happy to tell you that debugging the menu actually works pretty great in my experience! You can set breakpoints and watchpoints, step in/out/over, examine all the variables, the whole shebang. I imagine it might be trickier for some of the functionality that directly communicates with the FPGA, but for the menu itself I had no problems at all. When I had the menu on a breakpoint, the loaded cores kept playing in the background but the menu was (obviously) frozen. When I released the breakpoint, everything continued just fine.

In order to get it working properly, I changed the makefile to include debug symbols, removed optimizations and removed the stripping of symbols (you wouldn't release it like that, but for debugging it's nice). In order for it to show source code I had to upload the source tree to the mister and then use the "dir" command in gdb to load it, but all of that works just fine. I also got gdbserver running on it, so i can debug locally. I'm using Emacs which has extensive gdb support (comparable to what you'd get with Visual Studio's or Xcode's debugging capabilities), and using it through gdbserver worked great (if you're running it locally, you don't need to upload the source, you can just "dir" your local copy). Also: i generally didn't start the MiSTer process with gdb, i just attached to the running process instead, that seemed easier.

I've been digging through the menu.cpp script, and I might have some stuff I'd like to make PR's for in the future. Good to hear you might be receptive towards that!

Thanks again for the great project, and thanks for the foresight of including gdb in the Linux distro.

[Sorgelig]

Glad you found the way to use debugger, although it's redundant from my point of view. I solve all debugging issues by printf to console, and it doesn't stops the communication with core.
You are welcome to improve the Main, but you need to know as it's system and common component for all cores it's unlikely i will accept PR for some new random functionalities. So better to discuss in advance about new features to make sure it will be accepted.
PR to fix the bugs are always welcome.

[Newsdee]

I've been wondering if some unit testing would be useful to help maintain the Main binary.

It's not exciting at all but it would be a good exercise for people just starting with the C++ code and understand what goes where.
I'm just not sure yet what would be the best way to go with it (eg. which framework to use, how to mock pieces like the FPGA access, etc.)

This isn't a request for it; it is just something that has been on my mind and I was wondering what are everybody's thoughts on it.

[invzim]

Having issues with the input system, so wanted to have a poke. It's not exactly clone and compile..

The docker stuff gives me errors on step 8 when doing make build :

Code: Select all

Step 8/31 : RUN apt-get update && apt-get upgrade -y && apt-get install -y 	autoconf 	automake 	bash-completion 	bison 	build-essential 	ca-certificates 	checkinstall 	curl 	flex 	gdb 	git 	iputils-ping 	less 	libc-dev 	libcurl4-openssl-dev 	libelf-dev 	libfreetype6-dev 	libgmp3-dev 	libjsoncpp-dev 	liblz4-tool 	libmpc-dev 	libmpfr-dev 	libncurses5-dev 	libpcap-dev 	libreadline-dev 	libssl-dev 	libtcmalloc-minimal4 	libtool 	libtool-bin 	libusb-dev 	libusb-1.0-0-dev 	locales 	mlocate 	nano 	nasm 	openssh-client 	p7zip 	python3-pip 	pkg-config 	software-properties-common 	sshpass 	sudo 	tcl 	texinfo 	tree 	unzip 	wget 	xz-utils 	zlib1g-dev 	--no-install-recommends && 	apt-get purge -y 'libx11*' x11-common libxt6 && 	apt autoremove -y && 	rm -r /var/lib/apt/lists/*
 ---> Running in 6d48d84a885c
standard_init_linux.go:211: exec user process caused "exec format error"

Running this on a virtual ubuntu.