gbadev.org forum archive

Whoa, that is great to see :D

Did i see that right,
it has two communication ports?
_________________
It seems this wasn't lost after all.

jenswa wrote:

Did i see that right,
it has two communication ports?

I know that if you want to use a headphones, you have to buy a adapter to plug it into you GBA SP. Maybe that is the second connector for, don't know.
_________________
To this day, many C programmers believe that "strong typing" just means pounding extra hard on the keyboard.
- Peter van der Linden

No, that's not two communication ports; it's one connector for the charger and headphone jack and one Game Link connector.

I'm assuming that chip next to the CPU is the EWRAM. Right?

And I notice that the GBA SP's CPU is marked "CPU AGB B". IIRC, when I opened my GBA to install an Afterburner light kit (which I promptly removed when I saw how washed out the graphics became), I saw revision "A". This could potentially be bad news for owners of Visoly and F2A flash carts.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Just for comparison the "old" GBA:

[Images not permitted - Click here to view it]
[Images not permitted - Click here to view it]
_________________
To this day, many C programmers believe that "strong typing" just means pounding extra hard on the keyboard.
- Peter van der Linden

Look at the EWRAM! It's marked.
The speed grade is a bit hard to read thou...
It says "-x0FN" where the "x" is hard to make out... I think the "x" might be a 4... if that's the case, then there is no problem running the EWRAM at zero waitstate.

Yes, there is an "overclock EWRAM" register documented in Martin Korth's GBATEK document that changes EWRAM to use one wait state instead of two. I should write a program that runs in IWRAM and continuously rewrites the entire EWRAM and looks for any differences between what is read and what was written. If I write this, and several of us with multiboot or flash hardware run this and submit their results, it should help determine the reliability of overclocked EWRAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

If the speed grade of the RAM really is "-40FN" Then it will work w/o any extra waitstates, no testing necessary.

ampz wrote:

If the speed grade of the RAM really is "-40FN" Then it will work w/o any extra waitstates, no testing necessary.

The GBA's memory controller requires one wait state to be inserted. (The BIOS initializes it to 2.)

The "testing" I suggested was primarily for those older GBA units that may have slower RAM. Published programs must run on all GBA systems.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

[img]
http://www.doonee.com/pub-pics/ewram.jpg
[/img]
EWRAM closer look, taken from my old GBA.
memory speed grade is -10FN

[img]
http://12.47.46.71/pub-pics/ewram.jpg
[/img]
EWRAM closer look, taken from my old GBA.
memory speed grade is -10FN

it is actually -10FN in GBA (not SP).

sorry for multiple post, webboard said first two messages are error but ???.

Speed grade -10FN might be a problem.
It can stand for 100ns, or 10ns.

I'm assuming the GBA EWRAM is 100ns.

Three CPU cycles (2 wait states + 1 data) are 180ns, and this is the normal EWRAM timing. Two CPU cycles (1 wait state + 1 data) are 120ns, which matches the "overclocked" EWRAM timing. But how many nanoseconds before the start of the next cycle does the CPU need the data from RAM? Is a 20ns difference between CPU speed and RAM speed enough?

(I'm just asking so I can see whether or not testing my GBA for OCability is futile before I spend too much time writing and tweaking test code.)
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Would it be possible to put the lighted screen from the sp in to an original agb case?

Jakerrzero - I doubt it. The screen probably has a different connector, or at least would need hookups for the light power, which wouldn't work on the standard GBA. In fact, looking at the picures, the origional GBA had a 40 pin cable going to the LCD, the GBA SP has a 34 pin cable. They must have changed the pins and such around. You won't get it to work without a lot of time and expensive test equiptment, I think.

I.C.E - You're right about the "two communication ports." One is the communication port, the other is used for the headphone connection and recharging the battery.

ATepples - As for the "CPU GBA B" comment, it most likely means that they changed in the internal design in some way with no outword effect. My guess is something like removing a feature from the die that wasn't used in the origional GBA (a feature that got cut), a die shrink (to allow it to use less power), integrated more glue logic into the core, or some other such thing. It might even be as simple as having a different pinout to make manufacturing the motherboard easier (this is very likely, IMHO). I doubt they could make flash carts stop working without causing incompatabilities with 'real' games.
_________________
--Michael

I'm trying to think of a way that they could break compatibility with flash carts at all...

I mean, the flash is connected exactly the same way as a ROM, right? (Voltage, Clock, Ground, Data, Addressing?) If thats the case, then the only ways I can think that it could possible break flash are...

Write test for known flash interfaces. (Breaks reading and writing, but only for known flash interfaces.)

Limit current to bus. IE, cut off at the threashold between normal reads and write. (Breaks only writing.)

Software scan for known menu-boot software. (Breaks only menu booting...)

I can't think of any 'solution' that would allow them to cut flash off anyway.

Any hardware gurus wanna gently set me straight on this? :D
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

That sounds about right to me. The only comment I have is flash might (I'd need to look this up) need more current for reading than maskrom, but the problem with current monitoring would be that carts in the future might need more power (like if they had more rom on 'em, internal clock, etc).

Basically my conclusion is the same as yours. They couldn't do anything without going WAY out of their way. I would suspect that their threat against lik-sang did alot more to stop piracy than making the gba "flashproof" would do, because people would just find ways around it. Most of those tests could be defeated by carts:

write test - It would be stored in the BIOS/ROM, so flash carts could just ignore that signal and use a different one. They couldnt' change it on the GBAs already shipped so this is worthless unless they want to constantly have to make the rom bigger.

current test - give the flash cart it's own battery (or patch into main ones), and use transistors to isolate the bus, with resistors to controll the current draw. You could make a little adaptor that would, no matter how much power is needed, look like a normal rom cart. Wouldn't be easy for a hobbiest, but it would be very simple for any company to make.

software scan - same as the write test, only easier.

I really don't know how they could do this without breaking compatibility with all the original GBAs. Any other people who know this kind of stuff have any ideas? I'm no hardware guru, just making (semi-)educated guesses.

Now that I think about it, if they could do some kind of high speed timing test, they might be able to detect things. I'd assume that mask rom would be faster than flash. The problem is that when a company is told "You only need to use rom that can do 5 mhz (or whatever)" that's what they'll use, because anything that can do better will be more expensive. So unless "5 mhz" flashrom is actually "4.895" and maskrom is "4.992", this wouldn't work. Again, this is pure speculation.
_________________
--Michael

Is flashrom slower then maskrom? I was under the impression that it only slowed down when burning.
_________________
Moron! You don't herd chickens with a shotgun!

--CoolMan

I don't know. I assume since you need flipflops (I think) instead od simple transistors (like rom?) it would be slower. Anyone actually know the answer?
_________________
--Michael

D-flops vs. xistor+cap is SRAM vs. DRAM, not flash vs. mask ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Like I said, I'm no expert. I assume the issue is mute though, because you can get both in many different speeds.
_________________
--Michael

As I said before, If Nintendo wanted to put some stuff in he GBA to stop flash carts, they could just as well do it in the old GBA, no need to wait for a new version. Also, it's somewhere inbetwenn complicated to imposible to do.
However, they could _easily_ put copyprotection hardware into the game carts themself. I can't understand why they have not done that yet.

ampz wrote:

However, they could _easily_ put copyprotection hardware into the game carts themself. I can't understand why they have not done that yet.

I don't think so -- the timings needed to read from the GBA carts are already out there. If they protected the cart from being read, it wouldn't be backwards compatible. Also, it wouldn't take much longer for someone to stuff an logic analyser inbetween the GBA and the cart to figure out what was going on.

If Nintendo is going to protect their code more, it's going to be on the next major upgrade, and they are probally going to have to use a proprietary optical disc, like the GameCube. That won't stop people from reading the discs forever, but it will hold them off for a while -- especially if it's a different format from the GCN.
_________________
dennis

SmileyDude wrote:

Also, it wouldn't take much longer for someone to stuff an logic analyser inbetween the GBA and the cart to figure out what was going on.

What if Nintendo puts a crypto processor on the cart? Capcom's CPS-2 coin-op crypto still hasn't been completely cracked yet.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I'm with smiley. Right now it would cost too much and cause too many problems to be worth it. To put in copy protection of any decent form, it would have to be in the future.

As for media, I don't think Nintendo will move to optical storage any time in the next decade for the gameboy simple because of the moving parts. The gameboy is ment to be jostled and bumped in use. A CD drive would have a hard time keeping up with it. Unless holographic storage is perfected soon, don'tcount on it. Remember that the maximum cart size for the GBA is 512 megabits, which is 64 megabytes. A 64 megabyte compact flash card is currently available for $20, which means that a ROM version is next to nothing. By the time the next gameboy comes out, they'll probably have much bigger cartridge sizes than 512 megabytes (which currently go for $120 in flash to start) so they'll be very cheap by then, and that's not even rom, which is cheaper than flashrom.

For a console, non-optical storage doesn't make a lot of sense today to ship games, but I think it will continue to make alot of sense on handhelds for years and years and years.

Tepples: maybe that crypto hasn't been broken, but if you gave that technology to millions of people to fiddle with, how long would it take? I think that's a case of it's not cracked because it's not very common.

Side rant: I hope the W3C gets their act together soon and puts tabs in the next version of the HTML specification. That's always driven me nuts. NUTS. Sorry ;)
_________________
--Michael

mbcook wrote:

As for media, I don't think Nintendo will move to optical storage any time in the next decade for the gameboy simple because of the moving parts. The gameboy is ment to be jostled and bumped in use.

So is a Sony MiniDisc player.

Quote:

Remember that the maximum cart size for the GBA is 512 megabits

There is no "maximum cart size" for a Game Boy system. There is only a maximum ROM size for a given bankswitch method. The maximum ROM size for the method current GBA carts use is 256 megabits, but who's to say N won't introduce a new method?

Quote:

but if you gave that technology to millions of people to fiddle with, how long would it take?

Millions of Americans own an Xbox console. How long would it take to break the 2048-bit signing key used by Microsoft to authorize programs to run on the Xbox console?

Quote:

I hope the W3C gets their act together soon and puts tabs in the next version of the HTML specification.

It's possible to indent the first line of an HTML paragraph element using CSS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

What if Nintendo puts a crypto processor on the cart? Capcom's CPS-2 coin-op crypto still hasn't been completely cracked yet.

But, the bus between the GBA and the cart has to be unencrypted until the next major change to the GBA. So, you would have a ROM that was encrypted, and then you would have the chip that would decrypt the ROM on the same board. Nobody dumps GBA carts by reading straight from the ROM chips -- they read it through the cart connector just like the GBA would.

BTW, when I said that Nintendo would have to use an optical disc in some future version, I wasn't saying that the next version would have it -- the only reason Nintendo would make a change like that is if they wanted to slow down the copying of their games, and the cost of implementing something like that wasn't prohibitive. Until they can build an optical drive into a device the size of a GBA cheaply and reliably, it ain't gonna happen.

Also, another reason why I think it won't happen for a while is that a big part of the reason why the GBA and it's predecessors have had such good success is the backwards compatibility. It's pretty unlikely that any new portable with an optical drive is also going to include a cart slot -- unless they use that slot as a memory card for saves... hey, I think I might have answered my own question ;) Maybe I am wrong, and we'll see a portable GameCube with backwards GBA/GBC/GB compatibility in a machine the size of a GBA SP someday in the future :D
_________________
dennis

SmileyDude wrote:

ampz wrote:

However, they could _easily_ put copyprotection hardware into the game carts themself. I can't understand why they have not done that yet.

I don't think so -- the timings needed to read from the GBA carts are already out there. If they protected the cart from being read, it wouldn't be backwards compatible. Also, it wouldn't take much longer for someone to stuff an logic analyser inbetween the GBA and the cart to figure out what was going on.

If Nintendo is going to protect their code more, it's going to be on the next major upgrade, and they are probally going to have to use a proprietary optical disc, like the GameCube. That won't stop people from reading the discs forever, but it will hold them off for a while -- especially if it's a different format from the GCN.

No, no, it can be done much more simple than that.
Just add a small device to the ASIC in the carts (not in the normal adress space) that returns a serial number when read. Make the serial number different for different games.
Yes, it could be cracked by modifying the asm source, or adding the device to future flash carts, but all N has to do then is to slightly change the way the device works, and they are back on. By implementing different devices in different games it becomes much more to crack.

If they add a simple encryption to the serial number device it may even be more or less unbreakable.

SmileyDude wrote:

But, the bus between the GBA and the cart has to be unencrypted until the next major change to the GBA. So, you would have a ROM that was encrypted, and then you would have the chip that would decrypt the ROM on the same board.

And this chip wouldn't start decrypting until it gets a handshake from code on the cart. It's the same way that nobody has been able to figure out the compression on Star Ocean, Street Fighter II Alpha, and a couple other later Super NES games in order to play them without a "graphics decompression pack".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

To prevent game copying then only thing I can think of that they can do now is the hardware of the cart it's self. If they put in a RTC chip and made the program check for it's existance at random times that would do it. Or with games that use other special hardware (like Kirby's Tilt 'n' Tumble). Basically use/require a feature that you can put in the REAL cart, but won't be there when the game is copied to a flash cart. That's the only thing that could be done to make copying hard right now.

For example, would the new Pokemon games work off a flash cart since they use a RTC? I doubt it, but who knows. It's that kind of thing that can be used to stop/slow copying now without effecting old games/compatibility. Be interesting to see what happens when the next Game Boy comes out. They'll have to drop backwards compatibility at some point, but it's going to be very tough for them, considering the shear size of the GB library.
_________________
--Michael

gbadev.org forum archive

Hardware > Inside the new GBA SP

#2846 - I.C.E - Thu Feb 13, 2003 8:08 pm

#2847 - Lord Graga - Thu Feb 13, 2003 8:11 pm

#2848 - jenswa - Thu Feb 13, 2003 8:25 pm

#2850 - I.C.E - Thu Feb 13, 2003 8:33 pm

#2851 - tepples - Thu Feb 13, 2003 8:34 pm

#2857 - I.C.E - Thu Feb 13, 2003 8:57 pm

#2858 - ampz - Thu Feb 13, 2003 9:01 pm

#2859 - tepples - Thu Feb 13, 2003 9:33 pm

#2861 - ampz - Fri Feb 14, 2003 12:25 am

#2870 - tepples - Fri Feb 14, 2003 3:16 am

#2871 - xponder - Fri Feb 14, 2003 3:23 am

#2872 - xponder - Fri Feb 14, 2003 3:35 am

#2873 - xponder - Fri Feb 14, 2003 3:37 am

#2874 - xponder - Fri Feb 14, 2003 3:44 am

#2898 - ampz - Fri Feb 14, 2003 10:28 am

#2966 - tepples - Sat Feb 15, 2003 5:09 am

#3161 - Jakerrzero - Wed Feb 19, 2003 8:56 am

#3202 - mbcook - Thu Feb 20, 2003 2:29 am

#3203 - CoolMan - Thu Feb 20, 2003 3:25 am

#3208 - mbcook - Thu Feb 20, 2003 4:16 am

#3226 - CoolMan - Thu Feb 20, 2003 5:54 pm

#3239 - mbcook - Thu Feb 20, 2003 10:32 pm

#3240 - tepples - Thu Feb 20, 2003 10:38 pm

#3243 - mbcook - Thu Feb 20, 2003 11:24 pm

#3262 - ampz - Fri Feb 21, 2003 10:33 am

#3445 - SmileyDude - Tue Feb 25, 2003 3:00 am

#3450 - tepples - Tue Feb 25, 2003 4:43 am

#3451 - mbcook - Tue Feb 25, 2003 4:48 am

#3454 - tepples - Tue Feb 25, 2003 5:02 am

#3455 - SmileyDude - Tue Feb 25, 2003 6:00 am

#3463 - ampz - Tue Feb 25, 2003 12:24 pm

#3475 - tepples - Tue Feb 25, 2003 5:40 pm

#3493 - mbcook - Wed Feb 26, 2003 1:00 am