Lets actually try Hybrid Emulation

[foft]

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

[foft]

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

[lordoftime79]

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

where does the 68000.sh file go then?

[lordoftime79]

anybody? why is this so hard? I dont understand.

[kolla]

If you cannot understand, then just wait till it is ready for end-users.

[Fularu]

If you cannot understand, then just wait till it is ready for end-users.

Prety much this. You're just spamming the thread with something that's still experimental.

[jca]

how do i use this? I thaught the zips contained a core but it dosnt seem to be the case.

how do i start musashi_68020_mister?

Can you please tell me how to use this - I dont know anything about ssh so where does the file go and how do I run it?

I think it is better for you to wait until something more usable is posted. Right now it is a proof of concept, which is a huge step, but my guess is that you will be frustrated in no time.

i just want to look i am excited if I had some instuctions i cud follow them.

nice work. unfortunately even following your insturctions it wouldnt work for me, just got a blue and purple garbled screen.

Finally got it working but I cant seem to get it to load hardrive images - I get a bus error?

this is brilliant I having lots of fun experimenting! how does the hack work? does it stop me having to do the ssh stuff?

just tried it and i cant get it to work... just sits at a black screen, I have a folder in meida/fat/_Amiga that has these files in it 68000.sh, musashi_68020_mister, Minimig_Hybrid.rbf and the 68000.sh has this line at the top: CPU_DIR="/media/fat/_Amiga"

I am setting the ram to 8mb fast and hitting reset so What am I doing wrong?

because then I cant launch the core as folders without the _ dont show on the menu?

Typically the core (computer) ".rbf" file should go under "_Computer" and your (amiga specific) ADF's and HDF's should be under "Amiga". Do that and it will probably work for you...


https://youtu.be/dN2KSp2p6sE

where do we put these files?

how do I use this?

Is there away to do it without the ssh in part as i dont have a computer close to my mister - is there anyway i can get it to work without doing that like the old version?

I am struggling with this - the old one worked but this isnt working... how do I make it work without having to do the Shh - do i still need the 68000 and if so what do i put in it - go or qemu-system-m68k also where do the libs folder go?

where does the 68000.sh file go then?

anybody? why is this so hard? I dont understand.

I guess you are not interested in learning but just want to be spoon fed.

[lordoftime79]

I am pretty new to mister stuff instead of being arseholes I just want some help, why do you have belittle me? wasnt you all new to this at some point too? The instructions arnt clear to me as I am not SUPER MEGA ELITE skill like you all seem to be! I dont have a computer near the mister so the shh into it isnt easy - I wanted to use the script but dont know where they need to go or how it works I just want some help please!

[dshadoff]

I think the point he was trying to make is that this is not ready for use by most people - only high-level developers (and only those who can keep up).
It's not released. It's not beta. It's not even alpha yet.
The main developer is reporting that he is actively finding (and attempting to fix) bugs.

I think jca's fourth quote from the above is apt:

I think it is better for you to wait until something more usable is posted. Right now it is a proof of concept, which is a huge step, but my guess is that you will be frustrated in no time.

[lordoftime79]

I get that but I am not illiterate with tech, I am an active developer and know quite a bit, just that the scripts and way the Mister works is new to me all I wanted was some help as that is why these forums exist surely?

[foft]

I'm happy to help but don't really understand the question.

I think you already have working ./68000.sh and its just a case of pointing it at the other binary.

[foft]

Perhaps the confusion is partly the way I wrapped up a binary and libraries together.
This is because my cross compiler toolchain isn't set up with the correct libraries for mister.
So I copied them all into a folder and pointed at them with LD_LIBRARY_PATH and ran via ld.so.

[lordoftime79]

so from the top how do I do this? extract archive to media/fat, then what should I do to make it work without needing to ssh? i.e what needs to go into the 68000.sh file and where does this file need to be located?

[foft]

I haven't tried the 68000.sh patch myself so can't say. I ssh in and run it using ./qemu_system_test/go

Though I think you already have 68000.sh somewhere? Where is it and what do you have in it now?

[lordoftime79]

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.

[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