#33163 - ghettron - Fri Dec 31, 2004 7:40 am
I count 6 pins on the power connector. So that makes two for audio, two for power, possibly one ofr ground -- what is the sixth one for? anybody?
#33164 - PhoenixSoft - Fri Dec 31, 2004 8:15 am
Please search first - http://forum.gbadev.org/viewtopic.php?t=4538
It's supposedly two for power, two for left audio, and two for right audio. Apparently, they don't have a common ground, as you seem to have assumed.
#33165 - netdroid9 - Fri Dec 31, 2004 8:17 am
Switch. Don't ask me why.
#33191 - darkfader - Fri Dec 31, 2004 3:55 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:38 pm; edited 1 time in total
#33221 - willgonz - Fri Dec 31, 2004 10:25 pm
darkfader,
How does this compare to the SP?
Perhaps, Pin 4 when Connected to Ground pin 6 will turn off the sound for the unit, so you could use attached headphones instead. Silly that they stayed with this setup, because the SP didn't have a headphone jack and the DS does.
_________________
│?ig │
All of this is research. You are going to see theories come and go. Things you think can't be done, will be done. But because you are here, you'll be the first to know.
#33231 - mymateo - Fri Dec 31, 2004 11:22 pm
For better compatability with their "It's not a gameboy!" system. After all, we can't have a new handheld that isn't the successor to the old one be incompatible with it.
Actually, I think it was more to save money 'cause then they wouldn't have to re-design and patent a new adapter, they could just use the old one. Saves a lot of time that way, too.
#33236 - EaDS Milliways - Fri Dec 31, 2004 11:58 pm
| mymateo wrote: |
| Actually, I think it was more to save money 'cause then they wouldn't have to re-design and patent a new adapter, they could just use the old one. Saves a lot of time that way, too. |
Keeps the accessory makers happy too! Rework the box art, add DS to it, BAM same product, new sales!
#33300 - Alex Atkin UK - Sat Jan 01, 2005 7:29 pm
The certainly thing they kept it for the save of saving money on the mains adapter. Add a DS sticker instead of an SP sticker and it means they can continue the manufacture the same mains adapter but stick on whichever label they need at the time.
They kept the audio in there again for compatibility but also because if they had re-pinned it some clever sod would probably have plugged their headphones in and fried them, or the DS.
I really wish they had kept the link port though, or at least had a BIOS option to emulate it over wireless. Im sure this could have been done without risking compatibility problems.
_________________
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
#33304 - mymateo - Sat Jan 01, 2005 8:15 pm
| Alex Atkin UK wrote: |
| They kept the audio in there again for compatibility but also because if they had re-pinned it some clever sod would probably have plugged their headphones in and fried them, or the DS. |
Hmm... I never really thought of that... so true. People can be idiots, but mistaking the DS power port for GBA compatible would and could happen to anybody, idiot or not. Yay Nintendo! (I guess that's why the warning screen at every boot, to make the DS more 'idiot' proof.)
| Alex Atkin UK wrote: |
| I really wish they had kept the link port though, or at least had a BIOS option to emulate it over wireless. Im sure this could have been done without risking compatibility problems. |
It would not have been hard. In fact, it could still be done! Just make a wireless adapter that plugs into the GameCube and sends out a Download-and-Play "game". Go into the DS, choose "Download Play", and select the adapter. Each adapter would have a button to change its channel, and whatever channel it's on, that's the name of the download. For instance, if the adapter in P1 spot is channel 9 and the P2 spot is channel 1, then player 1 would select "Wireless GBA Boot Ch.9" and player 2 would select "Wireless GBA Boot Ch.1" from their DS menus. Once someone has selected their port, the adapter would lock in communications and not allow someone else to connect to it. Then, the program the DS downloads would be a GBA Boot emulator, and the Adapter would act as a GBA plugged into the GameCube taking commands from the DS.
Whew, lengthy explanation, but there you have it. It (probably) can and SHOULD be done. I mean seriously! And Nintendo should have built in 1 more protocol -- the one used on the GBA wireless adapters!! That way, DS owners who don't have a GBA can play their wireless GBA games like Pokemon, or the new Classic NES series that can multiplay over wireless... geez.
Anyway, that's my $0.02
#33315 - dagamer34 - Sat Jan 01, 2005 10:01 pm
| Alex Atkin UK wrote: |
I really wish they had kept the link port though, or at least had a BIOS option to emulate it over wireless. Im sure this could have been done without risking compatibility problems. |
This would kill the GBA/GBA SP as there would be no reason to buy one anymore. It is stupid to kill a successful product.
Besides, it is supposed to be a "third pillar". If you put in a link port, people will begin thinking it is just another GameBoy. Nintendo is trying to stay away from that, remember?
_________________
Little kids and Playstation 2's don't mix. :(
#33324 - ampz - Sat Jan 01, 2005 11:46 pm
| Alex Atkin UK wrote: |
| I really wish they had kept the link port though, or at least had a BIOS option to emulate it over wireless. Im sure this could have been done without risking compatibility problems. |
You say you are sure it could have been done without risking compatibility problems? Well, sorry, but you are very wrong. It is technically impossible to emulate the GBA link port over wireless at all!
You cannot emulate the synchronous serial communication interface over wireless, or any packet switched network (such as Ethernet/TCP/IP) for that matter.
It simply cannot be done.
#33331 - Abcd1234 - Sun Jan 02, 2005 12:17 am
Yeah, riiight...
1) TCP/IP defines a reliable, FIFO-style transport layer which just happens to support full-duplex communication. There's nothing stopping you from using it in a half-duplex (and hence fully-synchronous) fashion.
2) no$gba and VBALink both emulate the GBA link layer over TCP/IP. Meaning it is quite obviously very possible to do this.
So, the next time you plan on flaming people and acting like some kind of authority, please make sure you know what you're talking about first.
Now, as for the idea that Nintendo is worried about killing the GBA SP, that seems kinda silly, too. After all, they had no trouble doing the same with the regular Gameboy. In fact, given the increased price point of the DS, Nintendo should be doing everything they can to encourage people to move to their new platform.
#33343 - tepples - Sun Jan 02, 2005 4:38 am
| Abcd1234 wrote: |
| TCP/IP defines a reliable, FIFO-style transport layer which just happens to support full-duplex communication. There's nothing stopping you from using it in a half-duplex (and hence fully-synchronous) fashion. |
Except the size of a GBA multiplayer comms packet is 2 bytes, and the minimum useful size of a TCP packet is much bigger than that.
| Quote: |
| no$gba and VBALink both emulate the GBA link layer over TCP/IP. |
They use what Forgotten has called the "TGB Dual method": emulate all linked systems on each machine, and exchange control data. The Nintendo DS could not have used the TGB Dual method, as it would require two to four GBA CPUs and a four times faster cart edge interface.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#33348 - mymateo - Sun Jan 02, 2005 4:55 am
Then I guess the best solution is a GBA card with a serial port built into it that, when you turn it on, will act like a GBA in listen mode, grab the data, and send it into internal memory and execute it from there. Two problems I can think of with that are:
1) Send-back data. Some apps/games (in fact, many) talk with the gamecube to either tell it everything is OK or to start a conversation.
2) Making the downloaded app/game talk to the port on the cart instead of hardware in the GBA which isn't there 'cause it's a DS.
So, unless Nintendo knows of a way around this (and let's face it, I'm not that smart, so just 'cause I don't know it doesn't mean it doesn't exist) then I guess we're all gonna be stuck with both a DS and a GBA if we want it all.
Stop me if I'm rambling.
And that's my $0.02
#33349 - tepples - Sun Jan 02, 2005 4:59 am
You're stuck with a DS, a GBA, and a GBC. The GBA doesn't have the GBC's infrared port either.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#33352 - flipper - Sun Jan 02, 2005 5:21 am
[quote="ampz"] | Alex Atkin UK wrote: |
You cannot emulate the synchronous serial communication interface over wireless, or any packet switched network (such as Ethernet/TCP/IP) for that matter.
It simply cannot be done. |
*grin* Actually, the company I work for holds many patents on sync serial over packet.
It is not that it cannot be done. It is that doing it for the general case is a PAIN in the ass.
#33361 - Abcd1234 - Sun Jan 02, 2005 9:38 am
| tepples wrote: |
Except the size of a GBA multiplayer comms packet is 2 bytes, and the minimum useful size of a TCP packet is much bigger than that. |
Yes, good point. Although with clever buffering algorithms, you might be able to cut down the overhead some (try to detect when large-scale streaming is in progress versus periodic control messages, etc). And, of course, TCP, with all it's overhead, isn't the only reliable transport available... heck, you could probably get away with UDP and basic sequence numbers since, by-and-large, packet drops aren't terribly common.
| tepples wrote: |
They use what Forgotten has called the "TGB Dual method": emulate all linked systems on each machine, and exchange control data. The Nintendo DS could not have used the TGB Dual method, as it would require two to four GBA CPUs and a four times faster cart edge interface. |
*shudder* Interesting, I wasn't aware of that. It's been a long time since I've seen a hack quite that nasty.
#33383 - ampz - Sun Jan 02, 2005 7:52 pm
| Abcd1234 wrote: |
Yeah, riiight...
1) TCP/IP defines a reliable, FIFO-style transport layer which just happens to support full-duplex communication. |
Yes, TCP is a asynchronous FIFO-style transport protocol with a latency about equal to the underlaying network (usually in the area of 1ms in the case of a ethernet network without any packet drops, wireless adds alot to that number due to lower bitrate and plenty of transmission errors), but the GBA synchronous serial protocol does not work like that at all. All units synchronize on the same clock (provided by the master). Any delay equal or greater than one clock period (3.9us at 256kbit/s) will crash everything. | Abcd1234 wrote: |
| There's nothing stopping you from using it in a half-duplex |
Or course not.
| Abcd1234 wrote: |
| (and hence fully-synchronous) fashion. |
No, making something half duplex does not make it synchronous.
| Abcd1234 wrote: |
2) no$gba and VBALink both emulate the GBA link layer over TCP/IP. Meaning it is quite obviously very possible to do this.
|
Actually they don't.
(Already answered in detail by tepples)
| Abcd1234 wrote: |
So, the next time you plan on flaming people and acting like some kind of authority, please make sure you know what you're talking about first.
|
Well, I claim that I know what I'am talking about.
How about you?
#33392 - Abcd1234 - Sun Jan 02, 2005 9:19 pm
| ampz wrote: |
| [Yes, TCP is a asynchronous FIFO-style transport protocol with a latency about equal to the underlaying network (usually in the area of 1ms in the case of a ethernet network without any packet drops, wireless adds alot to that number due to lower bitrate and plenty of transmission errors), but the GBA synchronous serial protocol does not work like that at all. All units synchronize on the same clock (provided by the master). Any delay equal or greater than one clock period (3.9us at 256kbit/s) will crash everything. |
Yes, but the point isn't to perfectly emulate the physical layer. The GBA exposes a form of programmer's interface, in the form of registers for data transfer, status, etc. Emulating these correctly may very well be sufficient to trick most software, as games probably use status registers, rather than carefully tweaked timing trickery, in order to perform data transfers.
Now, I will definitely grant you that communication latency is a serious issue, and it may not be surmountable, but it seems a little extreme to just flat out declare that it's completely impossible.
| ampz wrote: |
Well, I claim that I know what I'am talking about.
How about you? |
Well, I'd like to think I'm not totally ignorant on the subject. I do apologize, though... I come across enough posts in forums like these that are clearly written by those with, err, limited technical knowledge, and so it can be a little difficult to tell one way or another if the author actually knows what they're talking about, especially when the post consists of nothing more than a statement with no explanation to back it up.
#33400 - ampz - Sun Jan 02, 2005 10:29 pm
| Abcd1234 wrote: |
| ampz wrote: | | [Yes, TCP is a asynchronous FIFO-style transport protocol with a latency about equal to the underlaying network (usually in the area of 1ms in the case of a ethernet network without any packet drops, wireless adds alot to that number due to lower bitrate and plenty of transmission errors), but the GBA synchronous serial protocol does not work like that at all. All units synchronize on the same clock (provided by the master). Any delay equal or greater than one clock period (3.9us at 256kbit/s) will crash everything. |
Yes, but the point isn't to perfectly emulate the physical layer. The GBA exposes a form of programmer's interface, in the form of registers for data transfer, status, etc. Emulating these correctly may very well be sufficient to trick most software, as games probably use status registers, rather than carefully tweaked timing trickery, in order to perform data transfers.
Now, I will definitely grant you that communication latency is a serious issue, and it may not be surmountable, but it seems a little extreme to just flat out declare that it's completely impossible.
|
It is correct that it is slightly easier to emulate the communication on the register layer rather than on the physical layer. However, it is not a huge difference.
GBA software send and receive one byte (or one word) at a time, and expect a response byte to be immediately available in a register when a byte has been transmitted.
The latency requirements would vary depending on the number of GBAs connected to each other, and the transmission mode used, but to get a basic idea of the latency requirements: A byte transmission is 8 clock cycles, 8*3.9 = 31.2us.
You see the problem?
Even on the register level the latency requirement is nowhere near that of packet based networks.
There is also the packet bandwidth overhead issue, Ethernet packets can never be smaller than 64byte (assuming wired ethernet, I don't know the specifics about wireless ethernet), and the GBa protocol requires transmisson of single bytes. That's one packet for each byte.
256kbit/s == 32kByte/s == 32000 packets/s => 2 * 16Mbit/s Ethernet traffic (16Mbit/s in each direction)
That's just for 256kbit/s and only two connected GBAs.
| Abcd1234 wrote: |
| ampz wrote: |
Well, I claim that I know what I'am talking about.
How about you? |
Well, I'd like to think I'm not totally ignorant on the subject. I do apologize, though... I come across enough posts in forums like these that are clearly written by those with, err, limited technical knowledge, and so it can be a little difficult to tell one way or another if the author actually knows what they're talking about, especially when the post consists of nothing more than a statement with no explanation to back it up. |
Yeah, I know what you mean.
I did not write a full explanation of the subject because I (and others) have already done that several times on this forum, and it is getting tiresome to explain it over and over again.
#33410 - Alex Atkin UK - Mon Jan 03, 2005 2:20 am
| Quote: |
You say you are sure it could have been done without risking compatibility problems? Well, sorry, but you are very wrong. It is technically impossible to emulate the GBA link port over wireless at all!
You cannot emulate the synchronous serial communication interface over wireless, or any packet switched network (such as Ethernet/TCP/IP) for that matter. |
Ooops, latency, I always forget about the latency. LOL
Well surely they could at LEAST have made the Pokemon wireless compatible with DS wireless. This would have also mean that all future GBA games could have been designed to be fully DS compatible.
This all seems to stem from the fact that Nintendo wasnt sure the DS would fair well so they claimed it wasnt the next Gameboy to make sure people knew they werent ditching the GBA. I can see their logic but it will be a real shame if the DS DOES prove hugely popular (im not counting my chickens yet, its sold well but it could still flop later) then they really missed out on a useful feature.
As for having a GBA link port on a GBA cart. Possible? Maybe.
But the usefulness would be limited as it would only work with multiboot games unless it could somehow be a passive devide allowing a GBA cart plugged in at the same time.
_________________
[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
#33426 - ampz - Mon Jan 03, 2005 7:29 am
| Alex Atkin UK wrote: |
| Quote: | You say you are sure it could have been done without risking compatibility problems? Well, sorry, but you are very wrong. It is technically impossible to emulate the GBA link port over wireless at all!
You cannot emulate the synchronous serial communication interface over wireless, or any packet switched network (such as Ethernet/TCP/IP) for that matter. |
Ooops, latency, I always forget about the latency. LOL
Well surely they could at LEAST have made the Pokemon wireless compatible with DS wireless. This would have also mean that all future GBA games could have been designed to be fully DS compatible.
This all seems to stem from the fact that Nintendo wasnt sure the DS would fair well so they claimed it wasnt the next Gameboy to make sure people knew they werent ditching the GBA. I can see their logic but it will be a real shame if the DS DOES prove hugely popular (im not counting my chickens yet, its sold well but it could still flop later) then they really missed out on a useful feature.
As for having a GBA link port on a GBA cart. Possible? Maybe.
But the usefulness would be limited as it would only work with multiboot games unless it could somehow be a passive devide allowing a GBA cart plugged in at the same time. |
The GBA game would have to be patched to use the cart link port.
#35615 - emumanXM - Tue Feb 08, 2005 5:51 am
Where can one get such a connector for the power/headphone gbasp-style jack? I ordered Pelican headphones for the gbasp, hoping the power pins would be there. I'll need it for passing audio out and charging/powering the unit for my current project.
#35650 - Sebbo - Tue Feb 08, 2005 11:37 pm
| Alex Atkin UK wrote: |
| This all seems to stem from the fact that Nintendo wasnt sure the DS would fair well so they claimed it wasnt the next Gameboy to make sure people knew they werent ditching the GBA. I can see their logic but it will be a real shame if the DS DOES prove hugely popular (im not counting my chickens yet, its sold well but it could still flop later) then they really missed out on a useful feature. |
i don't think the DS was designed to be the next gameboy at all. infact, if the Revolution lives up to its name, you can count on the next Gameboy being a gamecube in your pocket with some of the revolutions features (in fact, count on it being a gamecube in your pocket anyway) nintendo's gonna steer clear of discs for GB-Next too, we all know the battery problems with the PSP (nintendo themselves have also said that they won't use discs in a portable system)
#35658 - Dib - Wed Feb 09, 2005 3:16 am
How can you have a portable Gamecube and not use disk media? How much data is stored on a GC cd? (I know it's several gigabytes)
Nintendo held out too long on switching to cd media, and it hurt them on the 64. Eventually they capitulated and the Gamecube had the mini cds. The same is inevitable for portables as well. If they want to make a truly powerful system, there is really no choice.
#35659 - PhoenixSoft - Wed Feb 09, 2005 3:23 am
| Dib wrote: |
How can you have a portable Gamecube and not use disk media? How much data is stored on a GC cd? (I know it's several gigabytes)
Nintendo held out too long on switching to cd media, and it hurt them on the 64. Eventually they capitulated and the Gamecube had the mini cds. The same is inevitable for portables as well. If they want to make a truly powerful system, there is really no choice. |
It's somewhere around 1.6 GB from what I remember. I think it's actually the same amount as the UMD - aren't they both just mini DVDs that are formatted strangely?
#35660 - mymateo - Wed Feb 09, 2005 3:23 am
1 GC disc = Approx. 1.5 GB
Or 12,000 megabits, roughly 12 times the size of a standard 128 MB DS card. Really, it doesn't seem exactly feasible for the next GameBoy, but the one after is highly likely. In my opinion, anyways.
#35671 - Sebbo - Wed Feb 09, 2005 9:13 am
nintendo's just keeping battery life and how much cooling the system is gonna need in mind. unless they put in huge amounts of RAM or something it will b constantly streaming off the disc...running a motor and laser hurts the battery more than reading off a card. plus you won't need to fork out extra for a memory card either
#35672 - PhoenixSoft - Wed Feb 09, 2005 9:32 am
| mymateo wrote: |
1 GC disc = Approx. 1.5 GB
Or 12,000 megabits, roughly 12 times the size of a standard 128 MB DS card. Really, it doesn't seem exactly feasible for the next GameBoy, but the one after is highly likely. In my opinion, anyways. |
Actually, it's 12288 Mb or exactly 12 times the size of a DS card.
(I know, I'm awfully pedantic, aren't I?)
#35688 - mymateo - Wed Feb 09, 2005 5:56 pm
Yeah, you're right. I guess I was too tired to multiply 1.5 GB by 1024 to get MB before the other math, which if we pick apart I probably didn't do quite as accurate either, especially since I don't think GC discs are exactly 1.5 GB in the first place. :)
#35834 - emumanXM - Fri Feb 11, 2005 7:10 am
To get back to the subject of the thread, here is the ascii from joat's NDS Wiki:
EXT 2 Socket (Power Supply and Headphones)
Pin Expl. ___________
A PWR(-) GND | X ___ Y |
D PWR(+) 5.2V DC | --- --- |
|_A_B C_D_|
X,Y,B,C Headphones ??? \_/
I figured this out:
C Audio GND (Shield)
B Audio L
X Audio R
Y ??? (connect this to D(when charger is not connected) and the speakers are disabled and audio is piped through the audio pins)
I want to use the connector for audio out and charging for my project. Thing is, I am unsure if the DS or GBASP would be damaged if 5.2V is connected to Y and D to not only charge, but pass audio out.
#35847 - PhoenixSoft - Fri Feb 11, 2005 11:24 am
You can buy double adapters that have both headphones and power going into the EXT2 port at once, so it must be possible somehow.
#35907 - emumanXM - Sat Feb 12, 2005 7:15 am
Do you know any suppliers that will ship to the US? I'd like to buy one and take it apart.
![[Images not permitted - Click here to view it]](http://csdprojects.co.uk/banners/linuxusers.png){kind=link}
![[Images not permitted - Click here to view it]](http://csdprojects.co.uk/banners/segagaming.png){kind=link}