MiSTer FPGA Forum

Here, have an FPU:
http://www.64kib.com/qemu_system_testv6.tar.xz

The patch was sent to me by Laurent (qemu maintainer) a week or so back but afraid I only just got around to applying it. It enables 68040 style stack frames on the fpu, even though we're in 68020 mode. Since they are not implemented for 68020 - which is the original problem I had with it booting.

Would this hybrid work help with the possibility of a Atari Falcon core now that higher motorola chips and fpu are in the mix?

foft wrote: ↑Wed Apr 28, 2021 6:24 pm The patch was sent to me by Laurent (qemu maintainer) a week or so back but afraid I only just got around to applying it. It enables 68040 style stack frames on the fpu, even though we're in 68020 mode. Since they are not implemented for 68020 - which is the original problem I had with it booting.

Thanks!

Benchmarks aside, Musashi certainly seems "feel" faster than qemu...

Here is a update 68000.sh with an updated MiSTer built last night (with reset hack).

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.

I found Midnight Commander seems to be installed on the MiSTer by default, so that is nice, but has not helped much. I will be busy this weekend but I will probably try experimenting with this again Sunday or Monday. Seems really promising, and I feel like trying to experiment with it

Have I understood it correctly that the QEMU Test files are QEMU source code for building a musashi file by compiling that source code? Or do I need to do something with that as well, to be able to use the CPU file?

kolla wrote: ↑Mon Apr 26, 2021 6:09 am Some first impressions...
* turned off PPP, set UART to "none" (does it matter? I see no difference really)

I've not been able to to get PPP to connect with the hybrid core. Maybe its too much lag or something because serial does seem to work.

It probably makes very little difference if PPP, Console or Modem are selected, but MUNT and FluidSynth use not and insignificant portion of CPU just sitting idle.

I just added "uartmode 0" to my 68000.sh just to make sure CPU sucking softSynths are disabled for testing.

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?

@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.

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.

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...

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?

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!

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

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.

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.

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)

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

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

One priority item to fix in qemu is : crash when clicking on icons!!

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

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.

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?

Doesn't dhrystone use C library functions for string manipulation? Maybe the C library's calling ROM functions?

I thought that, I'm trying to install mmulib to map the rom to fast ram.

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...

mmulib -> bad idea -> doesn't boot!

Well I added copying the rom -> fast memory - and it goes up to 900 dhrystones/second!!

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?

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.

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...

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

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.