Previously Unknown Warhol Works Discovered on Floppy Disks from 1985 (2014)(studioforcreativeinquiry.org)
studioforcreativeinquiry.org
Previously Unknown Warhol Works Discovered on Floppy Disks from 1985 (2014)
http://studioforcreativeinquiry.org/events/warhol-discovery
73 comments
I've got a few Amigas and my 6 year old son loves messing about in Deluxe Paint. Some of his creations are starting to approach Warhol's level... I think...
The PDF report gives some fascinating technical detail, linked in the article and at http://studioforcreativeinquiry.org/public/warhol_amiga_repo...
This is silly: lots of Amiga computers are still around, the Amiga community knew about these images for years. They didn't do due diligence and studied previous/related/existing works.
The artist who "rediscovered" them is a notorious self-promoter.
Ahh so I have seen them before. I thought I had.
Part of CMOA's wonderful Invisible Photo doc:
http://www.nowseethis.org/invisiblephoto
Amiga games are so important to the history of game development and design. Could the brand could be resurrected if willing investors were to arise?
Amiga Documents:
https://sites.google.com/site/amigadocuments/
http://www.nowseethis.org/invisiblephoto
Amiga games are so important to the history of game development and design. Could the brand could be resurrected if willing investors were to arise?
Amiga Documents:
https://sites.google.com/site/amigadocuments/
Here's a direct link to Part 2 on Vimeo, featuring the Warhol story: https://vimeo.com/92583299
I wish they'd just release the raw disk images themselves. It's said Warhol used a prototype Amiga, and thus a prototype version of pre-1.0 Kickstart (earlier than rev 27.5, which is publicly floating around and which has no Workbench).
Previous discussion: https://news.ycombinator.com/item?id=7638904
I wonder what the "plan for reading the disks with a cart of exotic gear" actually entailed...
So where is my sceptical top hacker news comment saying something negative about theese images?
I define myself as a former Amiga owner. That computer was so defining and the community so strong sad that Jack Tramiel went out to kill the Amiga with the Atari ST. These Andy Warhol pictures were a claim to fame for many Amiga owners and it was awesome to know that they were found right next to the bouncing red and white ball.
It must have taken around 6 or 7 years for the Macintosh and "IBM PC" computers to catch up. The graphic art capacity was head and shoulders about anything else outside of Silicone Graphics. Not to mention that VIM was developed on the Amiga.
I had a audio port so I could record through RCA cables and remix things. My church had the Video Toaster which was in use from 1987 to 2004. This actually led to me doing a lot of audio and video work that I still do today.
In the future I think the hardware architecture will resemble more of the Amiga as we hit the limits of computer chips. There will be more dedicated chips and cores for more specific things.
It must have taken around 6 or 7 years for the Macintosh and "IBM PC" computers to catch up. The graphic art capacity was head and shoulders about anything else outside of Silicone Graphics. Not to mention that VIM was developed on the Amiga.
I had a audio port so I could record through RCA cables and remix things. My church had the Video Toaster which was in use from 1987 to 2004. This actually led to me doing a lot of audio and video work that I still do today.
In the future I think the hardware architecture will resemble more of the Amiga as we hit the limits of computer chips. There will be more dedicated chips and cores for more specific things.
We've already seen the resurgence of heterogenous computing on the iPhone. The SoC inside offloads video and voice processing to dedicated ASICs. When you call these functions on the API, they run on the ASIC, not on the main CPU.
Video processing has been offloaded in PCs for a long time; the first "3D accelerators" were in the late 90s.
Perhaps I meant to say image processing. The ability to point the camera at something and make sense of the picture (FaceID, AR).
> the first "3D accelerators" were in the late 90s.
You forgot about SGI and I'm sure a few others like Intergraph who were doing dedicated 3D video pipelines in hardware starting in the in the 80's.
Actually the Amiga had a GPU for 2D graphics. You need a Amiga desktop model and not a A500. The graphics shop down the road had a dozen Amigas with these cards for rendering and even ray tracing. They were pretty amazing. Even Disney used them for Beauty and the Beast and other animation at the time.
http://www.amigareport.com/ar216/p1-7.html
http://www.amigareport.com/ar216/p1-7.html
really? Pretty sure OCS was the same in all Amigas
Back in the 80s there was a co-processor known as 8087 and it was a different beast than 8086/8088.
I had a computer with two different CPUs 6502 and Z80 that could actually ran them in parallel.
There is nothing new about the ability to have some functionality offloaded to another processing unit regardless of the architecture.
I had a computer with two different CPUs 6502 and Z80 that could actually ran them in parallel.
There is nothing new about the ability to have some functionality offloaded to another processing unit regardless of the architecture.
The 8087 was the floating point co-processor or FPU for the 8086. It was not a separate CPU.
The blitter, raster, and audio coprocessors on the Amiga weren't Turing complete general purpose CPUs either.
The 8087 FPU was not offloading the CPU as the CPU was halted after the FPU caught a FP instruction and made a DMA call to the CPU and took control of the bus to access what memory it had to. They were a tag-team if you will; jumping in and out of the ring to deal with their respective instructions.
Halted?
You had an option to WAIT for 8087 but you could 'cheat' and just run other instructions, manually calculating cycles.
Thus, a system with an 8087 was capable of true parallel processing, performing one operation in the integer ALU of the main CPU while at the same time performing a floating-point operation in the 8087 coprocessor. Since the 8086 or 8088 exclusively controlled the instruction flow and timing and had no direct access to the internal status of the 8087, and because the 8087 could execute only one instruction at a time, programs for the combined 8086/8087 or 8088/8087 system had to ensure that the 8087 had time to complete the last instruction issued to it before it was issued another one.
https://en.wikipedia.org/wiki/Intel_8087#Design_and_developm...
Thus, a system with an 8087 was capable of true parallel processing, performing one operation in the integer ALU of the main CPU while at the same time performing a floating-point operation in the 8087 coprocessor. Since the 8086 or 8088 exclusively controlled the instruction flow and timing and had no direct access to the internal status of the 8087, and because the 8087 could execute only one instruction at a time, programs for the combined 8086/8087 or 8088/8087 system had to ensure that the 8087 had time to complete the last instruction issued to it before it was issued another one.
https://en.wikipedia.org/wiki/Intel_8087#Design_and_developm...
I believe Agnus(?) and the CPU had to wait on each other for the memory bus - as evidenced by the CPU getting slower when the screen resolution was increased, due to the greater amount of video memory being read per frame.
The first college I went to wouldn't let me in as a CompSci major because that program was full. But it had a TV station with an Amiga and Video Toaster that nobody knew how to use, so I was enrolled in the journalism school so I could run it for them.
I'm not sure. Heterogeneous architectures were a huge mess with the PS3, for a recent example, and abandoned in the subsequent PS4 for relatively standard x86 kit. Taking advantage of specialized hardware is not without its costs.
As someone who went through that era and worked on a cross-platform title.
The issue wasn't that the PS3 was heterogeneous, it was that the X360 came first so everyone wrote for a system that had relaxed memory constraints. When the PS3 came along all of a sudden things that weren't vectorized didn't run slow, they just flat out didn't run at all.
Fun fact, the few engines that were developed for the PS3 first and X360 second ran circles around everyone else because all the vectorization work for PS3 meant they fit in caches really nicely and had zero cache misses. Easily 2-4x faster than titles doing equivalent work.
The issue wasn't that the PS3 was heterogeneous, it was that the X360 came first so everyone wrote for a system that had relaxed memory constraints. When the PS3 came along all of a sudden things that weren't vectorized didn't run slow, they just flat out didn't run at all.
Fun fact, the few engines that were developed for the PS3 first and X360 second ran circles around everyone else because all the vectorization work for PS3 meant they fit in caches really nicely and had zero cache misses. Easily 2-4x faster than titles doing equivalent work.
It depends on the API implementation, really. The criticism back in the day was that Cell was difficult to program for. I would imagine this was because its functions were at a lower level, which buys you power at increased development cost. Think the difference between Vulkan and OpenGL. Sony didn't seem to value development value over capability, which led to the PS3 earning the reputation of being an underutilised console: https://www.cnet.com/news/sony-ps3-is-hard-to-develop-for-on...
Apple's heterogenous computing functions on iOS are higher-level and much easier to use. Instead of manually writing code to do FaceID on iOS, possibly involving graduate-degree levels of theory, you simply create a biometry type which abstracts much of the details, many of which developers aren't particularly interested in fine-tuning. This is how someone on a budget like Bank XYZ can use FaceID to unlock your bank app.
Apple's heterogenous computing functions on iOS are higher-level and much easier to use. Instead of manually writing code to do FaceID on iOS, possibly involving graduate-degree levels of theory, you simply create a biometry type which abstracts much of the details, many of which developers aren't particularly interested in fine-tuning. This is how someone on a budget like Bank XYZ can use FaceID to unlock your bank app.
Another angle worth considering is the economics of porting titles. If you take full advantage of specialized hardware like the PS3 had, it could have a strong influence on the implementation of games- possibly even pushing down to choices in aesthetics and game mechanics. As a result it may be very difficult to get a comparable experience on another console.
If a game is designed and written to more-or-less cater to a common denominator it is more straightforward to later port the game to other consoles or PCs- including platforms that might not exist at the time the original game was created- and mop up sales from those other userbases.
If a game is designed and written to more-or-less cater to a common denominator it is more straightforward to later port the game to other consoles or PCs- including platforms that might not exist at the time the original game was created- and mop up sales from those other userbases.
I'm not sure I agree. It was much easier to develop your game around the PS3's heterogeneous architecture, then port it to a more conventional architecture like the Xbox 360 or PC and get good performance than doing it the other way around.
In very broad strokes, compared to the other consoles of its generation, the PS3 offered a large compute capacity via SPEs and was starved for RAM and memory bandwidth. I think you're conflating the technical impact of a heterogenous architecture with other differences in specs.
If you tailored a game to work within the memory footprint of a PS3 and did not take advantage of SPEs, a port is easy- you've aimed at a lowest common denominator. If you designed your game with the expectation that you'd have more RAM, you'll have to make some painful decisions to cut the game down to size. If you designed your game to actually take advantage of SPEs, there wouldn't necessarily be a comparable compute resource on the platform to which you would like to port.
If you tailored a game to work within the memory footprint of a PS3 and did not take advantage of SPEs, a port is easy- you've aimed at a lowest common denominator. If you designed your game with the expectation that you'd have more RAM, you'll have to make some painful decisions to cut the game down to size. If you designed your game to actually take advantage of SPEs, there wouldn't necessarily be a comparable compute resource on the platform to which you would like to port.
Just a small nit that the PS3 and X360 had the same amount of RAM, it was just split on the PS3. X360 had a unified memory model which was a lot easier(PS3's is closer to a PC and X360 your mobile phone).
We still did clever things like putting music in GPU memory and then streaming it back to system memory since the bandwidth wasn't large and read patterns were very predictable.
We still did clever things like putting music in GPU memory and then streaming it back to system memory since the bandwidth wasn't large and read patterns were very predictable.
Yup, and when you did that you got a huge perf-bump on non-PS3 platforms since you already had things built in a way that were memory-locality friendly.
Jay Miner - Creator of Amiga's API
http://www.geekometry.com/2015/01/gamechangers-jay-miner-and...
Amiga had the best API. Even as a kid I could understand what I was doing with it.
http://www.geekometry.com/2015/01/gamechangers-jay-miner-and...
Amiga had the best API. Even as a kid I could understand what I was doing with it.
Well, not really: the PS4 still has a GPU, so it has two kinds of computing units where the PS3 had three. The SPUs existed mostly because the same number of full-blown cores would have been prohibitively expensive back then.
I specifically said it would look more like. Of course we have GPU and other chips but we are going to have much more than we have now to get an increase in computer power.
The BIG issue will be programming to utilize these architecture and we haven't really hit anything yet that we see a HUGE increase when we have multiple of cpu cores let alone other components. The big issue will be API.
The BIG issue will be programming to utilize these architecture and we haven't really hit anything yet that we see a HUGE increase when we have multiple of cpu cores let alone other components. The big issue will be API.
Any modern PC is heterogeneous. Not just the GPU, but even full CPUs. Most harddrives have full CPUs driving the HD controller, for example (e.g. you'll find multicore ARM's on many of them).
>Reviewing the disks’ directory listings, the team’s initial excitement on seeing promising filenames like “campbells.pic” and “marilyn1.pic” quickly turned to dismay, when it emerged that the files were stored in a completely unknown file format,
I wonder what format it was...
I wonder what format it was...
Most likely Graphicraft, which was the paint program he used during the Amiga launch.
I found it quite amusing that they describe it as a "completely unknown file format" - it have taken them minutes to identify the paint program used if they actually read any of a number of accounts of the launch prep.
It's described on page 284 onwards of Commodore: The Amiga Years (Brian Bagnall), and many other places. (EDIT2: Note that specific book was not published when the article was written, but a very similar account is present in an older book by the same author - Commodore: The Amiga Years is the second volume of what started as a second edition of his previous account of Commodore)
EDIT: "Graphicraft" is even present in the images in the article..."
I found it quite amusing that they describe it as a "completely unknown file format" - it have taken them minutes to identify the paint program used if they actually read any of a number of accounts of the launch prep.
It's described on page 284 onwards of Commodore: The Amiga Years (Brian Bagnall), and many other places. (EDIT2: Note that specific book was not published when the article was written, but a very similar account is present in an older book by the same author - Commodore: The Amiga Years is the second volume of what started as a second edition of his previous account of Commodore)
EDIT: "Graphicraft" is even present in the images in the article..."
The linked PDF is a better read: http://studioforcreativeinquiry.org/public/warhol_amiga_repo...
They mention Graphicraft was unable to load the images unless booted with a particular Kickstart version.
They mention Graphicraft was unable to load the images unless booted with a particular Kickstart version.
So interestingly that shows the Venus was IFF ILBM, which matches its origin as a demo image for Deluxe Paint rather than GraphiCraft.
The format for most of the others is described as "PLBM", which makes sense as P(L)BM is basically a cruder variation that'd allow dumping the screen/window content to the disc in planar format directly (native for all Amiga on-screen display prior to AGA or graphics cards) with minimal framing, while ILBM interleaves the bitplanes row by row (and can optionally use run-length encoding too), and so needs a bit more finesse.
It's kinda funny how they play up that the person who found this out "specializes in and is world-renowned for hacking and reverse engineering" - if you're remotely familiar with image file formats, it takes about 5 seconds of looking at these files in a hex editor to see that they're an IFF related format, and the chunk names are plain ASCII. I'm sure the person in smart - I'm not disputing that; but they're overplaying how much expertise is required for this.
Both ILBM and P(L)BM are formats you can write a basic decoder for in an hour or two - IFF contains chunk headers and length markers to let you extract each chunk, and you need the palette information and the bitplanes. ILBM also allows for basic run-length encoding. There's no complicated compression or anything else to make it hard.
The format for most of the others is described as "PLBM", which makes sense as P(L)BM is basically a cruder variation that'd allow dumping the screen/window content to the disc in planar format directly (native for all Amiga on-screen display prior to AGA or graphics cards) with minimal framing, while ILBM interleaves the bitplanes row by row (and can optionally use run-length encoding too), and so needs a bit more finesse.
It's kinda funny how they play up that the person who found this out "specializes in and is world-renowned for hacking and reverse engineering" - if you're remotely familiar with image file formats, it takes about 5 seconds of looking at these files in a hex editor to see that they're an IFF related format, and the chunk names are plain ASCII. I'm sure the person in smart - I'm not disputing that; but they're overplaying how much expertise is required for this.
Both ILBM and P(L)BM are formats you can write a basic decoder for in an hour or two - IFF contains chunk headers and length markers to let you extract each chunk, and you need the palette information and the bitplanes. ILBM also allows for basic run-length encoding. There's no complicated compression or anything else to make it hard.
How is that possible?
The version of GraphiCraft used for the demo was not a finished version, and was known to be buggy. Recollections of people involved includes claims that they were terrified when Warhol used the flood fill, for example, because there was a known bug in flood fill that would cause it to fill memory outside the screen bitmap. So it's quite likely that there other bugs too.
As a wild guess, one possible source of problems might be that GraphiCraft might have taken shortcuts in saving that might have e.g. assumed a certain offset into some data structure to copy the palette information from the file to that changed before release, as some of these early programs were known to basically pretty much dump memory straight to file and load it back in straight into some data structure with minimal parsing and validation.
As a wild guess, one possible source of problems might be that GraphiCraft might have taken shortcuts in saving that might have e.g. assumed a certain offset into some data structure to copy the palette information from the file to that changed before release, as some of these early programs were known to basically pretty much dump memory straight to file and load it back in straight into some data structure with minimal parsing and validation.
> EDIT: "Graphicraft" is even present in the images in the article..."
But how did they know that before they were able to view the images?
But how did they know that before they were able to view the images?
They wouldn't know that - I meant that as confirmation that it was in fact GraphiCraft that was used. They would however know it was GraphiCraft if they read up on the event in advance.
I wonder how much reverse engineering they actually did before using Graphicraft. Or it could be a embellishing by the author of the piece.
They don't really say very much. The Venus bitmap was a demo picture that shipped with Deluxe Paint (and the one they've published seems to be blank where the header/toolbox would be), and although they credited it to Warhol it doesn't appear he's done much than cut/paste a third eye in.
If these were system disks from a prototype Amiga, then it makes sense that these pictures came from an early version of Deluxe Paint, and that .pic was some intermediate / temporary / memory-dump type format before they adopted the .iff system.
Given the Amiga was quite different display-wise, a description of the file format would probably be quite instructive in terms of whether it was an Amiga-native data structure or something already existent somehow.
If these were system disks from a prototype Amiga, then it makes sense that these pictures came from an early version of Deluxe Paint, and that .pic was some intermediate / temporary / memory-dump type format before they adopted the .iff system.
Given the Amiga was quite different display-wise, a description of the file format would probably be quite instructive in terms of whether it was an Amiga-native data structure or something already existent somehow.
Minor Nit: IFF was released in Jan 85 [0], a few months before Amiga was released and several Amiga guys, including RJ, contributed to the spec. It was baked into the Amiga from the very start.
So Commodore's Graphicraft was probably always using ILBM IFF, maybe with new and pre-release chunk types. :)
I'd be very surprised if they weren't alpha IFF or some such. I'd love to see a hex dump of the start of a file.
[0] http://static.lightwave3d.com/sdk/11-6/html/filefmts/eaiff85...
So Commodore's Graphicraft was probably always using ILBM IFF, maybe with new and pre-release chunk types. :)
I'd be very surprised if they weren't alpha IFF or some such. I'd love to see a hex dump of the start of a file.
[0] http://static.lightwave3d.com/sdk/11-6/html/filefmts/eaiff85...
"IFF" doesn't say all that much, of course, as it's just very basic framing. It's the chunk types that matters.. It does seem the images were in fact PLBM, so very similar to ILBM but "raw" bitplanes instead of interleaving row by row.
It's pretty much a memory dump of the window/screen bitmaps with a bit of extra data in front.
It's pretty much a memory dump of the window/screen bitmaps with a bit of extra data in front.
He used GraphiCraft for the demo, but of course it's possible he at some point later used DPaint. I do believe the reason GraphiCraft is present in the images, though, is because GraphiCraft early on did in fact use pretty much a memory dump. Several of the early graphics programs in fact didn't store a separate full copy of the bitmaps, but let you draw directly into an window on the screen, and relied on AmigaOS to preserve any sections temporarily covered by other windows.
But DPaint at least let you paint under the title bar.
Later versions of GraphiCraft did use IFF, as Commodore wholly embraced the format once EA released it.
But DPaint at least let you paint under the title bar.
Later versions of GraphiCraft did use IFF, as Commodore wholly embraced the format once EA released it.
[deleted]
> it doesn't appear he's done much than cut/paste a third eye in.
To be fair, that third eye changes the picture in a very significant way, in artistic terms. Art is not about quantity of effort.
To be fair, that third eye changes the picture in a very significant way, in artistic terms. Art is not about quantity of effort.
The original Amiga Venus image was created by Avril Harrison (The AH in the lower left corner. She did a lot of awesome work for LucasArts, too.)
http://amiga.lychesis.net/artist/AvrilHarrison/AH_Venus.html
http://amiga.lychesis.net/artist/AvrilHarrison/AH_Venus.html
I'm guessing it was either a raw binary dump, or the old (even then obsolete) IFF PLBM format, which preceded the well-known IFF ILBM format. PLBM files were found on the famous EA Kaleidoscope demo disk.
The Venus image was one of the ones bundled with Deluxe Paint, Just seems he's duplicated the eye. Feels we might be attributing a mistake as a conscious piece of art.
Worhol's style was perfect for these early paint programs, since they were so rudimentary (by modern standards).
Had Amiga employed random interns to do the same thing, people would have gotten the impression that it was a silly child's toy. But Andy Worhol's doodles "immensely alter the composition and complexity of the source image".
Had Amiga employed random interns to do the same thing, people would have gotten the impression that it was a silly child's toy. But Andy Worhol's doodles "immensely alter the composition and complexity of the source image".
So it's a remix. What was that about good artists steal?
It's a remix with a single cut and paste.
This is an artist who signed soup cans. I'm sure he'd tell you something like there is no difference between accident and art when done by an artist.
This is one way to view artist - not as a craftman, but as a brand like Walt Disney (or Merceded Benz). The artist then functions as a curator for all the data that passes through him and signs those articles he considers worthy of the brand. This is a totally fine way to look at it - just as long as he/she does not tread on someones copyright.
> not as a craftman, but as a brand
That's reductionist. Warhol's craft was in recognising and willfully exploiting brand culture. He described the celebrity culture we now live with, and made a job out of being the one who understood how it worked. He wasn't just signing "worthy" stuff; he was showing people how the mechanisms of brand-building and celebrity culture actually work: by repetition and labelling/signing/appropriating. He branded the brands like brands branded the world, and he did it over and over with minor variations, exactly like they do.
He was not without his flaws, but he wasn't just some sort of "gatekeeper of cool". He obviously didn't think an artist exists to validate this or that brand; the validation was a side-effect of his artistic craft. This is why trying to "play Warhol" today, using different brands or imagery, is just stupid, in artistic terms: he's done it already, it's all there already and there is nothing else to say on that particular subject.
That's reductionist. Warhol's craft was in recognising and willfully exploiting brand culture. He described the celebrity culture we now live with, and made a job out of being the one who understood how it worked. He wasn't just signing "worthy" stuff; he was showing people how the mechanisms of brand-building and celebrity culture actually work: by repetition and labelling/signing/appropriating. He branded the brands like brands branded the world, and he did it over and over with minor variations, exactly like they do.
He was not without his flaws, but he wasn't just some sort of "gatekeeper of cool". He obviously didn't think an artist exists to validate this or that brand; the validation was a side-effect of his artistic craft. This is why trying to "play Warhol" today, using different brands or imagery, is just stupid, in artistic terms: he's done it already, it's all there already and there is nothing else to say on that particular subject.
Many years ago I got to see a Warhol retrospective at MoMA, and seeing the early works in person was a revelation. My own tastes leaned more toward the "traditional" abstract expressionists and I thought Warhol was too "surface" and not interesting or deep. But seeing them on walls, they're wonderful - playful, vibrant, visually striking. The later work tapers off imo - from some accounts that I've read, the decline happened after he was shot.
Really crazy. The first one gives off a strong vaporwave vibe. Really weird how that works out.
Art made in 1985 looks like art made today that is made to look like it was made in 1985 - shocking.
It's 1985, so that's not weird at all.