One of the big reasons I was interested in this job in the first place is now being phased out.

Oh well, I guess I’ll just add it to the pile of things to consider every day when I start thinking about how sick and tired I am of working nights.

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.

more animals

This is the saddest thing I have heard in a very long time:

(CNN) — The Dallas, Texas, school district laid off hundreds of teachers Thursday to avoid a projected $84 million deficit.

[...]

The district laid off 375 teachers and 40 counselors and assistant principals Thursday, and transferred 460 teachers to other schools within the district.

Read the full article at CNN.

What makes this worse is that I’d make a fair bet that the majority of those teachers are art, music, and other “non-essential” subjects. What I want to know is, how do you make an error like that and still have your job? Sickening. Because of somebody’s math error, these students are going to suffer for the rest of their lives.

I was reading through iFixit’s disassembly of the new MacBook, and found this little gem, in reference to the new battery latch which is not a coin-turn one like the old ones:

“For those hurt by the financial crisis, a coin is no longer required.”

So, I’d kind of like to incorporate a few “widgets” into the design… just a few little icons, like the current weather, a Minnesota scoreboard, maybe something with World of Warcraft… I’m just having trouble figuring out where to stick them without ruining the design.

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!