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.
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.
6502 16bit addition
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.
Off an on I’ve been working on an FM synthesizer. Today I finally hooked up an ugly UI so I can at least pass it around. Since I wanted to pass this app bundle around and I was using portaudio as a dynamic library I had to do some magic to make the application distributable. If you run xcodebuild then just hand off the app bundle to someone the app will crash at launch when the dynamic libraries are loaded. The built app has by default an absolute path to wherever your dynamic library is stored. You can check this by running “otool -L <executable path>” to see what dynamic libraries your executable is referencing.
At any rate, here is the script I wrote to make my app bundles distributable:
After you do something similar if you run “otool -L” everything should look sane.
Here is a link to an early release to the fm synthesizer. You can play it with your keyboard. There are tons of things that don’t work yet, like saving patches and the decay and sustain elements of the envelopes, but have fun anyways. Maybe I’ll get around to posting more about how it works: FMSynth 0.1
The developers at my company were recently tasked with removing push notifications from an iOS app. We ran through push notification tutorials in reverse, removing anything that got mentioned, but still we would be asked for permissions for push notifications on app launch. We were unable to duplicate the ask for permissions when building to device from Xcode so we were left building ad-hoc distributions, and you had to reset the device each time you installed the IPA. On top of that our app is a media heavy app that has half a gig of resources, so we were wasting alot of time building ad-hoc builds.
We spent alot of time fiddling with provisioning profiles since we already searched the binary’s symbols looking for any reference to anything push notifications related and we were pretty confident the changes weren’t in the code. Eventually we had to just start ripping the app apart, removing bit by bit until the notification didn’t show up. The culprit was finally found, it was a call to -[UIApplication setApplicationIconBadgeNumber:]. I have no idea what this is, apparently it is related to push notifications. I never setup the push notifications so I had no idea to look here.
This was an unfortunate perfect storm of compounding complications arising from developing for a close embedded system… sad sad sad.
New tools come out for software development all the time, usually they do more good collectively for productivity than not, but sometimes the limitations of the past had their hidden gems as well. Our industry is obsessed with the latest greatest thing, I’m not a curmudgeon that’s going to badmouth everything that came out since 1990, but like everything else, the truth is somewhere in the middle of those 2 extremes.
I was lucky to have started my professional career before the advent of Git and Mercurial so I got a couple good years using the previous generation of version control software (VCS). The major difference between using SVN (a previous generation VCS) and Git for me was the ease of managing branches with Git. With SVN it was such a hassle, it was rarely done by me. With today’s VCS’s you use branches all the time for things like trying out experimental changes or editing things without getting in the way of your colleagues. Just because our VCS’s didn’t have branches didn’t mean that we didn’t do these things though. What I, and I imagine alot of people, did was edit our code’s design to be more flexible so that with one line of code I could toggle the behavior of the program. All you had to do was make sure your object allocations were inside factory functions then introduce a new interface so that just swapping the factory function would change everything. It was a bit more work but it left a lasting modular plugin point to your code that could be used later and usually forced a more clear definition of the relationship between the objects via the interface.
I’m sure you are already seeing the danger here; if over prescribed this could lead to a more confusing, overly modular, code base. It was something I was always cognizant of, and it never became a problem that I saw, but I respect the danger. Today I use the branching the tools provide, but more than once I’ve recognized in hindsight some branches as missed opportunities to make my design more dynamic. Opportunities that I would have seized in a previous age out of necessity. So, we should see branching and modular design as overlapping tools and just make sure you weigh the benefits of both before you default to VCS branching. My guess is that 10% of the time you might want to modularize your design… then you can still branch, it will just be a single line difference.
The Problem: You wrote a custom inspector for Unity, subclassing the Editor class, after using the inspector you found that it is only updating when you interact with it. Values are changing continuously during Update() calls from the MonoBehaviour so there is no other event with which you can tie your inspector Repaint().
Solution: I’d recommend tying your Editor.Repaint() to some event if possible, but if not I’d recommend putting a lambda on your MonoBehaviour which gets conditionally called if you are running your code in the Unity Editor inside your Update method. Inside your inspectors OnInspectorGUI just set your targets lambda to something that will call your Editor’s Repaint Method.
Today I derived a neat little function I haven’t needed in the past. I don’t know if there is already for a classification for this type of function but its a step (floor) function whose value tells you when the next step is going to happen. “n” is the number of steps you want to happen before 1. So for example f(4,0) = 0.125, f(4,0.124) = 0.125, f(4,0.125) = 0.375.
I ended up using this to create another function that had spurts of regular activity, a saw wave with steep slope and long period, so the graph ended up looking like: ____/____/____/ More concretely it allowed me to turn interpolation between values on in pulses. I imagine there are a few cases where this class of function could be helpful.
At work I found myself needing to call previously written Objective-C code from Unity for an iOS app. My options were to rewrite the code in C# or find a way to call the code from Unity. I opted for not rewriting the code.
When looking around you’ll find ways to call C code from Unity on iOS apps using [DllImport(“__Internal”)] This requires that when you build the app to device; the symbol you are referring is inside the executable somewhere. Since on iOS dynamic libraries are verboten, this is your only option for iOS apps. So just generate your xcodeproj, then edit it to link in your library that contains the C symbols you want to call from Unity. This works but it will require that you build to device anytime you want to test your code that calls your C functions. Unacceptable! Especially since building to the iOS Simulator doesn’t work in my experience.
The other option is to make your library compile to a static library for iOS and a dynamic library for Mac OS X. That way inside of the Unity editor we can load in the Mac OS X dynamic library to call the code without building to device, awesome! There are a few gotchas though:
make sure your library is fat i386 and x86_64 (in my experience it only has to be i386 but I imagine this will change eventually)
you’ll need to have Unity Pro if you want to plop your library into the “Plugins” folder to have them magically distributed (if you are building for iOS this doesn’t matter anyways since you wont be distributing your dynamic library)
you’ll have to rename your library from “libfoo.dylib” to “foo.bundle”, the key part being the .bundle, it’s an error in the Mono runtime that they say will get fixed some day
if you aren’t using the Plugins directory you’ll have to put your library someplace where Mono can find it, like “~/lib”
The calling MonoBehaviour (NewBehaviourScript.cs):
Different people get into software for different reasons, and they get into it differently, like almost anything else. For some people software engineering is a means to a end, for others it is the enjoyment. In reality most people fall somewhere on that spectrum of enjoyment, process vs product.
I believe I can get along with anyone. I’m not as good as my wife, she’s a meek sweetheart who everyone likes. But some of the most challenging relationships in your software career will happen from dealing with people whose raison d’etre is different than yours. One example is pacing: someone who loaves process but loves product might have a more sporadic schedule where they will avoid the work, psych themselves up, then finally take their medicine and cram. A classic example of this is probably how most of us did our homework, because homework sucks. Someone who enjoys software development won’t have an issue working at a more constant rate, until then end of development when the work becomes less interesting of course.
This is where a solid development system and scheduling comes into play, and scrum does a good job at this. The product people need regular checkups to reduce the amplitude and period of their cram sessions. The process people need regularly scheduled time to provide feedback on the target. Small companies can run without a solid system and be productive, but it isn’t sustainable. Like driving a car around in first gear, the wear on the engine will eventually catch up with you.