Lets actually try Hybrid Emulation

[Caldor]

Emu68 runs on the Pi bare-metal, so not much help there I'm afraid.

Oh... amazing that could even be done. So it does not use an OS, its just Pi code that boots on its own?

I guess we need some other source of JIT CPU emulation. I hope foft gets it to work. Pretty sure that would increase the performance by at least 30%. Probably even more.

[Solskogen]

Nope, no OS. It runs on the Pi directly.
So in order use that, someone has to develop some kind of an interface to the Pi to DE10

[pgimeno]

Hard to know which of the settings take the most ressources, but it seems like the high frequency USB polling is a bit CPU heavy.

If I understood correctly what I read at the beginning of the thread, the CPU emulation process is running in the ARM core that handles hardware interrupts. That may be related to the issue you were having.

[kalach.x]

Nope, no OS. It runs on the Pi directly.
So in order use that, someone has to develop some kind of an interface to the Pi to DE10

Pi has 3.3V on its I/O pins just like DE10 so connecting them should not be too difficult, even without any specific interface.
The issue might be loosing either I/O board or SDRAM due to only having two I/O connectors on DE10, either of which is absolutely a must for normal Mister setup.

And the biggest issue is that if I connected something like Pi4 to Mister and loose analog output, then have to deal with latency issues I might as well use Pi4 and emulate Amiga without latency issues

Hybrid emulation project like this is great exercise though. Also to develop this FPGA <=> ARM part of Mister which might be useful for some systems.

BTW. Running latency sensitive CPU emulation as user process in Linux which you have to manually start does not sound all that great. Better approach would be to run such emulation kernel module which would automatically load alongside the core. Though this approach might have its issues as well eg. security concerns and need to match kernel version with kernel module version.

[foft]

I figured out why I was struggling to find the memory stuff in the aranym uat jit... Because it doesn't have an access layer like in musashi, it simply mmaps everything into the right place. i.e. the binary is set to load at 0x10000000 (virtual address), leaving the entire virtual space to mmap in like the target system. Then page faults can be used for hardware access.

I might try that direct memory access to get my head round the idea.

Not sure it really works like that on arm, since: https://www.arm.linux.org.uk/developer/memory.txt
i.e. the start of the ram virtual map is not free for use.

[foft]

Turns out the configure doc page explains all these modes: direct, fixed and real.
https://github.com/aranym/aranym/wiki/a ... onfigure_2

[Caldor]

I have been thinking about the MiSTer Minimig core and this hybrid solution. Should it not be possible to make this hybrid automation fix you did in a way that would be able to tell the main Minimig branch from the Hybrid one, and know when to run the CPU emulation? I am thinking there ought to be something that could be added to the hybrid version of the core that the MiSTer main could look for and detect so it would know whether or not to launch the CPU software. That would make it more likely for this to be integrated I think.

Hmm, in fact... would it not be enough to maybe just not have the 68arm CPU be the default CPU? So that it would only launch the emulation software if the 68arm CPU was selected? I have noticed that the core detects the CPUs differently, so when I run a configuration saved with this hybrid core, the non-hybrid core sees the CPU as the 68010 I think?

[foft]

It only launches the software when 68Arm is selected and stops it when another CPU is selected. I forget if I stopped it when choosing another core though, that will be needed! Also it could be more generic in its implementation, but the same could be said for the whole of mister main!

Yes I changed the cpu mapping since the mapping was: 0:68000, 1:68010 (off), 2:empty, 3:68020. Its annoying for the menu code, so I made it 0:68000, 1:68020, 2:68Arm. Of course this can be changed but its just a case of changing the default after the core.

I wasn't thinking anyone would be mixing and matching the old code/new binary etc. i.e. when it gets merged people would be advised to update both at once.

[Caldor]

It only launches the software when 68Arm is selected and stops it when another CPU is selected. I forget if I stopped it when choosing another core though, that will be needed! Also it could be more generic in its implementation, but the same could be said for the whole of mister main!

Yes I changed the cpu mapping since the mapping was: 0:68000, 1:68010 (off), 2:empty, 3:68020. Its annoying for the menu code, so I made it 0:68000, 1:68020, 2:68Arm. Of course this can be changed but its just a case of changing the default after the core.

I wasn't thinking anyone would be mixing and matching the old code/new binary etc. i.e. when it gets merged people would be advised to update both at once.

So far when I test it, I am just replacing the main and then run the Hybrid core. Then I switch back. Just seems faster even if its a bit risky.

Seems that if the menu code is changed to 0:68000 1:68arm 2:68020, it would be compatible with current saved configuration. Not that its really important to do right now, but if it ends up being merged into the main, then that would make sense I think.

So far it really seems to run quite well. It is a bit hard to know if the CPU emulation gets shut down or restarted correctly or at all. I guess something could maybe be added to the UI that helps track that. Also more of a nice to have feature, but it could also help debug and might be the kind of thing that Sorg might implement if its merged. I also guess such a feature might risk MiSTer Main crashing just trying to get a state update, so I guess it might be a bit of a risk.

[kalach.x]

Change core name and it will have its own configuration.

Also worrying about Mister Main with this project is a bit premature, don't you think?

[Caldor]

Change core name and it will have its own configuration.

Also worrying about Mister Main with this project is a bit premature, don't you think?

Well, if I am to use it more generally it would be nice if it was otherwise compatible, like a patch, to the official MiSTer main. Right now it stops the official Minimig core from working, but from what I can tell, does not have to. So it just seems to make sense.

[pgimeno]

Change core name and it will have its own configuration.

Changing the core name makes all Minimig-specific parts of Main to stop working.

https://github.com/MiSTer-devel/Main_Mi ... o.cpp#L225

[foft]

Look if this is a big problem I can change the order... I just thought it was an opportunity to clean it up!

[Caldor]

Look if this is a big problem I can change the order... I just thought it was an opportunity to clean it up!

True, but I would favor compatibility though, and then hopefully this change could be made in the official core first.

At any rate its a minor detail. Its not especially important to me, I just noticed it and figured it might make sense to go for the compatibility if possible.

[raparici]

Hi all,

MiSTer main does not need to be replaced every now and then to test the Hybrid main. Just go to the console and do killall MiSTer and then executing MiSTer_Hybrid . (folder) does the job and is much faster. I see the hybrid core does work more or less ok with the HDFs exception. I got a 5MB HDF to work at a time, but not always. Hard Disk issues seem the most blocking to me after a quick review. Floppies work perfect.

regards,

Ruben

[Caldor]

Hi all,

MiSTer main does not need to be replaced every now and then to test the Hybrid main. Just go to the console and do killall MiSTer and then executing MiSTer_Hybrid . (folder) does the job and is much faster. I see the hybrid core does work more or less ok with the HDFs exception. I got a 5MB HDF to work at a time, but not always. Hard Disk issues seem the most blocking to me after a quick review. Floppies work perfect.

regards,

Ruben

Ahh, that seems like a nice idea. So a simple script could be used to run a special version of MiSTer main?

[foft]

I got a 5MB HDF to work at a time, but not always. Hard Disk issues seem the most blocking to me after a quick review. Floppies work perfect.

The hdf's work fine for me if I turn off the fast IDE stuff. Are you seeing issues with that disabled?

[foft]

Look if this is a big problem I can change the order... I just thought it was an opportunity to clean it up!

True, but I would favor compatibility though, and then hopefully this change could be made in the official core first.

At any rate its a minor detail. Its not especially important to me, I just noticed it and figured it might make sense to go for the compatibility if possible.

OK, I'll make this change tonight then. Since you have been most helpful testing/trying this I want to make sure its not a pain for you

[foft]

Small update on ARAnyM... Again, finding this painful. Going to start from uae4arm instead first. I guess we should try just compiling it natively first, to see how it does without the FPGA side. i.e. 100% arm. It should only be faster than that, though not necessarily better! Since the emulator can freeze hardware during JIT to reduce relative latency.

[raparici]

Ahh, that seems like a nice idea. So a simple script could be used to run a special version of MiSTer main?

Exactly, for those who want to test this and arent familiar with the MiSTer console this is as simple as:

F9
root
1
hybrid

being hybrid the script to launch the new MiSTer main:

cd /media/fat
killall MiSTer
MiSTer_Hybrid .

[Caldor]

Look if this is a big problem I can change the order... I just thought it was an opportunity to clean it up!

True, but I would favor compatibility though, and then hopefully this change could be made in the official core first.

At any rate its a minor detail. Its not especially important to me, I just noticed it and figured it might make sense to go for the compatibility if possible.

OK, I'll make this change tonight then. Since you have been most helpful testing/trying this I want to make sure its not a pain for you

Thanks, that would be awesome Not much of a pain for me, but I am fully using the list of possible configs for the Minimig core already and I am also making a startup configuration that is now specific to the Hybrid MiSTer core, at least in the way that I use it to test it. But it contains a minimum of stuff to ensure it does not crash when booting the core. I have made the mistake of saving a startup config that made it impossible for me to boot the hybrid Minimig core because it always runs that startup configuration first. The configurations being compatible with the non-Hybrid Minimig is therefore... well, more future proof I think. I do hope we will see this become part of the MiSTer main at some point.

I have also begun looking into hybrid options for the AO486 core. Not that I could develop that, but I am thinking of just testing how well the various emulators run on the MiSTer ARM, but first off I am trying to figure out how I install Linux stuff on the MiSTer. It remember that as being pretty simple, but that might have been because I had the LXDE Linux desktop installed and working, and now I cannot boot LXDE on the MiSTer. I suspect it has something to do with the many Linux backup updates Sorgelig has been doing. So maybe the LXDE stuff has to be redone. Installing without that, I am beginning to suspect I might have to copy extra Linux stuff manually to the MiSTer and install it into the Linux so there is a package manager or something available.

Or maybe I can do what you did and just copy an app directly to the MiSTer and see if it runs, but then I first have to figure out the type of Linux and such... I think its some custom version of Debian maybe?

[foft]

OK, this one should all be in sync with the original Minimig core. You need to update the MiSTer and the MinimigHybrid.rbf.
https://github.com/scrameta/MiSTer_Hybrid_Support
I've not tested it yet myself, but should be ok.

[foft]

Does anyone want to try out uae4arm? I mean a plain compile, not a hybrid patched jit. This is a static build for mister. I'm not sure which core has fbdev support, the menu one? I'm curious how it performs on that amiga-dhrystone binary...
http://www.64kib.com/mister_hybrid_files/uae4arm

Ooops: that isn't static!

[Caldor]

Does anyone want to try out uae4arm? I mean a plain compile, not a hybrid patched jit. This is a static build for mister. I'm not sure which core has fbdev support, the menu one? I'm curious how it performs on that amiga-dhrystone binary...
http://www.64kib.com/mister_hybrid_files/uae4arm

Ooops: that isn't static!

Would be nice to try this. I have been wanting to also try to see how DOSBox runs if run on the MiSTer directly, and maybe QEMU running Amiga or x86 DOS. But QEMU still seems strange to me. Seems it needs to be compiled in pretty advanced ways.

OK, this one should all be in sync with the original Minimig core. You need to update the MiSTer and the MinimigHybrid.rbf.
https://github.com/scrameta/MiSTer_Hybrid_Support
I've not tested it yet myself, but should be ok.

Nice, I will try to add a script making it easy to switch between the normal and the hybrid main tomorrow.

[foft]

I'm going to give this a go, to get real Debian installed... Wish me luck!
https://forum.digikey.com/t/debian-gett ... -kit/12435

[Caldor]

I'm going to give this a go, to get real Debian installed... Wish me luck!
https://forum.digikey.com/t/debian-gett ... -kit/12435

Nice, I was hoping there was something like this. I might create an SD card just for this.

[Caldor]

OK, this one should all be in sync with the original Minimig core. You need to update the MiSTer and the MinimigHybrid.rbf.
https://github.com/scrameta/MiSTer_Hybrid_Support
I've not tested it yet myself, but should be ok.

I have been testing this and it seems to have some bugs. The FastRAM option now shows "---" instead of... I think I had it at 384mb. When I change that option it shows Chipset types instead of types of RAM. And if I change the CPU setting away from 68Arm, it freezes / crashes.

The ChipRAM and Chipset option seems to work as normal.

Ahh, that seems like a nice idea. So a simple script could be used to run a special version of MiSTer main?

Exactly, for those who want to test this and arent familiar with the MiSTer console this is as simple as:
F9
root
1
hybrid

being hybrid the script to launch the new MiSTer main:

cd /media/fat
killall MiSTer
MiSTer_Hybrid .

I made a script. I just put it in the scripts folder so it can be run from the menu:

Code: Select all

#!/bin/sh
echo "Killing MiSTer Main..."
killall MiSTer
sleep 1
echo "Running MiSTer_Hybrid Main..."
cd /media/fat/
./MiSTerHybrid .

Seems to work. For me the ./ before the command seems to help. I added the . after the MiSTerHybrid as you did. Not sure what it does? Sets the home directory so it knows where to find the MiSTerHybrid directory?

[foft]

OK, this one should all be in sync with the original Minimig core. You need to update the MiSTer and the MinimigHybrid.rbf.
https://github.com/scrameta/MiSTer_Hybrid_Support
I've not tested it yet myself, but should be ok.

I have been testing this and it seems to have some bugs. The FastRAM option now shows "---" instead of... I think I had it at 384mb. When I change that option it shows Chipset types instead of types of RAM. And if I change the CPU setting away from 68Arm, it freezes / crashes.

Uploaded a bug fix for MiSTer (hybrid edition). This might fix it, but more likely I need to pull my finger out and test it

[Caldor]

I'm going to give this a go, to get real Debian installed... Wish me luck!
https://forum.digikey.com/t/debian-gett ... -kit/12435

Nice, I was hoping there was something like this. I might create an SD card just for this.

Already seems much better. The FAST RAM option now works and I can select CPU types without it crashing.

[Caldor]

Updated the script I made inspired by raparici. So now its one script that checks if MiSTerHybrid is running (I rename it to MiSTerHybrid instead of just MiSTer) and then kills the MiSTer main that is running and runs the other main, hybrid or non-hybrid.

Code: Select all

if pidof /media/fat/MiSTerHybrid > /dev/null
then
	echo "Found MiSTerHybrid Main."
	echo "Killing MiSTerHybrid Main..."
	killall MiSTerHybrid
	sleep 2
	echo "Running MiSTer Main..."
	sleep 5
	cd /media/fat/
	./MiSTer .
else
	echo "Killing MiSTer Main..."
	killall MiSTer
	sleep 1
	echo "Running MiSTerHybrid Main..."
	sleep 5
	cd /media/fat/
	./MiSTerHybrid .
fi

Seems to work quite well for me. Also the configurations work. I found out that saving the start config with the 68Arm CPU still works on the non-Hybrid Amiga core, it just boot with it, but you can then change the CPU setting and boot.