I have done a lot of work on the cartridge portion of the emulator. Now the system is able to take in the raw rom data from a zipped file (still no support for unzipped roms) and parse the data into the header, program instructions, and pattern tiles. No real emulation of the system is occurring, but we are just steps away from that.
Up until now I have been using the working title JNES. This is not satisfactory. I have decided to create a google code repository for the project. This allows me to store the code and create a wiki I can use to create documentation for the system. However, in order to do that I have to come up with a final name for the system. I am toying with a few ideas. LambNes comes to mind.
The next steps for the system involve writing the code that emulates the cpu. I now have the instructions, so now it's time to start doing something with them. This will likely take a long time. I need to find out a lot about the system. For instance, I need to know what flags exist, when these flags are modified, what instructions are supported, etc. Lots and lots of stuff. This will likely involve lots of testing. I will probably have to create one test case for each instruction just about. I think there's on the order of 100 instructions. I will likely be doing more research on the cpu in the next couple of days and will likely be updating with information regarding my progress. I'm kind of excited to be past the file system stuff.
Saturday, August 28, 2010
Monday, August 23, 2010
Read up a little bit on the INES format, but haven't done a whole lot of the implementation of that. I did, however, download a hexeditor so I could look at my test rom to see what was actually in there and downloaded a known good NES emulator to test the rom. I used Nestopia. The rom seems to work well. I played through to about world 2-3. Those damn jumping fish.
I fixed a few small bugs. I initially was using ZipInputStream.read(). This was loading only the first 500 bytes or so for whatever reason even if I set the read size to the entire size of the file. Rather than inspecting why that was I switched over to using ZipEntry to read the file and am now getting an InputStream via ZipFile.getInputStream. Using InputStream.read appears to be loading the entire file. This is a better design and works, so I'm not curious as to why ZipInputStream did not work.
My test rom contains 40976 bytes. This is a little interesting. The NES itself has 32k of program memory and 8k of character memory. This maps directly to the super mario bros rom, which has 32k of program code and 8k of character code. The additional 16 bytes unaccounted for are the ines file header.
Some of the other roms have additional memory built into them which need to be emulated for the emulator to run them, but I don't plan on implementing that feature right now. If I get the NES running with this standard rom I'll consider new features.
Now that I'm reading the entire file I need to work on supporting the INES file format. This means separating out the header from the program code from the character code. Then I can start work on emulating the CPU. I expect this blog will be a bit more interesting once I start writing the actual emulation. Right now I'm still doing the formative work, which isn't all that interesting.
I fixed a few small bugs. I initially was using ZipInputStream.read(). This was loading only the first 500 bytes or so for whatever reason even if I set the read size to the entire size of the file. Rather than inspecting why that was I switched over to using ZipEntry to read the file and am now getting an InputStream via ZipFile.getInputStream. Using InputStream.read appears to be loading the entire file. This is a better design and works, so I'm not curious as to why ZipInputStream did not work.
My test rom contains 40976 bytes. This is a little interesting. The NES itself has 32k of program memory and 8k of character memory. This maps directly to the super mario bros rom, which has 32k of program code and 8k of character code. The additional 16 bytes unaccounted for are the ines file header.
Some of the other roms have additional memory built into them which need to be emulated for the emulator to run them, but I don't plan on implementing that feature right now. If I get the NES running with this standard rom I'll consider new features.
Now that I'm reading the entire file I need to work on supporting the INES file format. This means separating out the header from the program code from the character code. Then I can start work on emulating the CPU. I expect this blog will be a bit more interesting once I start writing the actual emulation. Right now I'm still doing the formative work, which isn't all that interesting.
Sunday, August 22, 2010
So, I'm successfully loading a rom into some sort of data structure. At this point, this is an array of bytes. In the case of my test rom this is an array of 40976 elements. I'm not completely certain this array is the best data structure to store this data. Nor am I at all certain what all of the data in the rom file means. However, I'm starting to figure it out.
I've been talking about roms a lot without really describing what they are. Roms are essentially a file that represents all of the data for a particular program. In the case of the NES, this would be all of the data from the cartridge that is inserted into the NES. Most of this data represents the program code, but also contained in the cartridge and in the rom file are the 8x8 pattern tiles that make up the visual portions of the game. It appears that most NES roms downloadable from the internet are stored in ines format. INES was an early NES emulator. I don't know very much about how it gained dominance in the NES rom market. However, my test rom appears to be in ines format, so this appears to be the format I will be supporting in my emulator. The .nes file I currently search for in the zipped rom is an ines file.
In a way I feel like I am going about this project backwards. I have not done any planning of the architecture for my code. I am not at all certain what it will look like when I'm done. In fact, I don't have the knowledge necessary to do this planning. Instead, I'm gathering this knowledge a I go. I'm concerned that decisions I make regarding the project without full knowledge will cause some portions to be written poorly and will likely need to be rewritten once I have a better understanding of the project.
bibliography:
http://wiki.nesdev.com/w/index.php/INES -- a nice introduction to the ines file format.
http://fms.komkon.org/EMUL8/HOWTO.html -- I am not reading anything too specific regarding nes emulation yet. This is a very high level guide to emulation.
http://www.cecs.csulb.edu/~hill/cecs497/nestreme/howto.html -- this is a pretty general introduction to NES emulation.
I've been talking about roms a lot without really describing what they are. Roms are essentially a file that represents all of the data for a particular program. In the case of the NES, this would be all of the data from the cartridge that is inserted into the NES. Most of this data represents the program code, but also contained in the cartridge and in the rom file are the 8x8 pattern tiles that make up the visual portions of the game. It appears that most NES roms downloadable from the internet are stored in ines format. INES was an early NES emulator. I don't know very much about how it gained dominance in the NES rom market. However, my test rom appears to be in ines format, so this appears to be the format I will be supporting in my emulator. The .nes file I currently search for in the zipped rom is an ines file.
In a way I feel like I am going about this project backwards. I have not done any planning of the architecture for my code. I am not at all certain what it will look like when I'm done. In fact, I don't have the knowledge necessary to do this planning. Instead, I'm gathering this knowledge a I go. I'm concerned that decisions I make regarding the project without full knowledge will cause some portions to be written poorly and will likely need to be rewritten once I have a better understanding of the project.
bibliography:
http://wiki.nesdev.com/w/index.php/INES -- a nice introduction to the ines file format.
http://fms.komkon.org/EMUL8/HOWTO.html -- I am not reading anything too specific regarding nes emulation yet. This is a very high level guide to emulation.
http://www.cecs.csulb.edu/~hill/cecs497/nestreme/howto.html -- this is a pretty general introduction to NES emulation.
Saturday, August 21, 2010
beginnings
I am creating this blog mostly as a means of logging my progress in a personal project of mine. The basic goal of the project is writing an NES emulator in java which I plan to release as open source. This is a fairly ambitious project. While I've been working as a professional developer for approximately 5 years, I don't know very much about emulation. Also, while I know a little bit about assembly programming, I'm hardly an expert. The majority of my programming experience has been with higher level languages. Couple these things with the fact that I don't know very much about NES architecture and it's plain to see that there's going to be a significant learning curve involved with this project.
This project came to my mind about five years ago. I was reading an article on slashdot. I think it was an Ask Slashdot article in which the writer was a new computer science graduate who had recently graduated and was kind of concerned about how much they didn't know about computer science. They mentioned that they had no idea how emulators worked. This resonated a lot with me. I was a new computer science guy myself who had just gotten hired to do java programming for a place in town. I was a little bit overwhelmed with my new position and like the guy in the article was kind of concerned about how much I didn't know about computer science. One of the guys in the article recommended looking at some open source emulators. This struck me as a great idea. I'm a java guy and I found an open source NES emulator written in java. I think it was called nesticle. I took a look at it, but not so much that I really understood it. There's a significant amount of knowledge that I don't have to truly understand the code. I might understand the general concepts behind what it's trying to do, but I don't understand the architecture it's trying to emulate. It became clear to me that if I wanted to understand what was going on I could either study this code or start writing my own emulator. I recently decided to do the latter. This is a bit foolhardy and definitely unnecessary, but it sounds fun to me right now.
I see this blog as a means of recording my progress and of connecting the project with the world. That said, I really doubt that anybody will be interested in my project. There exist NES emulators. As I've mentioned, there even exist java based NES emulators. Also, emulator guys are pretty talkative. There is tons of documentation concerning how to write emulators. Especially, it seems, NES emulators. The NES is historically significant architecture. It has been emulated again and again by anyone and everyone. My project isn't going to do anything new. It's just going to do it again largely as a personal learning project. This blog is going to record the day to day progress on the project. Maybe someone will come along who is also trying to learn more about programming or emulation and might be interested in what I'm doing. Toward that end, one of the things I'm planning on doing is keeping an extensive bibliography of the materials that I read in order to educate myself on the information necessary to get the project off the ground. That will probably be of more use to such a person than this blog and the associated code.
I wrote the very first lines of code for the project today. The portion that I have written now largely just opens up a zipped rom, searches for a .nes file, and reads that file. As I understand it, there are two main functions that an NES emulator has to do. The first is to load the rom, the second is to run the code pulled from the rom. Loading the rom is fairly easy. As it stands right now, the code looks for my test rom (super mario bros.), which is hard coded into the main class. I have not yet bothered to code an interface that will allow the user to pick a rom to load. Nor have I coded in support for roms that are not zipped. My test rom is zipped, so this is what I am sticking with for the time being.
There are several things on the agenda:
1. I have not ran my test rom in a known good emulator. Therefore, whether or not my rom is a good test case is questionable.
2. I want to find a decent and free code repository service so that I can store the code for other people to see it if they want.
3. so far as coding goes, I'm not storing the code that I am reading from the rom into anything yet. I'm actually just writing it to the console. My understanding is that I need to read the rom in a fixed increment. 16 bits maybe? All of the instructions are 16 bits, I think, but I'm not quite certain. Also, I'm not sure how the format of the rom is laid out. I am not certain which portions of the rom are sprites, which are instructions, and which are music. I know absolutely nothing about how the music is encoded. It ought to be pretty interesting to figure that out.
4. This blog is great for the day to day recording of my progress, I'm not sure it will fit the bibliography I want to write. We'll see.
Anyway, thanks for reading.
This project came to my mind about five years ago. I was reading an article on slashdot. I think it was an Ask Slashdot article in which the writer was a new computer science graduate who had recently graduated and was kind of concerned about how much they didn't know about computer science. They mentioned that they had no idea how emulators worked. This resonated a lot with me. I was a new computer science guy myself who had just gotten hired to do java programming for a place in town. I was a little bit overwhelmed with my new position and like the guy in the article was kind of concerned about how much I didn't know about computer science. One of the guys in the article recommended looking at some open source emulators. This struck me as a great idea. I'm a java guy and I found an open source NES emulator written in java. I think it was called nesticle. I took a look at it, but not so much that I really understood it. There's a significant amount of knowledge that I don't have to truly understand the code. I might understand the general concepts behind what it's trying to do, but I don't understand the architecture it's trying to emulate. It became clear to me that if I wanted to understand what was going on I could either study this code or start writing my own emulator. I recently decided to do the latter. This is a bit foolhardy and definitely unnecessary, but it sounds fun to me right now.
I see this blog as a means of recording my progress and of connecting the project with the world. That said, I really doubt that anybody will be interested in my project. There exist NES emulators. As I've mentioned, there even exist java based NES emulators. Also, emulator guys are pretty talkative. There is tons of documentation concerning how to write emulators. Especially, it seems, NES emulators. The NES is historically significant architecture. It has been emulated again and again by anyone and everyone. My project isn't going to do anything new. It's just going to do it again largely as a personal learning project. This blog is going to record the day to day progress on the project. Maybe someone will come along who is also trying to learn more about programming or emulation and might be interested in what I'm doing. Toward that end, one of the things I'm planning on doing is keeping an extensive bibliography of the materials that I read in order to educate myself on the information necessary to get the project off the ground. That will probably be of more use to such a person than this blog and the associated code.
I wrote the very first lines of code for the project today. The portion that I have written now largely just opens up a zipped rom, searches for a .nes file, and reads that file. As I understand it, there are two main functions that an NES emulator has to do. The first is to load the rom, the second is to run the code pulled from the rom. Loading the rom is fairly easy. As it stands right now, the code looks for my test rom (super mario bros.), which is hard coded into the main class. I have not yet bothered to code an interface that will allow the user to pick a rom to load. Nor have I coded in support for roms that are not zipped. My test rom is zipped, so this is what I am sticking with for the time being.
There are several things on the agenda:
1. I have not ran my test rom in a known good emulator. Therefore, whether or not my rom is a good test case is questionable.
2. I want to find a decent and free code repository service so that I can store the code for other people to see it if they want.
3. so far as coding goes, I'm not storing the code that I am reading from the rom into anything yet. I'm actually just writing it to the console. My understanding is that I need to read the rom in a fixed increment. 16 bits maybe? All of the instructions are 16 bits, I think, but I'm not quite certain. Also, I'm not sure how the format of the rom is laid out. I am not certain which portions of the rom are sprites, which are instructions, and which are music. I know absolutely nothing about how the music is encoded. It ought to be pretty interesting to figure that out.
4. This blog is great for the day to day recording of my progress, I'm not sure it will fit the bibliography I want to write. We'll see.
Anyway, thanks for reading.
Subscribe to:
Posts (Atom)