Adventures with IronScheme pt. 2

So, I got a response on StackOverflow from the creator of IronScheme on how to combine enums.  It was very nice of him, IronScheme is obviously a labor of love for him.  Just as I wrote a conversion of the “hello world” program generator in F#, I now present it in IronScheme with no attempt to reduce the verbosity.


Software Engineering Parables 3: Project Xanadu


In the 1960’s Ted Nelson inspired a generation with his papers on the future of information and his coined term ‘hypertext.’  The culmination of his thoughts became Project Xanadu.  Project Xanadu was a mixture of the World Wide Web with version control which in his eyes would solve many of the worlds woes.  His assumption was that many of the worlds problems stem from ignorance and misinformation.  It was ambitious and complete in its appraisal of the problem with exchanging and archiving information.  One killer feature that was noted was the impossibility for dead hyperlinks.  Project Xanadu had a  ~20 year head start on Tim Berners-Lee’s World Wide Web, but alas it didn’t ship in time.

This story comes to mind when in Software Engineering we are designing something and the discussion devolves into a chain of minor considerations that complicate the larger goal.  History shows us that the implementation of the web that revolutionized the world was the system that ignored versions and dead-ends, the flawed version is the one that shipped and brought immeasurable value to humanity.


Reflection Emit with F#

Been playing around with making a Lisp with F#.  I don’t really know F# and I haven’t used System.Reflection.Emit directly yet…  So here is my direct translation of Reflection.Emit Hello World in F#:


Adventures with IronScheme

TL;DR; I wasted an afternoon attempting something I think is impossible with IronScheme.

Off and on I’ve been playing around with Lisps that target the CLR.  I was newly energized by articles about writing Lisps in F# so I decided to give it a try.  I met a bit of resistance since I haven’t used OCaml since… 2004.  So instead of working that out I figured if I used IronScheme I’d already have a parser, so I could just skip to the generating CLR part of the problem, but alas I think I’ve ran into a impassable wall.

While trying to use the System.Reflection.Emit library I was perturbed that interfacing with C# libraries from IronScheme were so verbose, unlike the nifty Java interop in Clojure.  Example:

Most of that can be hidden with macros, but it still requires you to specify the type of the instance you are calling the method on and thats annoying.  But that wasn’t the impassable wall.  The impassable wall is I couldn’t figure out how to ‘or’ enumerations.  System.Reflection.Emit.ModuleBuilder.DefineDynamicAssembly takes in System.Reflection.TypeAttributes which are an enum that you are exported to ‘or’, like this type is public and a class.  I tried hard to ‘or’ them with IronScheme using the bitwise-ior function sometimes in combination with clr-cast but I couldn’t get it to work.  I finally gave up when I saw that there was a footnote in the IronScheme documentation that out parameters aren’t supported, that was the signal to me that not everything is possible with IronScheme C# interop and I gave up.  What a waste of an afternoon, I thought for sure it was going to be productive.

Then problem case:


Color Blending Exploration

In OpenGL and ShaderLab you can customize the way that blending is done.  In ShaderLab you use the Blend keyword and in OpenGL you would use glBlendFunc or glBlendFuncSeperate.  Notice that ShaderLab can do like glBlendFuncSeperate, you just have to supply more arguments [1].

Someone has developed a nice visualization that can be used to explore the settings for these functions:

Wikipedia also has a nice section on alpha blending that is worth checking out:

Checking out the man page for glBlendFunc is always helpful too:


Software Engineering Parables 2: Archie Bunker

All in the Family
All in the Family

My next parable comes from Jesse Schell’s wonderful book “The Art of Game Design.”  In the book at some point Dr. Schell starts recounting the story of the development of the hit TV show from the 70’s, “All in the Family.”  So the show had been planned out and they filmed a pilot episode and decided to do some user testing by having some people watch the episode and asking them what they thought of the show.  After having watched the pilot episode people were pretty impressed, they liked it for the most part, except they thought that the show should would be more enjoyable without Carroll O’Conner’s character, Archie Bunker.

If you haven’t seen “All in the Family” before, Archie is the working class patriarch of the family.  He has his progressive daughter and son-in-law living with him.  They often end up in some debate where it is Archie’s old fashioned conservatism vs. his son-in-law’s progressive views.  Archie became an important vehicle for satirizing old fashioned prejudice and the show was wildly successful.  Bottom line, “All in the Family” would have been a load of shit if they listened to the feedback.  Not only that, I’ll say the world would be a worse place without Archie Bunker.

Jesse Schell provided this anecdote as the cautionary tale to balance the call to do user testing.  It is that, but also I see it as a tale that highlights the need of a vision for your work.  Had Norman Lear just been seeking to make money he would have tried to please everyone and thrown out Archie Bunker.  Fortunately for us he was in a position where he could execute his vision and make the show he wanted to make.  This was the product we fell in love with, because it didn’t dilute its raison d’etre.

Software Engineering Parables 1 : Feynman’s Biology Class

Dr. Richard Feynman c/o
Dr. Richard Feynman c/o

As software engineers we should always be on the lookout for lessons from other disciplines or from the past.  This industry is young, but also has amnesia.  Over the years I’ve clung to a few stories that resonated with me and formed my opinions on the art.  I’m going to share them in a series called Software Engineering Parables.

One book that is just chalk full of wisdom and can be a source of inspiration for anyone is the book “Surely You Must Be Joking Dr. Feynman”.  It’s an autobiography by the famous physicist Richard Feynman.  Feynman was a bit of a rebel genius who had a knack of seeing the same things as everyone else, but understanding them differently than the average Joe.

I believe the story goes that he was at Princeton, where he was studying physics.  Dr. Feynman had such a curiosity and love of learning that he would often sit-in on classes of different disciplines.  So, he picked up a class on Biology and would show up for lectures and follow along.  I don’t know if he was officially enrolled in the class (it wouldn’t surprise me if he wasn’t), but the story goes that eventually he decides to write a paper on Biology.  He feels like he has something to contribute to the field, so he gets to it and when he is done, since he has befriended some Biology majors while on campus, he decides to get one of them to proof read his paper.  The friend took it overnight then brought it back to Feynman telling him that his idea was fantastic but the paper is written all wrong, no one will take it seriously.  The friend offers to edit the paper for Feynman and to make it more inline with what is expected from a Biology paper.  Feynman agrees and in a couple of days the friend returns with the edited paper and hands it to him to read.  Feynman studied the new edited paper and he confessed that he didn’t understand it anymore, even though he was the originator of all the ideas and the original author of the paper.  The academic field of Biology expected a certain protocol on its papers, but since Feynman studied Physics he wasn’t privy.

There are so many lessons in this tiny story.  One might be that sometimes we are the authors of our own complexity.  It comes to mind today because I find that different companies have different forces at work that attribute to the level of pomp in communication.  In a startup with limited resources it is our goal to keep things simple and efficient.  At big companies, pomp is incentivized to prove your worth and intelligence.

Interview with Trip Hawkins

I missed this interview the first time around, this is with the founder of Electronic Arts, Trip Hawkins.  His story is entertaining with him working at the early Apple computers, to him creating a game publishing company because he saw programmers as tomorrow’s rock stars. The tale is filled with perfect timing, being right for the wrong reasons, and tenacity.

The interview left me a bit shaken.  I wonder what the moral of his story is, what does it mean for people in the software industry in 2015.  I see a man that is driven, who was wildly successfully and fantastically got his ass handed to him.  I guess the lesson is, you have to love playing the game because if you are playing to win its probably more out of your hands than you want to believe.

C64 Assembly Development

October 18, 1987. (Photo: Lyn Alweis/Denver Post) via
October 18, 1987. (Photo: Lyn Alweis/Denver Post) via

My latest obsession has been developing for the Commodore 64 with 6502 assembly.  I missed out on the c64 craze unfortunately.  My family’s first computer was a 128k mac.  It didn’t ship with BASIC so that delayed my access to programming by a few years.

So, in order to do c64 development I’ve been writing the code on a modern computer then cross compiling with the ACME assembler then running the result with the VICE emulator.  I couldn’t bring myself to type out the code on the c64 itself since I’m too used to emacs keybindings.

For this post I’m just going to provide links to the sources I’ve been using and collect some tips I’ve picked up along the way.


  • VICE has the ability to monitor your emulator.  While it is running if you go into the menu and find the option “Monitor” the machine will pause and you will be provided with a prompt similar to gdb.  From there you can print the contents of memory, the values of registers, step over lines of code, see the disassembled code in memory, and add breakpoints.  You’ll need to use this at some point.
  • Learn to do 16 bit arithmetic.  This will come up eventually.

  • At some point in your 6502 code you will accidentally type “$00” when you meant “#$00”.  It’s an easy typo to grab the contents of memory location zero instead of the constant zero, it can be difficult to spot so keep an eye out for it.
  • Be aware of what machine you are developing for.  By default VICE runs as C64:PAL.  Since your code will probably be tied to screen refresh interrupts, code that works on PAL might not work as you expected on C64:NTSC.
  • C64 computers can have one of 2 sound chips, the 6581 or the 8580.  Developing music for one might not sound good on the other.  The huge difference everyone mentions is the 6581 has a bug in it where it pops when you set certain parameters, people use this bug in order to playback PCM audio.
  • Indirect Addressing (pointers) only work if the address is on the Zero Page (the first 255 bytes of memory).  Also the Zero Page is hotly contested real estate, one safe place to put things is $FB and $FC.
  • The VIC-II (the video card) can run in one mode at a time:
    • hires character mode – a single global and background color, video memory is a series of 40×25 character codes.  Character codes are 8×8 bits, each bit deciding if its background or foreground color.
    • multicolor character mode – similar to hires character mode, except each character is now 4×8 pixels since each pixel is represented by 2 bits.  It will chose from 3 global colors or a 4th color that is an 40×25 array, an element for each character.
    • bitmap mode – this can be multicolor or hires as well.  This mode lays out all the pixels somewhat sequentially in memory.  They are sequentially aligned like characters.  So the first 8 bytes represent the colors in the top left square of real estate, instead of the top line as you might have expected.
    • There are other modes mentioned elsewhere but these are the ones the old documents talk about.  I’m guessing those graphics modes are hacks to get different qualities like more colors.
  • Joystick handling is inverted, each button and direction on the joystick has a bit associated with it in the hardware register $dc00, it is being activated when that value is zero, not one.
  • All games and thus most users assume the joystick is plugged into port 2 not port 1.
  • LDA sets the zero flag and negative flag.  I was expecting only math or logical operations to set flags.