Not that anyone cares, but here's some Chunky HAM stuff

https://youtu.be/PoS_LF8Ik2s

Read the video description to see what is going on, but a TLDR

8 bit pixel (chunky)
15-bit RGB colour model
32 freely definable 15-bit palette entirely
Lower 5 bits of pixel specify the palette index or a value in the range 0-31
Upper 3 bits choose the application behaviour
000 : Palette index
001 : Hold previous, set new blue
010 : Hold previous, set new green
011 : Hold previous, set new cyan (blue+green)
100 : Hold previous, set new red
...
110 : Hold previous, set new yellow (red+green)
111 : Set new grey (hold previous but set all channels)

The display is filled with a pattern that is almost HAM pixels except for every 8th line. The first pixel of every row is set black using 11100000. There's a copper like script modifying the horizontal scroll position at various locations down the screen and the pulses are the resulting fringing artefacts for this screen.

I came up with this variation of HAM because I thought it might be fun and liked the symmetry of it, a bit like the original HAM6.

Last edited by Karlos on 23-Jun-2023 at 08:29 PM.

_________________
Doing stupid things for fun...

@Karlos

I hope to see alien breed 2 ported soon and play in it! xD

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@pixie

Don't hold your breath, lol.

Though I have to admit, it could be fun to try. There are just too many differences in the instruction set for that to be a realistic possibility.

Last edited by Karlos on 23-Jun-2023 at 09:30 PM.

_________________
Doing stupid things for fun...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Not at the time, because on '92 PC's graphic cards were much more powerful and with more features. Plus, they had the packed more already implemented, which was important. Last but not really least, they had processors with better performances (even the 286 was much better, especially for games). For 1992-1993 PC DOS gaming, it's mostly a fast VGA 320x2x0 frame buffer.

Which was fine for games of that age, but VGA clones allowed much more which was simply not used (besides Windows).
Quote:

Quote: BTW, Playstation arrived later. PlayStation was attracting 3rd party developers around late 1993. On 27 October 1993, Sony publicly announced that it was entering the game console market with the PlayStation. A team from Epic Sony visited more than a hundred companies throughout Japan in May 1993 in hopes of attracting game creators with the PlayStation's technological appeal.[58] Through a series of negotiations, Sony acquired initial support from Namco, Konami, and Williams Entertainment, as well as 250 other development teams in Japan alone. Namco in particular was keen to participate in the PlayStation project as a third-party developer since Namco rivalled Sega in the arcade market.[59] Attaining these companies secured influential games such as Ridge Racer (1993) and Mortal Kombat 3 (1995), Ridge Racer being one of the most popular arcade games at the time, and it was already confirmed behind closed doors that it would be the PlayStation's first game by December 1993. Namco's research managing director Shegeichi Nakamura met with Kutaragi in 1993 to discuss the preliminary PlayStation specifications, with Namco subsequently basing the Namco System 11 arcade board on PlayStation hardware and developing Tekken to compete with Virtua Fighter. The System 11 launched in arcades several months before the PlayStation's release, with the arcade release of Tekken in September 1994 Namco's PlayStation-based System 11 was released several months before the PlayStation's release. PlayStation hardware was operational before the Japanese retail Q4 1994 release. Sony made sure Playstation has AAA games during the retail release. Your argument is not based on 3rd party developer experience for PlayStation.

My argument was this:

"Playstation arrived later."

Which means 1994. And it was / is true.

Do you understand it?
Quote:

Quote: The PS1's CPU didn't reached 100MPS, but much less. I assume that you talked of the graphics processor. PS1's CPU has 33 MIPS and the graphics co-processor has 66 MIPS. 100 MIPS requirement is from a gaming PC Pentium perspective.

Only 'til 1995.
Quote:

Quote: Not suitable: too many characters displayed in some scenes, with characters also being larger than 16 pixel. Sprites cannot cover this. And BOBs can't be used due to the fringing the HAM generates. Refer to Amiga's Links Golf game.

I know it very well. Have you ever took at look at it? How many moving objects are displayed?
Quote:

Direct adventure PC VGA game ports that use Amiga HAM mode will require hard disk storage.

Well, NO: HAM uses 6 bitplanes and there's not so much differences with 32 colours games.

Plus, we have non-HAM adventure games that used even more than 10 disks.

So, hard disk was not mandatory (but certainly welcome).
Quote:

HAM mode has certain color artwork rules to minimize fringing.

Already covered even this on my article. And... it kills details / graphic artists work.
Quote:

Quote: Unbelievable: a 1987 computer that cannot access a 1993 CPU! Amiga's decline started around 1991. Wing Commander for PC was its "Defender of the Crown" moment and Doom's 1993 release reinforced the gaming PC's position.

I beg to differ: I was shocked when Star Trek for PC was published.
Quote:

Quote: There was no "context" before: you continuously bashed and hit the Vampire because of its FPU. Now you completely changed your mind and became a PiStorm evangelist, which suffers from exactly the same issues. Apollo Core's AGA promise for Vampire V2 FAILED. 68080 V2 is stuck in a 52-bit floating point.

I reveal you a secret: FPU for V2 wasn't even planned!

With its limited FPGA, it was already more than enough it was expected.

And V2 was the first product.
Quote:

68080 V4 initially didn't have a 64-bit floating point.

I reveal you another secret: neither Emu68 had FPU support at the beginning.
Quote:

Quote: You're not trustable. PADDING. Quote: So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU. For "FPU Precision On V4SA" topic http://www.apollo-core.com/knowledge.php?b=4¬e=34161 Gunnar von Boehn: R5 release supports 56 Bit FPU precision. Posted 14 Feb 2021 06:15 http://apollo-core.com/knowledge.php?b=1¬e=34946 V4SA R6 was released on 18th of April 2021 HAHAHAHA For Gold 2.7 core for all Vampires 500, 500+ and 600 https://forum.amiga.org/index.php?topic=73325.0 Posted date: March 04, 2018 Other forums have already reported that the FPU implementation doesn't work properly. For example, launch SYS:Tools/Calculator and try to calculate 5 * 1.3, and the result will be 6.499999999069. More about issues in the FPU implementation over here: https://blog.alb42.de/2018/03/03/vampire-2-7-fpu-part-2/ This FPU is just "Quake enabler". HAHAHAHAHA Posted: March 05, 2018 Kolla: As I commented, it's not really an FPU as much as a Quake enabler - any hope for a proper FPU on V2, is long gone. In many cases, FEMU works better (more accurate) than the FPU of core 2.7, but sadly it has its issues and development has stopped. So, another FPU emulator is needed for V2. HAHAHAHAHA You're not trustable. Look in the mirror.

Ehi, "genius", I've just used the information reported on the link that YOU provided:
https://amitopia.com/gold-2-11-is-out-for-68080-amiga-accelerator-users/
"Gold 2.11 is out for 68080 Amiga accelerator Users
ON: OCTOBER 18, 2018 IN: VAMPIRE 68080"

You don't even check YOUR resources!
Quote:

PiStorm32 Lite and Raspberry Pi 4 is cheap.

Irrelevant regarding this specific topic (which is: YOU bashed Vampire for this!).
Quote:

Fact: There is no sales contract for zero-cost open-source software like Emu68.

As above: irrelevant.
Quote:

I did have a Natami account.

Same for me, but again: irrelevant.
Quote:

I'm aware of the FP80 issues with certain software that runs on the Amiga, MacOS and Vampire AC68080 e.g. http://apollo-core.com/knowledge.php?b=5¬e=24818&order=&x=3&z=NHLVYf

Me too. Irrelevant.
Quote:

PiStorm32 Lite + RPI 4B (ARM Cortex A73) + Emu68 can brute force softFPU Shapeshifter that beats Power Macintosh 6100/60 FPU performance https://eab.abime.net/showpost.php?p=1605865&postcount=91 A1200/Vamp v2 Coffin56/Gold2.12fw - 1526s (25m 26s) Amiga4000D 3.2.1 WarpEngine060@96MHz - 1477s (24m 37s) Vampire V4SA+ Coffin57/SA_8435.jic (x14) - 1405s (23m 25s) Amiga4000T 3.2.1, BFG9060@100MHz - 1358s (22m 38s) A1200/PiStorm32 w/Pi4b+ @2.2GHz.CaffeinOS - 166secs X5000/20 2GHz MorphOS 3.18 - 119secs MACPRO5,1 2010 2x3.5GHz 6core. FSUAE/Coffin on BigSur - 80secs SGI FUEL 800MHz / IRIX 6.5.30f - 65s (62 without render preview turned on) SGI 4x1GHz (1 THREAD) - 53s (50s no preview) SGI 4x1GHZ (MAX THREADS) - 15s (14s no preview)

Again, irrelevant.

You continuously bashed the Vampire for what is still missing on your beloved PiStorm. Incoherent!

@Karlos

Quote:

Karlos wrote: Not that anyone cares, but here's some Chunky HAM stuff https://youtu.be/PoS_LF8Ik2s Read the video description to see what is going on, but a TLDR 8 bit pixel (chunky) 15-bit RGB colour model 32 freely definable 15-bit palette entirely Lower 5 bits of pixel specify the palette index or a value in the range 0-31 Upper 3 bits choose the application behaviour 000 : Palette index 001 : Hold previous, set new blue 010 : Hold previous, set new green 011 : Hold previous, set new cyan (blue+green) 100 : Hold previous, set new red ... 110 : Hold previous, set new yellow (red+green) 111 : Set new grey (hold previous but set all channels) The display is filled with a pattern that is almost HAM pixels except for every 8th line. The first pixel of every row is set black using 11100000. There's a copper like script modifying the horizontal scroll position at various locations down the screen and the pulses are the resulting fringing artefacts for this screen. I came up with this variation of HAM because I thought it might be fun and liked the symmetry of it, a bit like the original HAM6.

Well, this is the "natural" evolution of HAM for 15-bit RGB.

@cdimauro

Quote:

I've written an article about HAM mode and games, taking Hamulet as an example: Amiga in modalità HAM: gioia per gli occhi, ma per pochi giochi It's in Italian, but it can be easily translated with DeepL, Google Translate, ...

That was a good/insightful read, thanks!

I sense some parallelism between HAM and how JPEG handle images, HAM assets could be made so that they take into consideration HAM limitations so that fringe could be less.

Last edited by pixie on 24-Jun-2023 at 09:48 AM.

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@cdimauro

Moreso than the natural evolution for 15-bit, for 8-bit chunky source pixels too. Unlike HAM8, where you can only adjust the most significant 6 bits of an 8-bit channel value.

What I need to do to properly evaluate it is to create a tool for turning RGB images into this format. The first step is to dither down from 24-bit to 15-bit (a job for imagemagick or similar). Next, construct an optimum palette of 32 15-bit colours, ignoring any greyscales.

The process should then encode the image row by row, choosing for the leftmost pixel the best palette or greyscale value for that pixel. Next you could try to find the best palette/grey or ham modification that gets you closest to the target 15 bit value in the RGB image. Since this is all precomputed, it could just brute force this search. Repeat until the row is done.

Last edited by Karlos on 24-Jun-2023 at 12:20 PM.

_________________
Doing stupid things for fun...

@pixie

Quote:

pixie wrote: @cdimauro Quote: I've written an article about HAM mode and games, taking Hamulet as an example: Amiga in modalità HAM: gioia per gli occhi, ma per pochi giochi It's in Italian, but it can be easily translated with DeepL, Google Translate, ... That was a good/insightful read, thanks! I sense some parallelism between HAM and how JPEG handle images, HAM assets could be made so that they take into consideration HAM limitations so that fringe could be less.

Yes, more or less.
With JPEG you pay for reducing the details with more bitrate AKA space required.
With HAM you pay for reducing the fringing with reducing the details.

@Karlos

Quote:

Karlos wrote: @cdimauro Moreso than the natural evolution for 15-bit, for 8-bit chunky source pixels too.

That's a perfect match: 3 control bits + 5 "selection" bits = 1 byte can be used to efficiently save & manipulate the information.
Quote:

Unlike HAM8, where you can only adjust the most significant 6 bits of an 8-bit channel value.

That was a compromise, because HAM10 (2 + 8 bits) wasn't possible (at least with AGA).
Quote:

What I need to do to properly evaluate it is to create a tool for turning RGB images into this format. The first step is to dither down from 24-bit to 15-bit (a job for imagemagick or similar). Next, construct an optimum palette of 32 15-bit colours, ignoring any greyscales. The process should then encode the image row by row, choosing for the leftmost pixel the best palette or greyscale value for that pixel. Next you could try to find the best palette/grey or ham modification that gets you closest to the target 15 bit value in the RGB image. Since this is all precomputed, it could just brute force this search. Repeat until the row is done.

Hum. Since you're working on a row basis, do you plan to realized something like S-HAM (redefining each time the 32 entries in the colours palette)?

BTW, you can also try an HAM7 (like the regular HAM: 2 control bits) and make a comparison with your HAM8 in terms of PSNR. So, to see if there is or not much difference with the quality of the generated.
HAM7 is more efficient in terms of needed space, but it's more subject to artifacts. Your HAM8 takes more space, but it gives less artifacts.
However on real-world image it should interesting to be seen what's worth: more space or more quality.

@cdimauro

It is possible to do SHAM with this model because there's already a beam racing "copper" function that can modify palette entries (including performing colour addition and subtraction).

_________________
Doing stupid things for fun...

@cdimauro

Quote:

Yes, more or less. With JPEG you pay for reducing the details with more bitrate AKA space required. With HAM you pay for reducing the fringing with reducing the details.

In modern PC and game console gaming with DirectX12U, variable-rate shading reduces the effective shading resolution on a selected area.

Sony's Spiderman for PS5 has a 4K raster render with 1080p raytraced reflections. RDNA 2's raytracing capability is below par when compared to its NVIDIA counterpart. PS5's GPU is equivalent to PC's RX 6700 level GPU.

Motion vectors are part of pixel reconstruction techniques. Advanced pixel reconstruction techniques have AI-based deep learning e.g. NVIDIA DLSS and "RTX super-resolution" features for video playback.

Pixel reconstruction can introduce artifacts. Resource conservation methods still exist on modern hardware.

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

@Karlos

Quote:

Karlos wrote: @cdimauro It is possible to do SHAM with this model because there's already a beam racing "copper" function that can modify palette entries (including performing colour addition and subtraction).

Nice: like our beloved machines.

However and if you plan to collect some stats / make comparisons, it'd good to have them for the regular (non S-variant) mode first, because it's the one which has better chances to be used on games (so that the free slots on each raster line can be used for controlling the sprites).


@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Yes, more or less. With JPEG you pay for reducing the details with more bitrate AKA space required. With HAM you pay for reducing the fringing with reducing the details. In modern PC and game console gaming with DirectX12U, variable-rate shading reduces the effective shading resolution on a selected area. Sony's Spiderman for PS5 has a 4K raster render with 1080p raytraced reflections. RDNA 2's raytracing capability is below par when compared to its NVIDIA counterpart. PS5's GPU is equivalent to PC's RX 6700 level GPU. Motion vectors are part of pixel reconstruction techniques. Advanced pixel reconstruction techniques have AI-based deep learning e.g. NVIDIA DLSS and "RTX super-resolution" features for video playback. Pixel reconstruction can introduce artifacts. Resource conservation methods still exist on modern hardware.

Correct, but artifacts on HAM are "built-in" e unavoidable (unless you strongly hit the artistic side of the graphics), whereas with the above resources / techniques there's a lot of control on defining / tuning the graphics details.

P.S. Unfortunately AMD's GPUs are on RT well below compared to nVidia's ones. Not even counting the DLSS.
Actually the "RT market" is substantially monopolized by nVidia.
However it was a surprise to see that Intel's first discrete GPUs had a good RT support (albeit Intel's primary problem is... drivers!).

@cdimauro

Quote:

Correct, but artifacts on HAM are "built-in" e unavoidable (unless you strongly hit the artistic side of the graphics), whereas with the above resources / techniques there's a lot of control on defining / tuning the graphics details.

HAM mode works okay as long the CPU generates a frame for HAM mode consumption in a timely manner.

Against VGA 256 color mode PC DOS games, AGA doesn't need to switch to HAM mode. The problem moves towards the math compute problem and this is a major issue for the Amiga.

Modern PC GPUs have "Delta Color Compression" to conserve memory bandwidth and cache storage i.e. brute force with resource conservation. Texture compression can have artifacts when aggressive compression is used. It depends on the game development team's direction who can balance between hardware capability targets and artwork quality.

Quote:

P.S. Unfortunately AMD's GPUs are on RT well below compared to nVidia's ones. Not even counting the DLSS.

RDNA 3 has discrete WMMA for the tensor workload, but without software, it's nearly pointless.

For the Stable Diffusion deep learning benchmark, RX 7900 XTX delivered RTX 3090 Ti performance.
https://i.gzn.jp/img/2023/01/26/stable-diffusion-gpu-benchmarks/01.png
Stable Diffusion iteration per second
RTX 4090 = 29,923
RTX 4080 = 23,504
RTX 4070 Ti = 20,697
RX 7900 XTX = 19,296
RTX 3090 Ti = 19,238
RX 6950 XT = 4,382
Intel Arc 770 = 2,219

AMD's RDNA 3 is one generation behind NVIDIA's ADA. it comes down to hardware pricing for Stable Diffusion type workloads.

Quote:

Actually the "RT market" is substantially monopolized by nVidia.

https://www.phoronix.com/benchmark/result/radeon_rx_7900_xt_xtx_vs_nvidia_opencl_linux_compute/ae05ef28b3e0.svgz
Blender 3.4 Classroom benchmark (lower is better)
RTX 3080 Ti = 14.26 seconds (OptiX Linux)
RTX 3080 Ti = 20.78 seconds (OpenCL Linux)
RX 7900 XTX = 22.84 seconds (HIP Linux)

From https://www.phoronix.com/review/rx7900-blender-opencl/2
AMD's Blender raytracing acceleration is one generation behind ADA.

RX 7900 XTX has 24 GB VRAM for workstation high-textured modeling. It comes down to hardware pricing for the Blender raytracing workload. Running out of VRAM can result in a crash.

RTX 3090 Ti 24 GB VRAM is still good for Blender 3.4.

For Blender 3.4, AMD needs to fix its Windows HIP and forget about RDNA 2.

Quote:

However it was a surprise to see that Intel's first discrete GPUs had a good RT support (albeit Intel's primary problem is... drivers!).

Intel ARC 770 is not at RTX 3090 / RTX 3080 Ti GA102 level.

Last edited by Hammer on 27-Jun-2023 at 06:04 AM.
Last edited by Hammer on 27-Jun-2023 at 06:02 AM.
Last edited by Hammer on 27-Jun-2023 at 05:50 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)

@cdimauro

Quote:

My argument was this: "Playstation arrived later." Which means 1994. And it was / is true. Do you understand it?

That's the retail argument, not 3rd party development argument.

My point, Sony's PS1 was in the advanced development stage by the end of 1993.

System development and attracting 3rd party developers are not done by retail release schedules.

Commodore International was a headless chicken in 1994 and the critical Xmas 1993 sales target has been missed by a longshot.

Sony has an active PS1 public and 3rd party developer relations in 1993.

Quote:

Only 'til 1995.

System development and attracting 3rd party developers are not done by retail release schedules.

Sony has active PS1 public and 3rd party developer relations in 1993 and 1994.

Like Mehdi Ali, your failure to recognize this fact led to an uncompetitive baseline Amiga configuration. Your mindset is against Commodore UK MD David Pleasance's awareness of Sony's PS1 threat.

Both David Pleasance and Dave Haynie attempted to close the math compute gap.

Quote:

I know it very well. Have you ever took at look at it? How many moving objects are displayed?

Link Golf has slow gameplay like PC VGA point-and-click adventure games.

Amiga OCS handled the Time Gal laser disc game port in HAM6 mode.

Quote:

I beg to differ: I was shocked when Star Trek for PC was published.

Star Trek: 25th Anniversary was released in 1992 for PC DOS.

Amiga AGA port was released in 1994. Amigas with at least a 32-bit 68020 CPU can't run Star Trek: 25th Anniversary.

PC clones with 386 CPU can be upgraded with fast VGA clone cards and join the fun. I played Star Trek: 25th Anniversary playable demo on the 386DX PC and the fake 3D (2.5D) gameplay presentation was already done on Wing Commander.

Quote:

I reveal you a secret: FPU for V2 wasn't even planned! With its limited FPGA, it was already more than enough it was expected.

PADDING. This is why 68080 V2 being superior PR over 68060 is a load of BS. I canceled my Vampire 1200 V2 reserve for TF1260.

It's interesting to note that both Vampire-centric CoffinOS and CoffeineOS have softFPU ShapeShifter configs.

Prior to 52-bit FPU FPGA implementation, Gunnar hyped the software FPU solution along with GOLD 2.7 i.e. Femu. 68080 V2 has ~7.46 to 7.85 MFLOPS Femu in SysInfo while AIBB BeachBall for example shows that 68040 is still faster. I'm aware of both Jari Eskelinen and Renee (Buffee) Cousins' Femu builds.

Vampire 2 is the second release after Vampire 1 i.e. the first Vampire card was made for Amiga 600 with FPGA TG68. Refer to https://majsta.com/modules.php?name=News&file=categories&op=newindex&catid=9


Vampire 600 V1. "V2" label is version 2.

There was a fallout between Majsta and Gunnar, hence the minimization of the "Vampire" brand e.g. Apollo Computer's Apollo Standalone, IceDrake, Firebird, and Manticore.

I wasn't born yesterday. You're wrong.


Quote:

Ehi, "genius", I've just used the information reported on the link that YOU provided: https://amitopia.com/gold-2-11-is-out-for-68080-amiga-accelerator-users/ "Gold 2.11 is out for 68080 Amiga accelerator Users ON: OCTOBER 18, 2018 IN: VAMPIRE 68080"

If you actually read https://amitopia.com/gold-2-11-is-out-for-68080-amiga-accelerator-users/

FPU Issues fixed in Gold 2.11
* Added Out of Order Execution for FPU
* Improved FPU to 52bit precision

68080 FP64 do NOT exist in Gold 2.11. Date: OCTOBER 18, 2018


Your claim: "So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU.'

FALSE, FAKE NEWS.

On 14 Feb 2021 Gunnar Von Boehn said "R5 release supports 56 Bit FPU precision. The upcoming R6 release support 64-bit."

You are wrong.





Quote:

As above: irrelevant.

It's relevant.

Fact: Emu68 is free and there is no exchange of money for the offered product, hence there is no sales contract.

Fact: There is no sales contract between myself and Michal Schulz.

Fact: Emu64 and ARM Cortex A53 / Cortext A72 have the minimum FP64 threshold.

Fact: There is a sales contract between the Raspberry Pi vendor and myself.

Quote:

Again, irrelevant. You continuously bashed the Vampire for what is still missing on your beloved PiStorm. Incoherent!

What's the matter? Did I hurt your beloved Vampire feelings?

You can't handle the truth.

Your "beloved PiStorm" on me is FAKE NEWS.

For SoftFPU Shapeshifter, Emu68-RPi 4B can brute force that is faster than PowerPC 601 @ 60 Mhz FP results. Results from MacBench 4.0 that was included from CaffeineOS 921.

Facts don't care about your feelings.

Last edited by Hammer on 29-Jun-2023 at 04:03 AM.
Last edited by Hammer on 29-Jun-2023 at 04:01 AM.
Last edited by Hammer on 29-Jun-2023 at 03:54 AM.
Last edited by Hammer on 29-Jun-2023 at 03:44 AM.
Last edited by Hammer on 29-Jun-2023 at 03:41 AM.
Last edited by Hammer on 29-Jun-2023 at 03:40 AM.
Last edited by Hammer on 29-Jun-2023 at 03:34 AM.
Last edited by Hammer on 29-Jun-2023 at 03:32 AM.
Last edited by Hammer on 29-Jun-2023 at 03:29 AM.
Last edited by Hammer on 27-Jun-2023 at 08:39 AM.
Last edited by Hammer on 27-Jun-2023 at 08:39 AM.
Last edited by Hammer on 27-Jun-2023 at 08:31 AM.
Last edited by Hammer on 27-Jun-2023 at 08:29 AM.
Last edited by Hammer on 27-Jun-2023 at 08:11 AM.
Last edited by Hammer on 27-Jun-2023 at 08:01 AM.
Last edited by Hammer on 27-Jun-2023 at 07:20 AM.
Last edited by Hammer on 27-Jun-2023 at 07:18 AM.
Last edited by Hammer on 27-Jun-2023 at 07:16 AM.
Last edited by Hammer on 27-Jun-2023 at 07: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)

@cdimauro

Quote:

cdimauro wrote: There was no "context" before: you continuously bashed and hit the Vampire because of its FPU. Now you completely changed your mind and became a PiStorm evangelist, which suffers from exactly the same issues.

Hm, no, no it doesn't, not at all the same issues.

Quote:

I reveal you a secret: FPU for V2 wasn't even planned!

Only because nothing is ever _planned_ in that camp, everything is ad-hoc.

But.. FPU was spoken of - A LOT !
First it was "it is ready, just needs testing"
Then it was "we just need test cases, please submit"
Then "It will be rewritten, and it will be amazing!!!111"
Then "Stop naging - 99.99% of Amiga software doesn't need FPU!!11"
Then "FPGA is full!! It wont fit! Use emulator, it will be blaaazingly fast with AMMX!!111"

Along came FEMU, showing exactly how blazingly fast it would be, so...

- "FEMU is awesome! We have FPU! We finally have code!! It will become awesome!" (well, if _emulator_ was what he wanted all the time, why didn't he just ask for it in the first place, rather than the vague "we need test code"?)
- "We are improving FEMU with AMMX code, it will be magnificent!"
- "We are implementing parts of FEMU in the Apollo Core, just you wait and see!"
- "We are implementing thw whole FPU in Apollo Core!!"
(by magic there was suddenly space for it)
- "Quake works!!!"

And that's pretty much how it was communicated.

Quote:

With its limited FPGA, it was already more than enough it was expected. And V2 was the first product.

No, V2 was second, or even third product.

There was obviously "V1", Majsta's first Vampire cards for A600, which first used TG68 and then in "apollo core land" was limited to the scaled down Phoenix core. This was exactly what the V2 was supposed to solve - the V2 was supposed to have an FPGA big enough to fit "the full" Apollo Core 68080 - and that includes FPU, which at the time was bespoken as "almost ready". The whole AGA and chipset through HDMI was slapped on in the typical ad-hoc "yeah, sure, why not!!" fashion.

But then there was also another product... or attempt thereof, the Natami, which luckily never really hit the market.

The V2 ended up just becoming what it was supposed to fix, and the V4 cards aren't much better in that regard - "affordable" and "abailable"?

Quote:

I reveal you another secret: neither Emu68 had FPU support at the beginning.

In the beginning, Emu68 wasn't even connected to an Amiga.

But what took the Apollo Team a decade (and more, really), PiStorm and Emu68 has achieved in _MUCH_ shorter time span.

Quote:

So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU.

And I had my arguments with Gunnar over the FPU many years before that.

Quote:

Irrelevant regarding this specific topic (which is: YOU bashed Vampire for this!).

You are right, there are so many other things one can bash the Apollo Core for.

Quote:

You continuously bashed the Vampire for what is still missing on your beloved PiStorm. Incoherent!

And what could that be? "Fighting Spirit" optimized for the V4 and AMMX? :)

Last edited by kolla on 27-Jun-2023 at 02:04 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: Correct, but artifacts on HAM are "built-in" e unavoidable (unless you strongly hit the artistic side of the graphics), whereas with the above resources / techniques there's a lot of control on defining / tuning the graphics details. HAM mode works okay as long the CPU generates a frame for HAM mode consumption in a timely manner.

Which was NOT the case AT THE TIME.
Quote:

Against VGA 256 color mode PC DOS games, AGA doesn't need to switch to HAM mode.

AGA already had 256 colours, so HAM wasn't needed anyway.

Plus, there was no processing power for generating HAM screens, as I've already stated several times.
Quote:

The problem moves towards the math compute problem and this is a major issue for the Amiga.

Exactly. So why do you continue to talk about totally unrealistic / historically non-existent contexts?
Quote:

Modern PC GPUs have "Delta Color Compression" to conserve memory bandwidth and cache storage i.e. brute force with resource conservation. Texture compression can have artifacts when aggressive compression is used. It depends on the game development team's direction who can balance between hardware capability targets and artwork quality.

That's modern stuff. So, out of the above discussion.
Quote:

Quote: P.S. Unfortunately AMD's GPUs are on RT well below compared to nVidia's ones. Not even counting the DLSS. RDNA 3 has discrete WMMA for the tensor workload, but without software, it's nearly pointless. For the Stable Diffusion deep learning benchmark, RX 7900 XTX delivered RTX 3090 Ti performance. https://i.gzn.jp/img/2023/01/26/stable-diffusion-gpu-benchmarks/01.png Stable Diffusion iteration per second RTX 4090 = 29,923 RTX 4080 = 23,504 RTX 4070 Ti = 20,697 RX 7900 XTX = 19,296 RTX 3090 Ti = 19,238 RX 6950 XT = 4,382 Intel Arc 770 = 2,219 AMD's RDNA 3 is one generation behind NVIDIA's ADA. it comes down to hardware pricing for Stable Diffusion type workloads. Quote: Actually the "RT market" is substantially monopolized by nVidia. https://www.phoronix.com/benchmark/result/radeon_rx_7900_xt_xtx_vs_nvidia_opencl_linux_compute/ae05ef28b3e0.svgz Blender 3.4 Classroom benchmark (lower is better) RTX 3080 Ti = 14.26 seconds (OptiX Linux) RTX 3080 Ti = 20.78 seconds (OpenCL Linux) RX 7900 XTX = 22.84 seconds (HIP Linux) From https://www.phoronix.com/review/rx7900-blender-opencl/2 AMD's Blender raytracing acceleration is one generation behind ADA. RX 7900 XTX has 24 GB VRAM for workstation high-textured modeling. It comes down to hardware pricing for the Blender raytracing workload. Running out of VRAM can result in a crash. RTX 3090 Ti 24 GB VRAM is still good for Blender 3.4. For Blender 3.4, AMD needs to fix its Windows HIP and forget about RDNA 2.

First, I was talking about games, not applications.

Second, you're comparing the latest AMD GPU with the previous generation from nVidia.
Quote:

Quote: However it was a surprise to see that Intel's first discrete GPUs had a good RT support (albeit Intel's primary problem is... drivers!). Intel ARC 770 is not at RTX 3090 / RTX 3080 Ti GA102 level.

It was never meant to be.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: My argument was this: "Playstation arrived later." Which means 1994. And it was / is true. Do you understand it? That's the retail argument, not 3rd party development argument. My point, Sony's PS1 was in the advanced development stage by the end of 1993. System development and attracting 3rd party developers are not done by retail release schedules. Commodore International was a headless chicken in 1994 and the critical Xmas 1993 sales target has been missed by a longshot. Sony has an active PS1 public and 3rd party developer relations in 1993.

OK, and? We already know that Commodore missed xmas '93 market, which was a bit punch to its business.
Quote:

Quote: Only 'til 1995. System development and attracting 3rd party developers are not done by retail release schedules. Sony has active PS1 public and 3rd party developer relations in 1993 and 1994.

See above.
Quote:

Like Mehdi Ali, your failure to recognize this fact

My failure? Where? QUOTE me and PROVE IT!
Quote:

led to an uncompetitive baseline Amiga configuration.

Really? Those are "news"...
Quote:

Your mindset is against Commodore UK MD David Pleasance's awareness of Sony's PS1 threat.

Same as above: never stated something like that. QUOTE me and PROVE IT!
Quote:

Both David Pleasance and Dave Haynie attempted to close the math compute gap.

And?
Quote:

Quote: I know it very well. Have you ever took at look at it? How many moving objects are displayed? Link Golf has slow gameplay like PC VGA point-and-click adventure games.

PC's point-and-click adventures weren't slow.

And, again, you have never played to Link Golf, so you don't know how slow it was to compute the scene each time, otherwise we weren't here still talking about it.
Quote:

Amiga OCS handled the Time Gal laser disc game port in HAM6 mode.

I don't know it. If it was using static images with some sprites, then it's ok: perfectly feasible in HAM.
Quote:

Quote: I beg to differ: I was shocked when Star Trek for PC was published. Star Trek: 25th Anniversary was released in 1992 for PC DOS.

Right. I was recalling badly (the year. No the shock).
Quote:

Amiga AGA port was released in 1994. Amigas with at least a 32-bit 68020 CPU can't run Star Trek: 25th Anniversary.

What were the Amiga port's requirements?
Quote:

PC clones with 386 CPU can be upgraded with fast VGA clone cards and join the fun. I played Star Trek: 25th Anniversary playable demo on the 386DX PC and the fake 3D (2.5D) gameplay presentation was already done on Wing Commander.

Not news...
Quote:

Quote: I reveal you a secret: FPU for V2 wasn't even planned! With its limited FPGA, it was already more than enough it was expected. PADDING.

?!? This was a FACT!
Quote:

This is why 68080 V2 being superior PR over 68060 is a load of BS.

And... who cares? V2 was very good for what it promised and went beyond the expectations.
Quote:

I canceled my Vampire 1200 V2 reserve for TF1260.

And ordered a PiStorm which... suffers from exactly the same problems: "coherent"...
Quote:

It's interesting to note that both Vampire-centric CoffinOS and CoffeineOS have softFPU ShapeShifter configs.

And?
Quote:

Prior to 52-bit FPU FPGA implementation, Gunnar hyped the software FPU solution along with GOLD 2.7 i.e. Femu. 68080 V2 has ~7.46 to 7.85 MFLOPS Femu in SysInfo while AIBB BeachBall for example shows that 68040 is still faster. I'm aware of both Jari Eskelinen and Renee (Buffee) Cousins' Femu builds.

And?
Quote:

Vampire 2 is the second release after Vampire 1 i.e. the first Vampire card was made for Amiga 600 with FPGA TG68. Refer to https://majsta.com/modules.php?name=News&file=categories&op=newindex&catid=9 Vampire 600 V1. "V2" label is version 2.

And?
Quote:

There was a fallout between Majsta and Gunnar, hence the minimization of the "Vampire" brand e.g. Apollo Computer's Apollo Standalone, IceDrake, Firebird, and Manticore.

After that they split there's no Vampire brand on the Apollo products.
Quote:

I wasn't born yesterday.

Same for me, but you're aging very badly.
Quote:

You're wrong.

On what?!? QUOTE me and PROVE IT!
Quote:

Quote: Ehi, "genius", I've just used the information reported on the link that YOU provided: https://amitopia.com/gold-2-11-is-out-for-68080-amiga-accelerator-users/ "Gold 2.11 is out for 68080 Amiga accelerator Users ON: OCTOBER 18, 2018 IN: VAMPIRE 68080" If you actually read https://amitopia.com/gold-2-11-is-out-for-68080-amiga-accelerator-users/ FPU Issues fixed in Gold 2.11 * Added Out of Order Execution for FPU * Improved FPU to 52bit precision 68080 FP64 do NOT exist in Gold 2.11. Date: OCTOBER 18, 2018 Your claim: "So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU.' FALSE, FAKE NEWS. On 14 Feb 2021 Gunnar Von Boehn said "R5 release supports 56 Bit FPU precision. The upcoming R6 release support 64-bit." You are wrong.

How much ignorance you continue to show. You don't even understand the difference between 64-bit FPU and 52/56 bit PRECISION.

Here's how the FP64 data type is made:


52-bit precision is MATCHING the FP64 datatype! So, it was perfectly matching what I've said before, that I report here for your convenience:

So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU.

Understood, "genius"?
Quote:

Quote: As above: irrelevant. It's relevant.

No, still irrelevant.
Quote:

Fact: Emu68 is free and there is no exchange of money for the offered product, hence there is no sales contract.

Which is still irrelevant.
Quote:

Fact: There is no sales contract between myself and Michal Schulz.

Irrelevant.
Quote:

Fact: Emu64 and ARM Cortex A53 / Cortext A72 have the minimum FP64 threshold.

Same for the Vampire. See above, ignorant!
Quote:

Fact: There is a sales contract between the Raspberry Pi vendor and myself.

Again, Irrelevant.
Quote:

Quote: Again, irrelevant. You continuously bashed the Vampire for what is still missing on your beloved PiStorm. Incoherent! What's the matter?

The matter is that you're totally INCOHERENT because your PiStorm has the SAME problems of the Vampire that YOU HEAVLY BASHED IN THE PAST.

Do you understand now, or should I report it EACH TIME? Bad aging?
Quote:

Did I hurt your beloved Vampire feelings?

My beloved? Vampire? STRA-LOL!

You don't know of what you talk about!!!

Why don't you ask Gunnar how much I love the Vampire? Or, you may ask Kolla as well.

Bad aging? Or you're simply a complete ignorant?
Quote:

You can't handle the truth.

I can. Care to explain?
Quote:

Your "beloved PiStorm" on me is FAKE NEWS.

Rather no, as you continue to heavily support it and you report it continuously, whereas in the near (not even that long) YOU BASHED THE VAMPIRE FOR EXACTLY THE SAME ISSUES!
Quote:

For SoftFPU Shapeshifter, Emu68-RPi 4B can brute force that is faster than PowerPC 601 @ 60 Mhz FP results. Results from MacBench 4.0 that was included from CaffeineOS 921.

And? WHO CARES?!?
Quote:

Facts don't care about your feelings.

My feelings are the ones which I've reported again and that show that you're INCOHERENT!

@kolla

Quote:

kolla wrote: @cdimauro Quote: cdimauro wrote: There was no "context" before: you continuously bashed and hit the Vampire because of its FPU. Now you completely changed your mind and became a PiStorm evangelist, which suffers from exactly the same issues. Hm, no, no it doesn't, not at all the same issues.

The issues are related to the lack of FP96 support and PMMU and Hammer explicitly talked about those things in the past.
Quote:

Quote: I reveal you a secret: FPU for V2 wasn't even planned! Only because nothing is ever _planned_ in that camp, everything is ad-hoc.

Then, what's the problem?
Quote:

But.. FPU was spoken of - A LOT ! First it was "it is ready, just needs testing" Then it was "we just need test cases, please submit" Then "It will be rewritten, and it will be amazing!!!111" Then "Stop naging - 99.99% of Amiga software doesn't need FPU!!11" Then "FPGA is full!! It wont fit! Use emulator, it will be blaaazingly fast with AMMX!!111" Along came FEMU, showing exactly how blazingly fast it would be, so... - "FEMU is awesome! We have FPU! We finally have code!! It will become awesome!" (well, if _emulator_ was what he wanted all the time, why didn't he just ask for it in the first place, rather than the vague "we need test code"?) - "We are improving FEMU with AMMX code, it will be magnificent!" - "We are implementing parts of FEMU in the Apollo Core, just you wait and see!" - "We are implementing thw whole FPU in Apollo Core!!" (by magic there was suddenly space for it) - "Quake works!!!" And that's pretty much how it was communicated.

I know it very well, since I'm following the Apollo forum since it was born (and the Natami one as well).

However and as I've said before, the FPU was never planned and the original plan (read: first announcements) never reported it.

That was/is the point.
Quote:

Quote: With its limited FPGA, it was already more than enough it was expected. And V2 was the first product. No, V2 was second, or even third product.

I was talking about the products released by the Apollo team. NOT about Majista's first product, which was his own only.
Quote:

There was obviously "V1", Majsta's first Vampire cards for A600, which first used TG68 and then in "apollo core land" was limited to the scaled down Phoenix core. This was exactly what the V2 was supposed to solve - the V2 was supposed to have an FPGA big enough to fit "the full" Apollo Core 68080 - and that includes FPU, which at the time was bespoken as "almost ready". The whole AGA and chipset through HDMI was slapped on in the typical ad-hoc "yeah, sure, why not!!" fashion. But then there was also another product... or attempt thereof, the Natami, which luckily never really hit the market. The V2 ended up just becoming what it was supposed to fix, and the V4 cards aren't much better in that regard - "affordable" and "abailable"?

I know it very well, but see above.
Quote:

Quote: I reveal you another secret: neither Emu68 had FPU support at the beginning. In the beginning, Emu68 wasn't even connected to an Amiga. But what took the Apollo Team a decade (and more, really), PiStorm and Emu68 has achieved in _MUCH_ shorter time span.

Clap clap clap: hardware vs software implementation...
Quote:

Quote: So, it's since 5 (FIVE) years that the 68080 support a 64-bit FPU. And I had my arguments with Gunnar over the FPU many years before that.

See above.
Quote:

Quote: Irrelevant regarding this specific topic (which is: YOU bashed Vampire for this!). You are right, there are so many other things one can bash the Apollo Core for.

I know it, but that wasn't the point of the discussion with Hammer.
Quote:

Quote: You continuously bashed the Vampire for what is still missing on your beloved PiStorm. Incoherent! And what could that be? "Fighting Spirit" optimized for the V4 and AMMX? :)

?!? Too much vodka?

@cdimauro

Quote:

My failure? Where? QUOTE me and PROVE IT!

You argued
"Playstation arrived later."
Which means 1994. And it was is true.

The gaming platform's existence is NOT done at "retail release schedules". Sony made sure PlayStation's retail introduction has good games when PS1 was released into retail i.e. don't repeat 3DO's retail release debacle.

Sony has an active PS1 public and 3rd party developer program in 1993. Sony's PS1 was in the advanced development stage by the end of 1993.

My argument is based on Commodore UK MD David Pleasance's story about losing 3rd party developers to Sony's camp after 3rd party developer's disastrous meeting with Commodore International CEO Mehdi Ali. The argument is about re-establishing new baseline math compute power for the A1200 games bundle.

Commodore International was a headless chicken in 1994 and the critical Xmas 1993 sales target has been missed by a longshot.

There are many ex-Amiga users like myself have switched to non-Amiga platforms in 1993!
In 1993 Australia, A1200's price is not price competitive against 386DX-33 and 486SX-25 PC clones.

AAA's display capability is nothing with C='s hobbled 68EC020 CPU configuration!

Quote:

PC's point-and-click adventures weren't slow.

PC VGA's slow gameplay point-and-click adventures examples are Eye of the Beholder (1991), King Quest V (1990), King Quest VI (1992), Universe (1994), and 'etc'.

PC's 1991 Eye of the Beholder runs in PC's VGA 256-color mode and it's the superior version.

PC Eye of the Beholder VGA and Eye of the Beholder II VGA was ported to the Amiga AGA in 2006.

Quote:

And, again, you have never played to Link Golf, so you don't know how slow it was to compute the scene each time, otherwise we weren't here still talking about it.

Amiga's 1992 Links: The Challenge of Golf's HAM mode performance is okay with A3000 with 68030 @ 25 Mhz.

Don't "you have never played to Link Golf" assume since it makes you look like a fool.

A3000's Chip RAM performance is superior to the earlier 16-bit Amigas (e.g. run the bustest chip benchmark) and my A3000 has a 4MB static column ZIP Fast RAM upgrade. For this game, A3000 performs like a PC 386DX-25 with a clone VGA.

PC DOS has Links: The Challenge of Golf in 1990 and Links 386 Pro in 1992.

For Links: The Challenge of Golf game, the hardware requirements and recommendations are similar for Amiga and PC.

In terms of performance, my 386DX-33 with ET4000AX PC clone will destroy my A1200 with 4 MB of Fast RAM (I purchased Amiga Kit 8 MB Fast RAM board). A1200 needs 68030 at 40 Mhz based accelerator to match it.

A1200 with 28 Mhz 68020 with 4 MB 32-bit Fast RAM acts like my old A3000 but with a working 256-color gaming mode.

A1200 with 25 Mhz 68020 / 68030 performance for Wing Commander AGA (WHDLoad) is similar to the 386DX-25 VGA version and pretty smooth at this hardware level.


Quote:

And ordered a PiStorm which... suffers from exactly the same problems: "coherent"...

1. Both PiStorm (gateway adapter board) and Emu68 are open-source projects with no end-user obligations.

2. Emu68 with stock RPI 4B can brute force softFPU Shapeshifter's MacOS 7.5 and 8.1 faster than PowerMac's PowerPC 601 FPU. RPI 4B fits within the stock Amiga 500's PSU wattage.

Vampire V2's Femu slower than 68040 CPU is LOL.

Vampire V2 is the second project, hence the V2. You're wrong and unreliable.

Did you assume I'm not aware of Femu when I initially have 68LC060 Rev4 with TF1260 while my full 68060 CPU was in transit?

For the timeline context, my return to Amiga hardware is part of my COVID-19 lockdown projects.

Quote:

52-bit precision is MATCHING the FP64 datatype! So, it was perfectly matching what I've said before, that I report here for your convenience:

Wrong.

Double-precision floating-point format (sometimes called FP64 or float64) is a floating-point number format, usually occupying 64 bits in computer memory.

In IEEE 754 double precision the 64 bits are:- 1 sign bit, 11 exponent bits, and 52 mantissa bits.

http://www.apollo-core.com/knowledge.php?b=4¬e=34161&z=XSwuLb

Hint: V4 was later updated with FP64 support with R6

Gunnar von Boehn: R5 release supports 56 Bit FPU precision. The upcoming R6 release support 64 bit.
Date: 14 Feb 2021.

Again, Vampire V2's FP52 doesn't match the FP64 threshold. You're wrong again and unreliable.

Gunnar's R6's 64-bit FPU support announcement in Feb 2021 wreaked your narrative.

I reactivated my A500 sometime in 2019 and I purchased my "broken for parts" A1200 (it was working since the seller is an Amiga noob.) in the middle of 2020.

Emu68's prerelease preview (Emu68-binaries-v0.1-alpha.zip) was released on Dec 1, 2019.
Before Emu68, it was Musashi for the PiStorm with RPI 3A+ configuration. PiStorm with RPI 3A+ hardware combo remained the same for both Musashi and Emu68 software. Vampire V2 reached its dead-end state with an FPGA limit.

Last edited by Hammer on 04-Jul-2023 at 02:16 AM.
Last edited by Hammer on 03-Jul-2023 at 08:09 AM.
Last edited by Hammer on 03-Jul-2023 at 08:06 AM.
Last edited by Hammer on 03-Jul-2023 at 08:02 AM.
Last edited by Hammer on 03-Jul-2023 at 07:43 AM.
Last edited by Hammer on 03-Jul-2023 at 07:37 AM.
Last edited by Hammer on 03-Jul-2023 at 07:37 AM.
Last edited by Hammer on 03-Jul-2023 at 07:33 AM.
Last edited by Hammer on 03-Jul-2023 at 07: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)

@cdimauro

Since Doom started the planar vs chunky debate.

Quote:

Which was NOT the case AT THE TIME.

That's a red herring.

My point, Amiga 1985 HAM mode continues to scale with CPU power better than the original IBM's 1987 VGA.

The planar vs chunky is dependent on actual hardware implementation.

AAA display is nearly useless with C='s hobbled 68EC020 CPU.

AAA display with 68EC020 @ 14 Mhz will have a shit Doom experience i.e. this is like having 386SX-16 with fast VGA mode ET4000AX PC configuration.

Amiga 500 can sustain HAM frame rates (HAM formatted framebuffers being copied from Fast RAM) at playable frame rates. Compute power is needed for geometry, texture, and basic color shading.

Quote:

AGA already had 256 colours, so HAM wasn't needed anyway. Plus, there was no processing power for generating HAM screens, as I've already stated several times.

For OCS/ECS Amigas, some of Amiga's Doom ports can run with 6-bitplane EHB and 3rd party Graffiti modes.

I wouldn't need to cite a Quake example when there's a Doom port that runs in HAM6 (6-bitplane) mode.

Quote:

Exactly. So why do you continue to talk about totally unrealistic / historically non-existent contexts?

That's a red herring.

It seems I need to contact Sam's Quake port and port the fucking HAM6 render for Doom!

Amiga 500 can sustain HAM frame rates (HAM formatted framebuffers being copied from Fast RAM) at playable frame rates.

Compute power for geometry, texture, and basic color shading is a separate debate.

Last edited by Hammer on 03-Jul-2023 at 08:39 AM.
Last edited by Hammer on 03-Jul-2023 at 08:31 AM.
Last edited by Hammer on 03-Jul-2023 at 08:30 AM.
Last edited by Hammer on 03-Jul-2023 at 08:29 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)

I think we can all agree that the appearance of accelerators like the PiStorm with their huge compute reserves makes even some of the most outlandish ideas possible. Quake running fast in HAM6 on an OCS A500? You got it.

This is a great time to be a 68K Amiga enthusiast.

_________________
Doing stupid things for fun...