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!

There is a bug in the comment AJAX; some change between 2.5.1 and 2.6.2 changed the location of a file. I’m looking into it; be aware that comments ARE coming through, the view just isn’t updating correctly.

//edit: Fixed. I enabled permalinks, apparently in 2.6.2 if permalinks are enabled it refuses to read a standard query string when deciding what post to read. I’ll work on getting permalinks back with working comments.

//edit2: Fixed the template to figure out the actual permalink address to read from. Wouldn’t you know it if WordPress doesn’t have a template tag to return a relative permalink. I may have to put in a ticket for that. In any case, permalinks and comments are now working in relative harmony.

It’s hockey season again.

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.