MiSTer FPGA Forum

Just ran a few quick tests and it works like a charm mostly. Feels like a reset leaves the CPU or some other components in a wonky state sometimes. Makes me curious as to what the reset menu item in the core actually does and to what extent it really resets the whole system and brings them back in line together.

I have a new qemu m68k 'machine' that points to the chip ram (hps fpga bridge) and some fast ram. It has a single device that polls the irqs.

Will it work, won't it work. Lets try!

Bas wrote: ↑Fri Apr 16, 2021 7:20 pm Just ran a few quick tests and it works like a charm mostly. Feels like a reset leaves the CPU or some other components in a wonky state sometimes. Makes me curious as to what the reset menu item in the core actually does and to what extent it really resets the whole system and brings them back in line together.

Yeah I didn't tie reset of the 'software cpu' to the hardware reset yet. So currently need to stop the process, reset on the core, then start the process.

foft wrote: ↑Fri Apr 16, 2021 7:26 pm Will it work, won't it work. Lets try!

Of course it will - have a little faith!

Diagrom starts to boot with qemu, I don't believe it!

Some problem with interrupts, I think I'm raising the right interrupt, but its not executed.

OK, interrupts work.

Here is a binary if anyone wants to play. Its like the other one though (fixed 8MB fast, no reset plumbing etc) - except worse since only Diagrom runs

http://www.64kib.com/qemu_system_test.tar.xz

Extract in /media/fat then run ./qemu_system_test/go

Perhaps someone smart can run it in trace mode and see why it gets stuck on workbench?

foft wrote: ↑Thu Apr 15, 2021 8:37 pm Regarding bus errors: try this cpu.

I was successful at running the following programs:

• Deluxe Paint 5

• Photon Paint 2.0

• Cloanto Personal Paint

• NewTek DigiPaint 3.0

• Brilliance

• Monkey Island 2

• GODs

And ShapeShifter Mac emulator worked too! I know that one is difficult for compatibility.

While testing, manually starting/restarting the CPU with SSH was slowing me down so I did this hack to main:

https://github.com/bbond007/Main_MiSTer ... 42a5d8cc8b

This will kill and start the 68000 CPU when reset is selected. You still must first (set RAM) and reset initially on cold boot.

68000.sh should go in your Minimig home dir - Typically /media/fat/Amiga unless using USB

68000.sh will look for musashi_68020_mister in /media/fat/Amiga, but this can be changed by editing the script.


This MiSTer (most likely) won't adversely effect other cores (including standard Minimig) if you cold boot after using it.

Remember to turn off FSynth or MUNT if enabled in the UART menu. Even sitting idle they will slow down your software CPU somewhat.

*** The core .rbf filename must contain "_Hybrid" for this hack to work. ***

Thanks for working on this project foft! This is very cool and unique.

Well I guess this is going way beyond the proof of concept now. Truly amazing work foft!

Awesome, thanks for testing though and the MiSTer patch.

Its still a PoC, but it'll be a usable PoC once I get qemu working. I also got some help from TomB of uae4arm, so will try that one too.

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

Somehow qemu gets stuck: PC:f82934:subq.b #1, ($127,A6)

2094@1618650071.686524:exec_tb tb:0xb2a8d6c0 pc=0xf81cbe
2094@1618650071.687794:exec_tb_exit tb:0xb2a8d8c0 flags=0x0
2094@1618650071.689237:exec_tb tb:0xb2a8e780 pc=0xf81cd4
2094@1618650071.690566:exec_tb_exit tb:0xb2a8e780 flags=0x1
2094@1618650071.692027:exec_tb tb:0xb2a8e900 pc=0xf81cea
2094@1618650071.693452:exec_tb_exit tb:0xb2a8e900 flags=0x0
2094@1618650071.694805:exec_tb tb:0xb2a8dd80 pc=0xf81cf4
2094@1618650071.696194:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.697558:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.699044:exec_tb_exit tb:0xb2a8e780 flags=0x0
2094@1618650071.700498:exec_tb tb:0xb2a8eb40 pc=0xf81cde
2094@1618650071.701933:exec_tb_exit tb:0xb2a8eb40 flags=0x0
2094@1618650071.703334:exec_tb tb:0xb2a8da00 pc=0xf81ce0
2094@1618650071.704845:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.706276:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.707796:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.709239:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.714500:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.715744:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.717143:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.718450:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.719862:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.721154:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.722614:exec_tb_exit tb:(nil) flags=0x0
2094@1618650071.723941:exec_tb tb:0xb2a89c00 pc=0xf82934
2094@1618650071.725367:exec_tb_exit tb:(nil) flags=0x0

followed by this rather odd set of pcs:
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0x710
0x6f2
0x704
0xf82934
0x70a
0x5cc
0xf82934
0x5ae
0xf82934
0x52a
0xf81920
0xa1a
0xa32
0xa44
0xf82934
0xa0e
0xa14
0xa20

So there is quite a lot of active m68k work between qemu 5.2 and qemu 6.0, so I'm trying to use the newer version instead first.

Interesting stuff - F8xxxx range is in the kickstart ROM, so you could verify that the instructions you're seeing really do exist in the ROM file at that point.

If it still fails after you've updated to the newer qemu, would it be easy to see where a6 is pointing at that point in the code? And where the VBR and interrupt vectors are pointing?

I get the same sequence on 6.0

0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0x710
0x6f2
0x704
0xf82934
0x70a
0x5cc

Interestingly it does the loop perfectly fine earlier on
0xf819c6
0xf819f6
0xf82934
0xf819c6
0xf819f6
0xf82934
0xf819c6
0xf819f6
0xf82934

I'll see what I can dig out.

In the meantime here is the patch in case anyone wants to try it too

After extracting qemu then its
cat ../qemu.patch | patch -p1
(the patch is against 5.2 and there a few need manually applying for v6 since there is a new m68 target)
./configure --cross-prefix=arm-linux-gnueabihf-
make qemu-system-m68k -j12

Well it turns out it can capture a shed load of stuff, see attached! Would be easier to look through this with the kickstart 3.1 commented disassembly. Is this available somewhere?

The first time through, the stack and frame pointers are in low chip RAM - the second time they're in fast RAM - that might give some clue?

foft wrote: ↑Sat Apr 17, 2021 10:01 am I get the same sequence on 6.0

0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0xf82934
0x710
0x6f2
0x704
0xf82934
0x70a
0x5cc

Interestingly it does the loop perfectly fine earlier on
0xf819c6
0xf819f6
0xf82934
0xf819c6
0xf819f6
0xf82934
0xf819c6
0xf819f6
0xf82934

I'll see what I can dig out.

In the meantime here is the patch in case anyone wants to try it too

After extracting qemu then its
cat ../qemu.patch | patch -p1
(the patch is against 5.2 and there a few need manually applying for v6 since there is a new m68 target)
./configure --cross-prefix=arm-linux-gnueabihf-
make qemu-system-m68k -j12

Any chance 0xf82934 is an interrupt handler, and it's failing to block out multiple interrupts from a single event?

I was wondering about interrupts. I just poll them 500000 times/sec. Perhaps there is no auto-clear.

I turned off fastram and it still failed the same way.

However I have another hint! If you try 'play module' in diagrom its completely screwed up with qemu. Seems like its playing very slowly and misses a lot of notes too. Which I guess does point to some irq issue. The irq test itself work fine but think that is pretty basic.

p.s. might have no further time to look until tomorrow now

Did you build the qemu dependencies from source or were you able to find gnueabihf dev packages for glib, gthread and whatever else it needs somewhere?

I’m using Ubuntu so can use all the Debian/Ubuntu multi-arch stuff. So apt-get install blah:armhf
It was a different libc to mister hence the copying of ld.so...

Confirmed that the IRQs are not cancelled properly.

I've tried a few patches to sort that out but so far now having much luck getting any further towards the kickstart disk.

lordoftime79 wrote: ↑Sat Apr 17, 2021 9:02 am this is brilliant I having lots of fun experimenting! how does the hack work? does it stop me having to do the ssh stuff?

Unless you are interested in debug information, you no longer need to use SSH to start the CPU when you have installed the modified MiSTer and 68000 script. It simply works by doing this for you when you select "Reset" from the OSD.

bbond007 wrote: ↑Sat Apr 17, 2021 10:08 pm

lordoftime79 wrote: ↑Sat Apr 17, 2021 9:02 am this is brilliant I having lots of fun experimenting! how does the hack work? does it stop me having to do the ssh stuff?

Unless you are interested in debug information, you no longer need to use SSH to start the CPU when you have installed the modified MiSTer and 68000 script. It simply works by doing this for you when you select "Reset" from the OSD.

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?

lordoftime79 wrote: ↑Sun Apr 18, 2021 12:42 am
I am setting the ram to 8mb fast and hitting reset so What am I doing wrong?

Why "_Amiga" and not just "Amiga"

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

lordoftime79 wrote: ↑Sun Apr 18, 2021 1:04 am 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

I looked at the music replay routine on diagrom, since I thought that was also indicative of an IRQ problem. It doesn't use IRQs, it uses CIA timers and polls them. Now CIA timers are interesting since they are 8-bit hardware registers, while the rest of the Amiga hardware registers are 16-bit.

So ... this brings me back to endianness. The 68k is big endian and the arm is switchable. armhf debian (and mister) are little endian. The hps-fpga bridge is little endian.

In Musashi I added 16-bit and 32-bit byte swaps to switch from 68k big-endian to hps-bridge little-endian. In qemu I expected that I'd have to do that, but IT WORKED WITHOUT. Which means it must have some policy I have to understand. Anyway I know that:
i) rom reads to the emulated cpu work.
ii) 16-bit hardware access works.
I don't know how 8-bit access is handled.

I have a cross compiler for m68k so might try out some memory access with qemu user mode and see how it works. With the assumption that it behaves the same as in system mode (which may not be the case). Otherwise I'll need to set up the cross compiler to make my own new rom to test stuff I guess. Though thinking about that there is elf loading code in the qemu 'machines' so might be able to directly load a compiled elf binary into the 'system'.

Anyway no time to later, just thinking!

foft wrote: ↑Sun Apr 18, 2021 8:09 am In Musashi I added 16-bit and 32-bit byte swaps to switch from 68k big-endian to hps-bridge little-endian. In qemu I expected that I'd have to do that, but IT WORKED WITHOUT. Which means it must have some policy I have to understand. Anyway I know that:
i) rom reads to the emulated cpu work.
ii) 16-bit hardware access works.
I don't know how 8-bit access is handled.

This might be a byte-mirroring problem, then? (When writing a single byte the CPU should put the value-of-interest in both halves of the 16-bit word) - or maybe the byte selects are simply backwards?