Monday, May 1, 2017

RC2017/4 Final! (Replica Results and Post-Mortem)

"The Treachery Of Pop Pixel Art" - Scott Lawrence, 4/30/17
Inspired by Andy Warhol and René Magritte's works
As you might know, I spent time this past month working on what I nicknamed "The Andy Project". The idea was to re-create some of Andy Warhol's art pieces on an Amiga, well, an emulated Amiga, using appropriate tools, as pixel-accurately as possible.

This blog post will be a summary of results, mentions of pitfalls, and that kind of thing.  The previous three blog posts cover most of the other information for the project.  Links for these are on the bottom of this post.

Philosophical musings...

Andy's work is interesting because you don't see any other of the "classic" artists doing their work in such a media, where you can get pixel-for-pixel copies of the originals.  Nowadays, sure, you get photographs of the original, but with these digital art works, you can get essentially the EXACT same content that was originally produced. This is likely why the "originals" have never been made public directly... Understandably so.... That floppy gets out, and we see posters of pop-pixel-art available in every mall. That said, I want to make poster blow-ups of some of these. ;)

This actually got me thinking a lot about the resulting media files that I will be produced.  These will be virtually indistinguishable from the originals.  Are they the same as the originals?  In some of these, I am the person who drew all of the individual pixels in Deluxe Paint.  It is distinctly not the original files, which are still under lock-and-key.  But those may surface, and you may find that mine are nearly identical with respect to which color pixels are where on the digital canvas.

In the music industry, if you were to make a copy of a waveform, by looking at numerical representations of the wave, and typing them in to a computer, making a replica of the original waveform.  When played back, it's still Debbie Harry's "Rush Rush"... but you actually created it from scratch by copying the numbers from the original.  It's a replica... that is functionally and actually identical to the original.  In fact, if you were to write a computer program that did this for you; go through the audio file, and look at the numbers, then write those numbers into another file... then the computer has generated a replica of the original... That's exactly the same as I'm doing here, right?

That software already exists.. it's "cp", "copy" or "drag-and-drop the icon to another folder."

Does that mean that I cannot take credit for my reproductions?  This is kind of why I had wanted to add specific mistakes/changes to mine, so even if you were to compare them at the pixel level, mine would be at the least, a derivative work. ... but is that enough?  Couldn't Andy's estate come after me and say "that imagery is exactly the same as the original, and you're putting it up online for free! Stop that now!"

I know that mine are replicas...  perhaps that's enough.

But then, if you think about the pop-art movement of the '50s and onward, it delves DIRECTLY into this, head on.  Andy, for example, took iconic things (soup cans, Marilyn Monroe) and used them as the basis for his iconic works.  If the Campbell's Soup can looked different, so would have his artwork.

So in that vein... My reproductions are essentially my brand new art pieces, just using his pieces as the inspiration...

Wait.. are mine replicas of his works?  Are mine new works, like the originals under the pop-art umbrella?

I don't know how to resolve this.

The Andy Project

I started out with a list of 11 images to pick from.  I thought I might get a few done, but I never set specific goals for myself... so I only got three of them done.  I still feel like this is a major success. Mainly because I can now do many of the other ones at my leisure using all of the tools and frameworks I've already set in place, with full knowledge of the pitfalls for the various steps.

I also created two pieces that I was inspired to make from the project, so I included those in the ZIP and slideshow ADF as well.  Links to the slideshow ADF downloads are at the bottom of this blog post, along with an in-browser emulator that can play it in-browser.

Everything provided here is to be considered to be Creative-Commons BY-NC-SA. (Attribution, Non-Commercial, Share-Alike).

What went wrong

I think the big thing that went wrong was wrangling with tools. There are two instances that come to mind.
Nothing really went wrong here, I just thought it would almost
be appropriate for this to be my end-state of this image. :)
I feel like Andy might have accepted this.


First of all, my tool "ObeseBits" was giving me trouble.  It's the first Javascript-Processing app I've ever really made.  Most of the time for Processing, I just use Java mode.  That seemed a bit excessive, and I wanted to make something I could easily share, so I went Javascript instead. 

If you watch the time lapse, you may see bits like this roll through.
The frustration was real.
This is a fine choice, but I had a problem where... I'm not exactly sure what was going wrong, but I was re-drawing the entire screen every frame.  It seemed to be chewing on more RAM that it should, especially after it sits for 5 minutes... especially running in Chrome on a 8 year old mac with 2 gig of RAM.  Yes, I see the irony here that I'm creating these images on a machine that could do this with 1/2 megabyte of memory... hehe  Anyway, it would get so unresponsive that it would essentially lock up the machine, but it always seemed like it was JUST ABOUT TO wake up.  But no... spinny rainbow pizza instead...  Force reboots were my friends.

FS-UAE emulator

The other main issue was that I couldn't get the ADF file exported from the emulator I was working in!  Seems like a pretty straightforward thing to do:

  1. Mount an ADF disk image
  2. Diskcopy Amiga Workbench 1.3 to it
  3. Make space by removing printer drivers, fonts, utilities, etc that aren't needed
  4. Copy my "Files" folder from the virtual hard disk to the virtual floppy
  5. Set the startup-sequence to just add disk buffers and then run the slideshow (DPShow)
  6. Quit out of the emulator
  7. The ADF disk image file you have there has all of the above done to it, right?

.  I was using FS-UAE that, because of reasons that kinda make sense, treats all mounted ADF disk images as read-only, and creates an "overlay" in a separate directory with all of your changes.  So... here's the list of things I tried to get the modified ADF out of the thing:

  1. "apply" the changes to the ADF.
    • Can't do this.  The change overlay is in a custom format.
    • No tools exist to do this. (!!s)
  2. Turn on the UAE emulator flag "writable_floppy_iamges=1", which tells the emulator that it's okay to write directly to disk images for new disks.
    • Then you must mount a new disk, once this is set, diskcopy the content over, and you'll end up with an ADF with all of these changes. Right?
    • WRONG. FS-UAE ignores this flag.  There is literally NO WAY to write to an ADF that I have found directly from FS-UAE.  (let it be noted: otherwise, FS-UAE is freaking awesome.  this just really frustrated me.)
  3. At some point in here, I needed to edit the startup-sequence on the ADF, and I couldn't do it via the emulator's mounted-folder-as-disk-image, so i grabbed "Vim" from Fred Fish disk 591.
    • This required ARP for some reason, so I grabbed ARP and ran the installer.  
    • It replaced a bunch of AmigaDOS commands, added a library, etc.
    • Vi now worked.  Yay!
  4. Make a disk image to a file within the emulated Amiga.
    • Sounds ridiculous, but in fact, yes... it is ridiculous.
    • The only one I found that "should" work in AmigaDOS 1.3 was "TransADF"
      • Grabbed TransADF off Aminet, put it on my "Work13" disk (which is a mounted folder from my Mac). 
      • Ran TransADF, and... GURU MEDITATION
    • Fumbled for a while and realized I could boot an emulated AmigaDOS 3.1 system.
    • Booted up AmigaDOS 3.1, ran TransDisk, created the ADF, looked good.
    • Booted back into 1.3, and suddenly, on "loadwb", the system just locked up with a blank blue screen.
    • Eventually traced it back to ARP being an issue.
    • Luckily, my Work13: disk was being maintained by Git, so i just reverted the changes that the ARP installer did... and now it all worked again.  blerg.
So yeah.  Cumbersome as all get out, but I managed to get the ADF made, and I now know I can just boot into 3.1 and run TransDisk to do this again.

What went right...

I got three image replicas done! YAY!

I feel super proud of the fact that I was able to do it to the best of my abilities, to the best effort I could provide and do.  I tried my best to be pixel-perfect, to be color-accurate, and I think the results paid off really well!

You can see me work on these in a time-lapse on YouTube too!

What you see here are EXACTLY what I was doing this project to avoid.  Incorrect aspect ratio, wrong file format, etc. ;)  But they show the effort. I  left the Deluxe Paint panels up just for fun, and to show that these are in fact the ones that I made, and not the source Warhol material.  If you want the proper files, they're downloadable at the bottom of this file.

"campbells.pic" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

"Campbells" took full advantage of the foray into GraphiCraft, as I used the palette generated from the saved out Graphicraft 1.2 image, but then tweaked by hand to accurately match the pre-release palette that Andy would have had available to him.  I feel like this is a great representative pice of his work on the Amiga, as well as for this project itself.
"venus" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

I had originally thought that "venus" was going to be pretty simple. It was mostly the "venus.iff" file that is included with every copy of Deluxe Paint.  (Here's a link to the original as seen in Deluxe Paint IV.) Well, there's those two orange dots on the left, the scribble on one eye, and the third eye... so it should be easy.  Right?  Nope.  

  1. The source material that I had was a JPEG, with its entire color palette completely wonky.  Browns looked violet... whites looked yellow... that kind of thing
  2. This means that I had to spend time not just picking the right color, but also cross-referencing the pixel in the jpeg with another of the same wrong color, but unchanged by andy... then find THAT color in my DPaint version, and use that color.  
  3. The forehead.  I don't know how... I don't know why, but Andy replaced MOST of the forehead with the version that's there... He probably just grabbed a brush and pasted it down a lot. There's some evidence of this being the case along the left side. Perhaps I'll analyze it more for another blog post in the future.  I ended up having to wipe out the entire forehead and re-do it entirely.
I do feel it necessary to note that many of the pixels in this are "close".. not specifically the exact correct shade of the colors.  There are a lot of orange/browns that are VERY similar and with the process of cross-referencing mentioned above, I know that I made a few mistakes here and there on this one.

I had felt a bit uneasy looking at this one for a while, but couldn't place exactly why... but it turned out that the forehead's replacement was a huge subconscious "something's not right here" flag in my head that I couldn't quite place. 
"flower" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

This one looked like it was going to be fairly straightforward to make... and it in fact was!  There were a lot of stepped lines, and the source material was scaled up and fuzzy, but I was able to work around this.  I remembered that DPaint has a tool "Coords" (press | to enable) which shows where your cursor is in X and Y, and also length of lines you're drawing.  This took was invaluable for doing this replica.


Yes, I did notice that "Flower" and "Campbells" are missing the red rectangles in the upper right of the imagery on the provided ZIP and ADF files below..  Those are the screen raise/lower tools from AmigaDOS shining through.  Much like the "GraphiCraft" drag bar being visible, those should also have been visible. That's my mistake. The next version I cut of the slideshow will have that fixed.



Here's a list of links of products and stuff that may be interesting:
Everything provided here is to be considered to be Creative-Commons BY-NC-SA. (Attribution, Non-Commercial, Share-Alike). 

And previous blog posts about the topic:

Friday, April 28, 2017

RC2017/4 Update - ObeseBits is now online!

I've not gotten more images done yet, but I have exported the tool "ObeseBits" to the interwebs.  You can play with it here:

Press 'I' (uppercase) to pick a different image, 'G' and 'g' to change grid mode and settings, drag the mouse to move around in the image, and shift-drag to adjust the size of the grid.

I made it in Processing 3.3.1, in "JavaScript Mode".  When I got to this point, i just copied the entire directory to, and there it is!

Enjoy!  Or dont! Whatever!

Building some RC2014 upgrades...

I've been working on upgrading my RC2014 Z80 computer for the past few months, but in a very low-impact-to-my-finances-that-can't-support-it-otherwise way.  This post will just go into explaining a few of the upgrades I have in mind,

First of all, my current hardware scheme, the "RC2014/LL MicroLlama" as I call it, is and has been fully functional in its current state, and is emulated well in my emulator.

I started working on a mass-storage solution for the MicroLlama, which I have slightly back-burnered this month so that I could attempt to focus on the 2017-04 RetroChallenge ("The Andy Project"), but I'll likely pick it up again next month, especially with some of the upgrades I now have in my hands, which I will now briefly talk about...

Dr. Scott M. Baker's Bus Supervisor Board

A ton of chips and a well packed board!
I just received a "kitted" version of Dr. S.M.Baker's RC2014 Bus Supervisor board. Major kudos to Rob Leisenfeld from the RC2014 community...

The short description of this is that it has some I2C I/O Expanders that sit on the entire bus (Data, Address, Control) as well as replaces the system's 7.37 Mhz clock board.  This can be used to snoop on the system, read/write IO, read/write RAM, etc... taken one level above that, you can use SMB's python scripts to upload data right into RAM, thus eliminating the need for a ROM module.

People have successfully used this to run 64k RAM-only RC2014 computers, and upload the program ROM from their Raspberry Pi. (Schematic, GitHub link to software)

It took me about 15 minutes to figure out the orientation of that crystal.
(Pin 1, the pointy corner, is in the bottom right)
Also, I'm not sure the jumper configuration is correct yet.
That's where my personal problem with it comes in.  As it stands, his project uses a RasPi to communicate with the board over I2C.  This is fine, however it does not fit within my workflow.

I do not really have a RasPi to use for dev work, so my solution is to take a tiny Arduino Leonardo clone ("Micro-SS" like this one), with a cable connecting its I2C lines to the Bus Supervisor Board.  Then, I'll make a thin Serial-I2C bit of software and making some desktop tools, perhaps in python to fit with the original from SMB.
My "proof of concept" for USB-I2C communications.
Here it's connected to an RGB color sensor.
The end result is that in my Z80 project makefiles, i can add a target for the generated .HEX files to be downloaded directly to the physical RC2014.

I've made a cable for my Micro-SS and have built my Bus Supervisor Board.  As you can see in the photo, this is it set up on a powered RC2014 backplane with only the standard IO module, and a few LEDs on a few data lines, so that I can test out everything before putting the CPU and RAM on there, potentially damaging them.

Obviously, it would also be possible to include a couple of ROM programs directly into the MicroSS, and possibly store a small one in the ATmega 32u4's EEprom as well.  Some buttons on the MicroSS could be used for injeting these pre-stored programs.  i could even see a program that generates a menu that the arduino can basically farm out to the Z80 to get user responses/menu options, etc.

Additionally, I can make a RC2014 bus - to - pac-man bus adapter, and actually deploy code-in-development directly to the machine from my desktop from the makefile/build scripts.  ... This is a dev tool I've wanted for about 20 years now!

Lots of possibilities!

I will put out another blog post and a github link for the supporting software, when I've got this working. (estimated - mid next month)

64k RAM and Pageable ROM

I also received this past month the boards for these two official RC2014 boards: the 64k RAM and Pageable ROM.  As you can see in the pic, i still need to order quite a bit to make these work.  Now that I have the Bus Supervisor board, the Pageable ROM is less interesting to my needs, although I may still adapt my RC2014/LL design to use these pieces instead.

You can see pics of these in the top of this blog post.

The 64k RAM will definitely work well with the Bus Supervisor board, however the Pageable ROM board has definitely taken a bit of a slip down my plate... Until I can get the parts in for the RAM (sockets, etc) I can use my existing unmodified 32k RAM board for the upper segment of memory ($8000-$FFFF) and my slightly modified second 32k RAM board for the lower segment of memory, I just have to manually enable it for read/write.

Monday, April 17, 2017

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)
  • 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


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. ;)

Tuesday, March 14, 2017

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".

Monday, December 5, 2016

RC2014/LL Showing ROM/RAM switching, 64k!

So I thought I'd just make a quick post to show how I know that the ROM swap hardware in my RC2014/LL is working. I'll walk through the procedure here...

First, I booted up the RC2014 as usual, which drops me into BASIC.  From there I wrote this short program:
10 FOR A = 0 to 8192
20 B = PEEK( A ) 
What this does is goes through the lowest 8 kbytes of memory, reads (peek) and then writes (poke) the byte it finds right back to the place it got it from.   For example:
  1. Read from memory address 0
  2. Write to memory address 0
  3. Switch to the next memory address, repeat 
Which seems stupid, that it does nothing.  But if you remember from a previous post, when the ROM is enabled, it's only enabled for reads.  Writes still happen to the RAM in the same addresses.  So the above program copies the BASIC ROM into RAM.

Next, we switch off the ROM by doing this:
 OUT 0,1
The lowest bit, '1' turns off the ROM, and switches to the RAM for read operations.  To confirm we're working out of the RAM, we can poke a 0 in somewhere down there.

POKE 0,0
So we can see here that memory address 0 has been changed from 243 to 0.

I also went one step further and yanked the ROM board out of my RC2014.  This is not recommended. ;)  But it did continue to run without any problems... until I really tried to muck things up, for fun:

I wrote a program to clear RAM, and then ran it in BASIC.  Here is the listing:

And here's what happened when i typed 'run'.  It completely locked up after it printed the '8'. Starting at memory address 0x0008 is the text output routine, so it cleared out the boot code before that (0x0000-0x0007), erased the beginning of the print handler, then went to print out something to the screen, and crashed.  Well, I assume it crashed. It got an invalid opcode and who knows what it's actually doing. The code there used to be a "jump" which is 3 bytes.  Instead it got a NOP, which does nothing, (0x00)  and then two garbage bytes which map to something incorrect. Boom!

Monday, October 17, 2016

State of the RC2016/10

RC2016/10 is a little more than halfway over... so where am I?

Pretty much in the weeds.

I'm almost at the point where I wanted to be at the beginning of the challenge. I'm still working on finishing up the SD loader routines.  Well, I've finished the SD/Micro side of things (in the SSDD1 module - Serial SD Drive) both for the real physical drive as well as for the emulator, for loading only.  The emulation also supports writes now, and both support file/directory manipuations:  Directory listings, make directory, remove directory/file. (For the FAT filesystem anyway.)

I've got a bunch of things on my plate right now, between work, finishing up a contract or two, the animatronic bird project has reappeared a bit, plus time for the family, lack of sleep, and general lack of motivation for anything.

I haven't done any of the sector IO stuff yet, as I want to get regular files working.

In any event, here's a quick bullet summary of the current state of the project:


  • Hardware for SD interface
  • Hardware for ROM/RAM switcher
  • SSDD1 process design (see image above)
  • SD drive (SSDD1) firmware (preliminary)
  • SSDD1 emulation for file and directory support
  • SSDD1 firmware for directory support and file reading
  • CP/M research to figue out what needs to be done, prior work.


  • SSDD1 firmware for file writing
  • SSDD1 firmware and emulation for simulated sector IO
  • Z80 SSDD1 decoder (Hex string+checksum to proper formatter)
  • Z80 IHX decoder (stream from SSDD1 to RAM writer

Gameplan tasks (Roughly in order of probable completion):
  • Z80 IHX decoder
  • Load a ROM from the SD card into RAM, switch off the boot ROM, restart, run from RAM
  • Backport emulation into the firmware to get them equal
From here, I can go down one of two paths.  I can completely flesh out the rest of the SSDD1, and get the sector IO code implemented, which is probably the best course of action, just for completeness.  Or I could start working on porting/implementing the CP/M bios ROM, which might give me the "win" kick that I need to get the Sector interface implemented... although once I have the regular file IO stuff done (which it is) the sector IO stuff is the same plus a bit more wrapper implementation... after all it's just a bunch of 128 byte files in subdirectories... so...
  • Sector IO SSDD1 emulation
  • Backport Sector IO to SSDD1 firmware
  • CP/M Bios
  • CP/M Bootloader into LLoader ROM
  • Burn new LLoader ROM to 27C512 EPROM
  • Boot a RC2014 to CP/M!