|
Writing My Own Emulator From Scratch
#137585 - 01/10/08 07:15 AM
|
|
|
Well what I'm about to embark on was something I mentioned that I would like to see "In Mame" in 2008.
But I got to thinking. Why rely on someone else to start it? I can start on my own. Surely there's enough information out there on the information super highway that can get me through a lot of things. Plus, I figure I can ask "dumb" questions here and get lots of good help that will assist in filling in those darn blanks. I'm also thinking of asking some questions which I may actually know (or think I know) the answer to or at least have a good idea, but still ask in order to hopefully generate some good conversation.
I will be using the (partly completed) guide on how to convert schematics to an emulator that I found on Dan Borris' website as a guide to help as well. That document is located here: http://www.atarihq.com/danb/files/zarzon.txt
So will it work? Will I stay motivated enough to finish it out? I don't know. But if it does, we'll have a nice solid blue-print for others to use.
So let's see if we can get started...
Every other "How do I write an emulator?" that I've ever seen usually has the statement of making sure your first step is to choose a game you like. At the same time, it is usually recommended to not choose something that is way too hard for a so-called "first-timer".
With that in mind, I've chosen Centipede. The only scary thing about this is I seem to remember the Pokey chip wasn't easy to figure out for sound...so maybe for now we'll just leave the sound out.
Okay, so I've chosen the game...now what? Well, I might want to start looking for documentation. The first and probably most obvious place to start would be the PCB. I don't have access to that, but a good ol' google search turned up a nice pile of schematic diagrams that should be most helpful.
Finding the processor is fairly simple. There's a chip on one of the diagrams that says 6502 on it. Some knowledge of CPUs would be nice for those who don't know here...or at least the ability to search around and figure it out. So now that I know that the game uses the 6502 processor, I can begin looking for documentation on this as well.
Now, if memory serves correctly, the 6502 can be of variable speeds. This is where my first stumbling block comes along. I understand that there is a clock circuit that has to determine this. Of course, following the zarzon schematics in Dan's example made sense, but I didn't see the same type of circuit on the Centipede's schematic. I mentioned before that I wasn't the best at schematics so maybe it is trivial. Are there a certain "set" of commonly used clock circuits that were used in arcade games? In other words, assuming we are not "cheating" by looking at someone else's emulator or we don't have a document that happens to give us that information, is there a sure-fire way to determine this?
Tutors now welcome to chime in!
ArcadeGamenut
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#137588 - 01/10/08 07:48 AM
|
|
|
Timing's easy, at least at first  Given the clock of the emulated CPU and the frame rate of the game, you simply run the CPU for (clock / rate) cycles each frame.
So for a 1 MHz CPU (common in 6502 games) at 60 frames per second, you'd run the CPU for 1000000/60 = 16666 cycles each frame. Each time you were done running the CPU is when you'd update the screen, read the keyboard/joypads, and all the other stuff.
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: R. Belmont]
#137628 - 01/10/08 06:26 PM
|
|
|
That makes sense. And it goes with everything else I've read. Now, I did cheat and looked at the Mame Source for centipede (naughty naughty me!) It lists the XTL as 12.096. When you divide that by 8 for the 6502 you end up with 1.512. Also, there is a note that it should be 0.756 when accessing the playfield RAM.
On the Zarzon schematic the clock isn't clearly marked to say "Hey silly...here's your XTL.", but it does clearly show 11.289 which, if I were to cross-reference this with xtl.h would lead me to believe I was looking at the correct thing. I didn't see anything resembling 12.096 on the Centipede schematic. (Did I just miss it?) Is it possible to get this number from the schematic if the number isn't clearly written? Or is the only way to get it (other then finding it documented somewhere else) to measure it directly from the PCB?
ArcadeGamenut
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#137639 - 01/10/08 08:27 PM
|
|
|
> That makes sense. And it goes with everything else I've read. Now, I did cheat and
> looked at the Mame Source for centipede (naughty naughty me!) It lists the XTL as
> 12.096. When you divide that by 8 for the 6502 you end up with 1.512. Also, there is
> a note that it should be 0.756 when accessing the playfield RAM.
>
> On the Zarzon schematic the clock isn't clearly marked to say "Hey silly...here's
> your XTL.", but it does clearly show 11.289 which, if I were to cross-reference this
> with xtl.h would lead me to believe I was looking at the correct thing. I didn't see
> anything resembling 12.096 on the Centipede schematic. (Did I just miss it?) Is it
> possible to get this number from the schematic if the number isn't clearly written?
> Or is the only way to get it (other then finding it documented somewhere else) to
> measure it directly from the PCB?
>
> ArcadeGamenut
A cursory look at the schematic I found online shows the following:
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: Stolistic]
#137663 - 01/11/08 12:10 AM
|
|
|
> A cursory look at the schematic I found online shows the following:
Aha! Nice catch. I bet I missed it because I was spending more time looking at the microprocessor page and was pretty much skipping the other pages assuming they had nothing to do with what I was searching for.
So this should circuit should (somewhere) then connect to pin 37 on the processor, right?
ArcadeGamenut
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#137671 - 01/11/08 01:10 AM
|
|
|
> > A cursory look at the schematic I found online shows the following:
>
> Aha! Nice catch. I bet I missed it because I was spending more time looking at the
> microprocessor page and was pretty much skipping the other pages assuming they had
> nothing to do with what I was searching for.
>
> So this should circuit should (somewhere) then connect to pin 37 on the processor,
> right?
Yeah, assuming that's the clock in (I don't have pinouts memorized). BTW, a 6502 game is an excellent choice for a first-time project. Good taste on your part ;-)
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#137769 - 01/11/08 07:09 PM
|
|
|
Okay, so it's been an interesting past couple of days.
Let me review what's happened so far:
1. We've identified the game we wanted to emulate.
This was centipede. I do have to admit that I actually picked the processor first and then searched around for games that I liked that used that processor.
2. We've located schematics for the game.
3. We've located tons of information on the processor we'll be using. This thing is documented all over the place and their are lots of "emulators" for it out there already.
4. We've begun analyzing the architecture for the game.
This has been the toughest part (for me). If someone were to ask me how to do this then, at this point, I would end up pointing them to the internet. For example, we identified the speed of the crystal, but I don't know how I knew it was the crystal from the schematic. Maybe the schematic I have just isn't the best. (For example, the CPU is on one corner of one page and the page with the crystal is on another corner of another page. This made (makes?) it difficult for me anyway to actually trace where the pin 37 on the 6502 is actually coming from).
I've also glanced ahead just a tiny bit. Even though I'm nowhere near ready to start coding, I still wanted to identify the language I would use to code the whole project. The majority of time it is probably recommended to use C or assembly. But I've decided to see how Delphi will work (Delphi 2005 specifically). I really like using Delphi to prototype applications and there's a wealth of free components out there that can make your life easier. After deciding this, I also came up with a silly name for the project. So for now, it'll be called Delphipede!
I then wanted to really decide if I wanted to write my own 6502 emulator or if I just wanted to use something already written. Two things came into play here. The goal of the project is to learn, but at the same time I still want to keep things simple. So what I'm going to do to start with is go in the middle. I've found the source code to a 6502 emulator written by Neil Bradley. It's written in C. Since, I'm going to use Delphi, I'll be converting this C to Delphi which will give me a real good chance to understand everything that is going on.
ArcadeGamenut
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#138321 - 01/14/08 02:12 PM
|
|
|
> The majority of time it is probably recommended to use C or assembly.
I wouldn't advise assembly unless you know you're going to need to it, like if you want to run an emulator on a gameboy or something.
If you really want to go places, then I'd suggest C or C++
I know someone has done emulators using Visual Basic, but it's not the best tool for the job. I guess it depends on where you want to go with this.
I've been tempted to do something with c#, but not enough to actually do it :-)
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: ]
#138353 - 01/14/08 09:20 PM
|
|
|
> If you really want to go places, then I'd suggest C or C++
> I know someone has done emulators using Visual Basic, but it's not the best tool for
> the job. I guess it depends on where you want to go with this.
I don't know that I want to go anywhere with it. I just want to learn a little more then I already know and if at the same time someone else learns a little too, that'd be great.
I agree that C or C++ would probably be best, but part of me wants the challenge of seeing if it can be done with Delphi. Plus, a lot of examples I find are in C. If I'm forced to evaluate what exactly the C code is doing (especially those where the author decides to code all of his or her variables as A, B, C, D, E, etc with no comments), the more I'm really going to understand what is happening (once I figure it out) and will be able to answer questions from others instead of just saying "I don't know really. I just used .".
Should I stay interested in the project enough, the ultimate goal would be to come up with a FAQ/How-To that someone with reasonable skills could use to walk thru creating their own emulator, participating in the MAME project, etc.
There are several how-to's out there already, but many of them are unfinished or do not go into enough detail in some spots (in order to make the above-mentioned goal possible)...which could be what this project does as well....who knows.
ArcadeGamenut
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#138383 - 01/15/08 01:30 AM
|
|
|
> (especially those where the
> author decides to code all of his or her variables as A, B, C, D, E, etc with no
> comments),
Often if there is a variable with names like that it's because there is a register with that name. Most people wouldn't document it in that circumstance because you ought to be able to figure that out from the code. Anyone looking at cpu cores that doesn't understand how cpus work, at least at the functional level, is pretty much wasting their time.
Picking another language just so you have to rewrite the code seems like a masochistic way of doing things, it's possible to write an emulator in almost all languages. You don't necessarily want to though.
Good luck with it.
smf
|
|
|
|
Re: Writing My Own Emulator From Scratch
[Re: arcadegamenut]
#138706 - 01/16/08 06:27 PM
|
|
|
Well so far not much has been done except for a lot of reading, jotting down notes, etc.
I did find a free direct x component for Delphi last night and managed to get that installed.
I then created a new test project to test a few ideas.
The first thing I did was to create a direct draw surface on the form. From there, I added in code to switch between the window and full screen. As I test, I wrote out "Delphipede" on the surface. That seemed to work well enough. 
For the next part, I created a new unit in order to begin the 6502 emulator. I have a very good idea how this will work, it's just a matter of doing all the tedious typing. To start with, I just wrote part of the init and reset procedures (enough to where I could test the first instruction $4C anyway ). I then wrote a rom load routine and and processed that first description. At this point I didn't actually perform the instruction, but rather just looked up the cycle count, instruction and address mode for the opcode I found and printed it on the screen.
So what remains for me to investigate?
1. How, when I need to refresh the screen, the directdraw surface interacts with the video ram. I was hoping I could just split the directdraw surface into a grid (240x256) and then "write" out the data from the video array as needed. I'll need to read more about how direct x works.
2. The pokey chip...though I may save this for the very very end.
3. Something else I was thinking about when I started typing this....but then forgot as it took me almost 30 minutes to type this (happens when you keep getting interrupted at work ).
ArcadeGamenut
|
|
|
|
|
I've pretty much scrapped the idea of using Direct X for this project. What a major pain in the rear to work with.
On the other hand, SDL seems very good. Clear, concise and down to the point. Further, there's a header conversion for Delphi. With a couple of seconds, I had it creating a window and blitting a yellow pixel in the center of the screen.
Other things I messed with during the 30 minutes I was playing around:
1. Pretty much finished the init routine. Now, all know opcodes are mapped with the number of cycles, the instruction and address mode.
2. Added in the remainder of the program roms into memory. Including adding in the mirror of 310 at the end so that we can determine the program counter during the cpu reset routine.
3. Worked a little bit on the cpu reset for determining the starting address. I've either loaded the wrong rom, loaded it in the wrong spot or my logic is incorrect in doing the arithmetic because a test revealed 4 for the PC. I don't know, but that just doesn't sound correct to me. Maybe because there's no program code at location 4 in memory? I'll have to give this some additional thought next time I look into it.
ArcadeGamenut
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
|
> On the other hand, SDL seems very good. Clear, concise and down to the point.
> Further, there's a header conversion for Delphi. With a couple of seconds, I had it
> creating a window and blitting a yellow pixel in the center of the screen.
Yeah, "raw" DirectX isn't for the faint of heart. SDL wraps everything very nicely.
> 3. Worked a little bit on the cpu reset for determining the starting address. I've
> either loaded the wrong rom, loaded it in the wrong spot or my logic is incorrect in
> doing the arithmetic because a test revealed 4 for the PC. I don't know, but that
> just doesn't sound correct to me. Maybe because there's no program code at location 4
> in memory? I'll have to give this some additional thought next time I look into it.
Mmm, yeah. There's no way a 6502 game would boot at $0004. $0400 or $4000 I'd believe, but not 4 :-)
|
|
|
|
Re: Baby Steps
[Re: R. Belmont]
#139231 - 01/20/08 12:38 AM
|
|
|
> Mmm, yeah. There's no way a 6502 game would boot at $0004. $0400 or $4000 I'd
> believe, but not 4 :-)
If it's centipede that he's emulating ( which I thought he said earlier but maybe I wasn't paying attention ) then it starts at 0x3b04.
This is where something like visual studio is super useful, I'm sure there are alternatives on linux but none of the gnu debuggers I've tried have been any good on windows.
|
|
|
|
Re: Baby Steps
[Re: ]
#139237 - 01/20/08 01:34 AM
|
|
|
> > Mmm, yeah. There's no way a 6502 game would boot at $0004. $0400 or $4000 I'd
> > believe, but not 4 :-)
>
> If it's centipede that he's emulating ( which I thought he said earlier but maybe I
> wasn't paying attention ) then it starts at 0x3b04.
>
> This is where something like visual studio is super useful, I'm sure there are
> alternatives on linux but none of the gnu debuggers I've tried have been any good on
> windows.
Yes, it's Centipede. And that is the correct address. So, the question becomes do you really need to mirror the rom? Or, can you just start the execution from the beginning since the first instruction appears as JSR 0x3b04 anyway?
ArcadeGamenut
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
|
> Yes, it's Centipede. And that is the correct address. So, the question becomes do you
> really need to mirror the rom? Or, can you just start the execution from the
> beginning since the first instruction appears as JSR 0x3b04 anyway?
You need to mirror the ROM at least enough so that the 6502 vectors appear at 0xfffx. I would suggest fully mirroring it from square 1 though - it's not hard to do, and it immediately eliminates one source of potentially hard to trace problems.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Baby Steps
[Re: ]
#139249 - 01/20/08 03:38 AM
|
|
|
> This is where something like visual studio is super useful, I'm sure there are
> alternatives on linux but none of the gnu debuggers I've tried have been any good on
> windows.
He's using Delphi, which AFAIK has it's own debugger. In a case like this, a printf() or equivalent works equally well though - he's probably just missing the high byte of the reset vector.
|
|
|
|
Re: Baby Steps
[Re: R. Belmont]
#139259 - 01/20/08 04:13 AM
|
|
|
> > This is where something like visual studio is super useful, I'm sure there are
> > alternatives on linux but none of the gnu debuggers I've tried have been any good
> on
> > windows.
>
> He's using Delphi, which AFAIK has it's own debugger. In a case like this, a printf()
> or equivalent works equally well though - he's probably just missing the high byte of
> the reset vector.
Turns out the problem was a silly variable declaration being declared as a byte rather then a word. Tada!
ArcadeGamenut
|
|
|
|
|
Well with a little bit of work here and there, progress is being made!
Of course, I can't see anything yet as I haven't done any of the video, but I can have it run through a given number of cycles, see the current instruction along with all of the registers and their values.
One nice thing is I've been able to use the debug build of Mame to verify my cpu core is actually doing what it should be doing.
At this point, there seems to be a problem with pushing (or retrieving) the return address from a jsr instruction. My initial guess without looking at it is that the value I'm calculating for the stack register is incorrect.
Once I solve that, I should (without finishing every instruction in the instruction set) be getting to where I can at least put together a rudimentary video routine.
The audio is still going to come dead last. And at that point, I may just convert the code that it appears anyone who uses pokey uses (or at least it's a variant) to Delphi.
ArcadeGamenut
|
|
|
|
|
> At this point, there seems to be a problem with pushing (or retrieving) the return
> address from a jsr instruction. My initial guess without looking at it is that the
> value I'm calculating for the stack register is incorrect.
>
I forgot to mention that my hunch was pretty much correct. I ended up taking out a sheet of paper and writing out what should be happening and then mapped it out with test data. From there, I rewrote a couple of pieces of the code and it is now working.
Well up to the point that I stopped working on it the other day anyway.
ArcadeGamenut
|
|
|
|
|
> > At this point, there seems to be a problem with pushing (or retrieving) the return
> > address from a jsr instruction. My initial guess without looking at it is that the
> > value I'm calculating for the stack register is incorrect.
> >
>
> I forgot to mention that my hunch was pretty much correct. I ended up taking out a
> sheet of paper and writing out what should be happening and then mapped it out with
> test data. From there, I rewrote a couple of pieces of the code and it is now
> working.
>
> Well up to the point that I stopped working on it the other day anyway.
>
> ArcadeGamenut
Can you submit a patch to mamedev.org? or at least post the changed code?
This would be nice to have fixed in the core.
LN
|
"When life gives you zombies... *CHA-CHIK!* ...you make zombie-ade!"
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9714
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
|
> Can you submit a patch to mamedev.org? or at least post the changed code?
> This would be nice to have fixed in the core.
I don't think you understand - MAME is working fine. He's writing his own CPU core as a learning exercise (something I can't encourage enough for younger would-be emu devs).
|
|
|
|
Re: Progress
[Re: R. Belmont]
#140521 - 01/30/08 04:27 AM
|
|
|
> > Can you submit a patch to mamedev.org? or at least post the changed code?
> > This would be nice to have fixed in the core.
>
> I don't think you understand - MAME is working fine. He's writing his own CPU core as
> a learning exercise (something I can't encourage enough for younger would-be emu
> devs).
That is correct. Well I'm not sure about the younger part...unless you mean in terms of an emulator developer.
I should also point out that if I make it all the way through the to the end (without getting bored, engrossed on another project, etc) I'll probably be more then happy to completely document everything I've done.
ArcadeGamenut
|
|
|
|
Centipede Documentation
[Re: arcadegamenut]
#140801 - 02/01/08 10:19 PM
|
|
|
This isn't really related to the emulator, but I found it quite interesting. Seems like Atarigames.com got ahold of some documents (internal memos and the like) concerning such things as the design of Centipede, field testing and other things.
My only gripe is his watermark sometimes makes the document a bit hard to read. Other then that, neat stuff!
http://www.atarigames.com/page5/page5.html
ArcadeGamenut
|
|
|
|
Re: Centipede Documentation
[Re: arcadegamenut]
#140810 - 02/01/08 11:59 PM
|
|
|
Great stuff. I posted news of the rest of the update over on the news submission board.
|
|
|
|
|
> I should also point out that if I make it all the way through the to the end (without
> getting bored, engrossed on another project, etc) I'll probably be more then happy to
> completely document everything I've done.
While finishing off your project isn't a bad goal, at least you are getting some experience of the concepts that go into an emulator. If you then end up working on something like MAME, where you don't necessarily need to write a CPU core, you'll still understand how it works. Which when you're trying to figure out why something won't run then it's nice to know how a CPU works.
|
|
|
Index 
Threaded 
Writing My Own Emulator From Scratch
Reply
[Re: 
Given the clock of the emulated CPU and the frame rate of the game, you simply run the CPU for (clock / rate) cycles each frame.
