#83220 - thegamefreak0134 - Sun May 14, 2006 7:24 am
You may have heard me talking about creating a GBA emulator,just for debug purposes? Well, I do indeed want to create an emulator as a life-long programming goal, but seeing as how the DS is the new handheld of choice, I would like to start there. Now, I understand that this is no easy task, so don't go reminding me of that. I want to do it very badly, and want no discouragement. (cause that will probably work, and we don't want that.)
I would like to know three things:
(1) Where can I find general info about emulating a processor on a PC in general? I reckon I will need to start here so I can get the general gist of things before working on whatever one the DS uses.
(2) Where can I find the most current info we have about the DS? Where specifically can I find info that would be useful for creating demos and such?
(3) What information will I need to know by way of actually reading the ROM files for the commercial games I will need to test? (I have them already, not asking for that.)
I realise my new-ness on this whole thing, but this is something that I would really like to do. Besides, I figure that by having the DS development community helping me out on it, I would be able to do a good job of emulating it accurately.
I am of course very new to emulation, never having taken on the idea before. I have a lot of logic floating around in my head about how it would need to be done, from an outside point of view, but I know little about actually implementing processor commands, or reading ROM files. If anyone here can help me take this on, I would greatly appreciate it. I may not be the best in the world, but I do want to give this a good effort, if nothing else. Thank you.
-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83233 - waruwaru - Sun May 14, 2006 8:38 am
You might want to take a look at DeSmuME.
Probably want to memorize NDSTech wiki too.
_________________
DSLua - a scripting language for your DS!
#83252 - agentq - Sun May 14, 2006 2:49 pm
You could always take a look at my Gameboy emulator source code for some help on general emulation techniques. I also have the project writeup somewhere on my hard disk which describes a little on how I wrote it. It's in Java, but it's still going to be fairly familiary if you know C++.
http://www.millstone.demon.co.uk/download/javaboy
#83274 - HyperHacker - Sun May 14, 2006 11:24 pm
I suggest you start by emulating something simpler like the NES or Game Boy, then move on to more complex systems. Also, you'd probably be best making a GBA emulator, and once that works, add the DS features.
#83282 - agentq - Mon May 15, 2006 12:11 am
You might want to try a CHIP-8 emulator first. It's something you should be able to complete in a week, and would give you a taste for emulator development before you dive in.
http://en.wikipedia.org/wiki/CHIP-8
#83449 - thegamefreak0134 - Tue May 16, 2006 1:53 pm
Alright, to make y'all happy, I am currently working on the CHIP-8 emulator. I already have it showing screens after a considerable number of commands were handled, and I should have the thing finished by tommorrow. A week? I should have this finished within 2 days.
Interestingly enough, I'm doing this in visual basic. It's rather difficult, as it took me a very long time to realise that VB reads variables from files backwards, inverting the order of the bytes. Once I got that worked out, it got through the first couple of lines with no prob. I'm going to do this right and give it a proper memory viewer and probably a disassembler of some sort as well.
Once I have this finished (soon) I'l come back to my original question. I'll probably take on a graphics only emulation project of one of the older GBs to get started, but I really want my main focus to be on the DS. I'm suprised, as this is turning out to be a lot easier than I thought! Yay!
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83455 - SteveH - Tue May 16, 2006 2:15 pm
If you think that's easy - and emulating a processor is easy I had to do it for a uni course, and learn asm at the same time.. - then you will have a lot of fun getting everything else working.
Oh the good old day's of uni, having to design a new CPU, then emulate it on a 68000, as well as in hardware... Gah the nightmares are returning :D
#83683 - thegamefreak0134 - Wed May 17, 2006 8:54 pm
Well, (as a quick report) I've got the stupid thing actually running some games. Whoopie. Unfortunately, getting to play pong over and over again isn't too impressive. It's nowhere near perfect, doesn't play many games due to lack of supported opcodes, has no sound, and has this minor issue of not recognizing a single key, but overall I've got the general idea down. I could of course fix it up by using directX for graphics, sound, and actual input, but that comes later. Getting VB to do binary operations is a pain in the (obscene word) let me tell you. I think I'll stick to visual C++ from now on, thanks.
I've seen how it's possible to go off and update stuff by the instruction, but everyone knows that's no fun. I'd like to tackle something a little more advanced than an old computer. Can someone point me toward the old GB specs? (Black and white will do for now.) I think if I can get that up and running (taking the time to actually allow input and sound) I will have an accomplishment worthy of starting my orignal quest. Thanks!
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83691 - SteveH - Wed May 17, 2006 9:56 pm
Check out www.devrs.com for al your GB info including:
02/06 - GameBoy based CD Player v1.0 - Posted by: Jordi
A GameBoy based CD Player with a CD-ROM ATAPI unit. Plug your GameBoy and your old CD ATAPI drive to the interface board and you will have a nice CD Player. Information page is in spanish.
WHA?!?!?!?!
#83718 - HyperHacker - Thu May 18, 2006 1:19 am
You are NOT going to write a reasonably fast DS, or even Game Boy emulator in VB. Believe me, I tried.
#83725 - tepples - Thu May 18, 2006 1:46 am
Is this VB6, or is it one of the .NET versions? If the latter, then VB.NET is as powerful as C#, which in turn is as powerful as Java, which was used to make BoycottAdvance Online.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#83740 - gladius - Thu May 18, 2006 3:19 am
VB.Net is plenty powerful. I dislike the syntax, but the underlying architecture is .NET, not the old VB interpreter. Check out http://forwardcoding.com/projects/gbaemu.html for my GBA emulator in .NET (C# though) with source. Another piece of source to look at never hurts :).
That being said, emulation is still a task where bit twiddling and pointer math can make a big difference. But having been on both ends of the spectrum, doing an all assembler emulator and a C# one, I must say I prefer the development experience in C# ;).
#83749 - PhoenixSoft - Thu May 18, 2006 7:39 am
You will probably be able to get it running at a decent speed, the main problem I see would be that it may use up a lot more RAM than a C++ version would, due to the low amount of control over memory management.
#83805 - thegamefreak0134 - Thu May 18, 2006 5:36 pm
The site given is cool, and would be a great resource if I were coding in asm for the GB. Unfortunately, I need to do just the opposite. Nintendo has already done the coding part, I need to know what the asm part actually does. Something to the effect of this instruction (in hex) does these things to this memory using these registers. Thus, I will also need the basic memory info and such, but I can probably find that myself.
I do not intend to code the thing in VB.NET. I will use that for primary testing, but I intend to do the main program in C++ .NET. This will give me much greater controll and flexibility over my memory. Course, I have to figure out how to do file handling in C++, but that couldn't possibly be any harder than VB. (maybe even easier.) Thus, the speed should improve. I also don't intend to do the implementation the same as the CHIP-8 thing. I had it literally checking every instruction for every single command possible, which was slow as heck mind you. I was also using the VB graphics routines, which are even _slower_ than heck. Needless to say, I know where the improvements need to be made.
I will do some searches and try to get this running. Can someone who's done this let me know what games are going to be the easiest and most difficult to get running? (on the GB, that is) Thanks!
-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83845 - SteveH - Thu May 18, 2006 10:58 pm
The actual part of that site I provided that you need to look at is:http://www.devrs.com/gb/docs.php#docsmisc
and in that section:
2000/02/29 - GB Cribsheet - Posted by: Jeff Frohwein
Now a full-color version of Otaku's cribsheet for GB/GBC programming is available. The cribsheet is basically a few sheets of paper that when printed out contain a massive amount of information in a very area.
2000/02/29 - GB Cribsheet in HTML - Posted by: Jeff Frohwein
An HTML version of Otaku's cribsheet can be found here.
2000/05/01 - GB/GBC Opcode Summary - Posted by: Jeff Frohwein
Details the opcodes, the flags affected, and the clock cycle timing of each code.
Here is a more detailed Text and HTML version.
Or even the following docs:
2000/04/04 - Thomas Scherrer's Z80 Support Page - Posted by: Jeff Frohwein
Quite a bit of information on the Z80 processor can be found here. The Z80 is very similar to the processor used in the GameBoy.
2004/10/25 - Z80 User Manual - Posted by: Vegard
Complete instruction set reference for the Z80 processor (similar to the one used in DMG/GBC)
All you need to do is look around that site and you will find what you need...
#83920 - thegamefreak0134 - Fri May 19, 2006 5:33 pm
I see. So THIS is the one that has the z80 processor. This should be a lot simpler now, as I already know pretty well how to code in z80 asm. I would just need to adapt to the bios calls and memory on the GB. OK, I will take a look at the docs there, they should help out a lot.
Is there info somewhere on how all of this compiles down to hex? And possibly how the file will look on a low level? This is going to be possible, I'm so excited!
-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#83994 - agentq - Sat May 20, 2006 1:55 am
A reference I used extensively when writing my GB emulator was the Pan docs:
http://www.work.de/nocash/pandocs.htm
I wouldn't expect writing a GB emulator to be as easy as CHIP-8. The CPU is a lot more complex, then you've got to look at the graphcis, sound, interrupt handling, cartridge mappers and a whole lot of other stuff. Although I found it great fun to write.
Tetris is probably the simplest game to start with.
#84025 - HyperHacker - Sat May 20, 2006 5:55 am
Tetris actually has the worst code I've ever seen. That may be good, though; if it runs that it's doing pretty well. ;-)
#84033 - tepples - Sat May 20, 2006 6:31 am
Does Tetris DX in monochrome mode have better code?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#84157 - HyperHacker - Sat May 20, 2006 8:33 pm
Probably, I never looked at it.
#84452 - thegamefreak0134 - Mon May 22, 2006 5:37 pm
Yay! this looks like what I need. Thanks a bunch. OK, so that means that my small time goal is to get tetris up and running. Awesome.
Last question I promise. Is the ROM file for any given game basically an exact copy of the cartridge memory? Or is there some other junk I will have to read from it (or skip) to get to the stuff the emulator will need to use? I think the docs you provided tell me about the ROM header and all, I just need to know if reading the file will be the equivilent of looking at the cartridge directly. Also, there are files with different extensions. Will this have any effect on their contents? (I haven't looked at any docs in detail, so if this is already covered then sue me.)
Thanks again sooo much. I realize that this is kindof a dissapointing title, since I haven't even gotten to the DS part yet, but I promise I will. If the mods feel the need to move the file, so be it. Just let me know where it ends up.
-thegamefreak0134
PS: Thanks again!
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#84469 - tepples - Mon May 22, 2006 7:08 pm
| thegamefreak0134 wrote: |
| Is the ROM file for any given game basically an exact copy of the cartridge memory? Or is there some other junk I will have to read from it (or skip) to get to the stuff the emulator will need to use? |
It depends on the platform being emulated. With Game Boy, as with GBA, the "header" is part of the ROM, not skipped as in the NES. Every bit in a .gb or .gbc ROM file is a bit in the ROM chip.
| Quote: |
| Also, there are files with different extensions. Will this have any effect on their contents? |
The extensions .gb, .sgb, and .gbc mean exactly the same thing: a bit-for-bit copy of the content of a Game Boy ROM chip. Game Boy Color and Super Game Boy modes are actually denoted by bits in the header, which the SGB BIOS and the GBC BIOS read.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#84590 - thegamefreak0134 - Tue May 23, 2006 3:13 pm
Hmm.. I was looking at the "hex dump" of the nintendo logo, and to tell the truth I can't see how they get a nintendo logo from that. All I can make out of it is garbage. (Although it is definately the right garbage, as I checked the site against several commercial ROMs.) Is it done this way on purpose? Or perhaps is this used with a mask or something similar to produce the actual image? I realize that my emulator need not care what this data contains, but I still eventually want to fake the intro logo as an option. (and thus fake the garbage that comes from a bad header.)
Also, does someone know if it's possible to set priority in directDraw? (new at this, remember?) If so, I could just use the image functions there for sprites and save some processing time.
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#84603 - SteveH - Tue May 23, 2006 5:25 pm
What do you mean by priority?
And DirectDraw does not have any idea about sprites, and with the way sprites are stored in the 1D mode, you will be better off writing your own sprite handlers...
#84625 - HyperHacker - Tue May 23, 2006 7:39 pm
On Game Boy the Nintendo logo is several tiles (I think 8 or 16) stored in monochrome format. The bootROM converts them to 4-colour and copies them into VRAM; I believe the tilemap is defined in the bootROM. On GBA I think it's the same, but compressed. However, the compression header is not stored in the ROM, but rather in the BIOS, for 2 reasons:
1) It's always going to be the same, so there's no point taking up the extra space.
2) If the compression header were malformed it could overflow a buffer and/or overwrite code in memory.
BTW, Game Boy (even Color) only has a bootROM, not a full-blown BIOS. Super GB has one though.
_________________
I'm a PSP hacker now, but I still <3 DS.
#84634 - thegamefreak0134 - Tue May 23, 2006 8:54 pm
By priority, I mean which sprites appear in front. In the old GB mode, sprites have priority by the X coordinate (left is on top) and then by OAM position, while in the color mode there is the option to specify sprite priority, much like in the GBA.
I realised that I probably shouldn't use DirectDraw, mainly because I am going to have to write my own sprite handlers anyway. Although few games use it I'm sure, it is possible I believe to change a sprite's position every scanline, thus making DirectDraw most likely unable to handle the change. I'll be coding the entire screen draw routine by the pixel, thank you very much. (And looking at the logic, it doesn't look that hard either.)
I still need to do DirectInput. Turns out, my VB form isn't handling the key states mainly because Windows isn't handling them right. It's doing that whole repeating key thing rather than just registering the button as down. (stupid windows.) Unless there's a way to turn that off with code, I'll stick to DirectX. (Provided, of course, I can get it to work at all... Should be simple but it's being a pain instead.)
-thegamefreak0134
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#84678 - HyperHacker - Wed May 24, 2006 2:39 am
You really only need to set the appropriate bit in the keydown event, and clear it in keyup. It shouldn't matter if keydown fires multiple times. (I may have those names wrong; haven't used VB in ages.)
_________________
I'm a PSP hacker now, but I still <3 DS.
#84696 - SteveH - Wed May 24, 2006 8:41 am
No DirectDraw does not have any priority stuff.
You will be better off writing your emulator in C++ using DirectDraw and DirectInput natevly, instead of using VB which IMHO is not good for games, mainly as it's a very slow lnguage to run (even GDI games are slow in VB).
I'm currently in the design stage of a suite of tools to help design levels for games, and the first thing I've done is look at the 2D hardware limitations, 8x8 tiles, flip's, palettes, etc and the only thing I can think of doing is writing the whole thing in C++ using either GDI or DirectDraw to blit the tiles onto the window. Ether way it will be fun...
#84699 - DekuTree64 - Wed May 24, 2006 9:06 am
Yeah, best to just use a plain old array of memory for the screen. When I was toying around with a GBA emulator a while back, I used OpenGL to display my buffer. The setup code is pretty short if you want it.
Perhaps I'll try my hand at GBC too, once I have a bit more free time. What I really wanted to do before was a SNES emulator on DS, but I'm a bit lazy for that to get very far :)
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#84719 - doublec - Wed May 24, 2006 11:22 am
The OmegaGB site, a gameboy emulator written in Haskell, has pointers to a number of GB resources:
http://www.mutantlemon.com/omegagb/devlog/
#84720 - Mighty Max - Wed May 24, 2006 11:31 am
On the first read, i thought "OMG Haskell? This is nuts!"
But on the second thought, yes, sound like the perfect system to emulate a cpu on. I mean, you actually define the cpu's function, and not how to emulate it.
Cool thing.
_________________
GBAMP Multiboot
#84746 - thegamefreak0134 - Wed May 24, 2006 3:43 pm
| Quote: |
| You will be better off writing your emulator in C++ using DirectDraw and DirectInput natevly, instead of using VB which IMHO is not good for games, mainly as it's a very slow lnguage to run (even GDI games are slow in VB). |
Actually, I'm told that in .NET (which I use) VB code compiles down to the same base code as C++, so the only real benefit of C++ is if I'm comfortable with it. I am, but thats not the point. Also, I've already determined that DirectDraw is not the way to go, as I just need to do pixel stuff. I already have info on how to quickly draw pixels in VB, so it's not a problem.
| Quote: |
| You really only need to set the appropriate bit in the keydown event, and clear it in keyup. It shouldn't matter if keydown fires multiple times. (I may have those names wrong; haven't used VB in ages.) |
You know, you might have a good point there. My other program was clearing the keys every instruction, and attempting to re-read them. I suppose if windows doesn't send a message that fast (and why should it? stupid cheap piece of...) then the logical solution is to read it that way. You are a genius. I should go fix my other thingy now!
I think I have enough info to actually get the thing started. However, I have one last question. There is only a certain length of memory that the games use to access things on the cart. There is a register that is used to access the other memory banks in the cart as well. Does increasing this register simply increase the cart memory offset by he ammount of memory that can be read at one time?
What I mean is, do I read the info from the ROM like:
Requested Byte + (BankSelect * Banksize)
? Or do I have to do something different? The docs are a little unclear about this.
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#84788 - dXtr - Wed May 24, 2006 8:20 pm
| thegamefreak0134 wrote: |
| Actually, I'm told that in .NET (which I use) VB code compiles down to the same base code as C++, so the only real benefit of C++ is if I'm comfortable with it. |
Correction.. exchange VB with VB.NET and C++ with C++.NET (or managed C++) and the statement should be correct
_________________
go back to coding and stop screaming wolf :)
#84792 - thegamefreak0134 - Wed May 24, 2006 8:32 pm
Grrr... you know what I meant.
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#85356 - Helius - Mon May 29, 2006 9:21 am
#85542 - thegamefreak0134 - Wed May 31, 2006 4:17 pm
OK, naturally I'm having some issues with the Pandocs. They're wonderfull, but a bit confusing in two areas.
(1) In the CPU instruction set, I'm confised about how they're showing the opcodes. What do the xx, rr, and nn mean? It never specifies. Also, if an instruction has no specific hex identifier, how do I know to execute it?
Take this example:
ld r,r xx 4 ---- r=r
ld r,n xx nn 8 ---- r=n
ld r,(HL) xx 8 ---- r=(HL)
ld (HL),r 7x 8 ---- (HL)=r
ld (HL),n 36 nn 12 ----
ld A,(BC) 0A 8 ----
ld A,(DE) 1A 8 ----
ld A,(nn) FA 16 ----
(Pandocs)
Note the instructions at the top. What on earth will xx look like in hex? I assume some of it is supposedc to be replaced with a register, which leads me to other questions. If an instruction requires a certain register, how would that be done in hex? (ie, what's the hex representation of every register?)
I understand that nn is supposed to be a number, usualy a byte, correct?
(2) Look up again. The timing on the rigt hand side (the ones divisible by 4) are throwing me a little. I understand them, but I don't understand what I can use them for. Is there a list of how long it takes the gameboy to do things like draw pixels and wait in vblank that is measured in the same units as these timings? He's kinda unclear on what the units are throughout the docs.
Any help clearing this up would be greatly appreciated. Thanks a lot!
-thegamefreak
EDIT- Well curse filters. Apparently my spacing on the documentation is gone. Y'all know where to find it, or can understand this, right?
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#85546 - thehive - Wed May 31, 2006 5:21 pm
| Quote: |
(1) In the CPU instruction set, I'm confised about how they're showing the opcodes. What do the xx, rr, and nn mean? It never specifies. Also, if an instruction has no specific hex identifier, how do I know to execute it?
|
r refers to a register (A, B, C, D, H, L, etc).
rr refers to a register pair (BC, DE, HL, etc).
nn refers to the next byte in memory after the instruction.
xx in the pan docs is simply a placeholder for the real hex values.
You'll need to get hold of the Z80 instruction set to determine the hex values of every instruction (note the GB has a cut down Z80 instruction set, so refer to the Pan docs for the actual differences).
| Quote: |
2) Look up again. The timing on the rigt hand side (the ones divisible by 4) are throwing me a little. I understand them, but I don't understand what I can use them for. Is there a list of how long it takes the gameboy to do things like draw pixels and wait in vblank that is measured in the same units as these timings? He's kinda unclear on what the units are throughout the docs.
|
The timings given are the CPU clocks or cycles that each instruction takes to execute. You will need to count these to determine when an IRQ or interrupt occurs. For example the pan docs state that a complete screen refresh occurs ever 70224 clks, so in simple terms you start to draw the screen after counting this many clocks.
#85855 - Helius - Fri Jun 02, 2006 5:32 pm
#86209 - Two9A - Mon Jun 05, 2006 2:34 pm
Only just found this thread, so apologies for partial resurrection. I've been procrastinating on a DMG emulator for over a year now, so I'm not too great a guide on that side, but when you get to the GBA/DS, feel free to flick through the source to DSemu and "DSemu: next generation".
doublec maintains the DSemu codebase now, but it was always a horribly hacked-up mess; DSemu-ng has a little design principle behind it, so should make more sense to you. Each emulator is about 30k lines of the programming language concerned (C or C++) last time I checked.
You'll enjoy the ARM instruction set: much more orthogonal than Z80, a dream for an assembly coder. (Nightmare for an emulator, mind.)