Lets actually try Hybrid Emulation

lordoftime79
Posts: 97
Joined: Sun Feb 14, 2021 6:29 pm
Has thanked: 1 time
Been thanked: 2 times

Re: Lets actually try Hybrid Emulation

Unread post by lordoftime79 »

I just srtuggle with this full stop - could somebody perhaps zip up a working setup that we can just un zip to the sd card and go?
Bas
Top Contributor
Posts: 518
Joined: Fri Jan 22, 2021 4:36 pm
Has thanked: 60 times
Been thanked: 225 times

Re: Lets actually try Hybrid Emulation

Unread post by Bas »

@lorsdoftime79 the whole thing is still very much in development flux with bits flying left and right. There is no working setup at the moment. Some things function but only until they break. There's still a lot of leg work left to be done before a just working setup can be packaged for any kind of stable general use.
kolla
Posts: 188
Joined: Sat Jun 13, 2020 7:56 am
Has thanked: 17 times
Been thanked: 33 times

Re: Lets actually try Hybrid Emulation

Unread post by kolla »

Noone really has a working setup yet, we are all experimenting. Btw you don’t need ssh, you can just press F9 in the menu core, log in and start the 68k emulation from there, after for example a 20 sec sleep, enough so you can F12 and start the hybrid core before CPU emulation kicks in.
kolla
Posts: 188
Joined: Sat Jun 13, 2020 7:56 am
Has thanked: 17 times
Been thanked: 33 times

Re: Lets actually try Hybrid Emulation

Unread post by kolla »

What I find really strange is how all benchmarks say everything is much faster than tg68, while in reality it is so much slower, heh... :)
ByteMavericks
Posts: 53
Joined: Tue Oct 27, 2020 4:52 pm
Has thanked: 69 times
Been thanked: 11 times

Re: Lets actually try Hybrid Emulation

Unread post by ByteMavericks »

kolla wrote: Thu Apr 29, 2021 5:44 am What I find really strange is how all benchmarks say everything is much faster than tg68, while in reality it is so much slower, heh... :)
Could that be because benchmarks can execute from the cache on the arm side, and the challenge in performance is in the fpga to arm bridge?
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Here, have an 040 with FPU and MMU:
http://www.64kib.com/qemu_system_testv7.tar.xz

More dhrystones on sysinfo. Still rather slow in workbench!
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

ByteMavericks wrote: Thu Apr 29, 2021 9:58 am
kolla wrote: Thu Apr 29, 2021 5:44 am What I find really strange is how all benchmarks say everything is much faster than tg68, while in reality it is so much slower, heh... :)
Could that be because benchmarks can execute from the cache on the arm side, and the challenge in performance is in the fpga to arm bridge?
I'm still thinking its to do with that raster test and cia test...

P.S. try the bump map demo that robinsonb5 posted, it really is quick
bbond007
Top Contributor
Posts: 519
Joined: Tue May 26, 2020 5:06 am
Has thanked: 85 times
Been thanked: 198 times

Re: Lets actually try Hybrid Emulation

Unread post by bbond007 »

Caldor wrote: Wed Apr 28, 2021 10:38 pm I have been trying this out, but so far no luck getting it to run. I cannot run the 68000.sh script without getting the "wrong core", I tried changing it so it would have the right core name and QEMU file name, but both just crash. I then tried running the script from Putty, which helped a bit I guess, but same problem as when I run the musashi_68020_mister or musashi_68040_mister directly, I see some hex code kind of thing in the prompt and the MiSTer itself freezes and then reboots after something like a minute.
The 68000.sh says "Wrong core" if you are attempting to run it when the Minimig core is not nunning.

The script is really not designed to be called directly in the shell, it get called by my custom MiSTer when the (Minimig) OSD Reset is pressed. This script makes sure things get started and stopped and reset in the proper sequence without needing to use SSH.

I suggest first get the manual start process with SSH working.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

I spent some time creating a disk image in uae and it doesn't work, since it has too many heads.

Is there a way to adapt it with rdbtool?

I also tried to create an empty one to copy it onto, but it doesn't seem to work at all. Is there a magic trick?
rdbtool LargeDisk.rdb create h=16 s=255 c=7000 +init rdb_cyls=10
rdbtool LargeDisk.rdb info
'info' IOError: No RDB Disk?

Just trying to get workbench set up so I can install a local compiler to run some tests. I was going to use coffin but don't have space.
bbond007
Top Contributor
Posts: 519
Joined: Tue May 26, 2020 5:06 am
Has thanked: 85 times
Been thanked: 198 times

Re: Lets actually try Hybrid Emulation

Unread post by bbond007 »

foft wrote: Thu Apr 29, 2021 8:08 pm I spent some time creating a disk image in uae and it doesn't work, since it has too many heads.
Did you pick "Change Drive Type", "Define New" and finally "Read Configuration" inside HDToolBox prior to partition and format?

Inside UAE "CD and Hard Drives" :
  • Full drive/RDB mode
  • I always pick A600/A1200/A4000 for "controller type", but I'm not sure that is necessary.
I think that is all, but its been a while...
foft wrote: Thu Apr 29, 2021 8:08 pm Is there a way to adapt it with rdbtool?
I have never used "rdbtool" but convert your existing nonfunctional drive you could:
  • Make new HDF on MiSTer Minimig core with dd/HDToolbox
  • Copy that HDF over to PC
  • Mount both in UAE
  • from CLI/Shell "copy DH0: DH1: all" (assuming DH0: is your source and DH1: is the dest)
User avatar
meauxdal
Posts: 124
Joined: Mon Nov 23, 2020 3:28 am
Location: atlanta
Has thanked: 32 times
Been thanked: 75 times
Contact:

Re: Lets actually try Hybrid Emulation

Unread post by meauxdal »

foft wrote: Thu Apr 29, 2021 8:08 pm I spent some time creating a disk image in uae and it doesn't work, since it has too many heads.

Is there a way to adapt it with rdbtool?

I also tried to create an empty one to copy it onto, but it doesn't seem to work at all. Is there a magic trick?
rdbtool LargeDisk.rdb create h=16 s=255 c=7000 +init rdb_cyls=10
rdbtool LargeDisk.rdb info
'info' IOError: No RDB Disk?

Just trying to get workbench set up so I can install a local compiler to run some tests. I was going to use coffin but don't have space.
Sent you a PM just now
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Thanks for your advice on this, think its almost there.

One priority item to fix in qemu is : crash when clicking on icons!!
User avatar
Caldor
Top Contributor
Posts: 930
Joined: Sat Jul 25, 2020 11:20 am
Has thanked: 112 times
Been thanked: 111 times

Re: Lets actually try Hybrid Emulation

Unread post by Caldor »

bbond007 wrote: Thu Apr 29, 2021 1:54 pm
Caldor wrote: Wed Apr 28, 2021 10:38 pm I have been trying this out, but so far no luck getting it to run. I cannot run the 68000.sh script without getting the "wrong core", I tried changing it so it would have the right core name and QEMU file name, but both just crash. I then tried running the script from Putty, which helped a bit I guess, but same problem as when I run the musashi_68020_mister or musashi_68040_mister directly, I see some hex code kind of thing in the prompt and the MiSTer itself freezes and then reboots after something like a minute.
The 68000.sh says "Wrong core" if you are attempting to run it when the Minimig core is not nunning.

The script is really not designed to be called directly in the shell, it get called by my custom MiSTer when the (Minimig) OSD Reset is pressed. This script makes sure things get started and stopped and reset in the proper sequence without needing to use SSH.

I suggest first get the manual start process with SSH working.
Ahh.. I was not sure if it was supposed to be running or not. I will try this next time
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Thanks, up and running with a hdd now. Also building this https://github.com/bebbo/amiga-gcc so that I can compile some test app to run on the amiga side.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

I build dhrystones for the amiga, here is a comparison of running the same code on the arm (also with qemu m68k):
from linux:
/media/fat# LD_LIBRARY_PATH=./qemu_system_test/libs/lib/arm-linux-gnueabihf/ ./qemu_system_test/libs/lib/ld-linux-armhf.so.3 ./qemu-m68k ./dhrystone_m68k -l 1
duration: 0 seconds
number of threads: 1
number of loops: 1000000
delay between starting threads: 0 seconds

Dhrystone(1.1) time for 1000000 passes = 1.9
This machine benchmarks at 523065 dhrystones/second
298 DMIPS

Total dhrystone run time: 1.943114 seconds.

from amigaos 3.1.4:
Will report back, but its well over 2 seconds!
~300 dhrystones/second...

Why? Shouldn't this use fast ram and thus be 100% on the arm. Perhaps some slow OS call in the loop?
robinsonb5
Posts: 129
Joined: Fri Jun 19, 2020 8:54 pm
Has thanked: 13 times
Been thanked: 57 times

Re: Lets actually try Hybrid Emulation

Unread post by robinsonb5 »

Doesn't dhrystone use C library functions for string manipulation? Maybe the C library's calling ROM functions?
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

I thought that, I'm trying to install mmulib to map the rom to fast ram.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Thing is even if it is calling rom functions, I'd expect there to just be a few and they'd end up in the translation cache. Unless they do a lot of chip ram access...
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

mmulib -> bad idea -> doesn't boot!
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Well I added copying the rom -> fast memory - and it goes up to 900 dhrystones/second!!
robinsonb5
Posts: 129
Joined: Fri Jun 19, 2020 8:54 pm
Has thanked: 13 times
Been thanked: 57 times

Re: Lets actually try Hybrid Emulation

Unread post by robinsonb5 »

foft wrote: Fri Apr 30, 2021 8:19 pm Well I added copying the rom -> fast memory - and it goes up to 900 dhrystones/second!!
The world's not ready for such speeds...

Where's the VBR located? Is it in chip or fast RAM?
If this is pretending to be a 68040, does the dhrystone loop maybe include some instructions that the '040 doesn't implement, causing exceptions to emulate them?
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

It’s 500-1000x slower than it should be. So it should be fairly obvious in principle. I just need to get my head clear and write some basic tests - I guess.

When I get some time to look...

I didn’t tell gcc any cpu so I’d expect it’d target base 68k, but I can experiment with the settings. Or crack out devpac 2 and write some asm tests.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Playing around some more... even a plain old (unoptimized) for loop is just as bad.

int main(void)
{
for (int i=0;i!=0xffffff;++i)
{

}
return 0;
}

m68k-linux-gnu-gcc -O0 main.c -o main_68k -> 1 second running on mister arm under linux
/opt/amiga/bin/m68k-amigaos-gcc -o main_amiga -> a LONG time on mister arm under amigaos.

Now to find out why...
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

In terms of speed..

#include <time.h>
#include <stdio.h>

int main(void)
{
clock_t last = clock();
for (int i=0;i!=0xffffff;++i)
{
if ((i&0xfff)==0)
{
clock_t now = clock();
fprintf(stderr,"Delay:%ld %ld\n",(now-last),CLOCKS_PER_SEC);
last = now;
}
}
return 0;
}

ARM: ~100us
M68K qemu user mode: ~300us
M68K qemu machine: 200000us

Haha
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

In case clock is a slow thing, switched to polling 0xdff006 (I can read this in ~300ns). So it takes about 2 scanlines for 16 loops, or 30 scanlines for 256 loops.

So, a fairly consistent 125000/sec (at the micro-level, so avoiding any nasty slow task switching etc), vs 40 million (native) and 13 million (qemu m68k user mode). Hmmm. Though 100 times slower rather than the 1000 times slower I see at the macro level.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Late now, but have to try turning off the OS and disabling interrupts next. Then I guess changing background colour to see how long things take.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

I can't think I'm doing much to slow it down, but one thing springs to mind is how I handle interrupts. Updated with a ptimer in qemu that fires 50000 times/second and also on irq register writes. This may not be a root cause of this issue (still TBD) but I think I should update this to do it correctly in any case.

The plan:
i) Use f2h_irq bridge
ii) Write a kernel module that provides an ioctl to wait for an irq
iii) High priority user space thread that waits on this irq and calls set_irq in qemu when woken.

+ some notes:
// qemu_mutex_lock_iothread();
// mpc8xxx_gpio_set_irq(arg,mg->pin,mg->state);
// qemu_mutex_unlock_iothread();
// see:
// ../svn/Linux-Kernel_MiSTer/drivers/video/fbdev/MiSTer_fb.c
// also:
//../svn/Minimig-AGA_MiSTer/sys/sys_top.v
// wire [63:0] f2h_irq = {video_sync,HDMI_TX_VS};
// cyclonev_hps_interface_interrupts interrupts
// (
// .irq(f2h_irq)
// );
// if (ioctl(fb, FBIO_WAITFORVSYNC, &zero) == -1)

In the meantime going to also try to build my own rom from C which gives more flexiblity. + try diagrom without that interrupt polling, I think it works without.
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Turned off the 'device' that does the interrupts and stuff - raster test is near perfect now. So I think this is a good track.
ByteMavericks
Posts: 53
Joined: Tue Oct 27, 2020 4:52 pm
Has thanked: 69 times
Been thanked: 11 times

Re: Lets actually try Hybrid Emulation

Unread post by ByteMavericks »

That sounds promising: are you saying you were actively polling thousands of times for interrupts? I can see that being an issue!
foft
Posts: 334
Joined: Thu Dec 03, 2020 11:05 am
Has thanked: 29 times
Been thanked: 120 times

Re: Lets actually try Hybrid Emulation

Unread post by foft »

Well yeah, but what is 50000 times/second when you have 800000000 cycles? 16000 cycles/poll. That is like half a frame vs say 2-3 instructions in the 8-bit world that I'm used to.

Anyway I tried changing it to a thread that polls 5000 times/second and ... while the raster stuff looks better and it feels better it didn't fix the core perf issues. Still I'm going to implement this.
Post Reply