Thanks for the Memories

When I program, I try to follow the following pattern: get it working, get it working correctly, then if necessary get it running fast. Premature optimization is one of the bigger problems that programmers face. Often optimized code is hard to read and is the ideal spot for bugs to lurk. Making premature optimization even a worse habit is far too often you end up spending time optimizing the wrong code (not the thing that is actually causing the program to run slow) or are optimizing code that you are going to be replacing later. This is why optimizing after you have finished something makes the most sense.

After writing my C++ memory system for my emulator project, I realized that I really didn’t like the code. Several professors that I have had would call this code smell. The thing is, I really didn’t know why I didn’t like the code, just that it didn’t feel right. The subconscious is really good at determining when something isn’t right but feeds this information to the conscious mind in the form of vague feelings. I have learned that it is best to try and listen to these feelings and work out what your subconscious is trying to tell you.

My initial thoughts on the problem were that the code was not going to be efficient. With an emulator this could be a big concern as poor performance on memory operations would reduce the overall performance of the emulator. This lead me to thinking about other ways I could handle the memory and realized that I was prematurely optimizing the problem. This, however, may be a case where that is a good thing. The memory subsystem will be used by everything in the emulator so making sure the interface is locked down is important.

The big issue with the 2600 memory management is that I need to track reads and writes. If I only had to track writing, then memory could be a fast global array with only writes needing to be handled through a function. This got me researching the various 2600 bank switching schemes to verify if any need to handle switching on a read. The most common bank switching scheme does the switch on a LDA instruction so that approach will not work. As tools for refactoring code have improved immensely making such drastic changes to the code later may not be that big of a deal, so I decided to leave things alone and port the existing code to Kotlin.

While re-writing the code in Kotlin, I realized that I may be over-complicating things. In C++, the cartridge loader class would be passed to the A2600 class (the machine) which would then call the cartridge loader install code which would tell the A2600 which memory manager to use. The A2600 - specifically the TIA emulator and the 6502 emulator - would access memory by calling the MMU class and if the code resulted in a bank switch then the MMU would call the cartridge loader to adjust the banks. By having the memory accesses go through the cartridge and having the MMU built into the cartridge (it could still be a separate class but don’t think that is necessary at this point) things are much easier as this picture shows. This change should make any future optimization easier alieving me of most my conserns.

While I am now starting my disassembler, or at least writing the test for the disassembler, next week will be a postmortem of my Halloween game which will be released this weekend. It is a port of a really old “game” that I did  and even though it is pretty low on the polling results it is a cute game and would be easier to port now than later (more on why next week).

The Kotlin Decision

Just like there are a number of JavaScript replacement languages, Kotlin is a Java replacement language which produces JRE bytecode which is compatible with the Java language. What got Kotlin on the roadmap was Google announcing full support for the language on the Android platform. The Android course I took in university was Java based which is okay. I am one of the few(?) programmers out there that don’t mind Java but do wish it was less verbose, compiled to JavaScript (or preferably asm.js), and could be compiled to native code. These are the things that Kotlin does, along with better type safety. This sounds to me like an ideal language and with it becoming increasingly popular among Android programmers it may take off meaning future work potential.

What I do when I want to learn a new language is skim through some of the books on the language get an idea about the basic syntax of the language and then find a small but real project to attempt to do in that language. Having a real project for a language really tells you a lot more about a language than books will and lets you know if a language is one that you can tolerate using or if it one of those languages that you will only use if you are being paid to use it, such as COBOL. I have in the past had the problem of having way too many projects going on at the same time. I still have a bad habit for this but am going to try and keep my personal projects down to two which at the moment are my re-write of Flash Game Development and my emulator/Coffee Quest 2600 project that I am developing on this blog. This means that if I want to learn Kotlan, I either have to wait until the book is finished or switch the language that I am using for developing my emulator in.

As there is only a hundred lines of code written for the project, now would be the ideal time to switch languages. It would also let me develop code for the web (JavaScript) while also working in the JRE and on Android devices. The problem is that part of the reason I decided to go with the emulator project was to get my C++ skills back up to a useful level. There is a third option, being to develop the emulator in both C++ and Kotlin and see how well the languages compare for such a task. As C++ is a system level language it should win hands-down but if native Kotlin is comparable in performance then that may speak to the future direction for my personal projects.

So, tonight I am setting up my Kotlin development environment and porting my existing code over to Kotlin. I will then start working on the disassembler portion of  the project in Kotlin. I have a really interesting way of doing the disassembly that will also be very helpful when I get around to writing the 6502 interpreter. Once I have finished the disassembler portion I will then port the code to C++ and then make an assessment as to if I want to continue developing in two languages or pick which language I wish to stick with.

So my decision is not to make a decision. This is probably a good decision as it will give me exposure to the Kotlin language so even if I ultimately drop it for C++ I will know whether it is an appropriate language for projects such as Coffee Quest. My Coffee Quest port, a future project, was going to be a port of the Java code into a language that could be compiled into JavaScript so it can run on the web as well as stand alone. I had been thinking of porting to C++ then using emscripten to generate asm.js code but if Kotlin works out then the Kotlin route may be the easier approach. Worst case I waste a bit of time prototyping my emulator in a different language but as this is a hobby project anyway that is not much of a loss.

Friday the 13th

I do not like the code that I wrote and am also considering switching this project to Kotlin as my test project for that language so am going to hold of discussing it this week and instead make an announcement. On Friday the 13^th I will be updating my Spelchan.com site to have a less-ugly look. I will also be posting the first ported Blazing Games title, which will be 13² spikes.

Why that day? After all, doesn’t a horror movie franchise claim that this is an unlucky day? Well, porting games is drudge work and I consider it a horror so what better day than that. I am using Adobe Animate CC for the porting but am thinking that it really is not worth the price so will probably be switching to using direct Create.js code once I finish the games I am porting for the upcoming revision of my Flash Game Development book.

The first few games that I have ported went smoothly being easier to port than I feared yet nowhere near as easy to port as I had hoped. Animate CC converted the vector graphics and tween animations to create.js code for me, but none of the ActionScript was ported over requiring me to re-write the code myself in JavaScript. This is not overly hard as most of the Flash API has equivalent Create.js calls, but remembering to put this in front of all class scoped variables was a bit of a pain and often was the cause of any errors in the game. The speed of the games isn’t that great but I am waiting for the WebGL version of Create.js to be officially released before I start playing with that.

Some readers may have noticed that said I have finished porting several games, not just 13² spikes. My plans are to post one port a month for sure and additional posts of games when it is the appropriate occasion, (so yes, there will be a Halloween game). On Wednesdays where I have not made significant progress on my emulator, or at least don’t have new emulator topics to discuss, I will have a short progress report and apologize for my slow development time by posting another game that I ported.

My current porting plans are to finish the 10 games from my Flash book and then look at the poll results on BlazingGames.com to see what bigger series (right now One of those Weeks or Coffee Quest) is more desired then go with one of those larger projects doing smaller holiday games as appropriate. This plan is not set in stone so could change based on factors outside of my control.

Next week I will either be explaining my switch to Kotlin decision or reviewing why I think that my memory emulation code sucks. I do want to play around with emscripten but Kotlin does look like a real interesting language and may actually be a good language for tablet and web development, with work being done on a native compiler to boot. Tough decision ahead for me. See you next week.

Emulating Memory

The 2600 emulator is going to need memory. As it is based on the 6502 processor, we know that at most it has 16 bits worth of memory which is very little for modern processors. The obvious solution then is the following code:

unsigned char memory[65536];

Sadly, it is not going to be that easy. This is for several reasons. First, the 2600 used a cheaper version of the 6502 which only had 13 address lines not 16 so only 8192 bytes were addressable. Making this even worse is the fact that only 12 of these were for the cartridge, so cartridges were limited to 4096. Some of you are probably thinking, “Wait a second, Bill, weren’t there 8K, 12K, and 16K cartridges for the 2600?” Yes, there were. This leads to the real problem with the above approach.

Because of the memory restrictions of the cartridges, developers who needed more memory for increasingly complex games had to come up with ways around this. The solution that was used was several different bank-switching types of cartridges. The idea here is that a chip on the cartridge would act as a go-between giving the console different memory based on certain actions by the program. The memory management unit could detect things like reading or writing to a certain address and would use this to determine which bank of memory would be in place. This means that we are going to need to be able to know when memory is read or written to so we can handle such situations.

The next issue is the fact that cartridges were ROM. You cannot write to ROM.

As is common with common with computers, some memory is often mapped out to hardware devices so you communicate with this hardware by reading and especially writing to memory within a certain address range. This is how you set up the TIA chip for displaying things on the screen. There are a few other IO operations that also work this way (though I believe they are handled by different chips).

So emulating memory is not going to be that easy. My initial plan is to break up memory into a cartridge loader and a MMU class that can be overridden to support several types of bank-switching schemes. The cartridge loader would be responsible for determining which MMU to use and then giving the MMU the ROM data. There could be different cartridge loaders as well, and I plan on having two. The first would be a very basic file-based loader that would be used during development and would simply load the ROM file from the hard drive. Emscripten, the tool that I am using to compile C++ into asm.js, does let you load files but does so using a virtual file system. This is a bit of a pain so another cartridge loader which would be more web-friendly and be designed to so that I don’t need to deal with virtual file systems to change cartridges on a web page.

This project is being developed relatively live. This means that I am writing this as I work on the project. I am hoping I can get a few articles ahead of what I am posting but do want to keep what I post on this blog accurate to what I am going through as I develop this project so that readers can learn from both my successes and my failures. Tonight I am going to start coding and hopefully next post we will finally start seeing some of the code.