So, it seems as though I’m suffering from the same malady that I did in college. By the time I get home from a long day of school and work, sitting down and putting more of my energy into writing the applications I’m working is just not appealing, especially when they will likely result in any real tangible benefit (or at least, that benefit is significantly down the road).

StudioMan is at a dead stop, again. Every time I think I’ve got it figured out, I re-imagine the way it should work. I have trouble envisioning a user interface that’s clean, yet has a place for all the information that I need it to display.

WeatherMan is at the opposite end of the spectrum. I know exactly how I want the interface to look and act, but the implementation is what is killing me. I haven’t really been able to wrap my head around the iPhone’s UI framework yet, and on top of that the damn NWS internet weather feed is still borked. My tax dollars hard at work.

And then there’s CocoNES. I think that this is the project that seems the most appealing to me, likely because out of the three it’s the one I consider most a hobby. It’s also the one that’s been the hardest to work on, because after working all night, and then not getting enough sleep during the day, trying to wrap my head around how to implement hardware in software just makes my brain melt.

I know I can’t be the only one out there with these issues… How do you keep the motivation going?

So, I began some preliminary design work on WeatherMan the other day. For this first run I’m probably going to use the UIKit navigation tools for organization. I don’t know whether or not I’ll stay with them, depending on how things look down the road.

For the most part, the program will be fairly straightforward. All data will originate from the National Weather Service. The program will need to be able to take location data (supplied either by the user in the form of city/state or zipcode, or supplied by CoreLocation) and translate it to figure out the correct NWS zone. From that point, it’s a pretty simple retrieval of data from the NWS public access servers, and then format that data for the user. There will probably be a backend hosted on my Dreamhost account to take care of much of the heavy-duty work.

While most of this will be straightforward, there are two or three specific things that will need some major work:

1. Geocoding. I will need to make a database of NWS zones and their boundaries, and also figure out a way to translate the city/state/zip user data into latitude/longitude. I believe Google Maps offers this functionality, but I don’t know what limits it has and/or what the cost is for commercially licensed software.
2. Radar. My plan is to use the raw radar data provided by NWS and overlay that data onto Google Maps. Unfortunately, that means I need to come up with a way to translate touch events into Google API events, as there is no Google Maps frameworks in the iPhone SDK (WHY?!?!?).
3. Advisory notification. This could be the most difficult part. There are two major challenges here: Getting the data, and then getting it out to the end users. There are two options for getting the data: push and pull.
   1. For the casual end-user of this data, pull is the obvious method. The data can be easily retrieved from the NWS servers on demand. However, since I want to provide notification, this muddles things up a bit. How often do I pull the data to check for new notifications? Too often and I become an unwelcome drain on their servers, and too infrequently I limit the usefulness of the software, as watches and (especially) warnings are very time sensitive. Pulling the data is not a very good option.

   2. Having the data pushed to me is my other choice. This is how your local news channels and other websites receive their NWS data. I did some research on this today, and it may actually be feasible. The big guns receive their data via a satellite feed. This has very high initial and recurring costs, and is not really an option for a small-time developer like myself. However, the contract between the NWS and their data provider specifies an internet delivery option, which in its most basic form has a one-time $75 charge associated with it. When I say basic, I mean basic: You establish a telnet connection to their server and the data is streamed in realtime. The uptime is a little less reliable than the satellite options, but it should be good enough, especially if I write a cron job to check the status of the process that is reading the data. I’ll need to figure out how to parse the data; though the service has a 30-day trial period I haven’t been able to try it out as the sign-up page is currently offline (hoping that’s not a bad omen). If I can figure things out, this should be the way to go.

   As far as sending the data out, it’s not an option at all until Apple implements their notification services. After that time, we’ll see. I’d like to be able to target specific users with specific notifications if I can, but at the same time I’d like the application to be useful from first launch, without the need for registration or anything of that nature. Again, a moot point until the time arrives that these notifications can be pushed out at all.

Due to the costs associated with running this service (Apple’s developer fee, the access fee for the weather notifications, and the possibility of more hosting charges if this thing gets bigger than I think it will and Dreamhost kicks me off of shared servers), I will definitely be charging for this application. The price will be no higher than $4.99, and I’m actually leaning toward $.99 or $1.99. This will allow me to recoup costs associated with keeping this running without introducing a huge cost barrier to the consumer.

So, a little more on CocoNES’s 2A03 core. But first, a general idea of where I’m going with this. I’ll be running two threads–one is the event dispatch thread with the main event loop, and then the virtual machine itself will run on a secondary thread. The VM loop is really fairly simple; the first thing that happens in the loop is the -pulse message is sent to each timed component (ATM, the CPU and PPU). The CPU only receives the -pulse message every third cycle, as the CPU runs at 1/3 the speed of the PPU; this will give cycle-exact accuracy. The other part of giving cycle-exact accuracy was accounting for the fact that each CPU instruction actually takes multiple cycles to execute, and making sure the correct data, address, and control lines are set for each cycle. I spent a lot of time trying to figure out how I could do this, and came up with a pretty decent solution, I think.

The actual CPU itself has a timing control unit that keeps track of where the instruction is in its processing. I used the same idea in my emulated version; the CPU is kept in a static state between pulses, and each time a pulse is received, the next cycle is executed and the CPU is kept in state. I was actually able to easily handle the slight overlap in instruction (the next instruction is fetched as the current finishes executing); it was very easy when I realized that the CPU still only had one data latch and one address bus, so I could still only grab one piece of information at a time. So, while the last instruction is executing, I’m getting the opcode for the next instruction, then I reset the cycle counter to 1 instead of 0, signifying that the instruction is already stored in the instruction register and ready for execution.

In order to cut down on overhead, I came up with what should be an overhead-light “addressing” solution. Basically, there’s two components to each opcode, the addressing mode and the operation itself. So, what I ended up doing was making two arrays, one for the addressing mode and one for the operation. The opcode itself is just a simple 8-bit byte, so I can use the value of the byte as the index of the array; for example, if the opcode is $EA (which happens to be the No Operation code), I can look up addr_modes[0xEA] and instructions[0xEA].

But, you may ask, what ARE those arrays of? Well, I figured out early on that the Objective-C messaging overhead would probably be too much for this task. So I went searching for an alternative. I had originally thought to just write it in straight-up C with Core Foundation, but in the end I came up with a better solution. Objective-C is a strict superset of C–that means any C code works in an Objective-C environment, and that Objective-C is completely based off of standard C components. I was able to use this fact to realize that somewhere in there, there must be pointers to all of these methods. Cocoa specifies the IMP type (implementation pointer) that points to the implemented methods, that can then (with a couple of normally hidden arguments) be called as normal functions. So I was able to typedef a couple of custom types, and each array is an array of pointers to the functions. So, when the CPU receives a pulse, it runs addr_modes[opcode](), which starts the process of retrieving data, and then calls operations[opcode]() when it’s time to do the dirty work.

As soon as I have a chance to test the code more and clean it up a bit (as well as comment it some more) I’ll post a link to the source, since it can probably explain what’s going on far better than I can.

Well, since I’m currently being kept awake by my upstairs neighbors (who have apparently conspired to keep me awake a lot lately), I guess an update is in order.

• Making progress on CocoNES. Finished the initial code for the NES core, minus the audio processing unit. I think I came up with a fairly slick solution that fits the code neatly into the Objective-C/Cocoa framework while still being able to cut out the overhead on some repetitive operations. More on that in another post.
• I have my second concert with Masterworks Chorus this weekend. I’ll be singing the solo movement 17 from Brahms’s Liebeslieder-Walzer. It’s a lovely tenor solo… too bad I’m not a tenor. I’ve managed to almost convince myself I could pass for a lyric baritone, though. At the right time of day. In any case, as long as my voice cooperates it should be fun. I enjoy singing it, it’s a lovely movement, it just hinges on how my G4 and A4 are feeling that day. If you HAPPEN to be in Omaha this Saturday, you should stop by the Strauss Center at UNO and take a listen.
• Hockey season has started. I’m making generous use of NHL Center Ice. Watched most of Minnesota’s season opener on Saturday (except for when I was fighting with my routers), and caught the end of another game last night. Minnesota’s looking really sharp this year, and Marion Gaborik hasn’t figured much into that, which is a really good thing, because I’m guessing that he will no longer be wearing a Wild uniform by Christmastime. Fuck him, if he wants to be greedy there are plenty of other great players out there who realize that Minnesota is the envy of the league as far as market and culture, maybe beaten out only by Detroit. Doug Risebrough did a bang-up job this summer bringing in Antti Miettenen (who had one goal in the opener and two last night) and Marc-Andre Bergeron.
• I’m finally working on some new music, a different setting of a poem that I already set in college and wasn’t really happy with the result of. I’m shopping around for a digital piano; Yamaha has a new line of home digital pianos that are really tempting. I need to work on my piano… I’d love to teach private lessons once we get a place of our own, but I won’t be able to do it fumbling around on the keyboard.
• World of Warcraft 3.0 was released yesterday. All sorts of cool new shit. I’m forcing myself to NOT get up and play it right now and throw my sleep schedule even more out of whack.

I think that’s about it.

Well, I think I’ve come up with a more than suitable solution for CocoNES’s CPU emulator. It will remain an Objective-C class to facilitate variable scope limiting and other object-oriented goodness, but will take an advantage of a low-level method of NSObject that will return a method implementation pointer, which is basically a pointer to the actual C function that a method is built on. When the CPU object is initialized it will create a C array of these pointers with the index of each instruction being the same as the opcode for that instruction, so I can do a simple opcodes[current_opcode](); to run the opcode.

The CPU object will have an instruction counter that is incremented with each cycle of an instruction; each instruction will contain a switch() block that will take it to the correct place in the execution, so I can synchronize the CPU and the PPU. Basically I’m trying to make it act like the real thing, where the state is held until the next clock pulse. Then I can do the cycle on both the PPU and CPU, and make sure the correct data is on the data and address buses for the next clock pulse.

Colin’s comment on my last post about CocoNES got me thinking, and now I’m strongly leaning toward abandoning Cocoa for the 2A03 and 2C02 parts and writing them in straight-up C with Core Foundation. This should help keep the overhead low while still letting me insert the cores easily into the virtual machine and ultimately the Cocoa shell.

My only concern about following that method would be the threading. I’m still hammering out the details of how I want that to work. There are two things that seriously complicate matters: first, each instruction takes multiple clock cycles. Secondly, like most 8-bit MPUs the 2A03 (6502, for all intents and purposes) has some minor parallelism going in where for most (but I don’t believe all) instructions the opcode for the next instruction is fetched while the current instruction finishes execution. My main concern is that I need to have the correct address and data on the buses at the right time; that’s probably the most complicated part of this whole endeavour until I need to do optimization. I already know for sure I’m going to launch one thread for the entire virtual machine so it doesn’t block the event loop. Do I want to launch separate threads for the 2A03 and 2C02? Do I need two threads to account for the parallelism in the 2A03? If so, how do I go about that?

I will say though that my investigations into CF (thanks again, Colin!) have given me one good idea. I was originally planning to use a switch() block to decode the opcode, but now I’m thinking I can make an array of pointers to functions, since it looks like I’ll be using pure C for the core. That will seriously cut down some branch work, and should be very easy to implement since 1) all opcodes are void functions with no arguments and 2) opcodes are just 1-byte numbers, so I can read the opcode and voila! Array index!

OK, all you Objective-C programmers out there… riddle me this.

I’m working on CocoNES. At the moment I’m writing the code that reads in the ROM file and sorts the data into various variables that can be read from. Each NES ROM has an arbitrary number of 16KB program ROM banks. I need to make a multidimensional C array that is a class variable based on the number of ROM banks, but I’m having trouble figuring out how to go about it. Here’s what I’ve thought through. I haven’t actually tried any of this yet, I don’t have the patience right this second to try it all:

1. The first thing I thought was just making an NSArray. The problem is is that I’m only storing simple bytes in each element, and NSArray won’t accept primitive elements. I could do the conversions, but I’m pretty sure the overhead would kill me.
2. Then I thought of going with the NSArray idea and instead of using simple byte elements, making an NSData object for each bank and then doing the data accesses using the getByte: method of NSData. This may be a workable solution, but I still think the Objective-C overhead may kill the speed too much, as this would be called every single clock cycle of the emulator, and twice every third cycle (The CPU runs at 1/3 the speed of the PPU). OUCH!.
3. So, at this point, it’s became evident that the ideal solution is just a C array that I can access using romArray[address]. However, I’m pretty sure that just declaring a variable in the class header (char[][] rom) won’t work, as C’s array support is primitive and needs to know the length of the array when it is declared.
4. The last step on this journey took me to the point of only declaring the array pointer in the class header and then creating the array in the initWithROMFile: method. The only problem is, I’m fairly sure that the array would be wiped out when the method completes execution.

Any thoughts, o ye programmers? Just so you know what kind of constraints I’m working with there, I’m attempting to make this a cycle-perfect emulator. The CPU runs at about 1.78MHz and the PPU runs at about 5.36MHz. I’d like this emulator to be able to run on the slowest available multi-core Intel Mac, so a 1.67GHz Core Duo. This means I need to crank out each cycle of the PPU within about 310 clock cycles on the Mac, and that’s including all of the background tasks.

It’s been awhile since I made an update on my programming, mostly because I haven’t had the time or energy to devote to it lately. However, I have started to get the bug again recently, and have been working.

StudioMan is sitting on the sidelines for the moment. I got a ways into it and realized that the interface still wasn’t as useful as it needed to be. I keep struggling with that in that program. I learned a lot working on it, and when I can come up with a UI design that I’m happy with I’m going to give it another shot.

Beyond StudioMan, I’ve begun work on two other projects. The first is a weather application for iPhone. Currently Weatherbug is the best thing available, and it’s… well… blah. My plan is to make it a nice, clean, standard interface, with a list of locations at the top of which is your current location. For each location there will be current data, forecasts, radar, and watches/warnings. I plan to put warning notifications in also; i doubt I’ll have a release before Apple implements that as I’m still learning the iPhone ropes.

The second project is a NES emulator written from the ground up in Objective-C and Cocoa. This stemmed from my new hobby that I’m going to write about in a subsequent post, but it’s been a real fun challenge. A few days ago I finished a rudimentary 6502 core in Java. It steps through and correctly executes instructions, and reads and writes memory. However, it’s not a cycle-perfect core; it just takes the opcode and the data, does what it needs to do, and puts the data where it needs to be without regard to how many clock cycles the real chip takes. I’m going to need to dig even deeper into the guts of this to figure out how each instruction is executed in a clock-for-clock basis, as there are some very exact timing issues on the NES. I’ll go into more detail in a later post. In addition to the challenge of figuring out the guts of the NES, I’m also learning new things on the modern side; I’m definitely going to need to learn about multithreading to keep the emulator running without binding up the user interface, and more about graphics and input devices. It should be a very good project to learn from.

I’ve created the first page with some basic information on each project that will be updated as time goes on. If you hadn’t guessed by my decision to use “Pages” as one of the main headers at the top, my intention is to make even more pertaining to my various interests.