Was anyone else disappointed with the A1200?

[hammer]

Originally Posted by emiespo

Edit: missed the link. That must’ve been a really crappy GFX board that no pentium user would’ve wanted unless in an office PC.

My A4000 with 060 and Cybervision 3D could finally match a 486/DX2 running Doom, for double the money.

An A1200 with that config can barely keep up with a speedy 386. Comparing costs, it’s nonsense.

Also, Akiko’s purpose was to cut costs and integrate chips, it has ALMOST nothing to do with “hardware chunky”. It does the math operation to convert pixels, but needs to engage the cpu a lot. It was just a useful addition, given how slow the CD32 was. A real chunky mode would have been *a lot* better.

Actually: has anyone ever thought that bitplane graphics are almost always computationally worse than packed chunky? The only reason why they might have kept them relate to the initial chip design and some cost saving factor.

SNES Mode 7 has packed chunky support which needs SuperFX2 for a Doom port.

A stock A1200 CPU (without Fast RAM) and an SNES CPU have similar MIPS. Chip RAM only A1200 with packed chunky support would be similar to SNES. 1 MB Fast RAM equipped A1200 would be nearly twice the MIPS over SNES's CPU.

A1200 with 1 MB Fast RAM + 2 MB Chip RAM baseline could allow 386DX with 4 MB RAM and 3DO with 3 MB RAM profile game ports. A1200 with 1 MB Fast RAM + 2 MB Chip RAM baseline is the "foot in the door" configuration which enables the existing Budgie's 32-bit Fast RAM controller.

[hammer]

Originally Posted by Bruce Abbott

If you want the "full 32-bit 2.5D/3D gaming experience" of an SNES then just buy one, but don't expect the full range of experience the Amiga provides.

Wrong. My "full 32-bit 2.5D/3D gaming experience" statement is for a 32-bit gaming PC with at least 386DX-33 CPU and ET4000 or Trident 8900CL or WD90C32 SVGA chipsets.

SNES does NOT deliver gaming PC's "new 32-bit 2.5D/3D gaming experience".

SNES delivers a strong late 16-bit 2D gaming experience.

Originally Posted by Bruce Abbott

Ultima Underworld needed a very powerful machine to do it justice, whereas Amiga Legends of Valor ran on a stock A500. No need to buy that Gateway 486!

Wrong.
[ Show youtube player ]
Ultima Underworld The Stygian Abyss on 80386 @ 25MHz

I had a 386DX-33/ET4000AX-based PC and A3000/030 @ 25Mhz.

Originally Posted by Bruce Abbott

But the Amiga version was better.

PC has VGA while the Amiga/Atari ST version is like improved EGA graphics.

Originally Posted by Bruce Abbott

You see, the number of colors are not what makes or breaks a game. So long as you have enough to get the message across that's all you need. I can provide many examples of games where fewer colors were better. Latest example is the Amiga Knight Lore port that destroys the atmosphere and muddies the graphics. Give me the 2 color Spectrum or 3 color Amstrad version any day!

PC has VGA while the Amiga/Atari ST version is like improved EGA graphics.

I run Legends of Valor on a faster A3000 @ 25 Mhz which is like running Wing Commander with 16 colors.

[hammer]

Originally Posted by Bruce Abbott

This makes no sense. In 1985 256 colors was barely on the RADAR. IBM's Professional Graphics Controller (introduced in 1984) cost more than two entire Amiga 1000 systems. AFAIK no contemporary home computer did 256 bitmapped colors at a reasonable resolution.

AFAIK no contemporary home computer did 32 and 64-color EHB colors bit mapped at a reasonable resolution when the so-called 16-bit competition from Atari ST and IBM PCjr had 16 colors.

Back at you.

Amiga OCS already reached 6-bitplanes with a 5-bit (32) color register hack known as EHB.

Sega looked into the gaming market and decided on a fast 64-color bitmapped for the Mega Drive's 1988 release.

Commodore is happy to dismantle the original Los Gatos Amiga group.

Nintendo looked into the gaming market and decided on a fast 256-color bitmapped for the SNES's 1990 release.

Meanwhile, the SVGA cloners have cost-reduced IBM VGA/8514 standards.

Commodore had zero response to SNES until Q4 1992 while SNES has reached an install base with critical size.

Commodore shifted from being a leader to a follower i.e. Commodore looked at PC's 256 color standard.

In the 1990s, there is no "Amiga tech jump" package for purchase which forced Commodore to improve its in-house tech with less management experience when compared to the competition.

Your argument is a follower and not even zero-sum.

[logo]

A stock A1200 CPU (without Fast RAM) and an SNES CPU have similar MIPS.

Come on... SNES cpu is weaker than a 68000.
020 with CHIP RAM only plays in another league.
020 with FAST RAM is miles away.

[AestheticDebris]

Originally Posted by emiespo

Actually: has anyone ever thought that bitplane graphics are almost always computationally worse than packed chunky? The only reason why they might have kept them relate to the initial chip design and some cost saving factor.

Bitplanes are incredibly useful at the hardware level. They're more computationally expensive for a lot of operations with a CPU (although there are a handful of things that are made easier), but with specific hardware to accelerate updates like the blitter they make a lot of sense. Well up to a point, that being 256 colours.

Once you reach that point, making everything byte based starts to be an easier win on every level. And meaningful image quality improvements at that point start being much bigger jumps to 16-bit, 24-bit or 32-bit displays, all of which also work better without a planar arrangement.

[AestheticDebris]

Originally Posted by logo

Come on... SNES cpu is weaker than a 68000.
020 with CHIP RAM only plays in another league.
020 with FAST RAM is miles away.

Sure, but the SNES isn't as reliant on it's CPU. Having the ability to do things like rotate and scale the entire display, or do colour maths to create transparency/lighting effects in real time meant that it could pull off an awful lot of things that were hard to do with a purely CPU driven solution even with a high end CPU of the era.

[Promilus]

@AestheticDebris - sure, but neither is Amiga...
On the other hand 7MHz 68000 is already faster than 3.58MHz Ricoh 5A22 which is 16bit version of 6502 (but has 8 bit data bus and 2 address buses, one 24 bit and one 8bit but they do not combine into 32). Trying to say 14MHz fully 32bit (registers, execution units and ram interface) EC020 has similar performance is basically BS. On the other hand great many of SNES games uses SA1 coprocessor which is basically same 65C816 core but clocked around 10MHz so roughly 3x faster. Other games uses DSP based on NEC design, yet another games uses SuperFX chip which is 16bit RISC with clock over 20MHz. So that's how it goes. SNES was DELIBERATELY crippled at launch so Nintendo could sell enhancement chips and take more money. But the fact is - it did allow SNES to keep up for quite a while and with pretty great looking games like Donkey Kong Country.

[emiespo]

Originally Posted by Thomas Richter

The initial idea was not so bad: You can upscale the number of colors by the number of bitplanes, and thus scale by the amount of memory. You can also use the same planar blitter design, regardless of the bitdepth of the frame buffer. The alternative (back then) would be to have 1, 2 or 4 bits/pixel modes, and a blitter that is also mode-dependent and can draw lines in 1, 2 or 4 bits/pixel, which surely complicated the design, and you would still not have EHB, HAM, 32 and 8 color modes, and DualPF.

Thus, at the time the Amiga chipset was designed, it was a reasonable choice, but when RAM prices lowered, it became a burden.

Yeah but you increase the number of operations badly. I am pretty sure that if engineers designed this way it's either because of costs or simplicity of layouts, available tech of the time, etc.

There was a pretty detailed series of articles, mainly focused on the inefficiency of planar memory accesses: https://www.linkedin.com/posts/cesar..._campaign=copy

Leaving HAM alone, let's imagine a 5 bit packed format. To "move" an object of 16x16 pixels (in 32 colours) on the screen using the blitter, you'd have to access 5*16x16 bits (16*5 = 80 one row x 16 rows). Depending on the "relative position" of the object in the packed grid, an extra word might be read (and later written) by the blitter for each line, whereas with planar graphics you'd have to do an extra access for each line for each of the bitplanes, most of the times (excluding the case when the object would be perfectly aligned to a 16 bit boundary).

Again, increasing the complexity of the display fetching logic, it seems that packed graphics is always more efficient (bandwidth-wise) than planar, hence I wonder if it was chosen for a particular reason (cost of implementation with the tech of the time) or it's a bias due to other things.

I am fairly sure the engineers had a very good reason to choose it, just wondering why and also why they didn't try to move in a different direction with AGA, adding proper packed (aka chunky) modes.

[AestheticDebris]

Originally Posted by emiespo

Leaving HAM alone, let's imagine a 5 bit packed format. To "move" an object of 16x16 pixels (in 32 colours) on the screen using the blitter, you'd have to access 5*16x16 bits (16*5 = 80 one row x 16 rows).

A 5-bit packed format would be an absolute nightmare, imagine trying to plot an arbitrary pixel. Because 5 doesn't go into 16 cleanly it could start midway through a word and may or may not cross word boundaries. There's a reason machines with packed displays typically used 2, 4, 16 or 256 colour depths.

Bitplanes are a lot easier for arbitrary depth values because alignment is never an issue. And things like blitting are simplified because it's the same operation, just done X times, rather than having to do slightly different work per pixel depth.

[TEG]

Originally Posted by emiespo

I am fairly sure the engineers had a very good reason to choose it, just wondering why and also why they didn't try to move in a different direction with AGA, adding proper packed (aka chunky) modes.

I think it's based on the initial idea of Jay Miner to create a platform able to run flight simulators. So the dual playfields mode, you can manage a foreground and a background without doing computations. And yeah, on one simulator, I forgot which one, the horizon was able to rotate very fast like in real jet fighter.

[Locutus]

Originally Posted by Promilus

SNES was DELIBERATELY crippled at launch so Nintendo could sell enhancement chips and take more money. But the fact is - it did allow SNES to keep up for quite a while and with pretty great looking games like Donkey Kong Country.

Remember, the very first game with an enhancement chip was a delayed launch title, Pilot Wings!


If it's a money gauging idea, i wouldn't go that far. But it did help significantly with making the low-power SNES base unit somewhat future proof.

[hammer]

Originally Posted by logo

Come on... SNES cpu is weaker than a 68000.
020 with CHIP RAM only plays in another league.
020 with FAST RAM is miles away.

SNES's Ricoh 5A22 CPU works at approximately 1.5 MIPS, and has a theoretical peak performance of 1.79 million 16-bit operations per second. Stock A1200's 68EC020 operates like 7 Mhz.

Ricoh 5A22 has multiplication and division registers which are missing in 65C816 CPU.

Ricoh 5A22 additional circuitry for generating interrupts on calculated screen positions and generating non-maskable interrupts on V-blank.

Unlike the stock wedge Amigas, SNES uses discrete memory pools for the CPU's system RAM and GPU's VRAM.

[hammer]

Originally Posted by Promilus

@AestheticDebris - sure, but neither is Amiga...
On the other hand 7MHz 68000 is already faster than 3.58MHz Ricoh 5A22 which is 16bit version of 6502 (but has 8 bit data bus and 2 address buses, one 24 bit and one 8bit but they do not combine into 32). Trying to say 14MHz fully 32bit (registers, execution units and ram interface) EC020 has similar performance is basically BS. On the other hand great many of SNES games uses SA1 coprocessor which is basically same 65C816 core but clocked around 10MHz so roughly 3x faster. Other games uses DSP based on NEC design, yet another games uses SuperFX chip which is 16bit RISC with clock over 20MHz. So that's how it goes. SNES was DELIBERATELY crippled at launch so Nintendo could sell enhancement chips and take more money. But the fact is - it did allow SNES to keep up for quite a while and with pretty great looking games like Donkey Kong Country.

Stock A1200's 68EC020 operates like 7 Mhz. There's no SIMD with 68EC020's 32-bit ALU when operating in a 16-bit integer datatypes. 65xxx CPU operates on rising and falling edges i.e. "double pump", doing twice the work per clock cycle. Later DDR (double data rate) operates on both rising and falling edges. Note why the CSG 4510 CPU designer is hired for DDR-enabled K7 Athlon and K8 Hammer.

68000 has 16-bit ALU with 32-bit registers that are useful for 32-bit programming models for 32-bit desktop OS. SNES wasn't designed for 32-bit desktop OS and it was purpose-built for strong 2D games e.g. Ricoh 5A22 has custom hardware.

Note why multimedia SIMD still has 8-bit and 16-bit datatypes for multimedia processing.

In addition to the 65C816 CPU core, the 5A22 contains support hardware, including:

Controller port interface circuits, including serial access to controller data
An 8-bit parallel I/O port, which is mostly unused in the SNES
Circuitry for generating non-maskable interrupts on V-blank
Circuitry for generating interrupts on calculated screen positions
A DMA unit, supporting two primary modes:
General DMA, for block transfers at a rate of 2.68 MB/s
H-blank DMA, for transferring small data sets at the end of each scanline outside of the active display period
Multiplication and division registers
Two separate address busses driving the 8-bit data bus: a 24-bit "Bus A" for general access, and an 8-bit "Bus B" mainly for APU and PPU registers.
------
SNES has discrete memory buses for the CPU's system RAM and GPU's VRAM. A500's 16-bit bus is shared between the CPU and GPU. Stock A1200's 32-bit bus is shared between the CPU and GPU. A1200 has a 32-bit Fast RAM controller built into Budgie with no RAM Chips.

Commodore didn't see 6502's DDR potential e.g. AMD's K7 (data) 64-bit EV6 bus with DDR implementation. Alpha 21264 has a bidirectional 64-bit double data rate (DDR) data bus. MOS 65xx has some interesting tech.

[ Show youtube player ]
Starting at 11:42, SNES's Wolfenstein 3D with Ricoh 5A22 CPU doing most of the heavy lifting.

[ Show youtube player ]
At 13:11, 6502 at 8 Mhz running KG3D texture-mapped 3D game is impressive for an 8 Mhz CPU (effectively 16 Mhz due to double rate processing).

"The 8-bit Guy" warns against straight Mhz comparisons.

6502's double-rate characteristics have been assimilated into AMD.

[emiespo]

Originally Posted by AestheticDebris

A 5-bit packed format would be an absolute nightmare, imagine trying to plot an arbitrary pixel. Because 5 doesn't go into 16 cleanly it could start midway through a word and may or may not cross word boundaries. There's a reason machines with packed displays typically used 2, 4, 16 or 256 colour depths.

Bitplanes are a lot easier for arbitrary depth values because alignment is never an issue. And things like blitting are simplified because it's the same operation, just done X times, rather than having to do slightly different work per pixel depth.

Let’s say I want to turn pixel at coordinates 107,107 red (colour 5 in the clut).

5 bit planes: first I’d compute the Y coordinate start address, this is similar in both scenarios, imagining the hardware would discard up to N bits (final columns) in packed mode.

Then for planar I’d need to compute the bit modulo 8 (3), then divide by 8 to find the offset from the start of the row, then perform TEN accesses to memory - read with a mask - just to change one single colour. Ok on a 68020 I could leverage on bfset operations making it fairly easier and faster, but I was thinking of a 68000 ECS Amiga and of the blitter too.

Packed chunky 5 bits: similarly I’d compute the start of a row and the I’d need to divide the X coordinate by the number of planes (in this case 5), to get the initial bit, and then change 5 bits with two accesses to memory: read the resulting word, AND with a mask, OR the five changed bits with the value 5 (colour red) in one go. In the worst case the bits would spawn two bytes, so two extra accesses (as the 68000 dislikes word access to odd addresses), but most of the times it would be one read + one write. I could do another memory access to get the right value of the mask from a table. Three to five memory accesses against 10!

I understand this algorithm changes based on the display depth, but it’s basically always a lot less bandwidth, even for a blitter. If it was implemented in the Amiga 1000, we’d have had a lot more games running in 1 frame and 32 colours, something quite hard to achieve with the standard bitplane architecture that we got.

Edit: oh and a clever chipset like Amiga’s could’ve used some optimisations, like discarding the extra bit that would go to an odd address and keep all accesses aligned, at the expense of some ram. We’re talking about one bit every three pixels… for a 320x200 display that’s less than 3k of memory wasted. The AGA copper wastes a lot of memory (and bandwidth…) just to define a 24bit palette.

With this I’m not saying the original design was bad, as someone said most likely they started with a flight simulator in mind, and kept what was on the chip adapted to bit planes.

[hammer]

Originally Posted by Bruce Abbott

Sorry I must have lost track. But you said it was 'completed' in 1990. It wasn't. If it had been maybe the effort wouldn't have been 'wasted'. Anyhow Bill Sydnes did the right thing and cancelled it (just) before it was too late to develop the A1200, so it all worked out in the end.

What's interesting is that the A600 was being developed at the same time, so cancelling the C65 gave it more resources. Some say the A600 was also wasted R&D effort, but it laid the groundwork for the A1200 and became an actual product that fans enjoyed.

https://amiga.resource.cx/mod/access.html
This Amiga clone didn't use Commodore's Gayle and Budgie. Access incorporates the core Amiga chips only: Alice, Paula, Lisa, and 8520 CIAs.

Commodore wasn't in the business of selling Amiga chipsets for Amiga clones.

[hammer]

Originally Posted by Locutus

Remember, the very first game with an enhancement chip was a delayed launch title, Pilot Wings!


If it's a money gauging idea, i wouldn't go that far. But it did help significantly with making the low-power SNES base unit somewhat future proof.

https://en.wikipedia.org/wiki/Pilotwings_(video_game)

Pilotwings didn't use SuperFX, it's effectively a game tech demo for SNES's Mode 7.

NES's Mode 7 and Mode 7 Direct Color supports packed pixels.

Brian the Lion has shown some Mode 7-like effects.

[Thorham]

Originally Posted by hammer

Stock A1200's 68EC020 operates like 7 Mhz.

You're forgetting the instruction cache.

[hammer]

Originally Posted by Thorham

You're forgetting the instruction cache.

Instructions need data. SysInfo shows stock A1200's MIPS degradation.

[Bruce Abbott]

Originally Posted by emiespo

Let’s say I want to turn pixel at coordinates 107,107 red (colour 5 in the clut).

Let's say you didn't want to plot pixels one at a time, what then?

Packed chunky 5 bits: similarly I’d compute the start of a row and the I’d need to divide the X coordinate by the number of planes (in this case 5), to get the initial bit, and then change 5 bits with two accesses to memory: read the resulting word, AND with a mask, OR the five changed bits with the value 5 (colour red) in one go.

Great! Now show us the circuit made out of standard logic gate ICs. Then show us the extra circuitry you need for 1, 2, 3, 4 and 6 bitplanes too, and how you switch between them.

Jay Miner chose bitplanes for one simple reason - he could make a circuit that did 1 bitplane and apply it to as many as he wanted without a lot of tricky logic. And he didn't have any fancy HDL tools to create and debug it. To test the design he had to build the circuit on a wire-wrap board. These photos of the Lorraine prototype give you an idea of what a massive undertaking that was. If you've ever built logic circuits this way you will appreciate the effort that went into it. I've done a few, but I would never attempt something this large and complex.

The Blitter had to work in bitplane mode for doing 1 bitplane anyway, but guess how much extra circuitry you need to do multiple bitplanes? That's right, nothing. So you design your single bitplane blitter and that's it! Then to get more colors you just stack up multiple identical 1 bitplane display boards, and feed their output into the LUT. Perhaps even separate them into 2 groups, each generating its own display (dual playfield). And the blitter doesn't have to know anything about this.

But hey, perhaps you are right and it wouldn't be any more complex. Unfortunately - unlike today's armchair engineers - Jay Miner didn't think to do all it in packed pixel mode. Strangely nobody else did either. I guess they just weren't as smart as Amiga fans of today - probably due to all that tetraethyl lead they were breathing in back then.

Edit: oh and a clever chipset like Amiga’s could’ve used some optimisations, like discarding the extra bit that would go to an odd address and keep all accesses aligned, at the expense of some ram. We’re talking about one bit every three pixels… for a 320x200 display that’s less than 3k of memory wasted. The AGA copper wastes a lot of memory (and bandwidth…) just to define a 24bit palette.

I can think of more copper optimizations too, but this doesn't mean what we got was inadequate. It was far better than anything else out there. And it actually worked, unlike so many bright ideas that turned out to be impossible to implement. The AGA chipset was complex enough already, without loading it up with feature creep that would delay its introduction even more.

[Thorham]

Originally Posted by Bruce Abbott

The AGA chipset was complex enough already, without loading it up with feature creep that would delay its introduction even more.

Not having chunky modes still sucks, though