gbadev.org forum archive

http://users.skynet.be/firefly/gba/e-reader/index.htm

this guy figured out how to put games on the e reader, no big news but kind of neat.

Wow this stuff sounds like fun. I wonder where it will take us as a homebrew community.

This seems much more exciting to me, but hasn't gotten much news...

Memory Stick Library

You can buy 4Mb memory sticks for $4 or an 8Mb for $6 and give your games to friends who don't have a $75 flash card setup.

ecurtz wrote:

This seems much more exciting to me, but hasn't gotten much news...

Memory Stick Library

You can buy 4Mb memory sticks for $4 or an 8Mb for $6 and give your games to friends who don't have a $75 flash card setup.

that does look very cool indeed
$6 :)

cheers

Col

I just ordered one of these 4MB "Memory Sticks" from Success-HK

Should be here in a few days... I'll let you guys know how it works.

Seems like a portable, low-cost alternative for multiboots, at least.

That's great I can't wait to hear from you if it works well. I want to possibly get some of them to give my games to my friends or for a job application. Let us know if they are worth the money.

So I got my memory sticks today, but I'm having trouble compiling the encryption and upload code. I'm getting some software updates to my computer next week that should fix the problem, but in the meantime I was wondering if anyone would be willing to lend a hand...

If you can download the Memory Stick Library code from above and compile it for me, I'll give it a whirl and write a report on my experience with the thing.

Specifically, I need the mbencrpt.exe to be compiled for WIN32. I'm pretty sure I can get the other part (smsflash.gba) to compile. (Though if you have HAM already and could compile that as well, it would save me some time, since I'd rather not setup HAM just to compile this one little GBA.)

Thanks to anyone who can help. Send me a private message or email me: scott -at- scottlininger.com.

Scott

At long last, I managed to compile the SMS tools from the link above, but I'm sorry to say that so far it hasn't worked.

Basically, there are three steps:

1. You "encrpyt" your .gba multiboot program into a "stick-friendly" format using a command-line tool called mbencrypt. This encryption basically pads the binary with some random garbage, does some word swapping, and embeds a token at the start of the program (0xCAFEBABE) so it will later know where to start the read from

2. You concatenate this encrypted file onto smsflash.gba, which contains the code which presumably talks to the memory stick

3. You run the resulting .gba on hardware and plug in your SMS (super memory stick), at which point the program detects the stick and uploads your encrypted multiboot

Steps 1 and 2 seem to work fine. But so far I've had no success with #3. The program runs alright, and it detects the stick, but it continually fails to "initialize" the SMS.

I'm swamped with other projects right now, so I don't have time to get into the code and figure out exactly how it's talking to the stick and why it's failing. I've done enough SIO stuff on the GBA to know that it's touchy, though.

Eventually I hope to figure it out. This is really a cool idea. The sticks are cheap and they're sexy looking to boot. Would be a great way to share little projects WITHOUT buying a $40 cart. Slap a glossy inkjet sticker on them and you have a nice looking game vessel.

I encourage others to delve into the code. It's released under the GNU license. I'll even mail you a stick if you want to give it a try (I bought 5 of them and I see little use for them if this never works.) Email me if you want to take me up on it (scott -at- scottlininger.com)

I tried to email the fellow who wrote it for help, but thus far I haven't heard back from him.

:(

I went through some pain reworking the code to compile without HAM, so let me know if you want me to send the source or binaries.

I ordered a couple sticks off eBay (thought I might test before putting in my 50 piece order from Xinga), but they haven't arrived yet. I did get a reply from Uli eventually when I was working on F2A support, so he does respond to things, but it was pretty irregular.

I'd love to get your no-HAM version of the code so I can do this on my Mac instead of getting everything running on the PC again.

- eli
<myfirstname>@nuprometheus.com

Okay, let me clean up the code to conform to the GNU license and I'll post it to my site. Stay tuned.

That would be great since I don't use HAM either. Post it here when it's done.

Guys,

When I was cleaning up the code I realized that the reason the non-HAM version failed to write to the stick (I think) is because I was compiling it wrong. There is one function (in stick_iwram.c) that must be compiled into IWRAM. I was NOT doing this.

So, I spent a little time trying to get that to work with my non-HAM version, and I'm getting compiler errors up the wazoo. HELP! If you can get this code to compile properly, I'll buy you a drink.

Anyway, the only part of the original code that uses HAM, as far as I can tell, is a few lines that print text to the screen. So, I've posted the non-HAM code in its current form, which IN THEORY will work with DevKitAdvance. But you'll need to create the makefile.

http://www.thingker.com/gba/SMS_Non-HAM_v1.zip

My offer still stands to mail a stick to anyone who wants one (for free, no less.) Just send me your address. scott -at- scottlininger.com

I sent a build of this to Scott, but I forgot to put it up anywhere. If anyone has a stick to test (I don't yet) I'll send you a copy of the binary if you want. I didn't have the copiler errors Scott mentions, but I'm using the Mac, so I may have a different GCC version.

I'll edit this tonight and give a link for a download as well. Once again, I have NOT TESTED the build, since I don't have my sticks yet.

Ok, I decided to give it a shot, and strangely enough it compiled with little difficulty. I uploaded the ROM and project I set up for it to http://www.angelfire.com/wizard/deku/smsflash.zip, so give it a try and tell me how it goes.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku

First of all, thanks to both Eli and DekuTree for sending me binaries/code.

Unfortunately, both of the binaries you sent fail to finish. Interestingly enough, the "incorrect" version that I had before WITHOUT the iwram compilation got a step further (it seemed to recognize the stick) than both of the new ones, which fail on the "1. Insert stick" step.

Also interesting is that the version compiled on the mac is slightly smaller than the version from Dekutree. Different crt.o perhaps?

Anyway, it looks like we're back to square one. I think the next step is to download HAM onto another computer and start fresh with the original code. It's always possible that I screwed something up in my non-HAM code or that HAM has some other linked startup code that does something sneaky.

It's also possible that the DOS command I'm using to concatenate the smsflash.gba with my multiboot is wrong somehow. However, I would think that this wouldn't keep it from recognizing the stick.

Unfortunately, I just don't have time to put an real effort into figuring this out. If you guys want to experiment and recompile, I'd be happy to test it. The frustrating thing is that if we could just get the original author to send us a binary, we could skip all of this guesswork.

My offer to send sticks still stands. :)

How annoying.

Scott if mine don't show up by this weekend I'll get you to mail me a stick. I have a PC sitting around I don't mind installing HAM on. My GBA time is limited, but I can probably give it a few hours over the next week or so.

Of course anybody who already uses HAM is encouraged to help out at this point... Bueller? Anyone?

I have done some HAM coding in the past and have the environment installed, though I'm not sure I can help you, I will try. I am bored at the moment.

I guess I will pick you up on that offer.
_________________
Little kids and Playstation 2's don't mix. :(

satanicfreak2 wrote:

http://users.skynet.be/firefly/gba/e-reader/index.htm

this guy figured out how to put games on the e reader, no big news but kind of neat.

I have actually been following this development, and even made an e-reader demo of my own, e-reader sound test. Available at http://www.alpha-ii.com/caitsith2/ereader under the saves section.

No luck with the HAM version either. Same problem as what Scott had. I really do wonder what the problem is though. It's not even related to HAM but something else instead.
_________________
Little kids and Playstation 2's don't mix. :(

dagamer,

So were you able to compile the original code? And if so, at what point is it failing?

Scott

Try adding *(vu16*)REG_RCNT=0x0; to the beginning of stickInit() - that seems to be getting me past initialization. Unfortunately I absolutely need to go to bed now, as it's crunchy at work, and now it's crapping out trying to write the header. Good luck gentlemen, I hope somebody has it working by the time I wake up (since none of you sleep.)

- eli

[edit] I think maybe it was looking in RAM for my data, even though I was running off of a cart. I'm at the grind, so I can't check until tonight.[/edit]

I was able to get the code to compile on the first try but it got stuck on the stick initialization process. I'll try your suggesting ecurtz.
_________________
Little kids and Playstation 2's don't mix. :(

We are progressing!! I managed to get it to write the header, but I'm not sure how long it will take to write the entire MB rom, and I think I may have pulled it out a bit during the process on accident. I will try again tomorrow, but right now I need some sleep.

Until tomorrow, that is, if I'm not out roaming around looking for new E3 info!!!
_________________
Little kids and Playstation 2's don't mix. :(

I decided to try it out tonight anyway and I had success in writing the multiboot ROM (i think).

But I'm not hooting or hollering. When I wanted to test it out, the stick wouldn't do anything, so I'm stuck at the "GAMEBOY" screen without a *ding*.

Now the stick is useless. But I get to keep both pieces like Scott said! Maybe I'll figure something out tomorrow.
_________________
Little kids and Playstation 2's don't mix. :(

Hrm.

If you can post the binary smsflash.gba somewhere, I'd be willing to give it a try with a different multiboot.

I have a pile of the things just begging to be guinea pigs.

Scott

OK, I just got to the point of nuking the stick as well, but it still responds to the writing code the same way, so no loss. Scott, I had to hack the header length code by putting a flag at the beginning as well as the end of the multiboot file. Now I suspect that my file is encrypted wrong due to stupid Endian issues. Here's the code I changed in smsflash.c

Code:

//-----------------------------------------------
// STEP 3: Write Header
//-----------------------------------------------

// find end of MB image
DrawBitmap(arrowData,16,16,10,82);
sof=0x8000000;
while((*sof != 0xdeadbabe) || (*(sof+1) != 0xcafebeef)) sof++;
eof=sof;//&end+(PAD_LENGTH/4);
while((*eof != 0xdeadbeef) || (*(eof+1) != 0xcafebabe)) eof++;

// set image size in stick header
tmp[0]=0;
tmp[1]=((char*)eof)-((char*)&sof)-PAD_LENGTH-4;

Then I just adjusted my mb file with a hex editor until I got it to get past the header step. The header may be the wrong size now, I didn't bother to try and figure out where &end actually would be to compare. I'll email you smsflash.gba, but obviuosly it won't work unless you want to mess with your encrypted file.

- eli

if we did ever get the stick flashing to work, since it can store more than a 256KB game, someone could make code to read extra data off the stick and store it in sram :) then later after progress in the demo/small game saveram could be written back to the stick :) :) :) :) :)

OK, I'm writing a valid header. If I boot the written stick I get the second stage logo, and then it just sits there pulsing. I'm sure my encryption is wrong, as I'm too braindead to do the whole endian back and forth crap on all the constants and bit operations at this point. At this rate I should get it working tomorrow night though.

Here is the fixed code

Code:

//-----------------------------------------------
// STEP 3: Write Header
//-----------------------------------------------

// find end of MB image
DrawBitmap(arrowData,16,16,10,82);
sof=0x8000000;
while((*sof != 0xdeadbabe) || (*(sof+1) != 0xcafebeef)) sof++;
eof=sof;//&end+(PAD_LENGTH/4);
while((*eof != 0xdeadbeef) || (*(eof+1) != 0xcafebabe)) eof++;

// set image size in stick header
tmp[0]=0;
tmp[1]=((char*)eof)-((char*)sof)-PAD_LENGTH-4;

if(stick_write_data(0,2,tmp))
{
   DrawBitmap(failedData,16,16,10,82);
   while(1);
}
DrawBitmap(passedData,16,16,10,82);

//-----------------------------------------------
// STEP 4: Write MB Image
//-----------------------------------------------

DrawBitmap(arrowData,16,16,10,106);
if(stick_write_data(0x840/blocksize, tmp[1]/4+1, sof+(PAD_LENGTH/4)))
{
   DrawBitmap(failedData,16,16,10,106);
   while(1);
}
DrawBitmap(passedData,16,16,10,106);
DrawBitmap(passedData,16,16,10,130);

while(1);

If you're using this remember I added my new flags to the start of the padding data (included IN the padding, NOT before.)

That guy's page has a very heavilly commented asm trace of the menu, and it seems it's version 0.9. Now on my little memory stick that Scott sent me, it's says 1.0. Now the guy that made the libstick (Uli) also has source to download the whole file from the stick, so I'll try that and see if the code's any different, cause I have tried everything and his code just isn't working.

OK, now we're making some progress. I have successfully booted up a couple of multiboot programs! Unfortunately they've been ones I built myself, so I'm not sure if the few I tried downloading had bad headers, or I'm using a different crt0.s or what [edit] solved, see below [/edit]. I've uploaded a new version of the stuff:

New Code

It doesn't have new Windows binaries as I'm on the Mac, but it does have a built ROM that you should be able to put on a card and use to flash your SMS. I commented my changes in the README - basically a marker for the start of the file and a little additional initializing.

Post your results, we've almost got it all working.

[edit] I figured it out. My stuff was length padded. That should probably just be added into the smsencrypt code. Will somebody try the 8Mb version? There's been some talk on the Yahoo group about putting in a group order if anybody is interested. I'm planning on getting a stack of them. [/edit]

Well done, Eli... I'll see if I can get the windows version working.

What exactly do you mean by "My stuff was length padded?" Like you say, if it's a standard requirement, it should be added to the encryption program.

It should also be smart enough to detect if the multiboot has a valid header, and add it if needed (if that's possible.) Since my flash2advance program automatically attaches a header, it must be.

Actually, this whole mess needs to be put into a single program. Any volunteers? I'll get to it eventually, but if anyone else wants to step to the plate...

My Multiboot files, either by chance or a difference in my build setup, were even lengths (8 words maybe, haven't tested to make sure.) When I zero padded one of the downloaded files to be the same size as one of mine it also successfully loaded. <edit> By extending the multiboot file length to a multiple of 8 words BEFORE ENCRYPTION I've successfully gotten all but one demo which ran on hardware with the f2a cable to work off of the stick. </edit>

The gba loader also needs to be adjusted to look in memory for the file if it's running as multiboot (or be clever and get the address of something and go from there, which seems like what it was trying to do before.) The demo I uploaded will only work if you're running from a cart.

I'd still like to hear if the sample works on 8Mb sticks, and somebody could make a nice project out of writing a menu loader for the thing... <edit> I ordered a couple 8Mb sticks off eBay but I'd still like to here from somebody sooner than the time those will take to arrive. Also I booted a 240k program and it took just over 30s. Not exactly speedy, but I guess cheap bastards can't be choosers. </edit>

Someone on the Yahoo group successfully tested this build on an 8Mb stick, so I ordered a set of them direct from Xinga. Assuming there are no snags (ordering from China always makes me nervous) I'll have some available at cost (about $5 plus shipping) if anybody wants a few to play with.

- eli

Eli,

So I assume you're going to work on some sort of library to load data dynamically from the stick? Otherwise, isn't the 8M stick pointless?

Scott

Quote:

So I assume you're going to work on some sort of library to load data dynamically from the stick? Otherwise, isn't the 8M stick pointless?

At least a menu system capable of loading new multiboot files. I think that Uli's stuff is most of the way towards just being able to get junk into EWRAM. No problem, right?!?

Has anyone else successfully flashed the Xinga stick? A critical mass of people to where this is "stable"?

Any work on the dynamically reading from the stick at run time?

Spektre

You guys gonna make me go buy and burn up my own sticks hunh?? :)

Spektre

It works. I haven't had much time to play with loading data in game. I'm planning on doing a menu system, but it might be a long time before I get around to it...

I'll give it a try and report back.

Spektre

I've had a couple questions about this, so here's the recap.

This code which I posted earlier has a working example (burn to cart and then flash stick from cart) and source code. Unfortunately for most of you the source code is for the Mac, and there are some endian issues you'll need to fix to get it working on the PC. They should be pretty simple fixes though, just compare my version to Uli's PC version of mbencrypt.c. (Scott's changes are included in mine, but his source seems to have been taken down.) Look for places constants have changed or I'm swapping bytes around.

I had a lot of trouble with invalid multiboot files. If the included test works you CAN get it to work for your projects. They need to have the correct header, and they need to be the correct length (when built!, not just pasted on to end.) My compile scripts were doing this stuff correctly, so I'm not sure how to fix it if your's are not.

Yeah, we sort of ran out of steam on this topic. I got distracted by a different project and I haven't been back to mess with it.

If anyone wants my source (which never worked, by the way,) I'd be happy to send it to them. PM me.

The only stuff I did in the source was to comment it, clean it up a bit, and create some output graphics that don't rely on HAM. The core "download" code simply never worked, though from what Eli found it may have been a problem with my multiboot ROM and not the original code...

-Scott

ecurtz,

So you actually burn this to the cart and then to the stick?? I would have thought it would go to RAM as a multiboot program and burn the stick from the multiboot RAM. My hope is to be able to allow people who don't have cartridges (but who do have a multiboot cable) a way to make their work portable.

Did anyone verify if the original HAM version of the code worked?

Spektre.

There's no reason you couldn't convert it to run as a multiboot program. You should probably have it wait for a keypress before looking for the stick. It was just a lot less complicated to do it with a cart while I was trying to get it working. I never tried building the HAM version as it was reported not to work and I do most of my GBA stuff on the Mac, but it may have just been invalid test programs the whole time.

...me get the sticks up and running. I was able to load ecurtz multiboot program, however when i insert the stick it fails "Stick initialization.

Spektre

OK, I got my new shiny 4M Xinga sticks here. I was able to compile Uli's original HAM code and run it. I get as far as "Insert stick" and it fails on Init.

I have tried ecurtz code as well and also get a fail on stick initialization.

I have tried 4 different sticks. Maybe Xinga changed their design? In any event I seem to be stuck. Any help or ideas?

Spektre

<insert standard excuse about how busy the damn job is>

Sorry to be slow here. Did you recompile the sample as multiboot? It won't work unless you did because it is looking for the code to transfer starting at a given value in ROM. It's possible the stick code has changed somewhat - what version are the ones you have? I have a bunch that flash before the menu 2003.11.24 as they start up and it works on them. You may also want to check earlier in the thread where I describe the communication register I had to reset to get past the initialization step.

Hope that helps. If none of that works you can PM me your address and I'll mail you a stick that I've tested.

eli

Well...It may be that it is new stick firmwae. My sticks boots up with a date of 5/20/2004. Once in the main menu it reads Memory CARD Manager v1.1.

I have added the register initialization you noted Eli, and no luck. Tracing through the code, I get to the stick_init routine.

Once in stick_init there are numerous reads with stick_xfer16.

The first is from location 0 and the code loops until it gets a 6202h.

Then it does 5 reads from 0x7200 and does nothing with the returned value.

Finally it reads location 0x2738, and if it receives a 0x9a5c the stick "inits" successfully. Anything else, and it does not.

I have checked and the reads from 0, 7200 and 2738 ALL return a 6202h on my stick.

I wish I had some idea what these locations were. They are all magic numbers to me.

Spektre

Look at GBATEK's description of multiboot. "0x6202" is one of the things the master sends in one of the stages of multiboot.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Spektre-

The big problem we were all having is that the ROMs didn't have the correct header. It's a common problem, I think, since most cartridge writing software automatically puts in the correct header.

You might email eli and see if he can send you the ROM that he had success with.

Somebody really needs to write a version of this thing that checks for those problems and solves them during the write phase. Eventually, I'll get to it, but it's on my back burner for now...

-Scott

Good catch tepples, but the rest of the exchange seems only vaguely related to the multiboot startup stuff. I'll check what replies my 1.0 stick gives next chance I get.

I did send Spektre a hacked together multiboot version of the loader and he confirmed that it did NOT work on his 1.1 sticks. Anybody here with enough ARM experience to easily reverse the new handshake protocol interested in this?

Hi all,

Tepples, thanks for the info. I have been comparing that to the older 1.0 assembly dump. It appears that the handshaking in 1.0 was not very close to the "real" multiboot protocol. Enough so that I can't follow how the two match up.

To summarize the old 1.0 handshake:

Send 0, receive value
Repeat until value is 6202h

Send 7200 5 times, do nothing with received values.

Send 2738, receive value.

If the value is 9a5c, you have a stick that is initialized and you can move on.

So far, anything I have thrown at teh stick returns a 6202h.

As Eli confirmed, his multiboot image did not initialize either.

I spoke with Uli and he explained how to get the SW from the stick, however it requires an MBV2 cable which I don't have. Anyone with one want to lend it to me, or I can lend you a stick to dump from.

Spektre

I have one you can borrow if nobody else responds.

Send me your info in email and I'll mail you the cable (and a 1.0 stick, while I'm at it.) Probably simpler than you sending me a stick as I haven't got HAM installed and have been doing all of my development on this stuff on the Mac.

OK, some success looking at the new firmware. It is relocating to a different area of memory and they have changed the handshaking.

I have updated Uli's original code to the new handshaking and IT INITIALIZES with the new sticks! Hooray.

Now I need to test it with a full image. I do not have a general pupose C compiler for x86 sitting around. Could someone compile the non_HAM_SMS version of the mbencrypt program and send me an executable? If not I can probably code it up in VB, but it will take a bit.

With this, I can see if with the new handshaking v1.1 sticks are useable as well.

Spektre

Great job!

If you catch this while I'm still at work (West Coast) and mail me the source I probably have time to do it...

If you were really desperate you could also probably cut the image off my sample one and use that. You'd need to hex the extra file marker ('CAFEBABE', or whatever) out or change your version of the gba writing to match mine.

Eli,

Done.

Ok I have ben beating my head against this for too long and am loosing interest in it. If there is someone who would like to help me, I am at a beginner level in gba development, have the project moved about 50% done and can provide a stick.

Must be willing to work in HAM, and have an xboo cable.

This just isn;t going anywhere on my own.

Spektre

Spektre,

I feel your pain. I hit against the same wall a couple months back.

This is still an incredibly cool idea, but it's just so hard to debug that you end up trying random changes to the code... And I think a lot of people are busy working on the compo right now, so interest in this little project is low.

Maybe after December I'll have some time to get back involved. Thanks for your efforts!

-Scott

Eli, I have a few questions for you.

Quote:

My Multiboot files, either by chance or a difference in my build setup, were even lengths (8 words maybe, haven't tested to make sure.) When I zero padded one of the downloaded files to be the same size as one of mine it also successfully loaded. <edit> By extending the multiboot file length to a multiple of 8 words BEFORE ENCRYPTION I've successfully gotten all but one demo which ran on hardware with the f2a cable to work off of the stick. </edit>

When you say a multiple of 8 words, do you mean a 32bit word?

Quote:

If the included test works you CAN get it to work for your projects. They need to have the correct header, and they need to be the correct length (when built!, not just pasted on to end.)

I've never done any multiboot stuff, is there a difference in the header for multiboot than normal gba files?

Quote:

My compile scripts were doing this stuff correctly, so I'm not sure how to fix it if your's are not.

Could you please post an example of your compile script so we could see how yours differs?

I can't get my program to get past writing the header to the stick, yet your demo works fine.

-Joe

Nevermind, I figured it out. It was the endian order at the start of the padding, and the fact that my compile script wasn't adding the logo into the header.

Joe,

Does this mean you are able to use your Xinga sticks now? If so, can you tell em what the date code is when you first boot up your new unprogrammed stick?

Spektre

Yes I have got some demos to work on the stick. I believe the date code for the stick is 2003.11.24. The firmware is version 1.0.

-Joe

Joe,

There is a new version of the firmware out. Interested in helping to crack it for use?

Spektre

I'll help where can, but I don't have much time to devote to the GBA.

Once the compo is over, maybe I can get one of you talented coders to help me RE the new Xinga sticks. (after all we have a while before the DS gets coder friendly!) :)

Spektre

I've been working on this off and on for a while now and thought you guys might like to have it.

http://joesextus.okiedreams.com/GBA/libstick_v2.2b.zip

I made a few changes to the smsflash.gba the most important of which is the reduction in size to 9.39KB. Eli's buil is 12.6KB (that leaves roughly an extra 3.25KB for your games to use.)

I also added the ability to have reset the gameboy by pressing START + SELECT + A + B after flashing is complete (You have to remove and reinsert the stick for the gameboy to recognize it though).

Has anyone tried to read from a stick yet?

I tried to read the length from the stick, but got only garage.

I changed this line in smsflash.c to

Code:

if(stick_write_data(0,2,tmp))

to

Code:

if(stick_read_data(0,2,tmp))

The length on my image is 0x00010460 but the function thinks that it has a length of 0xFFFFFFFE.

Any ideas would help.

I can read and write to the stick, but it does little good until I can figure out the encryption and location on the new firmware Xinga sticks. It should be added to the readme files that these routines are worthless with any stick bought from Xinga today.

Spektre

I can't even get libstick to read from the 1.0 sticks, can you show me your code to read from the stick?

Have you tried to copy Xinga's manager from RAM. To RE it?

I updated the readme in version of the library I released so it includes this:

WARNING: This library is currently compatible with firmware version 1.0 and 0.9 (I beleive) of the SMS sticks.

In stick.c there are read data and write data routines. Just use those. Maybe I'm not getting your question.

Spektre

When I use stick_read_data, the program gets stuck trying to read the header.

I see. I would suggest that maybe the firmware has changed a bit for you as well, although the writing routines seem to work ok...hmmm.... You can load new image files onto your sticks right?

What I found when re-disassembling the firmware on my stick is that the handshaking values had all changes for reading and writing. I had to rip the new firmware...find the read/write routines and update Uli's original C code to match the new handshaking.

My only problem is there is no way to tell where the new image should be written to or how it shoudl be encoded, and I haven't had any luck getting WntrMute's xboo console app to compile in HAM to help out with figuring that out. The only way I know how to get the new read/write handshaking is to redump the firmware, assuming that is what's wrong.

Spektre

I can write to stick just fine. It just won't read. Have you tried to copy the manager program? If you could get it and disassemble it the codes for reading and writing could be their.

Could you post your modified version of the library?

Yes, that is what I had to do. It is fairly time consuming but a utility to help rip it was with Uli's original code here....

http://www.emulinks.de/cgi-bin/viewcvs.cgi/libstick/reversing/smsrip.c

With that you can download the manager program, reverse assemble it, find the code for reading from the stick and see what the handshaking is for your rev of firmware.

I'll try and dig up my library, but it isn't usable as I cannot find where the manager program is being stoired on the stick or in what format. What I need to accomplish that is to be able to get WntrMute's xboo console routines to compile from HAM.

Spektre

Here's and idea that might help get you your commands, loop from 0 to 0xFFFFFFFF and when you get the expected return value output the value you passed in to the transfer function to SRAM of a cart and then read the cart's SRAM with a linker and it should give the valid commands. Then you can just start from that code if it is not a valid code.

Code:

u32 i;
for(i=0; i < (u32)-1; i++)
{
x = stick_xfer32(i)
if(x == 0x4b4f4d49)
{
write_to_SRAM(i); //write a function to handle this
break;
}
}
if(x != 0x4b4f4d49)
return RW_ERROR_CMD_NAK;

Joe,

I'm not sure I am following you. There are 2 issues.

1. You being able to read from a stick in your code. In order to do that, you will need to disassemble the manager program in your stick and find the correct way to access it. In mine for example the 0x4b4f4d49 code was different as were many of the "magic numbers".

2. For me to be able to load programs onto my stick, I need to be able to learn where the manager program's image is being stored and with what encryption. The on stick micro decrypts the data when being sent back for multiboot, so ripping it does not work. What would help there is reading the stick and sending the still encrypted contents back to a file via the xboo's console routines. No luck getting that to work in HAM yet though.

Spektre

I think we may be talking about two different things. Correct if I am misunderstanding you, but you do have the read/write codes for version 1.0.

Do you have a Flash Cart?

No, I do not.

I assume from other posters that Uli's original code was for 0.9 or at a minimum works with 0.9.

My sticks are v1.1 which I have also disassembled and have read/write codes for. From other's in the thread, v1.0 must store the multiboot code in the same place with the same encoding as you have noted.

I don't have a v1.0 stick here to rip and disassemble, sorry.

---

Now on my side, although I have read and write codes, I do not know how to encode my program or where to place it on the v1.1 sticks. The v0.9 method does not work.

Spektre

Joe_Sextus wrote:

I think we may be talking about two different things. Correct if I am misunderstanding you, but you do have the read/write codes for version 1.0.

Sorry about that I meant v1.1. I am not too concerned about me being able to read the stick at the point.
Have you tried reading from your stick and comparing it to the first n words of your dump? (ie 25 words at address 0 to the first 25 words in the manager then gotto address 1,2...)
It might be a way to get the address.

Thanks,

Yes, I have tried this but I am not having too much luck trying to decipher it looking at it a few bytes at a time (what I can dump to the screen). Thus the desire to get the console app working.

Spektre

I've noticed on a few sites offering the "writer" software for these sticks that HAM is needed to make the rom bootable from a memory stick.
I've HAM installed if anyone want to send a game to have compiled.
Also, does anyone have one of these memory sticks they would be willing to sell so I can try some stuff out myself, or recommend a (pref UK based) supplier?

Thanks - Chris

Hi Chris,

Actually HAM isn't needed, its just what Uli, the original reverse engineer on the project used. If you read back through the thread Eli has made a writer and "encrypter" that does not require HAM.

The problem comes in with the fact that new sticks you buy (and I have a lot to sell you) have updated firmware. With this new firmware, the old read/write code does not work and the ROM seems to reside either in a different place on the stick or with a different encryption.

Bottom line is, right now there isn't a way to use new sticks with your own code.

If you would like to help i getting this to work, and are a coder let me know, I'd like to collaborate with someone on it as I am progressing very slowly by myself.

Spektre

Spektre

While the sticks may have code encrypted in one way, It should be possible to upload a program to the gba, to fake the multiboot protocol that these sticks depend on, to upload its code. Once that is done, and the code is captured, the multiboot faker will then upload the captured decrypted code back to the PC, for reverse engineering purposes.

If you need help on the multiboot protocol, have a look at multi.c, in the MBV2 program, (at http://www.caitsith2.com/mbv2.zip (Also note that I implemented the planned but never implemented Turbo Multiboot.)) In general, a one byte seed is calculated into an xor key, that is depenedent on the address of the data being encrypted.

Caitsith2,

Yes, thanks.

That WAS the first step, but if you read back through this thread you'll see that THAT step was completed months ago. I HAVE the decrypted code using a multiboot "faker" program, for the v1.1 sticks.

The problem comes from trying to put a new program on the stick. Where does it go physically in memory on the stick? What format is it in physically?

Address translation and encryption exist on the stick's micro which reads from on stick's flash and sends out the serial data necessary for running the GBA in multiboot mode. This micro does NOT give up its code via multiboot. The only way to RE this that I know of, is to look at 1. the captured code via the mutliboot faker and then look at 2. the raw translated/encrypted data on the stick and look for a pattern.

Uli did this to the v0.9 sticks and found the pattern and location of the code. In order for me to do this, I would need to get a way to dump the raw data off the stick back to the PC for comparison and that is where I have been stalled for lo these many months. I haven't had any luck getting either the MBV2 cable to dump code back or WntrMute's xboo routines.

Spektre

On the encryption part have you tried writing values in at a location, and the reading them back? This may give you a start on the encryption part (unless it gives you what you put in).

Joe_Sextus wrote:

On the encryption part have you tried writing values in at a location, and the reading them back? This may give you a start on the encryption part (unless it gives you what you put in).

Just got back to this project a bit.

Yes reading from a position you just wrote to will give you the same value. The reading and writing routines work ok from the stick.

To boot from the stick though, the on stick micro will "unencrypt" the contents starting at a certain location. Therefore to have your program served up, you need to know how to encrypt it before writing it and where it needs to go.

Spektre

Any of the big brains REing the DS want to get in on this? This project is where all the ACTION is!!!

LOL

Spektre wrote:

That WAS the first step, but if you read back through this thread you'll see that THAT step was completed months ago. I HAVE the decrypted code using a multiboot "faker" program, for the v1.1 sticks.

Hi, I have a slightly different need than installing code on the SMS, and I've got some 1.0 sticks here.

I want to convince the code to write a smaller save into a larger save (for copying a save from a retail cart to a flash cart).

I tried to use "mbdumper" to get the multiboot image from the stick but couldn't. I suspect that if I could get that code I could patch it and run it off my flash cart.

What software did you use to dump the SMS multiboot code?

zigg wrote:

Spektre wrote:

That WAS the first step, but if you read back through this thread you'll see that THAT step was completed months ago. I HAVE the decrypted code using a multiboot "faker" program, for the v1.1 sticks.

I tried to use "mbdumper" to get the multiboot image from the stick but couldn't. I suspect that if I could get that code I could patch it and run it off my flash cart.

"mbdumper" is actually not for multiboot GBA to GBA communication multiboot dumping, ("Multiboot") (which MBV2 does), but Gamecube to GBA communication multiboot dumping. ("JoyBoot").

I used Uli's smsrip routines and they worked great.

http://www.emulinks.de/cgi-bin/viewcvs.cgi/libstick/reversing/smsrip.c

Spektre

zigg wrote:

Spektre wrote:

That WAS the first step, but if you read back through this thread you'll see that THAT step was completed months ago. I HAVE the decrypted code using a multiboot "faker" program, for the v1.1 sticks.

Hi, I have a slightly different need than installing code on the SMS, and I've got some 1.0 sticks here.

I want to convince the code to write a smaller save into a larger save (for copying a save from a retail cart to a flash cart).

I tried to use "mbdumper" to get the multiboot image from the stick but couldn't. I suspect that if I could get that code I could patch it and run it off my flash cart.

What software did you use to dump the SMS multiboot code?

Spektre wrote:

I used Uli's smsrip routines and they worked great.

Ah, that's what that code is for... :)

I don't have an mbv2, so I made a little hack to do an SRAM save of the dump to my flash cart instead, but I ended up with 0x32f4 bytes of garbage, or so it seems. Isn't this code decrypting? At least, that's what it seems like...

Hi,

I'm not sure what you are asking. What did you hack to do the save?...The libstick routines?

If so, no these routines do not do any decrypting. They are simple read/write routines only.

The firmware on board the stick does the decryption when needed to send the multiboot code to the gba. If you do a dump via the libstick routines, you will get an encypted multiboot image with the save data (I have no idea if they encrypt that or not).

Spektre

Spektre wrote:

I'm not sure what you are asking. What did you hack to do the save?...The libstick routines?

Sorry. I was talking about smsrip.

The smsrip program will send the multiboot program stored on the stick via the MBV2 cable to your PC. I'm not sure what good sending to RAM will do as you will need to disassemble the code to see what is going on, but yes...in this case the code stored in RAM should be unencrypted.

Spektre

Spektre wrote:

The smsrip program will send the multiboot program stored on the stick via the MBV2 cable to your PC. I'm not sure what good sending to RAM will do as you will need to disassemble the code to see what is going on, but yes...in this case the code stored in RAM should be unencrypted.

Well, it was to SRAM (I replaced the mbv2 calls with SRAM writes), so I could later retrieve it with the linker software. What I got didn't seem to be bootable in any way... I probably did something wrong. I'll have a few more whacks at it. :-)

Thanks for the insight.

Good luck. What type of a flash cart do you have?

Spektre

Just thought I'd ping and see if anyone is even looking at this anymore.

Anyone? Bueller?

Ok last chance on this and then I am moving on!

:)

What? no updates in 10 years on this? (LOL, The memsticks in question are probably no longer available.)

Better check back in another 5 years.

gbadev.org forum archive

Announcements And Comments > New way to put games on gba

#19449 - satanicfreak2 - Tue Apr 20, 2004 4:59 am

#19450 - zazery - Tue Apr 20, 2004 5:36 am

#19467 - ecurtz - Tue Apr 20, 2004 4:32 pm

#19476 - col - Tue Apr 20, 2004 6:57 pm

#19575 - ScottLininger - Thu Apr 22, 2004 6:55 am

#19577 - zazery - Thu Apr 22, 2004 7:18 am

#19729 - ScottLininger - Fri Apr 23, 2004 10:32 pm

#19962 - ScottLininger - Wed Apr 28, 2004 11:35 pm

#19967 - ecurtz - Thu Apr 29, 2004 12:45 am

#19976 - ScottLininger - Thu Apr 29, 2004 1:52 am

#19997 - zazery - Thu Apr 29, 2004 4:08 pm

#20252 - ScottLininger - Wed May 05, 2004 5:49 pm

#20307 - ecurtz - Thu May 06, 2004 9:16 pm

#20308 - DekuTree64 - Thu May 06, 2004 9:16 pm

#20324 - ScottLininger - Fri May 07, 2004 1:00 am

#20326 - ecurtz - Fri May 07, 2004 1:54 am

#20339 - dagamer34 - Fri May 07, 2004 10:04 pm

#20377 - caitsith2 - Sun May 09, 2004 10:05 am

#20423 - dagamer34 - Tue May 11, 2004 2:28 am

#20425 - ScottLininger - Tue May 11, 2004 4:42 am

#20433 - ecurtz - Tue May 11, 2004 6:59 am

#20473 - dagamer34 - Tue May 11, 2004 9:47 pm

#20490 - dagamer34 - Wed May 12, 2004 4:29 am

#20494 - dagamer34 - Wed May 12, 2004 4:45 am

#20500 - ScottLininger - Wed May 12, 2004 5:18 am

#20501 - ecurtz - Wed May 12, 2004 6:43 am

#20510 - phonymike - Wed May 12, 2004 9:22 am

#20570 - ecurtz - Thu May 13, 2004 6:10 am

#20687 - phonymike - Fri May 14, 2004 11:58 pm

#20810 - ecurtz - Tue May 18, 2004 5:37 am

#20933 - ScottLininger - Thu May 20, 2004 5:29 am

#20953 - ecurtz - Thu May 20, 2004 4:01 pm

#21220 - ecurtz - Wed May 26, 2004 2:16 am

#21272 - ScottLininger - Wed May 26, 2004 4:31 pm

#21274 - ecurtz - Wed May 26, 2004 4:39 pm

#24630 - Spektre - Sun Aug 08, 2004 5:46 am

#24786 - Spektre - Wed Aug 11, 2004 3:42 pm

#24790 - ecurtz - Wed Aug 11, 2004 4:38 pm

#25024 - Spektre - Sun Aug 15, 2004 5:15 pm

#25119 - ecurtz - Tue Aug 17, 2004 2:26 am

#25392 - ScottLininger - Sat Aug 21, 2004 11:10 pm

#25507 - Spektre - Tue Aug 24, 2004 5:59 am

#25530 - ecurtz - Tue Aug 24, 2004 2:48 pm

#26423 - Spektre - Wed Sep 15, 2004 5:14 am

#26494 - Spektre - Fri Sep 17, 2004 1:50 am

#26496 - ecurtz - Fri Sep 17, 2004 3:53 am

#26500 - Spektre - Fri Sep 17, 2004 4:37 am

#26515 - tepples - Fri Sep 17, 2004 1:50 pm

#26520 - ScottLininger - Fri Sep 17, 2004 4:39 pm

#26521 - ecurtz - Fri Sep 17, 2004 4:42 pm

#26524 - Spektre - Fri Sep 17, 2004 7:02 pm

#26527 - ecurtz - Fri Sep 17, 2004 8:22 pm

#26993 - Spektre - Fri Oct 01, 2004 4:31 am

#27031 - ecurtz - Fri Oct 01, 2004 9:22 pm

#27037 - Spektre - Fri Oct 01, 2004 11:23 pm

#27239 - Spektre - Thu Oct 07, 2004 7:40 am

#27249 - ScottLininger - Thu Oct 07, 2004 5:07 pm

#28601 - Joe_Sextus - Wed Nov 03, 2004 6:26 am

#28687 - Joe_Sextus - Thu Nov 04, 2004 3:24 pm

#29145 - Spektre - Fri Nov 12, 2004 5:38 am

#29157 - Joe_Sextus - Fri Nov 12, 2004 3:18 pm

#29221 - Spektre - Sun Nov 14, 2004 6:22 am

#29225 - Joe_Sextus - Sun Nov 14, 2004 5:11 pm

#30623 - Spektre - Thu Dec 02, 2004 9:46 pm

#31337 - Joe_Sextus - Fri Dec 10, 2004 6:09 am

#31725 - Joe_Sextus - Tue Dec 14, 2004 3:38 am

#32063 - Spektre - Fri Dec 17, 2004 6:53 pm

#32068 - Joe_Sextus - Fri Dec 17, 2004 8:42 pm

#32088 - Spektre - Sat Dec 18, 2004 2:15 am

#32095 - Joe_Sextus - Sat Dec 18, 2004 3:30 am

#32099 - Spektre - Sat Dec 18, 2004 3:53 am

#32101 - Joe_Sextus - Sat Dec 18, 2004 4:05 am

#32162 - Spektre - Sat Dec 18, 2004 9:15 pm

#32165 - Joe_Sextus - Sat Dec 18, 2004 10:30 pm

#32175 - Spektre - Sun Dec 19, 2004 12:46 am

#32180 - Joe_Sextus - Sun Dec 19, 2004 2:45 am

#32187 - Spektre - Sun Dec 19, 2004 4:25 am

#32189 - Joe_Sextus - Sun Dec 19, 2004 4:56 am