@mattheyQuote:

matthey wrote: OneTimer1 Quote: Thank you for proving my claim : It was a niche on a niche system ... None of this games where available in 1995 when AGA Amigas where still sold. As I explained, Amiga base specs were too low to support such games in 1995. The same was true for other demanding games which were released later or not at all for the Amiga. Sim City 2000 PC:1993 Mac:1993 Amiga:1994 (Amiga version inferior) Doom PC:1993 Mac:1995 Amiga:1997 (Amiga versions unofficial releases) Myst PC:1994 Mac:1993 Amiga:1998 Star Wars: Dark Forces PC:1995 Mac:1995 Amiga:2023? (Amiga version unofficial release) Command & Conquer PC:1995 Mac:1996 Amiga:2022? (unofficial Amiga Red Alert ports were earlier) Marathon 2: Durandal PC:1995 Mac:1995 Amiga:None Quake PC:1996 Mac:1997 Amiga:~1998 The lack of chunky was not as much of a limitation as the low CPU and chipset specs of the average Amiga which greatly reduced the Amiga market size for higher end games. Even the Mac, which previously was not known for games, had a larger 68040 install base with 8-bit chunky graphics that surpassed the Amiga on the high end with games. Mac had the Mac developed Myst in 1993 and Mac only Marathon starting in 1994 in addition to replacing the Amiga as a porting target for high end games in the 1990s. Low end Amiga gaming specs were a 68000@7MHz, OCS/ECS and 512kiB or 1MiB of memory and high end was a 68EC020@14MHz, AGA and 2MiB of memory in the early to mid 1990s. At the same time, PCs were being upgraded to 486s and Pentiums and Macs to 68040s all with 256 colors and chunky. HAM8 often looked better than 256 colors, somewhere between 16-bit and 24-bit chunky, while using less memory bandwidth but the advantage was lost by such low spec Amigas. Actual 16-bit chunky gaming started to appear for high end gaming in the mid to late 1990s as well as hardware 3D. Evidence suggests Commodore tried to wind down Amiga development while boosting PC development until the bottom dropped out of the commodity PC market leaving Amigas as the highest margin Commodore computers. The Amiga practically alone kept Commodore alive for awhile but the pause in already late Amiga development ended them.

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

cdimauro Quote:

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

Ever heard of interleaved bitmaps and how many flicker free, non-static and minimal fringe HAM examples do you need to dispel the misinformation that HAM is only useful for static images?

Quests Of Nargoth (AGA HAM8 - RPG Amiga game unreleased)
https://www.youtube.com/watch?v=wbWGAFIkA5E&list=PLRdmatuCYANuckM5c4yknkm7cXv9jIeow&index=2

My Raycaster Funtime #15 (Amiga 1200 AGA, Ham8 mode - over 10k colors)
https://www.youtube.com/watch?v=SwnDqj8pNe4

Commodore Amiga HAM8 Video (4,453,360 colors, FS-UAE) - Italobrothers - Summer Air
https://www.youtube.com/watch?v=nR3VC7QodFM&list=RDnR3VC7QodFM&start_radio=1

UBEK Polish HAM6 Wolfenstein engine type game
https://www.youtube.com/watch?v=Tk4_hxKfgWQ

Quake running Amiga 500's 4096 colors HAM mode with PiStorm / Emu68 CPU accelerator.
https://www.youtube.com/watch?v=btoU_CQSg7A

Blood attract loop Amiga HAM (UAE)
https://www.youtube.com/watch?v=RwFMz1bWpBg

Gameplay REM Game HAM - AMIGA - 720
https://www.youtube.com/watch?v=8mpYvDkt4lo&list=RD8mpYvDkt4lo&start_radio=1
https://eab.abime.net/showpost.php?p=1593880&postcount=1

Only the Amiga made it possible but Commodore made it impossible due to low spec CPUs, chipsets, memory and streaming drives (slow and non-existent HDs and lack of a CD-ROM standard). HAM and HAM8 modes were only useful for static images with the standard hardware specs Commodore gave us which could not even utilize 256 color modes. This does not mean HAM modes were useless for non-static images though. Most of the examples above work with chip memory bandwidth bottlenecked Amiga chipsets with CPU, memory and streaming drive upgrades. Chipset upgrades were likely the cheapest way to make HAM modes more useful though. Commodore missed a great opportunity with HAM modes.

@matthey

Quote:

matthey wrote: cdimauro Quote: 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). Ever heard of interleaved bitmaps

I've used them on my games, but they don't eliminate the problem: they only mitigate it.
Quote:

and how many flicker free, non-static and minimal fringe HAM examples do you need to dispel the misinformation that HAM is only useful for static images?

Let's see how is the real situation.
Quote:

Quests Of Nargoth (AGA HAM8 - RPG Amiga game unreleased) https://www.youtube.com/watch?v=wbWGAFIkA5E&list=PLRdmatuCYANuckM5c4yknkm7cXv9jIeow&index=2

060 emulated without JIT, also JIT enabled

Unreal machine which is using UAE -> super doped CPU which is taking care of the RGB -> HAM framebuffer conversion.

Anyway, the point here that there's a RGB -> HAM conversion, so completely generating the HAM image from scratch. Which, obviously, made static the final image...
Quote:

My Raycaster Funtime #15 (Amiga 1200 AGA, Ham8 mode - over 10k colors) https://www.youtube.com/watch?v=SwnDqj8pNe4

Real machine, but same as above (RGB-HAM), plus it limits the output to 10k colours instead of the 256k possible with HAM8.
Quote:

Commodore Amiga HAM8 Video (4,453,360 colors, FS-UAE) - Italobrothers - Summer Air https://www.youtube.com/watch?v=nR3VC7QodFM&list=RDnR3VC7QodFM&start_radio=1

Same as first:

played in the Amiga Emulator FS-UAE
Quote:

UBEK Polish HAM6 Wolfenstein engine type game https://www.youtube.com/watch?v=Tk4_hxKfgWQ

Real machine, but same as above (RGB-HAM) and very low resolution used (especially noticeable at the end, before the player dies: just take a look at how the enemy character is rendered: super pixelled).

Plus... where is the HAM6 4096 colours palette? A few colours are visible.
Quote:

Quake running Amiga 500's 4096 colors HAM mode with PiStorm / Emu68 CPU accelerator. https://www.youtube.com/watch?v=btoU_CQSg7A

PiStorm / Emu68 CPU accelerator...
Quote:

Blood attract loop Amiga HAM (UAE) https://www.youtube.com/watch?v=RwFMz1bWpBg

UAE...
Quote:

Gameplay REM Game HAM - AMIGA - 720 https://www.youtube.com/watch?v=8mpYvDkt4lo&list=RD8mpYvDkt4lo&start_radio=1 https://eab.abime.net/showpost.php?p=1593880&postcount=1

I've written two articles about it (available in English as well).

In short:
- sprites are heavily used for almost all animations;
- "BOBs" are statically pre-computed animations where the BOB graphic was already "fused" (cooike-cut) with the background;
- HAM's fringing on the left side is hidden by using a sprite to cover the first 16 pixels, when the screen scrolls;
- HAM's tile fringing is mitigated (but not eliminated: take a look at the details and you'll see it) by using a limited palette for the tiles, and carefully designing the tiles.

This is THE greatest piece of work using HAM, but nevertheless it shows all its limits.

And it's only usable on games like that, which are basically and entirely built around the HAM limitations (coders and graphic artists are both heavily limited on what they can do).
Quote:

Only the Amiga made it possible but Commodore made it impossible due to low spec CPUs, chipsets, memory and streaming drives (slow and non-existent HDs and lack of a CD-ROM standard). HAM and HAM8 modes were only useful for static images with the standard hardware specs Commodore gave us which could not even utilize 256 color modes. This does not mean HAM modes were useless for non-static images though. Most of the examples above work with chip memory bandwidth bottlenecked Amiga chipsets with CPU, memory and streaming drive upgrades. Chipset upgrades were likely the cheapest way to make HAM modes more useful though. Commodore missed a great opportunity with HAM modes.

I don't agree: see above my analysis.

And BTW: CPUs were limited at the time not only for the Amiga, but for competition as well. You got on your machine what could be afforded according to the specific market.

What the Amiga chipset needed for games like the above (with the exception of the last one) was primarily packed/chunky pixels to avoid the C2P conversion, which could have been easily added to the display controller logic.

And more sprites (as I've shown on my last series of articles), if you really wanted to use HAM for games.

@Thread

To all users of Ultimate 64 / Commodore C64u systems:

Quote:

Firmware version 3.12a - for All Platforms: U2, U2+, U2+L, U64 and U64E2! - Dated 2025-06-19 Click here to download This version also includes an update for the WiFi modules (U2+L, U64 and U64E2). This update might fail the first time around, because of the way the firmware 'talks' to the modules has changed. Just run the updater again, skip the primary update and then update the ESP32. It is highly recommended to update your Ultimate 64 Elite-II with this version after receiving it.

The homepage of commodore : https://www.commodore.com/ seems to be "slash-dotted"

@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,

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.

_________________

@matthey

Quote:

Only the Amiga made it possible but Commodore made it impossible due to low spec CPUs, chipsets, memory and streaming drives (slow and non-existent HDs and lack of a CD-ROM standard). HAM and HAM8 modes were only useful for static images with the standard hardware specs Commodore gave us which could not even utilize 256 color modes

For a full VGA 256 color artwork, Turrican 2 AGA needs Fast RAM.

https://eab.abime.net/showthread.php?p=1583235
https://eab.abime.net/showthread.php?t=106735


Muzza: It requires Fast RAM to run at 50hz on an A1200. From testing I found it can run at 50hz on a base A1200 but only if I reduce the number of bitplanes. I may do this eventually, but for now I'd rather get it working without modifications to any of the source artwork. Currently it uses 8 bitplanes.


1990s-era mainstream Japanese game consoles and PC VGA have discrete video memory.

_________________

@cdimauro

Quote:

Who was the (technical) responsible for that? Was it Porter again?

After the C65's 8-bitplane chipset reveal and Rubin's approval, AGA ASIC R&D was done by a CSG LSI team member.

AA3000 and AA1000plus are system integration projects. AA3000 acted as the primary system integration test platform for AGA.

Jeff Porter was a task allocator within the system engineering group within the bounds of management directives e.g. Herni Rubin's monochrome hi-res management directive.

Herni Rubin has other directives, not just monochrome hi-res.

Quote:

The hierarchy was defined, but the technical people were incompetent and not even able to agree on the SPECs of a project...

Wrong. Similar-ranked headstrong engineers are not cooperating, which needs proper leadership i.e. the captain is missing in action.

A1000's project had Jay Miner as leader for both system integration and custom ASIC design for both ICS and OCS (drop-in 64 color EHB improvement).

After the A1000 project, the monochrome hi-res mandate was Herni Rubin's.

Quote:

This furtherly proves how engineers were doing whatever they wanted, even against what managers had said them to do.

Managers are oblivious to PC graphics.

Quote:

In fact, Hedley haven't proved why this ‘bitplane to pixel converter’ was so important for the... CDTV. Which was Commodore's multimedia machine.

1. For the CDTV-CR project after CDTV.

2. Improved PC graphics handling without modifying the core Amiga graphics.

Quote:

He has wasted time and resources for the company just to play with his idea...

Amiga's multimedia group can only modify surrounding chips (i.e. system integration), and they don't have the mandate to change the core Amiga graphics design e.g. AGA R&D needs Henri Rubin's approval.

Amiga's multimedia group only has a system integration mandate.

Remember, the system engineering group was responsible for CBM's 8-bit business desktops and C900's system integration.

The system engineering group created a VLSI team for AAA and Hombre. VLSI team recycled some engineers from the CSG LSI team. VLSI team is under the system engineering group's administration.

The CSG's LSI team is responsible for VIC-20 and C64 for both AISC and system integration R&D, which largely kept the CIC group alive until the A500 takeover. The problem is the weak business plan after A500.

Corporate structure limitation is an executive board management problem.

It was the executive board that deleted the original Los Gatos Amiga team.

The Amiga lacks Ken Kutaragi's leadership capability.

Last edited by Hammer on 06-Sep-2025 at 01:17 AM.

_________________

@cdimauro

Quote:

OK, but that wasn't my point. The context was the CDTV and its market, which is more like a multimedia player / kiosk, and with the ability to run Amiga games (but it wasn't central). Chunky/packed wasn't needed for that, neither a hardware conversion logic.

Hardware C2P improves PC ports handling. Games such as Grind/Dread have extra R&D effort with Blitter-assisted C2P.

A500-level hardware has crap Death Mask instead of Grind/Dread.

There are three pathways for chunky pixels:

1. Chunky graphics hardware support. Result: zero R&D risk for 3rd party developers.

2. Hardware C2P. Result: reduced R&D risk for 3rd party developers.

3. Blitter-assisted C2P. Needs game-ready SDK code sample to reduce R&D risk for 3rd party developers. Executing "Michael Abrash" level evangelism for VGA's Mode X for Blitter-assisted C2P. Remove software C2P is slow statement in all official documentation since this is self-defeating.

During the early 1990s, for each independent game project, 3rd party developers had to reinvent the wheel on Blitter-assisted C2P. Other platforms didn't have this extra R&D effort and risk.

Last edited by Hammer on 07-Sep-2025 at 12:17 AM.
Last edited by Hammer on 06-Sep-2025 at 01:39 AM.

_________________

@Thread



To all users of Ultimate 64 / Commodore C64u systems:

Quote:

Firmware version 3.12a - for All Platforms: U2, U2+, U2+L, U64 and U64E2! - Dated 2025-06-19 Click here to download This version also includes an update for the WiFi modules (U2+L, U64 and U64E2). This update might fail the first time around, because of the way the firmware 'talks' to the modules has changed. Just run the updater again, skip the primary update and then update the ESP32. It is highly recommended to update your Ultimate 64 Elite-II with this version after receiving it.

Commodore C64u


https://ultimate64.com/Firmware

Last edited by OneTimer1 on 06-Sep-2025 at 09:51 PM.