@Karlos

Quote:

The stupidity of his remarks are amazing, aren't they? He bemoans the lack of chunky and says smart people moved to graphics cards from AGA. Then says stupid people use PiStorm, which is hands down the fastest and most affordable expansion for any Amiga and includes a chunky/ RTG implementation faster than any of the cards classic 68K users would have selected back when we were all doing such things.

I know right!? You have to see to believe!!

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

@ppcamiga1

Quote:

ppcamiga1 wrote: @bhabbott Quote: What I find curious is that Accelerator card manufacturers didn't put a c2p converter onboard. I guess they figured it wasn't worth the effort, there was no reasons to use aga they add pci and/or pc graphics chip smart people switch from AGA to graphics cards dumb people use c2p and 060 and/or pistorm

AGA is Amiga's VGA legacy equivalent. Modern PC GPUs from AMD and NVIDIA still have legacy VGA.

PiStorm-Emu68 enhanced A1200 still runs Deluxe Music 2 in either AGA or RTG.

Deluxe Music 2 is broken in classic AmigaOS 4.1 FE or SAM460 AmigaOS 4.1 FE.

Last edited by Hammer on 09-Dec-2024 at 12:20 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Hammer

He doesn't care what software works, he just wants to lick the screen.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

bhabbott wrote: @BigD Quote: BigD wrote: It would have helped speed up Wing Commander CD32, but Nick Pelling made a mistake in the game code, so yes it was overall pointless! Has this bug been patched? Can we see the difference Akiko would have made without the mistake?

The bug has been "fixed" in the WHDLoad install of Wing Commander CD32 but I only play it with an 030/50 so who knows if the Aikiko works as described?

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hammer

Quote:

AGA is Amiga's VGA legacy equivalent. Modern PC GPUs from AMD and NVIDIA still have legacy VGA.

This is a very good point, by the way. Modern GPU vendors may implement it in varying ways but the fact is, the standard is still supported.

_________________
Doing stupid things for fun...

@Karlos

Quote:

Karlos wrote: There are no "copy speed" 256 colour C2P routines for anything less than 040 and the fastest accelerator in the day was an 030 (SX-32 IIRC).

Tests I have done prove that a 50MHz 030 does 256 color c2p at practically copy speed in Doom - and a 50MHz 030 is the slowest you want for that game (equivalent to a 40MHz 386DX with ISA graphics card, which was a 'mid-range' PC system in 1993 ).

Quote:

Tests I wrote not long ago show that an 030 can write to akiko as fast as the bus permits, but all the performance is lost in having to read back the data and then dump it back to chip ram via the CPU.

Yes, because the CPU is writing at copy speed even with software c2p, and Akiko is limited to 14MHz max. An 'Akiko' writing at CPU bus speed with DMA to ChipRAM could be as fast as direct access to an RTG card's RAM. However this would not translate to a big increase in fps in Doom because 3D calculations and rendering are already taking up ~80% of the CPU time at 50MHz. This becomes more critical as scene complexity increases, causing the frame rate to slow down anyway - even if c2p was taking no time.

So Akiko was useful on the CD32 because the CPU was slower, but only for games that didn't have a high CPU loading. In Doom the difference in frame rate is dramatic, but 5.9 fps is still too slow. Other games that weren't doing full-screen textured-mapped 3D could benefit more.

Quote:

On the stock machine, it's even worse because you are reading from Chip RAM in the first step.

But it's still way faster than having to execute a bunch of CPU instructions to convert from chunky to planar.

Quote:

In short, it was a good conversion engine, let down by an abysmal PIO interface, ironically bolted onto a chip already capable of performing DMA.

It was significantly better than not having it, which is what matters. DMA would have been even better of course, but would require significantly more design effort.

But there was another plus side to Akiko's c2p, which is that it spawned discussions like this. I wish I could justify spending a grand on a CD32 so I could do my own tests. OTOH I might consider making one in a CPLD or FPGA. Would be great if we could retrofit them to Amigas that don't have it. Then we could compare PIO to DMA etc. for even more retro fun!

Quote:

While it was faster than doing C2P on the stock 020, that same configuration wasn't exactly fast enough for the sort of software that was emerging that relied on chunky graphics in the first place.

True for Doom and 3D games that came after it.

But virtually all PC VGA games relied on chunky graphics, including top sellers like Monkey Island, Day of the Tentacle and Myst. These games didn't have a high CPU loading and didn't need high frame rates. Akiko c2p was a way to make porting these games easier.

@ppcamiga1

Quote:

ppcamiga1 wrote: @bhabbott Quote: What I find curious is that Accelerator card manufacturers didn't put a c2p converter onboard. I guess they figured it wasn't worth the effort, there was no reasons to use aga

Yes, there were.

AGA completed the Amiga in a way that RTG couldn't, providing the graphics enhancements it 'should' have had by 1990 - including the full 8 bitplanes the OS was designed for, sprites large enough to actually be useful, dual playfields with enough colors to be useful, a 24 bit palette for true colors, HAM8 in any resolution for real photographic quality without noticeable fringing, and enough ChipRAM bandwidth to make these features usable. As a bonus it also had fully programmable sync rates to allow using a VGA or other high scan rate monitor to eliminate flicker in hires.

And it did all this while still being compatible with OCS and still being operated the same way, so developers didn't need to relearn a different chipset or be forced to go through software drivers. Thus it preserved the essence of the Amiga's chipset. RTG would do the opposite, making the Amiga less of an Amiga and more like a PC or Mac.

You may say these reasons are not valid, and perhaps for you they aren't. But for many of us they are.

Quote:

they add pci and/or pc graphics chip

No, we just use our A1200, A4000 or CD32. No need to add anything.

Quote:

smart people switch from AGA to graphics cards

Smart people don't destroy the retro experience by adding PC stuff to their Amigas.

Quote:

dumb people use c2p and 060 and/or pistorm

Dumb people think it's all about getting the best performance, but that's not what retro computing is mostly about.

There's an A600 selling on TradeMe (NZ online auction site) right now that includes a V2 Vampire with HDMI and a Rapid Road USB card, from a deceased estate. It's in a bit of a mess, with the case screws missing and bits hanging out all over the place. Seems the owner died before he could get it tidied up, if he ever bothered. What does this mean? Clearly he didn't get the enjoyment out of it that he could have. It might have been better to just add a CF Card and FastRAM expansion to play all those OCS games and enjoy the machine as it was back in 1992, rather than turn it into a Frankenstein monster.

I say this as someone who has an A1200 with 50MHz 030 and an A600 with Vampire. The A1200 gets a lot more use. Why? Because the Vampire with RTG just feels 'wrong', and it's a pain to switch between that and OCS. I also have a stock A500 which I use for playing OCS games, a far more authentic experience.

When I want to do stuff that needs PCI and/or a PC graphics chip, I use a PC. It's pointless trying to get an Amiga to do stuff it was never intended for and can't do properly anyway, when I have several 'modern' PCs set up for that. The Vampire card has turned out to be waste of money, not because it didn't do everything it was supposed to, but because it did. I now understand why I wasn't sad about selling my A3000 with 060 and RTG back at the turn of the century. I wasn't using it as an Amiga, just as a computer to do jobs - and by that time a PC did it better.

@BigD

Quote:

The bug has been "fixed" in the WHDLoad install of Wing Commander CD32 but I only play it with an 030/50 so who knows if the Aikiko works as described?

I have the same problem. I can't find any videos of the patched game running on a CD32, and I'm too tight-fisted to spend NZ$1000+ on a CD32 just to answer that question. But surely someone has done it? It would be nice to know how it would have played if properly programmed.

Hmm. I wonder if WinUAE is good enough now to do cycle-accurate CD32 emulation?

@bhabbott

Quote:

Tests I have done prove that a 50MHz 030 does 256 color c2p at practically copy speed in Doom - and a 50MHz 030 is the slowest you want for that game (equivalent to a 40MHz 386DX with ISA graphics card, which was a 'mid-range' PC system in 1993 ).

The problem is Amiga's 256 color install base and 40 to 50 Mhz 030 accelerator's attachment rates.

A few 50 Mhz 030 CPU accelerated A1200s are easy, but 1 million of them don't exist.

AGA's full-year sale was only in 1993 before Commodore International's bankruptcy. One million A600-related debt was a major problem. OCS/ECS are locked out of PC ports 256 color gaming.

CSG's wasted 2 microns fabs for C65's mass production was a major ROI debacle.

Commodore PC(Jeff Frank)'s excess 386 inventory when the 486 was released in 1989 was another debacle. Commodore Germany's logistics is Petro Yyschtschenko as I recall.

For A2000-CR 1987, the Commodore-Amiga's West Chester group has to apply cost reduction improvements for Commodore Germany's 1986 A2000 design.

There wasn't a coherent, unified plan with Commodore.

Last edited by Hammer on 09-Dec-2024 at 09:55 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

Quote:

AGA completed the Amiga in a way that RTG couldn't, providing the graphics enhancements it 'should' have had by 1990 - including the full 8 bitplanes the OS was designed for, sprites large enough to actually be useful, dual playfields with enough colors to be useful, a 24 bit palette for true colors, HAM8 in any resolution for real photographic quality without noticeable fringing, and enough ChipRAM bandwidth to make these features usable. As a bonus it also had fully programmable sync rates to allow using a VGA or other high scan rate monitor to eliminate flicker in hires. And it did all this while still being compatible with OCS and still being operated the same way, so developers didn't need to relearn a different chipset or be forced to go through software drivers. Thus it preserved the essence of the Amiga's chipset. RTG would do the opposite, making the Amiga less of an Amiga and more like a PC or Mac.

AGA duplicates the same mistakes in Atari ST's low and high-resolution mode, which requires a separate high-resolution monitor or expensive MultiSync monitor. AGA's game resolution mode wasn't scan line doubled for typical 31 kHz VGA monitors.

PC VGA has a built-in double scan line hardware feature for 200 lines mode 13h/240 lines mode X and legacy 15 kHz CGA/EGA. VGA cloners made built-in double scan line hardware features to be low cost.

Amber's extra expensive frame buffer is needed for the deinterlace issue with 400i/512i 15 kHz modes which is negated by AGA's doublePAL/doubleNTSC/productivity modes.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

Quote:

bhabbott wrote: @Karlos Quote: Karlos wrote: There are no "copy speed" 256 colour C2P routines for anything less than 040 and the fastest accelerator in the day was an 030 (SX-32 IIRC). Tests I have done prove that a 50MHz 030 does 256 color c2p at practically copy speed in Doom - and a 50MHz 030 is the slowest you want for that game (equivalent to a 40MHz 386DX with ISA graphics card, which was a 'mid-range' PC system in 1993 ).

Right, you will forgve me for my skepticism here, but here are the results from a range of C2P scenarios, conducted on a real 030 accelerator for CD32. It's an oddball being clocked at ~70MHz but if you have found a copy-speed, or even near-copy-speed C2P routine for 256 colour mode, you need to share it with the world. I for one would be extremely interested!

Akiko Detected
Akiko verification test without CACR manipulation
C[0]: 0x80808080 P[0]: 0x01010101 E[0]: 0x0000000F FAIL
C[1]: 0x40404040 P[1]: 0x01010101 E[1]: 0x000000F0 FAIL
C[2]: 0x20202020 P[2]: 0x01010101 E[2]: 0x00000F00 FAIL
C[3]: 0x10101010 P[3]: 0x01010101 E[3]: 0x0000F000 FAIL
C[4]: 0x08080808 P[4]: 0x01010101 E[4]: 0x000F0000 FAIL
C[5]: 0x04040404 P[5]: 0x01010101 E[5]: 0x00F00000 FAIL
C[6]: 0x02020202 P[6]: 0x01010101 E[6]: 0x0F000000 FAIL
C[7]: 0x01010101 P[7]: 0x01010101 E[7]: 0xF0000000 FAIL
Akiko verification test with CACR manipulation
C[0]: 0x80808080 P[0]: 0x0000000F E[0]: 0x0000000F PASS
C[1]: 0x40404040 P[1]: 0x000000F0 E[1]: 0x000000F0 PASS
C[2]: 0x20202020 P[2]: 0x00000F00 E[2]: 0x00000F00 PASS
C[3]: 0x10101010 P[3]: 0x0000F000 E[3]: 0x0000F000 PASS
C[4]: 0x08080808 P[4]: 0x000F0000 E[4]: 0x000F0000 PASS
C[5]: 0x04040404 P[5]: 0x00F00000 E[5]: 0x00F00000 PASS
C[6]: 0x02020202 P[6]: 0x0F000000 E[6]: 0x0F000000 PASS
C[7]: 0x01010101 P[7]: 0xF0000000 E[7]: 0xF0000000 PASS
Got Timer, frequency is 709379 Hz
Running Test Cases
	Allocated aligned fast buffers at 0x513dabc0 and 0x513eebe0
	Allocated aligned chip buffer at 0x3e010
Case 0: Copy
	Vanilla Fast to Chip Copy, 8 longwords at a time.
	No initialisation needed.
	Elapsed: 168052 ticks, 236 ms [20 frames, 84 fps]
	Perf   : 6915993 bytes/second

Case 1: Null C2P
	Chunky read from Fast and planar write to Chip, but no conversion.
	No initialisation needed.
	Elapsed: 167235 ticks, 235 ms [20 frames, 85 fps]
	Perf   : 6949780 bytes/second

Case 2: Akiko C2P (Limit)
	Register to Akiko to Register throughput
	No initialisation needed.
	Elapsed: 93862 ticks, 132 ms [20 frames, 151 fps]
	Perf   : 12382503 bytes/second

Case 3: Akiko C2P (Limit)
	Register to Akiko to Register throughput, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 128092 ticks, 180 ms [20 frames, 111 fps]
	Perf   : 9073529 bytes/second

Case 4: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip.
	No initialisation needed.
	Elapsed: 237588 ticks, 334 ms [20 frames, 59 fps]
	Perf   : 4891857 bytes/second

Case 5: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Chip, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 328831 ticks, 463 ms [20 frames, 43 fps]
	Perf   : 3534479 bytes/second

Case 6: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko.
	No initialisation needed.
	Elapsed: 271163 ticks, 382 ms [20 frames, 52 fps]
	Perf   : 4286154 bytes/second

Case 7: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Chip, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 313476 ticks, 441 ms [20 frames, 45 fps]
	Perf   : 3707609 bytes/second

Case 8: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Chip.
	Initialisation
	Elapsed: 268881 ticks, 379 ms [20 frames, 52 fps]
	Perf   : 4322531 bytes/second

Case 9: Akiko C2P (Naive)
	Chunky read from Fast, planar write to Fast, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 156646 ticks, 220 ms [20 frames, 90 fps]
	Perf   : 7419573 bytes/second

Case 10: Akiko C2P (Buffer)
	Chunky read from Fast, planar write to Fast, register buffer to/from Akiko, CACR Write Allocation Disabled.
	No initialisation needed.
	Elapsed: 180304 ticks, 254 ms [20 frames, 78 fps]
	Perf   : 6446038 bytes/second

Case 11: Kalms C2P (c2p1x1_8_c5_030_2)
	Chunky read from Fast, planar write to Fast.
	Initialisation
	Elapsed: 240479 ticks, 338 ms [20 frames, 59 fps]
	Perf   : 4833048 bytes/second

Last edited by Karlos on 10-Dec-2024 at 10:10 AM.

_________________
Doing stupid things for fun...

@Karlos

AA+ with native chunky pixels wouldn't have solved 2MB Chip RAM with a gimped 68EC020 configuration.

CD32 wasn't designed for Doom-level workload.

Jeff Porter's 8 MB (6 GB Fast, 2 MB Chip) for an extra $20 would improve 1990's Wing Commander port, but the gaming PC has moved on.

Indivision AGA MK3 has Graffiti-chunky pixels.

For A1200, I used Indivision AGA MK3's Graffiti and TF1260 combo before PiStorm32.

Motorola didn't replace 68000 @ 16 Mhz or 68EC020 @ 16 Mhz with a cost-reduced RISC 88000 CPU.

A1000Plus with AA was initially spec with 68000 @ 14 Mhz before changing to 68EC020 & 16 Mhz in early 1991.

Chunky Pixel support for AA is only half of the solution.

Commodore - The Final Years reveals Commodore's main reason for moving away from Motorola's RISC offerings i.e. it's a cost factor.

From 1989, Commodore engineers are aware they needed a game console machine with 88000 @ 25 Mhz like RISC CPU solution at 68000 @ 16 Mhz price, 32bit AAA chipset and 32bit FP DRAM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@bhabbott

To my knowledge, the people that figured out the bug used the knowledge to tweak and optimise the WHDLoad install and nothing else! Since the target of the install was 030 based A1200s I would imagine no further effort to patch the standard CD32 ISO version of the game was attempted!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hammer

I believe my opinion on 020+ systems without full speed memory access, whether that's local fast ram or any other solution that allows full speed read/write bandwidth from the CPU, is a matter of record.

I will fight to the death anyone that thinks it was acceptable to release the 020/AGA combination with chip-only contended memory access. It's utterly inexcusable that it was ever allowed to happen. The trajectory of memory prices was well understood while the system was being designed. But no. Clearly space for an FPU was more useful...

_________________
Doing stupid things for fun...

@Karlos

Quote:

Clearly space for an FPU was more useful...

Yeah, I don't understand that. A FPU not attached to an accelerator with at least an 030/50 on board is dumb! It actuallly trumps the accelerator's FPU if you solder one on! That's sabotage!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@BigD

It's easy to criticise these things in hindsight I suppose, and I do appreciate that cost reduction was basically everything by the the time the A1200 came out, but damn, if only.

For all this, I still stand by the claim that my A1200(s) were the most inspirational and fun to use systems I've ever owned. No machine before or since has left the same mark. Some of that is the era, the fact I was 17 when I got it and it was just an amazing decade to live in from a home computing perspective.

I also remember how many people I knew at the time didn't want to upgrade in any way shape or form after they got it. For many of them, it was the upgrade, from their earlier A500. There's so much more it could have done out of the box if it had just had even 1MB of additional Fast memory just for the CPU.

_________________
Doing stupid things for fun...

@Karlos

68881's and 68882's low IPC wasn't optimized for 3D games i.e. DSP3210's 0.5 IPC is the superior solution.

DSP3210 @ 50 Mhz is about 25 MFLOPS IEEE-754 FP32 and it supports 020/030 bus.

Commodore has bulk discounts with 140 ns read-write cycle FP DRAM.

Commodore could have recycled C0 range address range for A1200's bundled 32-bit Fast RAM without affecting the Zorro II Fast RAM address range.

1 MB Fast RAM + 2 MB ChipRAM configuration would enable A1200 / CD32 to join the common 3 MB RAM CD games console group i.e. PS1, 3DO, and Saturn.

Last edited by Hammer on 10-Dec-2024 at 10:20 PM.
Last edited by Hammer on 10-Dec-2024 at 10:05 PM.
Last edited by Hammer on 10-Dec-2024 at 10:00 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@BigD

Quote:

BigD wrote: @Karlos Quote: Clearly space for an FPU was more useful... Yeah, I don't understand that. A FPU not attached to an accelerator with at least an 030/50 on board is dumb! It actuallly trumps the accelerator's FPU if you solder one on! That's sabotage!

A1200 is based on A1000Plus (68EC020/68881/16 Mhz crystal clock + AA + Bridgette + Super Buster + Ramsey + Fat Gary) before being repackaged into AA600 (68EC020 + AA + Budgie + Gayle AA). A1000Plus's FPU placement was inherited into AA600 (A1200).

Budgie includes the functions of Bridgette, Buster, and Ramsey. 28 Mhz was reused for the CPU's 14 Mhz. These are cost reduction measures started in Feb 1992 and completed in around March 1992. The A1200 design was completed around May 1992.

A1000Plus has one or two 16-bit Zorro II.

PCMCIA is 16-bit like Zorro II with byte swap chips.

A1200 design phase includes beta-testing AA chips since Jeff Frank / Bill Sydnes froze the AA beta-testing phase for "more than 6 months".

The Commodore - The Final Years includes a timeline for AA development and proves Jeff Frank / Bill Sydnes anti-AA was BS.

AA based A1000Plus and A3000Plus would be ready for Xmas Q4 1991.

Last edited by Hammer on 10-Dec-2024 at 10:15 PM.
Last edited by Hammer on 10-Dec-2024 at 10:11 PM.
Last edited by Hammer on 10-Dec-2024 at 09:58 PM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB

@Karlos

Quote:

Karlos wrote: Right, you will forgve me for my skepticism here, but here are the results from a range of C2P scenarios, conducted on a real 030 accelerator for CD32. It's an oddball being clocked at ~70MHz but if you have found a copy-speed, or even near-copy-speed C2P routine for 256 colour mode, you need to share it with the world. I for one would be extremely interested!

Note how I said "practically copy speed in Doom". Here are my results (DoomAttack, timedemo3):-

"c2p_optimized" (normal AGA c2p routine) - 10.1 fps
"fake chunky" (copy FastRAM to ChipRAM) - 10.85 fps, 7% faster.
"fake RTG" (copy FastRAM to FastRAM) - 12.65 fps, 25% faster
"Fake RTG" direct (no copy) - 13.27 fps, 31% faster

So direct copy made the game go 7% faster, practically unnoticeable. Not shown here is blitter-assisted c2p, which on my machine was the same frame rate as a direct copy (measured 10.93 fps).

FYI, here are some results for a CD32 with 8MB FastRAM compared to an A1200 with 28MHz 030:-

Amiga CD32 68020/14Mhz 8Mb (Optimised 020 C2P) - 18971 realtics (3.9 fps)
Amiga CD32 68020/14Mhz 8Mb (Akiko Optimised C2P) - 12872 realtics (5.8 fps)

Amiga A1200 030/28Mhz 64Mb (Optimised 020 C2P) - 17732 realtics (4.2 fps)
Amiga A1200 030/28Mhz 64Mb (Blitter 020 C2P) - 12727 realtics (5.8 fps)

So using Akiko increased the frame rate by 49%, making it as fast as an A1200 with 28MHz 030.

Unfortunately I don't know which 030 board was in that A1200. Some have quite slow ChipRAM write speed, which may have been a factor hare. But the bottom line is 5.8 fps is still a bit slow for Doom in standard resolution.

In 1993, games like Doom gave us taste of what the future would bring. I'm not talking about the games here, but the hardware you would need to run them. The days of programming to match the machine were over. Now you produced games that barely ran acceptably on the most powerful hardware available, and the next version would need even more power. Users would be constantly buying new hardware if they wanted to play the latest games - a brilliant marketing strategy!

Last edited by bhabbott on 11-Dec-2024 at 06:09 AM.

@bhabbott

The major problem is Commodore HR's hired less skilled software engineer Ken Dyke who declared A1200's AGA has a major problem with chunky pixels.

https://bigbookofamigahardware.com/bboah/product.aspx?id=1604
Quote:

The “chunky to planar� logic was thought out in a lunchtime conversation between Beth Richard (system chip design), Chris Coley (board design), and Ken Dyke (software) over Subway sandwiches on a picnic table in a nearby park one day, because 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. We took the idea to Hedley Davis, who was the system chip team manager and lead engineer on Akiko and he said we could go ahead with it. I showed him the “napkin sketch� of how I thought the logic would work and was planning on getting to it the next day as it was already late afternoon by that point. I came in the next morning and Hedley had completed it already, just from the sketch!

Commodore's AmigaOS autodocs warns slow software C2P solution.

http://amigadev.elowar.com/read/ADCD_2.1/Includes_and_Autodocs_3._guide/node033C.html
Quote:

From Commodore's AutoDocs, Bugs: Not very fast on systems without chunky-to-planar conversion hardware.

John Carmark repeated a similar statement in 1994.

Without Akiko's hardware C2P, Commodore officially declares slow C2P on AGA. PR wise, it looks bad.

Commodore should have hired or contracted Legends of Valour's Amiga programmer who created useful software C2P for games.

Platform's SDK quality is important e.g. Sony's PSY-Q SDK vs the competition.

The price for 68EC040-25 is close to full 68030-25 with MMU.


https://archive.computerhistory.org/resources/access/text/2013/04/102723262-05-01-acc.pdf
Page 119 of 981

For 1992
68EC030-25 PQFP = $35.94
68030-25 CQFP = $108.75

68040-25 = $418.52
68EC040-25 = $112.50

Motorola has a high premium price with MMU.

From Commodore - The Final Years
Quote:

Their architecture required three custom chips: EPIC, AMOS, and SAIL. In cost comparisons, Haynie calculated that the Acutiator architecture would add approximately $125 to a system (including the cost of a 68EC040 chip), resulting in a $300 retail price increase. This was a bargain, considering the user received a significant processor upgrade. Haynie proposed that Commodore should assign Scott Shaeffer, Paul Lassa, and himself to each create the three required gate array chips. He expected prototypes in 7 to 9 months, with the first systems shipping in 1992.

How about retail $300 68EC040-25 accelerator for A1200/A1000Plus? That's 486SX-25 class power for 386DX-33 PC prices. The 68EC040 chipset support could be reused for 68EC060-50.
Commodore management doesn't want 68EC060-25 gaming Amiga step on Commodore PC 486DX-25.

1994's 68EC060-50 has a similar asking price as 1992's 68EC040-25.

The potential offer is pretty good.

$100 68EC060 @ 50Mhz (for double INT32, pixel/texture processing, game logic) with $25 DSP3210 @ 50Mhz (for FP32, geometry processing) would be a potent value combo for desktop gaming.

Last edited by Hammer on 11-Dec-2024 at 07:38 AM.
Last edited by Hammer on 11-Dec-2024 at 07:28 AM.
Last edited by Hammer on 11-Dec-2024 at 07:26 AM.
Last edited by Hammer on 11-Dec-2024 at 07:21 AM.

_________________
Amiga 1200 (rev 1D1, KS 3.2, PiStorm32/RPi CM4/Emu68)
Amiga 500 (rev 6A, ECS, KS 3.2, PiStorm/RPi 4B/Emu68)
Ryzen 9 7950X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB