Lets actually try Hybrid Emulation

[foft]

Here is a newer musashi set to 68040 mode and with 384MB fastram.
Not sure why, but only gets 2000s dhrystones, didn't this get like 6000 before??

I included the main.c, config and build stuff. For anyone who wants to play.

Oh and I figured out why qemu is complaining about the bad boards - I had the wrong address. So will upload a v4 in a sec.

[robinsonb5]

I dont know i have moved and rewritten the file so much I have lost track and got really confused. I really wish this was like a normal core.

It will be, eventually - but for now it's just a lashup to see if the concept can be made to work. You're tripping over the reels of duct tape and exposed wires, which will all be tucked away neatly in due course - but the user-experience stuff comes much later. For now, the focus is on gettting it to work properly.

It's not really fair to be asking for support at this stage, even if foft doesn't mind!

[foft]

Here is a newer qemu.
http://www.64kib.com/qemu_system_testv4.tar.xz
All I changed was to fix the address of the fast ram. I had it at 0x8000000 and it should be at 0x40000000!

BTW if you set it to this then you can catch all these instructions that it doesn't support well:
LD_LIBRARY_PATH=./qemu_system_test/libs/lib/arm-linux-gnueabihf/ ./qemu_system_test/libs/lib/ld-linux-armhf.so.3 ./qemu_system_test/qemu-system-m68k --machine mister_minimig --nographic -d int -D qemu.log
I'm trying to add some disassembly of the pc at the area...

[foft]

Would someone be able to help me out with an adf (or vhd) with sysspeed installed please? I really don't trust the benchmarks I'm getting from sysinfo, it should be FAR faster than this. As seen by the user mode m68k dhrystones test...

I guess I should set up a vhd with a c compiler installed then I can test some stuff.

[Higgy]

I cant help just at the moment, but what about running the game Frontier.
On a real fast system the 'flames 'coming out of the factories in the intro should move smoothly.
I am not sure that on an emulated 040 would you need all the correct Libs etc? Testing 030 performance would be much easier initially as things will just run.
Great work on the progress by the way.

[robinsonb5]

Yeah, no problem - I can sort out some benchmark ADFs.

[robinsonb5]

Would someone be able to help me out with an adf (or vhd) with sysspeed installed please?

SysSpeed requires MUI and calls all manner of other programs to do its thing, so that's not going to fit on an ADF.

AIBB fits on a floppy, though - here's a couple of ADFs. The first contains AIBB and bustest - just boot the disk and type "aibb" or "bustest fast" to run them, but you might be better off booting from a workbench disk and running them from the shel so you get setpatch, etc.
The other one's just a little graphics demo which may or may not work, and may or may not be a slideshow.

[foft]

So AIBB shows about 30% faster than the 040 on most tests.
The bump mat is not very smooth, maybe 10fps - hard to guess!

[foft]

+ bustest (again qemu)

[foft]

Fast mem seems VERY slow

[robinsonb5]

Fast mem seems VERY slow

Indeed. I don't know much about 68k MMUs, but I guess qemu emulates an MMU? It's not crossing the HSP bridge for lookups is it?

[foft]

I wonder if the fastmem area shared with the fpga-hps bridge is somehow slow. I’ll try some plain old malloc’ed ram - tomorrow.

[foft]

I’m running qemu in 68020 mode iirc, so no mmu

[NovaCoder]

I can't offer any help because this is way over my head but I just wanted to offer encouragement

If you can get this working properly it will be so cool

[foft]

OK, can someone explain this to me...
This is timing for 32-bit write/read/verify of each location.
I didn't even program the core...

int fd2 = open("/dev/mem",(O_RDWR)); // no O_SYNC, cache should be on
unsigned int fast_span = 32*1024*1024;
unsigned int fast_base = 0x28000000; // physical ddr address, shared with f2h bridge
fastram = (unsigned char volatile *)mmap(NULL,fast_span,(PROT_READ|PROT_WRITE),MAP_SHARED,fd2,fast_base);
20MB/s

fastram = malloc(fast_span);
120MB/s

fastram = mmap(NULL,fast_span,(PROT_READ|PROT_WRITE),MAP_SHARED|MAP_ANONYMOUS,-1,0);
120MB/s

[foft]

https://linux-mips.linux-mips.narkive.c ... ry-so-slow
"mmap will create uncached mappings for anything above the highest RAM address."

So, how do I enable the cache, even though its not in /proc/iomem?

[foft]

Here are builds using malloc instead:
http://www.64kib.com/qemu_system_testv5.tar.xz

musashi_68040_mister.gz

(1.34 MiB) Downloaded 173 times

+ some pics of bustest and qemu benchmark results

[LamerDeluxe]

Wow, that is really impressively fast.

[robinsonb5]

That's more like it!

(Interesting that the Dhrystone score is so much lower than the other two...)

Nice work, anyway!

[foft]

Yeah, that dhrystone score is weird. I get much more with 68k user mode qemu. I'm going to set up a .vhd and install gcc and see how a local build looks.

[foft]

So, what do we need to do to get this 'releasable':
i) Figure out caching for mmap of 'spare' DDR.
ii) Plumb in reset
iii) Plumb in config params: fastram etc.
iv) Figure out common crash reasons - possible unimplemented instructions etc
v) Enable FPU on 68020 (maintainer sent me a patch to enable fsave 68040 style on 68020) or enable 68040
vi) Make it switchable: 68000, 68020 (tg68) or Hybrid qemu.
vii) Merge sys framework
viii) A generic method to start hybrid cpu from MiSTer binary

Who wants to help?

[foft]

This might be a solution for cache:
https://github.com/ikwzm/udmabuf

[Bas]

From that list I'd only qualify for VIII. I'll see if I can come up with something sensible.

[kolla]

I have some test code that was used to find bugs in tg68, which surely can be used again, and also software that use FPU... what kind of precision can we expect?

[kolla]

Some first impressions...
* turned off PPP, set UART to "none" (does it matter? I see no difference really)
* more or less untampered OS 3.1.4.1
* turned off Minimig RTG, use P96 with "native" driver and HD720 mode (32 pens)
* installed CPU libraries (+ mmu.library - http://aminet.net/package/util/sys/Mu680x0Libs)

* with musashi_68040_mister, all software thinks there is a 68030+68881
* with qemu (testv5), all software thinks there is just a 68020
* qemu ("testv5") seems very sluggish (debug output somewhere?), but sysinfo etc show that it is fast
* musashi is quite snappier, but sysinfo etc show that it is slow
* with musashi, I got a couple of "yellow guru" recoverable alerts on boot
* both passed the MULU.L test (which tg68 recently didn't), hehe

[foft]

Thanks Bas and Kolla.

Be great to have some better integration with MiSTer and to have some tests of correctness of the CPU.

I noticed too that qemu benchmarks faster, but feels slower. Not sure if its jit delays or something else is going on. I did notice a bunch of privilege violation exceptions and not sure if that is normal or not! Pretty sure I turned off all the debug stuff in the v5 of qemu.

qemu is currently set as 68020. When I set it to 68040 I got some MMU assertions and then qemu exited iirc. Probably 68020/030 + FPU (040!) might be a reasonable next try. Though given that Laurent said 68040 is the 'main' qemu version (built for Quadra emulation) that might be the best to use, if we can work out the MMU issue.

[bbond007]

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

I actually extracted mine to my "Amiga" directory, so for "/media/fat" you'll just need to alter "CPU_DIR"

68000.zip

(583 Bytes) Downloaded 152 times

Musashi seems to run better for me. With the qemu v4 I notice the original Amiga "boing ball" demo runs like a slideshow. Something must be wrong for that...

To switch back to testing with Musashi:

Code: Select all

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

EDIT: found an issue switching to Musashi - uploaded new script.

@bbond007, come and help us out here:-)

Sorry it took so long. Had a reaction to my CV19 booster and was not feeling well the last few days

[ron]

Hi ! Thx for the effort and work.
I have tryed with musashi_020 and worked fine. Sysinfo shows 5.31 Mips

But, when launching 040...: Segmentation fault. Do I need to configure/copy/install anything else ?
I tryed both binaries.

Code: Select all

/media/fat# ./musashi_68040_mister 
Segmentation fault

/media/fat# file musashi_68040_mister
musashi_68040_mister: ERROR: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3 error reading (Invalid argument)

/media/fat# ./musashi_68040_mister 
Segmentation fault

[ron]

Hi there:

It Works I Fixed copying with scp. Don't know what happen to FTP transfer.

/media/fat# ./musashi_68040_mister
3:4
0xb5f90000:0xb4090000:0xb6fa0000:0x9c090000

I tryed half a dozen demos and worked fine. Sysinfo says 1.75 Mips xD

[foft]

Pleased you have it working.

Perhaps ftp was in ascii mode?

@bbond007: Uff, pleased you are feeling better