We have the last of the games for the TG-16 launched purchased and they should be here soon. The last five games we intend to put up before launch are: Aero Blasters, Air Zonk, Devil's Crush, Neutopia 2 and Parasol Stars. That will bring the total up to twenty. It's a small launch, but the original TG-16 only had a little over one hundred titles in the US, so it's still a good percentage of the total. I hope to have everything put together and launch the first Monday in June. That being the 7th.
Once it's out there I want to start putting up TG-16 and N64 games at least once a month. We have got to get ourselves in a position where we can start adding more games more quickly. We ran into some unexpected expenses this month and it put us back a bit. Lord willing, June will be different.
There wasn't much news this week I admit. I ended up out of the office most of the week. Hopefully I will have more news next week, lol.
Everyone have a great weekend!
Friday, May 28, 2010
Friday, May 21, 2010
More Games
This was an exciting week game-wise. We added five new titles to the TG-16 Beta. They were as follows: Dungeon Explorer, Galaga 90, Neutopia, Ninja Spirit and Vigilante. We are getting closer and closer to an actual launch. I want to have twenty titles and enough copies to go around before we make it public. Lord willing, we'll have gotten what we need together by the end of the month.
We also put up our first new N64 games since launch. I plan to start putting them up a little more regularly. We may have to slow down on the GBA for a while. We're going to do our best to increase the total number of games we're putting up. Like so many things in life we have to priorities. Still, inch by inch we're getting better and better.
Mathias sent me a few new revisions of the firmware for the Retrode this week. He has greatly improved his TG-16 support. It works as is, but he keeps making it better and better. Any of you serious collectors out there need to check the Retrode out. He has only made a limited number so far. On top of working great they are going to be serious collectors items in time.
So much for this week! Everyone have a great weekend!
We also put up our first new N64 games since launch. I plan to start putting them up a little more regularly. We may have to slow down on the GBA for a while. We're going to do our best to increase the total number of games we're putting up. Like so many things in life we have to priorities. Still, inch by inch we're getting better and better.
Mathias sent me a few new revisions of the firmware for the Retrode this week. He has greatly improved his TG-16 support. It works as is, but he keeps making it better and better. Any of you serious collectors out there need to check the Retrode out. He has only made a limited number so far. On top of working great they are going to be serious collectors items in time.
So much for this week! Everyone have a great weekend!
Friday, May 14, 2010
A Change of Pace
I've decided that I am probably going to just start posting on Fridays for a while. The things we are working on at the moment don't generate enough to talk about three times a week. The plain truth is that Console Classix is having to dig in and let a little time pass. We just launched the N64 and, Lord willing, the TG-16 is right around the corner. We have got to get our game purchasing up to full speed and start getting more new games up.
I know this might seem like a no brainier, but it takes a little more planning that you might imagine. It's something I hope to have all worked out by next month. After we're getting games up like we should we are going to wait until we've filled these systems out before we launch another one. I was hoping we could get rolling a little faster, but it's just not feasible at the moment.
Still, patience is a virtue. We're all going to have a chance to work on it because time is the main solution here. So, until we get the ball rolling a little faster I am probably going to just stick with an end of the week wrap up on Fridays.
I know this might seem like a no brainier, but it takes a little more planning that you might imagine. It's something I hope to have all worked out by next month. After we're getting games up like we should we are going to wait until we've filled these systems out before we launch another one. I was hoping we could get rolling a little faster, but it's just not feasible at the moment.
Still, patience is a virtue. We're all going to have a chance to work on it because time is the main solution here. So, until we get the ball rolling a little faster I am probably going to just stick with an end of the week wrap up on Fridays.
Monday, May 10, 2010
More on the TG-16
The good news is that we have more games on the way. So far we've got the following: Galaga 90, Neutopia, Neutopia 2, Vigilante and Ninja Spirit. It's not a long list, but every step is another step. I plan on placing a few more bids this week. I admit that I'm waiting for deals. I want to get as much bang for our buck as we can. Lord willing, we will get enough up to kick the TG-16 off early next month. Also, I've gotten one complaint that the control setup is backwards. I want to know if any of you other beta testers are getting that problem.
Speaking of the N64, (well we weren't, but let's do) I hope to get some more games up for it soon. We've had a lot going on and it's been hard to get into a good rhythm. I want to put games up for it once a month kinda like we do with the GBA once a week. I want to put up more obviously, still, you get the idea. We'll be playing it by ear, but hopefully we'll get things moving along and get some more games up soon.
Speaking of the N64, (well we weren't, but let's do) I hope to get some more games up for it soon. We've had a lot going on and it's been hard to get into a good rhythm. I want to put games up for it once a month kinda like we do with the GBA once a week. I want to put up more obviously, still, you get the idea. We'll be playing it by ear, but hopefully we'll get things moving along and get some more games up soon.
Friday, May 7, 2010
The Art of Emulation – Part 3
In my last couple of posts I briefly explained that emulation is simply taking code written for one platform and making it run on another. This is done by translating the input to the native format, completing the correct processing and then translating the output. This explanation is necessarily lacking in details. If it wasn't it would be a book not a blog post. All this is just a very cursory overview.
To wrap this all up I decided to talk a bit about my personal method of coding an emulator. To start with I consider it best to bring the emulation down to the lowest possible level. For instance, I don't think about how I would emulate an Atari 2600 I think about how I would emulate the 6502 processor. Each piece of the Atari 2600 can be emulated separately. Once each of these pieces is complete they can be “assembled” into a working Atari 2600 emulator. For those of you who are familiar with Object Oriented Programming you understand the concept.
Doing things this way has several benefits. First, it allows you to test each component and do you best to bang out bugs while the situation is less complicated. Second, as each of the pieces are completely separately, several coders can work on the same emulator with very little communication. Once a standard I/O is agreed on each programmer can work on their section independently. Lastly, once a particular chip has been successfully emulated it can be used in other projects. For instance both the Atari 2600 and the NES use a 6502 processor (there are slight differences... but still...). Many systems used the Z80 processor. Once these chips have been developed they can be used across multiple emulators.
Keep in mind all these ideas are being presented by a man who has never successfully completed an emulator, but the theories are sound. Console Classix plans to begin pursuing it's own emulation project in the future. We just have to line up more help. I hope this post has got a few people out there considering the idea.
To wrap this all up I decided to talk a bit about my personal method of coding an emulator. To start with I consider it best to bring the emulation down to the lowest possible level. For instance, I don't think about how I would emulate an Atari 2600 I think about how I would emulate the 6502 processor. Each piece of the Atari 2600 can be emulated separately. Once each of these pieces is complete they can be “assembled” into a working Atari 2600 emulator. For those of you who are familiar with Object Oriented Programming you understand the concept.
Doing things this way has several benefits. First, it allows you to test each component and do you best to bang out bugs while the situation is less complicated. Second, as each of the pieces are completely separately, several coders can work on the same emulator with very little communication. Once a standard I/O is agreed on each programmer can work on their section independently. Lastly, once a particular chip has been successfully emulated it can be used in other projects. For instance both the Atari 2600 and the NES use a 6502 processor (there are slight differences... but still...). Many systems used the Z80 processor. Once these chips have been developed they can be used across multiple emulators.
Keep in mind all these ideas are being presented by a man who has never successfully completed an emulator, but the theories are sound. Console Classix plans to begin pursuing it's own emulation project in the future. We just have to line up more help. I hope this post has got a few people out there considering the idea.
Wednesday, May 5, 2010
The Art of Emulation – Part 2
In my last post I was using the NES as my example system. I'm now switching to the Atari 2600. I didn't give any real details on the NES and I know a bit more about the Atari 2600. So, changing gears shouldn't throw any of you off the scent. I'm going to go into a little more detail here so that when I wrap all this up by explaining what Console Classix plans to do in the future it will all make sense.
The CPU is the Central Processing Unit within a computer system. It has a limited number of instructions that it can complete. These instructions are known as Op Codes. If you take a look at the 6502 processor that was in the Atari 2600 and compare them with a modern PC you will find, in many cases, identical Op Codes. For instance, ADC is used to add two numbers with carry. Both the Atari 2600 and a modern PC have to be able to this. The trick is that Op Codes are actually accessed by using a one byte number (for the 2600) to represent the code's location in the CPU. The numbers within the two CPUs are not going to match. (The following numbers are arbitrary guys, so if you're a 6502 expert ignore them, I'm not explaining this to you...) So, say ADC is 0x65 on the Atari 2600 and 0x3E on your home PC. If you just tried to run an Atari game on your PC it would run into 0x65 and instead of running ADC would do something totally different. The result being that it wouldn't work!
Now, some emulation authors have simply remapped the Op Codes in order to emulate the CPU. They create a kind of go between that takes the Atari 2600 codes and translates them for the PC. So when it runs into 0x65 in Atari software it translates to 0x3E and does it's thing. This is an elegantly simple method and is very fast. However, it comes with a number of limitations that I won't go into now. (Just run with the idea that rewriting the functionality of the Op Code in something like C++ is more flexible.) Whatever method the emulator uses it has to give the same results as ADC would when it runs into that Op Code. In the case of the CPU core I wrote for our Atari 2600 emulator (that may be released one day) I used C++ and provided the same results as the expected Op Code.
This has been a very long way of explaining that you have to grab the data that is destined for an Atari 2600 CPU then process it and return the same results. It's a complicated subject, but I am honestly trying to keep it simple. When you look at the data on an Atari 2600 cart a large portion of it is just calls to Op Codes one byte at a time. So you grab the data read off the cartridge and start with the first Op Code (0x65 or what have you) and then step through one at a time doing what each one is requesting to be done.
More before long...
The CPU is the Central Processing Unit within a computer system. It has a limited number of instructions that it can complete. These instructions are known as Op Codes. If you take a look at the 6502 processor that was in the Atari 2600 and compare them with a modern PC you will find, in many cases, identical Op Codes. For instance, ADC is used to add two numbers with carry. Both the Atari 2600 and a modern PC have to be able to this. The trick is that Op Codes are actually accessed by using a one byte number (for the 2600) to represent the code's location in the CPU. The numbers within the two CPUs are not going to match. (The following numbers are arbitrary guys, so if you're a 6502 expert ignore them, I'm not explaining this to you...) So, say ADC is 0x65 on the Atari 2600 and 0x3E on your home PC. If you just tried to run an Atari game on your PC it would run into 0x65 and instead of running ADC would do something totally different. The result being that it wouldn't work!
Now, some emulation authors have simply remapped the Op Codes in order to emulate the CPU. They create a kind of go between that takes the Atari 2600 codes and translates them for the PC. So when it runs into 0x65 in Atari software it translates to 0x3E and does it's thing. This is an elegantly simple method and is very fast. However, it comes with a number of limitations that I won't go into now. (Just run with the idea that rewriting the functionality of the Op Code in something like C++ is more flexible.) Whatever method the emulator uses it has to give the same results as ADC would when it runs into that Op Code. In the case of the CPU core I wrote for our Atari 2600 emulator (that may be released one day) I used C++ and provided the same results as the expected Op Code.
This has been a very long way of explaining that you have to grab the data that is destined for an Atari 2600 CPU then process it and return the same results. It's a complicated subject, but I am honestly trying to keep it simple. When you look at the data on an Atari 2600 cart a large portion of it is just calls to Op Codes one byte at a time. So you grab the data read off the cartridge and start with the first Op Code (0x65 or what have you) and then step through one at a time doing what each one is requesting to be done.
More before long...
Monday, May 3, 2010
The Art of Emulation – Part 1
So, how does emulation work? What exactly is emulation? This subject may or may not be of much interest to the few readers of this blog, but it is of interest to us here at Console Classix. Because of this I've decided to discuss it. At least, I've decide to give a cursory overview here. Many of our fans are programmers and we are always looking for people to help us do what we do. I hope that some of these coding fans may take a look at this and think to themselves “That sounds easy! I could help with that!” Still, my motivations aren't entirely selfish. Anyone who is interested in the subject needs a place to start. The small amount of information I put up here may help them get the ball rolling. I will warn you guys that this may get a bit long. There are some interesting things in it, you just have to plow through and try to keep your brain from going numb.
To start with, emulation is the process of making one computer system act like another (at least for the sake of this explanation). When you consider a modern PC you have several elements that make the machine useful to people. A computer allows input, processes data and then provides output. These are the first three elements we have to look at when we begin to plan an emulator. The forth element is software. The magic of software is that it takes the three hardware elements and makes the machine do something useful. So, for an emulator to do anything it has to be able to read software for one platform and make the hardware of a different platform act the correct way.
We have to start by looking at each of the three elements.
Input: The NES has two controllers that have a D-Pad and four buttons. The modern PC has a least a keyboard and mouse and possibly has a number of controllers plugged into it as well. The NES controls place input at a certain memory block. So, when you push the A button it updates a memory location that the game programmer can read. In order to use PC control to represent this an emulation coder has to catch the input and translate it into the form the NES uses. We'll come back to this, for now you just need to understand that you catch the PC input and translate it.
Processing: The NES has a CPU just like the PCs our clients use. I am going to give some detailed information on the CPU so we'll skip it for now. The NES also has video and sound processors. They take the data coming from the game and prepare it to be displayed on a TV and played on TV speakers respectively. The emulator has to make the PC process data in exactly the same way as the system being emulated.
Output: Here the emulation author has to take the data output by the NES and translate it in order to display the video and play the sound. As I said, this is just a cursory glance. I plan to add some detail before I'm done.
More Soon...
To start with, emulation is the process of making one computer system act like another (at least for the sake of this explanation). When you consider a modern PC you have several elements that make the machine useful to people. A computer allows input, processes data and then provides output. These are the first three elements we have to look at when we begin to plan an emulator. The forth element is software. The magic of software is that it takes the three hardware elements and makes the machine do something useful. So, for an emulator to do anything it has to be able to read software for one platform and make the hardware of a different platform act the correct way.
We have to start by looking at each of the three elements.
Input: The NES has two controllers that have a D-Pad and four buttons. The modern PC has a least a keyboard and mouse and possibly has a number of controllers plugged into it as well. The NES controls place input at a certain memory block. So, when you push the A button it updates a memory location that the game programmer can read. In order to use PC control to represent this an emulation coder has to catch the input and translate it into the form the NES uses. We'll come back to this, for now you just need to understand that you catch the PC input and translate it.
Processing: The NES has a CPU just like the PCs our clients use. I am going to give some detailed information on the CPU so we'll skip it for now. The NES also has video and sound processors. They take the data coming from the game and prepare it to be displayed on a TV and played on TV speakers respectively. The emulator has to make the PC process data in exactly the same way as the system being emulated.
Output: Here the emulation author has to take the data output by the NES and translate it in order to display the video and play the sound. As I said, this is just a cursory glance. I plan to add some detail before I'm done.
More Soon...
Subscribe to:
Posts (Atom)