This sounds like a great development. Thanx for sharing this news.

_________________
Sent from my Quantum Computer.

Sounds good!

Excellent news. I hope this get ported to more platform outside of A600GS / Amibench.

Pistorm and Pi builds would be great.

I cant help but think if you had put this into a full size Amiga replica case with working replica Amiga keyboard, (i know it would of likely double the costs if not more) but i think you would have had a real kill product on your hands, and I know eye candy and kinda daft thing like that shouldn't matter, what the system can do, should matter more, as I this will kick A500 mini into the ground for what it can do, but likely just because of the way it looks, i kinda feel it going to struggle. I hope im wrong.

_________________
AmigaNG, YouTube, LeaveReality Studio

What did I tell ya? This is the one to watch.

_________________
All the way, with 68k

Quote:

The library provides a link between 68K programs and the native ARM processor.

How is it “linked� to the ARM side, outside of the emulator? A host OS (Linux?) component?
And why only limited to graphics? Why not make it more generic, sort of like PowerUP or WarpUP?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Sounds like either a CGX/P96 clone or something like EGS.

Not sure if that was really needed....

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

Looks interesting. Looking forward to seeing it in action.

_________________
Sam

Quote:

Sounds like either a CGX/P96 clone or something like EGS. Not sure if that was really needed....

A P96 driver would probably have made more sense.

Why is the date on this 3rd July?

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

07th of march 2024 :D

Last edited by petrol on 10-Mar-2024 at 06:03 PM.

@amigakit

FYI, maybe you already know this but just in case you don't.

There is no Wikipedia page for the A600GS.

It is mentioned in the OctaMED entry.

From Wikipedia

https://en.wikipedia.org/wiki/OctaMED

The page "A600GS" does not exist. You can create a draft and submit it for review or request that a redirect be created, but consider checking the search result below to see whether the topic is already covered.
OctaMED
OctaMED was updated primarily for inclusion in AmigaKit's forthcoming A600GS computer system. The upcoming OctaMED v8 will add important features such...

Last edited by DiscreetFX on 13-Mar-2024 at 02:05 AM.
Last edited by DiscreetFX on 11-Mar-2024 at 02:22 AM.

_________________
Sent from my Quantum Computer.

Quote:

07th of march 2024 :D

Unless the version command is translating it to American date format, which (a) I don't think it can do and (b) AmigaKit are in Wales so I don't see why they'd be using that anyway, that date is 3rd July 2024.

$VER string dates are supposed to be d.m.yyyy.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

I explained how an ARM Cortex-A53 core wastes about half of its performance on load-to-use stalls in the following thread.

https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=44957&forum=8&start=200&viewmode=flat&order=0#868905

Rather than calls to an ARM graphics library to gain back some of the 50% performance loss of an emulator executing unscheduled code, there are other options.

1. Use the successor in-order Cortex-A55 that reduces the load-to-use penalty from 3 cycles to 2 cycles. This alone should improve best case cached performance by over 15%. A Cortex-A55 is not much larger and shouldn't cost too much more yet should be significantly better at emulation of 68k code.

2. Use a SoC with an in-order SiFive U74 core utilizing a CISC like core design that usually eliminates the load-to-use penalty. A best case 40-50% performance improvement emulating 68k code is likely from eliminating load-to-use stalls. In some ways the U74 core is simpler and not as mature as the Cortex cores but shows that a good design can outperform larger and more expensive cores. The U74 core is likely similar size or smaller compared to in-order Cortex cores helping to reduce cost but availability is tricky as SiFive does not directly produce commodity chips.

3. OoO Cortex cores should improve performance with results dependent on how aggressive the OoO is which is difficult to predict. If a RPi hardware was selected instead of custom hardware, then upgrading from a RPi 3 to a RPi 4 would be an easy solution. The down side is a much hotter SoC that needs a fan. The cost of the SoC is higher and the cost of the fan increases this. Even the RPi 3 can experiences throttling that lowers the CPU core clock speeds and the RPi 4 runs significantly hotter but does more work instead of being stalled over half the time like most cheap RISC cores.

4. If compiling the OS for the hardware, it would be possible to crack CISC reg-mem instructions and schedule instructions for a RISC like core. The most common reg-mem instruction is the following...

add mem0,reg0

which can be decomposed into the following...

move mem0,reg1
add reg1,reg0

This is what emulators for RISC architectures do with load-to-use stalls in between the 2 instructions but cracking at compile time allows instruction scheduling. There are a couple of downsides which are increased code size and increased register use, RISC traits. Ideally, RISC code is scheduled like the following...

move mem0,reg0 ; load
move mem1,reg1 ; load
move mem2,reg2 ; load
move mem3,reg3 ; load
add reg0,reg4
add reg1,reg5
add reg2,reg6
add reg3,reg7

This is the minimum unrolling required to eliminate a 3 cycle load-to-use penalty and it is using 8 registers which is twice as many registers as 68k code uses. Most low end superscalar RISC cores can only do one mem load/cycle and this code requires best case 6 cycles instead of 4 cycles for a pipelined scalar 68k core and potentially 2 cycles for the 68060. Without a 2nd load unit (and 2nd simple int unit) for a superscalar RISC core, instruction scheduling is often too hard and cycles are lost. This is why low end in-order RISC cores are known for poor performance. Still, it is probable that cracking the CISC instructions and scheduling for RISC core load-to-use stalls would provide some performance benefits to compiled code. Performance would usually be lower than calling native functions but it could be used more widely. Both are a waste of developer resources due to a very poor RISC CPU core choice for emulation of 68k code.

5. Use a 68k CPU core. Even a pipelined scalar 68k CPU core should outperform a Cortex-A53 core for 68k native code given a similar clock speed and resources (especially caches). A pipelined superscalar 68060 core with similar speed and resources should be closer to the performance of older ARM OoO cores and PPC OoO cores. We should have higher performance 68k cores emulating weak RISC cores where load-to-use stalls can be eliminated. The 68k has similar performance traits to x86(-64) but is more efficient and less bloated making a superscalar 68060 like core more practical. Availability is an issue requiring an ASIC but then this is the best solution for performance of 68k code and the most appealing to 68k Amiga fans. There is more performance with less heat than an OoO RISC core emulating the 68k and the memory (and cache) footprint is a fraction of using ARM JIT emulation thus reducing costs.

Last edited by matthey on 12-Mar-2024 at 09:51 PM.

@Chris_Y

Occam's razor.

_________________
All the way, with 68k

@agami

Getting Philosophical on us?

Last edited by DiscreetFX on 13-Mar-2024 at 02:07 AM.

_________________
Sent from my Quantum Computer.

@matthey

How's your own system shaping up?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

Great stuff looking forward ! Arm is the way to go !