@matthey

the a500 is not amiga device. it is emulator.
real amiga has real cpu other than pc.

@Karlos

there is no virtual 68k. it is emulator and nothing more than emulator.

and of course.
pi storm is worth nothing crap that change amiga into expensive
mouse and keyboard interface for rpi.
it is dumb because amiga mouse and keyboard was copied 40 years ago from pc.

@ppcamiga1

Can you please show the court where the PiStorm touched you inappropriately?

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: The 68060 had many cost advantages but the Pentium had the desktop economies of scale advantage. Motorola gave up the first and the last advantage when they went with fat PPC and dumped the 68060.

The AIM/PowerPC alliance, was formed on October 2, 1991, between Apple, IBM, and Motorola, this was the end for 68k on the desktop, the 68060 was therefore neglected and went very late into production.

Motorola switched to Coldfire for 68k compatible MCUs, but a 300MHz Coldfire doesn't have the performance a 300MHz 68060 would had. This MCU was developed as a cheap solution for industrial ex 68k customers wanting source code compatibility.


Quote:

matthey wrote: the AC68080 does not even implement all 68060 FPU instructions ...

I don't think they have a paying industrial user for their 68080 implementation, the 68080 FPU isn't IEEE compliant, it may not matter for most Amiga users but without proper FPU they can't compete on the open market.

What's senseless is that this thread has 43 pages...

Get a life dudes! DO something!

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

OneTimer1 Quote:

The AIM/PowerPC alliance, was formed on October 2, 1991, between Apple, IBM, and Motorola, this was the end for 68k on the desktop, the 68060 was therefore neglected and went very late into production.

Correct. Some people just don't see how much the 68060 was neglected during late development. The 68060 started out as near flag ship priority and was demoted to non-core asset before release. If the 68k hadn't been the number one 32 bit embedded CPU in the world, it may have been cancelled like the 88k. It was really ignorant to throw their 68k baby out for the embedded market where they tried to replace it with PPC and ColdFire resulting in the loss to SuperH and eventually ARM. The AIM alliance was an attempt to choose one CPU architecture to improve economies of scale on the desktop which made some sense but it wasn't smart to limit the 68060 clock speed because the in-order 68060 outperformed some of the early OoO PPC CPUs at the same clock speed and it had the potential to clock higher with a deeper pipeline.

OneTimer1 Quote:

Motorola switched to Coldfire for 68k compatible MCUs, but a 300MHz Coldfire doesn't have the performance a 300MHz 68060 would had. This MCU was developed as a cheap solution for industrial ex 68k customers wanting source code compatibility.

It was allowed to clock up a sufficiently weakened and incompatible ColdFire architecture that wasn't the 68k though too late to save the loss of the embedded market. There was a fully superscalar ColdFire V5 that performed roughly on par with the 68060 and likely would have beat it in some benchmarks. I believe it may have only been licensed by one customer and there were no commodity chips but I have Motorola documentation giving some information.

1994 68060 1.8 DMIPS/MHz 8kiB-I/8kiB-D 500nm 8-stage superscalar 2-way

1999 ColdFireV4 1.54 DMIPS/MHz 16kiB-I/8kiB-D ~250nm 9-stage limited superscalar
2002 ColdFireV5 1.83 DMIPS/MHz 32kiB-I/32kiB-D 130nm 9-stage superscalar 2-way

Note that ColdFireV4 "limited superscalar", as Motorola called it, is instruction folding (multi-instruction combining or removal) so really scalar and still outperforming many in-order RISC cores (ColdFire still executes more powerful CISC instructions despite the "RISC encoding" propaganda). ARM cores were still weak at that time.

2002 ARM11 1.25 DMIPS/MHz 16kiB-I/16kiB-D 90-40nm (RPi1=40nm) 8-stage scalar with parallelism
2005 Cortex-A8 2.0 DMIPS/MHz 32kiB-I/32kiB-D 65-45nm 13-stage superscalar 2-way
2011 Cortex-A7 1.9 DMIPS/MHz 32kiB-I/32kiB-D 40-28nm 8-stage superscalar 2-way
2012 Cortex-A53 2.3 DMIPS/MHz 32kiB-I/32kiB-D 40-10nm (RPi3=40nm) 8-stage superscalar 2-way

These were generally popular cores due to being small and ARM11 introduced Thumb2 for code density. The Cortex-A8 had a longer pipeline than desired for most embedded uses and longer pipelines use more transistors for the pipeline and branch prediction making the cores larger and more expensive. ARM abandoned the super deep pipeline and went back to the more practical 8 stage pipeline. ARM used to be known for their small cores.

Year | CPU | transistors
1975 6502 3,500
1979 68000 68,000
1984 68020 190,000
1985 ARM1 25,000
1985 80386 275,000
1986 ARM2 30,000
1987 68030 273,000
1990 68040 1,170,000
1993 Pentium 3,100,000 superscalar in-order 2-way
1994 68060 2,530,000 superscalar in-order 2-way
1994 ARM7 250,000
1995 PentiumPro 5,500,000 OoO uop
2002 ARM11 7,500,000
2008 Nehalem 731,000,000 (1st gen Core i7 with 4 cores) 64 bit OoO uop
2011 Cortex-A7 10,000,000 superscalar in-order 2-way
2012 Cortex-A53 12,500,000 64-bit superscalar in-order 2-way
2012 Cortex-A57 75,000,000 64-bit OoO 3-way big.LITTLE companion of Cortex-A53

Rough ARM transistor counts come from the following link.
https://www.sciencedirect.com/topics/computer-science/stage-pipeline

The OoO Cortex-A57 with 4.1 DMIPS/MHz uses roughly 6 times as many transistors as the in-order Cortex-A53 and the difference is no doubt growing with newer ARM cores. The successor to the ARM Cortex-A57 is the ARM Cortex-A72 used in the RPi 4. The superscalar in-order SiFive U74 core claims to have reached 2.64 DMIPS/MHz which is significantly more than the Cortex-A53 claimed 2.3 DMIPS/MHz and even the successor Cortex-A55. The SiFive U74 core design looks like it was copied from the 68060 as it allows to execute more powerful CISC instructions even though RISC-V can't take advantage (RISC code has more instructions to execute and can only retire 2 instructions/cycle from two integer pipelines while CISC can retire the equivalent of 4 RISC instructions/cycle and often has fewer instructions to execute). The point of SiFive using this CISC/68060 like design is to avoid load-to-use stalls which is useful even for RISC code. Increases the performance of an in-order core is about avoiding stalls and increasing the number of instructions executed per cycle.

Avoiding stall cycles and increasing instructions executed per cycle
add caches, improve cache efficiency, lower cache/memory latency
predictive memory prefetching for instructions and data
improve branch prediction (including indirect branches)
hardware return/link stack
fold out/remove branch instruction and reduce instructions with folding/fusion
add more units with more capabilities or use symmetric mult-issue to execution pipelines
use a store buffer or larger store buffer
use register renaming and/or add visible registers
use instruction result forwarding/bypass

use early instruction completion with result forwarding/bypass
avoid load-to-use stalls by pipelining load/store instructions with integer instructions
use code with more powerful instructions (CISC encoding)
use code with fewer instructions (CISC encoding)

The last 4 in-order methods to increase performance are possible with the 68060 and SiFive U74 core designs but RISC-V code does not give the advantage of the last two like 68k code. The 68060 doesn't even have some of the advantages above like large caches, advanced prefetching, a hardware return/link stack, indirect branch prediction or instruction folding other than removing predicted branches. I believe a modern superscalar in-order 68060 or SiFive U74 like core could reach 3 DMIPS/MHz with 68k code. The advantage is much cheaper chips. Think six 3 DMIPS/MHz CPU cores for the same cost as one 4 DMIPS/MHz core with lower power and less heat. That's about the performance of the best PPC cores which is pretty usable.

OneTimer1 Quote:

I don't think they have a paying industrial user for their 68080 implementation, the 68080 FPU isn't IEEE compliant, it may not matter for most Amiga users but without proper FPU they can't compete on the open market.

I doubt IEEE compliance is a major factor for embedded adoption and the AC68080 could be IEEE compliant. Software is required even for the 68k FPU to meet compliance. Extended precision is not required. The ColdFire FPU removed extended precision support and switched the default precision to double precision. This has some advantages like consistent double precision results without needing to round extended precision to double precision. We need compatibility and there are advantages to extended precision like improved intermediate calculation precision, fewer instructions needed to calculate at least double precision, 64x64 and 64/64 can be shared for integer and FPU instructions (extended precision has 64 bits of fraction/mantissa while double has 52 bits) and full quad precision calculations may be possible with double-extended arithmetic (like double-double arithmetic but the extended precision exponent is the same as quad precision so no exponent range loss but a new rounding mode would be necessary or the FPU could calculate in hardware with 2 passes).

https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic

The 68k and x86 extended precision FPUs were sabotaged by having old ABIs that pass FPU function arguments on the stack in double precision when using extended precision arguments. The arguments should be defined as being passed in FPU registers where they would be retained at full extended precision. Clipping the extended precision usually doesn't cause a problem but can and it is unpredictable when compilers will do it (an inlined function may not clip the precision but a called function may). The ABI for x86-64 was updated and is a significant improvement while the 68k is still rocking the original Unix ABI from the 1970s (the Amiga function ABI defines passing args in registers at least but other args are passed on the stack by default). Even ColdFire continued to use the same old 68k ABI.

Last edited by matthey on 05-Feb-2024 at 08:02 AM.

@Deniil715

Quote:

Deniil715 wrote: Get a life dudes! DO something!

We are. This is part of our life. We're doing this.

There's more than one way to live.

_________________
All the way, with 68k

@matthey

Quote:

Larry Kaplan probably said the same thing to Jay Miner. Do it already. It's not a one man project and there are IP squatters and road blocks. After development, imagine an Amiga device without the Amiga name, AmigaOS or Workbench. Oh wait, that already happened with THEA500 Mini

THEA500 Mini is an officially licensed Amiga ROM from Cloanto Corporation.

Quote:

Most ARM CPU cores produced are in-order. Most customers buy the cheapest low power compromise processors including in Amiga Neverland with the ARM Cortex-A53 in THEA500 Mini and A600GS. The micro-oped OoO ARM cores beat any in-order core but they are likely 50 times the transistors/area, usually use a more expensive chip process and are significantly more expensive.

ARM Cortex-A53 and the current ARM's Amiberry emulator in THEA500 Mini is good enough for 50 Mhz ish 68030 to JIT'ed 173 MIPS CPU accelerated level Amiga AGA/RTG. THEA500 Mini and A600GS are not designed to compete against A1222 Plus/SAM460's Amiga NG performance.

Amiberry is based on WinUAE with ARM optimizations. Hosted on Linux and Amiberry overheads, it doesn't match bare-metal Emu68's performance.

Amiberry needs fatter ARM CPUs to close the gap with bare-metal Emu68's ARM Cortex-A53 performance.

You're mixing up the Amiga platform with Motorola/Freescale's 68K issues.

The Amiga software platform is not an embedded software market.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The OoO Cortex-A57 with 4.1 DMIPS/MHz uses roughly 6 times as many transistors as the in-order Cortex-A53 and the difference is no doubt growing with newer ARM cores. The successor to the ARM Cortex-A57 is the ARM Cortex-A72 used in the RPi 4. The superscalar in-order SiFive U74 core claims to have reached 2.64 DMIPS/MHz which is significantly more than the Cortex-A53 claimed 2.3 DMIPS/MHz and even the successor Cortex-A55. The SiFive U74 core design looks like it was copied from the 68060 as it allows to execute more powerful CISC instructions even though RISC-V can't take advantage (RISC code has more instructions to execute and can only retire 2 instructions/cycle from two integer pipelines while CISC can retire the equivalent of 4 RISC instructions/cycle and few instructions to execute). The point of SiFive using this CISC/68060 like design is to avoid load-to-use stalls which is useful even for RISC code. Increases the performance of an in-order core is about avoiding stalls and increasing the number of instructions executed per cycle.

SiFive Essential 7-Series are missing ARM Cortex A53's 128-bit SIMD standard.

1. https://starfivetech.com/uploads/u74mc_core_complex_manual_21G1.pdf
SiFive U74 is missing 128-bit SIMD.

Your CPU transistor count comparison is flawed.

ARM Cortex A520 replaced ARM's little core lines e.g. Cortex A53, A55, and A510.

ARM Cortex A510


From https://fuse.wikichip.org/news/5268/arm-unveils-next-gen-armv9-little-core-cortex-a510/

ARM Cortex A510 has three instruction issues per cycle and an in-order processing design.

---------------------

There are two 68080 implementations i.e. V2 and V4. 68080 V4 has FP64.

Last edited by Hammer on 05-Feb-2024 at 03:50 AM.
Last edited by Hammer on 05-Feb-2024 at 03:48 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The 68k Amiga doesn't get a deluxe ice cream maker. It's more like a cheap shaved ice machine with corn syrup sweetener but has more markup. That's what the ARM Cortex-A53 based THEA500 Mini and A600GS are like. A scalar 68k CPU could and should outperform the in-order superscalar Cortex-A53 at the same clock speed due to fewer instructions (CISC instruction=2xRISC instructions) and no load-to-use stalls.

The major reasons for RPi 3's Cortex A53 selection are to leverage RPi's economies of scale, good enough GPIO performance, good documentation, and wider 3rd party support.

Other Pi wannabe clones have performance issues with GPIO. This GPIO issue wouldn't be a problem for TheA500mini and A600GS-type products.

https://en.wikipedia.org/wiki/ARM_Cortex-A55
Usage
The Cortex-A55 is used as a little core in Intel Agilex D-series SoC FPGA devices.
Rockchip RK3566/RK3568, RK3588.
Amlogic S905X3, S905X4, A113D2, T962X2, T968X2, T962D2.
Unisoc SC9863A
Samsung Exynos 850
JLQ JR510
NXP i.MX93

ARM Cortex A510 has three issues per cycle, three ALUs, two loads, and one store unit.

ARM-based mobile phone SoCs are ahead of ARM-based embedded SoCs.

RPi selected Cortex A72 for 4B and CM4 following 3A+ and 3B models.

Exceeding the price of a full-priced PS5 game is not a low risk and it's entering AMD's AM4 price range.

Selecting a CPU core is part of the solution. CPU-less TF1260 costs more than PiStorm32 Lite.

Quote:

What percentage of embedded systems emulate another ISA? Even desktop emulation and virtual machines went the way of the dodo bird because they aren't efficient. The Amiga is going the way of the dodo bird too.

The Amiga platform is not an embedded software platform.

Last edited by Hammer on 05-Feb-2024 at 05:19 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ppcamiga1

Quote:

ppcamiga1 wrote: and of course. pi storm is worth nothing crap that change amiga into expensive mouse and keyboard interface for rpi.

Wrong. PiStorm-Emu68'ed wedge Amigas turns the legacy C= Amiga chipset into Southbridge functions.

With minor improvements, Agnus/Alice memory controllers are mostly frozen in 1985 specs.

A1200 has Gayle (Fat Gary role with PC ISA-based PCMCIA and internal PC ATA PIO controller) and Budgie (cutdown Buster and 32bit Fast RAM controller). Budgie's 32-bit Fast RAM controller is not in use when a fast 68K CPU accelerator (above 14 Mhz) is connected.

Amiga 3000/4000 has Super Buster (bus control and arbitration for Zorro III)/Ramsey (32-bit Fast RAM controller)/Super DMAC (DMA for SCSI chip)/Fat Gary (memory address decoder) for Northbridge functions and they are obsolete. Ramsey is designed for a 68030 bus and its 25 Mhz Fast RAM controller role shouldn't be used with faster 68K CPUs.

For A1200's expansion accelerator cards

Phase 5 Blizzard PPC has its 32-bit memory controller, 50 Mhz 68060 CPU, PowerPC 603e CPU (up to 240 Mhz CPU, 32-bit front side bus up to 66 Mhz), Fast SCSI2 controller (NCR 53C710), mini-PCI controller, and BlizzardVision RTG (PC's Premedia 2, 25 Mhz PCI, 8MB 64 bit SGRAM) mini-card.

Warp1260 has its 32-bit DDR3 memory controller, L2 cache, 16-bit Audio Codec, microSD card slot, FastIDE interface, 105 Mhz 68060 Rev 6 CPU, 400MHz ARM CPU, USB Host controller, WiFi, and CS-Lab RTG.

These two accelerator cards turn legacy C= Amiga chipset into Southbridge functions.

Quote:

it is dumb because amiga mouse and keyboard was copied 40 years ago from pc.

Wrong.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@matthey

Quote:

The 68040 FPU can execute more than one FPU instruction "concurrently".

Read Page 25 of 442 https://www.nxp.com/docs/en/reference-manual/MC68040UM.pdf

1. The context is "instructions in flight" from convert, execute, and write back stages and from an integer pipeline's single decoder.

68040 FPU obtains its instructions from the integer pipeline decoder.

Pentium FPU consists of eight stages which are used to speed up the execution of the floating point unit. FPU's floating point pipeline are prefetch, first decode, second decode, operand fetch, first execute, second execute, write float, and error reporting.

2. 68040 FPU has an inferior FPU when compared to Pentium FPU.


Quote:

Competitive Advantages: Intel Pentium: Dominates PC-DOS market o Weaknesses: Requires 64-bit bus. 68060: Superior integer performance with low-cost memory system

False.

1. PODP5V83 Pentium OverDrive has 33 Mhz on legacy 486DX2's 32-bit front-side bus.

PODP5V83 Pentium OverDrive is being overclocked.
https://www.vogons.org/viewtopic.php?p=214257#p214257

486DX-50 has 50 Mhz rated motherboards.

68060 targeted 50 Mhz 32-bit front side bus. There were no 100Mhz 68060s in 1995 and 1996.

Pentium targeted up to 66 Mhz 64-bit front side bus like PowerPC 60x. Pentium's Socket 7 evolved into a 100Mhz Super Socket 7 with AMD's K6-II and Cyrix M-II.

PC has so-called 586 clones for faster than 486 CPUs on 486's 32-bit sockets.

2. FP64 workloads are better with 64-bit front-side bus. Intel MMX 64-bit SIMD and AMD 3DNow 64-bit SIMD (pack FP math) match Pentium's 64-bit front-side bus.

The Amiga lost its Lightwave workstation rendering niche during the 68060 era.

Quote:

For integer instructions, the removal of the 64 bit result MULx and DIVx hurt by far the most. The others had negligible affect on performance or code density and were not so bad to trap. I have never seen a CHK2, CMP2 or CAS2 instruction used in Amiga code while CAS2 is documented as illegal on the Amiga. MOVEP was used by a few old Amiga games while the only issue was a lack of 680x0.library in kickstart at startup. For FPU instructions, the 68060 removed FScc, FDBcc and FTRAPcc which I never seen used on the Amiga and added back FINTRZ and FINT which are very common. Removing FINT(RZ) from the 68040 FPU was an epic mistake that never should have happened. The 68060 FPU was overall a nice improvement from the 68040 FPU as far as frequency of trapped instructions. Overall, the 68060 instruction removal was minor other than the 64 bit MULx and DIVx. The other instructions removed were rare. Many of the 6888x FPU instructions removed with the 68040 are more useful, although it is arguable whether the code should be part of the FPU or as regular 68k functions. Not counting trap overhead, most removed 6888x instructions are not much faster than similar functions. The legacy Pentium FPU instructions likely didn't give much of a performance advantage after trapped FPU instructions on the 68060 were replaced with function calls. The saved transistors likely could be used to increase performance more with increased caches.

Are you asserting 68060.library is not mandatory? Is 68EC060 usable on the Amiga?

Missing 64bit MUL makes some datatypes and some applications only work with 060 library.

https://www.ibrowse-dev.net/2.5/issues.php

> HTTPS slowness on 68k hardware [fixed in 2.5.2]
It is possible that many of the new security ciphers available in AmiSSL v4 may pose trouble for real 68k processors, even for a 68060. You will have experienced similar with IBrowse 2.4 and AmiSSL v3, had you ever enabled DH on IBrowse's cipher settings page (we disabled it by default, due to performance issues). We identified a fundamental flaw in AmiSSL v4 specific to 68060 processors, where 64-bit multiplication and division instructions were being used by AmiSSL v4 and the 68060 does not possess these in hardware (68020/030/040 do). This will have caused thousands of software emulation exceptions which greatly slow things down (and make the mouse pointer move erratically), allowing the missing instructions to be emulated by software in 68060.library. This has been addressed for AmiSSL 4.4 / IBrowse 2.5.2, with separately optimised versions - one for 68020/030/040 and another for 68060. You may still find that disabling various options in IBrowse's cipher settings may yield an improvement as certain algorithms perform better than others.

Last edited by Hammer on 05-Feb-2024 at 07:18 AM.
Last edited by Hammer on 05-Feb-2024 at 07:05 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Discussion around the viability of a new ASIC 68K is probably even more moronic than trying to make the case for new PPC hardware.

The PiStorm is already the most optimum solution. It exists, compatible, bug-fixable, performant, includes RTG and other useful enhancements. It's also afforable - by far one of the most important metrics for attracting users. The fact it pisses off ppcamiga1 is just a bonus.

How it performs compared to native ARM or non-existent 3GHz ASIC 68060 hallucinations is an irrelevant strawman attack since it's main purpose is to run 68K software and as such should only be compared to other existing solutions that are 68K compatible. Using that as a realistic means of comparison, a CM4 is already a monster that crushes all extant physical 68K including Vampire. It's so performant the only remotely comprehensible argument from the PPC/NG crowd (discarding the violent throwing of fecal matter around whatever cage ppcamiga1 is held captive in) has been "but who needs such an overpowered 68K anyway?". Note that none of them ever said this when wondering if JIT emulation on PPC was a good idea.

Comparing it to UAE is another strawman, since the aim of the PiStorm as it stands is to run said 68K software in an actual Amiga, not as a complete emulation solution. Besides which, there's AmiBerry for that.

Last edited by Karlos on 05-Feb-2024 at 01:30 PM.
Last edited by Karlos on 05-Feb-2024 at 11:40 AM.
Last edited by Karlos on 05-Feb-2024 at 11:38 AM.
Last edited by Karlos on 05-Feb-2024 at 11:37 AM.
Last edited by Karlos on 05-Feb-2024 at 11:36 AM.

_________________
Doing stupid things for fun...

@Hammer

Quote:

I used a Yamaha OPL3 ISA sound card into the 1996 Pentium150 era. The joystick port has a cable adapter for external MIDI.

I recall those connectors. Funny arrangement. A wide joystick port with MIDI included.

Quote:

The current PiStorm for Mac is based on a 68000 socket for Macintosh Classic and it's monochrome. It's using the slower Linux-hosted 68K emulator i.e. it's no Emu68.

Seems a bit underdeveloped. Does the Mac lack a CPU slot? Might as well plug a Vampire into that.

Quote:

My Dell flat panel for A1200 supports 15 kHz VGA.

So a friend gave me a Dell with Amiga compatible VGA. After plugging in VGA to RGB port and RTG to HDMI port I think it best to forget about RTG for a while. Just too exhausting pressing buttons to switch.
DblPAL would be fine. FullHD RTG is nice. But I'll wait for the auto switcher. Too used to the luxury of my A4000 where switching between native and RTG is transparent.

Quote:

Karlos wrote: The PiStorm is already the most optimum solution. It exists, compatible, bug-fixable, performant, includes RTG and other useful enhancements. It's also afforable - by far one of the most important metrics for attracting users.

Biggest issue:
You still need an Amiga to use it.

@OneTimer1

The PiStorm, yes as that's the whole point of it. Emu68 not really. It has a standalone mode if you prefer.

_________________
Doing stupid things for fun...

@Hypex

Quote:

I recall those connectors. Funny arrangement. A wide joystick port with MIDI included.

My Pentium 166 is powerful enough for a Yamaha S-YXG50 software MIDI synthesizer.

I later purchased a Yamaha YMf724 PCI sound card, but no 64-bit drivers doom'ed this sound card. I use a Yamaha S-YXG50 VSTi plugin with 64-bit WIndows.

I have set up GMPlay and Timidity installs for my A1200/TF1260 before switching to PiStorm-Emu68.

Quote:

Seems a bit underdeveloped. Does the Mac lack a CPU slot? Might as well plug a Vampire into that.

It depends on the Mac models. 68000 socket is accessible. PiStorm-ST project is a better fit for 68K Mac.

Quote:

So a friend gave me a Dell with Amiga compatible VGA. After plugging in VGA to RGB port and RTG to HDMI port I think it best to forget about RTG for a while. Just too exhausting pressing buttons to switch. DblPAL would be fine. FullHD RTG is nice. But I'll wait for the auto switcher. Too used to the luxury of my A4000 where switching between native and RTG is transparent.

I have a KVM switcher and hence switching between the two modes is relatively quick.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

Hammer Quote:

You're mixing up the Amiga platform with Motorola/Freescale's 68K issues. The Amiga software platform is not an embedded software market.

That's the problem. The 68k Amiga should be an embedded platform again but there is a lack of competitive affordable hardware. It is attractive for hobby and retro markets also where affordable hardware is nearly as important. Where the Amiga platform is nowhere near competitive is the desktop market even with the best hardware on Earth.

Amiga NG hardware markets: hobby, desktop (lacks competitive features)
68k Amiga potential markets: retro (especially gaming), hobby, embedded, educational
RPi hardware markets: embedded, hobby, educational, retro (lacks gaming)

Amiga NG hardware sales: hundreds of units/year
68k Amiga hardware sales: tens of thousands of units/year
RPi hardware sales: millions of units/year

Even if Amiga NG was mass produced, there is no market. Mass produced 68k Amiga hardware that is more competitive with RPi hardware has potential for the hot retro gaming market while embedded features reduce risk. The RPi Foundation and ARM are what they are today by leveraging embedded market economies of scale.

Hammer Quote:

SiFive Essential 7-Series are missing ARM Cortex A53's 128-bit SIMD standard. 1. https://starfivetech.com/uploads/u74mc_core_complex_manual_21G1.pdf SiFive U74 is missing 128-bit SIMD.

The SiFive U74 core is less mature than newer ARM in-order cores which is what makes the performance more impressive. The older in-order ARM cores like the Cortex-A53 and Cortex-A55 are outselling the newer ones because they are smaller and cheaper, especially for embedded use. Also, the RISC-V philosophy and market is about simpler and cheaper hardware. The U74 core has impressive performance for a small in-order core but the RISC-V market is not built up yet.

Hammer Quote:

Your CPU transistor count comparison is flawed. ARM Cortex A520 replaced ARM's little core lines e.g. Cortex A53, A55, and A510.

These newer cores are larger to increase performance. In order to save space, ARM initially tried to remove 32 bit support from the Cortex-A510 and backtracked but did remove it from the Cortex-A520. Also to save space, the Cortex-A510+ is the new AMD Bulldozer that shares resources between pairs of cores. At least it makes more sense for non-performance cores. One of the resources designed for sharing is the SIMD/FPU unit.

FPU instruction latency/throughput of at least double precision instructions
CPU | FADD | FMUL | FDIV | FPU Pipelining
68060 3/3 3/3 37/37 no
Pentium 3/1 3/1-2 39/39 yes
SiFive-U74 7/1 7/1 9-58/8-58 yes
Cortex-A510 4/2 4/2 22/19 partial (pipelined for single precision)

The scalar FPU is used much more often than a SIMD unit and it is easier for a compiler to use. There are compromises everywhere. Integer performance is usually more of a focus for in-order cores than FPU or SIMD performance. Electricity has a tiny fraction of the distance to travel for the Cortex-A510 at 7-5nm compared to 68060/Pentium at ~500nm and the latter is using extended precision instead of double precision.

Hammer Quote:

ARM Cortex A510 From https://fuse.wikichip.org/news/5268/arm-unveils-next-gen-armv9-little-core-cortex-a510/ ARM Cortex A510 has three instruction issues per cycle and an in-order processing design.

A Cortex-A510 core is approaching the complexity of an OoO core. It decodes instructions to uops (adding 2 pipeline stages of decode and using more power like x86-64 cores are often criticized for), has many execution units (3xALU, 2xload/store, 1xMAC/DIV/complex, 1xbranch) and stores a lot of execution state data to continue speculative execution during load misses and branches (speculatively executed up to 12 total instructions, 6 FP instructions, 3 branches, 5 loads). I don't know how large these cores are but they are not your small and simple in-order cores anymore. Despite all the execution units which should make instruction scheduling easier, whether instructions can multiple issue is complex. The 2xload, 1xstore per cycle using likely dual ported data cache is very helpful for scheduling and performance of a RISC core. A 2nd integer execution unit (ALU) is likewise a major improvement for scheduling and performance but a 3rd ALU is likely to see limited use. ALUs are cheap as far as resources though.

I suggested a 3rd integer execution pipe to Gunnar for the AC68080 core. I think it makes more sense for an in-order 68k CISC core for a couple of reasons. The first I discovered when doing 68k code analysis with a special version of the ADis disassembler. The 68k instructions are tiny on average which is what 68060 developers discovered too.

https://www.academia.edu/64300961/The_superscalar_architecture_of_the_MC68060 Quote:

The chips instruction-set architecture contains 16-bit and larger instructions, with a measured average instruction length of less than 3 bytes.

Instruction fetch uses a high percentage of the CPU core power for small cores.

https://diginole.lib.fsu.edu/islandora/object/fsu%3A182239/datastream/PDF/view Quote:

Instruction fetch is a critical pipeline stage in modern embedded processors that can consume approximately one-third of the total processor energy on a StrongARM SA- 110. ... For these applications, instruction fetch energy comprises 30% to 45% of the total power requirements.

The solution is code compression although most RISC compressed ISAs increases the number of instructions partially offsetting the gains from smaller instructions. This is not true for the 68k which has both small instructions and often less instructions to execute. The ARM Cortex-A510 doubled the Cortex-A55 fetch to 16 bytes/cycle to supply the 3 instruction decode and issue (each instruction is 4 bytes so 12 bytes of fetch are needed for 3 instructions). The 68060 only has an instruction fetch of 4 bytes/cycle feeding 2 integer execution pipes and a branch unit. A larger fetch would sometimes improve performance with large instructions while an 8 byte/cycle fetch more easily feeds 3 integer execution pipelines than the 68060 4 byte/cycle fetch feeds 2 integer execution pipelines. With the 68060 design, a 3rd ALU could be added cheaply that is register only (weak execution pipe). This could be used for decrement or compare in MOVE mem,mem loops decreasing loop overhead so loops don't need to be unrolled as much. Even better would be able to rotate the execution pipes as needed to the position needed which even the Cortex-A53 does. The AC68080 core design lacks the fetch pipeline and execution pipeline decoupling and uses a large fetch (at least 16 bytes/cycle) but it is targeted at performance instead of power and lower frequencies use less power anyway. The affordable FPGA is cramped so even a weak pipeline 3rd ALU may not be worthwhile.

Hammer Quote:

There are two 68080 implementations i.e. V2 and V4. 68080 V4 has FP64.

The AC68k V2 FPGA is packed like a sardine. It doesn't even have room for full 68020 integer support let alone a FPU. Without at least FPU registers, it is not worth trapping FPU instructions as can be expected on the A1222+. Recompiling with software fp is higher performance.

Hammer Quote:

Are you asserting 68060.library is not mandatory?

No. I was stating that the 680x0.library should be in kickstart so games work without first accessing a boot partition on a hard drive or similar.

Hammer Quote:

Missing 64bit MUL makes some datatypes and some applications only work with 060 library. https://www.ibrowse-dev.net/2.5/issues.php > HTTPS slowness on 68k hardware [fixed in 2.5.2] It is possible that many of the new security ciphers available in AmiSSL v4 may pose trouble for real 68k processors, even for a 68060. You will have experienced similar with IBrowse 2.4 and AmiSSL v3, had you ever enabled DH on IBrowse's cipher settings page (we disabled it by default, due to performance issues). We identified a fundamental flaw in AmiSSL v4 specific to 68060 processors, where 64-bit multiplication and division instructions were being used by AmiSSL v4 and the 68060 does not possess these in hardware (68020/030/040 do). This will have caused thousands of software emulation exceptions which greatly slow things down (and make the mouse pointer move erratically), allowing the missing instructions to be emulated by software in 68060.library. This has been addressed for AmiSSL 4.4 / IBrowse 2.5.2, with separately optimised versions - one for 68020/030/040 and another for 68060. You may still find that disabling various options in IBrowse's cipher settings may yield an improvement as certain algorithms perform better than others.

They obviously didn't compile with vbcc for the 68060. I optimized the 68060 integer 64 bit code for vbcc. The 64 bit integer division code could be a few cycles faster but it isn't used as much so I didn't bother (it's not bad). They were probably using GCC and targeting 68020-68060 expecting there to be no trapped instructions used for 68020-68060. If they targeted only the 68060, GCC shouldn't generate any trapped instructions but I wouldn't guarantee it.

Removing the 64 bit MUL instruction was one of the biggest mistakes of the 68060. Motorola should have considered making all 68060s with MMU and FPU so the integer and FPU DIV unit could be shared. They loved to give a discount for handicapped embedded CPUs though. It didn't cost that much to give everyone full CPUs by the time of the 68060 and practically all the 68060 customers were embedded by that time. Many of the early EC/LC 68060s were full 68060s. The only 68060 "improvement" priority Motorola had was to make new EC/LC dies with deleted units though. Sad.

Last edited by matthey on 06-Feb-2024 at 07:06 AM.
Last edited by matthey on 06-Feb-2024 at 06:20 AM.
Last edited by matthey on 06-Feb-2024 at 06:16 AM.

@matthey

Quote:

The AC68k V2 FPGA is packed like a sardine. It doesn't even have room for full 68020 integer support let alone a FPU. Without at least FPU registers,

Matthey for the record.

1) You are claiming the 68080 V2 would have no full 68020 integer instructions support?
Your post is absolutely wrong.

The 68080 CPU in V2 and V4 is complete covering all 68K integer instructions.
You can nicely run with it Amiga OS 1/2/3/../3.2 .. ApolloOS, MAC-OS and even Emutos / AtariOS.
You can enjoy Amiga 060 demos using FPU and also play 3D games like Quake.

There is nothing missing in the Apollo 68080 CPU.
And claiming it would miss 020 EA modes is not the trust but a lie.

The Apollo 68080 CPU has 100% all integer instructions including all instructions of 68000/68010/68030/68040/68060 and so on.
You can read this here yourself:
http://www.apollo-core.com/documentation/AC68080PRM.pdf


2) You are claiming the 68080 V2 would have no hardware FPU registers and no hardware FPU?
Your post is again absolutely wrong.
The 68080 in the V2 has not only all register it also has a very potent hardware FPU.
The V2 happily scores 74 MFlops in Sysinfo test - which is a lot higher than 68040 and 68060 score.

http://www.apollo-core.com/gfx/vampire_sysinfo.gif


Matthey, your posts are all wrong!

Do you purposely post false claims and total nonsense?
or do just have absolutely no clue both about the topic and about the 68080 CPU?


Could it be that you are mixing up Vampire 2/4 and 1?

The Vampire 1 card if which only about 200 were produced has no FPU.

But the V2 and V4 of which there are over ten thousand (10,000) Vampire 2 and Vampire 4 owners - all have a full CPU and FPU!
And the FPU is also including FINTRZ which the 68040 misses ;)
The V2 and V4 FPU are pretty potent for running 060 FPU games and demos with over 70 MFlops of the V2 and for V4 over 80 MFlops.

Last edited by Gunnar on 06-Feb-2024 at 07:21 AM.
Last edited by Gunnar on 06-Feb-2024 at 07:17 AM.