gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > newbe's questions

#38330 - R4p70r - Sat Mar 26, 2005 10:45 am

My brother bought a DS a few days ago and I think it'd be cool if I could do some coding for it. I ordered a PassMe from natrium42 and while I'm waiting for it to ship I should also purchase a GBA flash cart.

Since I'm new to Gameboy development in general I'm not sure which cart is the best. Some carts have to be programmed from the GBA link port and I don't have a GBA so they won't do me any good. There are also some carts that seam to offer a boot menu. I'm not sure how this is done but if the proper data is not visible at boot time I'm afraid the PassMe may not work. Any suggestions?

There is something else that I'd like to know about flash carts... All the GBA specs I have seen so far tell me there is a 32 MegaBytes limit to the cart ROM size. That's odd because some flash carts are bigger than that. Were there some memory bank scheme used by late GBA games to work with larger ROM size? Or is there at least a way to do that on one of the big flash carts. That could be useful for a media player project on the DS and things like that.

64kb of cart RAM seam quite small as well. With a microphone on the DS it would've been cool to make a small audio notebook app or something. But that takes a lot of storage space.



I took a quick look at the code template from NDSTech Wiki and I just want to be sure I understand it correctly.

It's necessary to use the ARM7 as a relay to the ARM9 cause some I/O registers are only accessible from one of the CPU. According to the wiki there are some odd cases like the A, B, L and R keys that are accessible from both CPU while the X and Y keys that would only be visible to the ARM7. It's odd but I can believe it.

Now there is something I'm not sure I understand. The ARM7 fills a struct with some I/O data on VBlank and the ARM9 reads that same struct on VBlank as well. Do we know that the ARM7 interrupt will execute before the ARM9 interrupt or do we just don't care? I guess it would be easy to create a spinlock by using a volatile integer in ram and some loops. (But then I alway use library functions for concurrent programming ;-)
I guess the code will work whatever the order of execution is in that case I just want to know what happens here.



One last thing. Can any of the connectors on the DS be used to plug a simple logic sensor or maybe link the console to my PC. That could be useful at least until the WiFi interface is completely understood.

There is a plug near the headphone jack, I don't know what its for. Any idea?

Well I think that's all there is for now. I can't wait to to receive the PassMe.


Last edited by R4p70r on Sat Mar 26, 2005 10:50 am; edited 1 time in total

#38331 - Seiru - Sat Mar 26, 2005 10:47 am

There is a plug near the headphone jack, I don't know what its for. Any idea?

That's the external microphone input.

#38335 - DekuTree64 - Sat Mar 26, 2005 11:23 am

The VBlank interrupts should trigger at the exact same time, aside from minor delays like being in the middle of a ldmia/stmia instruction. Still, in things like the template (the one that changes the screen color), I think the ARM9 will get to the data before the ARM7 finishes filling it out, so it's actually running a frame behind. You could indeed correct that spinning on a volatile flag that the ARM7 sets as soon as it's finished.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

#38340 - darkfader - Sat Mar 26, 2005 2:33 pm

That connector on the back is a debug port. It will output either 1200/2400 Hz bleeps or morse code depending on the debug library you're using.
I guess you could alternatively also hook up a tape recorder and read in basiccode programs and run them on DS.

#38358 - tepples - Sat Mar 26, 2005 5:07 pm

That does it. Now somebody's probably going to go make a C=64 or Spectrum emulator with a touch-screen keyboard and a working cassette interface.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#38360 - Mike - Sat Mar 26, 2005 6:03 pm

darkfader wrote:
That connector on the back is a debug port. It will output either 1200/2400 Hz bleeps or morse code depending on the debug library you're using.
I guess you could alternatively also hook up a tape recorder and read in basiccode programs and run them on DS.


I can confirm this and even disclose a preliminary success in attaching a USB flatbed scanner through the use of a homebrew cable. Currently 25% of an A4 can be transmitted through PictoChat to the kid nextdoor with the runny nose.

#38365 - Kyoufu Kawa - Sat Mar 26, 2005 7:03 pm

I don't believe you, Mike.

#38379 - R4p70r - Sat Mar 26, 2005 8:49 pm

Seiru wrote:
There is a plug near the headphone jack, I don't know what its for. Any idea?

That's the external microphone input.


I guess that was too obvious.

darkfader wrote:
That connector on the back is a debug port. It will output either 1200/2400 Hz bleeps or morse code depending on the debug library you're using.
I guess you could alternatively also hook up a tape recorder and read in basiccode programs and run them on DS.


That's an ingenious suggestion. We could also send wireless bleeps if the receiver microphone is near enough. Remember R2D2?



Btw Any recommendations for a good GBA flash cart that works with the PassMe?