Anyone who used an pre-Kickstart 2.0 Amiga will be very familiar with the "Insert Workbench floppy" image:

enter image description here

I realise that this is subjective, but the image has always stuck me as ... well, a bit ugly. Quite apart from the misshapen thumb and fingers, the image seems very low-res: big blocky pixels and thick angular lines. It's certainly not stretching the Amiga's legendary graphics capabilities; Kickstart 2.0 and later had a much improved boot animation.

I'm assuming the screen resolution was the standard OCS 320x200 (or 320x256 for PAL): was there a technical reason for the image being so chunky, or was it just something that didn't really matter too much at the time?

  • 15
    Space in boot prom is rather tight. That might be part of the explanation. Commented Feb 23, 2020 at 14:19
  • 12
    To be fair to it, it’s a lot more communicative than the Macintosh equivalent of an icon-sized floppy disk (32x32 maybe?) with a flashing question mark in front of it.
    – Tommy
    Commented Feb 23, 2020 at 19:32
  • 11
    I'm entirely bothered by the non-square floppy. Is that an artifact of presentation here, or did it look like that on original hardware?
    – dave
    Commented Feb 23, 2020 at 19:45
  • 18
    @another-dave On an NTSC screen it is square. Commented Feb 24, 2020 at 0:16
  • 15
    @Geo... You're assuming they even had a graphic arts department. To me this looks like hastily-drawn "programmer art". We do it all the time at most companies I've worked at, possibly expecting it to be replaced by "real art" later, but sometimes that never happens. Commented Feb 24, 2020 at 15:01

7 Answers 7


Looking at the actual code, the iconic KS1.x Workbench disk-hand image is technically drawn as vector art — except for the texts, which are bitmaps.

The machine-language code uses a simple “program” — stored in an array — to draw the different parts of the diskette, hand, and the fingers, run-time. This “DSL” implements three commands:

  1. Draw a polyline. Parameters: color index for the drawing pen and an arbitrarily long list of x,y coordinates.
  2. Flood-fill an area. Parameters: color index of the desired fill color and a single x,y coordinate for indicating where to begin filling.
  3. End the program, return.

There’s another kind of “program in an array” for drawing the bitmaps.

The code uses the SetAPen, Move, Draw, Flood, and BltTemplate calls (and some others) from graphics.library to do all this. The screen resolution is set to 320x200 (2 bitplanes; 4 colors) and the code centers the vector image by drawing it at an offset.

I assume this code and the data it uses takes less space than, say, RLE-compressing the resulting bitmap image but it is a bit hard to assess exactly.

If not, maybe the vector art approach was taken simply because it was the least tedious way to create such art it in the absence of a proper bitmap graphics editor.

I’m not sure how the A1000 drew its Kickstart disk prompt, though, if it did not have the graphics.library available during the early stages of boot. Or maybe they included a stripped-down version of the library which only had the specific calls needed for recreating this image...

The vector art data — without any code or bitmap images — takes 412 bytes:

FF 01 23 0B 3A 0B 3A 21 71 21 71 0B 7D 0B 88 16 88 5E 7F 5E 7F 38 40 38
3E 36 35 36 34 38 2D 38 2D 41 23 48 23 0B FE 02 25 45 FF 01 21 48 21 0A
7E 0A 8A 16 8A 5F 56 5F 56 64 52 6C 4E 71 4A 74 44 7D 3C 81 3C 8C 0A 8C
0A 6D 09 6D 09 51 0D 4B 14 45 15 41 19 3A 1E 37 21 36 21 36 1E 38 1A 3A
16 41 15 45 0E 4B 0A 51 0A 6C 0B 6D 0B 8B 28 8B 28 76 30 76 34 72 34 5F
32 5C 32 52 41 45 41 39 3E 37 3B 37 3E 3A 3E 41 3D 42 36 42 33 3F 2A 46
1E 4C 12 55 12 54 1E 4B 1A 4A 17 47 1A 49 1E 4A 21 48 FF 01 32 3D 34 36
3C 37 3D 3A 3D 41 36 41 32 3D FF 01 33 5C 33 52 42 45 42 39 7D 39 7D 5E
34 5E 33 5A FF 01 3C 0B 6F 0B 6F 20 3C 20 3C 0B FF 01 60 0E 6B 0E 6B 1C
60 1C 60 0E FE 03 3E 1F FF 01 62 0F 69 0F 69 1B 62 1B 62 0F FE 02 63 1A
FF 01 2F 39 32 39 32 3B 2F 3F 2F 39 FF 01 29 8B 29 77 30 77 35 72 35 69
39 6B 41 6B 41 6D 45 72 49 72 49 74 43 7D 3B 80 3B 8B 29 8B FF 01 35 5F
35 64 3A 61 35 5F FF 01 39 62 35 64 35 5F 4A 5F 40 69 3F 69 41 67 3C 62
39 62 FF 01 4E 5F 55 5F 55 64 51 6C 4E 70 49 71 46 71 43 6D 43 6A 4E 5F
FF 01 44 6A 44 6D 46 70 48 70 4C 6F 4D 6C 49 69 44 6A FF 01 36 68 3E 6A
40 67 3C 63 39 63 36 65 36 68 FF 01 7E 0B 89 16 89 5E FE 01 22 0B FE 01
3B 0B FE 01 61 0F FE 01 6A 1B FE 01 70 0F FE 01 7E 5E FE 01 4B 60 FE 01
2E 39 FF FF

Rendering algorithm:

  1. Read two bytes at a time.
  2. If both bytes are FF, end the program.
  3. If the first byte is FF and the second byte is not, start drawing a polyline with the color index given in the second byte. Treat any subsequent two bytes as x,y coordinates belonging to that polyline except if the first byte is FF (see rules 2 and 3) or FE (see rule 4), which is where you stop drawing the line.
  4. If the first byte is FE, flood fill an area using the color index given in the second byte, starting from the point whose coordinates are given in the next two bytes.

The palette is:

    0: #fff 
    1: #000
    2: #77c
    3: #bbb

The offsets used for drawing the image centered are X=70, Y=40.


@v-joe adds some interesting points:

The research in his comments to this answer indicates the vector art approach saves about 3 kilobytes compared to run-length encoding the resulting bitmap. This is significant win if you’re tight on space.

Also, his answer quotes the original artist, Sheryl Knowles, as saying she only had the most primitive means of producing graphics at her disposal at the time of designing this image. Sheryl also mentions storage space-related limitations: “[t]he drawing was limited in size and in the number of pixels that could be used”.

Given this image is mostly composed of vector polylines, instead of an array of pixels, maybe Knowles did not mean pixels, per se, but the x,y coordinate points in those polylines? That she had been specifically told not to use too many of those could explain the “angular” aspects of the image. It also tells us storage space really was a concern during the design process.

That all said — and getting back to the original question — it is likely the resulting image still could be edited to look a bit more polished by fine-tuning and tweaking the placement of the polyline vertices while keeping the total number of them the same. But this is easy for us to say now that we have modern vector art tools like Inkscape and Adobe Illustrator at our disposal. Knowles’s recollection of the design process seems to indicate she did not have a tool at hand that would have allowed her to do any advanced editing once the coordinate points had already been laid down.

  • Very interesting, and certainly explains the "angular" look of the image. I wonder what the size comparison between a simple compressed bitmap and the vector approach is, and whether even the overhead (CPU or size of code required) for compression was a factor?
    – KenD
    Commented Feb 26, 2020 at 16:49
  • 4
    Curiously, the vector data included in the above answer seems to appear in Kickstart 1.2, but from a quick look with a hex editor, I cannot find it in Kickstart 1.1, Kickstart 1.0, or in the A1000 Bootstrap ROM — at least not in this format. So I’m not sure how those ROMs store the same image.
    – Jukka Aho
    Commented Feb 26, 2020 at 21:48
  • 4
    Encoding the insert workbench screen as a 2-bit 320x200 IFF-ILBM image with run-length-encoding compression, the size of the BODY chunk (i.e. only the compressed image data without palette information etc.) is 4276 bytes. If one didn't encode the whole 320x200 bit planes directly this way, but rather only the pixels encompassing the disk and apply the X=70,Y=40 offset, one could save a few bytes (max. encoded run-length limited to single byte in IFFs). One could only save a couple of hundred bytes this way, meaning that the kickstart linedraw/floodfill method saves significant amounts of ROM.
    – v-joe
    Commented Feb 27, 2020 at 21:59
  • 4
    @KenD Only storing the 130x131 bitplane area covering the depiction of hand+disk and not storing the pixelated characters in an RLE-compressed 2-bit IFF ILBM chunk takes up 3384 bytes. The Kickstart logo implementation with line draw and flood fill (unlike RLE also taking advantage of pixel repetition in vertical direction) thus reduces the ROM storage requirements by almost 3 kilobytes.
    – v-joe
    Commented Feb 27, 2020 at 22:15
  • 1
    Just for fun I wrote a quick renderer for that block of bytes. I didn't implement flood filling (because I jumped too quickly at my choice of vector drawing library), but it does work! codepen.io/Fortyseven/pen/rNWZpJb?editors=0010 Commented Mar 6, 2021 at 21:51

The limitation is based on saving precious space on the 8 KiB boot ROM for the Amiga 1000.

Before the "Insert Workbench" graphic ever graced an original Amiga 1000 from 1985, a user would first have to get past the "Insert Kickstart" screen.

enter image description here

Since the original Amiga 1000 lacked any Kickstart in ROM, this initial image had to be stored in the very limited boot code that was in ROM. This was only 8 KiB, so there was not a lot of space for a large, multi-colored bitmap to be included. Likewise, creating a more sophisticated graphic using drawing primitives would have required a great deal of code space. Likely, the engineers determined that a simple low-res image using 4 colors was most appropriate.

Of course, once Kickstart is loaded, there is potentially more space to set aside for a better graphic, and also a graphics library API that provides drawing primitives that could be used to code a nicer looking display. However, the engineers kept the simple graphic from the Amiga 1000's small boot ROM until the release of the Kickstart 2.0 ROM. This is when the ROM size doubled from 256 KiB to 512 KiB. Most likely, this freed the engineers to dedicate a little more space to making a better graphic, even including a simple animation.

  • 7
    It also makes sense from a UI perspective to use the same basic graphics twice, doesn't it?
    – Raffzahn
    Commented Feb 23, 2020 at 16:26
  • 6
    Yes. It would be "jarring" to use a different graphic to represent the same meaning on the next disk insertion. However, that reason goes away with the first release of ROM Kickstart in 1986.
    – Brian H
    Commented Feb 23, 2020 at 18:05
  • Wasn't Kickstart written in a hurry too? Seems like I read that somewhere...
    – T.E.D.
    Commented Feb 24, 2020 at 16:48
  • 7
    @T.E.D. Most everything related to the Amiga launch was rushed after Commodore acquired it, including all the software, and especially AmigaDOS. AmigaDOS was done by outside firm MetaComCo in the UK, and most of it resides on the Workbench disk, not in Kickstart. Still, Kickstart and Workbench were quite buggy at release and really only stable and feature-complete at v1.2.
    – Brian H
    Commented Feb 24, 2020 at 17:12
  • Quite buggy, perhaps. But I bought my Amiga shortly after taking only ten minutes to crash the first Macintosh three times.
    – WGroleau
    Commented Feb 25, 2020 at 21:41

Low number of bit planes (few colors) and low resolution saves kickstart ROM space as stated in the other answer(s). Another reason for the simplicity of the picture could be the limitation of available drawing tools when the kickstart logo was created. Considering the following to really be a post by the original artist Sheryl Knowles, creation of such an image was basically done on paper and the pixels had to be hardcoded by the programmers (i.e. there might have been "pixel counting" on graph paper involved): Post by Sheryl Knowles at eab.abime.net

One: there was no art tool on the Amiga before Graphicraft. We did every single illustration in the manuals, every "show it off" illustration that appeared in magazines or trade shows, and every practical graphic (i.e. the icons and fonts), pixel by pixel, with no tools other than being able to choose a color and place the pixel. No line tools. No fills. No shape tools. Two: We had no way to save our art work. So once designed, it had to go straight to the programmers to be coded in. I used a LOT of graph paper. Or, if it was an illustration, we had to photograph our screens and send that photo to the publisher needing it. Believe me, once Graphicraft was done, our jobs were so very much easier!

The boot disk that is the main topic of this thread was drawn by me holding it in my left hand and laying down the pixels with my mouse using my right hand. I am right handed. It was not intended to be a literal illustration of the disk or how to use it. It was simply an icon to represent the need to use a disk. The drawing was limited in size and in the number of pixels that could be used, by the programming requirements of the time. All of which should explain why it's a bad drawing. But it was deemed a sufficient icon.


I'm assuming the screen resolution was the standard OCS 320x200 (or 320x256 for PAL): was there a technical reason for the image being so chunky,

Chunky? Well, it's as usual in the eye of the beholder.

But lets look at some issues:

Any picture chosen

  • should be usable in all screen modes, as it's unknown what mode the machine has to come up
    • With more than 200x200px (IIRC), it's already close to maximum size
  • should not occupy more ROM than available
    • 4 colours and acceptable size does so
  • should only use few colours for low colour modes
    • 4 is good for anything past pure B&W
  • can only use few colours to work well on bad aligned and (grayscale) B&W screens
  • needs to use strong contrast to be visible such
  • may only use colours that translate well into (grayscale) B&W
  • should have colours that translates into pure B&W as well
    • here selected blue can be turned into black and grey into white without damaging the image's message.

or was it just something that didn't really matter too much at the time?

Keep in mind, even a high resolution Amiga picture would fit in the upper left corner of your screen, maybe 1/10th the size of the standard Full-HD of today.

We often tend to see back then graphics with today's standards. While it usually is of no harm, it hinders us often to see the real advancements certain things were.

Back then it was seen as a fine and highly detailed graphics symbol.

For judging its true impact, one need to compare it to the generation before. Like a C64. Here such a high resolution picture would need many tricks to be displayed in the same quality - if possible at all. So for 1985 this was state of the art and quite appealing.

There is BTW a nice story about it being basically wrong: The story of the Amiga Kickstart image.


It does the job it’s supoosed to do - it tells the user to insert a disk, and it does so without being language specific.

I always thought this was a rather clever and effective UI element.


Thanks for the info in this thread. I've wrote a program to draw it on an Amiga in AMOS. Here is a video of it being drawn slowly: Amiga Kickstart Hand

  • Is that program a step-by-step reconstruction of what the boot code does, or does it "merely" get the same result? Commented May 17, 2020 at 10:01
  • 1
    It just uses the rules mentioned on this page and the Hex values from the KS1.2 ROM to do the same thing. Commented May 17, 2020 at 14:36

It's actually pretty good for the time. The Amiga logo is anti aliased, almost certainly by hand. The hand itself is fairly detailed. Detail makes it harder to compress into the very limited ROM space available.

Compared to contemporary systems it wouldn't have looked bad. In fact not booting to a CLI but instead a graphic was quite novel.

Compare it with the Mac, a later machine, that just had a tiny 8x8 black and white disk icon.

  • 2
    Having made a throwaway comment about it earlier, I checked. The Mac image is 32x32: i2.wp.com/lowendmac.com/wp-content/uploads/question_mark.png . It’s also an earlier machine, not a later one.
    – Tommy
    Commented Feb 24, 2020 at 13:33
  • The Amiga logo is anti-aliased? Are you sure you're not seing CRT emulation (or CRT effects)? Commented May 17, 2020 at 12:20
  • @MichaelGraf if you zoom in on it you can see that there are shades of grey used in an attempt to hand anti-alias it. That was common at the time.
    – user
    Commented May 17, 2020 at 15:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .