Amiga - a 16bit or 32bit machine?

[Speelgoedmannetje]

I don't know how to classify the A3000. I think it had a 32-bit data bus, but the chipset only used 16-bit.

And we should never underestimate the chipset. See the Atari Jaguar.

[Speelgoedmannetje]

The whole thing about bits is nonsense anyway. Every computer/console has it's unique chipset with it's pro's and cons, so why talk about the bits?

I like the comparison between the Playstation 2 and the Dreamcast. While the Playstation 2 can show a lot more polygons (16 million, while the Dreamcast can only show 3 million), the Dreamcast has the trick up it's sleeve, for not rendering those polygons which aren't visible. As you see, the whole comparison becomes a lot more complicated.
Add to that how well the system can be programmed, how skilled the programmers are, and voila! There you have the end of the discussion!

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

[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".

[Speelgoedmannetje]

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

Not really, no. The FM Towns Marty contained a 386SX, the SX variant of the 386 had a 16 bit databus, like the 68000. Therefore, you could as well say the Sega Megadrive was the first 32 bit console.

[Speelgoedmannetje]

So, was the 68030 powered Atari Falcon 16 bit then?

Eh? The 68030 is, (as well as the 68020) clearly a 32bit processor, no?

[Speelgoedmannetje]

The falcon used a 16-bit databus for the CPU. As I said, the 68020 (and 030) are perfectly happy running on narrow data buses. Only the number of cycles required to transfer 32-bit words is affected. You can run a 68020 on an 8-bit databus if you really want

I can't find anything about it using a 16 bit databus, are you sure it's not about an address bus? They cut that down often back then (as they did with the proc of the CD32), because memory was expensive and nobody would buy more memory than a reduced processor could handle.
Cutting down the address bus doesn't affect the speed of the processor, so I'd still call it 32 bit.

Hence the reason for preferring GPR width over concerns like buses and memory organisation.

My GPU has a 448-bit bus, I wouldn't call it a 448-bit machine

Thankfully, the days of using bits and megaherzes are over . Still, and as always, it's up to the developer to make a system run or crawl. Considering that, there's still a lot to conquer.

[Speelgoedmannetje]

http://en.wikipedia.org/wiki/Atari_Falcon

A 16-bit address bus would be pretty poor show. That would be in the same league as the ZXSpectrum and C64

I don't understand that. For as far as I have read, the address bus doesn't affect the speed of the processor, yet the data bus does.
-edit- of course I understand that 65,535 bytes of memory is indeed not that much. I was a bit focused on the proc speed itself.

And therefore, yes, the Falcon does seem to be 16 bit. I guess it was it's main bottleneck, because IIRC the Falcon was considered to be slow.

You'd be surprised how easy the GPU is to program and how difficult it is to program well

I'd love to program one day... when I have some time.

[Speelgoedmannetje]

If it were being marketed circa 1990....

:lol:

[Speelgoedmannetje]

A 16-bit address bus would be more of a problem. It would limit you to 64K address space. I'm not sure if the 680x0 is capable of running on a "narrow" address bus in the same way it does a data bus.

Yes yes I thought of that later. I wasn't thinking, or well, I was a bit confused with only thinking about processor speed.