#4188 - cesium - Sun Mar 23, 2003 12:09 am
Just picked up a GBA SP 15 mins ago. Popped in my Flash2Advance
128M cart. I ran F2AW13NT. It sends over the i-Linker just fine.
Software reports that it finds i-Linker. But then it says....
Flash not found!!!
What!? I tried running with the re-charger plugged into the wall.
Same result.
I'll let it charge for an hour and try again...
Back in an hour.
cesium
#4191 - cesium - Sun Mar 23, 2003 2:03 am
No joy yet.
Does your Flash2Advance work in the SP?
cesium
#4192 - cesium - Sun Mar 23, 2003 2:32 am
I fully charged GBA-SP. I still can't get the F2A writer to work.
I upgraded to ver 2.0 (f2aw20nt), no luck.
I went back to the original GBA: I can write to the flash just fine.
I then put this flash in the GBA-SP, it runs great.
I simply cannot write to the flash from i-Linker. At several points
in the tinkering I saw different behaviors from the i-Linker code.
Sometimes it said it didn't recognize the type of cart,
other times it wrote garbage out to its little text region.
I give up.
cesium
PS, I think I'll go take a bath. (Get it? cesium + H2O = boom!).
#4194 - mbcook - Sun Mar 23, 2003 3:49 am
Just a guess, but here is what I think is going on:
The GBA SP has an internal battery (as we all know) and that might be the problem. My guess would be that because it takes more current to write to flash (than to read it), you can't write to the cart because the GBASP won't give you enough current. Chances are that the GBA (with it's AAs) can give you that much current.
I would expect that plugging the thing into the wall would fix the problem, but you said it didn't. Now if the power sequence was like this:
Battery
|
|
+---- Electronics
|
|
AC
So that the AC bypassed the battery, I would expect that it would work. But it's possible that it's not setup that way. It could be setup like so:
AC-----Battery---Electronics
In this way, even with it plugged in, you're still limited by the battery. This could be the cause. OK, now that I'm looking at it, it looks more like it's the second case. The battery provides 3.6v, the AC adapter provides 5.2. That means it's probably the second case. Now let's see about current.
The GBA SP battery is rated at 600mah (according to a picture of it on lik-sang). Looking on the net standard AA batteries (alkaline) have at least 1200mah (double what the internal battery has). In fact, many AAs have 2500mah. Now in high draw devices, they won't give you their full performance, but the point is that they can supply lots more current.
After looking around the 'net for about 15 minutes I found a datasheet for a NEC flash chip (the brand used in your flash cart, don't know if it's the same one). That chip required 3-4x as much current to program it as it did to read it. I think it's quite possible that it just won't work on the GBA SP unless they (Visorly or whoever) redesigns the cart to need less current.
But please note: the GBA was never designed for in system flash programming like you're using it for. When you buy a product like that, that DEPENDS on an ablility that isn't officially there, you run a large risk that a redesign of the product will "break" your device. I suggest that you either just program things in your GBA (non SP), or you buy a cart programmer (I have Visorly's USB one for the GBA, very nice). Please don't fault Nintendo for unliscenced 3rd party stuff. If it was licensed and it didn't work that would be one thing, but you run risks with stuff like this.
_________________
--Michael
#4195 - cesium - Sun Mar 23, 2003 5:12 am
Interesting explanation. I'll look at bit closer at the Intel Advanced
Boot Block Flash data sheet (28F320B3) (Not NEC), to see if the
currents take a jump.
Hmmm, so I wonder what are reasonable currents that can be drawn
from the cart interface lines for peripherals that plug in there.
Do things like the TV Tuner and camera steal their power from
somewhere else?
I see your point about using a stand-alone cart programmer. But
I am bummed because I wanted to provide users of my product
with the ability to download software updates from the WEB and
re-flash the cart "in system." Now that I look at it, the Intel
StrataFlash chips that I am planning to use in my cart design
can really suck some current when erasing
and programming. I guess I could always design a flash
programmer into my CPLD and add a power supply. Boy that
cart would be crowded!
I'll write some code to read the Device Code and Manufacturer ID,
(That shouldn't eat much current should it?) just to test
writing to the flash chip's state machine.
Thanks for the helpful and insightful reply,
cesium
PS: Of course, I am not faulting Nintendo for this situation. Did my posts
imply that? If so, that was not my intention.
Also, I'll simply draw some current from the VCC supply and map
its DC output impedance. I really need to know if this is a show stopper
for my design.
#4205 - ampz - Sun Mar 23, 2003 2:47 pm
| mbcook wrote: |
Just a guess, but here is what I think is going on:
The GBA SP has an internal battery (as we all know) and that might be the problem. My guess would be that because it takes more current to write to flash (than to read it), you can't write to the cart because the GBASP won't give you enough current. Chances are that the GBA (with it's AAs) can give you that much current.
...
|
No, that's not it.
First of all, writing to flash doesn't require much current.
Second, if your explanation is correct, then the GBA supervisorcircuit would kick in and reset the entire GBA when you try to draw too much current.
One explanation might be that Nintendo has disabled the write ability to the 16bit cart bus altogether. A quick check with a logic probe or a osciloscope could answer that.
#4207 - tepples - Sun Mar 23, 2003 3:27 pm
| ampz wrote: |
| One explanation might be that Nintendo has disabled the write ability to the 16bit cart bus altogether. A quick check with a logic probe or a osciloscope could answer that. |
If a future GBA were to disable the Game Pak connector's write enable entirely, then games with EEPROM save would fail.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#4209 - cesium - Sun Mar 23, 2003 4:52 pm
I made a couple of observations this morning.
Using the original GBA (I'll call it TOGBA :) I sent over a program on the
multilink cable to read the manufacturer code and device code of the
flash chips. We know from previous work that you must write the
Visoly preamble to the cart in order to enable writing to the flash
chips. Also, the Intel Command User Interface (CUI) requires writing
to the flash chips in order to read the manufacturer code and device code.
This works on TOGBA:
Manufacturer Code=0x0089 (Intel. Correct value.)
Device Code=0x8896 (28F320B3T. Correct value.)
So I did the same thing with the GBASP running on batteries.
Manufacturer Code=0x0089 (Intel. Correct value.)
Device Code=0x8896 (28F320B3T. Correct value.)
Apparently I can write to the flash chips' CUI state machine.
I can identify the flash chips, but i-Linker cannot.
How odd.
Can anyone get the Flash2Advance system working on GBASP?
cesium (with a little cesium hydroxide)
#4211 - ampz - Sun Mar 23, 2003 8:11 pm
| tepples wrote: |
| ampz wrote: | | One explanation might be that Nintendo has disabled the write ability to the 16bit cart bus altogether. A quick check with a logic probe or a osciloscope could answer that. |
If a future GBA were to disable the Game Pak connector's write enable entirely, then games with EEPROM save would fail. |
True, but a simple adress decoder could solve that.
Doesn't matter, as cesium notes, that does not seem to be the case anyway.
How about wait states? Perhaps the SP boots at a different waitstate setting?
It can really be one of many things.
#4215 - cesium - Sun Mar 23, 2003 10:37 pm
Hmmm,
I should dump the waitstate config register to the screen
when my code starts up. I don't change it myself but there's
a butt-load of startup code from devkit and Jeff that I have not
read through. It might fiddle with it to produce a NULL result
experiment.
cesium
(Don't call me caesium.)
#4217 - cesium - Mon Mar 24, 2003 12:12 am
The waitstate reg (0x04000204) comes up 0x0000 on
both the original GBA (TOGBA) and the GBASP.
The supply voltage on the cart is a FIRM 3.300 volts throughout
the Flash2Advance's attempt to ID the Flash cart. No sag here.
cesium
(9192631770 and counting.)
#4218 - mbcook - Mon Mar 24, 2003 3:54 am
Well, it doesn't seem to be a voltage problem, or a current problem. We know the cart works because it works in your origional GBA. Well, maybe the answers to these questions can help us figure out what is going on.
1. Have you tried it in another GBA SP? Do you have access to one?
2. I assume you can still use the cart to play games on the GBA SP, you just can't write to it, correct?
3. Have you missed any ritualistic sacrifices to the GBA gods this month?
OK, maybe that last one won't help much. But I'm quite interested in the answer to #1. Maybe it's just your unit for some reason.
_________________
--Michael
#4220 - FluBBa - Mon Mar 24, 2003 11:50 am
Has anyone dumped the BIOS from the SP yet?
I don't know about revers enginering it, but maybe a simple filecompare can come up with somethings =)
/FluBBa
_________________
I probably suck, my not is a programmer.
#4221 - ampz - Mon Mar 24, 2003 12:51 pm
As far as I know, no one have even fully reverse engineered the original GBA BIOS..
#4244 - cesium - Tue Mar 25, 2003 5:05 pm
| mbcook wrote: |
1. Have you tried it in another GBA SP? Do you have access to one?
|
Nope. I only have 1 of these babys.
| mbcook wrote: |
2. I assume you can still use the cart to play games on the GBA SP, you just can't write to it, correct?
|
That's right. I can play games off the flash cart just fine.
| mbcook wrote: |
3. Have you missed any ritualistic sacrifices to the GBA gods this month?
|
Doh! I ran out of sacrificial AA batteries!
I really can't believe that I'm the only one on this forum that has
a GBASP and a Flash2Advance cart. Has anyone else had it work?
Could someone please cross post this question to other boards/forums
that they frequent?
Thanks,
cesium
(Don't call me caesium!)
#4266 - ronin64 - Wed Mar 26, 2003 9:26 am
Does this problem with Flash2Advance on the GBA SP mean that there will be a similar problem for the GBA SP and the GameWallet?
#4280 - gb_feedback - Wed Mar 26, 2003 1:57 pm
Over on the gbaemu boards there are people the F2A does work for, as well as people it doesn't. Someone suggested you have to have the light off. I wouldn't know - they haven't released the SP here yet.
_________________
http://www.bookreader.co.uk/
#4284 - Tseng - Wed Mar 26, 2003 3:56 pm
I've got a SP and a 256 F2A. When I first got the SP, everytime I flashed the cart it would give me odd bugs when I started it up (distorted GB title screen or the games wouldn't run on Pogoshell) so I just used my old GBA for flashing instead.
However, I tried it again yesterday and turned the light off as numerous people have suggested and it works fine. That's really the only advice I can give, is to have the light off before you start flashing. Doubt it'll help though, since even with the light on there's no reason the i-Linker shouldn't be detected.
Good luck.
#4301 - mbcook - Wed Mar 26, 2003 11:17 pm
Tseng, that makes absolutly no sense. Therefor, it must be the correct answer. Who knows why. Don't you love electronics?
_________________
--Michael
#4303 - ampz - Wed Mar 26, 2003 11:20 pm
Gee... Well... If the GBA SP power supply is _very_ poorly decoupled then I guess it could make a difference...
The light, does it have adjustable brightness?