RC2019-10 - The Globbing Of The Projects... Globjects?

Hey.  Long time no post.  How y'all doing?  I'm still here. I've gotten a lot of small things done over the past half year, and a lot of things almost done as well... and some long-standing projects not done too.  So, I've been almost productive...  Anyway, I hope to try something different this month for the RetroChallenge RC2019-10...  Let me explain...

The main projects I've been trying to work on recently are:

LL530 USB interface for Amiga serial keyboards and controllers

I've been poking at it a little over time, and am really damn close to getting the proper firmware done for it, but I just haven't finished it.  Which is stupid because I can actually sell these things once I'm ready!  I have keyboard working for all but my A1000 keyboards, and I have joystick/mouse/paddle working... but not at the same time in a way that I'd be proud of.  I also will eventually need to rev the board to fix three layout issues; a power/ground short, lack of ICSP programming header, and lack of pull-up resistor for VCS paddle sampling.

Llichen-80 Computer (LL80)

Okay, so it's not really a whole other completely new computer... but it is a specific configuration of the RC2014 Z80 computer.  It started out this year as a whole lot of customizations to standard (but old, obsoleted) RC2014 boards to add bank switching, using the 8 bit parallel IO board (the one with all the LEDs and switches!).   Now, I reworked the idea so that I just use the standard "Switching ROM" board and the "64k RAM" board.  That simplifies the design; making it easier to get to the LL80 spec, since just using those two cards replaces two RAM boards, one ROM board, and one IO board... plus no modifications to any of the boards are necessary.

The other part of the LL80 computer is the "LLSuper" board.  This is an arduino-based supervisor of sorts that sits on the serial console port.  It acts as your usb-serial interface for when you use a desktop computer as a console.  This board used a CH376S USB Drive interface to access any flash drive as mass storage (it's a neat part.. like $2 for a board with a USB A port... it talks TTLRS232, SPI or parallel, and handles all of the disk switching, FAT filesystem etc. So there's very little overhead on a tiny ATmega micro.  I also have an I2C based clock chip board for this.  This sits between your console and the RC, and lets you have a kind of shell access to the disk from the console, as well as from the RC.  The RC side of things also got direct access to virtual disk image files with a sector-based interface, as well as direct fileio...

The next steps would have been to write a CPM BIOS and make the thing boot into that.

But I've come to realize that even the LLSuper board is unnecessary.  I can accomplish near-similar things using the standard  "Pi Serial Console" board.  If i use a RasPi Zero, and boot linux on it (or adapt the code in the PiGFX kernel, I can put in my serial-disk IO stuff, for cheaper, without needing to fab up my own board.  I started to mess around with this using my new RC2014 Micro, a Pi Zero, and a slight hack to attach the reset line of the RC to a GPIO of the Pi, so i can now reset the RC from the Pi.

I do have the protocol all worked out for the serial interface using unused ANSI escape codes, which are made for custom purposes like this.

A102 - Portable Emulated Amiga in a Tandy 102 shell

This is one i've wanted to work on since last year. I was trying to get it done before Rochester MakerFaire last November, but burned out on it.  It essentially is a project that joins together a bunch of parts... all of which I have:

• Raspberry Pi 3, with Amibian... booting right into an emulated Amiga environment
• Tandy 102 shell, rescued from some unrepairable 102's
• Tandy 102 keyboard, also rescued (keys bind as they're pressed though)
• Amiga 500 keyboard interface board, from a long-gone computer
• My LL530 USB serial keyboard interface board
• Amiga mouse
• 3.5" composite LCD panel (new, $10 online!)
• large Power Bank battery pack

This project entailed hacking the keyboard (removing the wiring/traces on the board) to convert the scan matrix to match an Amiga 500 keyboard.  This gets connected to the LL530, which is plugged into the Pi.  All of it gets jammed into the 102 shell, and becomes a portable computer. 

I waffled a bit on this... mainly because the keyboard stuff would be a chore.  I want to remove every key, and clean their travel tubes, to eliminate the keys binding.  Wiping out the traces and rewiring the board seems like it's going to be a tedious process... So i kept thinking that maybe I should make a cherry-mx switch based board to fit the keyboard space instead... and... yeah... i just kept going down that same path of "maybe i should do this other thing" instead... instead of actually moving forward on any of it.

I also pondered putting the entire Llichen 80 computer into this shell... which brings us to...

RC2019-10!

So that's where RC2019-10 comes in.  Why almost fail at three projects when I can almost fail at ONE project! Seems a lot more efficient!

The end result for this month will be to have a working portable laptop computer that runs Amibian (Linux), RC2014 (via serial connection to the Pi) and general Linuxy stuff.

Or, more granularly, here are the tasks as I see them now: (in no particular order)

• Finish the Keyboard + Joystick/Mouse firmware for the LL530
• remove the wires on the 102 keyboard PCB
• clean the travel tubes on the keyboard
• rewire the keyboard to match the Amiga's matrix
• Wire the keyboard to the Amiga 500 interface board
• Connect the RC2014 Micro via the Pi's serial interface pins
• Additional buttons on the device to cleanly shut it all down
• Have it all powered from a 5V/USB powerbank mounted internally
• Serial-console textmode app for Linux that provides the beginnings of a backchannel to 

Stretch goals:

• Full drive interface for the RC2014
• CP/M BIOS for the RC2014 that uses the serial protocol
• Fit the RC2014 Mini + 64k RAM + switching ROM + TMS9918A cards inside the case
• Have the video switchable between the Pi and the TMS9918A video card

Not sure how far i'll get, but it globs together all of the recent projects in a way that I won't feel like I'm neglecting one project by working on the others... since they're all the same project now. :D

Digital Logic in Javascript...

I needed some time off from my main project right now, and I had this bug in my brain to try out some of this, so I did a thing.  It uses javascript, jquery, bootstrap, and css stuff to do the whole thing. I use some of this at work, so this was a great chance to learn a bit more about that tech.

So here's a link to the quickly and horribly named "Logicr", pronounced "lä-jik-ər".

It's essentially a tiny javascript library/set of classes that simulate digital logic.  I'm not going to start drawing out diagrams of class hierarchies because that would take too long to do.  Instead, i'll quickly explain a bit of it, and then explain what the interface is showing.

At the bottom level, there are objects that are "pins".  This is a thing that can be set with a low, high, or floating data level.  I made the level actually a value from 1-100, below 25 is "low", above 75 is "high" and in the middle is "floating".  When you read them, you get back a true/false value, and you can write the 0..100 level, or true/false.  I made it this way so that i can eventually simulate pullups/pulldowns in the circuits.

Those pins are included in "nodes", which have a collection of inputs and outputs.  One example of a node is a logic gate.  A typical gate has two inputs, A, B, and one output, Y.  When the nodes get their update() call, they do whatever math is necessary to read in from their inputs and set their outputs.   Currently the system supports the basic 1-2 input logic gates: Not, And, Nand, Or, Nor, Xor, as well as one-pin output "sources" that generate High, Low, and Float output.

Another node is a "clock".  This one toggles its output once a second (1000ms) between high and low levels.

Another type of thing in the system is a "wire".  Wires are just lists of connections "from" and "to" pins on nodes in the system.

In the above example, there's a clock node (XTAL1), whose output Y goes to the first LED, named "clk".  There's a second wire from XTAL1's output that goes to the input of a Not gate (Inverter), in-turn, whose output goes to the second LED, "!clk".

You may notice that they don't change instantaneously.  That's because the system is set up to update all of the nodes first, then update all of the wires.  This prevented having to actually generate a real directed graph, and deal with loops and recursion and loops and recursion and stuff.  It probably simulates propagation delay on real parts, but i'm sure it has its own unique quirks.

So every 50ms, it goes through and tells all of the nodes to do their math, then immediately goes through the list of wires, reading from their FROM and writing to their TO.

So for the clock circuit:

• Nodes:
• Clock XTAL1 running at 1000ms
• LED D1, blue, labelled "clk"
• LED D2, blue, labelled "!clk"
• Not gate IC1
• Wires
• XTAL1.Y to D1.A -- connects the clock to the first LED
• XTAL1.Y to IC1.A -- connects the clock to the not gate
• IC1.Y to D2.A -- connects the not gate to the second LED

That's the basics of it.

But there's more.

I added a few input devices and output devices.  First is the switch.  The switch is essentially a html checkbox at its core.  When the switch node gets called to update, it reads the value directly out of the checkbox widget in the browser, and sets its output pin to the appropriate value.  Similarly, the LEDs are just a "div" that's made round and the right color (dim/bright red, etc) via CSS.  When the LED nodes are updated, they read the value from their input pin, then apply the appropriate "on" or "off" class to their html div.  The browser and CSS take care of the rest.

There's a couple other things happening in the circuit there too...

The amber switches are the A and B inputs to an XOR gate.  The A and B switches also go to the amber LEDs with the same labels, so that you can see what's going on there.  The output from the XOR gate goes to the green LED labelled Y.

The four red switches labelled 0x01, 0x02, 0x04, and 0x08 are run into a sort-of ROM, implemented as just a simple 16 value lookup table.  The ROM has 4 inputs and 8 outputs.  The 8 outputs are wired to the red seven-segment display node's "a"-"g" inputs, which light up the segments of the display on the web interface.  As you toggle the switches, the appropriate number is displayed.  The ROM data is basically a lookup table of which segments to drive for each value 0x0..0x9,0xA-0xF.  The equivalent of the 74LS47 ic chip.  I was originally going to build this circuit using logic gates, but it got really complex...  I may still do it eventually, once i have a better editor.

Mess with it...

In the interface, if you scroll down, you'll see an editor section at the bottom. Press the "Load Default" button to fill the text box with the circuit description that's running, and you can see all of the logic nodes and wire connections. Press the "Run Circuit" button to read in the JSON content from that window and rebuild the internal logic to use it.  The content there has to be valid JSON, otherwise it won't work.  The "Run" button will have a green border when it's valid, red when it's not.

Future

So yeah. This was meant to be a quick test to see how well it could quickly be done, and expanded upon for a possible future project that I've been thinking about for a while. There are still more component classes I want to add, such as "packages" which can group together circuits... for example, creating flip-flops using gate logic, or building that 7-segment decoder, or more complex things...

I also would like to make an in-browser editor of the circuits.  I've been looking at jsPlumb as well as a few other solutions for doing "create movable boxes with connection magnets that are connected with wires" type of things.  I may just spin up something of my own, as having draggable boxes is fairly easy to do using CSS/JS and then connections are just SVG lines between them, etc...  Although i'm sure the nuances of the interface make it more complex than it seems...

Oh. and this is running in my tiny page thingy, llmin... It's basically a wrapper for a page that sets up jQuery, bootstrap, and some other stuff, so that I don't have to create that boilerplate every time I want to make a page to test stuff. ;)

Finishing touches on LL530 v1.00 firmware

I'm currently cramming to get the first version of the firmware for my LL530 project out, so I can ship the first few ordered boards. (YAY!).

Quick backstory...

LL530 is a board with an Atmega32u4 (Arduino Leonardo/Pro Micro) and a few connectors on it so that you have a USB interface for Amiga/Atari ST/Atari mice, Atari controllers, and Amiga 500, 1000, 2000, 3000 keyboards.  Yes it even supports weird Atari controllers like Basic Programming's "Keyboard Controller" and Star Raiders' Video Touchpad, as well as the Indy 500 "Driving" controller that they made look identical to Paddles,... which are also supported.

Yes, there are other versions of portions of this, but I wanted more flexibility. I want to be able to just connect to the device, tell it that i have a mouse plugged in now, and it will just work... and in the future, auto-configuring the ports without even connecting... but i digress...

Yeah. I wrote a program in VCS Basic Programming via the Stella

emulator on my Mac.  Yeah. it's as cumbersome as it looks, but I'm

still freaking impressed that BASIC is even possible... it means only

one thing.. Warren Robinett is a god among men!

I'm getting off the subject here... okay...

Hey, Scott... don't forget the reason for this post...

Oh right.. Thank you Document McSubheading for reminding me.

No Prob..... now get on with it!

RIGHT.  So I'm trying to get all of the non-keyboard stuff working in one firmware.  I have a decent shell interface that lets you do all sorts of configuration stuff of the two ports, which I call "Port A" and "Port B".  I have a framework where you can pick the input device (joystick, mouse, paddle, etc) and then pick what it sends out to the host computer (mouse movements, joystick movements, various keyboard configurations.)

Now, the Arduino framework is kind of notorious for being slow in some respects.  That's the price you pay for ease of use.  One of the slowest is the port pin reads and writes.  For example:

digitalWrite( Pin3, HIGH )

 is a function that sets Arduino Digital Pin 3 as a HIGH value.  So internally, it looks at "Pin3", and figures out where on the ATmega microprocessor that maps to... The digital/analog pins from the Arduino are abstractions of the ATmega's actual ports.  for example digital pin 3 might actually be "PORTD" bit 5.  This function makes it so that beginners don't need to know that stuff... and what's more, all arduinos have digital pins 0, 1,2, 3, etc but generally map to different ATmega ports/pins... it might be PORTD bit 5 on a 328P, but it might be PORTG bit2 on a 32u4.  

Too much info.  TL;DR: digitalWrite() digitalRead() are an order of magnitude slower than just reading PORTG and masking off bit 2, which is near instantaneous.  (I should note that analog reads are slow, regardless, as the micro needs time to make the reading.)

I noticed this on the Eastman Theater sign project. I was using digitalWrite() calls to bit-bang out the data to the sign's shift register/LED drivers.  I was getting roughly 5 frames per second, when driving all 240 columns of 8 pixels...  When I switched it to direct bit writes, it went well over 60 FPS!

Mouse support....

I have all of the other controllers working, at least somewhat, and I've had a USB-Mouse interface using a 32u4/Pro Micro on my RaspberryPi/Amibian system for years now, so I knew it would work... but i was surprised when I finally got to working on the mouse device reading to find it wasn't working.  It was getting readings, but it was missing some... it was missing a lot of them.

To read a joystick, you only need to know "is it up now?"  "is it left now?"... not very time critical between readings.  However, for reading a mouse, you need to read all of the "gray code" sequence state numbers that it generates.  As it rotates left-right (the up-down axis is identical), it sends out, over two bits of the connector, a sequence of digits.

00 ⇨ 01 ⇨ 11 ⇨ 10 ⇨ 00 ⇨ 01 ⇨ 11 ⇨ ....etc

Moving left

00 ⇨ 10 ⇨ 11 ⇨ 01 ⇨ 00 ⇨ 10 ⇨ 11 ⇨ ....etc

Moving right

The mouse generates these regardless of you reading them. 

There was some slowdown in reading the mouse, so i was missing some of the readings... so instead of getting 00, 01, 11, 10, 00, 01, 11, ... I was reading 00, ... 11, 10, 00, .. 11, .. .. 01, ... 00,  which generated bad mouse movements, since those are sometimes recognized as left, sometimes as right, sometimes as completely invalid changes.

So it must've been the port reading?  Right?  That was my first thought too.  This thought was cemented further, when I tried out some stripped down firmware, which worked, but once i read from all three possible buttons, it would fail again.  I thought maybe the arduino framework was doing an analog read on one of those ports or something. I wrote some code to profile read/write times, and found that it was just as fast as expected.  (I had switched the port IO for this project to direct reads, without the framework long ago.)  (sidenote: Still not sure why commenting out button 3 had any affect... weird.)

So that wasn't it.

I eventually moved some simple mouse reading/generation code as a dedicated loop, which worked.. 

Next, I re-enabled my big switch statement that checks the input types, and checks the output types and does the right thing... to my surprise, it still worked.

I re-enabled some of the other polling routines... some are timing based, so they use the millis() function which of course has some overhead... and surprisingly, everything still worked.

Then I re-enabled the serial shell interface... and things broke... quickly!

But... the serial interface wasn't doing ANYTHING?!  what?!  All it's doing is first doing a

if( !Serial ) return;

The 32u4/Leonardo/Pro Micro will have major issues if you try to send out Serial data before it's done initializing that HID device.  This call just checks to see if the port is active.. I littered my code with them before Serial.print() blocks to prevent the thing from bricking again...  But even when the shell is active, i do a standard

if( Serial.available()) { .... }

to check if the user typed anything... then it pretty much returns...

The problem is... my assumptions were WRONG.

I threw some of these calls into my profiler, which is basically this kind of thing

startTime = millis();for( x=0 ; x<1000 ; x++ ) {    /* do the thing to test in here */}endTime = millis();

then it prints out (endTime - startTime)/1000, and you get the average time per loop.

if( Serial.available() ) { /* do nothing */ }

This took roughly 0ms per loop, so it's probably just checking a bit inernally...

if( !Serial ) { /* do nothing */ }

I thought this did the same sort of thing... Nope.  No matter what I did, 10ms.  Every time this is called, it blocks for 10ms.  No wonder that my mouse polling was failing! it was missing tons of gray code sequence states since the thing was almost constantly blocking in the "!Serial" check.

BLAGH!

It's feeling better now. :D

Anyway... Here's some more info on the project in general:

Links for the project are in flux right now; once I get the first version of the firmware packaged up, i'll be setting up a proper website/hub for it with full documentation of the project.  Until then, here are some links:

• LL530 at my Tindie store
• Controller Compatibility Chart... and my general notebook for research for the project 
• Firmware Version Roadmap

Testing the system is kinda fun!  Although that 7800 controller is pretty horrible.

RC2017/4 Update: The Andy Project - Tools

Just an update to show some progress on the project.

This project is to reproduce a near-pixel-perfect reproduction of a few of Andy Warhol's pieces that he created on the Amiga 1000 back in the 1985 timeframe, on native tools.

We're 12 days in, and I do not have any completed images to show y'all.  But don't be fooled into thinking I haven't done anything!  I've been running a timelapse of the entire process, and here's the segment for the tool setup work:

Here's a summary of the tasks done so far, and the direction I'm going.

Graphic editor tools

First of all I did a kind of survey of a few tools to figure out what would work best.  I had originally thought that I would use the pre-release GraphiCraft to generate the files, however I ran into a few snags.  This software crashes.  A lot.  More importantly, it does not  have the "save" function implemented.  It DOES however have something very important... Andy's works used some of the pattern flood fills that GraphiCraft (nee ProPaint) used.  These were removed before GraphiCraft was actually released.  But I'm getting ahead of myself here.  My feeling is that with this project, GraphiCraft will only be used to generate more sample and reference materials.  Mainly the fill patterns and how they are aligned, as well as the color palette, which seems to be untouched for many of Andy's pieces.

I have three versions of GraphiCraft here.  I have a pre-release version on a "v29 DOS" disk.  This is the one with patterns, correct palette, is unstable, and cannot save.  I also have two disks labelled "GraphiCraft 1.1" and "GraphiCraft 1.2".  As far as I can tell, the applications are the same, but one is on a Workbench 1.1 bootable disk, while the other is on a Workbench 1.2 bootable disk.  For some starting points of GraphiCraft images, I'll use this to generate the file, and perhaps I'll use them as the final save step, so that we get GraphiCraft /ProPaint ILBM files instead of DPaint ILBM files.

I have also settled on Deluxe Paint III for the main amount of the work.  1 and 2 are fine, but 3 just feels more stable and complete, at least with my 30+ years of experience with the Deluxe Paints... Deluxes Paint?  hmm.  DPaint 4 would work as well, but I've never really gotten completely used to/comfortable with it.

Slideshow tool

I also looked around a bit for a slideshow application.  I want the end product to be a bootable ADF that can be dropped onto a 1.3 system, or perhaps on an AROS-replacement-kick system. I wanted to use a program where I could just script it easily, without having to fire up a gui to add in or replace files.  So tools that were out included AmigaVision (2.x+), Deluxe Video (needs gui to make slides, palette limited anyway), and so on.
Early on, I was considering the "Slideshow" application that came with the "Deluxe Paint Art and Utilities" disk from Electronic Arts. I've used it quite a bit in the past, and it has exactly the type of "script it in a text file" interface that I want. However that one seems to not function on anything newer than AmigaDOS 1.1.  There is an updated version of this on the "Impressionists" art disk also from Electronic Arts, but that one did not work with 1.3 either.

Anyway, this is the exact feature list I want, in bullet form:

• Must run in AmigaDOS 1.3
• Fade in/out to black
• supports10-15 slides
• supports 320x200 32 color IFF-ILBM image files
• delay time while a slide is up
• (optional) user input to advance to next slide
• (optional) user input to exit from the slideshow
• should not require loading a GUI to add files, tweak sequence

Here's a quick summary of some of the tools I've experimented with, and my thoughts.  Some of them are from commercial products, some from Fred Fish disks, etc.
First: these were not suitable:

• EA Slideshow (DPaint Arts & Utilites Disk) - requires AmigaDOS 1.1
• EA Slideshow (The Impresisonists) - requires AmigaDOS 1.1
• EA Deluxe Video - requires gui editing to edit/tweak slideshow, 16 color images
• AmigaVision - requires gui editing, AmigaDOS 2.x+
• PPShow - Don't remember why. ;) I think it was doing weird palette things.
• Mostra - requires AmigaDOS 2.x (Aminet)

And these are potentials:

• dpslide - okay, can't seem to exit (Fish disk 11)
• slidemaster - okay as well (Fish disk 274)

Possibilities:

• ALook - TBD
• Show (Fish Disk 323) (early version of Mostra)
• Mostra (early version on Fish Disk 330)

One person on Facebook had recommended a trick that some demo disks did, which was to set the system colors to all black, then images could be loaded one by one from a startup-sequence or the like.  That's something I'll consider as well.  (also, ref Fish Disk 323, "Color Tools")

One AmigaDOS reminder; to make a CLI script executable, you use the "protect" command line tool like so:

    protect slidehowScript +s

AmigaDOS 1.3

All of this will be worked on in a virtual NTSC Amiga 1000 (or Amiga 500) provied by the FS-UAE emulator running on my Mac OSX laptop.  I've set up a Workbench 1.3 filesystem disk, onto which I have installed the basic 1.3 system, Deluxe Paint III and GraphiCraft 1.2.  This is honestly nothing too extravagant.
I set up a new FS-UAE config file with the specs:

• NTSC chipset
• 512k chip (Amiga 500)
• 2 meg fast (not really necessary)
• DH0: "WORK13:" is a filesystem-based hard drive, with a "Files" folder containing all the works-in-progress, and completed imagery

And I also set up a second config for obtaining and analyzing reference materials from GraphiCraft

ObeseBits

I discovered early on that it was going to be necessary to have some way to apply a grid to the reference images from the internet (PNG and JPEG images), so that I can recreate their content pixel-for-pixel.  Since they had differetn scaling, different compression and in some cases, different pixel aspect ratios (non-square or stretched-to-square) pixels.

The Amiga in the modes that Andy used had non-square pixels.  Well, the representation on disk was a 4:3 display of a 320x200 pixel image. This means that each pixel is slightly rectangular at 1.1:1 or something like that.  However, when they are displayed on an Amiga monitor or TV set, they are displayed-as-square.  This sounds confusing, but rest assured, it really is.

The tool that I eventually made, "ObeseBits" (the name is a play on the MacPaint magnifyer tool which it called "FatBits", but it's for much larger images. see?) has been made using the "Processing" development environment.  I used the most recent "Processing v3.3" to create it, using the "p5.js" JavaScript mode.  That way I could just run it in any browser without the need to install Java.

As I worked on it this past week, I rolled in a bunch of features which I figured would be useful for this project:

• Load in any image (scaled most images to 2xxx by 15xxx pixels for consistency)
• Show the image zoomed in (4x zoom defined in the code, nonadjustable)
• Grid is applied over the displayed image
• Grid has selectable white/black/yellow color with a few levels of opacity
• Grid has slightly bolder 5th lines, making 5x5 grid of pixels
• left-click drag to move the target zoom area around
• shift left-click drag to adjust the grid spacing/scale
• Scaled down to 160x100 thumbnail showing where the zoom area is in the "big picture"
• display of the current pixel color under the mouse

After using this tool on the same machine as the emulation for an evening, I've determined that it will be substantially more efficient to run this tool on a second computer, and dedicate the primary computer purely for the emulation environment.

Current State...

After the weekend, I've created the following content, using the above tools to be detailed in an upcoming blog post:

• GraphiCraft reference image 
• 320x200 IFF ILBM image
• Created from observations, documentation from GraphiCraft v27r6
• Recreated in Deluxe Paint III
• 32 colors with the exact palette from v27r6
• "purple balls" pattern reproduced with exact pattern-grid alignment
• "Campbells" image started
• Started with the reference image above, kept the palette and header bar
• Some of the top of the can is converted.

A Minor Dilemma...

I am caught in a dilemma of sorts though that I need to figure out at some point...

Andy did a lot of his work in ProPaint, which was the original name for GraphiCraft.  This can be seen on the video on youtube where he is capturing and editing a picture of Debbie Harry.  The header bar says "ProPaint V27 Release 14".  All of the released images from the recent effort show "GraphiCraft v27 Release 6"... Which is correct?  My gut is telling me that the software that he used, specifically, on that day for the presentation, it put that text atop the screen.  Perhaps that was the exact text on his copies as well.  I can only assume that the restoration team was using the software they had, not necessarily the specific application disks Andy was using... although I could be wrong.  I am trying to get into contact with them to determine exactly what is going on there.

For now, I'll stick with the GraphiCraft heading. ;)

RC2017/04 - A new direction... Andy Warhol

So the Retro Challenge 2017/04 is starting up again next month.  I've decided to try a different direction on this, this time.

For many years, I've been interested in the artwork that Andy Warhol had done on the Amiga.  For a long time, only fuzzy versions and NTSC video were available of it.  Fairly recently art historians found his Amiga computer, including all of his floppy disks and transferred the files off to modern devices so that we can all enjoy them again.

Anyway, after that procedure was done, scaled up pixel-perfect images have been released, in modern image formats.  The originals are still locked onto their disks.  I'd like to change that. (I should note here that there was a floppy demo disk circulating with all of the images as IFFs, but they were back-converted from the JPEGs... so.. yeah.  meh.)

So here's my plan:

I'm going to, as faithfully and pixel-perfect as possible, recreate some of the Andy Warhol pieces.

I'm putting all of the reference and work in here: (dropbox link) which currently is only photo references.

As far as I've been able to find, there are 11 works, which are represented here:

These are all captured from images and videos on the internet.  All are copyright the Andy Warhol Foundation for the Visual Arts, Inc. and are being used here without direct permission.

My plan for the first items are:

1. venus
2. signature
3. campbells can
4. self portrait (next to the can above)

And we'll see how it goes from there

I will be using GraphiCraft and Deluxe Paint (II) to reproduce these works.  I had originally thought to use the original pre-release version(s) of GraphiCraft to accomplish this, but I have decided to use production, shipping software to do the work, as they will be functionally the same, and a lot more stable.

I figure that my products will be my own works, much in the same way that Andy's reproduction of existing designs, like the Campbell's soup can, became his own...

I do plan on having minor, obvious intentional differences to differentiate mine from the "originals".