exxos's Atari, Amiga & retro forum

I am getting decent performance from PiStorm now. But..... have to use a Pi4. I am seeing 3.91MB/s (98%) read/write performance compared to real STFM and STE.

I doubt we will attain the dizzy performance the Amiga owners see I'm afraid as the ATARI just has too much to do for every read/write. I used to have big bus-error checking overheads, but have resolved those now. However interrupt handling remains a big overhead, and there are a LOT of interrupts every second.

The protocol IS a problem though. It is inefficient! If the hardware interface was 32bit instead of the current 16bit, then each GPIO setup would be halved - this would be a significant gain.

I am toying with the idea of incorporating a modified pistorm (32bit), with a Pi4 Compute Module on to a CPU adapter board. The downside of that though is there is no integrated USB or HDMI.

I have spoken to the Emu68 developer and he has incorporated FC bits. I haven't gone any further with it yet. As badwolf mentioned, going bare-metal is hard, and to be honest, it won't help with the GPIO performance anyway.

@dad664npc for a layman like myself, could you explain how bare metal is harder? Is it a completely different kind of language to deal with?

Steve wrote: 29 Apr 2023 10:50 @dad664npc for a layman like myself, could you explain how bare metal is harder? Is it a completely different kind of language to deal with?

It's harder because you don't have an operating system supplying the drivers and hardware abstraction for you. You have to basically write code to run everything form scratch. It's the difference between writing an application and writing a whole operating system plus the application.

@stephen_usher I get that, but that's not exactly the case in this situation though. I mean, the 'OS' is there, it doesn't need to be written from scratch. Emu68 would just need tweaking for Atari specific attributes.

So my question isn't about making it from scratch, it's about how working with the pre-existing emu68 code is more difficult than the pre-existing musashi code.

My understanding might be wrong but I believe that musashi runs on the pi OS but emu68 is just running on the hardware without an OS.

Steve wrote: 29 Apr 2023 12:10 @stephen_usher I get that, but that's not exactly the case in this situation though. I mean, the 'OS' is there, it doesn't need to be written from scratch. Emu68 would just need tweaking for Atari specific attributes.

So my question isn't about making it from scratch, it's about how working with the pre-existing emu68 code is more difficult than the pre-existing musashi code.

That's not how Emu68 works. The bare metal 680x0 emulator exposes the RPi hardware to the Amiga at a particular memory address. You then have to write drivers (in 68000) for AmigaOS.

Atari ST has a different memory map to begin with. And it's a completely different OS.

No tweaking here. It's a complete rewrite for a different OS.

I don't think I'm being understood here, I'm not talking about any kind of OS. Emu68 isn't an interpreter for an OS, it's a CPU interpreter. I'm also not talking about drivers.

All I am talking about is the fact that emu68 is a CPU interpreter, and those aspects of that interpreted CPU will be compatible with other 68k hardware. I understand there are more aspects of 68k emulation that need to be added.

All I was asking was about the challenges of making emu68 support the extra instructions required by Atari.

No extra instructions are there? It's bus errors, processor state, bus arbitration. I think Michael said he could add FC (Processor State)

But Emu68 HDD drivers won't work so no mass storage similarly no gfx card, no ethernet etc

For the last couple of weeks, I have been playing with "baremetal" on the PI4. I have gotten to the point where the emulator runs, but when returning from an interrupt the PC is corrupted so all hell breaks loose lol.

That aside, whilst stepping through the code I realised that a lot of optimisations could be made. So implementing these changes to the non-baremetal code, performance has increased A LOT!

COREMARK is now as high as 57, ELITE FB is around 3391, GemBench is just stupid

dad664npc wrote: 21 Jun 2023 11:53 For the last couple of weeks, I have been playing with "baremetal" on the PI4. I have gotten to the point where the emulator runs, but when returning from an interrupt the PC is corrupted so all hell breaks loose lol.

Oh cool! I've not dropped into PiStorm Discord for a while, I hadn't realised you were working on a baremetal version! :o

That aside, whilst stepping through the code I realised that a lot of optimisations could be made. So implementing these changes to the non-baremetal code, performance has increased A LOT!

:fire1: :2hot: :excited: :excited: *

Wow!

Consider my socks well and truly blown off!

Fantastic work, Steve. Love it! :D

BW


* Have you noticed how most of exxos' smilies are about frustration and beating people up? This is the best I could come up with for gobsmacked and blown away :P