Continuing the discussion from here: https://amigaworld.net/modules/newbb/viewtopic.php?mode=viewtopic&topic_id=45508&forum=16&start=500&viewmode=flat&order=0#880971

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: But there were two problems with HAM8: it was only useful for static images, and it was still... bitplane-based (which can cause flickering issues, due to bitplanes which should be individually updated and that can get out of sync with the display). Without a large CPU boost,

For doing what, converting a 12 / 24 bit framebuffer to HAM / HAM8 with brute force to overcome their limits? That wasn't the Amiga way.
Quote:

https://www.youtube.com/watch?v=Fcx5tyAZTQ4 Amiga's Time Gal AGA example Amiga AGA can do pre-baked full motion HAM8 laser disc-style games. The problem is the Commodore's weak game content to drive platform sales for the anime "gooner" market.

Using pre-computed graphics for for HAM/HAM8 animations wasn't a problem and never under discussion: it was a good way to use those graphic modes.

Albeit the planar graphics wasted both space and bandwidth due to the minimum 16/32 pixels / bits alignment PER bitplane: a packed/chunky version would have been way more efficient (as almost always, with planar vs packed graphic).

@cdimauro

Quote:

For doing what, converting a 12 / 24 bit framebuffer to HAM / HAM8 with brute force to overcome their limits?

Samuel Devulder's Quake port uses a 256-color framebuffer before converting to a HAM framebuffer.

Quote:

That wasn't the Amiga way.

HAM is part of the Amiga's value add.

The problem is CPU power, which is not Commodore's area.

CD32's FMV module has a 24-bit display with a 16-bit bus, 80 ns access FPM DRAM.

Last edited by Hammer on 08-Sep-2025 at 06:19 PM.

_________________

@cdimauro

I don't really think HAM was intended for moving graphics, period. A lot of care has to be taken to avoid fringing artefacts. That said, what was or was not the "Amiga way" is a bit moot today. I actually quite like the fact that ludicrous (CPU) speed opens up new opportunities to experiment with this stuff.

_________________
Doing stupid things for fun...

@Karlos

The Black Lotus (TBL) has lots of HAM demos.

If it was made for moving graphics or not, I have no idea. but you are not required to make changes to all 6 bit plains at once. In fact if you can setup the color selection channels prior to drawing pixels.
You only need to set the upper bits in color channels. That manes you only need to change 1 bit plain this gives you 8 RGB colors. 2 bits per channel, that’s 64 RGB colors, 3 plains / 3 bits per channels thats 512 RGB colors, and all 4 data bits gives you 4096 colors..
the fewer bits you need to set, the faster it gets. If you only need to change 2 bit plains, you should not need a fast CPU.

But we talking about drawing modes that was not easily made available to developers of Amos or BlitzBasic, a standard plot commands will make changes to all 6 plains, instead of only a few bit plains. There is a mask options in AMOS, I’m going assume this is slow due to the number of tokens that needed to be interpreted.

Last edited by NutsAboutAmiga on 09-Sep-2025 at 06:03 PM.
Last edited by NutsAboutAmiga on 09-Sep-2025 at 04:41 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@cdimauro

https://www.youtube.com/watch?v=wv3OYbADkJQ

Mateusz Staniszew's HAM8 mode with a first-person shooter (FPS) presentation with V1200 (AC68080 V2) turbo card, but it can be just 68060 @ 50 MHz.

Mikael Kalms' C2P routines were used.

Using Emu68 is just overkill for a 320x256 HAM8 first-person shooter.

A1200 was designed with a local bus expansion edge connector for turbo cards.

-------------------
Modern PC GPUs have delta color compression (DCC) everywhere.

For AMD GPUs, https://tpucdn.com/gpu-specs/images-new/g/861-cache-diagram-large.jpg

For NVIDIA GPUs, https://www.notebookcheck.net/Nvidia-Pascal-Architecture-Overview.165493.0.html

https://www.notebookcheck.net/fileadmin/_processed_/csm_pascal_delta_color_compression_9def90e968.png

That's brute force with improved memory bandwidth conservation.

Amiga's HAM mode is an early compressed pixel format.

Last edited by Hammer on 10-Sep-2025 at 12:50 AM.

_________________

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: For doing what, converting a 12 / 24 bit framebuffer to HAM / HAM8 with brute force to overcome their limits? Samuel Devulder's Quake port uses a 256-color framebuffer before converting to a HAM framebuffer. Quote: That wasn't the Amiga way. HAM is part of the Amiga's value add.

Right, and I never argued against it.
Quote:

The problem is CPU power, which is not Commodore's area.

And not in the scope for the Amiga consumer / mainstream market.

Besides that, and as I've already stated, the chipset was introduced to OFFLOAD tasks from the CPU, whereas the Framebuffer -> HAM/HAM8 conversion heavily using the CPU goes in exactly the opposite direction.
Quote:

CD32's FMV module has a 24-bit display with a 16-bit bus, 80 ns access FPM DRAM.

Irrelevant: the context is reported just above.
Quote:

Hammer wrote: @cdimauro https://www.youtube.com/watch?v=wv3OYbADkJQ Mateusz Staniszew's HAM8 mode with a first-person shooter (FPS) presentation with V1200 (AC68080 V2) turbo card, but it can be just 68060 @ 50 MHz. Mikael Kalms' C2P routines were used. Using Emu68 is just overkill for a 320x256 HAM8 first-person shooter. A1200 was designed with a local bus expansion edge connector for turbo cards.

Nevertheless, you're wasting A LOT of CPU power to "solve" the HAM8 issues.

Better to use the expansion connector for a RTG card.
Quote:

------------------- Modern PC GPUs have delta color compression (DCC) everywhere. For AMD GPUs, https://tpucdn.com/gpu-specs/images-new/g/861-cache-diagram-large.jpg For NVIDIA GPUs, https://www.notebookcheck.net/Nvidia-Pascal-Architecture-Overview.165493.0.html https://www.notebookcheck.net/fileadmin/_processed_/csm_pascal_delta_color_compression_9def90e968.png That's brute force with improved memory bandwidth conservation. Amiga's HAM mode is an early compressed pixel format.

That's not brute force. And it also serves a different scope.

A better example would have been the texture compression algorithms which are implemented in hardware by GPUs since long time. But those pre-computed, like the regular HAM/HAM8 images which we enjoyed, so the CPU was NOT needed for brute force any framebuffer -> compressed texture, and the users just enjoy the opposite (real-time decompression of the compressed graphic).

@Karlos

Quote:

Karlos wrote: @cdimauro I don't really think HAM was intended for moving graphics, period. A lot of care has to be taken to avoid fringing artefacts.

Exactly.
Quote:

That said, what was or was not the "Amiga way" is a bit moot today. I actually quite like the fact that ludicrous (CPU) speed opens up new opportunities to experiment with this stuff.

Absolutely, and I've to say nothing about the results of those new accelerators, which help largely overcome the old chipset limitations.

However, those limits are due to the missed evolution(s) of the chipset: the Amiga platform is dead since long time, and NOW what people can do is trying to use is as much as possible with some benefits coming from different areas where improvements are still possible.

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos The Black Lotus (TBL) has lots of HAM demos. If it was made for moving graphics or not, I have no idea. but you are not required to make changes to all 6 bit plains at once. In fact if you can setup the color selection channels prior to drawing pixels. You only need to set the upper bits in color channels. That manes you only need to change 1 bit plain this gives you 8 RGB colors. 2 bits per channel, that’s 64 RGB colors, 3 plains / 3 bits per channels thats 512 RGB colors, and all 4 data bits gives you 4096 colors.. the fewer bits you need to set, the faster it gets. If you only need to change 2 bit plains, you should not need a fast CPU.

My understanding is that those demos gets different effects on screen by only changes some bitplanes of HAM images, instead of all 6.

Nothing to say also here: this is the only advantage which planar graphics had over packed/chunky graphics.

However, demos are... demos. Nothing really useful in the daily activities / needs.
Quote:

But we talking about drawing modes that was not easily made available to developers of Amos or BlitzBasic, a standard plot commands will make changes to all 6 plains, instead of only a few bit plains. There is a mask options in AMOS, I’m going assume this is slow due to the number of tokens that needed to be interpreted.

I don't know the internal implementation, but maybe AMOS can be tweaked/optimized on those cases.

@cdimauro

“I don't know the internal implementation�

Exactly, that’s part of the issue, it was created for beginners, but required low-level understanding to write extensions, also HAM it self requires users to understand boolean logic, unless you have taken a class in electronics, you wont be told any of this.

I used to found the documents about HAM technical and hard to understand,
and I’m sure a tutorials can have made things a lot more easier.

Chunky is a lot less technical to work with, no color blur, but needed more ram, as was generally not available as early to home users, I remember my first PC had CGA graphics.

We also did not have data types or space for it on workbench 1.2, nor did our 880k disks have space for data types, we used what the language provided, and for assembly programmers, it was common to convert images to raw format. and just import the binary.

In any case Amiga 500 was a slow computer.

Last edited by NutsAboutAmiga on 10-Sep-2025 at 03:59 PM.
Last edited by NutsAboutAmiga on 10-Sep-2025 at 03:56 PM.
Last edited by NutsAboutAmiga on 10-Sep-2025 at 03:55 PM.
Last edited by NutsAboutAmiga on 10-Sep-2025 at 03:52 PM.
Last edited by NutsAboutAmiga on 10-Sep-2025 at 03:47 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

HAM was something wonderfull.
It was designed in 1983 and gives Amiga thousands of colors.
But it was designed in 1983.
It should be retired in 1992.
Since 1992 Amiga should have new chipset with 16 bit chunky colors.

@ppcamiga1

No doubt, You can do lots of tricks to get amazing results, HAM was preferred method to display true color images, when true colors where not available.

But there was another method, that does create color blurring, but its not supported by paint program, and that having custom palette per scan line. Also tricky sense you will need to write your own image conversion tool. Or you need source image that’s true color, but will make it load the image slowly.
(can then use Floyd stein-berg dithering to improve gradients)

Perhaps you can can refresh colors just in time as well, methods like that require lots CPU power calculate when a color has to changed in-head of time.

Last edited by NutsAboutAmiga on 10-Sep-2025 at 07:37 PM.
Last edited by NutsAboutAmiga on 10-Sep-2025 at 07:33 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @cdimauro “I don't know the internal implementation� Exactly, that’s part of the issue, it was created for beginners, but required low-level understanding to write extensions, also HAM it self requires users to understand boolean logic, unless you have taken a class in electronics, you wont be told any of this.

Well, if you decide to work on the computer science field, then understanding the Boolean logic is bare minimum.
Quote:

I used to found the documents about HAM technical and hard to understand, and I’m sure a tutorials can have made things a lot more easier.

I think that the Hardware Manual have a good explanation of how the HAM mode works. It's pretty easy. I've also quickly implemented it in Python, when I've created an IFF loader for fun:

    def render_ham6(self, surface, x1, y1, y, row, mask_row):
        four_bits_palette = self.four_bits_palette
        r, g, b = four_bits_palette[0]
        for x, value in enumerate(row):
            component = value & 15
            match value >> 4:
                case 0:
                    r, g, b = four_bits_palette[component]
                case 1:
                    b = component
                case 2:
                    r = component
                case 3:
                    g = component
            if mask_row[x]:
                surface.set_at((x1 + x, y1 + y), (r + (r SHL 4), g + (g SHL 4), b + (b SHL 4)))

@ppcamiga1

Quote:

ppcamiga1 wrote: HAM was something wonderfull. It was designed in 1983 and gives Amiga thousands of colors. But it was designed in 1983. It should be retired in 1992.

No: it could/should stay.
Quote:

Since 1992 Amiga should have new chipset with 16 bit chunky colors.

ADDED to the existing graphic modes: se my comment on the other thread.