@Hammer

Quote:

Commodore A2410 has Texas Instruments TMS34010, this TIGA ASIC is not low-cost when compared to ET4000AX. Commodore A2410 didn't advance Amiga's native chipset and somebody at Commodore is PC centric e.g. Commodore Germany and Bill Sydnes. In the PC world, the TIGA died. Lower-cost clones of IBM's 8514 architecture such as ET4000 SVGA killed off TIGA.

I wonder why they chose an expensive chipset? I suppose it was intended for workstation use and not the average big box user. By comparison the ET4000 wouldn't compare. I suppose they could have used an 8414 type chipset. But, according to Wikipee, later 8514 cards used the TMS34010 chipset. If so it should have worked out better.

Quote:

FYI, Advanced Amiga Architecture (AAA) chipset has direct chunky 16-bit pixels (15 bits for 32768 colors and 1 bit for genlock overlay), provided by custom chip 'Monica', but Commodore wasted engineering resources with C65 as the second 256 color chipset. [/quote Yes, unfortunately, it only became vapour ware. They might as well added the C65 256 mode to ECS instead and then it could have competed. Also, they should have produced the C65 as the C128. The problem with anything after the C64 is that they couldn't replace it with anything unless it was exactly compatible with a C64! The Amiga could have failed from the get go, it was totally incompatible with everything C64, even a Plus/4 was more compatible! [quote]C65 (256 display colors with 4096 color palette) was completed in December 1990. AGA (256 display colors with 16M color palette) was completed in March 1991.

Bit late for ECS bit also same year. So close. Needed in 1987 Amiga I reckon so A500 could have used it.

Quote:

Time and resources were also wasted on Bill Sydnes's "A1000jr" and A600 ECS designs. ECS's limited four color productivity display modes doesn't address Amiga's core market and are inferior to the 31.5 kHz VGA 640x480x 16-color mode, let alone IBM's 8514 clones/SVGA and IBM XGA.

Strange marketing. Some people thought the A600 was the next Amiga. Then bought it and soon found out later it was a poor mans A1200.

Quote:

Refer to Vampire SAGA's chunky pixels or Individual Computers Graffiti chunky pixels extensions. Graffiti changes the Amiga-bitplaned graphics into a chunky pixel mode i.e. one byte in memory represents a single pixel, hence the value of a byte selects it's colour.

I wonder how Grafitti did this. I mean, it goes into bitplanes, so it must interpret some organised confusion. I've seen code use 640 width for a 320 width screen. So that must assist somehow despite extra bandwidth.

Quote:

Modify Lisa chip with integrated Graffiti chunky pixels.

That would be interesting. A dedicated mode using chunky would have been good. And more direct.

Quote:

John Carmack's argument against the Amiga has the install base context.

\

What mostly A500 users?

I don't recall any 286 EGA users putting up a fuss. Which is closer to an A500. Guess they moved on.

Quote:

PS; I have an Amiga 3000 (with 68030/68882 at 25 Mhz) in early 1992 and I have my own beef against the fools who designed ECS.

Given it's not much better than an A2000 from 1987 I could see why.

Quote:

Unlike C= Amiga Hombre, TIGA's 3D didn't target OpenGL compliance i.e. SGI has accelerated 3D leadership. PC OpenGL/Direct3D cloners killed off SGI's 3D hardware.

Looks like all their days were numbered what ever they would do.

@Karlos

Quote:

Are you seriously telling me you didn't use FBlit patches on your Amiga? As soon as you got to a fast 020 (e.g. 28MHz/fast) the game was up for the AGA blitter when doing general workbench stuff. On faster processors (030/50MHz and above) you'd be mad not to use it. The performance difference is night and day.

No, but what makes you say that? I installed FBlit on my A1200 years ago. Likely it was a step up from FastFonts which probably used the same ideas. FBlit would have been faster because it relied on a side effect. And that was because it wasn't upgraded with other hardware on AGA. So with a faster CPU running at a faster clock rate it can then beat the blitter at block copy operations. By comparison, for chunky conversions, code uses blitter assisted routines on slower hardware.

My point was I prefer dedicated hardware. Just like preferring hardware sprites. And preferring hardware audio channels. The blitter was dedicated for the job. It was fine for what it would do, but the speed wasn't upgraded to keep up. Just like how the CIA wasn't upgraded but it's features couldn't be replicated in software.

@Hypex

The context was in relation to using (possible SIMD) the CPU to do graphical stuff. If all you have is AGA, then if you want to use it for productivity, you need the fastest drawing and blitting you can get, so why not use whatever additional CPU features your FPGA has sprouted for that task?

_________________
Doing stupid things for fun...

@matthey

Quote:

matthey wrote: Motorola called instruction combining "instruction folding" and it goes back to at least 1994. M68060 User's Manual 10-8 Quote: Additionally, the use of instruction folding techniques allow one or two instructions to be simultaneously executed with a predicted taken Bcc (also for BRA and JMP instructions). The 68060 only used "instruction folding" with branches which is sometimes called "branch folding".

This isn't instructions fusion: it's a mechanism like instruction predication.

What's weird is that they talk about executing two instructions with a predicted branch, which shouldn't be possible, since the 68060 can decode a maximum of 2 instructions per clock cycle.
Quote:

Instruction folding was brought back in the V4 ColdFire and expanded though. MOTOROLA THAWS COLDFIRE V4 (May 15, 2000) 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. Instruction folding was brought back in the CF5407 which is the V4 ColdFire chip the article above is about.

This is clearly instructions fusion.

@Hammer

Quote:

Hammer wrote: @matthey Quote: WinUAE didn't have a "compatible" extended precision 68k FPU until 2018 despite being first released in 1995. WinUAE changed back to an incompatible double precision FPU as default in 2020. WinUAE still offers 80 bits FP compatibility when users need this feature just as all modern X86-64 CPUs offer 80-bit FP compatibility in the slower performance path,

What's not clear to you about this:
"WinUAE didn't have a "compatible" extended precision 68k FPU until 2018 despite being first released in 1995. WinUAE changed back to an incompatible double precision FPU as default in 2020.
? I've highlighted the most important facts. Now check when the Apollo 68080 WITH FPU support was released, count how many years passed, and compare it with the same for WinUAE supporting 80-bit precision.
Quote:

but X86-64 CPUs have the option to brute force >4 Ghz and >5 Ghz this issue. Incoming AMD Zen 4 and Intel Raptor Lake have clock speeds nearing 6 Ghz.

Your usual non-sense + useless padding.
Quote:

The 68060 integrates a Floating-Point Unit that is compatible with Motorola 68881 / 68882 co-processors.

That's plainly FALSE!
Quote:

68060 FPU provides hardware support only for most common floating-point instructions and data types

Then this CONTRADDICTS your previous statement.
Quote:

while unsupported instructions and data types are emulated in the slower software path.

IF and WHEN it's possible. Which is NOT always the case, IF you know how 68K platforms (not only the Amiga) were developed, worked, and maintained.
Quote:

68060 FPU provides hardware support for FP32, FP64, and FP80.

So, it lacks stuff. MANY things, actually.

Logical conclusion (for whom logic works) is that the 68060 was NOT fully compatible with the 68K software which was previously developed.
Quote:

Motorola 68060's software support package (M68060SP) doesn't work with Amiga kick-the-OS games since it wasn't placed below the OS level.

Which means that some software did NOT work. Right?
Quote:

WHDload game patches mitigate this issue.

So, someone else had to fix what Motorola broke...
Quote:

Unlike Intel's Pentium X87 FPU, Motorola wasn't able to implement pipelining for the 68060 FPU. AMD implements fully pipelined X87 FPU with K7 Athlon.

Useless padding-
Quote:

AC68080 V2 has non-compliant IEEE-754 FP52.

Correct. And now what about 68040 and 68060 NOT supporting some data types? And A LOT of instructions?
Quote:

Apollo-Core didn't place unsupported FP instructions in the slower performance path.

Again, you don't know what you're talking about.

The Apollo core HAS a slower path for unimplemented FP instructions. This is a special 68080 code which is mapped in a reserved part of the memory and where those traps are routed.

So, the Apollo 68080 implemented ALL FPU instructions (and data types) of ALL 68K processors. It means that, from this PoV, it's the most compatible 68K processor which exists!

Motorola, on the exact contrary, developed the most INCOMPATIBLE 68K processors.

You're the king of ignorants.
Quote:

If Apollo-Core wants to follow Intel/AMD, Apollo team should have placed unsupported FP instructions in the slower firmware microcode path

They did it, but in millicode.
Quote:

and used higher clock speed

With such FPGA?!? Do you understand of what are you talking about?!?!?
Quote:

and general arhitecture improvements (e.g. larger cache, wider I/O) to brute force performance improvements.

That's what they did! You're complete ignorant!
Quote:

My argument is about respecting legacy software, not about the micro-architecture implementation argument. The micro-architecture implementation argument is useless when it doesn't respect legacy software.

Then talk to Motorola and let it know it since, after the 68000, it has developed not a single processor which was fully backward compatible!
Quote:

Quote: Maybe this incompatibility had become the Amiga industry standard despite the possibility to produce unintended results and even crashes. It stems from Motorola's mindset that doesn't respect legacy software.

Don't put the Apollo core at the same level of Motorola: it's not respectful of the FACTs.

As I've said, the Apollo 68080 core is the MOST compatible 68K ever. EVER!

It's missing only TWO things: 80-bit precision for the FPU, and a PMMU. Everything else is implemented!

Regarding the FPU, we just talked.

Regarding the PMMU, well, you should know (but you clearly do NOT know!) that there is NOT a 68K processor which has or implemented a PMMU which is fully compatible with the others. NONE! AT ALL! While I agree that the Apollo team should implement a PMMU, because it's useful, the problem here is to understand WHICH ONE to be implemented; and this is NOT an easy decision, since any implementation will leave out some existing software.

Anyway, if you compare all Motorola processors with the Apollo 68080 regarding the compatibility with the existing software, then the latter wins hands down. EASILY!
Quote:

On 8GB USB flash drive with MS-DOS 7.1, I run DOS games such as Pinball Fantasy, Doom, and Super Street Fighter 2 Turbo on a Core i7-3770K/GeForce GTX 1050/UEFI-CSM-based PC.

Hammer's padding...
Quote:

Quote: I warned the Apollo team that reducing the precision wouldn't be compatible. Gunnar knew but chose performance and logic savings over compatibility. WinUAE also chose performance over compatibility as the default. WinUAE still offers 80 bits FP compatibility as an option.

WHEN it was implemented it?

WHY it's not enabled by default?
Quote:

According to Intel documentation: Instruction Fusion is when multiple RISC-like assembly instructions are merged into CISC-like one assembly instruction.

This is micro-op fusion.
Quote:

Macro-Operation Fusion (also Macro-Op Fusion, MOP Fusion, or Macrofusion) is a hardware optimization technique found in many modern microarchitectures whereby a series of adjacent macro-operations are merged into a single macro-operation prior or during decoding. Those instructions are later decoded into fused-µOPs.

This is also called Instructions fusion, since a Macro-op is an instruction, in Intel's literature.
Quote:

This particular argument is about the micro-architecture implementation which is irrelevant to respecting legacy software argument.

As said above, go talk to Motorola, since they did a very bad job from this PoV with EACH processor after the 68000...
Quote:

Quote: A partial implementation of a FPU and a partial implementation of a SIMD unit doesn't count as one of something? If only someone had suggested leaving the SIMD unit experimental and implementing a fully compatible FPU. Oh, yea, someone did. If only the Apollo team implement unsupported 68881/68882/68040/68060 FPU instructions in the slower path i.e. X86 world implements fast and slow paths.

They DID it! With millicode.
Quote:

Quote: It sucks that there was bad blood between them but the "Apollo team" is on a mission to dominate the high end Amiga FPGA market. Too bad the standalone Vampire V4 didn't follow C= A500/A1200's CPU expandability characteristics.

What's the problem?
Quote:

FYI, Minimig FPGA version 1.8 supports a real 68000 socket, hence PiStorm/Pi 3a(or Pi 2W)/Emu68 and any other A500 68K CPU socket accelerator works with it e.g. Vampire AC68080, Warp 560, TF536 and etc. Minimig FPGA version 1.8 followed C= A500's CPU expandability characteristics.

And? See above: what's the problem?
@Hammer

Quote:

Hammer wrote: @matthey Quote: The size of chip memory was a limitation of some games depending on the complexity. However, fast memory improved total system bandwidth and more chip memory bandwidth remained. The caches of later 68k processors reduced memory accesses also leaving more system and chip bandwidth. Even the little 256 byte ICache of the 68020 combined with the very good code density of the 68k removes most instruction memory traffic as most code loops fit in 256 bytes. https://www.youtube.com/watch?v=GojpwZMBHz4 Amiga 1200's stock 68EC020 CPU with Fast RAM was able to handle arcade quality Final Fight game port. This port includes a parallax background. 68020's small cache is not enough.

LOL Using 64MB of fast ram...
Quote:

Arcade quality Final Fight port was programmed in 68020 assembler language.

What's the news here? Most of Amiga games were programmed in assembly (NOT assembler: this is the tool for compiling programs written in assembly language).
Quote:

I support then-MD of Commodore UK David Pleasance's out-of-the-box A1200 with Fast RAM SKU push.

I don't subscribe it: chip ram is way better for 2D games, which was/is the target of all Amigas.
Quote:

Hammer wrote: @cdimauro Quote: Then please tell me about Motorola decisions to remove FPU instructions from 68040 and 68060: those were DESIGN decisions, which affected the existing software. 68060 FPU hardware supports FP32, FP64, and FP80. Unsupported instructions are in the M68060SP software support package. Motorola's M68060SP support package wasn't placed below the OS level.

Already answered above. Consequences: the 68060 is NOT backward compatibile with existing 68K software...
Quote:

Quote: This is a bug: NOT a design decision. That's why Intel decided for recalling the processors. X86 market pressure has defined classic Pentium FDIV flaws as a bug.

It isn't the pressure which defines if something is a bug or not, rather its intrinsic nature (e.g.: the effects).

The pressure is only relevant for recalling campaigns.
Quote:

However, it has been noted that far fewer failures are found in single precision than in double or extended precisions. For example, correct values all would round to 1.3338, but the returned values are 1.3337, an error in the fifth significant digit. Classic Pentium with FDIV bug can still run Quake-type games.

Indeed. The bug was quite rare (happened with a probability of 1 / billions).
Quote:

Quote: Something which did NOT happen with Motorola and its processors which were missing FPU instructions. 68060 FPU supports FP32, FP64, and FP80. Unsupported instructions are in the M68060SP software support package a.k.a the slow path.

See above.
Quote:

Quote: If it's a fact (for you) then you can provide sources for your claims. If you find them, because you might have confused POWER4 / PowerPC 970 instructions cracking with fusion. But cracking is the exact opposite of fusion. Or, you might have confused their FMA instructions with instructions fusions. But, again, those are completely different things. Anyway, it isn't my problem: your is the thesis and you are the one that has to prove it. Your micro-architecture implementation argument is useless when it doesn't respect Amiga legacy software.

This is again a Red Herring: I see that you like a lot this logical fallacy. Logic isn't your friend. But, unfortunately for you, it's my friend, as well as memory. In fact, now I report again YOUR statement, YOUR words:
"FACT: IBM PowerPC 970 also has instruction fusion"

And I ask you again: PROVE IT!
Quote:

Quote: I assume because it's exactly your pattern. You behave like Pavlov's dog when talking about x86 processors, always trying to put AMD in good light, and Intel in bad light. Specifically, I quote again you: "Apollo-core's AC68080 attempted to be "AMD" for the 68K family" Which is clearly false, since the most important technologies implemented on the 68080 are the SIMD unit and instructions fusion (which allows this processor to execute up to 4 instructions per clock). And both were designed by Intel. So, the statement should have been this, instead, as I've said: "Actually Apollo's 68080 is attempted to be more like Intel instead of AMD, due to the design decisions." My argument is not about the micro-implementation argument i.e. my argument is about resulting output, performance, and respecting Amiga's legacy software.

Again, you're trying to change the topic. You should know that it does NOT work with me.

Your (usual) fault is that you've put AMD where it was NOT the case. And that's why I've corrected you.

Besides that and even taking your new argument, well, it's wrong: see above my replies.
Quote:

Your micro-implementation argument is meaningless when AC68080 V2 is not compliant with 688881/68882/68060's FP64 and FP80.

See above: 68080 is WAY better than ANY Motorola processor after the 68000. ANY. FACTs at hands (IF you know them).
Quote:

AC68080 V4's FP64 support debunks your FP52 is a "good enough" argument.

My argument? Care to QUOTE me and PROVE IT, dear liar? Now you started mystifying: lack of arguments?
Quote:

Apollo team didn't respect Amiga's legacy software at the same level as Intel/AMD's X86/X87 legacy software support.

MUHAHAHAHAH You made my day. Really!

As I've said, and even the stones know, it's Motorola which did NOT respect ANY (not only the Amiga) 68K legacy software, with its processors which were NOT backward compatibles each other.

On the exact contrary, and as I've already reported, the Apollo 68080 gives the BEST backward-compatibility. EVER. Since it implements ALL (again: ALL!) instructions of ALL 68K processors.
Quote:

Quote: So, you aren't able to judge yourself how the Amiga Doom is working compared to the PC one, and you've to resort to the comment of someone else. That's a fluff argument.

Fluff? Only because you're NOT able to rebut it.
Quote:

I have two RTX 3080 Ti OC AIB cards i.e. one ASUS ROG Strix and the other is an MSI Gaming X variant. In terms of benchmarks, the slightly faster RTX 3080 Ti is the MSI Gaming X variant. The minor frame rate differences are not major issues when ASUS is the largest AIB PC GPU vendor. If absolute highest frame rates were a major factor, I would have purchased MSI's Supreme X or EVGA FTW3 RTX 3080 Ti models. My 68K configuration for C= Amiga hardware platforms are 68HC000 @ 50 Mhz overclocked, 68EC020 @ 14 Mhz with 8MB 68882 @ 50Mhz card, 68LC060 rev 4 (reached 75 Mhz), 68060 rev 1 @ 62.5 Mhz overclocked and PiStorm/Pi 3a/Emu68. I sold my A3000/030 @ 25 Mhz in 1996 for Pentium 150/S3 Trio 64/Yamaha Sonata (16-bit sound card) based clone PC. My A3000/030 @ 25 Mhz was useless for Doom! For Quake, my A3000 with proposed Cyberstorm 060 @ 50Mhz and CyberGraphics 64 (S3 Trio 64) upgrades weren't cost-effective when compared to Pentium 150/S3 Trio 64/Yamaha Sonata (16-bit sound card) based clone PC. 68HC000 @ 50 Mhz overclocked, PiStorm/Pi 3a/Emu68 for C= A500 rev 6A. 68EC020 @ 14 Mhz with 8MB 68882 @ 50Mhz card, 68LC060 rev 4 (reached 75 Mhz), 68060 rev 1 @ 62.5 Mhz overclocked for C= A1200 rev 1D1. I don't plan to purchase another Motorola "68030" performance-level CPU.

Now you're passing yourself: an entire wall of non-sense & unuseful text.
Quote:

Quote: Well, I'm not superman and I don't have his sight, but I can see the differences. Better that you ask for a good pair of glasses Unlike IBM VGA, AGA's Doom frame rate continues to scale with a faster CPU.

So what?
Quote:

At a certain point with faster CPUs, AGA can be a bottleneck, but the Hollywood industry's full motion video standard is 24 fps. Many XBO/PS4 game console titles have a 30 fps target.

I've to recall you that YOU've stated that the AGA is able to do FULL MOTION (so, 25 or 30 FPS. At least). Care to PROVE it?
Quote:

My 386DX-33 with ET4000 was my gaming PC from 1992 to 1996 era and it acts like A1200 with a fast 030 card.

You aren't a reliable source, since you proved to NOT being able to distinguish the differences in the video that you posted yourself. And you'd to resort to someone else's comment. Which is like you, of course: unable to see the differences. Not because there aren't differences, but because you, both, are NOT able to catch them.

Now I want to see how long do you want you continue with your tragicomedy...

Meanwhile...

_________________
Doing stupid things for fun...

@cdimauro

Of course the 68060 was perfectly backwards compatible with every 68020 and 68882 user mode instructions. That's why nobody needed any complicated vendor supplied runtime trap and patch hacks with their 68060 cards and absolutely nobody thought to build a more general replacement patcher for other 060 cards either. It all just worked perfectly...

No, wait. The other thing.

_________________
Doing stupid things for fun...

@Karlos: :asd:

cdimauro Quote:

This isn't instructions fusion: it's a mechanism like instruction predication.

Predication does not reduce the number of instructions executed unless instruction fusion/folding is used with it (predication reduces bubbles/stalls of short branches). I was deliberate about what I posted which I believe is strong evidence that "branch folding" was considered to be a technique of "instruction folding" at Motorola. "Instruction fusion" may be different according to Intel terminology.

cdimauro Quote:

What's weird is that they talk about executing two instructions with a predicted branch, which shouldn't be possible, since the 68060 can decode a maximum of 2 instructions per clock cycle.

The 68060 fetches and pre-decodes 4 bytes/cycle of code but I couldn't find a limitation on the number of instructions per clock though a 2 instruction limit is entirely possible. With a fetch of only 4 bytes/cycle, this would normally be a huge bottleneck for a superscalar core and most RISC processors couldn't be superscalar with such a small fetch but the fetched and predecoded instructions go into an instruction buffer which decouples the prefetch pipeline from the execution pipelines. The prefetch pipeline is able to keep fetching instructions during execution pipeline stalls and multi-cycle instruction execution. There are only 2 integer execution pipelines which can only execute up to 2 instructions per cycle but there is also a branch unit which can use "branch folding" of predicted branches to fold away branches and the FPU can execute an instruction.

M68060 User’s Manual Quote:

The MC68060 superscalar architecture allows pairs of single-cycle standard operations to be simultaneously dispatched in the operand execution pipelines. Additionally, the design also permits a single-cycle standard instruction plus a conditional branch (Bcc) predicted by the branch cache to be dispatched in the OEP. Bcc instructions predicted as not taken allow another instruction to be executed in the sOEP. This also is true for forward Bcc instructions that are not predicted. Additionally, the use of instruction folding techniques allow one or two instructions to be simultaneously executed with a predicted taken Bcc (also for BRA and JMP instructions). The floating-point pre-exception model of the MC68060 supports execution overlap between multi-cycle floating-point instructions and the integer execute engines. Once a multi-cycle floating-point instruction has started its execution, the primary and secondary OEPs may continue to dispatch and complete integer instructions in parallel with the floating-point instructions. The OEPs will stall only if another floating-point instruction is encountered before the first floating-point instruction has completed its execution. The floating-point instructions that permit this execution overlap are classified as pOEP-butallows-sOEP in Table 10-4.

At least 3 instructions/per cycle could be retired and possibly 4 per/cycle. Not bad for a CPU with a power efficient 4 bytes/cycle fetch and only 32 bit data bus which allows cheaper hardware but that's what exceptional code density allows. The 68060 dominated the Pentium in Power, Performance and Area (PPA). Sadly, it was not used in PCs or laptops but the embedded market where PPA is important. I found market data on the 68060 which showed 1,310,000 units sold from 1994-1996 generating $290,150,000 of revenue.

https://manualzz.com/doc/21099114/dataquest

Volume was lower than most 68k chips but revenue was solid considering the high price especially for embedded use. The 68060 had surpassed the 68040 in unit sales in 1996 despite no use from Apple or CBM so almost purely high end embedded sales.

cdimauro Quote:

This is clearly instructions fusion.

Probably, unless Intel "instruction fusion" terminology only applies to OoO and/or micro-op instruction fusion. Did Intel use instruction fusion before moving to OoO mico-op designs?

@cdimauro

Quote:

Motorola, on the exact contrary, developed the most INCOMPATIBLE 68K processors.

Well, I don't mean to brag, but I mean MC64K is clearly more incompatible

_________________
Doing stupid things for fun...

@Karlos

If I could expand an ECS chipset to improve graphics, what do you think would be changed or added?
Could it be done without changing pin count too much?

The idea would be put the design into an FPGA and put it on an A600 remake mother board.
Expanded and Enhanced?

Last edited by Trekiej on 13-Aug-2022 at 03:08 AM.

_________________
John 3:16

@Karlos

Quote:

Karlos wrote: @Hammer Quote: At a certain point with faster CPUs, AGA can be a bottleneck, but the Hollywood industry's full motion video standard is 24 fps. Many XBO/PS4 game console titles have a 30 fps target. Lower frame rates are fine for non-interactive media like movies. For games, though, there is the whole input/feedback latency consideration: how long between pressing a control and seeing the reaction? FPS games of the era were single threaded and needed to process user input and game physics, sequentially each frame. As the frame rate goes down, so does the responsiveness until the perceived lag becomes a challenge. There is a much bigger difference going from 30 to 60 FPS for gaming purposes than there is for basic video consumption.

In the current gaming generation, games like Genshin Impact (Unity3D engine) is a multi-billion dollar revenue-earning games and its frame rate is limited to either 30 fps or 60 fps modes. Depending on graphics settings, Genshin Impact runs well on Intel Xe, AMD RX Vega, and Qualcomm Adreno 540/642 mobile Vulkan capable GPUs.

120/144/240 Hz are for competitive gaming with a lower 1080p/1440p resolution. There are 4K console games that run up to 120 Hz (HDMI 2.1), but the variable refresh rate's purpose is to support smooth frame rates within a certain range. The dynamic resolution, variable-rate shading and pixel reconstruction are tricks to prioritize frame rate over graphics clarity.

Story-driven RPG games don't require competitive gaming's high frame rates. Genshin Impact devs say Zelda: Breath Of The Wild was a big inspiration. Don't underestimate Nintendo's approach.

Genshin Impact (Story-driven RPG games) sold more units when compared to Microsoft/ID Sofware's Doom Eternal. Microsoft has been solidifying its RPG game offerings such as Bethesda's Elders Scrolls and Activision-Blizzard's World of Warcraft.

Gaming is split between causal and competitive gaming.

For late 1993's Doom context, the argument is the "good enough experience" argument e.g. response for "What IF" Dread running on a stock Amiga 500 with 1MB RAM is good.

_________________
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)

Trekiej Quote:

If I could expand an ECS chipset to improve graphics, what do you think would be changed or added? Could it be done without changing pin count too much? The idea would be put the design into an FPGA and put it on an A600 remake mother board. Expanded and Enhanced?

Why use 4 $10 FPGAs instead of 1 $10 FPGA while reducing potential performance and enhancements? CBM would have loved to have a single chip Amiga but it would have been too expensive. Today it is no problem at all. The newer Apollo Core/Vampire accelerators can provide (S)AGA and HDMI output to ECS Amigas if you still want to use the Amiga I/O. It is a bit of a hack and your mileage may vary but it is a nice bonus value added feature as I described it when I suggested it as part of the Apollo team.

https://www.investopedia.com/terms/v/valueadded.asp

@cdimauro

Quote:

What's not clear to you about this: "WinUAE didn't have a "compatible" extended precision 68k FPU until 2018 despite being first released in 1995. WinUAE changed back to an incompatible double precision FPU as default in 2020. ? I've highlighted the most important facts. Now check when the Apollo 68080 WITH FPU support was released, count how many years passed, and compare it with the same for WinUAE supporting 80-bit precision

1. WinUAE gained FP80 support just as WinUAE itself was maturing.

2. WinUAE is a free product while AC68080 is not a free product. With open source, if you want a feature X, do it yourself.

3. WinUAE is running on multi-GHz X86 CPUs when it has the option to brute force scalar operations. MacOS 68K works without an FPU via CPU-only scalar path.

I have K7 Athlon Thunderbird 1.133 GHz in 2001, Athlon XP "Thoroughbred" 2400+ (2Ghz)/nForce 2 motherboard in 2002, Athlon 64 3200+ ("ClawHammer", 2.0 Ghz) in 2004 and Core 2 Duo E6700 in 2006.

Any of my old K7 Athlons PCs murders Vampires just like Pi 3a (ARM Cortex A53 1.5Ghz) .

Amiga 3D applications come in scalar and FPU versions and PC Master Race has the option to brute force Amiga applications scalar edition.

X86 CPUs with integrated X87 FPU didn't reach down to AC68080 V2's FP52 debacle. Only Motorola mindset would have released Pentium class CPU such as 68060 without FPU like 68LC060.

68LC060 wasn't powerful enough to brute force software to emulate the FPU at reasonable performance levels.


Quote:

Your usual non-sense + useless padding.

You can't handle the fact that WinUAE/X86-64-based PC crushing Vampire, just as PiStorm/Pi 3a/Emu68 is a Vampire killer.

Quote:

That's plainly FALSE!

That's plainly FALSE!

Refer mmu.libraries and 68060.library's propose.
CyberPatcher will trap and emulate any unsupported instructions.
Mentioned software support package operates at the OS level.

https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf
An IEEE Standard, MC68040- and MC68881-/MC68882-Compatible FPU.

The MC68060 is compatible with the ANSI/IEEE Standard 754 for Binary Floating-Point
Arithmetic. The MC68060’s FPU has been optimized to execute the most commonly used
subset of the MC68881/MC68882 instruction sets.

Software emulates floating-point instructions not directly supported in hardware. Refer to Appendix C MC68060 Software Package for details on software emulation. The MC68060FPSP provides the following features:

• Arithmetic and Transcendental Instructions
• IEEE-Compliant Exception Handlers
• Unimplemented Data Type and Data Format Handlers


----

The MC68060 FPU has been optimized for the most frequently used instructions and data
types. The MC68060 fully conforms to the ANSI/IEEE 754–1985 Standard for Binary Floating-Point Arithmetic.

In addition, the MC68060 processor maintains compatibility with the
Motorola extended-precision architecture and is user object code compatible with the
MC68881/MC68882 floating-point coprocessors and the MC68040 microprocessor FPU.

With the inclusion of the M68060SP, the MC68060 provides MC68881/MC68882-compatible software functions


For 68060, unsupported instructions are on the slow path.

You can't handle fast and slow instruction path ideology.

Too bad MC68060 Software Package wasn't below the OS level like on X86-64's microcode firmware updates.

X86-64's microcode firmware updates are handled by a micro-coding hardware unit separate from actual execution units. Actual execution units wouldn't be wasting compute resources on the translation/decode stage.

PiStorm/PI 3a/Emu68's compatibility is below the OS level, hence the emulation is transparent to Amiga's legacy software. Emu68's bug fixes are done via software updates.

WinUAE 4.9.x 64-bit edition's FPU emulation has Host 64 bit, Host 80 bits and SoftFloat (80 bit) options. It's the end user's software option to trade performance vs accuracy.

AC68080 V2 FPU has 52 bits. Apollo team hasn't offered 64-bit and 80 bits FPU emulation support for the slow path.


https://www.youtube.com/watch?v=e_ElgKvKFuY
Amiga 1200 with 68060 running Mac OS 8.1 via Fusion Mac, and it works fine. 68060 FPU doesn't break Amiga's Fusion software.

Quote:

Then this CONTRADDICTS your previous statement.

The fast and slow instruction path is a hard concept for you.

Quote:

IF and WHEN it's possible. Which is NOT always the case, IF you know how 68K platforms (not only the Amiga) were developed, worked, and maintained.

Too bad MC68060 Software Package wasn't placed below the OS level like on X86-64's microcode firmware updates.

WHDLoad games are run after AmigaOS is loaded.

Unlike AmigaOS 4.x PowerPC's OS level 68K emulation, PiStorm/PI 3a/Emu68's 68K compatibility is below the Amiga OS level, hence the emulation is transparent to Amiga's legacy software. Emu68's bug fixes are done via software updates.

PiStorm/PI 3a/Emu68 with my A500 is like a very fast A3000 with RTG.

Transmeta's Code Morphing Software is below the OS level.

PiStorm32/Pi 4 CM/Emu68's and TerribleFire/Buffee's 68K emulation operates below the Amiga OS level.

Last edited by Hammer on 13-Aug-2022 at 07:03 AM.
Last edited by Hammer on 13-Aug-2022 at 06:44 AM.
Last edited by Hammer on 13-Aug-2022 at 06:42 AM.
Last edited by Hammer on 13-Aug-2022 at 06:39 AM.
Last edited by Hammer on 13-Aug-2022 at 06:11 AM.
Last edited by Hammer on 13-Aug-2022 at 04:42 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:

matthey wrote: cdimauro Quote: This isn't instructions fusion: it's a mechanism like instruction predication. Predication does not reduce the number of instructions executed unless instruction fusion/folding is used with it (predication reduces bubbles/stalls of short branches). I was deliberate about what I posted which I believe is strong evidence that "branch folding" was considered to be a technique of "instruction folding" at Motorola. "Instruction fusion" may be different according to Intel terminology.

Yes, they are very different.
Quote:

cdimauro Quote: What's weird is that they talk about executing two instructions with a predicted branch, which shouldn't be possible, since the 68060 can decode a maximum of 2 instructions per clock cycle. The 68060 fetches and pre-decodes 4 bytes/cycle of code but I couldn't find a limitation on the number of instructions per clock though a 2 instruction limit is entirely possible. With a fetch of only 4 bytes/cycle, this would normally be a huge bottleneck for a superscalar core and most RISC processors couldn't be superscalar with such a small fetch but the fetched and predecoded instructions go into an instruction buffer which decouples the prefetch pipeline from the execution pipelines. The prefetch pipeline is able to keep fetching instructions during execution pipeline stalls and multi-cycle instruction execution. There are only 2 integer execution pipelines which can only execute up to 2 instructions per cycle but there is also a branch unit which can use "branch folding" of predicted branches to fold away branches and the FPU can execute an instruction. M68060 User’s Manual Quote: The MC68060 superscalar architecture allows pairs of single-cycle standard operations to be simultaneously dispatched in the operand execution pipelines. Additionally, the design also permits a single-cycle standard instruction plus a conditional branch (Bcc) predicted by the branch cache to be dispatched in the OEP. Bcc instructions predicted as not taken allow another instruction to be executed in the sOEP. This also is true for forward Bcc instructions that are not predicted. Additionally, the use of instruction folding techniques allow one or two instructions to be simultaneously executed with a predicted taken Bcc (also for BRA and JMP instructions). The floating-point pre-exception model of the MC68060 supports execution overlap between multi-cycle floating-point instructions and the integer execute engines. Once a multi-cycle floating-point instruction has started its execution, the primary and secondary OEPs may continue to dispatch and complete integer instructions in parallel with the floating-point instructions. The OEPs will stall only if another floating-point instruction is encountered before the first floating-point instruction has completed its execution. The floating-point instructions that permit this execution overlap are classified as pOEP-butallows-sOEP in Table 10-4. At least 3 instructions/per cycle could be retired and possibly 4 per/cycle.

This explains why 2 instructions could be executed with a predicted branch.
Quote:

Not bad for a CPU with a power efficient 4 bytes/cycle fetch and only 32 bit data bus which allows cheaper hardware but that's what exceptional code density allows.

Absolutely: it's a "beast". Great processor.
Quote:

The 68060 dominated the Pentium in Power, Performance and Area (PPA).

As I've already said, they aren't comparable: different features (and design decisions).
Quote:

Sadly, it was not used in PCs or laptops but the embedded market where PPA is important. I found market data on the 68060 which showed 1,310,000 units sold from 1994-1996 generating $290,150,000 of revenue. https://manualzz.com/doc/21099114/dataquest Volume was lower than most 68k chips but revenue was solid considering the high price especially for embedded use. The 68060 had surpassed the 68040 in unit sales in 1996 despite no use from Apple or CBM so almost purely high end embedded sales.

Indeed. The bad thing was also that 68060 was too late. AND Motorola decided to kill its 68K family: this also seriously limited its adoption.
Quote:

cdimauro Quote: This is clearly instructions fusion. Probably, unless Intel "instruction fusion" terminology only applies to OoO and/or micro-op instruction fusion.

No, OoO isn't needed. AFAIR micro-op fusion happens when instructions are already decoded and micro-ops generated for them.

However Macro-op fusion is the real instructions fusion, because this happens at the decoding stage, when two instructions (so, not micro-ops) are fused to a single micro-op.
Quote:

Did Intel use instruction fusion before moving to OoO mico-op designs?

I don't know. However and AFAIR its Atom should have instructions fusion and it was in-order.

@Karlos

Quote:

Karlos wrote: @cdimauro Quote: Motorola, on the exact contrary, developed the most INCOMPATIBLE 68K processors. Well, I don't mean to brag, but I mean MC64K is clearly more incompatible

My C64K (a redesign & enhancement of 68K) as well, but at least it's assembly source-level compatible for a good part partially.

@Trekiej

Quote:

Trekiej wrote: @Karlos If I could expand an ECS chipset to improve graphics, what do you think would be changed or added? Could it be done without changing pin count too much? The idea would be put the design into an FPGA and put it on an A600 remake mother board. Expanded and Enhanced?

With an FPGA you could design a cleaned-up & enhanced Amiga(-inspired) platform, with a new 68-like (but not compatible) processor and an ECS-like (but, again incompatible) chipset, better using the resources.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: What's not clear to you about this: "WinUAE didn't have a "compatible" extended precision 68k FPU until 2018 despite being first released in 1995. WinUAE changed back to an incompatible double precision FPU as default in 2020. ? I've highlighted the most important facts. Now check when the Apollo 68080 WITH FPU support was released, count how many years passed, and compare it with the same for WinUAE supporting 80-bit precision 1. WinUAE gained FP80 support just as WinUAE itself was maturing.

Same for the Apollo.
Quote:

2. WinUAE is a free product while AC68080 is not a free product.

I reveal you a secret: all Motorola 68K processors were NOT free product, and they all incompatible each other. Much worse than Apollo's 68080.

Any feedback about this for you, or I've to assume that it was fine AND, then, you're using double standards...
Quote:

With open source, if you want a feature X, do it yourself.

Indeed. And the point was/is?
Quote:

3. WinUAE is running on multi-GHz X86 CPUs when it has the option to brute force scalar operations. MacOS 68K works without an FPU via CPU-only scalar path. I have K7 Athlon Thunderbird 1.133 GHz in 2001, Athlon XP "Thoroughbred" 2400+ (2Ghz)/nForce 2 motherboard in 2002, Athlon 64 3200+ ("ClawHammer", 2.0 Ghz) in 2004 and Core 2 Duo E6700 in 2006. Any of my old K7 Athlons PCs murders Vampires just like Pi 3a (ARM Cortex A53 1.5Ghz) . Amiga 3D applications come in scalar and FPU versions and PC Master Race has the option to brute force Amiga applications scalar edition.

Usual useless padding...
Quote:

X86 CPUs with integrated X87 FPU didn't reach down to AC68080 V2's FP52 debacle.

Debacle? Then could you please pick another term from the dictionary for what Motorola did with all of its 68K processors? Maybe you need a new term for it, since you've already used debacle...
Quote:

Only Motorola mindset would have released Pentium class CPU such as 68060 without FPU like 68LC060.

Maybe because it had a different target (embedded)?
Quote:

68LC060 wasn't powerful enough to brute force software to emulate the FPU at reasonable performance levels.

Well, Motorola's library shows the exact contrary: performance was very good.

Unless you talk about catching exceptions generated for unimplemented FPU instructions and emulating them: this was very slow.
Quote:

Quote: Your usual non-sense + useless padding. You can't handle the fact that WinUAE/X86-64-based PC crushing Vampire, just as PiStorm/Pi 3a/Emu68 is a Vampire killer.

Really? I'm an emulator evangelist from really long time and I'm not interested on hardware-based solutions like the one which I've reported.

In fact, I prefer to have a better PC if I want to improve performances running retroplatforms' code.

I've an Intel Alderlake 12900K for this: I think that my schwartz is bigger than your.

This clarified, care to PROVE your above statement? Because it looks another mystification from you...
Quote:

Quote: That's plainly FALSE! That's plainly FALSE! Refer mmu.libraries and 68060.library's propose. CyberPatcher will trap and emulate any unsupported instructions. Mentioned software support package operates at the OS level. https://www.nxp.com/docs/en/data-sheet/MC68060UM.pdf An IEEE Standard, MC68040- and MC68881-/MC68882-Compatible FPU. The MC68060 is compatible with the ANSI/IEEE Standard 754 for Binary Floating-Point Arithmetic. The MC68060’s FPU has been optimized to execute the most commonly used subset of the MC68881/MC68882 instruction sets. Software emulates floating-point instructions not directly supported in hardware. Refer to Appendix C MC68060 Software Package for details on software emulation. The MC68060FPSP provides the following features: • Arithmetic and Transcendental Instructions • IEEE-Compliant Exception Handlers • Unimplemented Data Type and Data Format Handlers ---- The MC68060 FPU has been optimized for the most frequently used instructions and data types. The MC68060 fully conforms to the ANSI/IEEE 754–1985 Standard for Binary Floating-Point Arithmetic. In addition, the MC68060 processor maintains compatibility with the Motorola extended-precision architecture and is user object code compatible with the MC68881/MC68882 floating-point coprocessors and the MC68040 microprocessor FPU. With the inclusion of the M68060SP, the MC68060 provides MC68881/MC68882-compatible software functions For 68060, unsupported instructions are on the slow path.

Which, as YOU also shown, IT'S PLAINLY FALSE!

Your previous statement: "The 68060 integrates a Floating-Point Unit that is compatible with Motorola 68881 / 68882 co-processors.".

Reality AND your documentation show that THIS IS NOT TRUE! The 68060 requires ADDITIONAL, EXTERNAL support to emulate what Motorola removed.

You're becoming each day more ridiculous. That's why also Karlos makes jokes against you: you're a clown!
Quote:

You can't handle fast and slow instruction path ideology.

Ideology?!? But do you read what you write? LOL

Well, 68080 could handle both fast and slow path. Very low. And WAY BETTER THAN what's required for the 68060.
Quote:

Too bad MC68060 Software Package wasn't below the OS level like on X86-64's microcode firmware updates.

Ask Motorola...
Quote:

X86-64's microcode firmware updates are handled by a micro-coding hardware unit separate from actual execution units. Actual execution units wouldn't be wasting compute resources on the translation/decode stage.

Which has pros and cons.

On my NEx64T I've decide to move to a special millicode execution almost all legacy x86/x64 instructions. I don't want that transistors are wasted on that stuff, which could be much easily handled in (special) software.
Quote:

PiStorm/PI 3a/Emu68's compatibility is below the OS level, hence the emulation is transparent to the Amiga's legacy software. Emu68's bug fixes are done via software updates.

I know it very well (since I'm following the project from long time).

And the point was/is?
Quote:

WinUAE 4.9.x 64-bit edition's FPU emulation has Host 64 bit, Host 80 bits and SoftFloat (80 bit) options. It's the end user's software option to trade performance vs accuracy.

Only recently, as it was reported by Matt.
Quote:

AC68080 V2 FPU has 52 bits. Apollo team hasn't offered 64-bit and 80 bits FPU emulation support for the slow path.

Again, you don't know what you're talking about.

Apollo uses 52 bits for the mantissa. So, excluding the exponent, which is handled separated. So, it's perfectly able to support double precision AKA 64-bit FP data type.

What it's missing is supporting the extended-precision 80-bit FP data type.

Care to (finally) inform yourself BEFORE writing pure bulls*its?

Anyway, 68060 lacks BCD data type. Whereas Apollo's 68080 supports it. Anything that you could says about it?
Quote:

https://www.youtube.com/watch?v=e_ElgKvKFuY Amiga 1200 with 68060 running Mac OS 8.1 via Fusion Mac, and it works fine. 68060 FPU doesn't break Amiga's Fusion software.

Then why don't you show a video of Sculpt 4D / 68020+68882 version running on a 68060? I'm preparing the popcorns...

@Hammer

Hey, quiche eater: when do you stop editing messages AND adding OTHER stuff? Do you understand that people might have already replied to them?

Isn't that difficult to WAIT and COMPLETE your message BEFORE posting it? OR write ANOTHER one with the NEW stuff?

Quote:

Hammer wrote: @cdimauro Quote: Then this CONTRADDICTS your previous statement. The fast and slow instruction path is a hard concept for you.

LOL: how to overturn the reality.

Do you understand that the 68060 has NO "slow" instructions path? What you're talking about?!?
Quote:

Quote: IF and WHEN it's possible. Which is NOT always the case, IF you know how 68K platforms (not only the Amiga) were developed, worked, and maintained. Too bad MC68060 Software Package wasn't placed below the OS level like on X86-64's microcode firmware updates.

And guess what: it made the 68060 INCOMPATIBLE with A LOT of existing software!
Quote:

WHDLoad games are run after AmigaOS is loaded. Unlike AmigaOS 4.x PowerPC's OS level 68K emulation, PiStorm/PI 3a/Emu68's 68K compatibility is below the Amiga OS level, hence the emulation is transparent to Amiga's legacy software. Emu68's bug fixes are done via software updates. PiStorm/PI 3a/Emu68 with my A500 is like a very fast A3000 with RTG. Transmeta's Code Morphing Software is below the OS level. PiStorm32/Pi 4 CM/Emu68's and TerribleFire/Buffee's 68K emulation operates below the Amiga OS level.

But NOT the 68060. Go to Motorola and ask why they didn't provide backward-compatibile processors. No, not only the 68060: I mean ALL processors AFTER the 68000.

And now make a side-by-side comparison between the Apollo's 68080 and ANY other Motorola processor and check what they provide. Then come back here and report which one offers the best compatibility.

@cdimauro

Quote:

Already answered above. Consequences: the 68060 is NOT backward compatibile with existing 68K software...

I have many WHDload games on my A1200/TF1260 that were mirrored from my old A500/A3000 game collection and they work fine. Amiga AGA games run fine on it.

My WInUAE's config mirrors my A1200/TF1260 setup.

My A1200/TF1260 runs WHDload games due to mass storage convenience.

When Amiga has a 68040 or 68060 class CPU, I expected a proper 68K FPU, not some shorted FPU like on AC68080 V2.

Apollo Core 68080 V2 is effectively 68EC080

Apollo Core 68080 V4 has FP64 and still no 68K MMU.

Quote:

This is again a Red Herring: I see that you like a lot this logical fallacy. Logic isn't your friend. But, unfortunately for you, it's my friend, as well as memory. In fact, now I report again YOUR statement,

That's red herring. Reminder, Intel attempted to kill the X86 family with IA-64 Itanium, the second source AMD served as insurance for X86 and it has into X86-64!

Intel Itanium was Motorola's PowerPC-like move.

Motorola 68K does NOT have second source insurance like AMD for X86 world.

Quote:

Fluff? Only because you're NOT able to rebut it.

You can't watch a simple video that compared A1200/68030@ 50Mhz vs AMD 386DX-40/ET4000AX playing Doom.

Quote:

I've to recall you that YOU've stated that the AGA is able to do FULL MOTION (so, 25 or 30 FPS. At least). Care to PROVE it?

https://youtu.be/afyCn6m2Qbc?t=42
DOOM on Amiga A1200 + Blizzard 1260's 68060 @ 66Mhz.

You can't watch a simple video.

Quote:

You aren't a reliable source, since you proved to NOT being able to distinguish the differences in the video that you posted yourself. And you'd to resort to someone else's comment. Which is like you, of course: unable to see the differences. Not because there aren't differences, but because you, both, are NOT able to catch them.

I dumped my 386DX+ET4000-based PC a long time ago before retro gaming.

I only entered retro gaming due to the COVID-19 lockdown and I'm not yet an extremist retro gamer. My oldest PC collection is a Pentium II Slot 1-based PC being stored in my garage.

https://youtu.be/KQDEKoRcXZc?t=102
i386DX-33 + ET4000AX running Doom.

Watching youtube videos is too hard for you.

Your personal attacks on me are red herrings.

Last edited by Hammer on 13-Aug-2022 at 08:10 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)

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Already answered above. Consequences: the 68060 is NOT backward compatibile with existing 68K software... I have many WHDload games on my A1200/TF1260 that were mirrored from my old A500/A3000 game collection and they work fine. Amiga AGA games run fine on it. My WInUAE's config mirrors my A1200/TF1260 setup. My A1200/TF1260 runs WHDload games due to mass storage convenience.

Sure. SOME software works, but not ALL.
Quote:

When Amiga has a 68040 or 68060 class CPU, I expected a proper 68K FPU, not some shorted FPU like on AC68080 V2.

I expect that a proper 68K processor has not problem executing ALL software which was developed BEFORE it was sold.

This is the meaning of backward-compatibility, which Intel followed and it's famous for.

But which lacked with ALL Motorola processors after the 68000.
Quote:

Apollo Core 68080 V2 is effectively 68EC080

FALSE again: it runs all 68K software which also uses FPU instructions. And it does it even with software which kills the o.s..

Care to prove that ANY other Motorola's 68K processor is able to do it?
Quote:

Apollo Core 68080 V4 has FP64

Hey, you improved here. Unbelievable.
Quote:

and still no 68K MMU.

Please, tell me WHICH ONE it should implement, since ALL Motorola's one are incompatible each other.
Quote:

Quote: This is again a Red Herring: I see that you like a lot this logical fallacy. Logic isn't your friend. But, unfortunately for you, it's my friend, as well as memory. In fact, now I report again YOUR statement, That's red herring. Reminder, Intel attempted to kill the X86 family with IA-64 Itanium, the second source AMD served as insurance for X86 and it has into X86-64! Intel Itanium was Motorola's PowerPC-like move.

Your usually useless padding.

But, again, you're miserably trying to change the topic and NOT proving your bullsh*t about the POWER4 and PowerPC 970. That's because you're a complete ignorant about the argument!
Quote:

Motorola 68K does NOT have second source insurance like AMD for X86 world.

Again, you don't miss any opportunity to show your ignorance.

Because, yes, Motorola had second sources for its 68K family. It's ONLY YOU that do NOT know it, because you're ignorant.
Quote:

Quote: Fluff? Only because you're NOT able to rebut it. You can't watch a simple video that compared A1200/68030@ 50Mhz vs AMD 386DX-40/ET4000AX playing Doom.

Ah, no? And then please tell me: why you've posted a video that actually... shows it?!?
Quote:

Quote: I've to recall you that YOU've stated that the AGA is able to do FULL MOTION (so, 25 or 30 FPS. At least). Care to PROVE it? https://youtu.be/afyCn6m2Qbc?t=42 DOOM on Amiga A1200 + Blizzard 1260's 68060 @ 66Mhz. You can't watch a simple video.

Then DO NOT POST IT!
Quote:

Quote: You aren't a reliable source, since you proved to NOT being able to distinguish the differences in the video that you posted yourself. And you'd to resort to someone else's comment. Which is like you, of course: unable to see the differences. Not because there aren't differences, but because you, both, are NOT able to catch them. I dumped my 386DX+ET4000-based PC a long time ago before retro gaming.

Who cares.
Quote:

I only entered retro gaming due to the COVID-19 lockdown and I'm not yet an extremist retro gamer. My oldest PC collection is a Pentium II Slot 1-based PC being stored in my garage.

Usual padding...
Quote:

https://youtu.be/KQDEKoRcXZc?t=102 i386DX-33 + ET4000AX running Doom. Watching youtube videos is too hard for you.

LOL: talks the one which isn't able to show the differences on the video that he posted.

And, please, tell me: why you continue to post videos to me, since I'm supposed to not being able to watch them?
Quote:

Your personal attacks on me are red herrings.

You don't even know the definition of red herring.

Nothing new, since, as I've already said, you proved several time that you're an ignorant.