[_lbaq]

>Likewise, I think Tramiel could have done something similar instead of diving down the 68000 path with the Atari ST.

The Atari ST was built from scratch in less than 8 months after the deal to license the Amiga chipset fell trouhg. The ST is an amazing engineering feat considering the insane schedule.

I agree on you that the 68k is a terrible CPU for gaming, but it got better when there was some cache added to it, starting with the 68030.

I had an Acorn Archimedes with an ARM 2 clocked 8 Mhz (the same speed as the Atari ST, and 1 Mhz faster than the Amiga 1000/500), it was so much faster than my ST.

[cmrdporcupine]

Yeah don't get me wrong, I was an ST user and loved it. It was a business and technical accomplishment. All respect to it. My point was only that for that class of machines what we really needed was wider address buses, not necessarily wider data buses. Along with a wider data bus came slower cycle times for a bunch of operations. And cost.

[mschaef]

> [Atari] ST.... what we really needed was wider address buses,

Are you sure? With memory costing hundreds of dollars per MB in the mid-80's, I remember thinking a 24-bit address bus was plenty. (I actually don't think I personally had a computer with enough RAM to need more than 24-bits of physical addressing until the mid-90's.)

[cmrdporcupine]

I never meant wider than 24 bits. I meant wider than the 16 bits on the 8-bit machines. Sorry if I was unclear. I didn't need a machine with more than 16MB until the mid 90s.

[mschaef]

Agreed... 16-bit physical addressing was very limiting. (x86's 16-bit segment offsets were bad enough.)

[Lio]

I always wonder if considering the processor and the “chunky pixels” of the Archimedes if had had something like a Wolfenstein or Doom back in 1987 if it would have driven sales enough to change.

Ofcourse that was probably pretty unlikely considering the Acorn/Olivetti bet so heavily on the education market.

[pjc50]

Probably not quite enough raw MIPS in 1987, but people have since ported it: http://gerph.org/riscos/ramble/doomplus.html

[Flow]

Maybe it was more a lack of the DOOM source code or know-how?

According to https://en.wikipedia.org/wiki/Instructions_per_second#Millio... the ARM2 at 8MHz was 4MIPS. The 386DX at 33MHz was 4.3MIPS. The 8MHz 68000 was 1.4MIPS.

Of course there could be other things that made it hard, such as too few bus cycles when running the 8-bit chunky graphics mode? Or that sound did not use DMA(I don't know if the Archimedes had sound DMA) or that the CPU had to mix samples instead of the sound hardware doing it?

[the-dude]

That was Zarch : https://www.youtube.com/watch?v=MNXypBxNGMo

This was the gold standard at the time.

[lstodd]

Very much like the Zeewolf https://youtu.be/tVwScInZfP8?t=159

I wonder what the connection is.

[the-dude]

Zarch : https://en.wikipedia.org/wiki/Zarch, 1987 Zeewolf : https://en.wikipedia.org/wiki/Zeewolf, 1994

[lstodd]

The visuals look very similar, but I can't see any continuity in the wikipeadia article.

OTOH, the sqare grid terrain can be traced to at least https://en.wikipedia.org/wiki/Return_Fire although that was a sequel to a completely different game

[_lbaq]

Zarch was out out 1988, the port of Zarch, Virus, came out on Atari/Amiga a bit later, this came out 1995...

[lowbloodsugar]

Chunky pixels? =) [1]

[1] https://www.youtube.com/watch?v=ACb0h7mmcQ8

[_lbaq]

Chuncky pixels refers to the "1 byte = 1 pixel" in this case, both the Atari and the Amiga had bitplanes, where the separate planes where interleaved into the bytes, this was a product of hardware limitations at times, for example using bitplanes you could do foreground graphics without the need to redraw the background graphics when the foreground moved, something that was valuable since the slow hardware (CPU and memory) could hardly keep up with the racing raster beam otherwise.