ZORRAM

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK

@MEGA_RJ_MICAL

Thanks for bringing us back on topic!

@xe54

Promises are pointless when PiStorm+Pi3a (or Pi Zero 2W)+Emu68 (more than 800 MIPS) is delivering 68K CPU acceleration beyond AC68080 and 68060 @ 100Mhz.

I paid about $150 AUD (or ~$104 USD) for a pre-configured PiStorm+Pi3a+32GB microSD combo.

A500 with PiStorm setup has zoomed past the A1200+TF1260 setup.

Unlike PowerPC-based neo-Amigas, both A1200 and A500 hardware platforms are not limited by a single or narrow set of CPU SKUs e.g. SAM440ep, SAM460ex, and AmigaOne XE are dead-end products nearly like any Android mobile phones.

I prefer any new Amiga hardware platform to duplicate A1200's expansion capabilities i.e. Commodore designed A500/A1200 to be expandable.

Last edited by Hammer on 04-Aug-2022 at 03:46 AM.
Last edited by Hammer on 04-Aug-2022 at 03:45 AM.
Last edited by Hammer on 04-Aug-2022 at 03:43 AM.
Last edited by Hammer on 04-Aug-2022 at 03:42 AM.
Last edited by Hammer on 04-Aug-2022 at 03:34 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)

@xe54

FYI, the Framework ultrabook is not limited to a single X86 CPU generation since the end-users are able to swap out the 11 gen Intel mainboard with a 12 gen Intel mainboard while recycling the rest of the ultrabook framework.

Framework has a static ultrabook mainboard form factor design i.e. delivering the PC's static "ATX" standard form factor for the PC ultrabook.

Last edited by Hammer on 04-Aug-2022 at 03:57 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:

FYI, Windows 11 X64's APCI X64 HAL is supplied by Microsoft.

Of course they did.

Quote:

The original year 2009 Windows 7 build still boots, installs, and works on July 2019 era AM4 X570 motherboard. AM4 socket and X370 chipset-based motherboards were released in September 2016. ACPI firmware assures compability with Windows NT ACPI HAL target. ...

That's because, over the years lots of businesses have had lots of money tied up in legacy software that's critical to their operations. Therefore there's been a lot of motivation for computer companies to maintain a high level of backward compatibility. It makes it easier to convince said business customers to buy new hardware if their old stuff will still run on it. Hence, we end up with x64 CPUs that still start in 16-bit 8086 mode, enabling compatibility with software written before some of us were even born.

None of that changes the fact that, every time new hardware that isn't backward compatible is released, someone has to write the HAL code to make it work. For example, graphics cards come with a VGABIOS/UEFI ROM for that very reason, and someone wrote the code that resides on the ROM.

Likewise, someone also had to write the Compatibility Support Module (CSM) for UEFI to enable pre UEFI OSes to boot on a modern machine.

Guess who has to do all that work with AmigaOS 4.x machines...

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@xe54

Quote:

Thanks for bringing us back on topic!

Aaaaaaand, we're back off topic.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@billt

yes aros running for more time on laptop x64 but the best choice is an desktop computer, on many laptop aros run in vesa mode

_________________
Patreon

@Hans

Quote:

That's because, over the years lots of businesses have had lots of money tied up in legacy software that's critical to their operations. Therefore there's been a lot of motivation for computer companies to maintain a high level of backward compatibility. It makes it easier to convince said business customers to buy new hardware if their old stuff will still run on it. Hence, we end up with x64 CPUs that still start in 16-bit 8086 mode, enabling compatibility with software written before some of us were even born. None of that changes the fact that, every time new hardware that isn't backward compatible is released, someone has to write the HAL code to make it work. For example, graphics cards come with a VGABIOS/UEFI ROM for that very reason, and someone wrote the code that resides on the ROM. Likewise, someone also had to write the Compatibility Support Module (CSM) for UEFI to enable pre UEFI OSes to boot on a modern machine. Guess who has to do all that work with AmigaOS 4.x machines...

FYI, Intel's dictated UEFI Class 3 X64 has removed CSM, hence the oldest OS for UEFI Class 3 motherboards is the year 2005-era Windows XP X64 UEFI.

UEFI Class 3 doesn't start up with 16-bit 8086 real mode.

Current AM4 B550/X570 motherboards are UEFI Class 2 that still includes Compatibility Support Module (CSM).

Intel is the entity that creates UEFI/ACPI baseline design for their motherboard platforms. When Intel says, CSM is not included in the UEFI Class 3 baseline for their motherboard platforms, it will be missing in UEFI Class 3 Intel motherboards across many motherboard vendors.

AMD covers their UEFI/ACPI baseline design for their motherboard platforms. AMD has a UEFI Class 2/ACPI baseline design.

PC BIOS UEFI vendors follow AMD/Intel/MS (Wintel trinity) directions.

2005-era Windows XP X64 UEFI still works with any UEFI/ACPI X64 motherboards such as AMD's X570 and Intel's Z690 chipsets.

Windows XP X64 UEFI and Windows 7/8/8.1 are not aware of AMD's X570 and Intel's Z690 (PCIe 5.0) chipsets and these OS still install, boot, and run. This holds true for AMD's incoming AM5 (PCIe 5.0) X670E/X670 chipsets.


UEFI and ACPI are based on agreed standards from multiple companies. Intel/AMD/MS (Wintel trinity) enforced UEFI/ACPI standards across multiple PC motherboard vendors, PC BIOS/UEFI vendors, and PC OEMs.


Windows UEFI/ACPI build is multi-motherboard vendor/multi-generation chipset compatible and the end user is not dependent on the motherboard vendor.


Compatibility Support Module (CSM) is not a requirement to enable end users the capability to purchase PC motherboards from multiple vendors and across chipset generations while using the same Windows UEFI/ACPI build.


With AmigaOS 4.x and general PowerPC situation, there are specific builds for each "AmigaOne" PowerPC variant, hence after paying for AmigaOS 4.x SAM440ep, this AmigaOS4 build doesn't work on the Raptor Computing's Power9 Blackbird motherboard.


SAM440ep has a dead-end future worst than Commodore's A500/1200 since A500/A1200's CPU acceleration market continues to evolve to include recent and modern ARM CPUs.


With the ARM market, Chinese Pi kitbashed clones such as Banana Pi or Orange Pi have their specific Linux builds, hence they are not Raspberry Pi clones e.g. different GPIO pins behavior.

The net result from kitbashed Pi, Banana Pi, or Orange Pi doesn't work with PiStorm.

Last edited by Hammer on 05-Aug-2022 at 05:57 AM.
Last edited by Hammer on 05-Aug-2022 at 04:51 AM.
Last edited by Hammer on 05-Aug-2022 at 04:46 AM.
Last edited by Hammer on 05-Aug-2022 at 04:43 AM.
Last edited by Hammer on 05-Aug-2022 at 04:38 AM.
Last edited by Hammer on 05-Aug-2022 at 04:32 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)

@xe54

Quote:

xe54 wrote: @MEGA_RJ_MICAL Thanks for bringing us back on topic!

RISC V laptop will not replace X86 PC laptops since that particular RISC V laptop lacks cross-vendor compatibility.

I have experienced buying Chinese Android devices and their Android support life cycle is terrible.

I have many ARM-based Android (Vulkan iGPU capable) devices that are serving as dead-end door stops.

Outside of the X86 PC and classic C= Amiga platforms, I have to learn to compile and modify Linux for specific hardware! Fuk that, I'm a classic C= Amiga user and I dislike the Linux way.

Last edited by Hammer on 05-Aug-2022 at 05:02 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:

... UEFI Class 3 doesn't start up with 16-bit 8086 real mode.

No, but there are x64 CPUs that do.

Quote:

... Compatibility Support Module (CSM) is not a requirement to enable end users the capability to purchase PC motherboards from multiple vendors and across chipset generations while using the same Windows UEFI/ACPI build.

My point was that there's a reason why the x86 line of computers has a long history of maintaining backward compatibility, and a lot of work has been done to make it happen. In no way was I suggesting that Intel & AMD still need to pander to businesses wanting to use legacy 8086 code. I never understood why they've kept 8086 backward compatibility going so long.

Quote:

With AmigaOS 4.x and general PowerPC situation, there are specific builds for each "AmigaOne" PowerPC variant, hence after paying for AmigaOS 4.x SAM440ep, this AmigaOS4 build doesn't work on the Raptor Computing's Power9 Blackbird motherboard.

Yes, we've already been over this point a few times, and neither of us like Hyperion's decision to lock OS distributions to specific hardware. And yes, PowerPC lacks the level of standardization that makes x86 backward-compatibility possible. This includes a lack of uniformity in BIOS/firmware. Multiple variations on UBoot, CFE, OpenFirmware...

Quote:

SAM440ep has a dead-end future worst than Commodore's A500/1200 since A500/A1200's CPU acceleration market continues to evolve to include recent and modern ARM CPUs.

Yeah, I don't see anyone using an ARM processor to try to emulate the Sam440's PPC CPU either.

Quote:

With the ARM market, Chinese Pi kitbashed clones such as Banana Pi or Orange Pi have their specific Linux builds, hence they are not Raspberry Pi clones e.g. different GPIO pins behavior.

Correct, ARM lacks x86-level standardization too.

Quote:

The net result from kitbashed Pi, Banana Pi, or Orange Pi doesn't work with PiStorm.

Not without modification. A good Hardware Abstraction Layer (HAL) would make adapting the PiStorm code to different hardware a lot easier.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

No, but there are x64 CPUs that do.

PCs are categorized as UEFI class 0, 1, 2, or 3. A class 0 machine is a legacy system with a legacy BIOS; i.e. not a UEFI system at all.

A class 1 machine is a UEFI system that runs exclusively in Compatibility Support Module (CSM) mode. CSM is a specification for how UEFI firmware can emulate a legacy BIOS. UEFI firmware in CSM mode loads legacy bootloaders. A class 1 UEFI system may not advertise UEFI support at all, since it isn't exposed to the bootloader. It's only UEFI "within" the BIOS.

A class 2 machine is a UEFI system that can launch UEFI applications but also includes the option to run in CSM mode. The majority of modern PCs are UEFI class 2 machines. Sometimes the choice to run UEFI applications vs. CSM is a one-or-the-other setting in the BIOS configuration, and other times the BIOS will decide which to use after selecting the boot device and checking whether it has a legacy bootloader or a UEFI application.

A class 3 machine is a UEFI system that does not support CSM. UEFI class 3 machines only run UEFI applications and do not implement CSM for backward compatibility with legacy bootloaders.

Regardless of UEFI classes, Wintel trinity enables the end user to be able to select multiple PC motherboards from multiple vendors and across different chipset generations while using the same Windows build under the common "design for Windows" HAL target.


Quote:

My point was that there's a reason why the x86 line of computers has a long history of maintaining backward compatibility, and a lot of work has been done to make it happen. In no way was I suggesting that Intel & AMD still need to pander to businesses wanting to use legacy 8086 code. I never understood why they've kept 8086 backward compatibility going so long.

Real mode 8086 legacy support enables Wintel camp to build its install base instead of being blasted back to ground zero.

Commodore didn't evolve the 65xx CPU family like Intel X86.

The initial purpose for ARM's existence was to overcome Commodore Semiconductor Group's crap 65xx development road map. 😂

Acorn's BBC Micro has 6502/6512 CPU and ARM 1 was later added as a co-processor.

Since Commodore didn't invest in 65xx CPU development, Commodore looked at external CPU technology injection such as Z8000 and 68K, and HP's PA-RISC.

For the Amiga Hombre project, Commodore's weak Amiga R&D investments led to Commodore seeking technology injection from HP's PA-RISC and targeted SGI OpenGL compliance.

Incidentally, HP's PA-RISC existence was due to Motorola's 68K embedded market focus, hence 68K CPU road map exited from the high-performance Unix workstation market. HP was a 68K Unix vendor before switching towards PA-RISC.


Quote:

Yeah, I don't see anyone using an ARM processor to try to emulate the Sam440's PPC CPU either

Refer to Hyperion's revenue for AmigaOS 3.1.x vs AmigaOS 4.x.

Many Amiga users didn't move towards PowerPC.

Quote:

Not without modification. A good Hardware Abstraction Layer (HAL) would make adapting the PiStorm code to different hardware a lot easier.

My use for PiStorm/Pi 3a/emu68 is to accelerate Amiga 500's 68K performance without the crazy prices.

My spending for TF1260 with 68060 was a little crazy.

Atm, ARM is a throw away door stop when Google/Apple stops supporting it. I have a small pile of ARM-based Nexus/Google/Samsung phones.

My 2013 Ipad Air Mini is a glass door stop while a Dell (Core i7) laptop of similar vintage still has working Windows 10.

A simple mod (skips the hardware checks) installed and run Windows 11 on Intel Core i7-3770K Ivybridge-based PC and it works fine i.e. it operated like the current Core i3 equivalent.

In terms of gaming, coupled with cheap secondhand NVIDIA GTX 1660 Super with Core i7-3770K, it's similar to Xbox Series S.

Last edited by Hammer on 06-Aug-2022 at 02:15 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:

My spending for TF1260 with 68060 was a little crazy.

Wouldn't the IceDrake accelerator have made more sense?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

IceDrake wasn't available in Y2020/Y2021 time period while TF1260 was available.

IceDrake has about 553.3 Euros which translates to $815.24 AUD including Aussie VAT (aka GST).

My TF1260 (includes very low-cost 68LC060 Rev4) and 68060 Rev 1 are about $500 AUD, and it was purchased in separate steps.

My preconfigured PiStorm+Pi3a+emu68+32 GB MicroSD is about $155 AUD for A500.


For Y2022, I'm budgeting for AMD's Ryzen 9 7900X (or Ryzen 7 7700X/7800X) AM5 and ASUS ROG Strix X670E and DDR5, hence retro hardware spending has lower limits.

Last edited by Hammer on 06-Aug-2022 at 02:26 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,

I built a Asus X470, Ryzen 7 2700, Radeon Vega 56 8GB graphics and 64 Gig mem. dang thing flies. Browser opens in less than 1 sec.
May be getting old now but the fastest thing I ever saw. But its not a n Amiga, thank God I still have those 2 machines.

Chris

@ans

Quote:

Hans wrote: @xe54 RISC-V's future looks promising.

Definitely: RISC-V is here to stay and gain market, especially on embedded / custom markets.
Quote:

The open-source nature has it's good and bad sides. One potential risk, is that the CPU architecture ends up with as many variants as Linux has distros, effectively killing binary compatibility.

It's not a risk: it's a reality. They started at the beginning with a plan having some extensions on specific fields/areas, and in the recent years they ended-up with several new "sub-extensions" to fix the mistake that they did.

A big mistake is about some compressed instructions, where they have some new proposal to reuse part of them... after that it was ratified and "set in the stone". Which means, that this will cause binary compatibility issues, of course...

Plus, there are already several custom extensions. But since they're custom, there's no problem with binary compatibility. However this further fragments the RISC-V market.


@matthey

Quote:

matthey wrote: RISC-V can scale down very well but I have doubts that it can scale up for competitive performance on desktops, laptops, pads, etc. RISC-V is basically MIPS with a few modern improvements and baggage from mistakes thrown away.

I fully agree.
Quote:

The more open ISA and trend toward open hardware are more appealing than the ISA.

This is the real benefit of this ISA: no licenses issues.


@Hans

Quote:

Hans wrote: It reminds me of when the PowerPC Cell processor came out, and there was some research into into using the Cell cores as a GPU instead of having a dedicated one.

I think that it was just a paper: Cell wasn't suitable at all for replacing a GPU.
Quote:

The PS3 added a proper GPU in the end, and I see that Intel's Larrabee was cancelled. So far, nobody has been able to make it work better than existing GPUs.

At least Larrabee had some fixed-functions parts to help it for competing with GPUs. That's because it was used to compete on that market.
Quote:

Having a dedicated GPU with hardware for texture & vertex fetches, rasterization, etc., is simply faster and more efficient at graphics.**

Exactly.
Quote:

If I were to design a GPU (which I have thought about), I'd probably go for an SIMTish architecture, with each core being as simple and small as possible (which rules out SIMD). I'd try to make the ISA easier to program, whilst still maintaining some sort of sync between adjacent threads like SIMT does.

Designing an ISA for a GPU isn't important nowadays, since they change quite often (compared to CPUs).

What's important is the abstraction language provided by high-level libraries like DirectX, OpenGL, Vulkan, Metal: those are the most important things for developers (which don't know and don't need to know the ISA used by a specific GPU).


@matthey

Quote:

matthey wrote: The Cell CPU didn't have enough SPEs for a high performance GPU. Detaching SIMD units from the integer CPU cores should have allowed for more of them at the expense of more difficulty in programming. Perhaps Cell and Larrabee did not have specialized enough SIMD "GPU" instructions?

Larrabee had them, to help for the rasterization. There should some nice presentation from Tim Sweeny and/or Michael Abrash, talking about it.


@Hammer

Quote:

Hammer wrote: "Design in Germany" Phase 5 and Vampire are not priced competitive i.e. overpriced BMW/Mercedes Benz mentality doesn't work in the desktop computer market.

Overpriced? BMW/Mercedes could be expensive, but certainly not overpriced.

The margin factor is just one digit...


@Hans

Quote:

Hans wrote: My point was that there's a reason why the x86 line of computers has a long history of maintaining backward compatibility, and a lot of work has been done to make it happen. In no way was I suggesting that Intel & AMD still need to pander to businesses wanting to use legacy 8086 code. I never understood why they've kept 8086 backward compatibility going so long.

The only reason is that it's still used. No other explanation is possible...

@cdimauro

Quote:

cdimauro wrote: The only reason is that it's still used. No other explanation is possible...

Or maybe the implemented the last version of that 16Bit support in a way that it can't be removed without damage to some 32Bit stuff still being used.

Or maybe it is just 1ct in transistor real estate and just not worth the hassle to change anything.

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

@Kronos

Quote:

Kronos wrote: @cdimauro Quote: cdimauro wrote: The only reason is that it's still used. No other explanation is possible... Or maybe the implemented the last version of that 16Bit support in a way that it can't be removed without damage to some 32Bit stuff still being used.

If we talk about the 8086 Real mode (THE 8086 ISA), then I can easily exclude it: it doesn't hurt at all 32 or 64-bit (both are "protected modes").

If we talk about the 16-bit protected mode, its libraries and code can be mixed with the ones with 32-bit protected. In fact, 32-bit Windows up to 10 (11 is only 64-bit) can still run 16-bit protected code (it's impossible in 64-bit mode: it can only run 32-bit protected code). So, dropping it could create problems for applications that are still using such code.
Quote:

Or maybe it is just 1ct in transistor real estate and just not worth the hassle to change anything.

Considered that CPU cores nowadays use around hundred of millions of transistors... yes: it's not worth the hassle to remove such legacy stuff.

@cdimauro

Quote:

cdimauro wrote: If we talk about the 8086 Real mode (THE 8086 ISA), then I can easily exclude it: it doesn't hurt at all 32 or 64-bit (both are "protected modes").

I wasn't talking bout 32Bit SW using 16Bit libraries, but about the HW implementation of both being so interconnected that they can't kill one without the other.

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

@cdimauro

Quote:

Quote: The open-source nature has it's good and bad sides. One potential risk, is that the CPU architecture ends up with as many variants as Linux has distros, effectively killing binary compatibility. It's not a risk: it's a reality. They started at the beginning with a plan having some extensions on specific fields/areas, and in the recent years they ended-up with several new "sub-extensions" to fix the mistake that they did.

Absolutely. But this is not a bug, this is a feature. You will have many different extensions developed for different use cases in parallel.
Most of them will be either too nieche to be generally useful or will turn out to not be a good idea once they are implemented in silicon and these features will become a dead-end and die off.
This means greatly accelerated rate of innovation compared to "single thread of development, driven by commite consensus".

But some of these features will turn out to be genuinely useful and then can be folded back into "upstream".

This is similar to how people fork a github project and develop patches / features. Most of these forks turns out to be shit and eventually are forgotten, but some of them are genuinely useful and eventually end up as a pull request to upstream so everyone can benefit from it.




Quote:

Quote: matthey wrote: RISC-V can scale down very well but I have doubts that it can scale up for competitive performance on desktops, laptops, pads, etc. RISC-V is basically MIPS with a few modern improvements and baggage from mistakes thrown away. I fully agree.

I also agree with this. For the primary reason that I do not see any of the current stakeholders having much interest in pushing toward desktop/server class CPUs.
That could change, for example if Apple suddenly decides this should be the basis for their next laptops.

ULTIMATE PADDING

_________________
I HAVE ABS OF STEEL
--
CAN YOU SEE ME? CAN YOU HEAR ME? OK FOR WORK