Amiga - a 16bit or 32bit machine?

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

[Nostalgiac]

oh noooo... not this old hat rechewed once again.

the 68000 was designed as a full 32bit cpu, only cost restriction caused external busses to be restricted to 16 (or late 24) bits. Study the cpu design docs as I did in 1991 for my university project.

end of story - move on

Tom UK

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

[Karlos]

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

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

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

[koaftder]

We're just arguing about what label the marketing droids slapped on the side of the box at this point.

[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?

[Karlos]

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

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.

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

[Zac67]

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

Not necessarily:
- Z80
- 68008 (!)
- 68000
- 8088
- Pentium (32 bit registers vs. 64 bit bus)
- ...

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

[Karlos]

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, because memory was expensive and nobody would buy more memory than a reduced processor could handle.

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

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.

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

[Trev]

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

If it were being marketed circa 1990....

[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:

[Karlos]

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.

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.

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

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.

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

[ejstans]

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.

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

Gosh, what a silly thing to do, to needlessly starve a CPU on memory bandwidth! I doubt the 68030 was very happy with that arrangement!

Anyway, what possible use is it to dub a machine this-or-that many bits? By itself, such a number is completely useless. Remember the CD32. What a laff compared with Saturn or Playstation in the 32-bit console battle...

Hmmm, the Playstation, now that was a beautiful machine :cool: