@ppcamiga1

>pistorm is piece of shit that changes your amiga into mouse and keyboard interface for rpi.

No it doesn't. It is actually one of the bigger points of the design that it does NOT do this.

And before you hit the reply-button check to WHOM you are replying. I have done massive software releases for both AmigaOS 4 and PiStorm and know both systems inside out.

And yes, I prefer OS4. But still what you claim is simply WRONG.

@amigang

Not sure what these "software issues" on PiStorm should be ? I am not aware of any ? Only things as bad points I am aware of:

- Two connectors (to two monitórs) needed (while Vampire can have all through one HDMI cable)
- Not as fast as other solutions (Pi5+Amikit is nearly as fast as an AmigaOne x5000)
- Cannot use a Pi5 (but most of the other options you list cannot either)

As to PiStorm "not as fast as emulation could be" ? What do you mean by this ??? It is faster than nearly all of the options you list. With only exception of Pi5+Amikit and no idea ahow fast "the a1200" will be. PiStorm/Emu68 is currently the most efficient Emulation option (due to the fact that it only emulates the CPU and uses the existing hardware for other things). Of course Pi5+Amikit beats this by simply having a Pi5 while PiStorm only got a Pi4.

As to A1200NG

- Not 100% accurate emulation is a bit underestimating it. For example Heretic 2 and Gorky 17 both do NOT work under Amibench (Heretic 2 works under the 600GS with OS3.2 installed, Gorky 17 not even with OS 3.2)
- I would not list access to Amibench as a "+" I have to admit
- If you wonder on speed difference to PiStorm - 600GS (and I take it A1200NG is basically the same hardware) is around 10% slower than a PiStorm 3 (a PiStorm 4 will of course be noticably faster).

As to the Vampire vs. PiStorm thing - the only reason to go for Vampire is if you both use highres Workbench and old games which require PAL/NTSC. And do not have a second monitor. Or want some sort of game which only runs on Vampire (though I think there will be more and more games not running on Vampire as it is too slow for them).

@MagicSN

Quote:

Not sure what these "software issues" on PiStorm should be ? I am not aware of any ? Only things as bad points I am aware of: - Two connectors (to two monitórs) needed (while Vampire can have all through one HDMI cable) - Not as fast as other solutions (Pi5+Amikit is nearly as fast as an AmigaOne x5000) - Cannot use a Pi5 (but most of the other options you list cannot either) As to PiStorm "not as fast as emulation could be" ? What do you mean by this ??? It is faster than nearly all of the options you list. With only exception of Pi5+Amikit and no idea ahow fast "the a1200" will be. PiStorm/Emu68 is currently the most efficient Emulation option (due to the fact that it only emulates the CPU and uses the existing hardware for other things). Of course Pi5+Amikit beats this by simply having a Pi5 while PiStorm only got a Pi4.

Well you only have to Google, "Pistorm Crashs" and you will get a number of threads and issues, to be fair a lot have been ironed out so maybe it was a bit harsh now the software has gotten better.

On the "Not as Fast as other solutions", I do basically mean the first choice, Emulation on custom hardware, Pi5 or mini x86 system. I mean one thing I have been on the look out for is a broken screen Valve steam deck, or similar (i did see one sold for as little as £70! and the hardware still worked), this would be massively over kill for Amiga emulation and beat Pi5 performance. The motherboard would easily fit a1200 case, add a USB C Hub with ports and HDMI out and hay presto you got yourself a very powerful system!

Quote:

As to A1200NG - Not 100% accurate emulation is a bit underestimating it. For example Heretic 2 and Gorky 17 both do NOT work under Amibench (Heretic 2 works under the 600GS with OS3.2 installed, Gorky 17 not even with OS 3.2)I would not list access to Amibench as a "+" I have to admit

Well software is still developing and I am interested in efforts to make the OS more aware of the fact its on an ARM system and take advantage of ARM chip, like the ARMgraphics.library. That can boost these speeds maybe pass Pi5. Plus it not just Amibench, software classics like PPaint, Octamed, final writer all got little updates which is always nice to see.

Last edited by amigang on 15-Apr-2025 at 08:41 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang
I just also learned about this development for vampire v4,
http://www.apollo-core.com/knwledge.php?b=1¬e=41089&order=&x=0

68k fusion will allow vampire v4 to get to 600mips, which get the system a lot closer to pistorm3 performance (which can do around 900mips).

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Quote:

Well you only have to Google, "Pistorm Crashs" and you will get a number of threads and issues, to be fair a lot have been ironed out so maybe it was a bit harsh now the software has gotten better.

Emu68 is very stable since the V1.0 release, My A1200 with PS32+CM4 @2.2Ghz is rock solid.
Uptime of 100+ hours without reboot is too easy for example.
And it all just works also WHDload games and demos (state of the art, desert dream etc etc)
Sure you'll have to dial in WHDload because you know wicked fast processor.
The WHDload wrapper does this for you and makes it extremely easy.

In terms of speed a config like PS32+CM4 @2.2Ghz is quite overkill already to give some examples:
Quake runs at nearly 150 fps in 320x200 software render (RTG)
Mpeg 1 video playback up to 1280x720 32bit with high bit rates (5200+ kbps 48Khz sound)
MP3 or Shoutcast playback you don't even notice it's running (with Amiga-Amp running all in highest possible settings)
Even the heaviest scene demos (Elude, TBL etc) run buttery smooth even on real AGA.

All in all you'll really get a WinUAE fast feeling/performance with a PS32+CM4 at 2.2Ghz, even better my A1200 with PiStorm outperforms WinUAE on my very old i7 870 (by quite a margin too).

Last edited by Mr-Z on 16-Apr-2025 at 05:09 AM.

_________________
Amiga is additive coz it is fun to use

@amigang

Quote:

take advantage of ARM chip, like the ARMgraphics.library.

Take a step back… what does ARMgraphics.library actually do? What does Emu68 actually do? Perhaps you will discover that Emu68 already allows everything armgraphics.library does AND MORE.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

amigang Quote:

Well software is still developing and I am interested in efforts to make the OS more aware of the fact its on an ARM system and take advantage of ARM chip, like the ARMgraphics.library. That can boost these speeds maybe pass Pi5. Plus it not just Amibench, software classics like PPaint, Octamed, final writer all got little updates which is always nice to see.

There are 3 different possibilities to better "take advantage of ARM chip".

1. native ARM code library
+ takes advantage of standard ARM ISA CPU cores
+ better optimized ARM code than JIT, especially for in-order ARM CPU cores
- optimization varies by ARM ISA, CPU design and endian mode so multiple libraries and not universal
- endian conversions or deprecated BE mode needed
2. 68k code/driver using ARM SoC hardware (emu68)
+ takes advantage of standard RPi SoC hardware
+ better optimized use of SoC hardware
+ minimizes software layers
- native ARM code is better optimized than JIT code
- requires standard SoC hardware and specific to that hardware
- BE mode support is currently standard for RPi hardware but deprecated for new ARM SoCs
3. native ARM code library using SoC hardware
+ takes advantage of standard RPi SoC hardware including ARM ISA CPU cores
+ better optimized use of SoC hardware including ARM CPU cores
+ better optimized ARM code than JIT, especially for in-order cores
- requires standard SoC hardware and specific to that hardware
- BE mode support is currently standard for RPi hardware but deprecated for new ARM SoCs

Similar optimizations are possible for other SoCs with different architectures emulating the standard 68k Amiga. The 68k Amiga is standard for the 68k CPU architecture and Amiga chipset which when better integrated becomes a SoC as Commodore planned and the cost reduction likely would have saved them if they had delivered. The AmigaOS is also standard on the 68k Amiga.

68k Amiga SoC
CPU: 68000, 68020 (standard and all backward compatible)
chipset: OCS/ECS/AGA (standard and all backward compatible)
GPU: none yet for 3D
OS: AmigaOS (standard and backward compatible for all versions)

ARM SoCs
CPU: ARM, Thumb, Thumb-2, AArch64 (standard but old ISAs being dropped)
chipset: ? (not standard but can be similar using standard ARM IP blocks)
GPU: Mali (not standard but ARM trying to force Mali GPUs for ARM SoCs)
OS: ? (not standard)

RPi SoCs
CPU: ARM, Thumb, Thumb-2, AArch64 (standard for now but old ISAs being dropped by ARM)
chipset: ? (similar but not standard)
GPU: VideoCore (mostly standard but ARM trying to force Mali GPUs for ARM SoCs)
OS: ? (Raspberry Pi OS is the most popular but not as standard as the AmigaOS on Amiga hardware)

The 68k Amiga standard remains strong. Attempts to replace the CPU and chipset hardware were abject failures. Emulation retains the base 68k Amiga standard and the performance is good enough to destroy the PPC AmigaNOne market but further optimizations for other hardware are less standard and divide the 68k Amiga market. Compromises are being made and compatibility reduced for performance like MMU and FPU support. The AmigaOS has declined from 68020 to 68000 support. There is no interest in an enhanced 68k ISA or ABI to modernize the 68k with emulation. There will never be 64-bit or SMP support for the 68k AmigaOS using emulation. Compiler support for the 68k will continue to decline with emulation. Maybe you view optimized emulation libraries as good but they are not development for a standard 68k Amiga system but a divided and closed bastard ARM standard so I view them as bad. Instead of uniting and using the 68k Amiga strengths, we are dividing and using ARM weaknesses.

amigang Quote:

I just also learned about this development for vampire v4, http://www.apollo-core.com/knwledge.php?b=1¬e=41089&order=&x=0 68k fusion will allow vampire v4 to get to 600mips, which get the system a lot closer to pistorm3 performance (which can do around 900mips).

This sounds like more AC68080 marketing BS to me. First of all, Gunnar uses the words "Up to 600 Mips" which is peak performance. Gunnar does not say whether this is millions of instructions per second, Dhyrstone DMIPS or useless SysInfo MIPS. More code folding/fusion should increases the peak performance but it would have a much smaller affect on average performance.

Gunnar von Boehn [quote]
With the current fusing the CPU can schedule up to six instructions per cycle and can retire up to 8 instructions per cycle.
[quote]

The mostly in-order AC68080 gives the instruction fetch as 16 bytes/cycle and it does not have a decoupled instruction fetch pipeline (IFP) and operand execution pipelines (OEPs) with instruction buffer like the 68060. This means the number of instructions that can execute per cycle is limited by the number of instructions fetched per cycle. The 68k average instruction length is less than 3 bytes per instruction but it would be rare that enough instructions would be fetched in a single cycle for even 6 instructions to execute. The average instruction length would have to be 16/6=2.66 or less for 6 instructions to execute which is rare for compiled code. My guess is that 6 instructions would be fetched less than 50% of the time and likely closer to 25% of the time. Branches make this more difficult as about 1 in 5 instructions (15%-20%) is a branch on average and mostly in-order cores and FPGA cores have a limited ability to execute instructions speculatively. Loads are about 1 in 4 (25%) instructions and can be executed in the same cycle only when the loaded data is in the L1 cache and only 1 load is allowed per cycle (AC68080PRM states only 1 load and 1 store allowed per cycle which is the same as the 68060). I would be surprised if 6 instructions could be executed in a single cycle even 10% of the time. Code folding/fusing would increase the average instructions executed per cycle but there would be a limited number of folding/fusion opportunities and primarily with existing 68k code. The less orthogonal AC68080 ISA and larger instructions with instruction prefixes makes executing more instructions with code folding/fusion more difficult. Overall, I expect to see a less than 10% average performance gain from additional code folding/fusing. A higher clock speed, more caches and/or an OoO design are needed to substantially increase performance. A higher end FPGA would allow a higher clock speed and more space for caches which have synergies together despite the still low clock speed for an affordable FPGA. It is likely the only way for the FPGA AC68080 to compete with the performance of a 68k CPU using emulation. The problem is that FPGA prices increase faster than ASIC prices as the number of transistors grow.

Last edited by matthey on 17-Apr-2025 at 05:16 PM.

@amigang

I HAVE a pistorm system and do not know
of these crashes. On the other hand both
Amibench and apolloos seem to be ways more
instable (and in case of amibench also ways
more incompatible).

As to armgraphics lib - at least for what i do - porting pc
games - it is useless. I do my own code to write
direct to videoram anyways. And 600gs is around
10% slower tham a technically sort of equivalent pi3.

Something like porting libs is only an advantage if more
of them are ported.

What is interesting though is that they mentioned there
might be in future models with higher hardware.

@amigang

Forget about mips (aka „meaningless
indicator of processor speed“ ;))

What does fusion do? It is about new
Cpu commands as far as i understand which are very
specific to 68080.

To have any use it would need support in gcc.

Currently i have two 68k compilers available- one
is 6.50b which is a bit old and cannot compile all
projects i work on (vut some) and has 68080
support (but no support to fusion).

The other is a recent gcc but does not support 68080
(Projects like gemrb and Stratagus i can only compile
for 68040 or 68060 - which runs on Vampire but without
any speedup advantage.

Like the other guy with whom i rarely agree i think
it is mainly pr business and advertising (unless you
work on vampire only titles - then it surely is useful,
but why close the door to other 68k solutions)?

If i would do 68k ports excluding to one 68k platform it
would be pistorm (but i do not do exclusives), even
with little optimization faster than massively asm optimized
On vampire. Instead i check on a by case basis on
what platform a game can run. And no this is no
„Straight pc porting“.

@MagicSN

My take about fusion is that 'it just works' no special need, just take advantage of the speed bump

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

pixie Quote:

My take about fusion is that 'it just works' no special need, just take advantage of the speed bump

Correct. Instruction folding/fusing works with and benefits preexisting 68k code but compilers can emit instruction combinations that increase the benefit. Motorola used the term instruction "folding" for folding away instructions by either combining/fusing instructions or removing them from the code stream, especially in the specific case of branch folding. Intel, AMD and others use the term "fusing" but it may refer to micro-op, macro-op or whole instruction combining. The 68060 is only documented as using branch folding but ColdFire V4 added additional instructions fusing using a similar pipeline design (scalar ColdFire V4 is like unreleased 68060 Lite and superscalar ColdFire V5 is like 68060).

Motorola Thaws ColdFire V4
https://www.cecs.uci.edu/~papers/mpr/MPR/2000/20000515/142001.PDF Quote:

The instruction-folding technique enables limited parallel execution without the extra logic of dual-issue superscalar pipelines. The second section of the V4 pipeline automatically folds certain pairs of instructions into a single cycle operation. For example, it combines MOV.l mem,Rx and ADD.l Ry,Rx to create ADD.l mem,Ry,Rx. Motorola says these kinds of instruction pairs occur frequently in embedded programs. Programmers writing in assembly language could make sure it happens by deliberately pairing those kinds of instructions inside critical loops.

ColdFire Doubles Performance With v4
https://websrv.cecs.uci.edu/~papers/mpr/MPR/19981026/121406.pdf Quote:

Last, ColdFire v4 is smart about collapsing commonly used constructs into a single operation. If two instructions will execute in different stages and have no dependencies, they will execute together in a single cycle. This “instruction folding� is ColdFire’s first move toward superscalar dispatch.

The execution pipeline design of the 68060, ColdFire V4, ColdFire V5 and AC68080 have an EA calc stage and normal execution stage which sometimes allows 2 instructions to be executed together, instructions to be executed early and late avoiding dependencies and powerful CISC like instructions to execute with complex addressing modes using memory in a single cycle that are the equivalent of two RISC instructions. This type of design gives more opportunities for instruction folding than simpler and weaker designs. The 68060 successors would likely have received similar instruction folding optimizations had it continued to be developed.

@amigang

Quote:

amigang wrote: @amigang I just also learned about this development for vampire v4, http://www.apollo-core.com/knwledge.php?b=1¬e=41089&order=&x=0 68k fusion will allow vampire v4 to get to 600mips, which get the system a lot closer to pistorm3 performance (which can do around 900mips).

That's pure marketing: it's impossible to reach such (very very) peak rate, unless for some synthetic benchmark purely written for achieving it.

It's a big number put there only for showing something which could resemble the MIPS shown by PiStorm (using the more obsolete and less performing RPi model) with emu68.

@cdimauro

Indeed. I could say something similar about Emu68:

The translation from m68k to JIT is capable of detecting special combinations of instructions that are typically injected when converting data between Big and Little Endian formats. In such cases, three m68k instructions are translated into a single aarch64 instruction.

One could, of course, craft a synthetic benchmark that performs nothing but LE-BE translation in registers, inside a tight loop. In that scenario, Emu68 might easily hit 6000 MIPS (300% efficiency) compared to m68k code on a 2GHz aarch64. But that’s just marketing fluff. Fusing, or whatever term we end up using, does help, of course. For instance, I can merge two consecutive post-increment or pre-decrement loads/stores into a single aarch64 LDP instruction. Similarly, I can detect byte or word loads followed by register extensions (signed or unsigned) to 32-bit. All of this helps, but outside synthetic tests, the overall performance gain isn’t massive.

@matthey

Quote:

matthey wrote: amigang Quote: Well software is still developing and I am interested in efforts to make the OS more aware of the fact its on an ARM system and take advantage of ARM chip, like the ARMgraphics.library. That can boost these speeds maybe pass Pi5. Plus it not just Amibench, software classics like PPaint, Octamed, final writer all got little updates which is always nice to see. There are 3 different possibilities to better "take advantage of ARM chip". 1. native ARM code library + takes advantage of standard ARM ISA CPU cores + better optimized ARM code than JIT, especially for in-order ARM CPU cores - optimization varies by ARM ISA, CPU design and endian mode so multiple libraries and not universal - endian conversions or deprecated BE mode needed 2. 68k code/driver using ARM SoC hardware (emu68) + takes advantage of standard RPi SoC hardware + better optimized use of SoC hardware + minimizes software layers - native ARM code is better optimized than JIT code - requires standard SoC hardware and specific to that hardware - BE mode support is currently standard for RPi hardware but deprecated for new ARM SoCs 3. native ARM code library using SoC hardware + takes advantage of standard RPi SoC hardware including ARM ISA CPU cores + better optimized use of SoC hardware including ARM CPU cores + better optimized ARM code than JIT, especially for in-order cores - requires standard SoC hardware and specific to that hardware - BE mode support is currently standard for RPi hardware but deprecated for new ARM SoCs

There could be another one:

4. 68k+ with SIMD/Vector extension code/driver using ARM SoC hardware (emu68+)
+ takes advantage of standard RPi SoC hardware
+ better optimized use of SoC hardware
+ minimizes software layers
+ use of 68k+ extension (new addressing modes and instructions) and a new SIMD/Vector for enhancing critical code (data types, graphics library / RTG, AHI).
- native ARM code is better optimized than JIT code
- requires standard SoC hardware and specific to that hardware
- BE mode support is currently standard for RPi hardware but deprecated for new ARM SoCs

This way there's no need to have ARM versions of the graphics library and datatypes. Performance wouldn't be at the same level, but very close (a 68k+ SIMD/Vector extension makes it's much easier and more efficient to exploit data-parallel code with emu68+ JIT).
The advantage is that it'll set and spread an enhanced 68k, without requiring to bind the code to specific ARM versions (and, in general, to a specific architecture).
Quote:

The AmigaOS has declined from 68020 to 68000 support. There is no interest in an enhanced 68k ISA or ABI to modernize the 68k with emulation. There will never be 64-bit or SMP support for the 68k AmigaOS using emulation.

The main problem here is that it's impossible to have the Amiga OS supporting 64-bit and SMP. Unfortunately, it's strictly bound to 31-bit and a single core/thread.

Amiga OS applications should run on a sandbox, whereas an Amiga OS64/SMP will have its proper applications (but who'll write this new OS? And its applications?).
Quote:

Compiler support for the 68k will continue to decline with emulation.

I don't believe so. Bebbo has shown what's possible with GCC, and LLVM has a new 68k backend (immature, but it can greatly improve).

There's a general revival of the old, retro platforms, because there are still many passionate and new ones which are joining because they are curious about such good old days (and remain fascinated).

There's still hope.
Quote:

A higher clock speed, more caches and/or an OoO design are needed to substantially increase performance. A higher end FPGA would allow a higher clock speed and more space for caches which have synergies together despite the still low clock speed for an affordable FPGA. It is likely the only way for the FPGA AC68080 to compete with the performance of a 68k CPU using emulation. The problem is that FPGA prices increase faster than ASIC prices as the number of transistors grow.

There's no hope that the Apollo core could compete with PiStorm/Emu68 remaining with an FPGA: numbers are too low and the comparison is merciless.

The only way for it to have a chance is by splitting the project into two parts: an ASIC for the 68k core and a small FPGA for the chipset (you don't need a fat FPGA only for this purpose). But with some changes:
- discarding the super crappy prefixes and AMMX extension;
- adding an effective 64-bit mode;
- extending the FPU registers to 16;
- adding a proper SIMD/Vector unit (scalable for future needs);
- discarding the horrible patchwork made with SAGA;
- virtualizing the OCS/ECS/AGA registers (like it was made with AAA);
- adding 32-bit equivalents of the old 16-bit registers, but in a new registers bank;
- properly enhancing the chipset using the new 32-bit registers, in a scalable and future-proof way.

There's no hope that the Apollo core could become the new Amiga until Gunnar continues with his very narrow-mind of "adding a patch to get something". He has no vision on how to evolve the platform in a good way, and this is heavily crippling the project. A good hardware engineer isn't necessarily a good architect...

@michalsc

Quote:

michalsc wrote: @cdimauro Indeed. I could say something similar about Emu68: The translation from m68k to JIT is capable of detecting special combinations of instructions that are typically injected when converting data between Big and Little Endian formats. In such cases, three m68k instructions are translated into a single aarch64 instruction. One could, of course, craft a synthetic benchmark that performs nothing but LE-BE translation in registers, inside a tight loop. In that scenario, Emu68 might easily hit 6000 MIPS (300% efficiency) compared to m68k code on a 2GHz aarch64. But that’s just marketing fluff. Fusing, or whatever term we end up using, does help, of course. For instance, I can merge two consecutive post-increment or pre-decrement loads/stores into a single aarch64 LDP instruction. Similarly, I can detect byte or word loads followed by register extensions (signed or unsigned) to 32-bit. All of this helps, but outside synthetic tests, the overall performance gain isn’t massive.

A JIT has a GREAT advantage even compared to a native core, because it allows things which are simply not possible. Things that even the most advanced out-of-order core can only dream about.

Intercepting patterns, as you've shown, is an example (very valuable, and quicker to get results).

Instrumenting the code executing and making better analysis out of it could lead to further improvements. IF needed & it deserves the effort, of course (which actually isn't the case for the goal of the project).

@MagicSN

if you really have to use 68k use real 68k
get lost with this shit pistorm
it is waste of time and money
you can get the some with winuae for almost free

@ppcamiga1

Quote:

ppcamiga1 wrote: @MagicSN if you really have to use 68k use real 68k get lost with this shit pistorm it is waste of time and money you can get the some with winuae for almost free

The same for your underPPowered CraPowerPcs which have not even The Name.

@ppcamiga1

Don't see how it is a waste, cheaper than the best 060 based card with a lot more power.

Could you also please answer my question from earlier in this thread? I am curious to understand.

_________________
Live Long and keep Amigaing!

A1200, Power Tower, TF1260 128MB RAM, 68060 Rev 6, OS3.9 BB2, HD-Floppy, Mediator TX+ PCI, Voodoo 3 3000, Soundblaster 4.1, TV Card, Spider USB, 100MBit Ethernet, 16GB CF HD, 52xCDRom.

@ppcamiga1

Quote:

you can get the some with winuae for almost free

I don't know what your experience is with WinUAE, and while running productive software I would agree on how great it is, regarding games and everything that hits the chipsets my experience isn't exactly stellar... I am under the impression that the experience if you don't have to emulate the chipsets Will be considerably better.

I have no doubt you rather sell your house to buy a 68060

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga