An Incredulous Undertaking

[Trotterwatch]

I think he meant to say "fast understanding". Good luck on your project btw

[-Shadow-]

I think he meant to say "fast understanding". Good luck on your project btw

You'd hit it

[Azimer]

BGNG, the hardest part imo, is waiting for the information you need to get started... not to mention the development tools needed to accomplish your task. Good luck.

[BGNG]

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.

[remmy]

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.

[BGNG]

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.

[remmy]

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.

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:

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.

[BGNG]

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.

[remmy]

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.

[BGNG]

Again... backwards. I'm using the VBlank to limit execution.

And THANKYOUTHANKYOUTHANKYOU for that information. It will be put to good use, I assure you.