@kolla

I think "quake enabler" is a bit unfair. You should only expect problematic results from software dependent on double or extended precision. How do old raytracing applications fare, for example?

_________________
Doing stupid things for fun...

@cdimauro

Quote:

Two pixels is already a very good result, however we're talking about a 160x200 (or 256) screen.

That is. About the closet to 1x1 there is with copper. I've read that the ECS copper was based on a trick that enabled 7 bitplanes that caused a side effect it used since only 6 exist. Sounds a bit hacky. But, on AGA the trick doesn't work, likely because a 7th (and 8th) bitplane does exist. So it must be worked around by using sprites. Somehow, even though the copper is said to be the same speed on AGA, a combination of tricks enable a copper list to change colours every two pixels across. Though, it must be worth it to be used as much as it is, because it seems somewhat complicated to go to all that effort. Especially given a copper chunky cannot be a direct framebuffer regardless, but I wonder how complex the pixel organisation is. It would offer 12-bit true colour (better than HAM6) but at the cost of lower resolution, no 24 bit ability and somewhat odd placement of pixel offsets.

Quote:

If I've understood correctly, you're changing the two scroll values of even and odd bitplanes, but when just using a single playfield. So, yes: this cannot be simulated with packed graphics.

Hooray! Yes that is what I meant. I've long suspected I have communication issues and doubt anyone can understand any instruction guide I have ever written.

Did you say previously packed can do it exactly the same?

Quote:

Unless you define the even bitplanes to show an 8 (or 16, with AGA) colors screen, and then using the odd bitplanes for another 4/8/16 colors "screen" that it's used to simulate transparencies (with a proper palette).

That would be cool to simulate another screen effect. I could be off the mark here. But I thought it might have been used as a cheap trick like this in State of the art.

https://youtu.be/WbVMJPh9i5Q?t=67

Quote:

Hardware scrolling is useless in this case, since you've to redraw the entire screen each time.

Yes I expected that.

Quote:

However it can and should be used to move the framebuffer, since in this case the game area is (supposed to be) much larger then the screen size.

A screen flipping trick. In ADoom, it does a similar to change screen on RTG. Adjusts vertical scroll offset to flip screens.

Quote:

No, it's like when you've to draw a BOB. Only that, instead of rendering with a usual cookie-cut routine (adapted, in case of packed-graphics), you just call the routine which is taking care of rendering the specific sprite. The route execute regular processor instructions that will access the framebuffer and changing it according to how the compiled sprite should be rendered.

Okay. So can this work with parallax layers? Or is it only suitable for one layer? Given the framebuffer would have the final composition.

Quote:

Not exactly an alpha channel, rather a sequence of zeros or ones, where the sequence has the same screen depth. Then you can use the order boolean operators to apply this mask.

I meant now days we have ARGB where any opacity is included in the pixel value as opposed to being separate to the pixels like a mask is.

Quote:

Well, you had 6 bitplanes in EHB, right?

Yes it did. Fusion Paint could have used it.

It may have diminishing returns up to 8 bitplanes so would need the right palette. As well as diminishing the speed. Then again EGA and family was based on RGB with intensity.

Quote:

However there's not enough space & transistors on OCS. That's why a 7 and 8-bit EHB mode, using 8 bitplanes, cut still using a 32-bit CLUT, would have been a very good compromise.

If it was fast enough yes.

Quote:

As I've said several times, AGA was an HORRIBLE patch over ECS.

Some of it was fine. But other things were expanding an old design. May have helped if the 68020 was used in the beginning with a fully 32-bit design. But of course the cost would have jumped too much. However the original design looks very 16-bit which made it harder for a 32-bit upgrade. The best way to update would be a fully 32-bit design but then it would have no compatibility. Also I thought the palette should have had a pointer of it's own in chip ram. All other graphic elements were in chip so to me it made sense. Like all else it could have read it all on screen refresh. A copper list sets palette anyway in common copper lists and that's in chip ram anyway so why not stick the whole palette in chip directly? Could have allowed custom screen modes with 1x1 chunky for real at 24-bit depth.

Quote:

For the processor it wouldn't have changed much: it had to sequentially program those Blitters and wait until the finished their respective jobs.

It was too single threaded when most blits needed multiple passes to complete.

Quote:

So, having multiple Blitters is, effectively, totally useless.

That's what I would have concluded. One faster blitter that had some ability to blit multiple planes would be better. Source is easy enough, since planar data can be in order, it just a destination where planes are spread about that would have needed a way to deal with it.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: First, the usual non-sense / off-topic Hammer's PADDING. Second, I already know it. Third, it's a motherboard issue: it can happen on for boards for any processors. Whereas using the ASMedia chipset for the additional USB ports on AMD's Ryzen processor isn't an issue, but a proper decision decision which let several people experience issues with USBs due to the well know bad implementation of this chipset. You started the off-topic AMD vs Intel debate, hypocrite.

Actually it was YOU, looking at the strict sequence of comments written here.
Quote:

The USB disconnection issues have been resolved with AGESA 1.2.0.2 update.

Finally (and hopefully).
Quote:

My ASUS ROG Strix 570-E, Strix X570-F, and Gigabyte X570 UD motherboards are at AMD AM4 AGESA V2 PI 1.2.0.6b. Motherboard's software makes firmware updates easy. Windows Update service also supplies P-Core/E-Core CPU driver and Intel microcode updates that include Intel Alder Lake CPUs.

Hammer's PADDING...
Quote:

I'm not against good aftersales support.

Me neither. So, what?
Quote:

Quote: "I've one of the last Alder Lakes (directly coming from Santa Clara) without the laser cut to remove the AVX-512." That's a useless statement for the rest of the market. The PC market doesn't revolve around you!

From the rest of the market:
https://twitter.com/rpcs3/status/1461369839491026948

If you are using an Alder Lake (Intel 12th Gen) CPU with RPCS3, make sure you disable the little cores, otherwise you're leaving a lot of performance on the table.

With disabled E-cores you get AVX-512 and higher ring ratio.

ADL's performance is by far the best of any CPU arch.

As usual, you talk of things that you've no clue. At all!
Quote:

Quote: Again, what wasn't clear to you about this: "I've the AVX-512 still enabled (when I want: there's a BIOS option) on my 12900K and works perfectly" useless and hopeless PARROT? You do NOT read what people write and repeat totally NON-SENSE stuff on things which were ALREADY KNOWN and, most important, ALREADY CLARIFIED. What's IQ level?!? As said, Mother Nature was a very bad stepmother with you... Your statement is useless when a new user purchases an Intel Adlerlake/Z670 motherboard combo as of today.

Have I stated something against that? Care to PROVE it?
Quote:

The PC market doesn't revolve around you!

See above on that: I'm NOT the only one...
Quote:

Quote: I don't defend the Apollo team. As I've ready said and you don't read and/or neither understand because of your evident intrinsic limits, I had a butcher fight with Gunnar. Besides that, I only defend FACTs and REALITY. Quote: Your FACTs and REALITY are based on your centric self.

I reveal you a secret: facts and reality are immutable. They don't depend from me, you, or anyone else.
Quote:

The PC market doesn't revolve around you!

And here's the usual Hammer's PARROTTing. After Homer Simpson you deserve an entry on the dictionary as well...
Quote:

Apollo-Core has its own backward compatibility issues that require multiple FPGA firmware updates or FPGA V4 hardware update.

Really? Maybe is it the reason why they are using a FPGA?

Or, is possible that they had an INCREMENTAL development? Or do you think that they had to fully complete the project before releasing the very first version?
Quote:

You're fooling yourself when you presented they are saints for Amiga 68K legacy

It's quite evident that you do NOT read what people write. And that's because, as I've already said, Mother Nature was so evil with you.

Let me copy & past it again:

I had a butcher fight with Gunnar.

What's not clear to you about that, Mother Nature's reject?
Quote:

when Apollo-Core followed Motorola ColdFire's shortening FPU tactics.

You know what? THAT was the reason why I had a fight with Gunnar. And many people on aros-exec saw it.

And now I'm curious to know what else you'll invent about me...
Quote:

No X86 CPU vendor has shortening X87 FPU compliance.

According to YOU some AMD processor was NOT FP-compliant, right? So YOUR statement is clearly false, and YOU were the one rebutting it yourself...
Quote:

https://youtu.be/2QGFveBnNWU?t=1242 A1200 Vampire V2 RTG playing Duke Nukem 3D Atomic edition with jerky frame rates. Date: October 2021 https://youtu.be/HTPWqEcjjds?t=132 Blizzard1260 equipped A1200 playing Duke Nukem 3D Atomic edition with smoother frame rates. Date: June 2011

Same as above: you do NOT read what people writes.

Another copy & paste is required:

V2 have a limited FPGA compared to V4 and subsequent. Do you know it? I think no, because you're the usual ignorant...

Which can be easily checked by comparing side-by-side the specs of all boards on the products page:
http://apollo-core.com/index.htm?page=products

On the age of internet ignorance is not a mitigating circumstance, rather an aggravating factor...
Quote:

Again, the Apollo-core team is distracted by feature extensions.

No, it's "distracted" by the FPGA limits.

Combined with the performance penalty of implementing full extended precision.

Have you tried the soft-FPU emulation on WinUAE? I think no. Because this is THE reason why it's NOT enabled by default.

And now tell me how many people complained against Toni Wilen for having left it disabled...

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: Two pixels is already a very good result, however we're talking about a 160x200 (or 256) screen. That is. About the closet to 1x1 there is with copper. I've read that the ECS copper was based on a trick that enabled 7 bitplanes that caused a side effect it used since only 6 exist. Sounds a bit hacky.

That's very strange, because if 7 bitplanes are fetching data from memory then there's not enough bandwidth for fetching 16-bits (for the 12-bit colour) every 2 pixels.
Quote:

Quote: If I've understood correctly, you're changing the two scroll values of even and odd bitplanes, but when just using a single playfield. So, yes: this cannot be simulated with packed graphics. Hooray! Yes that is what I meant. I've long suspected I have communication issues and doubt anyone can understand any instruction guide I have ever written. Did you say previously packed can do it exactly the same?

Well, the hypothesis was to have exactly an Amiga but with the ONLY difference of using packed instead of planar graphics. Then, yes: it's impossible to achieve.

However if we relax just a little bit the hypothesis this effect can be very easily implemented with packed graphics using two playfields of 8 colors each and by simply ORing their colors indexes (the second being shifted left by 3). With added bonus that packed graphics is more efficient for moving/drawing the graphics.
Quote:

Quote: Unless you define the even bitplanes to show an 8 (or 16, with AGA) colors screen, and then using the odd bitplanes for another 4/8/16 colors "screen" that it's used to simulate transparencies (with a proper palette). That would be cool to simulate another screen effect. I could be off the mark here. But I thought it might have been used as a cheap trick like this in State of the art. https://youtu.be/WbVMJPh9i5Q?t=67

Yes, I think that is uses this trick.
Quote:

Quote: No, it's like when you've to draw a BOB. Only that, instead of rendering with a usual cookie-cut routine (adapted, in case of packed-graphics), you just call the routine which is taking care of rendering the specific sprite. The route execute regular processor instructions that will access the framebuffer and changing it according to how the compiled sprite should be rendered. Okay. So can this work with parallax layers? Or is it only suitable for one layer? Given the framebuffer would have the final composition.

Yes, it works with multiple playfields as well: it's enough to render the sprite on top of the proper playfield.
Quote:

Quote: Not exactly an alpha channel, rather a sequence of zeros or ones, where the sequence has the same screen depth. Then you can use the order boolean operators to apply this mask. I meant now days we have ARGB where any opacity is included in the pixel value as opposed to being separate to the pixels like a mask is.

Nowadays, yes. But with the above hypothesis you have no ARGB rather CLUTs, so you need some way to implement masking.
Quote:

Quote: However there's not enough space & transistors on OCS. That's why a 7 and 8-bit EHB mode, using 8 bitplanes, cut still using a 32-bit CLUT, would have been a very good compromise. If it was fast enough yes.

As fast as 640x200/256 in 16 colors.
Quote:

Quote: As I've said several times, AGA was an HORRIBLE patch over ECS. Some of it was fine. But other things were expanding an old design. May have helped if the 68020 was used in the beginning with a fully 32-bit design. But of course the cost would have jumped too much. However the original design looks very 16-bit which made it harder for a 32-bit upgrade. The best way to update would be a fully 32-bit design but then it would have no compatibility.

When I've designed the AGA evolution (around 10-12 years ago), on Olaf's Amiga coding forum, I've proposed to "virtualize" the old (OCS/ECS/AGA) registers bank and directly remapping all (write) 16-bit accesses there with equivalent 32-bit ones on the new registers bank. This would have fully preserved the compatibility.
Quote:

Also I thought the palette should have had a pointer of it's own in chip ram. All other graphic elements were in chip so to me it made sense. Like all else it could have read it all on screen refresh. A copper list sets palette anyway in common copper lists and that's in chip ram anyway so why not stick the whole palette in chip directly? Could have allowed custom screen modes with 1x1 chunky for real at 24-bit depth.

I proposed this as well, at the time.
Quote:

Quote: So, having multiple Blitters is, effectively, totally useless. That's what I would have concluded. One faster blitter that had some ability to blit multiple planes would be better. Source is easy enough, since planar data can be in order, it just a destination where planes are spread about that would have needed a way to deal with it.

I've already proposed the solution which does it: packed graphics...

@cdimauro

https://www.youtube.com/watch?v=4o4MXV-d-jQ
Intel sucks. Intel tried to kill the x86 three times i.e. iAPX, i860, and Itanium IA-64. For each Intel attempts to kill the X86, Intel suck.

Quote:

Hammer's PADDING...

You can't handle the truth.

In the real corporate world, not applying security patches can result in an employment dismissal.

Quote:

From the rest of the market: https://twitter.com/rpcs3/status/1461369839491026948 If you are using an Alder Lake (Intel 12th Gen) CPU with RPCS3, make sure you disable the little cores, otherwise you're leaving a lot of performance on the table. With disabled E-cores you get AVX-512 and higher ring ratio. ADL's performance is by far the best of any CPU arch. As usual, you talk of things that you've no clue. At all!

That's a useless argument for new Alderlake users who have the laser-cut AVX-512 version.

ARM is not stupid enough to design little.BIG multi-CPU cores with a different instruction set.

I'm aware of MSI's recalcitrant action e.g. https://videocardz.com/newz/msi-partially-reenables-alder-lake-s-avx-512-support-for-meg-z690-unify-x-motherboard

Intel created a land mine situation for AVX-512.

https://www.tomshardware.com/news/how-to-tell-which-alder-lake-cpus-have-avx-512
April 2022, How to Tell if Your Alder Lake CPU Can Use the AVX-512 Instruction Set.

Next is BIOS compatibility, which can range significantly depending on the vendor. According to Zingaburga, MSI is the only reliable vendor that appears to be supporting AVX-512 as a whole. For Z690 motherboards, BIOS version 1.1 or later supports AVX-512, while BIOS version 1.2 includes a CPU microcode toggle to keep AVX-512 support if you need it.

The same appears to be true for MSI's B660 lineup; however, this hasn't been fully confirmed.

With other vendors, it's more of a hit or miss which BIOS's support AVX-512. So you'll have to research the board you are looking at (or already have) to see which supports AVX-512.



https://videocardz.com/newz/overclocker-explains-how-to-quickly-distinguish-intel-alder-lake-cpu-with-avx512-support
In March this year Intel officially started to fuse off the AVX512 from the silicon, meaning that even with supported BIOS, the functional will no longer work.



https://www.intel.com/content/www/us/en/support/articles/000089918/processors.html
Summary
AVX-512 will be fused off on Alder Lake.

Description
Unable to determine if AVX-512 instruction is supported on Intel® Alder Lake processors.

Resolution
AVX-512 will be fused off on Alder Lake mobile products and most desktop products. Although AVX-512 was not fuse-disabled on certain early Alder Lake desktop products, Intel plans to fuse off AVX-512 on Alder Lake products going forward.


https://www.dell.com/community/Alienware-Desktops/Aurora-R13-Intel-Alderlake-AVX-512-support/td-p/8139667
Dell customers wanted Dell to follow MSI's recalcitrant action on the AVX 512 issue.
The company that I work for is a "Dell shop".


https://www.reddit.com/r/intel/comments/rtfk8i/that_is_not_acceptable_intel_disabling_avx_via_a/
On Intel's Reddit, users raged against Intel's AVX 512 removal.


https://virginianewstime.com/why-cant-12th-gen-intel-processors-pass-the-legal-exam-blame-the-e-cores/57321/
Why can’t 12th gen Intel processors pass the legal exam (software)? Blame the E-cores.

Earlier this week, some people are waiting to pass the bar exam received a message from ExamSoft, the company that makes the Examplify software that many states use to administer the exam: PCs with the latest 12th-generation Intel Core processors are “currently not supported” because they “run the Examplify virtual machine automatic test.” The company’s proposed solution was for people to find another device to run the test on, a frustrating and useless “workaround” for those with a new computer.
..
Programs that haven’t been updated sometimes see two different types of CPU cores available to them and assume they’re actually seeing two completely different PCs. That was the reason some DRM video games and anti-cheat software packages updates or workarounds are required to run on 12th generation processors. Intel said at the time that the affected software detected the E-core “as a different system,” which could also explain why the Examplify software thinks it’s running in a virtual machine—it sees that there’s an abstraction layer between it and the CPU. , and it refuses to start.

Last edited by Hammer on 23-Aug-2022 at 04:40 PM.
Last edited by Hammer on 23-Aug-2022 at 09:36 AM.
Last edited by Hammer on 23-Aug-2022 at 09:28 AM.
Last edited by Hammer on 23-Aug-2022 at 09:26 AM.
Last edited by Hammer on 23-Aug-2022 at 09:20 AM.
Last edited by Hammer on 23-Aug-2022 at 09:17 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: If you are using an Alder Lake (Intel 12th Gen) CPU with RPCS3, make sure you disable the little cores, otherwise you're leaving a lot of performance on the table. With disabled E-cores you get AVX-512 and higher ring ratio.

Alder Lake, RPCS3, AVX-512.

I feel like Rip Van Winkle, waking up after 20 years and discovering the (CPU) world has changed so much I have no clue what any of it means.

Meanwhile I just a harvested a 16MHz MC68HC000 from an old Macintosh SCSI card, and can't wait to try it out in my A500!

@Hammer

Quote:

In the real corporate world, not applying security patches should result in an employment dismissal.

FTFY.

As a CISO I can tell you it will in our organisation, however, as an Infosec consultant I can tell you that it rarely happens in most other organisations. Sadly.

@cdimauro

From ColdFire V4 core
https://www.nxp.com/files-static/dsp/doc/ref_manual/V4ECFUM.pdf

6.3 Operand Execution Pipeline (OEP)

Instruction folding involving MOVE instructions allows two instructions to be
issued in one cycle. The resulting microarchitecture approaches full superscalar
performance at a much lower silicon cost.

-----


The ColdFire V4 core made claims about instruction fusing that could combine two instructions into one and issued in one cycle.


I'm aware of GunnarVB's adventures in the NXP community forum.

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

@Bosanac

Quote:

Bosanac wrote: @Hammer Quote: In the real corporate world, not applying security patches should result in an employment dismissal. FTFY. As a CISO I can tell you it will in our organisation, however, as an Infosec consultant I can tell you that it rarely happens in most other organisations. Sadly.

Killing critical business functionality via a known security flaw is a colossal security mistake.

Target’s security software had detected the Trojan software installation used to commit the hack, but the security team incorrectly deemed the event log message a false positive. Instead of alerting management that the company was under attack, everyone remained silent as the logs filled up with evidence of the infiltration. This single bonehead move cost Target hundreds of millions of dollars, forced the resignation of the CEO and CIO, and eroded customer trust in the brand.

Last edited by Hammer on 23-Aug-2022 at 03:55 PM.

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

@bhabbott
Quote:

Alder Lake, RPCS3, AVX-512. I feel like Rip Van Winkle, waking up after 20 years and discovering the (CPU) world has changed so much I have no clue what any of it means. Meanwhile I just a harvested a 16MHz MC68HC000 from an old Macintosh SCSI card, and can't wait to try it out in my A500!

Intel Alder Lake is a lost cause and its replacement is within a few weeks i.e. Intel RaptorLake and its competitor AMD Zen 4. AMD has confirmed AVX3-512 for Zen 4.

Zen 4 includes the following ISA enhancements:

AVX-512 - 512-bit Vector Instructions
AVX512F - Foundation (first introduced with Intel Skylake)
AVX512CD - Conflict Detection Instructions (Skylake X)
AVX512VL - Vector Length Extensions (Skylake X)
AVX512DQ - Doubleword and Quadword Instructions (Skylake X)
AVX512BW - Byte and Word Instructions (Skylake X)
AVX512 IFMA - Integer Fused Multiply-Add (Cannon Lake)
AVX512 VBMI - Vector Bit Manipulation Instructions (Cannon Lake)
AVX512 VPOPCNTDQ - Vector Population Count Instruction (Ice Lake)
AVX512 BITALG - Bit Algorithms (Ice Lake)
AVX512 VBMI2 - Vector Bit Manipulation Instructions 2 (Ice Lake)
AVX512 VNNI - Vector Neural Network Instructions (Ice Lake)
AVX512 BF16 - BFloat16 Instructions (Cooper Lake)

GFNI - Galois Field New Instructions (first introduced with Intel Ice Lake)
VGF2P8AFFINEQB - Galois field affine transformation
VGF2P8AFFINEINVQB - Galois field affine transformation inverse
VGF2P8MULB - Galois field multiply bytes

Good competition benefits consumers.

Intel is kitbashing AVX-512, hence making it a land mine instruction set. Intel's current LGA 1700 (Socket V) is at the "tock" state, hence LGA 1700's CPU support ends with Raptorlake.

----

The need for RPCS3 is less when Sony is releasing PlayStation games on the PC (e.g. God of War on Steam, The Last of Us for PC confirmed) and other Playstation exclusive games are on the PC.

Baseline Intel Xe Iris IGP and AMD RX Vega (higher clocked 7nm variants) and RX 660M/680M RDNA 2 IGPs have reduced the need for PS4.

I have Wicher 508 has MC68HC000 overclocked to 50Mhz, but it has compatibility problems with Dread. I tested Wicher 508's MC68HC000 at 25Mhz mode, Dread still results in graphics corruption. Dread works fine on the Amiga 1200/TF1260's 68060 with caches disabled.

For my Amiga 500, I'm waiting for PiStorm/Pi 3a/Emu68/preconfigured 32GB MicroSD to arrive from the EU. After I obtain Pi 3a, I plan to update the firmware for TF1260. I plan to fit heat pipes from 68060 onto A1200's RF metal shielding. Ex-laptop's heat pipe cooling solution is more than enough for cooling an overclocked 68060 rev 1. My 68060 rev 1 @ 62.5 Mhz has about 41 degrees C with a small passive heatsink. My target overclock is 70 Mhz range.

Good luck with your MC68HC000 adventure.

_________________
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 https://www.youtube.com/watch?v=4o4MXV-d-jQ Intel sucks.

I already knew that you're a blind AMD Taliban: there's no need to prove it all the time.
Quote:

Intel tried to kill the x86 three times i.e. iAPX, i860, and Itanium IA-64. For each Intel attempts to kill the X86, Intel suck.

As usual you're misinformed. From the three only Itanium was supposed to replace x86.

iAPX was a completely different project with other goals, since it also started well BEFORE IBM's PC (read: when 8086 was NOT so successful and spread around).

80860 was developed for workstations and not for desktops. It was doing so well in that area that it was used as graphic card accelerator (it was the first to integrated a SIMD unit, AFAIR. Anyway, at least one of the first ones).

Last but not really least, the above was your usual Hammer's PADDING. With the addition of some poison puked against your "enemy" due to your fanaticism, to satisfy your violated ego in this discussion. Go baby, go crying to your mammy!
Quote:

Quote: Hammer's PADDING... You can't handle the truth.

The truth is that this:

My ASUS ROG Strix 570-E, Strix X570-F, and Gigabyte X570 UD motherboards are at AMD AM4 AGESA V2 PI 1.2.0.6b. Motherboard's software makes firmware updates easy.

Windows Update service also supplies P-Core/E-Core CPU driver and Intel microcode updates that include Intel Alder Lake CPUs.

was effectively your beloved PADDING, considering what we were discussing about.

Or, if you want to call it Red Herring, it's the same, because you tried to distort the discussion, as usual. My dear King of logical fallacies...
Quote:

In the real corporate world, not applying security patches can result in an employment dismissal.

See above: again Hammer's PADDING.

Anyway, nobody stated something against it.

Who knows why you need to write sentences which mean and bring nothing on a discussion talking on specific arguments. Besides that you're the King of logical fallacies.
Quote:

Quote: From the rest of the market: https://twitter.com/rpcs3/status/1461369839491026948 If you are using an Alder Lake (Intel 12th Gen) CPU with RPCS3, make sure you disable the little cores, otherwise you're leaving a lot of performance on the table. With disabled E-cores you get AVX-512 and higher ring ratio. ADL's performance is by far the best of any CPU arch. As usual, you talk of things that you've no clue. At all! That's a useless argument for new Alderlake users who have the laser-cut AVX-512 version.

Tell me: who stated the contrary? Give me a name at least.

Otherwise it's your usual PADDING.
Quote:

ARM is not stupid enough to design little.BIG multi-CPU cores with a different instruction set.

And this is even MORE PADDING, since ARM means nothing in this context.
Quote:

I'm aware of MSI's recalcitrant action e.g. https://videocardz.com/newz/msi-partially-reenables-alder-lake-s-avx-512-support-for-meg-z690-unify-x-motherboard

No, you were NOT aware of it before. Likely you find it on one of your usual and desperate google searches...

Otherwise you knew the situation but this didn't stopped you to write your absolute sentence on AVX-512. Read: your're CONTRADDICTING yourself (what a news! ).
Quote:

Intel created a land mine situation for AVX-512.

If you would have read even your links (which is the bare minimum on a discussion), which clearly you have NOT, then you should have understood that it was NOT Intel that created this mess, rather the motherboards makers.
Quote:

https://www.tomshardware.com/news/how-to-tell-which-alder-lake-cpus-have-avx-512 April 2022, How to Tell if Your Alder Lake CPU Can Use the AVX-512 Instruction Set. Next is BIOS compatibility, which can range significantly depending on the vendor. According to Zingaburga, MSI is the only reliable vendor that appears to be supporting AVX-512 as a whole. For Z690 motherboards, BIOS version 1.1 or later supports AVX-512, while BIOS version 1.2 includes a CPU microcode toggle to keep AVX-512 support if you need it. The same appears to be true for MSI's B660 lineup; however, this hasn't been fully confirmed. With other vendors, it's more of a hit or miss which BIOS's support AVX-512. So you'll have to research the board you are looking at (or already have) to see which supports AVX-512. https://videocardz.com/newz/overclocker-explains-how-to-quickly-distinguish-intel-alder-lake-cpu-with-avx512-support In March this year Intel officially started to fuse off the AVX512 from the silicon, meaning that even with supported BIOS, the functional will no longer work. https://www.intel.com/content/www/us/en/support/articles/000089918/processors.html Summary AVX-512 will be fused off on Alder Lake. Description Unable to determine if AVX-512 instruction is supported on Intel® Alder Lake processors. Resolution AVX-512 will be fused off on Alder Lake mobile products and most desktop products. Although AVX-512 was not fuse-disabled on certain early Alder Lake desktop products, Intel plans to fuse off AVX-512 on Alder Lake products going forward. https://www.dell.com/community/Alienware-Desktops/Aurora-R13-Intel-Alderlake-AVX-512-support/td-p/8139667 Dell customers wanted Dell to follow MSI's recalcitrant action on the AVX 512 issue.

Again, PADDING.
Quote:

The company that I work for is a "Dell shop".

Spot the difference: I worked for Intel. My Schwarz is bigger than yours!
Quote:

https://www.reddit.com/r/intel/comments/rtfk8i/that_is_not_acceptable_intel_disabling_avx_via_a/ On Intel's Reddit, users raged against Intel's AVX 512 removal.

See above: they should talk with their motherboards vendors...
Quote:

https://virginianewstime.com/why-cant-12th-gen-intel-processors-pass-the-legal-exam-blame-the-e-cores/57321/ Why can’t 12th gen Intel processors pass the legal exam (software)? Blame the E-cores. Earlier this week, some people are waiting to pass the bar exam received a message from ExamSoft, the company that makes the Examplify software that many states use to administer the exam: PCs with the latest 12th-generation Intel Core processors are “currently not supported” because they “run the Examplify virtual machine automatic test.” The company’s proposed solution was for people to find another device to run the test on, a frustrating and useless “workaround” for those with a new computer. .. Programs that haven’t been updated sometimes see two different types of CPU cores available to them and assume they’re actually seeing two completely different PCs. That was the reason some DRM video games and anti-cheat software packages updates or workarounds are required to run on 12th generation processors. Intel said at the time that the affected software detected the E-core “as a different system,” which could also explain why the Examplify software thinks it’s running in a virtual machine—it sees that there’s an abstraction layer between it and the CPU. , and it refuses to start.

Thanks for having highlighted those very badly written softwares, which assumed wrong things (x86/x64 processors specs at the hand).

Anyway, you still haven't understood that my replies are caused by your "absolute" statements.

The pattern is very simple: you write sentences stating precise and absolute claims. Which means that it's enough to find just a SINGLE case where they don't apply to make your statements invalid.

That's purely, simple, elementary logic. But you continue to fall on such logical fallacies. Your pleasure, then...
Quote:

Hammer wrote: @cdimauro From ColdFire V4 core https://www.nxp.com/files-static/dsp/doc/ref_manual/V4ECFUM.pdf 6.3 Operand Execution Pipeline (OEP) Instruction folding involving MOVE instructions allows two instructions to be issued in one cycle. The resulting microarchitecture approaches full superscalar performance at a much lower silicon cost. ----- The ColdFire V4 core made claims about instruction fusing that could combine two instructions into one and issued in one cycle.

Right, and? Care to post the same for the PowerPC 970, as YOU claimed?
Quote:

I'm aware of GunnarVB's adventures in the NXP community forum.

I'm aware as well and this has nothing to do with any "cloning/stealing" of ColdFire cores, if that's what you want to insinuate, dear mystifier.

If you think differently then you're free to post the links to those discussions AND quote the relevant parts AND prove your thesis.

In the meanwhile I'm preparing the nails for your next public crucifixion...

@bhabbott

Quote:

bhabbott wrote: @Hammer Quote: Hammer wrote: If you are using an Alder Lake (Intel 12th Gen) CPU with RPCS3, make sure you disable the little cores, otherwise you're leaving a lot of performance on the table. With disabled E-cores you get AVX-512 and higher ring ratio. Alder Lake, RPCS3, AVX-512. I feel like Rip Van Winkle, waking up after 20 years and discovering the (CPU) world has changed so much I have no clue what any of it means. Meanwhile I just a harvested a 16MHz MC68HC000 from an old Macintosh SCSI card, and can't wait to try it out in my A500!

We already know that you're a caveman: no need to prove it each time.

You publicly defined yourself as "retro". Well, that's YOU: not all other people which had experience with the Amiga are the same. Fortunately.

If you like to live on a cave, well, do it! But then don't understand why you're here: do you feel lonely and need some buddy with you?


@Hammer

Quote:

Hammer wrote: Intel is kitbashing AVX-512, hence making it a land mine instruction set.

Other lies. As usual, because of your hatred against Intel.

I've already explained you Intel's AVX-512 plans for its Alder Lake microarchitecture family, but you've already forgotten it. Hint: workstations and servers.
Quote:

Intel's current LGA 1700 (Socket V) is at the "tock" state, hence LGA 1700's CPU support ends with Raptorlake.

There's no tick-toc strategy from YEARS! The last processor was... Kaby Lake!

Are you living on a cave like Bruce?
Quote:

---- The need for RPCS3 is less when Sony is releasing PlayStation games on the PC (e.g. God of War on Steam, The Last of Us for PC confirmed) and other Playstation exclusive games are on the PC.

So, is Sony planning to release ALL PS3 games for PCs? Read: ALL of them?

Do you see how easy is to kill your absolute statements? No, I don't think so: you'll never change, because Mother Nature was so bad with you...
Quote:

Baseline Intel Xe Iris IGP and AMD RX Vega (higher clocked 7nm variants) and RX 660M/680M RDNA 2 IGPs have reduced the need for PS4. I have Wicher 508 has MC68HC000 overclocked to 50Mhz, but it has compatibility problems with Dread. I tested Wicher 508's MC68HC000 at 25Mhz mode, Dread still results in graphics corruption. Dread works fine on the Amiga 1200/TF1260's 68060 with caches disabled. For my Amiga 500, I'm waiting for PiStorm/Pi 3a/Emu68/preconfigured 32GB MicroSD to arrive from the EU. After I obtain Pi 3a, I plan to update the firmware for TF1260. I plan to fit heat pipes from 68060 onto A1200's RF metal shielding. Ex-laptop's heat pipe cooling solution is more than enough for cooling an overclocked 68060 rev 1. My 68060 rev 1 @ 62.5 Mhz has about 41 degrees C with a small passive heatsink. My target overclock is 70 Mhz range. Good luck with your MC68HC000 adventure.

Good luck with Dread, instead: if it requires even disabling the caches for 68060s, then it has its own problems, and processors aren't the guilty ones.

Hammer Quote:

https://www.youtube.com/watch?v=4o4MXV-d-jQ Intel sucks. Intel tried to kill the x86 three times i.e. iAPX, i860, and Itanium IA-64. For each Intel attempts to kill the X86, Intel suck.

Intel has had its hits and misses but at least they didn't strike out like Motorola did when they abandoned the 68k for PPC. At least Intel was happy to sell any CPU they produced for any use and let market demand determine their development path while Motorola killed off the 68k and even anti-marketed the 68060 for anything but embedded use when it was easily the best choice for a low end Mac (PPC 603 non-Performa) and Mac laptop (delayed because of poor PPC 603 performance). I'm not so sure that this anti-Intel video is any more accurate than the pro-Intel video I made fun of awhile ago. I don't see iAPX or i860 as x86 replacements either as they were specialized and somewhat experimental architectures. Difficulty of compiler support was partially due to the failure of all 3 of these supposed x86 replacements which is funny because x86 isn't pretty or orthogonal for good compiler support either, at least not as good as the 68k. The 68000 used 68000 transistors so I don't know where the 40,000 number in the video came from. Not the most accurate video but entertaining none the less, maybe because I still harness some anti-Intel bias. I don't blame Intel for getting lucky and hitting a home run with their little 8088 bat.

Hammer Quote:

From ColdFire V4 core https://www.nxp.com/files-static/dsp/doc/ref_manual/V4ECFUM.pdf 6.3 Operand Execution Pipeline (OEP) Instruction folding involving MOVE instructions allows two instructions to be issued in one cycle. The resulting microarchitecture approaches full superscalar performance at a much lower silicon cost. ----- The ColdFire V4 core made claims about instruction fusing that could combine two instructions into one and issued in one cycle.

I have issues with the way the ColdFire manual describes two instructions issued in one cycle. I expect two instructions are folded together into one instruction and then one instruction is issued. I believe it is more accurate to say two instructions were retired in one cycle. Various ColdFire documentation and advertising literature makes it sound like code folding is similar to superscalar execution which is deceptive as superscalar uses Instruction Level Parallelism (ILP). Instruction folding can achieve the same results of retiring multiple instructions/cycle but is not ILP. Instruction folding is cheap to implement but there are limitations including very limited ability to do more ALU work due to fewer ALUs compared to superscalar.

https://en.wikipedia.org/wiki/Instruction-level_parallelism

Hammer Quote:

I'm aware of GunnarVB's adventures in the NXP community forum.

Well, ColdFire and the 68060 would have been higher performance if each integer pipe could decode and execute 8 bytes/cycle. This would have been especially helpful to the ColdFire where they didn't support addressing modes which made instructions too long to execute in one cycle but this change allowed them to infer that ColdFire uses a RISC architecture, another deceptive marketing ploy that has some truth.

https://www.nxp.com/products/product-information/ip-block-licensing/coldfire-32-bit-processors:COLDFIRE-32-BIT-PROCESSORS Quote:

All ColdFire cores feature a variable-length RISC architecture for compact code and are supported by an extensive collection of development systems, tools, libraries, and operating systems from Freescale and several third-party commercial and open-source providers.

ColdFire uses 95% the same encodings as the 68k but it is a RISC architecture. If lopping off support for all the longer instructions (and many of the instruction sizes) makes the 68k RISC, it also makes it weaker but then that is RISC like to execute weaker instructions. At least the ColdFire reg-mem accesses instead of load/store memory accesses decreases code execution paths and improves code density while using fewer registers than most RISC architectures and the remaining addressing modes are still pretty good for a RISC architecture.

Last edited by matthey on 24-Aug-2022 at 02:40 AM.
Last edited by matthey on 24-Aug-2022 at 02:32 AM.
Last edited by matthey on 24-Aug-2022 at 01:53 AM.

@cdimauro

Quote:

We already know that you're a caveman: no need to prove it each time. You publicly defined yourself as "retro". Well, that's YOU: not all other people which had experience with the Amiga are the same. Fortunately.

I'm only a caveman when I'm in my man cave.

The rest of the time I am out in the real world, where nobody knows or cares about all the silly names and acronyms that CPU manufacturers attach to their products. It's been like that for decades now. The average consumer doesn't want to know what is going on inside their PC, they just want it it to work. And they shouldn't need to know. We have enough things to worry about in this modern world without pretending to care about the contortions IC manufacturers put themselves through in an effort to keep up with Moore's law.

For the last 6 days I have been without hot water as I try to drain the leaking cylinder I have to replace. Can't get it out of the cupboard intact because the idiot builders put the cylinder in first and then built the door frame around it. I chose a replacement unit thin enough to fit and the supplier doesn't want to sell it to me because the manufacturer won't warranty copper cylinders in my area due to the council putting chlorine in the water for a few months 3 years ago. They don't recommend stainless steel for the same reason, and want to sell me a vitreous enameled unit that will rust out in seconds if the enamel cracks. And that piece of crap will cost NZ$2-3,000 to install (assuming I can I get the old one out myself, so the plumber doesn't have to waste even more time doing it). And now they are asking me whether I can build a bigger cupboard so they can sell me a wider unit!

To cap it off I caught a cold last week which I am still recovering from (thank goodness it wasn't Covid...). Wearing masks everywhere, staying away from people, washing my hands religiously and living like a caveman, and the virus still got me!

At least one thing hasn't let me down - my trusty Amiga which I enjoy using every day.

Quote:

If you like to live on a cave, well, do it! But then don't understand why you're here: do you feel lonely and need some buddy with you?

It's funny, when I come here it feels like visiting a mental hospital full of deluded souls who still think PPC and OS4 are the future. If it wasn't for a few threads like this that tickle my retro hardware fancies I wouldn't be here at all.

Last edited by bhabbott on 24-Aug-2022 at 04:03 AM.

@Hammer

Quote:

Hammer wrote: I have Wicher 508 has MC68HC000 overclocked to 50Mhz, but it has compatibility problems with Dread. I tested Wicher 508's MC68HC000 at 25Mhz mode, Dread still results in graphics corruption. Dread works fine on the Amiga 1200/TF1260's 68060 with caches disabled.

If it's any consolation, Dread also has graphical glitches when running on my A1200 with Blizzard 1230-IV 50MHz 030. To get it working properly I have to disable the accelerator card. I'm not too concerned about this. Dread was (rightly) optimized for the A500, which really needs it. Hopefully after the A500 version is finished someone will look at the code and produce a slower but more compatible rendering algorithm. Perhaps make it 1x1 pixel too (or at least fix the vertical lines in textures viewed close up), then it will be truly awesome!

@bhabbott

Quote:

bhabbott wrote: @cdimauro Quote: We already know that you're a caveman: no need to prove it each time. You publicly defined yourself as "retro". Well, that's YOU: not all other people which had experience with the Amiga are the same. Fortunately. I'm only a caveman when I'm in my man cave.

I don't think so: still using Window XP classifies you as caveman as well.
Quote:

The rest of the time I am out in the real world, where nobody knows or cares about all the silly names and acronyms that CPU manufacturers attach to their products. It's been like that for decades now. The average consumer doesn't want to know what is going on inside their PC, they just want it it to work. And they shouldn't need to know. We have enough things to worry about in this modern world without pretending to care about the contortions IC manufacturers put themselves through in an effort to keep up with Moore's law.

Then could I ask you how do you decide when you have to buy a PC or a smartphone? Do you open a flyer with your eyes closed and then put the finger in some place?
Quote:

For the last 6 days I have been without hot water as I try to drain the leaking cylinder I have to replace. Can't get it out of the cupboard intact because the idiot builders put the cylinder in first and then built the door frame around it. I chose a replacement unit thin enough to fit and the supplier doesn't want to sell it to me because the manufacturer won't warranty copper cylinders in my area due to the council putting chlorine in the water for a few months 3 years ago. They don't recommend stainless steel for the same reason, and want to sell me a vitreous enameled unit that will rust out in seconds if the enamel cracks. And that piece of crap will cost NZ$2-3,000 to install (assuming I can I get the old one out myself, so the plumber doesn't have to waste even more time doing it). And now they are asking me whether I can build a bigger cupboard so they can sell me a wider unit!

That's the business world...
Quote:

To cap it off I caught a cold last week which I am still recovering from (thank goodness it wasn't Covid...). Wearing masks everywhere, staying away from people, washing my hands religiously and living like a caveman, and the virus still got me!

Unfortunately I got the Covid a couple of months ago and I had worse experience. And all of that wearing masks all the time; but my kid was going at school and it got the virus there (while wearing the mask!). Damn...
Quote:

Quote: If you like to live on a cave, well, do it! But then don't understand why you're here: do you feel lonely and need some buddy with you? It's funny, when I come here it feels like visiting a mental hospital full of deluded souls who still think PPC and OS4 are the future. If it wasn't for a few threads like this that tickle my retro hardware fancies I wouldn't be here at all.

Then it's good.
Quote:

bhabbott wrote: @Hammer Quote: Hammer wrote: I have Wicher 508 has MC68HC000 overclocked to 50Mhz, but it has compatibility problems with Dread. I tested Wicher 508's MC68HC000 at 25Mhz mode, Dread still results in graphics corruption. Dread works fine on the Amiga 1200/TF1260's 68060 with caches disabled. If it's any consolation, Dread also has graphical glitches when running on my A1200 with Blizzard 1230-IV 50MHz 030. To get it working properly I have to disable the accelerator card. I'm not too concerned about this. Dread was (rightly) optimized for the A500, which really needs it. Hopefully after the A500 version is finished someone will look at the code and produce a slower but more compatible rendering algorithm. Perhaps make it 1x1 pixel too (or at least fix the vertical lines in textures viewed close up), then it will be truly awesome!

Then it's certified: Dread has serious issues on its own.

When I've developed Fightin' Spirit I was using self-modifying code (removed on the final version) running on chip mem. But it worked on all Amigas, because I used the o.s. API to disable the caches if the o.s. was 2.0+, or checking ExecBase for the CPU model and then directly executing the proper instructions to disable them.

That's because I've carefully respected all Commodore guidelines on the Amiga Hardware Reference Manual. Something which all coders should have done (but WHDLoad proves the opposite, unfortunately).

@matthey

Quote:

matthey wrote: Hammer Quote: https://www.youtube.com/watch?v=4o4MXV-d-jQ Intel sucks. Intel tried to kill the x86 three times i.e. iAPX, i860, and Itanium IA-64. For each Intel attempts to kill the X86, Intel suck. Intel has had its hits and misses but at least they didn't strike out like Motorola did when they abandoned the 68k for PPC. At least Intel was happy to sell any CPU they produced for any use and let market demand determine their development path while Motorola killed off the 68k and even anti-marketed the 68060 for anything but embedded use when it was easily the best choice for a low end Mac (PPC 603 non-Performa) and Mac laptop (delayed because of poor PPC 603 performance). I'm not so sure that this anti-Intel video is any more accurate than the pro-Intel video I made fun of awhile ago. I don't see iAPX or i860 as x86 replacements either as they were specialized and somewhat experimental architectures. Difficulty of compiler support was partially due to the failure of all 3 of these supposed x86 replacements which is funny because x86 isn't pretty or orthogonal for good compiler support either, at least not as good as the 68k. The 68000 used 68000 transistors so I don't know where the 40,000 number in the video came from. Not the most accurate video but entertaining none the less, maybe because I still harness some anti-Intel bias. I don't blame Intel for getting lucky and hitting a home run with their little 8088 bat. Hammer Quote: From ColdFire V4 core https://www.nxp.com/files-static/dsp/doc/ref_manual/V4ECFUM.pdf 6.3 Operand Execution Pipeline (OEP) Instruction folding involving MOVE instructions allows two instructions to be issued in one cycle. The resulting microarchitecture approaches full superscalar performance at a much lower silicon cost. ----- The ColdFire V4 core made claims about instruction fusing that could combine two instructions into one and issued in one cycle. I have issues with the way the ColdFire manual describes two instructions issued in one cycle. I expect two instructions are folded together into one instruction and then one instruction is issued. I believe it is more accurate to say two instructions were retired in one cycle. Various ColdFire documentation and advertising literature makes it sound like code folding is similar to superscalar execution which is deceptive as superscalar uses Instruction Level Parallelism (ILP). Instruction folding can achieve the same results of retiring multiple instructions/cycle but is not ILP. Instruction folding is cheap to implement but there are limitations including very limited ability to do more ALU work due to fewer ALUs compared to superscalar. https://en.wikipedia.org/wiki/Instruction-level_parallelism Hammer Quote: I'm aware of GunnarVB's adventures in the NXP community forum. Well, ColdFire and the 68060 would have been higher performance if each integer pipe could decode and execute 8 bytes/cycle. This would have been especially helpful to the ColdFire where they didn't support addressing modes which made instructions too long to execute in one cycle but this change allowed them to infer that ColdFire uses a RISC architecture, another deceptive marketing ploy that has some truth. https://www.nxp.com/products/product-information/ip-block-licensing/coldfire-32-bit-processors:COLDFIRE-32-BIT-PROCESSORS Quote: All ColdFire cores feature a variable-length RISC architecture for compact code and are supported by an extensive collection of development systems, tools, libraries, and operating systems from Freescale and several third-party commercial and open-source providers.

I fully agree on that.
Quote:

ColdFire uses 95% the same encodings as the 68k but it is a RISC architecture. If lopping off support for all the longer instructions (and many of the instruction sizes) makes the 68k RISC, it also makes it weaker but then that is RISC like to execute weaker instructions. At least the ColdFire reg-mem accesses instead of load/store memory accesses decreases code execution paths and improves code density while using fewer registers than most RISC architectures and the remaining addressing modes are still pretty good for a RISC architecture.

It's funny: I've used exactly the ColdFire as an example of how bad the RISC propaganda was/is, in my old article (still not yet published) about RISCs vs CISCs...

@cdimauro

Quote:

That's very strange, because if 7 bitplanes are fetching data from memory then there's not enough bandwidth for fetching 16-bits (for the 12-bit colour) every 2 pixels.

Sorry, I thought I had posted this link, that discusses it.

It's a trick they pull, since 7 planes doesn't exist pre-AGA on an A500, that sets up a 5 (or possibly 6) bitplane display with only DMA reading 4 bitplanes while bitplane 5 data is read from register. See comment #7.

https://ada.untergrund.net/?p=boardthread&id=442

Quote:

Well, the hypothesis was to have exactly an Amiga but with the ONLY difference of using packed instead of planar graphics. Then, yes: it's impossible to achieve.

If that is the only difference it should be possible, though instead of plane bits being out of place whole packed pixels could be out of place, but each field only needs one framebuffer pointer so less possible.

Quote:

However if we relax just a little bit the hypothesis this effect can be very easily implemented with packed graphics using two playfields of 8 colors each and by simply ORing their colors indexes (the second being shifted left by 3). With added bonus that packed graphics is more efficient for moving/drawing the graphics.

Then the logic involved is in fact simple.

Quote:

Yes, I think that is uses this trick.

Glad I wasn't just seeing things then.

Quote:

Yes, it works with multiple playfields as well: it's enough to render the sprite on top of the proper playfield.

I expected that to be the case.

Quote:

Nowadays, yes. But with the above hypothesis you have no ARGB rather CLUTs, so you need some way to implement masking.

It almost becomes hybrid at this point. A bit plane for the mask, with a packed plane for the pixels Mask data different size to pixels..

Quote:

As fast as 640x200/256 in 16 colors.

Yes that would work.

Quote:

When I've designed the AGA evolution (around 10-12 years ago), on Olaf's Amiga coding forum, I've proposed to "virtualize" the old (OCS/ECS/AGA) registers bank and directly remapping all (write) 16-bit accesses there with equivalent 32-bit ones on the new registers bank. This would have fully preserved the compatibility.

Looks like an interesting approach.

Quote:

I proposed this as well, at the time.

So I wasn't alone in my thinking there.

Quote:

I've already proposed the solution which does it: packed graphics...

Yes, I'm aware of that in the back of my mind, but I was thinking for the existing system which needed a faster way to move blit-planes.

@Hypex

Quote:

Hypex wrote: @cdimauro Quote: That's very strange, because if 7 bitplanes are fetching data from memory then there's not enough bandwidth for fetching 16-bits (for the 12-bit colour) every 2 pixels. Sorry, I thought I had posted this link, that discusses it. It's a trick they pull, since 7 planes doesn't exist pre-AGA on an A500, that sets up a 5 (or possibly 6) bitplane display with only DMA reading 4 bitplanes while bitplane 5 data is read from register. See comment #7. https://ada.untergrund.net/?p=boardthread&id=442

OK, I see thanks. So, it's an undocumented stuff. In fact, it doesn't work on AGA.

That's something which I absolutely don't accept, since it's against Commodore's guidelines.
Quote:

Quote: Nowadays, yes. But with the above hypothesis you have no ARGB rather CLUTs, so you need some way to implement masking. It almost becomes hybrid at this point. A bit plane for the mask, with a packed plane for the pixels Mask data different size to pixels..

Not really. Packed can handle pixels of any size. So, for depth = 1 bit it simply is the same as planar.
Quote:

Quote: I proposed this as well, at the time. So I wasn't alone in my thinking there.

Well, I'm a game developer: it was natural to me see some common problems during games development. And find practical solutions for them, like a CLUT loading DMA (which is way more practical and efficient compared to using the Copper).

The same for sprites: a direct pointer to the data instead of packing control words & plain graphic data would have been much much better.
Quote:

Quote: I've already proposed the solution which does it: packed graphics... Yes, I'm aware of that in the back of my mind, but I was thinking for the existing system which needed a faster way to move blit-planes.

But... there's no way.

PADDING

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