3

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?

closed as primarily opinion-based by pipe, DrSheldon, Raffzahn, Brian Tompsett - 汤莱恩, wizzwizz4 Jan 1 at 13:37

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    To start with, less than a fifth of the screen needs to be redrawn at a time, next, similar memory bandwidth was available to many others - start with the ST, and I doubt as well that the full colour range was used here. – Raffzahn Dec 30 '18 at 19:46
  • 1
    But for the colour depth requirement, the SAM Coupe does a pretty good impression: youtu.be/oX3blkwNjLU?t=2 – Tommy Dec 30 '18 at 19:54
  • 2
    One other observation: based on frame stepping a version on Youtube, the original animation looks like a 24-frame cycle. So any machine that supports at least 24 video pages needn't worry about bandwidth. Actually, the Sam version looks like just 16, and Raffzahn's Atari ST link mentions that version being four frames fewer, so presumably 20. – Tommy Dec 30 '18 at 22:42
  • 1
    @Raffzahn Any faithless reproduction should be put aside for falling short of the graphics fidelity (fps, resolution, color depth). It's like when kids insist that PS4 graphics beat PS3 graphics even though adults can't see a difference. The kids are both objectively and aesthetically right, in this case. – Brian H Dec 31 '18 at 18:57
  • 2
    Can someone explain how this is opinion based and thus closed? The question he asked has an exact answer – dashnick Jan 2 at 17:50
5

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 whooping 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 niche 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 :))

  • "Thus the only advangage of HAM is a possible higher colour usage (within the defined limits)." Well, that is exactly the point - 4,096 color display in bandwidth normally used for 64 color display. – Brian H Dec 31 '18 at 21:40
  • Your characterization of HAM mode as being used only for static images is incorrect. The rather extensive library of Amiga raytrace applications that were popularized with the aid of The Amiga Juggler validate this. – Brian H Dec 31 '18 at 21:44
  • If the Atari STe (which had 4,096 color output, 16 at a time) could be programmed to do both the delta compression and also one or more 16-color palette updates per scanline, then I think it would look about as good as the Amiga output. I think the STe was 4 years removed from the Amiga. – Brian H Dec 31 '18 at 21:48
  • 2
    @BrianH Did I hit the Fanboy button? :)) Serious, the Juggler player is a static display, as the content is prerendered. There are rather few games using HAM - exactly due it's limitations of location dependant colour. Without detailed preperation it's for example impossible to just a block around the screen or even draw a simple line of arbitrary colour. Next, Bandwith-'saving' isn't worth anything on its own - it's worthless if not used. Your argument goes more around colours, but they don't get as much used as well. It's not 4096, just up to 4096 in optimal configuration. – Raffzahn Dec 31 '18 at 23:33
  • Number of colours as well does not count as much - more so if they don't get used at all - and can't be displayed independent at each and every position. Effective colour resolution can be as low as one third. Colour wise I would assume that the Juggler could as well be done in 64 colour mode with about the same data rate. That's also what Juggler is about: Data Rate for filling. Not bandwidth needed to display. – Raffzahn Dec 31 '18 at 23:40

Not the answer you're looking for? Browse other questions tagged or ask your own question.