Trotterwatch
New member
I think he meant to say "fast understanding". Good luck on your project btw
An Incredulous Undertaking
- Thread starter BGNG
- Start date
OP
BGNG
New member
- Thread Starter
- #24
I now about the processors of the Nintendo DS, but I don't know about the CPU Memory Map or component functionality. When that information becomes available, I'll be able to code for the DS. And if an emulator or flash card comes out, I'll be able to use my code. (-:
But that's in the future. I'm currently writing an NES emulator in Windows where I WILL be able to test it.
But that's in the future. I'm currently writing an NES emulator in Windows where I WILL be able to test it.
remmy
reenignE
I'm inclined to agree with you about assembly. I started programming back on a Tandy EX 2000 in BASIC and moved logically up the ladder from there, assembly's instruction set is so simple to work with and with that knowledge, you can pick up a lot of usefull tips from the diassembling of existing software. I have no doubt at all that you will be able to create emulators for the DS considering that it's underlying cores consist of ARM946E-S(67MHz) and ARM7TDMI (33MHz) processor, both of which you can download techincal documentation for from arm's website. As you state, handling memory will be the thing to overcome until some kind souls tear open the system and give us the goodies.
[Edit} Today is your lucky day. The work has already been completed and I now have a complete memory map of the Nintendo DS. Leave a private message and I will send it along to you.
[Edit again]
Wow. Even more good news, I have the complete ROM File System specification information as well.
[Edit} Today is your lucky day. The work has already been completed and I now have a complete memory map of the Nintendo DS. Leave a private message and I will send it along to you.
[Edit again]
Wow. Even more good news, I have the complete ROM File System specification information as well.
Last edited:
OP
BGNG
New member
- Thread Starter
- #26
Uhbuh... uhbuhbuhbuh... *PM*
EDIT:
In your experience, would you say that VBlank is an approperiate real-time timer to use for the timing of the older processors?
My idea is to use the constant 60hz of the VBlank to keep emulation from going too fast... That is, count the number of cycles the emulator's virtual processor takes to perform its operations, and stop emulating and wait for VBlank in the event it covers all the possible cycles per 1/60 second for the emulated processor.
For example, the NTSC NMOS 6502 processor of the NES pumps out nearly 1,876,713 cycles per second. So 1/60 of that would be about 31,279 cycles; the number of cycles per VBlank. I figure it would be a good way to time the NES, which is slow enough that delicate timing can actually affect its execution. If I count the number of cycles per instruction that a REAL NES would take, I can stop emulating on the DS when it reaches that 31,279 mark and wait for VBlank before resuming.
EDIT:
In your experience, would you say that VBlank is an approperiate real-time timer to use for the timing of the older processors?
My idea is to use the constant 60hz of the VBlank to keep emulation from going too fast... That is, count the number of cycles the emulator's virtual processor takes to perform its operations, and stop emulating and wait for VBlank in the event it covers all the possible cycles per 1/60 second for the emulated processor.
For example, the NTSC NMOS 6502 processor of the NES pumps out nearly 1,876,713 cycles per second. So 1/60 of that would be about 31,279 cycles; the number of cycles per VBlank. I figure it would be a good way to time the NES, which is slow enough that delicate timing can actually affect its execution. If I count the number of cycles per instruction that a REAL NES would take, I can stop emulating on the DS when it reaches that 31,279 mark and wait for VBlank before resuming.
Last edited:
remmy
reenignE
It's the same as limiting frames per second in the creation of a video game, however on a console, there is no need to worry about running at the same speed on different systems since you are working with the same CPU on every system.
Here's a little example that I used. NOTE: This was for the creation of a game, but the idea is similar.
From there, I would set up a timer grabbing the Ticks (cycles) per second and making that the gametime. Now for my purposes (the game), I would never need this framerate to be more than 25 frames per second so would limit that cyclic count to my framerate and from there I would just:
As for the memory map, it's quite interesting. I've finished a framework for an emulator, but the hard part (after a little research) is going to be dealing with the ARM7. From what I see, it is used for the "PDA-Like" features of the DS. More than likely for the touchscreen and what not. Considering that the GBA and the Gamecube are both ARM in nature, I'd say very little modification will be needed to existing devkits for homebrew to begin.
The most interesting thing I have seen so far is how the DS handles 3D routines. It draws them directly to the LCD. There is no frame buffer.
Here's a little example that I used. NOTE: This was for the creation of a game, but the idea is similar.
Code:
volatile int fps = 0, cfps = 0, gametime = 0;
void fps_update()
{
fps = cfps;
cfps = 0;
}
void gametimer()
{
++gametime;
}From there, I would set up a timer grabbing the Ticks (cycles) per second and making that the gametime. Now for my purposes (the game), I would never need this framerate to be more than 25 frames per second so would limit that cyclic count to my framerate and from there I would just:
Code:
while(gametime < 0)
;
while(gametime > 0)
{
// Perform logical steps.
}
++cfps //increment the frame here
// Drawing routines.As for the memory map, it's quite interesting. I've finished a framework for an emulator, but the hard part (after a little research) is going to be dealing with the ARM7. From what I see, it is used for the "PDA-Like" features of the DS. More than likely for the touchscreen and what not. Considering that the GBA and the Gamecube are both ARM in nature, I'd say very little modification will be needed to existing devkits for homebrew to begin.
The most interesting thing I have seen so far is how the DS handles 3D routines. It draws them directly to the LCD. There is no frame buffer.
Last edited:
OP
BGNG
New member
- Thread Starter
- #28
You lost me a bit with your examples. What I'm saying is that, to limit the emulation of the slower systems from emulating too fast (more than their native clock speed), I could use the VBlank as a constant timer to halt emulation and resume when the time is approperiate.
EDIT:
In addition to the touch screen, the ARM7 might also be used to control the microphone and wireless communication.
EDIT:
In addition to the touch screen, the ARM7 might also be used to control the microphone and wireless communication.
remmy
reenignE
Indeed.
That's what I was trying to get at with the example code there. Limiting the VBLANK. I am half dead from working on the Framework, however it already supports the dual screens, so hopefully I can pass everything along soon and let the emulation authors go to work. Most of the framework was already completed by another individual, I am simply adjusting it based on this new information.
That's what I was trying to get at with the example code there. Limiting the VBLANK. I am half dead from working on the Framework, however it already supports the dual screens, so hopefully I can pass everything along soon and let the emulation authors go to work. Most of the framework was already completed by another individual, I am simply adjusting it based on this new information.
remmy
reenignE
haha
Don't mind me tonight. I will eventualy be able to type what I mean again.
And no problrm at all. I hope that from this we can get a better understanding of how the DS works. The next step is obviously BIOS related. And as you can see from the document, it will not be as easy to grab as the GBA was. The BIOS is the last thing called on a DS game, where I'd imagine it will be called first when running a GBA game. Testing time.
[Edit]
A note that I should add:
ITCM stands for Instruction Tightly Coupled Memory. It is likely the 32kb memory located on the processor chips themselves.
Don't mind me tonight. I will eventualy be able to type what I mean again.
And no problrm at all. I hope that from this we can get a better understanding of how the DS works. The next step is obviously BIOS related. And as you can see from the document, it will not be as easy to grab as the GBA was. The BIOS is the last thing called on a DS game, where I'd imagine it will be called first when running a GBA game. Testing time.
[Edit]
A note that I should add:
ITCM stands for Instruction Tightly Coupled Memory. It is likely the 32kb memory located on the processor chips themselves.
Last edited:
knowitman
New member
I have some faith in you on your project. I don't know if you know of this site, but the www.gbadev.org forums have a section for the NDS. You can find some info there.
aprentice
Moderator
Slougi said:You mean tuesday
Nope wednesday
And this just goes to show why you can't trust anyone who comes to the boards with outragous claims, this is a fine example
edit: also, he has showed me some code last week, it wasn't much, mostly cpu frame work and 2 opcodes, written in visual basic. Last I checked, visual basic wasnt portable to any system other than windows, so i don't see how this will port over to the DS in the future.
Last edited:
OP
BGNG
New member
- Thread Starter
- #39
Nor do you see how ISP failure can prevent a person from getting online for a week. My ISP trashed Sprint and switched to MCI, so perhaps it won't fail in the future. It's Signalblast.com, Inc. You can e-mail them about it if you don't believe me. And run a WhoIs on my IP address. I am a customer of theirs.
I do appologize for this malfunction, as the irony of it is just a little too perfect.
Attatched to this post is the source code and build of the CPU emulator and disassembler as its current progress is for my NES project. All opcodes are implemented. After I packed the ZIP file on Monday, I have found a few errors that are lingering about; mainly the duplication of some opcodes such as 40 and 4D, both of which can be pronounced "for dee" and were probably misdocumented that way in my 6502 resource.
A few notes:
As aprentice mentioned, it is coded mostly in VB. Even if you (whoever you are) do not use VB, the source code should be fairly easy to navigate nonetheless. There is also the source code for an MFC DLL I made in C++ that I call vbCallback, which enables Visual Basic to use function callbacks as it is not designed to be able to use them very easily. The vbCallback library uses all the default settings for a normal MFC DLL project, so I only included the two files I changed: the cpp and def files.
I have only tested the disassembler with one ROM: the Super Mario Bros. with the title screen (with "DiskDude" in the header), and it works through-and-through. It does not output data on the header or the trainer, and it does not disassemble ROMs with more than two 16KB pages of PRG-ROM... nor has it been tested on any other game. It only disassembles ROMs which use iNES Mapper 0 as well.
I have also attatched the VB6 runtime upgrade that configures Windows to run the files, and comes standard with every system after Windows 98 SE. But if the program won't run, install the runtime files and it will. If you get a "File not found: 'vbCallback.dll'", then don't worry about it because I haven't made a fix for that. Just open the source code.
__________
And to move the code over to assembly, I plan to do that by hand. If I can get an emulator working in VB, then I know how to emulate the system and simply re-write the code to assembly later. I'm not a big fan of "development kits" as it is, so I only do rough-drafts in VB.
I do appologize for this malfunction, as the irony of it is just a little too perfect.
Attatched to this post is the source code and build of the CPU emulator and disassembler as its current progress is for my NES project. All opcodes are implemented. After I packed the ZIP file on Monday, I have found a few errors that are lingering about; mainly the duplication of some opcodes such as 40 and 4D, both of which can be pronounced "for dee" and were probably misdocumented that way in my 6502 resource.
A few notes:
As aprentice mentioned, it is coded mostly in VB. Even if you (whoever you are) do not use VB, the source code should be fairly easy to navigate nonetheless. There is also the source code for an MFC DLL I made in C++ that I call vbCallback, which enables Visual Basic to use function callbacks as it is not designed to be able to use them very easily. The vbCallback library uses all the default settings for a normal MFC DLL project, so I only included the two files I changed: the cpp and def files.
I have only tested the disassembler with one ROM: the Super Mario Bros. with the title screen (with "DiskDude" in the header), and it works through-and-through. It does not output data on the header or the trainer, and it does not disassemble ROMs with more than two 16KB pages of PRG-ROM... nor has it been tested on any other game. It only disassembles ROMs which use iNES Mapper 0 as well.
I have also attatched the VB6 runtime upgrade that configures Windows to run the files, and comes standard with every system after Windows 98 SE. But if the program won't run, install the runtime files and it will. If you get a "File not found: 'vbCallback.dll'", then don't worry about it because I haven't made a fix for that. Just open the source code.
__________
And to move the code over to assembly, I plan to do that by hand. If I can get an emulator working in VB, then I know how to emulate the system and simply re-write the code to assembly later. I'm not a big fan of "development kits" as it is, so I only do rough-drafts in VB.
Last edited:
HyperHacker
Raving Lunatic
The idea is that even if you write it in a non-portable language, you learn how to do it, so you can re-write it easily. I can't wait to see this actually completed. ^_^
Only one question, how did you manage to write a working NES emu in VB? NES is like 4mhz right? I tried to write a GB emu (same speed) and got like 3khz max. >_<
Only one question, how did you manage to write a working NES emu in VB? NES is like 4mhz right? I tried to write a GB emu (same speed) and got like 3khz max. >_<