Amiga - a 16bit or 32bit machine?

[itix]

I would say it is 32bit software running on 16bit hardware. If you are a hardware guy Amiga is clearly 16bit. If you are a software guy Amiga is 32bit.

[Trev]

In console gaming terms, OCS/ECS would be 16-bit, AGA 32-bit. Those terms lost their meaning with the release of the SNES/Super Famicom, but that didn't stop marketing departments from using them.

[Karlos]

I imagine most 3D engines that run on the PS2 do backface culling, at the very least. There are many, many methods to throw away non-visible polygons, and leaving it until the hardware is about to render them is not a good idea. Really, you want to throw away non-visible polygons as early as possible.

This is actually a golden rule on every graphics pipeline I've looked at: The fastest elements are the ones you don't draw, so always eliminate stuff as early as possible.

Back face culling is a standard technique and one that's comparatively cheap to test for, even in software.

[Speelgoedmannetje]

I imagine most 3D engines that run on the PS2 do backface culling, at the very least. There are many, many methods to throw away non-visible polygons, and leaving it until the hardware is about to render them is not a good idea. Really, you want to throw away non-visible polygons as early as possible.

Eh, okay, it maybe a bad example, (or not, as you point out the programmer part of it).
Still, offscreen and backface culling done by hardware should be faster.
AFAIK this also enabled the Dreamcast to be able to render cell shaded games like Jet Set Radio.

[Speelgoedmannetje]

In console gaming terms, OCS/ECS would be 16-bit, AGA 32-bit. Those terms lost their meaning with the release of the SNES/Super Famicom, but that didn't stop marketing departments from using them.

The SNES is dog slow, but has some nice bits like hardware rotation, which enabled it to run games like Mario Kart, Wolfenstein and even Doom (though the latter being quite ugly).
It's something that really should've been part of the AGA chipset (plus a DSP, like the Falcon had).

[quarkx]

Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...

[drHirudo]

Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...

The Sega Mega Drive is stated as 16 Bit console (Actually the first 16 bit console), while the first 32 bit console is the Amiga CD32.
The Mega Drive have very similar architecture to the Amiga 500 - ~8MHz CPU, hardware sprites, soundchip etc.. The Amiga CD32 is close to the hardware of the later X68000 computers.


Commodore 64; Atari 800; Sega Master System; Nintendo NES; Apple II ---> 8 bit.
Amiga 500/600/1000/2000/CDTV; Atari ST; Sega Mega Drive; Super Nintendo; Apple IIGS  ---> 16 bit
Amiga 3000/1200/4000/CD32; Atari Falcon; Sega Saturn; Sony Playstation; Apple Macintosh Quadra ---> 32 bit
microAmigaOne/AmigaOne XE/SE/Sam/Pegasos ---> 64 bit.

[Karlos]

Still, offscreen and backface culling done by hardware should be faster.

Not necessarily, it very much depends on how the graphics pipeline is implemented. If you have a complete hardware transform and lighting system then the chances are hardware culling may be faster since it is logically part of the transformation process.

However, if you have only a hardware rasterizer, which was true of most early generation 3D accelerators, then you've expended cycles to transform polygons and calculate their lighting, only to have the hardware discard them when their screen space orientation ends up being back facing.

Even something simple like hardware clipping can be slower when there are interpolants such as polygon colour to consider. For example, the chip might have to spend quite a while calculating the ramp value of a pixel that is going to be rejected. Clipping the polygon in software first before passing it to the rasterizer would result in a speed up then. This isn't theoretical either, the Permedia 2 was a prime example of a chip that you got the best performance when you eliminated backfacing polygons and clipped large shaded ones before passing the vertex data to the chip.

[save2600]

Ah! this debate brings me back to my Color Computer days! For those that don't know the CoCo had a 6809 processor that had a 8 bit Data bus and a 16 bit Address bus, so everyone debated 8 or 16? I am sure those with the Dragon know what I am talking about as the dragon was essentially the same computer as the CoCo.
Yes, its off topic...

Reminds me of the Ti-994's & TG-16 systems.

But I've always considered an Amiga running 16-bit ram to be a 16-bit computer.
Amiga's with 32-bit ram and NO 16-bit ram is a 32-bit computer. Mixture of both types
could just as well be considered 24-bit.  LOL!  And speed wise, you all know what I am
talking about.

[Karlos]

Reminds me of the Ti-994's & TG-16 systems.

But I've always considered an Amiga running 16-bit ram to be a 16-bit computer.
Amiga's with 32-bit ram and NO 16-bit ram is a 32-bit computer. Mixture of both types
could just as well be considered 24-bit.  LOL!  And speed wise, you all know what I am
talking about.

Think of it this way. The 68020 is how many bits wide? You'd say 32, more than likely.

However, you can run a 68020 on a 32, 16 or even 8-bit data bus just fine. Buses do not define the machine, merely it's interconnectivity.

The reason the general purpose register width is taken as a metric is that it cuts through the hardware implementation of a system completely. The old 8-bit microprocessors may have had 16-bit address buses but they are considered to be 8-bit and not 16-bit simply because for most of them, you can't treat the 16-bit register pairs as single entities. Ok, there are usually a few basic arithmetic operations that can be performed on them, but it's normally only a subset of what can be performed on their respective 8-bit halves.

The 68000 still has 32-bit wide general purpose registers (including the address registers). Regardless of the ALU width and external buses, general purpose operations can be performed on all 32-bits of a 68000 register. It is therefore best considered a 32-bit processor.

[warpdesign]

Actually the first ever 32bit console is the FM Towns Marty, released in February 1993.

And the X68000 is way more powerfull than the CD32 in terms of sprite/scrolling handling... 128 hardware 16x16 sprites.

[Karlos]

Actually the first ever 32bit console is the FM Towns Marty, released in February 1993.

And the X68000 is way more powerfull than the CD32 in terms of sprite/scrolling handling... 128 hardware 16x16 sprites.

Sprites, or blitter objects?

[ejstans]

Eh, okay, it maybe a bad example, (or not, as you point out the programmer part of it).
Still, offscreen and backface culling done by hardware should be faster.
AFAIK this also enabled the Dreamcast to be able to render cell shaded games like Jet Set Radio.

The technique of the Dreamcast (the PowerVR chip really) was not about backface culling or anything like that. The aim was to achieve a high fill rate by avoiding overdraw. It worked by processing tile by tile instead of polygon by polygon. The graphics core had a 16x16 pixels (if I recall correctly) tile buffer with a Z-buffer with very high bandwidth. The framebuffer was divided into an array of tiles, and instead of directly rendering a polygon, the graphics core stored the vertex information in a buffer. After the polygon data for a scene had been submitted, the graphics core would go through each tile and determine which polygons might be visible there. Then it would render all those polygons to the internal tile buffer. After all polygons for that tile had been rendered to the high bandwidth buffer, the contents was copied to the appropriate slot in the framebuffer tile array. This technique minimized memory bandwidth requirements by avoiding all overdraw (or overhead from updating the Z-buffer) at the cost of having to have a vertex buffer to collect polygon data. Of course techniques such as backface culling were also used to minimize the number of polygons to be rendered.

Oh, and to get back on topic, the 68000 only had a 16-bit ALU which means any 32-bit operation takes longer time to execute. Why not stick with the 16/32 moniker?

[Zac67]

Usually the CPU (data bus) defines whether the machine is called 16 or 32 bit (think of a PC 386DX with ISA slots - 32 bit). So all earlier Amigas (1000, 500, 2000, 600, CDTV) are 16 bit machines, later/bigger ones (3000, 4000, 1200, CD32) are 32 bit machines.

When it comes to chipsets, OCS/ECS is definitely 16 bit. AGA is partly 32 bit (graphics data), so I'd call it 16/32 bit.

However, the architecture is based on a 32 bit command set with everything appearing 32 bit wide, 32 bit software etc. So I'd call the Amiga per se a 32 bit system.

[bloodline]

Usually the CPU (data bus) defines whether the machine is called 16 or 32 bit

Usually the Data bus and the general purpose registers are the same width...

[Speelgoedmannetje]

The technique of the Dreamcast (the PowerVR chip really) was not about backface culling or anything like that. The aim was to achieve a high fill rate by avoiding overdraw. It worked by processing tile by tile instead of polygon by polygon. The graphics core had a 16x16 pixels (if I recall correctly) tile buffer with a Z-buffer with very high bandwidth. The framebuffer was divided into an array of tiles, and instead of directly rendering a polygon, the graphics core stored the vertex information in a buffer. After the polygon data for a scene had been submitted, the graphics core would go through each tile and determine which polygons might be visible there. Then it would render all those polygons to the internal tile buffer. After all polygons for that tile had been rendered to the high bandwidth buffer, the contents was copied to the appropriate slot in the framebuffer tile array. This technique minimized memory bandwidth requirements by avoiding all overdraw (or overhead from updating the Z-buffer) at the cost of having to have a vertex buffer to collect polygon data. Of course techniques such as backface culling were also used to minimize the number of polygons to be rendered.

Thanks for the explanation I couldn't find such detailed info on the net.

Oh, and to get back on topic, the 68000 only had a 16-bit ALU which means any 32-bit operation takes longer time to execute. Why not stick with the 16/32 moniker?

Yea, back in the day, the 68000 was considered a 16 bit proc. My Sega Megadrive is also labelled "16 bit".