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#880972

@Hammer

Quote:

Hammer wrote: @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.

This is another example of using the brute force / CPU to overcome the limits of the Amiga chipset, for a regular task for this machine (e.g.: 2D game).

Which wasn't clearly the way to go: the chipset was the central element of the system, offloading most of the work from the CPU.
Quote:

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

The same for the Amiga was possible, but that's not the point with this system.

The Amiga could have evolved its chipset to remain competitive with both, while keeping its philosophy (as I've already proven on my last series of articles). But the engineers which remained after that the original ones left lacked both knowledge and vision.

@cdimauro

Quote:

This is another example of using the brute force / CPU to overcome the limits of the Amiga chipset, for a regular task for this machine (e.g.: 2D game).

FYI, each A1200 unit sold's $50 profit (69 percent of the profit) is allocated for A600's old debt production run.

A1200 was barebones on compute power when compared to the Atari Falcon.

With Bill Sydnes, Jeff Frank was responsible for AA600 (A1200) and A3400 (ECS initially, but AA3000's AGA was dropped in after Feb 1992 AGA mandate from Mehdi Ali) projects.

Without the C65 reveal, AGA wouldn't exist.

Herni Rubin was betting the farm on ECS, but C65 reveal broke his ego.

Bill Sydnes and Jeff Frank repeated Herni Rubin's betting on ECS.

Herni Rubin's system engineering administration repeated the same C900 debacle on Amiga ECS's "productivity mode".

C128's Z80 CP/M mode with aging gaming C64 hardware and C900 Unix clone repeated for Amiga ECS and AMIX.

Meanwhile, IBM VGA upgraded productivity mode's 640x480p with 16 colors display and "toy" mode 320x200/240 with 256 colors display, hardware scrolling, latch data move engine backed by 262144 color palette.

Commodore The Final Year book mentioned Herni Rubin has neglected the "toy" graphics mode that is the core business for Commodore.


Quote:

But the engineers which remained after that the original ones left lacked both knowledge and vision.

There are not enough chip engineers when there's a single engineer bottleneck for AAA Andrea, ECS Agnus B, and C65 projects. In 1991, AMD hired this engineer for 387 reverse engineering and joined the K7 Athlon project. This engineer's last project with AMD was 28 nm APUs.

MOS/CSG 6502 CPU design had leading and falling clock signal processing, which is useful for the eventual K7 Athlon's DDR "EV6 bus" chipset implementation. Pentium III's FSB is SDR. LOL. Intel's favored Rambus XDR (QDR) failed in the market. Rambus a.k.a. dead bus.

AMD provided superior leadership when compared to Commodore.

Last edited by Hammer on 10-Sep-2025 at 01:56 AM.
Last edited by Hammer on 09-Sep-2025 at 02:42 AM.
Last edited by Hammer on 09-Sep-2025 at 02:34 AM.
Last edited by Hammer on 09-Sep-2025 at 02:26 AM.

_________________

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: This is another example of using the brute force / CPU to overcome the limits of the Amiga chipset, for a regular task for this machine (e.g.: 2D game). FYI, each A1200 unit sold's $50 profit (69 percent of the profit) is allocated for A600's old debt production run.

That's a completely different thing / off-topic.
Quote:

A1200 was barebones on compute power when compared to the Atari Falcon. With Bill Sydnes, Jeff Frank was responsible for AA600 (A1200) and A3400 (ECS initially, but AA3000's AGA was dropped in after Feb 1992 AGA mandate from Mehdi Ali) projects. Without the C65 reveal, AGA wouldn't exist. Herni Rubin was betting the farm on ECS, but C65 reveal broke his ego. Bill Sydnes and Jeff Frank repeated Herni Rubin's betting on ECS. Herni Rubin's system engineering administration repeated the same C900 debacle on Amiga ECS's "productivity mode". C128's Z80 CP/M mode with aging gaming C64 hardware and C900 Unix clone repeated for Amiga ECS and AMIX.

And we know what "good" work the engineers have made in both cases (I mean, C128 and AGA)...
Quote:

Meanwhile, IBM VGA upgraded productivity mode's 640x480p with 16 colors display and "toy" mode 320x200/240 with 256 colors display, hardware scrolling, latch data move engine backed by 262144 color palette.

Not true. EGA already introduced all such features. VGA only (!) introduced the support to higher resolution (640x480 with 16 colours instead of the maximum 640x350 of the EGA) and the 256 colours mode.
Quote:

Commodore The Final Year book mentioned Herni Rubin has neglected the "toy" graphics mode that is the core business for Commodore.

What do you mean with that?

And, BTW, hasn't the AGA introduced (new) "toy" graphics modes?
Quote:

Quote: But the engineers which remained after that the original ones left lacked both knowledge and vision. There are not enough chip engineers when there's a single engineer bottleneck for AAA Andrea, ECS Agnus B, and C65 projects. In 1991, AMD hired this engineer for 387 reverse engineering and joined the K7 Athlon project. This engineer's last project with AMD was 28 nm APUs. MOS/CSG 6502 CPU design had leading and falling clock signal processing, which is useful for the eventual K7 Athlon's DDR "EV6 bus" chipset implementation. Pentium III's FSB is SDR. LOL. Intel's favored Rambus XDR (QDR) failed in the market. Rambus a.k.a. dead bus. AMD provided superior leadership when compared to Commodore.

Irrelevant / off-topic.

Besides that, at least Intel produced its own technologies, whereas AMD had to buy them from Digital...

Anyway, and to get IN TOPIC, your example still proves that bruce force (heavily using a doped CPU) was used for what the Amiga was very known (2D games).

ocs was great.
but since 1992 amiga should have new better graphics running in parallel to ocs

@ppcamiga1

Quote:

ppcamiga1 wrote: ocs was great. but since 1992 amiga should have new better graphics running in parallel to ocs

Why in parallel? AAA has shown a new Amiga chipset with better graphics which was NOT running in parallel, but EXPANDING the EXISTING architecture & features.

PiStorm can't do it, because it absolutely requires an ("original". SIC!) Amiga with its chipset, so the better graphics is ADDED to the system, exactly like all graphic cards did with the so called RTG subsystem.

The Apollo Computers had the possibility to evolve the chipset (since it's a reimplementation of the original one), but unfortunately they decided to follow the additional graphics card path.

TLDR; better graphics do NOT need to run in parallel to the existing one.

@cdimauro

This is not brute force, the code run in fast ram that is all so it run fluid in 8 bitplanes. This has always been on the Amiga design.

@kamelito

Quote:

kamelito wrote: @cdimauro This is not brute force, the code run in fast ram that is all so it run fluid in 8 bitplanes. This has always been on the Amiga design.

It's brute force because you need to do use a different framebuffer and convert it HAM/HAM8, because the latter format doesn't allow you to directly be used as the framebuffer (where you do your computations and then you can directly show it), as we naturally have done with all other Amiga graphics formats.

The CPU has to always to make the conversion, wasting a lot of time. It doesn't matter if its code and framebuffer are located in the Fast Mem: the problem is represented by the additional conversion.

This is NOT the Amiga way...

@cdimauro

stop this crap
stop trolling and start working on zune on aros

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro stop this crap stop trolling and start working on zune on aros

I don't take orders from a complete idiot which isn't able to distinguish a C64 game from an Amiga one.

My only pleasure is bashing your CraPPC UnderPoweredPC processor which runs on PCs-with-x86-CPUs-replaced-by-PowerPC-ones which are NOT, and NEVER will be, Amigas.

@cdimauro

stop this crap
stop trolling and start working on zune on aros

@ppcamiga1

Quote:

ppcamiga1 wrote: @cdimauro stop this crap stop trolling and start working on zune on aros

I don't take orders from a complete idiot which isn't able to distinguish a C64 game from an Amiga one.

My only pleasure is bashing your CraPPC UnderPoweredPC processor which runs on PCs-with-x86-CPUs-replaced-by-PowerPC-ones which are NOT, and NEVER will be, Amigas.

Quote:

cdimauro wrote: I don't take orders from a complete idiot

I truly don't think being crudely offensive like this, is something we should condone here on Amigaworld.net.

Condoning this behavior means being morally complicit.

Could you please refrain from such offenses?

Regards,
"Mega" ""RJ"" Mical

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

@cdimauro

Quote:

That's a completely different thing / off-topic.

It's relevant for the ability to add items within the per-unit financial budget and real timeline's target wholesale price.

This is about management issues after the A500 business model.

Quote:

Not true. EGA already introduced all such features.

EGA has 640x350, 16 colors with 64 color palette and 21.8 kHz.

VGA has 640x480, 16 colors with 262,144 color palette and 31.5 kHz.

VGA's 256 color modes have four byteplanes in addition to EGA's four bitplanes and hardware C2P i.e. EGA's latches and logic distribute CPU byte's bits to the corresponding addresses in each of the four bitplanes.

EGA hardware efficiently distributes the single byte from the CPU across all necessary bitplanes.

Amiga's Blitter can assist C2P, but this software-hardware innovation is done by 3rd party software developers. Commodore's software engineers requested a hardware patch like Akikio C2P and officially stated that software C2P is slow.

During VGA Mode X's publication in 1991, Michael Abrash was hired by Microsoft for the Windows NT's graphics-related project, hence Michael Abrash is effectively part of the 1st first-party for the PC platform.

For PC gaming, it's a good thing that Commodore's software engineers scored their own goal by condemning their own hardware in an official publication. John Carmack's 1994 statement is repeating Commodore's official publication (refer to the bug statement) on the C2P issue.

https://bigbookofamigahardware.com/bboah/product.aspx?id=1604
Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system

When you have internal nayayers, who needs external enemies?

Last edited by Hammer on 14-Sep-2025 at 01:31 AM.
Last edited by Hammer on 14-Sep-2025 at 01:07 AM.

_________________

@cdimauro

Quote:

cdimauro wrote: It's brute force because you need to do use a different framebuffer and convert it HAM/HAM8, because the latter format doesn't allow you to directly be used as the framebuffer (where you do your computations and then you can directly show it), as we naturally have done with all other Amiga graphics formats. The CPU has to always to make the conversion, wasting a lot of time. It doesn't matter if its code and framebuffer are located in the Fast Mem: the problem is represented by the additional conversion. This is NOT the Amiga way...

Amiga graphics architecture was frozen in the advanced EGA multi-bitplane era, but Amiga Blitter can assist in C2P.

The missing feature is turning multiple bitplanes into multiple byteplanes. Every 8 bits in a bitplane stream is a one byte pixel interpretation.

System engineering group's VLSI team was busy with AAA, hence the CSG LSI personnel defined the AA Lisa design just to beat C65's 8 bitplanes design.

Commodore HR only has one CSG LSI engineer allocated for bug fixing AAA Andrea, ECS Agnus**, and C65, hence an engineering bottleneck has occurred.

**ECS Agnus A is operational in 1989's A500 Rev6A.

The fault is management.

_________________

Quote:

Hammer wrote: Amiga graphics architecture was frozen in the advanced EGA multi-bitplane era, but Amiga Blitter can assist in C2P. The missing feature is turning multiple bitplanes into multiple byteplanes. Every 8 bits in a bitplane stream is a one byte pixel interpretation. System engineering group's VLSI team was busy with AAA, hence the CSG LSI personnel defined the AA Lisa design just to beat C65's 8 bitplanes design. Commodore HR only has one CSG LSI engineer allocated for bug fixing AAA Andrea, ECS Agnus**, and C65, hence an engineering bottleneck has occurred.

EGA (1984) is a 4-plane, 16-color, 6-bit (64-entry) palette device with no DMA
sprite engine, no scanline copper, and no blitter. Its planar organization is
not architecturally equivalent to Amiga:

Amiga OCS (1985) exposes:

DMA sprites (8 channels), each with their own fetchers, priority mixers, and
attach modes.

Copper (per-scanline/per-pixel register sequencer) allowing deterministic
palette and fetch changes at beam position granularity.

Blitter with line-mode, area fill, and Boolean combination (minterms) across
three sources + one destination, plus barrel-shift on A, B, or C channels
aligned by BLTCON0/BLTCON1.

Bitplane DMA with independent modulos per plane (per-scanline stride), enabling
dual-playfield, parallax, and subpixel scroll without touching a single byte of
pixel memory.

12-bit palette (4096) with HAM6 (6-bitplanes) producing up to 4096 on the same
frame. EGA can’t do anything like HAM because it lacks per-pixel arithmetic on
output.

ECS (1989/1990) extends resolution and bandwidth envelopes and tidies a bunch
of timing edges; still all of the above apply.

Saying “frozen at EGA� ignores:

Per-plane modulo (Amiga) vs shared plane stride (EGA latch model).

On-beam register scripting (Copper) vs static CRTC programmed once per mode (
EGA).

Hardware sprites vs none.

HAM modes (output-time color dependency) vs fixed 4-bpp decode.

VGA (1987)—not EGA—finally introduces useful palette depth and (in Mode 13h) a
chunky 8-bpp path. But even VGA has no native sprite engine, no copper, and no
HAM-style output transform.

The Amiga pipeline is a different class of raster engine—tightly coupled, DMA-
centric, and beam-synchronous—whereas EGA/VGA are largely framebuffer scan-out
devices with a CPU/GPU (if any) pushing pixels.

A hardware C2P (planar↔chunky swizzler) would have been nice-to-have for 256-
color software-rendered effects, but calling it “the missing feature�
misunderstands where time actually goes on OCS/ECS/AGA:

Where C2P cost lives:

Memory bandwidth & arbitration. Amiga chip RAM is a shared, time-sliced bus
between the video fetchers (bitplanes, sprites), Copper, audio DMA, Blitter,
and CPU. Every C2P routine runs under these arbitration windows. If Lisa/Alice (
AGA) is bus-mastering to fetch 6–8 planes at 7/14 MHz pixel clocks, your CPU’s
effective memory bandwidth is already carved up in fixed slots.

Address swizzle & cache absence. On 68000/68010, no caches. On 68020+, small
I/D caches help, but your write bandwidth to chip RAM is still the ceiling.

DMA fetch width. The display fetchers still expect bitplanes; even with a
hardware swizzler, the pixels must be re-expanded into planes before scan-out
unless you add an entirely new display path.

Blitter isn’t a C2P engine (by design). It barrel-shifts 16-bit words, merges
with minterms, and walks rectangles and lines very fast. That makes it a
monster for planar composition (masks, font glyphs, RLE sprites, dual-playfield
scrolling), but a mediocre swizzler for byte-oriented chunky because the write
pattern of chunky interleaves 8 pixels per 8 bytes while planar writes are 1
bit per plane across the same 16-bit word. You can abuse the blitter for
partial assists (e.g., stage bit-gathers into temporary buffers using specific
minterms and barrel shifts), but you pay extra bus turns and intermediate
stores that annihilate the win on OCS/ECS chip-ram.

Measured reality (typical demo-scene era figures):

68030 @ 50 MHz + AGA chip RAM: well-tuned 5-plane C2P (for 32-color effects)
sustained on the order of ~25–35 MB/s of logical bit moves when counting all
internal reads/writes, which translates to a visible frame budget of ~10–14 ms
for a 320×256 frame if the bus is not heavily contested. When the bitplane
fetchers are running wide (6–8 planes), the effective CPU bandwidth to chip RAM
drops, turning those same loops into ~14–18 ms. Exact numbers vary by copy
order and bursting, but the limiter is bus time, not integer ALU.

68020 @ 14–28 MHz + OCS/ECS: the same C2P pattern is memory-bound even harder;
expect ~1.5–2× slower than the AGA/030 case ignoring caches.

A dedicated planar↔chunky swizzler would have helped software renderers—no
question—but it’s not the “missing feature� that prevented the Amiga from doing
VGA-like 256-color “chunky� games by default. The display pipeline itself is
planar; you’d either a) add a new chunky fetcher (a second pixel path) or b)
keep swizzling into planar just in time—which still hits the shared bus
ceiling. Commodore’s RTG boards (Picasso/CyberVision) solved this the right
way: separate VRAM + chunky modes + independent blit engines.

“VLSI busy on AAA, so CSG made AA Lisa just to beat C65’s 8 bitplanes� —
timeline and purpose are conflated

AAA (the ambitious next-gen set) stalled; AA/AGA (Lisa/Alice/Paula-ish) shipped
as a pragmatic, backward-compatible bandwidth + palette bump: more planes (up
to 8), 18-bit palette (262k) with 256-entry CLUT, and wider internal fetches /
burst behavior to feed those planes.

C65 (VIC-III) was a late, 8-bit-line product that never mass-shipped; its
goals (C64 compatibility + higher modes) were orthogonal to Amiga’s. Beating
“C65’s 8 bitplanes� wasn’t the driver for AGA; the driver was breathing room
for 256-color UIs and better HAM (HAM8) while preserving the entire Amiga DMA
choreography.

If the target had been “beat C65 with a swizzler,� Lisa would have included
either a chunky fetch path or a true planar↔chunky DMA unit. It didn’t—because
the compatibility envelope demanded keeping the bitplane DMA semantics intact
so existing titles, copperlists, and sprite chains continued to function.

Planar gather (toy 4-bpp example):You want to turn 8 consecutive chunky pixels (
8 bytes) into 4 planar words (4×16 bits). A classic bit-gather uses masks and
shifts:

Quote:

; Abstractly for 8 pixels p0..p7, each 8 bits:plane0_word = (p0gtangtan0 & 1)ltanltan15 | (p1gtangtan0 & 1)ltanltan14 | ... | (p15gtangtan0 & 1)ltanltan0plane1_word = (p0gtangtan1 & 1)ltanltan15 | (p1gtangtan1 & 1)ltanltan14 | ......

CPU path (68030) uses:

MOVEM to pull 8 bytes into regs, then a tree of AND/LSL#n/OR, possibly with
lookup tables (8→8 deinterleave) to collapse to 2–3 ops per pixel bit on
average.

You land around ~6–8 ALU ops per pixel amortized for 4-bpp (plus loads/stores),
which still leaves you memory-bound on chip RAM.

Blitter assist:

Program A, B as two source streams with BLTCON1 barrel shifts set per stage;
use minterm 0xCA, 0xE2, 0x22 style combinations to isolate bit-slices. You
essentially perform bit-plane scatter by repeated passes: each pass writes a
more refined mask into the destination plane buffers.

Each pass consumes bus slots, and because the blitter writes to chip RAM, you
collide with video DMA. Worst case, the blitter runs only in the “free� memory
slots not used by display fetchers (you can watch the infamous “blitter-
badlines� behavior). The more planes currently displayed, the fewer free slots.

Result: On OCS/ECS, a cleverly written CPU C2P with tiny LUTs can match or beat
a blitter-heavy version because it minimizes bus turns and avoids extra
intermediate buffers. On AGA, the blitter has more headroom (wider internal
fetches), but you’re still fundamentally bandwidth-bound. Assistance ≠
solution.

The actual “missing feature� if you want PC-style 256-color games

Not planar→chunky conversion—it’s a native chunky fetch path (or separate
VRAM + chunky surface + independent scanout). That’s exactly what the RTG
boards delivered and why 68k Amigas running CyberGraphX/Picasso96 suddenly look
like fast 256-color workstations: the raster path matches the software
rendering model.

Adding only a C2P engine would still:

Compete for chip RAM bus time with bitplane and sprite DMA.

End up writing 8 planes’ worth of data for a 256-color screen (that’s 8
separate DMA consumers downstream).

Keep all the classic priority/slotting constraints that make timing
deterministic but bandwidth finite.

The org chart quip (“one LSI engineer… bottleneck�) is neither necessary nor
sufficient

Even if headcount was tight (and it was), the architectural story stands alone:
AGA is a conservative extension by design. It preserves cycle-exact DMA
choreography, Copper semantics, sprite channels, and bitplane fetchers—because
that’s what kept the entire back catalog and dev knowledge alive. A radical
chunky path would have helped a narrow class of titles while breaking a lot of
the platform’s identity and developer expectations. Commodore punted that to
RTG add-ons rather than mutate the chipset.

Micro-timing nibbles (because you asked for fastidious)

(Representative; numbers vary with exact silicon/clock, but the relationships
are stable.)

68000 shifts: LSR #n,ltaneagtan ≈ 6 + 2n cycles; doing 8 single-bit extractions
across 8 bytes is already ~22–24 cycles of shift/and/or per 8 pixels, excluding
loads/stores. At 7.14 MHz that’s ~3.3 µs just for the bit-twiddles per 8-pixel
group, oblivious to memory.

68030 cache vs chip RAM: cached LUT loads at 1 cycle (hit) vs chip RAM writes
at 3–4 cycles + wait states; but the video DMA slotting often forces effective
throughput down to ~7–10 MB/s sustained during display if the beam is fetching
many planes. That’s why demo coders redraw during VBLANK or use copper-split
displays to balance contention.

Blitter: Peak blitter word copy (ideal, off-display) approaches ~7–8 MB/s on
OCS, somewhat higher on ECS, and higher still on AGA when arbitration leaves
headroom. But C2P via blitter is multi-pass; even if each pass hits near-peak,
N passes × arbitration cuts it down.

HAM exists, and it matters in the “EGA� comparison

Comparing to EGA is particularly misleading because HAM6/HAM8 are output-time
transforms, not memory-time. A 6-plane or 8-plane buffer can produce thousands
of apparent colors by modifying only one component per pixel based on the
previous pixel. That is categorically unavailable on EGA/VGA (until much later
programmable DAC tricks on SVGA). It’s why photo-style displays on stock Amigas
look nothing like EGA output.

“ECS Agnus A in A500 Rev 6A (1989)� — trivia, not thesis

Sure. ECS Agnus/Alice/Agnus variants show up across late A500s and A2000s. That
doesn’t advance the C2P claim, the EGA comparison, or the AGA/Lisa design
intent. It’s a board-rev footnote.

The Amiga was not “frozen at EGA.� Its pipeline was richer and more orthogonal (
DMA sprites, Copper, per-plane modulo, HAM) and optimized for planar
composition, not chunky fill.

A hardware planar↔chunky swizzler would have been useful for 256-color software
renderers but would not have removed the primary constraint: shared chip-RAM
arbitration and a planar fetch display path. Without a native chunky fetcher (
or separate VRAM path), you’re still paying the planar piper.

AGA was a conservative, compatibility-preserving bandwidth/palette uplift; it
wasn’t a reaction to the C65, nor did it intend to reinvent the pixel path.

Blitter-assisted C2P is possible but never the silver bullet; the bus math, not
the Boolean minterms, is what sets your frame budget.

If you want a one-liner: the Amiga didn’t “need� C2P silicon to escape EGA; it
needed a parallel chunky raster path—and when you add that (RTG), the platform
instantly behaves like the PC world you’re holding up as the yardstick, without
sacrificing what made the native chipset special.

Last edited by MEGA_RJ_MICAL on 14-Sep-2025 at 01:59 AM.

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

@cdimauro

Quote:

And, BTW, hasn't the AGA introduced (new) "toy" graphics modes?

AGA's R&D approval is too late, and Herni Rubin's core Amiga graphics R&D pace didn't keep up with FPM DRAM's improvement pace e.g. refer to ET3000AX and ATI VGA Wonder.

Quote:

And we know what "good" work the engineers have made in both cases (I mean, C128 and AGA)...

C128's Z80 CP/M is part of the Zilog adventure with C900's Z8001/Z8010 Coherent's wannabe Unix clone. Both C900 (early 1983) and C128 had a common MOS Technology 8563 display chip.

Commodore obtained a second source license for Zilog IP instead of the failed x86 second source license attempt.

For the post-65xx road map, other desktop platform companies focus on RISC, such as ARM.

https://archive.org/details/ComputersElectronics1984-03/page/n27/mode/1up
Commodore scrapped the 16-bit 6502 R&D in favor of the Unix-capable 16-bit Z8001 and Z8010 MMU.

Commodore management had anti-toy direction, hence Z80 CP/M and Z8001/Z8010 Coherent's wannabe Unix clone.

Commodore's Zilog adventure abandoned any advancements with "toy" resolution modes. This is why "toy" C65 R&D needs to be hidden from upper management.

Quote:

Irrelevant / off-topic.

It's relevant.

Quote:

Besides that, at least Intel produced its own technologies, whereas AMD had to buy them from Digital...

DEC sued Intel for stolen tech.

Intel assimilates DEC's crown jewels. https://www.hpcwire.com/1997/10/27/intel-purchase-decs-alpha-manufacturing-operations/
Intel Corp purchased Digital Equipment Corp.'s Alpha computer chip manufacturing operations


The multi-year agreement includes sale of Digital's semiconductor
manufacturing operations to Intel for approximately $700 million,
cross-licensing of patents, supply of both Intel and Alpha microprocessors
and development of future systems based on Intel's 64-bit microprocessors.


Your narrative is bullshit.

_________________

OCS was wonderfull. ECS was ok.
After ECS C= should provide new chipset chunky oriented working in parallel to ECS.
Any further work on old chipset was wrong.
They should leave ECS as it is and start from scratch new graphics for Amiga.

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: That's a completely different thing / off-topic. It's relevant for the ability to add items within the per-unit financial budget and real timeline's target wholesale price. This is about management issues after the A500 business model.

Again, totally irrelevant.

Hint: check the context of the discussion. Optionally (!), take a look at the subject of the thread.
Quote:

Quote: Not true. EGA already introduced all such features. EGA has 640x350, 16 colors with 64 color palette and 21.8 kHz. VGA has 640x480, 16 colors with 262,144 color palette and 31.5 kHz.

Why do you repeat things which I've already reported?!?
Quote:

VGA's 256 color modes have four byteplanes in addition to EGA's four bitplanes

Again, you talk of things which you've no clue at all.

So, NO: VGA added NOTHING like that!

VGA is working exactly like the EGA: it's always fetching FOUR bytes from its video memory, and those bytes are sent to the display controller.

The only difference is how those four bytes are used / interpreted.

EGA extracts one bit from each byte and combines them to form the 4-bit index to read the corresponding entry in the CLUT, repeating the operation 8 times until the last pixel is displayed.
Which, contrary to what ChatGTP reported, is EXACTLY how the Amiga works (with the difference that it fetches 16-bit instead of bytes, and has a variable number of bitplanes. However, a 16 colours display fetches 4 x words -> it works exactly like the EGA, but it repeat the process 16 times instead of 8).

VGA just used each byte to read the corresponding entry in the CLUT, repeating the operation 4 times until the last pixel is displayed.

The difference between the 8 and 4 pixels processing is determined by the master clock which is used: High-Res or Low-Res. Which, again, is exactly how the Amiga works when dealing with high-res or low-res modes.
Quote:

and hardware C2P i.e. EGA's latches and logic distribute CPU byte's bits to the corresponding addresses in each of the four bitplanes. EGA hardware efficiently distributes the single byte from the CPU across all necessary bitplanes.

LOL. This has absolutely NOTHING to do with any "hardware C2P", because... there's NO C2P here!

It's "just" the copy with mask & minterms which EGA provides when the CPU accesses its video memory, with the ability to select to which of the four bitplanes are effected by the operations. EVERYTHING REMAINS PLANAR!

Again, you don't know of what you talk about!
Quote:

Amiga's Blitter can assist C2P, but this software-hardware innovation is done by 3rd party software developers. Commodore's software engineers requested a hardware patch like Akikio C2P and officially stated that software C2P is slow. During VGA Mode X's publication in 1991, Michael Abrash was hired by Microsoft for the Windows NT's graphics-related project, hence Michael Abrash is effectively part of the 1st first-party for the PC platform. For PC gaming, it's a good thing that Commodore's software engineers scored their own goal by condemning their own hardware in an official publication. John Carmack's 1994 statement is repeating Commodore's official publication (refer to the bug statement) on the C2P issue.

PADDING...
Quote:

https://bigbookofamigahardware.com/bboah/product.aspx?id=1604 Ken was telling us how much of a pain it was to shuffle bits in software to port games from other platforms to the Amiga planar system When you have internal nayayers, who needs external enemies?

Ask your 'hero', who candidly admitted in an interview how they were already aware of the need for chunky graphics 1-2 years BEFORE the ugly patch you are talking about now...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: cdimauro wrote: It's brute force because you need to do use a different framebuffer and convert it HAM/HAM8, because the latter format doesn't allow you to directly be used as the framebuffer (where you do your computations and then you can directly show it), as we naturally have done with all other Amiga graphics formats. The CPU has to always to make the conversion, wasting a lot of time. It doesn't matter if its code and framebuffer are located in the Fast Mem: the problem is represented by the additional conversion. This is NOT the Amiga way... Amiga graphics architecture was frozen in the advanced EGA multi-bitplane era, but Amiga Blitter can assist in C2P. The missing feature is turning multiple bitplanes into multiple byteplanes. Every 8 bits in a bitplane stream is a one byte pixel interpretation. System engineering group's VLSI team was busy with AAA, hence the CSG LSI personnel defined the AA Lisa design just to beat C65's 8 bitplanes design. Commodore HR only has one CSG LSI engineer allocated for bug fixing AAA Andrea, ECS Agnus**, and C65, hence an engineering bottleneck has occurred. **ECS Agnus A is operational in 1989's A500 Rev6A. The fault is management.

And here you completely misunderstood this part of the discussion, and you've written completely random things which are totally unrelated.

No words, really...

@Hammer

Quote:

Hammer wrote: @cdimauro Quote: And, BTW, hasn't the AGA introduced (new) "toy" graphics modes? AGA's R&D approval is too late, and Herni Rubin's core Amiga graphics R&D pace didn't keep up with FPM DRAM's improvement pace e.g. refer to ET3000AX and ATI VGA Wonder.

Again, you do NOT answer to precise questions and start talking of something different.

When do you think to stay in topic? Do you understand how to participate to a discussion?
Quote:

Quote: And we know what "good" work the engineers have made in both cases (I mean, C128 and AGA)... C128's Z80 CP/M is part of the Zilog adventure with C900's Z8001/Z8010 Coherent's wannabe Unix clone. Both C900 (early 1983) and C128 had a common MOS Technology 8563 display chip. Commodore obtained a second source license for Zilog IP instead of the failed x86 second source license attempt. For the post-65xx road map, other desktop platform companies focus on RISC, such as ARM. https://archive.org/details/ComputersElectronics1984-03/page/n27/mode/1up Commodore scrapped the 16-bit 6502 R&D in favor of the Unix-capable 16-bit Z8001 and Z8010 MMU.

Which has nothing to do with the CP/M: Unix is completely different and have completely different requirements. Hence, the Z8000 usage.

But I was talking about the C128...
Quote:

Commodore management had anti-toy direction, hence Z80 CP/M and Z8001/Z8010 Coherent's wannabe Unix clone. Commodore's Zilog adventure abandoned any advancements with "toy" resolution modes. This is why "toy" C65 R&D needs to be hidden from upper management.

Sometimes "toys" are back, but... without the top management informed. Which is NOT a good thing, right?
Quote:

Quote: Irrelevant / off-topic. It's relevant.

Then explain. READ the context and write down why what you've written is "relevant".

Preparing the popcorns...
Quote:

Quote: Besides that, at least Intel produced its own technologies, whereas AMD had to buy them from Digital... DEC sued Intel for stolen tech. Intel assimilates DEC's crown jewels. https://www.hpcwire.com/1997/10/27/intel-purchase-decs-alpha-manufacturing-operations/ Intel Corp purchased Digital Equipment Corp.'s Alpha computer chip manufacturing operations The multi-year agreement includes sale of Digital's semiconductor manufacturing operations to Intel for approximately $700 million, cross-licensing of patents, supply of both Intel and Alpha microprocessors and development of future systems based on Intel's 64-bit microprocessors. Your narrative is bullshit.

Again, ANOTHER thing to distract from what I've stated before (which clearly you haven't liked).

With the addition of your complete intellectual dishonesty, since you were careful to report a relevant part:

It then filed a countersuit accusing Digital of patent infringement.

Digital was certainly no goody-goody, as you see (and as is quite common in the industry: patent infringements are quite common, and it is hard to find companies that have not been involved). But 'strangely' in your polarised rhetoric only Intel had to look bad and ugly. Which proves, if there was still any doubt, your absolute bad faith.