MiSTer FPGA Forum

foft wrote: ↑Fri Apr 23, 2021 12:07 pm Yesterday I uploaded it all as a single archive. So just extract it to /media/fat. Then make a ./68000 (or was it 68000.sh) that calls ./qemu_system_test/go.

I wonder if the stop and restart works the same way as with the other one...

#CPU68000="ld-linux-armhf.so.3 qemu-system-m68kv5"
#CPU68000_START="qemu_system_test/go"
CPU68000="musashi_68040_mister"

foft wrote: ↑Fri Apr 23, 2021 12:09 pm @bbond007, come and help us out here:-)

foft wrote: ↑Wed Apr 28, 2021 7:26 am Pleased you have it working.

Perhaps ftp was in ascii mode?

@bbond007: Uff, pleased you are feeling better

Bas wrote: ↑Wed Apr 28, 2021 8:28 am The main MiSTer binary's code is sparsely documented and I've had less time than anticipated for this. What I'm looking to do, is to add a variable to the ini system to define a preload/postexit variable that will allow one to point to any kind of executable per core through the ini file. The main MiSTer binary should call the preload binary just before invoking the fpga_load_rbf function. This will ensure the system will have the CPU binary (or whatever Linux plumbing required) running before the FPGA core kicks in. That's the easy bit.

I have yet to find a clean exit-point where I can hook in to unload the CPU binary after the core is unloaded. For now it looks to me like cores do not actually get unloaded at all but simply overwritten with the next one the user chooses. So there's a bit of a thing there: the CPU binary will remain running and hogging ARM cycles long after we're done with our hybrid Minimig. That won't do at all. The way to fix this with the least amount of code touched, would be to add a flag somewhere so the main binary remembers that we still have the payload of a previous 'preload' (and which one) still running and then trigger the cleanup actions of the appropriate 'post-exit' script at that point in time.

Feels very very dirty to me, as I'd rather have a clean 'load core' and 'unload core' semantic (like a constructor/destructor) to plug things like this into. I don't think the next core's loading process should worry about any mess left behind by its predecessor. Coding that would seem to uproot a significant part of the current code base because I'd refactor things into a more OOP coding style. If I'm ever going to attempt that, then I'd prefer to have this discussed with and blessed by the project's maintainer beforehand. Investing the effort would be fine with me, but I'd rather not do it only to be shot down later.

For now I'll see what I can do by means of a proof-of-concept on the first idea, so we can at least see if the whole idea works at all and is workable in practice.

ron wrote: ↑Wed Apr 28, 2021 8:26 am I've been talking to shanshe, who is the one who is implementing part of the musashi in the PiStorm. He has told me that the patches are in the repository. Let's try to test how it goes.

This is its repo: https://github.com/shanshe/pistorm/tree/retrowiki

We will simply check if there is any speed increase although the main interest is compatibility.
Thank you all very much, the truth is that it is a fascinating project.

I'll keep you informed. Regards

Bas wrote: ↑Wed Apr 28, 2021 12:20 pm Restarting the binary would destroy state, unless we store that on the SD which I'd very much want to avoid.. this thing requires some more thought.

Edit: Writing a bit of state to /tmp (which is a tmpfs) should be viable. It'll be gone after a reboot, but so will any superfluous running binaries from a hybrid core so hey.. that'll do and I won't be needlessly wearing out the SD card this way.

Bas wrote: ↑Wed Apr 28, 2021 3:44 pm If Minimig hybrid needs a CPU emulator to run on the ARM, then that running emulator needs to be stopped (preferably in a clean way) when Minimig hybrid stops or it will be orphaned and just keep running after the user moves on to other cores. The state that needs to be kept, is the fact that Minimig hybrid still has its CPU running and a pointer to how to clean this up. It's not very long-lived, but needs to survive a restart of the MiSTer binary so RAM is not an option.

foft wrote: ↑Wed Apr 28, 2021 2:53 pm I didn't realise they had patches to Mushashi that aren't in the upstream repo. I think its well worth trying a build with.

Bas wrote: ↑Wed Apr 28, 2021 3:44 pm If Minimig hybrid needs a CPU emulator to run on the ARM, then that running emulator needs to be stopped (preferably in a clean way) when Minimig hybrid stops or it will be orphaned and just keep running after the user moves on to other cores. The state that needs to be kept, is the fact that Minimig hybrid still has its CPU running and a pointer to how to clean this up. It's not very long-lived, but needs to survive a restart of the MiSTer binary so RAM is not an option.

kill_all() {
	rm -f /tmp/uartmode*
	rm -f /tmp/ML_BAUD
	killall midilink
	killall pppd
	killall agetty
	killall login
	killall mt32d
	killall fluidsynth
	killall mpg123
}

foft wrote: ↑Wed Apr 28, 2021 5:53 pm Hmm, that pistorm one seems slower and crashier.
Here is an 020 of the 'official' Musashi with the 384MB fast.

Sure this was a fair bit faster on the early builds...