Was anyone else disappointed with the A1200?

[abu_the_monkey]

Originally Posted by Karlos

One of the original claims regarding the Akiko was that it could do c2p at least as fast as a 68040. This is likely true but I have no idea if that statement takes into consideration the klunky way you have to use it. Add to this mix the fact that software c2p has improved significantly on 040+ since the days those claims were made and I'm not sure how true it is today.

Maybe we should add support in AB3D2...

It would be interesting to see how AB3D2 performs on a cd32 with FastRAM + Akiko

[Bruce Abbott]

Originally Posted by abu_the_monkey

the times quoted are for just converting 1x320x256 screen c2p I assume?

Yes, that's what it says.

cos there is no way a CD32 with a 68020/14+fast+akiko could do the entire game loop and the c2p at 50fps.

Obviously. This is why to run games like Doom and Quake as intended akiko c2p becomes 'useless' (as Thomas Richter describes it) since you need a fast CPU anyway which can do it just as fast without akiko.

Akiko c2p is useful when you don't have fast CPU and the 'entire game loop' isn't that taxing. Heart of the Alien is a good example. It is the sequel to Another World, which was originally developed on an A500. However Heart of the Alien was ported back to the Amiga from a platform that used chunky graphics, so to avoid having to recode the graphic routines they just applied c2p. As result the original port needed a 50MHz 030 for full speed animation, but the CD32 with akiko was able to match that performance with a 14MHz 020 and no FastRAM! This is exactly what akiko c2p was designed for.

Gloom is another example. According to Peter McGavin, his Alternative C2P Routines v1.0 for Gloom Deluxe are the same speed as the original in 1x1 mode, but 3-4 times faster when using akiko. Unfortunately the CD32 version of Gloom didn't use akiko, and I can't find any hard data on frame rates with and without it. However I think it's safe to assume that it would have been significantly faster using akiko.

But even Doom benefits from akiko. Obviously you need FastRAM to play this game on the CD32, and the frame will be low due to the slow CPU. However akiko c2p still managed to make it 50% faster (5.8 fps vs 3.9 fps in timedemo3). ~6fps may not be fast, but considering that a 50 MHz 030 only got ~9 fps (8.8 fps in timedemo3) it's still a worthwhile improvement. Switch to low detail (2x1 pixels) and a smaller screen size, and Doom is playable on a CD32 with 4MB FastRAM!

[Bruce Abbott]

Originally Posted by Karlos

Using the Akiko sucks up a lot of bus time because you have to transfer 8 longwords from your chunky buffer to the registers, then move them again from there to the chip ram.

It's not necessarily as bad as it sounds. On the CD32 ChipRAM runs at 7MHz, but akiko runs at 14MHz. So for every 4 pixels you have one read of the chunky buffer in ChipRAM at 7MHz, one write and one read of akiko at 14MHz, and one write to ChipRAM at 7MHz, for a total of three 7MHz bus cycles per 4 pixels (+ CPU instruction overhead). In comparison a software c2p routine needs dozens of CPU cycles plus (at least) two ChipRAM cycles.

If you rendered those chunky pixels directly to akiko then it would only use the equivalent of two 7MHz bus cycles per 4 pixels (plus a few cycles of CPU overhead). You would have to consecutively write 32 pixels at a time, but this could potentially make horizontal texture mapping even faster.

[Gorf]

Originally Posted by Bruce Abbott

It's not necessarily as bad as it sounds. On the CD32 ChipRAM runs at 7MHz, but akiko runs at 14MHz.

Does it? Or is it more or less "instant", as it just represents the data/buffer in a different way? It doesn't do any calculations I assume, the data just needs to fall into the right place. So no clock, but register latency?

[Karlos]

Originally Posted by Bruce Abbott

If you rendered those chunky pixels directly to akiko then it would only use the equivalent of two 7MHz bus cycles per 4 pixels (plus a few cycles of CPU overhead). You would have to consecutively write 32 pixels at a time, but this could potentially make horizontal texture mapping even faster.

Sure, but that's extremely unlikely. Many classic 2.5D engines heavily rely on columnar rendering for walls and render spans only for floors and ceilings. Full 3D (quake style) engines render discrete triangles and all the data organisation is around the source texels rather than the destination buffer.

[Bruce Abbott]

Originally Posted by grond

Says the guy who constantly argues that the lack of a chunky mode wasn't a problem at all. Now it turns out that even a kludge that requires write-read-write operations through the slow bus to convert planar to chunky is better than a 50 MHz 030 with fastmem.

I said not having chunky wasn't a problem for games that already needed a fast CPU. 20% faster c2p isn't a lot when the CPU spends much more time doing game stuff, where a 50MHz 030 will easily beat a 14MHz 020.

As for having a chunky mode built in, sure it would be nice but would it necessarily be faster? Rendering directly into ChipRAM has been shown to be slower than rendering to FastRAM and copying to ChipRAM. To make best use of a chunky mode you would want some FastRAM. This wasn't going to happen on the CD32 because it would blow their budget, delay the launch due to having to redesign the custom chips for chunky, and be incompatible with the A1200 which was against the philosophy of having a standard chipset across models (akiko style c2p could easily be added on a plug-in card, a new Alice etc. couldn't).

However I'm betting they would have put chunky into AGA+, had they survived that long.

[Thorham]

Originally Posted by Bruce Abbott

As for having a chunky mode built in, sure it would be nice but would it necessarily be faster?

Compare a simple copy loop and the not so simple c2p code and get your answer.

[Bruce Abbott]

Originally Posted by Karlos

Sure, but that's extremely unlikely. Many classic 2.5D engines heavily rely on columnar rendering for walls and render spans only for floors and ceilings.

So it could make floors and ceilings a bit faster. It could also help games like Heart of the Alien that use filled polygons. And don't forget 2D games which use chunky, eg. ports from the PC. A game that used 16 or 32 pixel wide tiles could be a natural for this technique (probably better to convert the graphics to planar but keeping it chunky is easier).

Full 3D (quake style) engines render discrete triangles and all the data organisation is around the source texels rather than the destination buffer.

Quake is so far beyond what a 14MHz 020 can do that it's not worth discussing. My A3000 with 50MHz 060 and RTG card struggled to get above single digit frame rates.

[abu_the_monkey]

Originally Posted by Bruce Abbott

I said not having chunky wasn't a problem for games that already needed a fast CPU. 20% faster c2p isn't a lot when the CPU spends much more time doing game stuff, where a 50MHz 030 will easily beat a 14MHz 020.

As for having a chunky mode built in, sure it would be nice but would it necessarily be faster? Rendering directly into ChipRAM has been shown to be slower than rendering to FastRAM and copying to ChipRAM. To make best use of a chunky mode you would want some FastRAM. This wasn't going to happen on the CD32 because it would blow their budget, delay the launch due to having to redesign the custom chips for chunky, and be incompatible with the A1200 which was against the philosophy of having a standard chipset across models (akiko style c2p could easily be added on a plug-in card, a new Alice etc. couldn't).

However I'm betting they would have put chunky into AGA+, had they survived that long.

if the memory could have been configured on start-up by the software so that you could have 2meg ChipRAM or 1meg Chip + 1meg Fast or even 512k Chip + 1.5meg Fast it could have been neat. at the end of the day if you are doing c2p from FastRAM the ChipRAM is just a frame buffer.

[Karlos]

Originally Posted by Bruce Abbott

Quake is so far beyond what a 14MHz 020 can do that it's not worth discussing. My A3000 with 50MHz 060 and RTG card struggled to get above single digit frame rates.

I take it you didn't see that 3D engine that was posted here last year then. It was a full 6DOF 3D engine, running on 020/Fast with a custom C2P routine.

[ Show youtube player ]

[lmimmfn]

Originally Posted by Karlos

I take it you didn't see that 3D engine that was posted here last year then. It was a full 6DOF 3D engine, running on 020/Fast with a custom C2P routine.

[ Show youtube player ]

It's interesting you bring that up, it seems to have the lack of Z Buffer issues that the PSX had, is there any optimization on the Amiga if it did the same?

[Bruce Abbott]

Originally Posted by Karlos

I take it you didn't see that 3D engine that was posted here last year then. It was a full 6DOF 3D engine, running on 020/Fast with a custom C2P routine.

[ Show youtube player ]

Yes, I've seen that demo. Might be a good rendering engine for a game, but Quake it isn't.

Unfortunately like many of these 'tech' demos it's hard to tell how useful it would be in an actual game. This one doesn't seem to have many colors. Maybe that's just because they were lazy, or perhaps it really only has 16 or 32 colors. Nothing wrong with that (I think reducing colors could be a good way to improve performance), but it wouldn't be a fair comparison to games that use 256 colors.

Perhaps more importantly though, this demo is missing a lot of stuff like seeing beyond walls, 3D renderd objects and particles, and AI, that make Quake require a lot of CPU power. c2p is the least of your problems. On my A3000 the frame rate was very variable which was annoying and made gameplay very difficult. I've seen videos of Quake running on an A1200 with Vampire in AGA and it was super smooth with a consistently high frame that made me jealous.

[Bruce Abbott]

Originally Posted by abu_the_monkey

if the memory could have been configured on start-up by the software so that you could have 2meg ChipRAM or 1meg Chip + 1meg Fast or even 512k Chip + 1.5meg Fast it could have been neat.

That would make the hardware very very complicated. Better to just shove in eg. 2MB Chip and 2MB Fast, and use only ChipRAM when seeking compatibility with a stock A1200. An option to map some 'slow' RAM at $c00000 might be useful for running the few older games that needed it, but since you would be patching them to run on the CD32 anyway you might as well make them work on 2MB Chip too.

[CCCP alert]

I am not seeing anything special about Heart of the Alien on Amiga gameplay videos needing a 25mhz 030 minimum etc. Smells of poor port job to me. Looks pretty much identical to Another World actually.

Still not convinced Akiko was more useful than releasing the CD32 with 2mb+128k rather than having Akiko and a fuxxored CPU bus crippled to half speed. YMMV.

[AestheticDebris]

Akiko works best when you're drawing horizontally, so I imagine the thought process behind the design was that rendering video or even still images from PC formats could be easier. Just write each pixel value into Akiko at full CPU speed, then every 32 pixels do the copy into slow chip RAM. Minimal impact of the system.

Most 3D games of the era were column based though, which just doesn't lend itself to that approach. So you end up having to buffer the entire frame and then do a C2P copy, or at the very least render 32 pixel columns worth, to fit into how Akiko wanted to work.

I'm inclined to agree on Heart of the Alien though, I think it might have cut development effort but I suspect even the A500 could have pulled of something similar with an Amiga-centric port.

[Thorham]

Originally Posted by Bruce Abbott

I've seen videos of Quake running on an A1200 with Vampire in AGA and it was super smooth with a consistently high frame that made me jealous.

Why would you be jealous of Quake running on a Vampire?

[Gorf]

Originally Posted by AestheticDebris

Most 3D games of the era were column based though, which just doesn't lend itself to that approach.

"One man's column is the other man's row ..."

OK, there is no such saying

But we are talking about very low resolutions here and one could properly adjust the algorithm to render several columns quasi-parallel in lockstep.
And for a 160px wide resolution each column can be doubled, so we would only need two parallel columns to fill our longword we send to Akiko.

Still not saying Akiko is an ideal solution ....

And I really wonder about the internals of Lisa and can not come up with a good reason, why the same logic would be so hard to implement there other than the chip was already taped out ...

[SkulleateR]

Originally Posted by Gilbert

Was anyone else disappointed with the A1200?

No

[TEG]

Originally Posted by Gorf

And I really wonder about the internals of Lisa and can not come up with a good reason, why the same logic would be so hard to implement there other than the chip was already taped out ...

They lost the plans

[TEG]

I watched a video about macOS which show that it was an unstable OS for a very long period of time. Apart occasionally, I never really used a MAC (especially I always found the one button mouse design stupid) so I never had a chance to realized that.

On the contrary, I used the Workbench quite intensively and since AmigaOS 2.0, from my memory, it was rather very stable. I don't know who worked on it at CBM but AmigaOS 3.0 bundled with the A1200 was working well. However a tasks bar was really missing because, with now more memory, it was problematic to navigate between a bunch of applications running simultaneously.

Comments of the video tend to confirm the instability of the MAC:

As a network admin that supported a mixed network of about 300 computers 1/4 Mac, 3/4 windows, 1 AS400, and a couple Unix/Linux servers. I can say that nearly 2/3 of my support calls were from the Macs. Mac, Crash different.

[ Show youtube player ]