When were other inexpensive computers able to recreate "The Amiga Juggler"?

Question

The Amiga Juggler was the 2nd very popular demo to appear for the Amiga Computer early in its lifespan. The demo was created by Eric Graham (who went on to develop Sculpt3D) using raytracing to both render the scene and play the animation on a stock 512K Amiga 1000. Unlike the earlier Boing! demo, which barely tapped the Amiga's graphics abilities and was widely aped on other computers, Juggler does not seem to have ever been ported.

While Juggler was a tech demo of both raytracing and animation of the resulting frames, I'm not concerned with the rendering process simply because any computer with enough RAM could do it given sufficient time. But the actual playback of the animation was an impressive use of Amiga graphics unmatched in other low-cost computers of the time. Consider:

• A high color-depth framebuffer capable of 4,096 simultaneous colors at 320x200.
• Sufficient graphics memory/bandwidth to play at a smooth 30 fps.
• Nearly full-screen animation, since a relatively large portion of the scene must be modified between each frame.

Any port that was attempted would need to target a machine with the above attributes, at minimum, in order to faithfully recreate the Juggler demo.

I know that by the late 1980's, there were Macintosh II and PC w/ SVGA computers available. These were not only much more expensive than Amigas, but they were normally limited to 256 on-screen colors and did not have an architecture supportive of full-screen 30 fps animation.

An Amiga 1000 cost $1,495 with 512K in 1986 and an Amiga 500 with 512K was $699 ('87). So, I'd say approximately $1,000 is a suitable metric for an inexpensive system that might match the Amiga. How long was it before another roughly $1,000 computer was available with the palette, resolution, and graphics bandwidth to faithfully recreate Juggler?

Answer 1

This is only indirect an answer, but rather targeted at what it seams are misconceptions about Amiga (RAM) bandwidth and inner workings of its HAM (Hold and Modify) graphics mode.

The Amiga advantage for Juggler was both the size of the colour palette and the bandwidth efficiency of HAM

(From a comment)

Well, to start with, while HAM mode could display 12 bit colour (4096) on screen, these weren't independent of each other. Only the 16 colours of the basic palette can be used at any given position (*1). Every other pixels colour is generated by modifying one (RGB) channel's 4 bit value. So if a colour is needed that is not one of the 16 base colours, up to two intermediate pixels with somewhat similar colours are needed (*2). Effectively reducing the horizontal colour resolution to a third - 106x200.

Due to this dependence between successive pixels manipulating HAM for animation is rather complex and needs quite some CPU to avoid unintended effects - if they can be adverted at all. Since HAM's memory representation is also tied to the plane structure of all Amiga graphics, each pixel manipulation (may) take six separate write operations.

Next, the assumed 'bandwidth efficiency' is less of a general advantage but rather a way to overcome limitations of the Amiga hardware. Chip RAM - the area where graphics reside - is shared between chipset and CPU. Each access to generate video does slow down the CPU. Increased resolution and colour depth can slow down the CPU from the nominal 7 MHz to an almost full stop. So using less bandwidth doesn't exactly help to display a picture. It just leaves the CPU running (almost) unharmed.

In terms of memory bandwidth a plain (no additional tasks) 320x200 is always the same, no matter if 64 colour mode or HAM is used. Thus the only advantage of HAM is a possible higher colour usage (within the defined limits).

Bottom line: HAM is a nice idea, if the output is destined for a TV-like device and displaying more or less TV like, static pictures. (*3)

Taking all of this into account, then it's obvious that the juggler is less of a great example of what can be done in HAM mode on an Amiga, but rather a splendid exercise to overcome the built-in limitations ... well, if it would have been in real time. But it has been pre-rendered. So the demo isn't about doing all the complex tasks to generate a HAM image, but just a player loading the frames into display memory.

Here again the lower bandwidth usage for graphics isn't as important as it may seem. Sure, it leaves more room for the CPU to transfer frames into chip memory. So lets see what data rates we need.

A 320x200 HAM picture needs 6 planes of 64000 bit each, or short of 47 KiB each. Lets make that 48 KiB for easy calculation. At 30 frames/s (*4) this is up to 1,440 KiB/s (*5) - that's roughly 40% of what the 68k has available in this mode. Tight, but no big deal.

Further more the animation format used by Juggler was a delta encoding, only storing stripes of content changed between successive frames, reducing the data to an average of 10 KiB (*6,*7) or ~20%. Giving less than 250 KiB for the full animation. Now it's even less a deal for the 68k.

Easy to see that this compression has way more influence on bandwidth (80%) saving than HAM mode vs. some hypothetical full 12 bit colour mode (50%) (*8).

The good compression ratio also allows for even the smallest Amiga to hold all animation data in RAM, eliminating any wait for the floppy drive.

This reduces the task of displaying to a sustained memory to memory move of 250 KiB/s.

Bottom line: Selecting the right animation, plus conventional delta encoding, plus holding all data in RAM reduces the task way below any critical threshold.

So what could other system do?

Sure, the arch enemy, the Atari ST could only do 16 colours at 320x200 but also used only 32 KiB to do so. As a result, the task gets even faster on the ST: A third less data (*9) to be moved and at the same time ~15% more bandwidth for the CPU to do so (8 MHz instead of 7). This even leaves plenty room to use palette tricks and use 512 colours (still not more than 40 per line).

In fact, in 1987 a VGA equipped IBM-PC may even beat both. A 320x200 mode is default. Sure, only 256 simultaneous colours, but these are taken from an 18 bit range. Depending on the picture this may give a higher quality colour display than Amiga's HAM mode. And while it needs whopping 64,000 bytes per full frame, the resulting delta frame (*10) may average around 10-11 KiB, thus stay within the same space requirement as with the Amiga.

Of course the PCs memory bandwidth on the ISA BUS is rather slow compared to on-board memory or Atari/Amiga video memory. A (1986) PC AT would do about 1.2 MiB/s (*12) maximum transfer rate on an 8 bit VGA (as the IBM one was). That's about 4 times the transfer rate needed to play the Juggler video. A 16 Bit (*13) VGA could do even close to 5 MiB/s due 16 bit access plus less wait states. So most definitely no bottleneck here.

Similar calculation can be made for other contemporary machines. (*14,*15)

Bottom line: The Juggler Demo was quite cool for its time, but not out of the ordinary or something only the Amiga could do.

P.S.: Here some contemporary Atari ports.

---

*1 - For the first pixel of a line it is assumed that the border colour (colour 0) is already set, so any colour that can be done by modifying a single channel can be generated here.

*2 - If that colour is still relevant at this position.

*3 - Yes, in this context a TV-picture (or the Juggler player) is a static display. Its content is pre-rendered to perform the necessary colour optimization needed to circumvent HAM's limitations. A dynamic would mean that a picture is rendered on the fly, which is clearly not node.

*4 - Except, (AFAIK,) Juggler was a 24 frame loop over one second. This is not only relevant for speed considerations, but more so for space requirements.

*5 - Isn't it nice how some numbers always show up :))

*6 - See format description from the questions link

*7 - It's easy to see that most of the screen isn't changed at all.

*8 - Not to mention that 12 bit colour to HAM is not lossless.

*9 - This reduction due the use of only 4 planes instead of 6, not only reduces over all data by a third, but also compression overhead in form of unchanged pixel that get stored to improve decoding speed. So a frame shrinks to ~7 KiB

*10 - To simplify and speed up animation delta sequences for HAM mode are best restricted to 16 pixel chunks (and juggler did so), while VGA's plain video memory works at byte borders. Thus no unnecessary bytes need to be stored. As a result each run on the Amiga will on average have to transfer 16 unchanged pixel (8 on each side) in addition, while on the PC it's zero. Even if we use word transfers to optimize further, it's only 2 per run.

Since the juggler figure covers almost all screen lines, it's safe to assume close to 200 runs per frame (usually it'll be more, as there may be several runs per line). 16 pixel (12 byte) per run give 2400 bytes overhead per 10 KiB frame. On the PC this would be just 2 pixel ( 2 bytes) per run or 400 bytes total. That's almost 20% less per frame due no need to use planes (*11).

*11 - And no, it would be no good idea to store the data in a similar 'flat' format for the Amiga, as now the player would need to do a lot of bit operations on all 6 planes. Way too much to be done within a frame.

*12 - Which is even slower then the original IBM PC could do. And Word Access was further slowed down. The XT/286 introduced the same time as the AT was over all up to 20% faster due not inserting (as many) wait states.

*13 - 16 bit in combination with VGA is a delicate matter, as not only the original VGA was only 8 Bit, but also many so called 16 bit third party cards used 8 bit chipsets but added a pseudo 16 bit interface to use the faster 16 bit cycle and serialise the bytes afterwards.

*14 - In fact, I wouldn't rule out an unmodified PC to be able to display the Juggler in acceptable speed video using a 8 bit VGA.

*15 - It could even be fun to try the Sinclair QL - sure, colour is quite restricted ... still :))