#36163 - Vince - Tue Feb 15, 2005 3:18 pm
Hello guys,
Here are the SC inner pics (attn 56Kers, big pics)
http://if2a.free.fr/Pics/SC_front.jpg
http://if2a.free.fr/Pics/SC_back.jpg
(destructive opening, as everything is glued together so be prepared to glue back if you want to attempt).
The part inventory :
+ Lattice ispMACH LC4128V : CPLD (Mach4000 family)
+ HY57V561620CTP-H (Hynix): 256Mbits SDRAM, 3.3V, PC133-CL3
+ M5M5V208AKV (Mitsubishi): 2Mbit CMOS SRAM , 2.7-3.6V, 70ns
+ 29LV400TC-90PFTN (Fairchild also avail. from Fujitsu): 4Mbits FLASH, 90ns, 3V
FLASH mem means the firmware upgrades are permanent (I thought you had to keep the file on the CF). I also looked at the firmware upgrade binary. Does not seems like a GBA ROM (header is missing, probably hardcoded into the CPLD) or maybe compressed.
My aim is to have a free software SC patching utility and maybe a firmware as well.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36192 - gb_feedback - Tue Feb 15, 2005 10:52 pm
Nice pix. I just got one of those carts today, so you saved me breaking it open! Thanks.
(Looks like a 50MHz xtal too)
_________________
http://www.bookreader.co.uk/
#36193 - Dwedit - Tue Feb 15, 2005 11:05 pm
How similar to the supercard to the movie player? Would hacks for one work on the other?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#36198 - Lynx - Tue Feb 15, 2005 11:29 pm
Well.. Hardware wise, the GBA Movie Player only has 2 chips.. and 1 has the manufacturer info sanded off.. so you can't even tell what kind of chip it is.
Edit: what hacks are avaiable for the Movie Player?
#36217 - tepples - Wed Feb 16, 2005 4:49 am
There are rumors on the pocket heavens that the GBAMP is just a Supercard without the 32 MiB RAM, that their I/O is similar.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#36223 - Lynx - Wed Feb 16, 2005 5:40 am
Ah.. Never thought of it that way. I figured it was sanded so that it would be harder to reverse engineer.. not cause they copied someone elses design.. :P
#36235 - Vince - Wed Feb 16, 2005 10:22 am
Hi,
Thanks for all the info.
Tepples, you surely meant the SC is the same as the GBAMP as the SC is newer than the GBAMP. This would ease hacking to have that info confirmed ...
As for the quartz, gb_feedback, I'd rather think it's 50Khz than 50Mhz. The latter would require far too much battery power IMHO...
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36243 - gb_feedback - Wed Feb 16, 2005 12:59 pm
Not sure Vince. It would take about 35mA, it's true. Just can't think what use a 50kHz Oscillator could be put to in this application, whereas the SDRAM certainly needs a fast clock.
_________________
http://www.bookreader.co.uk/
#36245 - Vince - Wed Feb 16, 2005 1:47 pm
| Quote: |
| Not sure Vince. It would take about 35mA, it's true. Just can't think what use a 50kHz Oscillator could be put to in this application, whereas the SDRAM certainly needs a fast clock. |
Interesting. You are probably right concerning the SDRAM which surely requires fast refresh cycles (as it's PC133). This would also explain why the battery time is so much decreased when using a Supercard VS a normal flash cart.
Is there a way to tell whether the XTAL is 50Mhz instead of 50Khz? Quoting from the package, it's not so obvious...
Where did you get the 35mA fact? The package seems to indicate something like 0.35 but I'm not usre either.
Thanks for the answers,
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36249 - gb_feedback - Wed Feb 16, 2005 2:21 pm
I did a search for the top line of the writing on the can but didn't come up with anything. The 35mA was from a catalogue of similar crystal oscillators of similar freqency, so purely a guess. I downloaded the data sheet for the Hynix SDRAM, and it talks about a system clock of, for example, up to 133MHz.
You could compare the (possible) 35mA with some measurements I made some time ago.
If I get time I'll measure how much current this cart takes.
A couple more things. I could not see any similar looking oscillators in our catalogue with a frequency as low as 50KHz. I guess you'd need either to id the manufacturer or put an oscilloscope on the output pin to be sure.
_________________
http://www.bookreader.co.uk/
#36265 - Dwedit - Wed Feb 16, 2005 6:33 pm
I was thinking about the possibility of making a multiboot program that would wrap around the arm instructions and log all DMA. I'm still wondering where I could store such a program in a location that won't get overwritten.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."
#36281 - gb_feedback - Wed Feb 16, 2005 8:48 pm
I made a quick measurement with a Bookreader program on the CF cart, so we could compare it with the last time I did this.
Bookreader V4.91 (Light Off) F2A cart.........17mA
Bookreader V4.91 (Light On) F2A cart.........41mA
Bookreader V4.91 (Light On) CF cart.........70mA
So the CF cart seems to take 29mA MORE than the F2A under these conditions. You can compare that with the fact that turning on the light takes 22mA. And the GBA SP + F2A takes 17mA.
_________________
http://www.bookreader.co.uk/
#36326 - Vince - Thu Feb 17, 2005 10:24 am
Hello,
Thanks for the measurements. I also had a great time reading your interesting findings about power consumption in your other thread.
The power consumption from the CF are absolutely HUGE compared to flash carts. This is no suprise the battery time is so much decreased! Isn't there a way to not power the CF while not doing anything so save battery power (just as the CPU can use idle calls)?
Dwedit : thanks for helping here. I also tried looking at the firmware upgrade with no success. It's probably compressed or is stripped from its header (surely hardcoded found in the CPLD). Having a SC firmware dump would be great.
I tend to think tepples observations about the SC being a ripoff of the GBAMP HW are correct (quoting from the original GBAMP site, they even took the same picture design and logo!). From what I learnt in the pocket heaven GBAMP thread, there is a mean to flash your own firmware to the cart as this is what they do when GBAMP are dead (you'll need a second GBAMP to do that apparently).
The other way around would be to try flashing a fake firmware update by renaming your code rom into firmware.scu. However, I don't know whether there is a protected boot block that acts as a recovery flasher (I don't have a flash burner at hand to recover flash failures) and don't want to end up with a 'dead' SC.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#36332 - MumblyJoe - Thu Feb 17, 2005 3:09 pm
| gb_feedback wrote: |
I made a quick measurement with a Bookreader program on the CF cart, so we could compare it with the last time I did this.
|
Thanks again for making bookreader more power friendly by the way, but could you test it out with a commercial game (not condoning piracy, rip one of your own etc etc) just out of interest, something power heavy if possible (I hear pokemon is a good power drainer but I havent noticed this myself, would have to be leaf.fire as saphire/ruby use RTC). I mainly request this because the bookreader doesn't exactly represent the average use of the gba.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!
#36336 - gb_feedback - Thu Feb 17, 2005 4:23 pm
If I get the chance I will, but I suspect the answer will be that the SC is around 29mA worse. I can't tell you what a pain these measurements are if you have less than 5 hands.
_________________
http://www.bookreader.co.uk/
#36520 - Vince - Wed Feb 23, 2005 11:02 am
Hello,
Did a little more twiddling with my SC yesterday and upgraded to 1.43. Much better IMHO with long filenames.
Concerning the upgrade, it's the name of the file (upgrade.scu) that triggers it. In the header is the version in plaintext. There is a data check (CRC?) before flashing, meaning that foolling the flasher with a dumb file would probably not work.
I am not sure whether there is a read-only bootblock on FLASH that would protect against corrupt/failed flashing so I did not go any further with my dumb file. The percentage growing while flashing the official firmware stopped 3 times (at 33, 66 and 99%) surely maybe there is indeed a bootblock and the 3 others are used for firmware usage (the FLASH chip contains 4 block IIRC).
That's it for today.
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#37246 - Vince - Wed Mar 09, 2005 10:15 am
Hiya,
Good news today : Dwedit has managed to dump the GBAMP firmware. This opens new possibilities for hacking the SC as the HW is very similar between both.
More info on the thread : http://forum.gbadev.org/viewtopic.php?t=5144
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#46989 - look - Sun Jul 03, 2005 3:42 am
As mentioned in several places the supercard wont currently work with passme/wifime.
Is the problem that the SCs bootmenu overides everything else?
Can one of you bright sparks do some hacking on the supercard to disable the bootloader as someone did with one of the standard gba EF cards.
Its not going to be practical to run commercial .NDS roms from the supercard as its so slow but it would be good for homebrew games, emulators and apps.
#46992 - tepples - Sun Jul 03, 2005 4:40 am
Problem is that the bootloader is designed to run in GBA mode. "Disabling the bootloader" doesn't work because the games are stored on block-oriented flash memory and have to be copied into the cart's RAM to run. The code to do this is also designed to run in GBA mode.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#46995 - look - Sun Jul 03, 2005 4:55 am
What does this mean in terms of flashing the DS firmware using either passme or wifime?
That the SC is not accessible in DS mode because nothing is in loaded?
people have suggested booting in GBA mode loading the file through the SC menu to get the rom in memory then power off and try again while its still in memory.
With the supercard if you reboot after loading something it stays in the memory for a short while. Going back into the menu after a reboot shows a cart in the slot.
I've never been able to go back to a rom after this so I doubt it would work
#47006 - look - Sun Jul 03, 2005 7:36 am
Just had a look on ebay with the intention of selling my supercard in order to get something that does work.
There is a seller now doing SC + free P&P for ?30 in the UK
I paid ?60 for mine :(
At this price surely its worth buying one to hack to pieces
#55576 - pipomolo42 - Thu Sep 29, 2005 4:44 pm
Hello,
I've read this thread with interrest, and would really like to know if there is any { 3rd party | homebrew | open source } project for this hardware for now ?
Thanks to the picture posted by Vince (http://if2a.free.fr/Pics/SC_back.jpg) and the doc available on http://www.latticesemi.com/products/cpld/4000bc/index.cfm, I think that the 6 pins available on the back of the SC are for JATG access to the CPLD. On the pic you can clearly see that one goes to pin 52 (TMS), and that another one goes to pin 74 (TDO) ...
I, for now, do really know nothing about CPLD and FPGA, but my guess is that they first solder the chip to the PCB, and then use JTAG to program the CPLD and the Flash.
Of course, I will need to read many docs about these technologies before being able to make "correct assumptions", but here is what I have for now :
- maybe we can read and write the content of Flash through JTAG (sounds probable, else the JTAG points would be useless)
- maybe we can also read the content of CPLD through JTAG (less probable ?)
- maybe we can even write the content of CPLD through JTAG (evel less probable ? but it could allow us to redefine completely the way the GBA or DS sees the SuperCard ! Would be lovely for the dslinux project ;) which would then get 32 MB more RAM)
- the CPLD is the "main" part, interfacing between the GBA port, the SDRAM, Flash and CompactFlash ... then I don't understand what is the exact role of the CPLD vs Flash...
- solution 1 : Flash contains the "botloader" for the supercard, it is code executed by the GBA, with the CPLD in between which "intercepts" some of the GBA calls and takes actions (read CF card, copy CF to ram ...)
- solution 2 : part of the CPLD is routed as a microcontroller, and flash contains code for it as well as for the GBA ... this sound much more impossible, improbable and complex, but also much more powerful ...
Now, I wonder : does this post sound completely wrong ? what are your comments, experiences, or impressions ?
Regards,
Alex
#55588 - Vince - Thu Sep 29, 2005 6:48 pm
Hello !
Interesting post here pipomolo. I'll try to add more to the pot here:
+ AFAIK there is no homebrew stuff available for the SC. I once wrote a PM to chism (the author of the GBAMP hack) to offer him to fund an SC hack and he advised me to simply try his GBAMP routines with the SC (given that SC and GBAMP are more or less rippoffs of each other). Did not have time to do this but may be worth trying
+ the link you gave to the Lattice site gives a 404. When I did the SC parts inventory, I could not find information either about the particular CPLD used in the SC either. Just hope it's a typo from your part and that docs are really available...
+ your assumption about how they manufacture the chip seem right to me. However, I think the JTAG interface is only used to burn the VHDL (or whatever) in the CPLD and that's all. This means it would not be possible to read/write anything with JTAG (fuse are burnt to prevent R/W access to the CPLD and I'd tend to think the Flash is not connected to this interface)
+ as for the CPLD, I think solution #1 is the right one. Keep in mind CF relies on ATA behind the scenes. A CPLD is suited here to handle the protocol implementation. The CPLD can also be used to disallow reads to the flash once the SC has booted (and that everything is in RAM). However, given that you can change game on the fly (IIRC, this is done via one hotkey combination but I may be wrong), this may not be the case (the SC needs the firmware routines to copy the ROM to its internal RAM).
That's it for now, but I agree it is a very interesting project for homebrew.
Vinz
PS: how is your EFA hacking going? Did you successfully RE the protocol?
_________________
Reclaim control of your F2A/F2AU with if2a !!
#55597 - pipomolo42 - Thu Sep 29, 2005 8:45 pm
| Vince wrote: |
the link you gave to the Lattice site gives a 404. When I did the SC parts inventory, I could not find information either about the particular CPLD used in the SC either. Just hope it's a typo from your part and that docs are really available...
|
Of course, the correct URL is : http://www.latticesemi.com/products/cpld/4000bc/index.cfm and more exactly http://www.latticesemi.com/products/cpld/4000bc/resources.cfm?ty=32&catid=130 (direct access to the datasheet, but you'll need to fill in a web form to get a (free) account to download them).
| Quote: |
| PS: how is your EFA hacking going? Did you successfully RE the protocol? |
Not really far : I gave up on reading & understanding the firmware assembly dump, maybe it was too hard, or not so fun any longer, or I am just too lazy ;)
#58890 - pipomolo42 - Thu Oct 27, 2005 12:08 am
just to make sure it's not lost, here is a picture of my CF SC, with the JTAG traced : http://boeglin.org/static/supercard/supercard_cf.jpg
I noted these differences with Vince's picture :
- RAM is faster (70ns instead of 90ns)
- SRAM is bigger (or at least, the supplier website has only references to 4Mb chips) but I haven't check if all is usable yet.
And JTAG works very well with the BSDL file provided by lattice and the JTAG tool from http://openwince.sourceforge.net/jtag/ with a cable build from this scheme : http://evilg.home.t-link.de/jtag-howto/ (with the addition of two AA batteries to power the CPLD)
#58924 - Vince - Thu Oct 27, 2005 9:45 am
Hello,
That's great news ! One question though : what do you mean by "works very well"? I see that the GPLed jtag program for openwince does not have support for Lattice parts so how can you assume it is working? Could you also precise what use has the BSDL file that Lattice provides?
Thanks for the info,
Vince
_________________
Reclaim control of your F2A/F2AU with if2a !!
#58938 - pipomolo42 - Thu Oct 27, 2005 12:55 pm
Hi,
First, I downloaded the cvs version of the jtag tool, which includes support for the lc4032v cpld in the data/lattice directory.
Then, I downloaded the file for "4128V 100pin" from http://www.latticesemi.com/ in Downloads/BSDL , added an entry in data/lattice/PARTS like | Code: |
| 0001100000010001 lc4128v-tqfp100 LC4128V-TQFP100 |
and added the directory, as a copy of the lc4032v one, and just used the "bsdl2jtag" command provided by jtag-tool to produce a usable file from the BSDL.
After ./configure, make, make install, I was able to to use the tool, it detected the chip correctly, and I was able to read and write the chip input/output status ...
Now, there are two things that can be done out of this :
- trace (on the board) which I/O are used from CPLD to flash, and you can then read and write the flash through the CPLD.
- modify the file obtained from "bsdl2jtag", add the In System Configuration commandsto it, and if they didn't bother to fry the CPLD fuse, we can read and write the "mapping" of the CPLD (But I have to read a lot more about this, first ;) ).
#59828 - darkfader - Fri Nov 04, 2005 11:17 am
Anyone tried to replace the oscillator yet? I've heard Supercards can't run at fastest mode. Perhaps I should confirm this myself.
Changing the CPLD contents is going a bit too far imho, but might be required to fix timing.
Just in case you didn't know yet: you can rewrite the firmware with the flashmp utility.