@Gunnar

There’s plenty “ding dong" in HPC as well, I can assure you.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Trixie

Quote:

Trixie wrote: @Ferry Quote: Because almost ALL software available for Amiga is made for 68k. And the 4350 titles available at OS4depot.net are... what? Note that unlike Aminet, OS4depot refrains from storing media files such as music modules or pictures, so most of the items there are binaries. And while of course not all of them are actual programs or utilities (some are libraries etc.), the number of OS4-native applications goes well over a thousand. No dispute that classic 68K Amigas have waaaaay more; there's absolutely no contest! But the idea that AmigaOS4 has no native applications, and that PPC users have to rely on emulating 68K software, is not based on reality. It would actually take me some time to remember which 68K programs I still use - there won't be many.

I think that the most important information here is if there's any PowerPC software (OS4. MorphOS for the "other side of the Moon") that isn't available for the Amiga OS (so, 68k). Relevant / killer apps, of course: small utilities have more effort than it's worth.
Quote:

Quote: why would anyone buy TODAY a VERY expensive PPC machine to run emulated 68k programs? Exactly, why would they? Because they don't: as I've said above, OS4 has enough native software to get you going. 68K emulation under OS4 is nice when one gets the nostalgia bug from time to time, but it's more like a bonus.

I don't kind that it's a bonus, since some key components weren't ported to PowerPC.

Out of curiosity, have you tried to completely disable any kind of 68k emulation and see if your user experience had/has zero impact?

@Hypex

Quote:

Hypex wrote: @Hammer Quote: FYI, X86-64v4's AVX-512's EVEX encoding has 32 vector registers i.e. zmm0 to zmm31 for AVX-512, ymm0 to ymm31 for AVX-256 and xmm0 to xmm31 for AVX-128. It's met its match then. Things can only get better, as the song goes, but not for PPC. Well now the internal RISC core of x64 has come out of the shell.

There's no "internal RISC core" inside x86/x64 processors: that's an urban legend!

If you want to have more insight about this, you can check my series of articles about the everlasting RISCs vs CISCs dispute:
https://www.appuntidigitali.it/20594/the-final-riscs-vs-ciscs-6-conclusions/
This collects the links to all articles. But, specifically, article #5 clarifies this part.
Quote:

Perfect match for emulating PPC register to register!

Only for SIMD registers. But FPU register's can't be directly mapped. And for (almost) directly mapping the GP registers then you need the future processors which are implementing Intel's APX "extension".

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Seriously? You're so desperate to report a link of any USER which has written a post on Intel's COMMUNITY forum and that has written "AVX-128"? For vendor-neutral, I removed Intel from "128-bit Intel AVX". There is no substantial difference between 128-bit AVX and AVX-128.

I agree here: they both do NOT exist.

Whereas 128-bit AVX INSTRUCTIONS exist, instead.
Quote:

I was also annoyed with Intel's so-called 128-bit SSE with Pentium III when the fuking hardware implementation is 64 bits wide.

Your opinion is irrelevant and, also, non-sense, since a microarchitecture is coming from compromises.

But, what's more important about this: do you know how the Pentium III has implemented the SSE extension? Do you think that it is ONLY 64-bit wide?
Quote:

Pentium IV's so-called 128-bit SSE2 was a 64-bit hardware implementation. The same for K7 Athlon XP.

Same question as above.
Quote:

To remain competitive, both AMD and Intel needed higher clock speeds.

Not correct: it depends on the specific microarchitecture AND on the specific context/scenarios.
Quote:

AMD K8's 128-bit SSE had 128-bit FADD and 64-bit MUL implementation. A no brainer to why K8 AThlon FX has better IPC when compared to Pentium IV EE.

In fact, here comes another of your mistake: only considering the IPC. The IPC CANNOT be used to "measure" the overall performance / "goodness" of a microarchitecture.

Only a combination of the IPC AND the frequency can give some number which COULD have some sense.

That's why the P4, from Northwood on, was performing well: its high frequencies compensated quite well the smaller IPC. And gave solid results on games and, especially, multimedia applications (which were the more mainstream).
Quote:

Intel's 1st trueful 128-bit SSE hardware is with Core 2. AMD's 1st trueful 128-bit SSE hardware is with K10 Athlons. I give credit to PowerPC camp's 128-bit Altivec with truthful 128-bit SIMD hardware implementation.

I don't, because it's totally meaningful. What's important is how a processor performs.
Quote:

Quote: And just for this then the AVX-128 term magically existed, right? Even if there's NO trace, at all, on Intel's and AMD's architecture manuals... AMD was minimizing Zen 1's four 128-bit SIMD units for its AVX2 implementation. AMD's less than transparent bullshit AVX2 support. Zen 1's 128-bit AVX2 units are from Pipedriver's 128-bit AVX2. Hint: Bulldozer's FMA4 instructions still work when the feature check is ignored. I didn't buy AMD's Zen 1 since I had Intel Core i7-7820X Skylake X during this era. AMD's Zen 2 had a 256-bit hardware implementation.

For the same reasons as above, I simply don't care at all because this is meaningless information.

BTW, Skylake X was the first to implement AVX-512 for "more mainstream" products. However, it was NOT "fully 512-bit" (SIC!): strange that you've bought one, since you gross out "partial" implementations...
Quote:

Quote: That's a typical example of "information" which is completely build on/in internet. Which, unfortunately for you, still has ZERO value A full Gracemont SKU like the Intel Core i3 N205 SKU has AVX2 with two 128-bit vector FP/integer pipelines with 3rd vector 128-bit pipeline being integer only. 128b ALU/128b FADD/128b FMA/128b FMUL/AES/FDIV/SHA pipe1. 128b ALU/128b FADD/128b FMA/128b FMUL/AES pipe2. 128b ALU pipe3. Fact: AVX's support does NOT guarantee 256-bit hardware implementation. Read the fine print i.e. the gotchas.

Same as above: irrelevant AND non-sense.
Quote:

Fact: AVX-512 and AVX10.x has feature modes e.g. AVX-128, AVX-256 and AVX-512.

FACT: you aren't able even to READ the information that YOU've shared.

IN, FACT: AVX10.x has NOTHING about AVX-128 and AVX-256 and it only reports information about AVX-512. Guess why: AVX-128 and AVX-256 do NOT exist.

Source: YOUR image AND a pair of AVERAGE glasses...
Quote:

Your less transparent 256-bit AVX argument has ZERO value when attached to a performance debate!

Where's my lack on transparency about AVX? QUOTE ME AND PROVE IT!

I've VERY PRECISELY talked about AVX, which is part of an ISA = Instruction Set Architecture = Architecture (simplified).

MICROARCHITECTURES (I've highlighted if for YOUR benefit) are a COMPLETELY DIFFERENT THING.

In fact, I do NOT mix APPLES and ORANGES. And, what's more important, I perfectly know what's an ARCHITECTURE and what's a MICROARCHITECTURE.
Quote:

Hammer wrote: @cdimauro Quote: There's not a single trace of this or "AVX-256". Guess why: they do NOT exist! They ONLY EXIST ON YOUR MIND! Wrong. https://i.ibb.co/wR75gzd/AVX512-optional-under-AVX10.png This is from the Intel's AVX10 document. Fact: Intel released AVX-512/AVX10.x feature matrix. AVX-512 is not guaranteed on Intel platforms.

FACT: you don't understand why Intel presented AVX10.
Quote:

My AVX-128 (128-bit AVX) and AVX-256 (256-bit AVX) usage refers to the hardware implementation.

Oh, finally you've admitted it: yes, it's YOUR usage! YOU invented this term for YOUR OWN benefit!

However, and as I've tried to say already multiple times, you're CONFUSING the part of an ISA with its implementations.

AVX = ISA = Architecture.

With AVX-128 and AVX-256 YOU pretend them to be ISA = architectures whereas, again, YOU (and ONLY YOU!) are also talking about MICROARCHITECTURES using the same terms. So, MIXING two DIFFERENT things.
Quote:

It's foolish to trust the "256-bit AVX support" feature tickbox marketing.

It's foolish or stupid to do NOT understand that there's no "256-bit AVX support and no features matrix.

In fact, AVX was, is, and will ALWAYS be an Intel's SIMD extension which widened the existing SSE registers to 256 bits. WHATEVER were, are, and will be its implementation. Yes, it's ALWAYS 256 bits.
Quote:

Quote: Why he should? AVX-512 had no 16 registers version: it has only 32 registers. Do you support the claim that AVX-512 has 16 registers? This is a minor mistake.

How could you think that I support something like that when I've already stated that AVX-512 is ONLY using 32 registers? Where's the mistake on just reporting an OBVIOUS FACT?
Quote:

Quote: And his processors are NOT x64 compatible. They are (mostly) 68k compatible. ! And?

And it's IRRELEVANT, as I've already stated. 68080 has nothing to do with any Intel technology, despite the AMMX term that it was adopted (just for marketing reasons: MMX is a very well known technology).

@Hammer

Quote:

Hammer wrote: @Gunnar Quote: Do you think that the Amiga users in this forum like your irritating off-topic x86 and non logical copy-pasted posts from wikipedia? This topic is about PPC vs the world i.e. alternative CPU instruction sets. I'm on topic and you're not on topic.

You just copied some stuff from the web. Stuff that was not needed according to what was already written at the time.


@Gunnar

Quote:

Gunnar wrote: @Hammer Maybe it helps to look at Sprites and Vector instruction to visualize this better. If your hardware supports 8 sprites each 16 pixel width. And you upgrade this that your sprites support 8 sprite of 128 pixel width. Then YES this help a few games. Some games can use a 128 pixel monster sprite. But many games use sprites for small items like bullets. So having more sprites instead wider ones - will help more games.

Well, I've to admit that's unbelievable reading this from you, when you've written the exact opposite on the other thread for supporting the not-so-much-useful 64-pixels wide AGA's sprites.
Quote:

The same is true for Vector code. There are some algorithms benefit from wider vectors. But many algorithm do not. And for them having more small instruction would be MUCH better. Or making your instructions "stronger" like adding more colors to your sprite..

But you can also have both wider SIMD/vectors AND more small instructions.

As well as more sprites using more colours.
Quote:

You wonder why INTEL upgrades this like crazy? Why do INTEL and IBM follow here different strategies? Maybe this is because they have different customers? The customers buying IBM super computers - are educated computer experts. They understand the math and logic of vector units. How about INTEL customers? Many INTEL customer look for paper numbers so that they can boost in online forums: "my 512bit ding-dong is longer than your 128bit ding-dong"

And here, unfortunately, you completely derailed.

Intel and IBM have overlapping markets. At least, Intel is looking for almost the same market which is targetting IBM. In fact, they are both focused on high-performance computing.

How many supercomputers are Intel-based and how many are IBM-based? What's the high-performance market share for Intel and for IBM?

I don't think that those questions require answers, right? They should be obvious.

That's the reason why on this area "my 512bit ding-dong is longer than your 128bit ding-dong" MATTERS. A LOT. Despite what you claim.

And that's the reason why not only Intel, but other processors vendors have embraced the "bigger vectors" companion: Fujitsu with its #1 in the TOP 500 supercomputers with its ARM/SVE2 512-bit implementation is the most notable example. SiFive for its RISC-V 512-bit high performance implementation as another fresh one.

So, yes: SIZE MATTERS.

However this isn't just a recent trend. Look at this very old study:
https://militaryembedded.com/radar-ew/signal-processing/avx-leap-forward-dsp-performance

Since the doubling to 256 bits, AVX registers can hold twice as many integer or floating-point values as the 128-bit AltiVec and SSE implementations.
[...]
The PPC 7400 processors, and later Intel processors with SSE, were able to perform eight simultaneous floating-point operations per clock cycle. By doubling the register size to 256 bits, AVX fits eight 32-bit values into each register, enabling 16 floating-point operations per cycle. This effectively, in one fell swoop, doubles the peak performance.
[...]
Intel has published direct SSE versus AVX comparisons with benchmarks run on the same second-generation Core i7 processor with FFT performance improvements ranging from 1.2 to 1.8x.
[...]
These results underline the significance that doubling the raw performance of a floating-point machine holds for DSP applications.
[...]
When Intel upgraded the SSE instruction set for AVX, they rearchitected it and made it more easily extendable. This leaves the door open for easier transitions to even larger registers and keeps Intel’s processors competitive as new alternatives for DSP – such as General Purpose Graphics Processing Units (GPGPUs) – begin to emerge.

It doesn't deserve further comments...

@Trixie

Hmmm… Maybe I missed it last time I checked it: is there any DTP program available, in the like of PageStream or Professional Page? The last word processor I knew was AbiWord, and was not "native", it needed AmiCygnix.

And I stopped using my A1 for accessing my bank pages and any other modern web page because it couldn't, there are not really capable web browsers, maybe I missed their updates and now they are. 🤷��♂�

Saluditos,

Ferrán.

_________________
Amiga user since 1988
AOS4 Betatester
Member of ATO Spain
A1 Cfg
OS4 SCR
A1200

@cdimauro

Quote:

By doubling the register size to 256 bits, AVX fits eight 32-bit values into each register, enabling 16 floating-point operations per cycle. This effectively, in one fell swoop, doubles the peak performance.

This is a peak only.

More important is the combination of all factors
- how strong are your instructions
- what limitations do the instructions have
- how many bytes can you load / write to memory per cycle
- how many bytes can you load / write to data-cache per cycle

You can increase the number of flops you do in 2 ways.
1) double the width (this has a major drawback!)
2) double the number instructions per cycle you do

Doubling the width has the drawback that not all algorithms benefit from it.


Think of it like sprites

What is better 1 Sprite Channel with 128 pixel
Or 2 sprite Channel each 64 pixel
Or 4 sprite Channel each 32 pixel.

Which architecture is more flexible/ Which is better?

@ppcamiga1

https://www.youtube.com/watch?v=MqiEQtzGk-Q
https://github.com/shanshe/Z3660/tree/main
This is a 68060-based Z3660 accelerator card for C= A3000/A4000 with a difference.

This Z3660 accelerator card also supports MYIR Tech Z-Turn SBC (small board computer) powered by AMD's Xilinx Zynq-7010/Zynq-7020 FPGA SoC with dual-core ARM Cortex-A9 Processor @ 667 Mhz.

MYIR Tech Z-Turn SBC's low-cost concept is similar to Raspberry Pi SBC.

This accelerator supports Linux-hosted 68040 CPU emulator on ARM Cortex-A9 Processor @ 667 Mhz
SysSpeed benchmark
MIPS: 1550.56
MFLOPS: 139.7
Supports RTG and AHI.

SysInfo's FPU detection is confused. This is another ARM-based 68040 emulator for the C= A3000/A4000. This opens the door for further ARM-based pathways for the A3000/A4000.


For comparison from C= A1200's PiStorm32 Lite / RPi 4B (ARM Cortex A72 @ 1.8Ghz) / Emu68 (bare metal hypervisor 68040 emulator). SoC from Broadcom.
SysSpeed benchmark
MIPS: 3648
MFLOPS: 3635.

"Computers For The Masses, Not The Classes".

It's too bad it's not NXP Freescale's ARM SBC.

Last edited by Hammer on 16-Mar-2024 at 09:55 AM.

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

@cdimauro

Quote:

You just copied some stuff from the web. Stuff that was not needed according to what was already written at the time.

So what.

Again, this topic is about PPC vs the world.

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

@cdimauro

Quote:

I agree here: they both do NOT exist. Whereas 128-bit AVX INSTRUCTIONS exist, instead.

"AVX 128" terminology exists across many forums, not just this one.

Intel forum moderators don't attempt to correct "AVX 128" since they know it refers to the "128-bit AVX" feature i.e. it's shorthand.


https://accserv.lepp.cornell.edu/svn/packages/fftw/simd-support/simd-avx-128-fma.h
"AVX-128" term is used.


https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1421121 (IBM)
AVX-128 term is used.



During the AMD Bulldozer presentation, AMD used the "AVX 128" term.
PDF copy from https://naic.nrao.edu/arecibo/phil/software/amd/AMD_6200cpu_hpc.pdf


https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/6
AVX 128-bit term is used by Dr. Ian Cutress.


https://forum.beyond3d.com/threads/digital-foundry-article-technical-discussion-archive-2015.60515/page-31#post-1836452
Sebastian Aaltonen (sebbbi) programmer for these games https://www.mobygames.com/person/226323/sebastian-aaltonen/
AVX128 term was used by Sebastian Aaltonen.

This Beyond3d forum's topic discussed the performance regression with AVX-256 on AMD Jaguar! AMD Jaguar CPUs were the baseline for game consoles for Xbox One and PS4.

https://accserv.lepp.cornell.edu/svn/packages/fftw/simd-support/simd-avx-128-fma.h
AVX 128 (e.g. _avx_128_fma) term was used for FFTW open-source software.


Your register-level argument hides the real performance.

Intel's Gracemont E-Cores have inferior game performance, hence the need for Intel's Thread Director.

Your AVX register-only argument has been wreaked by Intel's Thread Director.

Your argument is not transparent when associated with performance.

It's a clown show when you argued that 256-bit AVX is a win when Intel does NOT guarantee 256-bit hardware implementation for Intel's current-gen SKUs with E-Cores.


It's too bad for you, Intel released the AVX-512/AVX10.x feature matrix table that divides 128-bit, 256-bit, and 512-bit feature sets.

Last edited by Hammer on 16-Mar-2024 at 11:19 AM.
Last edited by Hammer on 16-Mar-2024 at 10:42 AM.
Last edited by Hammer on 16-Mar-2024 at 10:27 AM.
Last edited by Hammer on 16-Mar-2024 at 10:23 AM.
Last edited by Hammer on 16-Mar-2024 at 10:20 AM.
Last edited by Hammer on 16-Mar-2024 at 10:16 AM.

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

@cdimauro

Quote:

cdimauro wrote: There's no "internal RISC core" inside x86/x64 processors: that's an urban legend! If you want to have more insight about this, you can check my series of articles about the everlasting RISCs vs CISCs dispute: https://www.appuntidigitali.it/20594/the-final-riscs-vs-ciscs-6-conclusions/ This collects the links to all articles. But, specifically, article #5 clarifies this part.

Counter https://arstechnica.com/features/2005/02/amd-hammer-1/5/ for AMD's K8 Hammer.

https://archive.arstechnica.com/cpu/1q00/g4vsk7/m-g4vsk7-1.html
The G4 and the K7: an architectural look at two post-RISC processors.

No modern X86 CPU microarchitecture implements old-school multi-variable instructions within the CPU's execution pipelines.

Last edited by Hammer on 16-Mar-2024 at 11:20 AM.
Last edited by Hammer on 16-Mar-2024 at 11:09 AM.
Last edited by Hammer on 16-Mar-2024 at 11:05 AM.
Last edited by Hammer on 16-Mar-2024 at 11:02 AM.

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

@Gunnar

Quote:

Gunnar wrote: So your goal is walls of text wikipedia posts was "bash" PPC for using 128Bit Altivec? But is your argument maybe flawed?

Don't assume.

Quote:

Background: Vector instructions help to improve performance for a some use cases.

3D with pack math FP32 usecase. 3D games?

Quote:

Most important here are the "features" of the instruction - what operation can it do? And also very important are what limits does it have - e.g. can they work only on certain alignments? 2nd comes how many instructions can I execute per cycle / per second And how does this work in correlation with my Data Cache troughput and memory transfer rate. While advertising with e.g 1024 bit vector registers looks very nice on paper - and can easily fool children - But if the CPU loads only 64bit from Data-Cache per cycle - or only can push 8 byte per cycle to memory. Then in most real world use cases this is a totally unimportant number- And is only nice on paper!

PowerPC G4's 128-bit Altivec faithfully implements 128-bit SIMD hardware, but X86's Ghz race focus on higher clock speed has benefits for improving legacy software's performance.

PowerPC G4/PowerPC 970 had other performance issues when running Quake 3.

Apple's software base needs additional developer effort for Altivec support.

Pentium III's SSE 64-bit hardware implementation with 128-bit SSE instruction set prepares the transition for the eventual Core 2's SSE 128-bit hardware implementation.

Intel had the 128-bit SSE marketing with Pentium III (hidden 64-bit SIMD implementation) to beat AMD's 64-bit 3DNow instruction set and its 64-bit SIMD implementation.

IBM didn't support Altivec until PowerPC 970 and POWER6 generation while AMD's K8 has SSE FADD 128-bit implementation.

Intel Core 2's release wasn't a barren wasteland with near zero SSE-128 3rd party software support and Intel had the original Xbox game console contract to set the baseline for PC gaming.

AMD's K8 SSE-128 FADD implementation exploited Intel's earlier Pentium III SSE work and it was used against Pentium IV. Intel returned the serve with Core 2's quad instruction issues per cycle, 128-bit FADD, and 128-bit FMUL implementation. AMD mess-up K10 with three instruction issues per cycle with 128-bit FADD, and 128-bit FMUL implementation. AMD mess-up again with Bulldozer. Zen 1.x was supposed to be after K10.

DirectX3D layers have 3DNow and SSE support.

The current wide instruction sets are from GpGPU's MIMD instruction set.

GpGPU and AVX-512 Icelake are useful for AI-related workloads. I have done some OpenAI on transcribing many hours' worth of lectures for the usual non-profit organization. Two RTX 3080 Tis were heavily used for the job. The gaming GpGPUs were useful. I didn't use my RTX 4090 and RTX 4080 since I use them for modern games and Blender 3D.

1024 bit SIMD vs MIMD. I rather use MIMD for the mentioned use cases.

Intel is chasing after Microsoft's Xbox 2027 contract.

APUs (with integrated GpGPUs) are part of the modern baseline PC and smart mobile phone landscape.

The Amiga is mostly about games and the pro-software that supports it, not embedded markets.

Last edited by Hammer on 16-Mar-2024 at 12:30 PM.

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

@Hammer

GUNNAR:
Quote:

So your goal is walls of text wikipedia posts was "bash" PPC for using 128Bit Altivec? But is your argument maybe flawed? HAMMER

Don't assume.[/quote]

I was just polite.


That you not understand Amiga hardware - is a fact.

You mix up CPU benchmarks with Amiga DMA bandwidth
and based on this you make false claims.

Every time someone corrects your mistakes ...

You try to drown the topic

with copy and paste 100 lines from wikipedia without context and without relation.

@BigD

Quote:

My friends A1200 had a underbelly exposed 3.5" HD balanced on the shielding for years with the case gaping open!

Ouch!

@cdimauro

Quote:

Absolutely. "Computer for the masses, not for the classes".

IIRC that slogan was from the pre-Amiga Jack era. The Amiga was too expensive. The C64 was about half or less in price and that was considered expensive in some market segments.

Quote:

Eh! Wasn't the Amiga the land of DMAs everywhere? Who created the EIDE interface seems to have forgotten it...

It was as far as I knew. The interface for A590 even looked better despite the age. But, I always wondered, even if the interface wasn't DMA capable couldn't they have added a buffer that cached the data in the background so 256 bytes or close could be transferred at once? Or even add a cache and some hardware interface that did the dirty work then could DMA when a block was complete. I know, it would have been more complex, but in the A590 example they already had adapted ATA or XT interfaces to Amiga. Though unsure now if XT drives uses DMA in Amiga interface.

Quote:

Well, the problem was the cost / size. That's the exactly the reason why many people mounted a 3.5" hard drive on their A1200s, so making it competitive with PCs. BTW, I've bought a 540MB Quantum short after the 1200, because a HD was really needed at the time, even for Amigas.

PCs also had more space usually, be that desktop or tower. An A1200T would have been a big seller reckon. Of course that stepped into A4000T territory. But a tower variant could have suited a middle segment that accepted 3.5" drives right out of the box. Or tower. My Quantum may have been 540MB actually. And yes, space was needed. I went from a 20MB A590 to 40MB A1200 and soon after, knowing what would happen, upgraded to more storage.

Quote:

Absolutely! I really enjoyed it: completely changed the way to use a computer. Floppies? Stone Age technology...

I backed up my 20MB A590 to floppy disks. Then needed to move the 40MB along. Fortunately CDRWs came along.

Quote:

Up to you. The A1200 had already enough space for fitting plenty of 3.5" which had a power consumption compatible with its power supply. It was nice, really!

I ended up in another direction. While upgrading my A1200 with CD drive an Amiga dealer gave me a solution. A SCSI Tower of Power with Ferret SCSI and SCSI CD drive. It was an ugly tower. But I added SCSI HDD and eventually external SCSI Yamaha CDRW.

@kolla

Quote:

Yes, there is AHI, much to Gunnar’s dismay, as he prefers asm coders that bang the hardware directly.

A good driver will bang the hardware itself while supporting all the hardware features.

@Hammer

Quote:

AmigaOS 4 has 3rd party CIAgent software which is a CIA emulator. http://os4depot.net/index.php?function=showfile&file=emulation/misc/ciagent.lha

Yes. I know about that. I wrote it.

Quote:

This function should be included out of the box.

It should be. So we need less hacks. But what they left in is the timer.device. Apart from parallel and serial the most common use of CIA is timers. Perhaps a "cia.device" would have been better in the original OS or even fully abstracting away the hardware in the CIA resources. It gave permission to bang the hardware. But so was Paula. There's no easy way out.

Given the Draco had CIA and Amithlon also emulates it shows how entrenched it was in the OS being tied to the hardware.

Quote:

PowerPC 60x on classic Amigas are dead-end route since Phase 5's PowerPC accelerators are not being manufactured nor is it open-sourced for uncontrolled clones. The strength of PiStorm and PiStorm32 Lite is the clone hardware and low-cost PRi 3A/3B/4B/CM4 via the economies of scale.

They tended to lack competition. We had the kernel wars. But where were other PPC accelerators? WarpUP gained traction and placed it self as a de facto standard. So it would have been quite possible for another PPC card to be produced using WarpUP as kernel. Sonnet cards, non Amiga PPC cards, demonstrate this possibility.

Quote:

Phase 5 didn't design a generic barebone PPC small board module like RPi and a separate gateway board specific to an Amiga model. The generic PPC small board module should be able to operate on its own via Linux.

There was APUS Linux. This idea looks suitable for embedded PPC. Which did come and may have helped with a PPC SBC design.

https://linux-apus.sourceforge.net/

RPi didn't copy PC's ATX standard and innovate its barebone and low-cost standard.
Quote:

RPi didn't copy PC's ATX standard and innovate its barebone and low-cost standard.

No, but an RPi is even smaller than a mini ITX. Though it wasn't designed as a mini PC. But now it's picked up there's some demand for that sort of thing.

@Hypex

Quote:

A good driver will bang the hardware itself while supporting all the hardware features.

What defines AMIGA?
Is it how it was coded?
Is it how the Amige inventors teached people how to code it?

If you read and understand the Amiga hardware reference manuals
What is the philosophy that the Amiga engineers teach you?

This is very clear to answer and there is no doubt.

But the Amiga inventors explicitly encourage you to directly code the hardware.
And they teach you how to do this the best.

Read the hardware reference manuals than you will agree to this.
Coding the hardware is the Amiga way the Amiga engineers encourage you to code!

Do you not like this?
You can like what you want - but this does not change the fact that coding the hardware
was always part of Amiga spirit - and encouraged by the fathers of the Amiga.

Why do you want to forbid people from using the Amiga the way the fathers of the Amiga envisioned it?



My position is very simple:
Code how you like, if you want to user drivers then use drivers.
if you want to code the hardware, then code the hardware.

Both was allowed on Amiga, and think people should have the right do code how they like.

Last edited by Gunnar on 16-Mar-2024 at 04:17 PM.

@Gunnar

Quote:

Phase 5 didn't design a generic barebone PPC small board

Is the Efika not exactly this?

@Gunnar

Quote:

with copy and paste 100 lines

Please, I’m getting drunk!

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC