@matthey

Quote:

With small breadbox/wedge/AIO computers and Leo Nigro being brought up in this thread, I noticed on lemon64.com in a discussion about the new Commodore, a pic of the Vic Slim with Commodore branding and C= keys that I had never seen before.

I have one of those. I wonder how many made it out the door?

@Kremlar

Quote:

Kremlar wrote: @matthey Quote: ... the new Commodore, a pic of the Vic Slim with Commodore branding and C= keys that I had never seen before. I have one of those. I wonder how many made it out the door?

Not bad, but if you want to reduce space on your desk, you can mount a small computer behind your monitor.

I'm pretty sure you can sell some of these.
Remembrance: https://www.commodoreos.net/CUSA_VICSlim.aspx

Last edited by OneTimer1 on 24-Jul-2025 at 01:30 PM.

@thread

The latest from Commodore International Corporation via Sean Donohue:

Source

Imbedded link within goes to new facebook page for Commodore

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@OneTimer1

Mainstream laptops serve as modern wedge microcomputers, but with operational mobility.

_________________

@matthey

Quote:

Extending 32-bit lines to 64-bit lines does not change the basic core design.

Bonnell has two 64-bit ALUs while Pentium has 32-bit ALUs.


Quote:

FADD 3 cycles for P5 Pentium FMUL 5 cycles for P5 Pentium FADD 5 cycles for Bonnell FMUL 5 cycles for Bonnell FADD 3 cycles for 68060 FMUL 3 cycles for 68060

https://cdn.preterhuman.net/texts/underground/phreak/68060Info.txt
Table 1 shows execution times for the 68060 FPU.
Instruction CPU Clocks
FMOVE 1
FADD 3
FMUL 4
FDIV 24
FSQRT 66

68060's design does not support concurrent floating point execution; only one of these functional units is active at a time.

68060 FPU is not pipelined.

Bonnell FPU cluster is superscalar pipelined i.e. dual FPU pipelines.
Port 0: Vec ALU, Vec Shuffle, Vec Mul, FP Mul, FP Mov, FP ROM, FP DIV, FP Store
Port 1: Vec ALU, FP Add,

Floating point XMM instructions
MULSS (FP32) latency is 4, Due to SIMD4 with FP32, it's effectively scalar operation has 1 latency.
MULSD (FP64) latency is 5. Due to SIMD2 with FP64, it's effectively scalar operation has 2.5 latency.
FMUL is just a scalar usage for SIMD FP. FADD is on another FPU pipeline.

A proper pipelined FPU has concurrent instructions-in-flight. A superscalar pipelined FPU has two or more pipelines operational.

Bonnell integer pipelines are 16 stages deep.
P5 Pentium integer pipelines are 5-stage deep.

Bonnell FPU pipelines are 19 stages deep.
P5 Pentium FPU pipeline is 8 stages deep.

Regardless of instruction latency, Bonnell is designed for high clock speeds. High clock speed is a design feature.


Quote:

Adding new features does not change the basic core design. Both Pentium P5 and Bonnell FPU instructions pass through the first integer execution pipeline (P5 Pentium u pipe and Bonnell ALU0/port0 pipe).

Bonnell has four ports that are grouped into integer and SIMD/FP cluster.


This Bonnell diagram splits into three group clusters i.e.
memory execution cluster,
integer execution cluster,
FP/SIMD execution cluster.

Bonnell FP Register File has two ports feeding into two FPU pipelines, which bypass the memory execution cluster's AGU stage. SSE can do RISC-style explicit data loads from memory, hence trading fused memory operands with math operations complexity for multiple math operations per instruction, as in the case for SIMD operations. SSE SIMD can also perform CISC fused memory operands with multiple math operations per instruction, which borrows from AGUs from the memory execution cluster.

P5 Pentium is not SSE SIMD capable.

Bonnell FP cluster only recycles AGU stage from the integer group. AGUs are needed for the implied memory data loads.

P5 Pentium's Control Unit has three ports.
Bonnell's Instruction Queue has four ports.

Bonnell pipelines are aware of SMT (Hyperthreading), while it's not the case for P5 Pentium. In a true multitasking SMP capable OS, Bonnell's dual hardware threads lower the context switch overheads when compared to P5 Pentium. Bonnell's instructions in flight have a thread assignment, which is not the case for P5 Pentium.

AmigaOS is not SMP capable, hence its multitasking is a time-slice method.

Like AMD's OOOE (out-of-order-execution) capable Jaguar, Bonnell (released in 2008) was replaced by OOOE-capable Silvermont in 2013. AMD's Jaguar has its origins in the earlier OOOE-capable BobCat (released in early 2011).

Intel Bonnell and Silvermont didn't win the embedded game console contracts such as the MS Xbox One and Sony's PS4 generation. Unlike Intel Silvermont, AMD Jaguar offers 256-bit AVX SIMD (via double-pump 128-bit SIMD hardware).

For Amiga's target audience majority (i.e. A500/A1200/CD32/CD3D price range and use case) and for AMD Jaguar's embedded game consoles design wins,
https://nathanlamont91.wordpress.com/2015/03/22/my-report-on-the-amd-jaguar-quad-core-cpu/



AMD Jaguar from scheduler stage
Pipeline 0: ALU,
Pipeline 1: ALU, MUL, DIV,
Pipeline 2: LAGU,
Pipeline 3: SAGU,
Pipeline 4: Vec ALU, Vec MUL, FPAdd,
Pipeline 5: Vec ALU, St Conv, FPMul,


https://en.wikichip.org/wiki/File:zen_block_diagram.svg
For data loads, Zen 1's LDCVT to feed SIMD/FP cluster. Zen 1 doubles nearly everything from Jaguar. Both Zen 1 and Jaguar have at least 14-stage pipelines.

The design win negotiations and development for the PS4's AMD components would have taken place during the latter part of the PS3's lifecycle and leading up to the PS4's announcement and launch.

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

https://www.tomshardware.com/pc-components/cpus/sony-playstation-4-chip-helped-amd-avoid-bankruptcy-exec-recounts-how-jaguar-chips-fueled-companys-historic-turnaround
Unlike Commodore's efforts, AMD's game console Jaguar APUs helped AMD avoid bankruptcy, which helped fund Ryzen R&D.

AMD's ATI Radeon business is the major factor for game console design wins and keeping AMD afloat. A mismanaged x86 CPU R&D almost sent AMD into bankruptcy.

In November 2009, Intel paid AMD $1.25 billion in cash to settle a series of antitrust and patent disputes. Intel's cash payment effectively helped bail out AMD. This is similar to Microsoft (Bill Gates)'s investment and maintain MS Office for Steve Jobs' Apple.

The Intel and AMD patent agreement is a poison pill that protects each other from a hostile takeover.

AMD's executive Frank Azor blames recent shortages of Ryzen 7 9800X3D processor partly due to the underwhelming performance of Intel's Arrow Lake desktop CPUs. Intel's mismanagement is not healthy for the X86 platform. AMD prefers the status quo with Intel properly competing.

Being x86 CISC CPU vendor doesn't guarantee financial health when mismanagement can cause major problems.

Despite moving to IBM's PPC, Motorola's control over 68K is tighter than Intel's x86.

For mainstream X86-64-based game consoles, picking on Bonnel is not real in the real world when mainstream game consoles are not provided by Intel i.e. they are not powered by Bonnel uarch.

AMD's game console hardware is in the real world, and they target the A500/A1200/CD32/CD3D's price range with a mostly gaming audience.

PS; the ex-C65's engineer (Victor Andrade from CSG LSI group) working in AMD has contributed to AMD's 28 nm APUs. The same person who was overburdened with ECS Agnus B, AAA Andrea, and C65 4510 work. https://www.linkedin.com/in/victor-f-andrade-814822b/


From Commodore - The Final Years book,

Pandora
By late 1989, the 32-bit AAA project was getting bogged down.
According to Dave Haynie, several factors allowed the project to slip.
“The first reason was that the chip group didn’t get enough
resources so they couldn’t advance the chip technology fast
enough,� he says. “It really was a matter of not reinvesting enough
money in the technology. We had plenty of hard work, which is why
we kept up as well as we did.�

The second reason was that Commodore was taking on too many
projects. James Redfield complained that his staff, especially Victor
Andrade, was spending too much time cleaning up problems in the
4510 and ECS Agnus chips. Andrea development was essentially
suspended until those other two chipsets were in production.


Commodore didn't have enough "Victor Andrade" to speed up A3000's Agnus B ECS's, C65 4510's and AAA Andrea's R&D.

Last edited by Hammer on 25-Jul-2025 at 05:05 AM.
Last edited by Hammer on 25-Jul-2025 at 04:58 AM.
Last edited by Hammer on 25-Jul-2025 at 04:40 AM.
Last edited by Hammer on 25-Jul-2025 at 04:37 AM.
Last edited by Hammer on 25-Jul-2025 at 04:25 AM.
Last edited by Hammer on 25-Jul-2025 at 04:22 AM.
Last edited by Hammer on 25-Jul-2025 at 03:57 AM.

_________________

Quote:

Hammer wrote: Mainstream laptops serve as modern wedge microcomputers, but with operational mobility.

That's why some are mocking keyboard computers as "No Screen Laptop"

When people are using a laptop at home or in the office they are often adding external keyboard, mouse monitor(s) and sometimes even an USB docking station.

On the other hand you can get a PC in a 'Thin Client' case with the same size like a big USB-docking station.

I'm glad people went away from those loud full size tower cases.

Hammer Quote:

https://cdn.preterhuman.net/texts/underground/phreak/68060Info.txt Table 1 shows execution times for the 68060 FPU. Instruction CPU Clocks FMOVE 1 FADD 3 FMUL 4 FDIV 24 FSQRT 66

That looks like preliminary info on the 68060 which changed. The MC68060 User's Manual Section 10 on "Instruction Execution Timing" is a more reliable source of info and it gives the following FPU instruction execution times in cycles.

FMOVE 1
FADD 3
FMUL 3
FDIV 37
FSQRT 68

It makes sense that the FMUL instruction would get optimized since it is so important to fp performance. FDIV may have had its area/transistor budget reduced or perhaps the MC88110 FDIV implementation with a 26 cycle latency for extended precision fp was planned to be copied to the 68060 but didn't make it in time.

Hammer Quote:

68060's design does not support concurrent floating point execution; only one of these functional units is active at a time. 68060 FPU is not pipelined.

The 68060 has 3 FPU units, which sounds correct, so 3 FPU instructions could be using each of the units in parallel. There is a good chance that these 3 units have pipelines where a new FPU instruction could start executing each cycle. It is the OoO like resource tracking which would require at least a scoreboard and additional tracking info like the FPIAR for each instruction. Keeping the instruction execution latencies of the most common FPU instructions to a minimum was a reasonable compromise that reduces area and power. A FPU instruction queue like the Cyrix 6x86 would have made instruction scheduling easier but the 68060 generally had shorter FPU latencies and a much better FPU ISA than the 6x86.

Hammer Quote:

Bonnell FPU cluster is superscalar pipelined i.e. dual FPU pipelines. Port 0: Vec ALU, Vec Shuffle, Vec Mul, FP Mul, FP Mov, FP ROM, FP DIV, FP Store Port 1: Vec ALU, FP Add,

The advantage of pipelining short latency FPU instructions is decreased, especially when only a single FPU instruction is issued each cycle.

https://en.wikichip.org/wiki/intel/microarchitectures/bonnell#Front_End Quote:

In addition, only one x87 instruction can be decoded per cycle.

According to Agner Fog's x86 instruction tables, Bonnell's FMUL is not fully pipelined like the P5 Pentium FMUL and has a reciprocal throughput of 2 instead of 1. That is, a new FMUL instruction can not always begin execution every cycle. I would rather have the 68060 non-pipelined FMUL with 3 cycle latency than a semi-pipelined FMUL with 5 cycle latency that can only execute a new FMUL every other cycle. The P5 Pentium has a similar semi-pipelined FMUL but both FMUL and FADD only have a 3 cycle latency. The much deeper Bonnell pipeline increased some FPU latencies. It would be interesting to see the original Quake on a P5 CPU vs Bonnell CPU core at the same clock speed. The original P5 Pentium used 3.1 million transistors vs a single core Bonnell CPU using 47.2 million transistors but most of that is for caches and SIMD support including register files which account for 50% of the die area.

https://en.wikichip.org/wiki/intel/microarchitectures/bonnell#Back_End Quote:

Nonetheless the total register file area accounts for 50% of the entire core's die area which was single-handedly an important contributor to the overall chip power consumption.

That is with old SSE register files where AVX512 register files are 8 times larger. This is why small embedded cores were more likely to use MAC units rather than SIMD units and CPUs like the A1222 CPU cut the standard PPC FPU register file to make room for a shared SIMD/FPU unit register file. Then AArch64 came along and made 32 x 64-bit integer files and 32 x 128-bit SIMD register files standard for embedded which is more like the register file area Bonnell used. Transistors are cheap enough for tens of millions of transistor embedded CPUs just not cheap enough for a 2.5 million transistor 68060.

Hammer Quote:

Regardless of instruction latency, Bonnell is designed for high clock speeds. High clock speed is a design feature.

A 7-14 stage pipeline is the most practical and is easier to program than very deep pipelines with longer stalls and longer latency instructions. The 16 to 19 stages of Bonnell are too deep for a low power in-order integer pipeline in my opinion. The ARM Cortex-A8, Cortex-A35, Cortex-A53, Cortex-A55 and SiFive 7-series in-order cores all have 8-stage pipelines. The 68060 8-stage pipeline is a good depth while the 9-stage ColdFire v5 pipeline is an example of minor changes to the pipeline design to clock a little higher if desired.

Hammer Quote:

AmigaOS is not SMP capable, hence its multitasking is a time-slice method.

Windows and Linux were not SMP capable until the support was added. The AmigaOS can be changed to add SMP. The only question is how many changes to the AmigaOS and existing software would be necessary. NG OSs based on the AmigaOS should have made the necessary changes to support SMP but they did not so they would also suffer from a loss of software compatibility to support SMP. The lack of SMP makes the AmigaOS look bad and why the first instinct of the new Commodore is to replace the AmigaOS with Linux Commodore OS Vision. Replacing is easier than developing but not as popular.

Last edited by matthey on 26-Jul-2025 at 02:36 PM.
Last edited by matthey on 25-Jul-2025 at 10:06 PM.

@matthey

Quote:

Windows and Linux were not SMP capable until the support was added. The AmigaOS can be changed to add SMP

How? Windows and Linux were multiprocess operating systems with schedulers that could assign processes (and virtual memory address space) to CPUs/cores depending on various criteria. AmigaOS is a single-process operating system, there is just _one_ process (exec) and its address-space is that of the hardware - this one process can only run on one processor.

Last edited by kolla on 26-Jul-2025 at 03:35 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Well Windows did for sure start without SMP support Windows NT changed that soon enough.

Linux started on 386 and while it may have been designed with SMP in mind it probably didn’t get tested till PentiumPro.

As for Amiga getting, think MacOS. Nothing prior to OSX had it and it’s debatable wether OSX really is macOS or just a new OS made to look a like.

Last edited by Kronos on 26-Jul-2025 at 08:43 PM.

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

kolla Quote:

How? Windows and Linux were multiprocess operating systems with schedulers that could assign processes (and virtual memory address space) to CPUs/cores depending on various criteria. AmigaOS is a single-process operating system, there is just _one_ process (exec) and its address-space is that of the hardware - this one process can only run on one processor.

Linux started as a multiprocess OS with a single scheduler. Linux is based on Unix which did not even support multitasking at first.

https://en.wikipedia.org/wiki/Unix#Overview Quote:

At first, Unix was not designed to support multi-tasking or to be portable. Later, Unix gradually gained multi-tasking and multi-user capabilities in a time-sharing configuration, as well as portability. Unix systems are characterized by various concepts: the use of plain text for storing data; a hierarchical file system; treating devices and certain types of inter-process communication (IPC) as files; and the use of a large number of software tools, small programs that can be strung together through a command-line interpreter using pipes, as opposed to using a single monolithic program that includes all of the same functionality. These concepts are collectively known as the "Unix philosophy". Brian Kernighan and Rob Pike summarize this in The Unix Programming Environment as "the idea that the power of a system comes more from the relationships among programs than from the programs themselves".

Linux was released in 1991 but did not support SMP until version 2.0 in 1996. SMP support was initially poor and improved gradually mostly from about 2000-2010,

The AmigaOS use of preemptive multitasking and a micro kernel from release in 1985 should make supporting SMP easier. AROS was first released in 1995 before multi-core CPUs and SMP support were common yet x86-64 AROS comes the closest to SMP support. MorphOS was released in 2000 yet failed to add SMP support. AmigaOS 4 was released in 2004 but failed to add SMP support. PPC's weak memory consistency model makes SMP support more difficult and requires more changes to the AmigaOS while a more sequential consistency model like CISC hardware more commonly uses should make it easier. Hardware changes to support SMP could also likely reduce the changes needed for the AmigaOS and existing software. With Linux, breaking compatibility while requiring a recompile is not a problem. The 68k Amiga "standard" including executables is one of the most valuable assets the Amiga has remaining including for so called NG AmigaOS flavors. SMP can certainly be added to the AmigaOS while breaking compatibility but can NG AmigaOS flavors afford to lose both NG AmigaOS compatibility and 68k AmigaOS compatibility?

@Kronos

Quote:

Kronos wrote: ... it’s debatable wether OSX really is macOS or just a new OS made to look a like.

I think OSX is a new OS with a GUI and most of the APIs being MacOS9 compatible.

What would have been needed for AmigaOS to go that way?

1. Make a new OS with an additional API that works without shared memory.
Let's call it AOS4

2. Make a new OS with a new kernel that only uses the new API and shove all old software into a sandbox.
Let's call it AOS5

If that new AOS5 is based on Unix/Linux/BSD it might support SMP out of the box.

@Thread

Nothing of this happened, you can try to implement some SMP/AMP features but you will increase instabilities. Just imagine what it means if an internet application is crashing on a system with shared memory, it means a virus can take it over via the internet.

AOS has no memory protection, no separation between user and system space, we are only save from viruses, because we are insignificant.

This transformation from old AOS3 to a modern AOS5 didn't happen, Hyperion, the MOS- or AROS-Team doesn't have the money to pay for it, we don't have enough users to buy it and we don't have the 3rd, party companies who will constantly work to make their application run under an OS with new API or CPU.

What can someone do now?

Support OS versions that are working on a transition, support people working on ports of GFX libraries, or support people who are working on UAE ... that's all.

Last edited by OneTimer1 on 26-Jul-2025 at 10:10 PM.
Last edited by OneTimer1 on 26-Jul-2025 at 09:47 PM.

@matthey

https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf

68060's FADD range from 3 to 5 cycles. No difference between FDADD (double precision rounding) and FSADD (single precision rounding).
FMUL range from 3 to 5 cycles. No difference for FDMUL(double precision).
FDIV takes 37 to 39 cycles (single precision).
FDDIV takes 37 to 39 cycles.

Only one of the FPU functional units is active since the 68060 FPU is not properly pipelined.
SpecFP score is not pretty for 68060!

---------------
https://www.agner.org/optimize/instruction_tables.pdf

Pentium P5's
FADD has 3 cycles
FMUL(P) has 3 cycles
FDIV(R)(P) takes 19, 33, or 39 clock cycles for 24, 53, and 64 bit precision respectively.

Pentium P5 wins for Quake and its clones.

Intel Atom (2008)
X87
FADD(P) has 5 cycles
FMUL(P) has 5 cycles
FDIV(R)(P) has 71 cycles

Floating point XMM instructions
ADDSS has 5 cycles
MULSS has 4 cycles (for FP32 data, effectively 1 cycle for each data element from SIMD4)
MULSD has 5 cycles
DIVSS has 31 cycles
DIVSS has 60 cycles
DIVPD has 122 cycles

They are not the same!

Intel Silvermont (Atom, 2013)
X87
FADD(P) has 3 cycles
FMUL(P) has 5 cycles
FDIV(R)(P) has 39 cycles


Floating point XMM
ADDSS has 3 cycles
ADDSD has 3 cycles
MULSS has 4 cycles
MULSD has 5 cycles
DIVSS has 19 cycles
DIVSD has 34 cycles

In terms of clock cycle latencies, Silvermont is closer to the Pentium P5, but with SIMD support.


AMD Jaguar, the embedded game console x86-64 CPU e.g. Xbox One and PS4
X87
FADD(P) has 3 cycles
FMUL(P) has 5 cycles
FDIV(R)(P) has 22 cycles

Floating point XMM instructions
ADDSS/D has 3 cycles
ADDPS/D has 3 cycles
MULSS/PS has 2 cycles (FP32 scalar)
VMULPS has 2 cycles (FP32 vec)
MULSD/PD has 4 cycles (FP64 scalar)
VMULPD has 4 cycles (FP64 vec)
DIVSS has 14 cycles
DIVPS has 19 cycles
VDIVPS has 38 cycles
DIVSD has 19 cycles
DIVPD has 19 cycles
VDIVPD has 19 cycles
for Quake 3 type 3D engines.
RCPSS has 1 cycle
RCPPS has 1 cycle
VRCPPS has 2 cycles (vector version)

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

Subsequent additions by hardware manufacturers have made this algorithm redundant for the most part. For example, on x86, Intel introduced the SSE instruction rsqrtss in 1999. In a 2009 benchmark on the Intel Core 2, this instruction took 0.85ns per float compared to 3.54ns for the fast inverse square root algorithm, and had less error


AMD Jaguar CPU is designed for Quake III style 3D engines with heavy inverse square root usage.

ID Software's game engines have a major impact on modern 3D games, and modern CPU hardware targets it.

68060 is not optimized for ID Software's Quake and Quake III! Software sells hardware!


AMD Zen 2, the embedded game console x86-64 v3 CPU e.g. Xbox Seise X/S and PS5/ PS5 Pro

Floating point XMM and YMM instructions
ADDSS/D has 3 cycles
ADDPS/D has 3 cycles
MULSS has 3 cycles
MULPS has 3 cycles
DIVSS has 10 cycles
DIVSD has 13 cycles
RCPSS/PS has 5 cycles
VFMADD132PS/PD has 5 cycles

Reciprocal throughput not factored in i.e. the same instruction that can start its processing after 1st since pipelining exists for competent FPUs.

X86's embedded game console design wins
Intel Coppermine for Xbox.
AMD Jaguar for Xbox One /Xbox One X and PS4 / PS4 Pro.
AMD Zen 2 for Xbox Series X / S and PS5 / PS5 Pro.
AMD Zen 5 or Zen 6 for Xbox Next and PS6.

Intel competed for the PS6 contract and lost, but Intel promised a large APU for the PC market.

Intel plans to release similar products to AMD's Strix Halo large APU SKUs, which is designed for games and large ML workloads.

Due to a certain fruit company, there are product overlaps between AMD's Strix Halo APU and game console APUs.

Last edited by Hammer on 27-Jul-2025 at 12:45 AM.
Last edited by Hammer on 27-Jul-2025 at 12:17 AM.

_________________

OneTimer1 Quote:

Nothing of this happened, you can try to implement some SMP/AMP features but you will increase instabilities. Just imagine what it means if an internet application is crashing on a system with shared memory, it means a virus can take it over via the internet.

An internet program has to allow a program to be downloaded and executed for there to be a virus problem. The internet program can open a virus checking library and check the program for viruses or an anti-virus program can watch library vector offsets used to execute programs. This is not that much different than other architectures with SMP and more viruses.

OneTimer1 Quote:

AOS has no memory protection, no separation between user and system space, we are only save from viruses, because we are insignificant.

Some NG AmigaOSs have partial memory protection which is effective. I expect most errant programs are caught by zero page protection and unused address space protection. Code and Kickstart protection is also possible but is less of a problem in my experience. The 68k AmigaOS has ThoRs MMU tools which allow to catch zero page accesses and unused address space accesses. It both catches them for reporting and protects against crashes. It is possible to use the mmu.library to protect code or read only data but it would be easier if the 68k AmigaOS supported this with flags in executables. The 68k AmigaOS is designated as "emulation" fodder declining in tech to 68000 compiled with no incentive to increase support for the MMU under emulation. The Hyperion A-EonKit syndicate wants AmigaOS 4 to be the high tech AmigaOS and the 68k AmigaOS is not allowed to threaten it.

OneTimer1 Quote:

This transformation from old AOS3 to a modern AOS5 didn't happen, Hyperion, the MOS- or AROS-Team doesn't have the money to pay for it, we don't have enough users to buy it and we don't have the 3rd, party companies who will constantly work to make their application run under an OS with new API or CPU. What can someone do now?

If the MorphOS devs are smart, MorphOS will gain SMP support as it transitions to a new architecture. However, they will likely lose direct 68k AmigaOS compatibility without sandboxing. AmigaOS 4 chose to port back to the 68k AmigaOS so new more advanced 68k Amiga hardware is needed but the Hyperion A-EonKit lawfare instead of development is counter productive. AROS x86-64 SMP had momentum but then fizzled before the necessary API changes could be added. Part of the problem was that the 68k AmigaOS is made for 68k Amiga hardware. On a 68k Amiga with custom chips, Disable() works by writing an Amiga register to disable interrupts. Without Disable(), Signal(), Wait() and SignalSemaphores do not work. This is core functionality of the AmigaOS that can not be used and needs to be changed for the AmigaOS to support SMP on x86-64, at least without adding custom Amiga chipset hardware. At least x86-64's more sequential memory consistency model is easier than PPC's weak memory consistency model. I expect AmigaOS 4 has added thousands if not tens of thousands of Load-Acquire and Store-Release instructions, eieio and fence instructions to no avail. The ~4 week SillySMP AROS x86-64 experiment by Jason McMullan and Michal Schulz came closer to SMP than PPC AmigaOS 4 in more than a decade of failure. If x86-64 hardware had the Amiga chipset, AROS x86-64 may already support SMP. PPC and no Amiga chipset is about the worst possible handicap for adding SMP support to the Amiga and AmigaNOne has been an abject failure anyway. Returning to the 68k Amiga with chipset would be easier but additional hardware changes could make SMP support easier yet. SMP is still possible on foreign hardware but how much of the AmigaOS and Amiga software compatibility is left after all the changes?

Hammer Quote:

https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf 68060's FADD range from 3 to 5 cycles. No difference between FDADD (double precision rounding) and FSADD (single precision rounding). FMUL range from 3 to 5 cycles. No difference for FDMUL(double precision). FDIV takes 37 to 39 cycles (single precision). FDDIV takes 37 to 39 cycles.

The minimum timing with all register instruction ops is the base timing. The 68060 FADD and FMUL have 3 cycle execution latency which was good. FDIV has room for improvement but 37 cycles is not bad for extended precision.

Hammer Quote:

Only one of the FPU functional units is active since the 68060 FPU is not properly pipelined. SpecFP score is not pretty for 68060!

The 68060 never received good compiler support and I expect Motorola was focused on integer compiler support which is more important. Without good compiler support, I expect SpecFP benchmarks would be poor. However, the ByteMark benchmark is similar to the Spec benchmark and VBCC support code changes allowed the 68060 to come close to the performance of the P5 Pentium at the same clock speed for fp benchmarks. With an instruction scheduler and more optimizations, the 68060 may outperform the P5 Pentium in fp ByteMark benchmarks. The P5 Pentium FPU can reach a higher IPC than the 68060 FPU but the 68060 FPU has a much better ISA that is much easier to use by compilers.

Hammer Quote:

https://www.agner.org/optimize/instruction_tables.pdf Pentium P5's FADD has 3 cycles FMUL(P) has 3 cycles FDIV(R)(P) takes 19, 33, or 39 clock cycles for 24, 53, and 64 bit precision respectively. Pentium P5 wins for Quake and its clones.

The P5 Pentium has a strong FPU but it is weak at integer compared to competitors with poor superscalar multi-issue, often 1-2 extra cycles for memory accesses and not as optimized of integer timings as FPU timings. A 32-bit integer multiply on the P5 Pentium was 9 cycles where it was 2 cycles on the 68060. Quake used FMUL instead of integer multiply which would have been better performance on some competitors like the 68060.

Hammer Quote:

Intel Atom (2008) X87 FADD(P) has 5 cycles FMUL(P) has 5 cycles FDIV(R)(P) has 71 cycles Floating point XMM instructions ADDSS has 5 cycles MULSS has 4 cycles (for FP32 data, effectively 1 cycle for each data element from SIMD4) MULSD has 5 cycles DIVSS has 31 cycles DIVSS has 60 cycles DIVPD has 122 cycles They are not the same!

The Hammer benchmark is Quake and it uses the x87 FPU. The Atom fixed the P5 memory access delays and an integer 32x32 multiply improved to 5 cycles and was semi-pipelined like FMUL but shared with FPU.

Hammer Quote:

...

Execution latencies can improve with modern chip fab processes.


https://en.wikichip.org/wiki/arm_holdings/microarchitectures/cortex-a76

It is actually a trade off as voltages can be reduced to save power instead. The FPU performance difference between the Cortex-A57 and Cortex-A76 is huge. The Cortex-A57 likely ran out of GP FPU registers with 32 GP registers to keep from stalling in flight instruction execution while the Cortex-A76 could almost get by with 16 GP FPU registers. A CISC FPU with Cortex-A76 execution latencies which supports mem-reg operations likely could get away with 16 GP FPU registers with a negligible drop in performance. A CISC FPU core in FPGA is more likely to have timing that resembles the Cortex-A57 though.

@matthey @hammer
What exactly have your posts to do with buying commodore ?
You guys wouldn't prefer to open a separate topic for these posts?
It makes quite hard to follow the news on the "let's buy commodore" topic this thread is supposed to discuss ?

IridiumFX Quote:

What exactly have your posts to do with buying commodore ? You guys wouldn't prefer to open a separate topic for these posts? It makes quite hard to follow the news on the "let's buy commodore" topic this thread is supposed to discuss ?

Sorry. SMP talk was since the new Commodore chose Commodore OS Vision Linux with SMP over the AmigaOS without SMP for C64x and presumably for the Amiga equivalent of the C64x which they are planning or were planning. One of the old Commodore USA systems, the VIC Slim, used an in-order Intel Bonnell Atom CPU when there was debate about how practical all in one wedge computers are today.


https://www.commodoreos.net/CUSA_VICSlim.aspx

Even way back then, it was practical with an in-order CISC CPU core somewhat like the 68060. Originally, the plan may have been for an A500 case but it may have more recently changed to a smaller A1200 case. The CUSA website has a pic of a modernized A1200 too.


https://www.commodoreos.net/CUSA_FutureModels.aspx

An A1200x is not so interesting but an A1200u would be if "Honouring the Past, Innovating the Future".

@matthey

I am sure you agree with me, yours is a topic best moved to another place where it can get the required attention.
This topic one serves to intercept if there are news on the acquisition, isn't it ?
Say the part 3 of the announced youtube video is released, that would fit here nicely

@IridiumFX

That Part 3 is only rumored to be released either Tuesday or next Saturday.

However there is some more trademark news:

Here

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

The Italian Commodore name holder previously opposed the Commodore 64X Kickstarter campaign because of its use of the brand. They asserted their ownership of the brand and got the campaign paused. Further investigation by Kickstarter revealed they didn’t have a leg to stand on and the campaign was resumed despite their objection. In all likelihood they also have no case with Perifractic’s C64 Ultimate.

The Italians are the same (or related to those) who sold Commodore branded android phones?

If Yes:
. I don't know hat I should think about C= branded android phones,
. if they have a C= theme and UAE installed, it seems right to me.

If No:
. Who the hell are they?

---

It's hard keeping track about who is who, when I search for "My Retro Computer Ltd" I come to "https://myretrocomputer.com/about-us/" where "https://myretrocomputer.com/" is redirecting to https://www.commodore.net/ a page where they are offering the Ultimate C64 in a breadboard case (seems OK to me).

The 'ARM_Pi in a breadbox' guys:
When I follow the guy who made "THEC64"it leads to https://retrogames.biz/products/thec64/


The 'Commodore PET Smartphone' guys:
https://web.archive.org/web/20180704005623/http://www.commodore-cbm.com/

And there is https://www.commodore.inc/

Last edited by OneTimer1 on 28-Jul-2025 at 08:41 AM.
Last edited by OneTimer1 on 28-Jul-2025 at 06:43 AM.

@matthey
@hammer

It's funny to see how you turn every thread on this forum to exactly the same academic discussion as always. Let me remind you the topic here: The "Let's Buy Commodore" Project

@OneTimer1

Sean Donohue's post

Not sure what is hard to understand here. Sean is COO for Peri so it makes no sense for him to run MyRetroComputer as a separate business any more.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*