Hi!

On Wednesday 26 May 2004 14:31, tcharlier wrote:
> I get a working compiled version of Libstick from another GBA addict
> (sorry I do not know if I can publish his name). His version works
> fine with 8Mb sticks.

Hey, that's really good to hear. I hardly get any feedback on this
stuff, positive or negative.

> His advice is :
>
> "The big thing that I discovered after posting that version of the
> code is that the multiboot file you're encrypting must be a multiple
> of 8 words long or the encryption doesn't work! You can just pad
> them with a hex editor (must be done PRE-ENCRYPTION!) or add the
> logic into your version of the encryption tool."

Are we talking 16-bit or 32-bit words here?

CU
Uli

>
> The thing with using someone elses library is that you don't know
> how it REALLY works, only its interface. Later on down the road when
> making your game, you're going to want to do something difficult
> with the hardware, and it's going to be hard to do it because of the
> additional layer of abstraction.

If you want to solve the issue of the source code availability, you
can checkout The Sgade ( http://www.suddenpresence.com/sgade/ ), an
open-source GBA general-purpose library. At least, if you want to know
how it works, you can go and read the source. It's probably not as
optimized as HAM, but to start creating a few programs, it's a very
good start.

Best regards,

mathieu

Hi,

you do not need the source code for all your game components to pass the
Nintendo lot check. One of my registered members of HAMlib submitted and
passed Nintendo lot check for a commercial GBA game. Commercial developers
usually buy the source code version of HAMlib in order to get full control
over eventual bug fixes / additions that need to be made to the library.

Best
Emanuel
http://www.ngine.de


-----Original Message-----
From: Win Schutten [mailto:win.schutten@...]
Sent: Freitag, 28. Mai 2004 20:27
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] HAM or not to HAM?

If you are like some who plan to get the game released you do have to have
all the sourcecode to get it through Nintendo I have heard. Ham is great but
I don't know if they add the sourcecode for all their functions. Then again
I could be a n00b who fell for an urban myth cuz I have no idea if they
actually require all the sourcecode :).

> I have been trying to decide weather I want to write my new game
> using HAM, I hate the forced Splash Screen, but it has a fairly
> unsubstancial registration fee, or if I should write my game by
> hand.  Has anyone here used HAM/HEL?  And if so were you satisfied,
> disappointed by your experience?  Please let me know.  Thanks!







Yahoo! Groups Links

--- In gbadev@yahoogroups.com, "H. Dean Hunter" <deanhhunter@y...>
wrote:

I have used HAM for a short while to get me introduced to the
system. It is a good library but I eventually moved away from it to
see what it was doing on the inside.

The thing with using someone elses library is that you don't know
how it REALLY works, only its interface. Later on down the road when
making your game, you're going to want to do something difficult
with the hardware, and it's going to be hard to do it because of the
additional layer of abstraction.

Bottom line is this, if your game is really going to use the
hardware to its fullest, then you need to make your own library and
use it. Otherwise, HAM should suit your needs.

> I have been trying to decide weather I want to write my new game
> using HAM, I hate the forced Splash Screen, but it has a fairly
> unsubstancial registration fee, or if I should write my game by
> hand.  Has anyone here used HAM/HEL?  And if so were you
satisfied,
> disappointed by your experience?  Please let me know.  Thanks!

> If you are like some who plan to get the game released you do
> have to have all the sourcecode to get it through Nintendo I
> have heard.

you heard wrong...

If you are like some who plan to get the game released you do have to have
all the sourcecode to get it through Nintendo I have heard. Ham is great but
I don't know if they add the sourcecode for all their functions. Then again
I could be a n00b who fell for an urban myth cuz I have no idea if they
actually require all the sourcecode :).

> I have been trying to decide weather I want to write my new game
> using HAM, I hate the forced Splash Screen, but it has a fairly
> unsubstancial registration fee, or if I should write my game by
> hand.  Has anyone here used HAM/HEL?  And if so were you satisfied,
> disappointed by your experience?  Please let me know.  Thanks!

I have been trying to decide weather I want to write my new game
using HAM, I hate the forced Splash Screen, but it has a fairly
unsubstancial registration fee, or if I should write my game by
hand.  Has anyone here used HAM/HEL?  And if so were you satisfied,
disappointed by your experience?  Please let me know.  Thanks!

Thank you, Dave! Fantastic work!

> Xboo Communicator has been updated with a debug console and file server.
> Code for this has been added to libgba and a small example in the Sample
> Code section.

Xboo Communicator has been updated with a debug console and file server.
Code for this has been added to libgba and a small example in the Sample
Code section.

as always the files can be found at http://www.devkit.tk

Dave

I get a working compiled version of Libstick from another GBA addict
(sorry I do not know if I can publish his name). His version works
fine with 8Mb sticks.

His advice is :

"The big thing that I discovered after posting that version of the
code is that the multiboot file you're encrypting must be a multiple
of 8 words long or the encryption doesn't work! You can just pad them
with a hex editor (must be done PRE-ENCRYPTION!) or add the logic into
your version of the encryption tool."

So it works.

Regards.

Thierry

--- In gbadev@yahoogroups.com, Dennis Munsie <dmunsie@c...> wrote:
> I'd be willing to go for either of them... is it possible to get a mix
> of 4 and 8?  I wouldn't mind having a couple of each for when the
> problems eventually get worked out.
>
> dennis
>
> On May 1, 2004, at 10:40 AM, Daniel wrote:
>
> > Everyone was telling me they wanted the 8 Mbit version.  Is everyone
> > willing
> > to go with the 4?

http://www.devkit.tk

details available in the news section, windows binary in the downloads
section.

I'd be willing to go for either of them... is it possible to get a mix
of 4 and 8?  I wouldn't mind having a couple of each for when the
problems eventually get worked out.

dennis

On May 1, 2004, at 10:40 AM, Daniel wrote:

> Everyone was telling me they wanted the 8 Mbit version.  Is everyone
> willing
> to go with the 4?
>
> ----- Original Message -----
> From: "Michael Reid - CSCI/P2003" <m6reid@...>
> To: <gbadev@yahoogroups.com>
> Sent: Friday, April 30, 2004 4:58 PM
> Subject: Re: [gbadev] Re: memory stick retailer
>
>
>> hi,
>>
>>> No I don't. I get the message "Stick init failed" with a 8Mb Memory
>>> Stick. I have no 4Mb version.
>>
>> ok. so then was the bulk-order going to be 8-mbit sticks or 4 ?
>> it seems that due to the problems with 8-mbit then 4 is the way to go.
>> unless no one is interested in the 4-mbit version.
>>
>> regards,
>> -mike.
>>
>>
>>
>>
>>
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com.  Free s/h on orders $50 or more to the US &
> Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/cPRolB/TM
> ---------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

You need to find out what flash chips are in the cart, and info about
the custom ASIC in the cart as well.

Usually, you need to access a specific set of addresses to put the cart
into read/write mode.  Once that is done, you then can use the
programming sequence for the flash chip.  Usually, if there are two
flash chips, they will be interleaved with one doing the top 8-bits and
the other doing the bottom 8-bits.  Which means that to program them
successfully, you have to put both chips into write mode.

Most likely, the MBV2 software already supports the flash chip, just
not the ASIC.  To find out what you need for that, you will probably
need to disassemble the f2a code that the USB cable uploads to the GBA,
since that's the bit of code that will actually be doing the writing.

dennis

On May 2, 2004, at 2:38 PM, Mike Reid wrote:

> hi john,
>
>> Ironically though, most of the info you can extract from it is about
>> the
>> f2a usb cable, not about the flashing process itself.
>>
> yep, i took a closer look and i would have to agree, there is nothing
> that reveals the flashing process. i'm pretty sure i don't have any
> idea
> how to reverse engineer that, so this might not be possible.
>
> on the other hand, i seem to recall reading somewhere that actually
> writing to flash memory is the same across all carts, so it might be
> that the firmware just does the timing of the serial writes as opposed
> to
> the if2a code, which just dumps the data down the usb cable in
> manageably-
> sized chunks. the code for the timing of flash/serial writes should
> already be accomplished in Jeff's mbv2 code. and since the protocol is
> exposed
> in the if2a code, it might be possible after all.
>
>> A PC file-server for the GBA, whether through serial or USB
>> (provided you have the code to drive the USB cable) can't
>> be that hard to write from scratch ?
>>
> probably not too hard, but why would i want to duplicate work? in
> my estimation, adapting the if2a code to write to a serial interface
> would be easier than writing file-serving code from scratch. (assuming
> the above speculation is true and that it's possible)
>
>> I'de be very interested to hear about what you are doing. For myself,
>> I'd like to try driving the USB cable from a PC program to communicate
>> with the GBA (file-serving and more) so I'm always keen on following
>> what others have done in this domain.
>>
> i'm using the gba as an experimental platform for operating system
> development. so my first project is a from-scratch kernel, with
> pre-emptive multi-threading, a dynamic linker/loader, and other
> "standard" features of modern operating systems.
>
> obviously i can't do memory protection, or virtual memory, but that's
> okay. its actually part of why i am doing this on the gba rather than
> the
> PC--it simplifies things greatly.
>
> if you want to discuss this more, i suppose we should take this off the
> list, as its probably somewhat off-topic.
>
> -mike
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> Buy Ink Cartridges or Refill Kits for your HP, Epson, Canon or Lexmark
> Printer at MyInks.com.  Free s/h on orders $50 or more to the US &
> Canada.
> http://www.c1tracking.com/l.asp?cid=5511
> http://us.click.yahoo.com/mOAaAA/3exGAA/qnsNAA/cPRolB/TM
> ---------------------------------------------------------------------
> ~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

Hello ronald_chenu,

Saturday, May 1, 2004, 10:48:41 PM, you wrote:

r> Thanks Aleksey!, but I was asking for help with the compressor program
r> (coded for the PC) not with the decompression call to BIOS (in the gba).
r> Sorry if I wasn't clear enough, English is not my native language :(.

http://bwteam.org/pub/~vivid/pucruncher.zip

There are a packing tools and GBA decompression code for Pucrunch
packer.


WinAmp is Sleeping...
-- [ZX][GBA][Scene][Anime][Ot.A.Ma.][B.A.K.A. S.T.][Powered by Jenechka]
Best regards,
  Vivid / Brainwave Team                    mailto:vivid@...

From: "Stephen Stair" <sgstair@...>
> ...
> > With the MBV2 you'd have multiboot and file-serving out of the box,
> > but the ability to flash the card remains theoretical.
> ...
>
> MBV2 has capability to program flash cards, out of the box
> http://www.devrs.com/gba/files/mbv2faqs.php#ExactFA
>

Um, sure but that was the starting point of this thread, as we're
talking of F2A cards :

http://www.devrs.com/gba/files/mbv2faqs.php#FlashSupport

Does anybody have more info on why the MBV2 firmware
would support FA but not F2A ? Has anybody even tried
to write to an F2A from a GBA program ? It is obviously
possible but I wonder if there has been some kind of
protocol change between the FA and the F2A.

Any pointers to code or doc would be much appreciated.

Cheers,
--Jonathan

The 8Mb version might work. I am not a GBA specialist : my build of
Libstick may be wrong. Because I have no 4Mb version, I can not test
my build with the 4Mb stick.

Another solution could be to buy one 8Mb version and do the test yourself.

Regards.

Thierry

--- In gbadev@yahoogroups.com, "Daniel" <webmaster@i...> wrote:
> Everyone was telling me they wanted the 8 Mbit version.  Is everyone
willing
> to go with the 4?
>
> ----- Original Message -----
> From: "Michael Reid - CSCI/P2003" <m6reid@s...>
> To: <gbadev@yahoogroups.com>
> Sent: Friday, April 30, 2004 4:58 PM
> Subject: Re: [gbadev] Re: memory stick retailer
>
>
> > hi,
> >
> > > No I don't. I get the message "Stick init failed" with a 8Mb Memory
> > > Stick. I have no 4Mb version.
> >
> > ok. so then was the bulk-order going to be 8-mbit sticks or 4 ?
> > it seems that due to the problems with 8-mbit then 4 is the way to go.
> > unless no one is interested in the 4-mbit version.
> >
> > regards,
> > -mike.

On Saturday 01 May 2004 10:46, Stephen Stair wrote:
> MBV2 has capability to program flash cards, out of the box
> http://www.devrs.com/gba/files/mbv2faqs.php#ExactFA

Yes, but only the no-longer-produced Visoly cards, not the
currently available F2A cards.  That was how this whole thread
got started.

Rob

...
> With the MBV2 you'd have multiboot and file-serving out of the box,
> but the ability to flash the card remains theoretical.
...

MBV2 has capability to program flash cards, out of the box
http://www.devrs.com/gba/files/mbv2faqs.php#ExactFA

-Stephen

--- In gbadev@yahoogroups.com, Aleksey Malov <vivid@b...> wrote:
> Hello Ronald,
>
> I just made functions to read/write bytes from/to VRAM
>
> static int ReadVRAM(unsigned char *pData)
> static void WriteVRAM(unsigned char *pDest, int byte)
> --
> Best regards,
>                              mailto:vivid@b...
Thanks Aleksey!, but I was asking for help with the compressor program
(coded for the PC) not with the decompression call to BIOS (in the gba).
Sorry if I wasn't clear enough, English is not my native language :(.

Ronald

hi john,

> Ironically though, most of the info you can extract from it is about the
> f2a usb cable, not about the flashing process itself.
>
yep, i took a closer look and i would have to agree, there is nothing
that reveals the flashing process. i'm pretty sure i don't have any idea
how to reverse engineer that, so this might not be possible.

on the other hand, i seem to recall reading somewhere that actually
writing to flash memory is the same across all carts, so it might be
that the firmware just does the timing of the serial writes as opposed to
the if2a code, which just dumps the data down the usb cable in manageably-
sized chunks. the code for the timing of flash/serial writes should
already be accomplished in Jeff's mbv2 code. and since the protocol is exposed
in the if2a code, it might be possible after all.

> A PC file-server for the GBA, whether through serial or USB
> (provided you have the code to drive the USB cable) can't
> be that hard to write from scratch ?
>
probably not too hard, but why would i want to duplicate work? in
my estimation, adapting the if2a code to write to a serial interface
would be easier than writing file-serving code from scratch. (assuming
the above speculation is true and that it's possible)

> I'de be very interested to hear about what you are doing. For myself,
> I'd like to try driving the USB cable from a PC program to communicate
> with the GBA (file-serving and more) so I'm always keen on following
> what others have done in this domain.
>
i'm using the gba as an experimental platform for operating system
development. so my first project is a from-scratch kernel, with
pre-emptive multi-threading, a dynamic linker/loader, and other
"standard" features of modern operating systems.

obviously i can't do memory protection, or virtual memory, but that's
okay. its actually part of why i am doing this on the gba rather than the
PC--it simplifies things greatly.

if you want to discuss this more, i suppose we should take this off the
list, as its probably somewhat off-topic.

-mike

Everyone was telling me they wanted the 8 Mbit version.  Is everyone willing
to go with the 4?

----- Original Message -----
From: "Michael Reid - CSCI/P2003" <m6reid@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, April 30, 2004 4:58 PM
Subject: Re: [gbadev] Re: memory stick retailer


> hi,
>
> > No I don't. I get the message "Stick init failed" with a 8Mb Memory
> > Stick. I have no 4Mb version.
>
> ok. so then was the bulk-order going to be 8-mbit sticks or 4 ?
> it seems that due to the problems with 8-mbit then 4 is the way to go.
> unless no one is interested in the 4-mbit version.
>
> regards,
> -mike.
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>

From: "Michael Reid - CSCI/P2003" <m6reid@...>
> thanks alot john, you've really helped my understanding of the flashing
> process of these carts.

Glad to be of assistance.

> i found some f2a flashing code (for linux) from
http://deyv.free.fr/gba/f2a
> with source included. i think i'm going to take a risk and assume i can
> port that source to write through a serial interface, making the mbv2+f2a
> combo a full solution. i'd go so far as to say it might even simplify the
> code, as writing through a serial port is probably easier than through
> usb, but i'll have to investigate further.

Yes, I knew about that code, forgot to mention it in my previous email.
Ironically though, most of the info you can extract from it is about the
f2a usb cable, not about the flashing process itself. From what I've seen
they just use the f2afirm.hex code from the windows utility provided with
the cable, but they don't provide the source for that GBA code
(though reversing the interesting part shouldn't be that hard).

> the reason i'm so hung on the mbv2 is that it has some good pc
> file-serving code already written for linux. unless there exists such a
> thing for the f2a linker (must be for linux, or have the source available
> for me to port) it seems easier for me to use jeff's mbv2 file serving
> code.

A PC file-server for the GBA, whether through serial or USB
(provided you have the code to drive the USB cable) can't
be that hard to write from scratch ?

I still think an USB linker would be a better choice because you
would have the certainty of being able to flash the card, and the
possibility of file-serving with a bit of work, much of which has
already been done in if2a.

With the MBV2 you'd have multiboot and file-serving out of the box,
but the ability to flash the card remains theoretical.

In the end it all depends on which feature is more important to you,
I guess.

> i don't have any of the hardware yet, so i won't be starting for some
> time, but if anyone's interested i can post this when i'm done.

I'de be very interested to hear about what you are doing. For myself,
I'd like to try driving the USB cable from a PC program to communicate
with the GBA (file-serving and more) so I'm always keen on following
what others have done in this domain.

Could you please keep me in touch if you make any progress ?

Cheers,
--Jonathan

hi,

> No I don't. I get the message "Stick init failed" with a 8Mb Memory
> Stick. I have no 4Mb version.

ok. so then was the bulk-order going to be 8-mbit sticks or 4 ?
it seems that due to the problems with 8-mbit then 4 is the way to go.
unless no one is interested in the 4-mbit version.

regards,
-mike.

hi,

thanks alot john, you've really helped my understanding of the flashing
process of these carts.

i found some f2a flashing code (for linux) from http://deyv.free.fr/gba/f2a
with source included. i think i'm going to take a risk and assume i can
port that source to write through a serial interface, making the mbv2+f2a
combo a full solution. i'd go so far as to say it might even simplify the
code, as writing through a serial port is probably easier than through
usb, but i'll have to investigate further.

the reason i'm so hung on the mbv2 is that it has some good pc
file-serving code already written for linux. unless there exists such a
thing for the f2a linker (must be for linux, or have the source available
for me to port) it seems easier for me to use jeff's mbv2 file serving
code.

i don't have any of the hardware yet, so i won't be starting for some
time, but if anyone's interested i can post this when i'm done.

regards,
-mike.

--- In gbadev@yahoogroups.com, "Daniel" <webmaster@i...> wrote:
> Do you have any idea as to what need to be done to use the 8 mbit
version?

No I don't. I get the message "Stick init failed" with a 8Mb Memory
Stick. I have no 4Mb version.

Regards.

Thierry

> ----- Original Message -----
> From: "tcharlier" <thierry@c...>
> To: <gbadev@yahoogroups.com>
> Sent: Tuesday, April 27, 2004 3:17 AM
> Subject: [gbadev] Re: memory stick retailer
> > Be aware that I did not succeed in using Libstick with the 8Mb
version.
> >
> > Feedback welcome.
> >
> > Regards.
> >
> > Thierry
> >
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >

From: "Michael Reid - CSCI/P2003" <m6reid@...>
> hi
>
> > Where did you read that one couldn't program an f2a through
> > the mbv2 ?
>
> in the mbv2 faq: http://www.devrs.com/gba/files/mbv2faqs.php#FlashSupport

You're right. It looks like the MBV2 is not as flexible as the f2a usb
linker cable - apparently it would need a new firmware to
flash newer cards.

The problem is that the MBV2 does not offer a simple way for a GBA
program to communicate directly with the PC (there's a serial interface
but you need another cable).

The F2A cards are writable from the GBA, this means any program
that runs on the GBA can just flash the cartridge. Uploading such
a program to the GBA is very easy to do with the multiboot facility.
All that remains is for the uploaded code to receive the contents of
the cart from the PC - this data obviously can't all be transferred during
multiboot since the RAM is only 256KB.

This is exactly how the f2a/usb cable works : they send a little bit of
code through multiboot, which starts and listens for data from the PC.
The PC sends the cart data to the GBA, probably in UART mode,
and the code on the GBA writes that data to the cart.

So in theory, assuming you had connected your MBV2 to your PC's
serial port in addition to the parallel port, you could write that bit
of GBA code and the controlling program on the PC, and everything
would work just fine. I don't know of anybody who has done that, though.

But I think you should rather buy the f2a/usb cable, as its price is
negligible compared to the price of the flash card anyway. And it can
do everything the MBV2 can, and more.

Cheers,
--Jonathan

hi

> Where did you read that one couldn't program an f2a through
> the mbv2 ?

in the mbv2 faq: http://www.devrs.com/gba/files/mbv2faqs.php#FlashSupport

> In any case, it is not the cable (either the mbv or
> the flash advance linker) that programs the cart, it is the small
> amount of code that is uploaded on the GBA that does the writing,
> so there is no reason that you couldn't upload the appropriate
> code using the mbv2.
>

hmm. how hard would it be to do this? ie. is there software around to do
this, or am i looking at writing/porting code to do this myself?

sorry for all the seemingly pointless questions..just trying to figure out
the best solution for me without spending/wasting too much money.

regards,
-mike.

Im looking if have any 3D render for GBA? something like OpenGL or D3D...
Any links? I know that Yeti3D has port to GBA, but dont know how it was
made...

Thanks
--
;---------------------;
;linux user #129517   ;
;linux machine #56653 ;
;---------------------;

www.animalliberation.net

Hello Ronald,

Thursday, April 29, 2004, 3:41:38 AM, you wrote:

RCA> Although there are some LZ77 compression sources
RCA> available, does anyone knows what kind of
RCA> modifications (or code) does these compressors need to
RCA> be decompressed directly to VRAM? (like the VRAM safe
RCA> option in the GBA Crusher) .
RCA> I know its related tot the fact that the compressed
RCA> data should not reference to the previous byte in the
RCA> uncompressed data because it may not have been written
RCA> yet by 16-bit, VRAM sized BIOS function.


I just made functions to read/write bytes from/to VRAM

static int ReadVRAM(unsigned char *pData)
{
         unsigned char *pRead = (unsigned char*)(((int)pData)&0xfffffffe);
         unsigned short tmp = *(unsigned short*)pRead;
         if (pRead == pData)
         {
                 return (tmp&0xff);
         }

         return (tmp>>8);
}


static void WriteVRAM(unsigned char *pDest, int byte)
{
         //Get aligned address
         unsigned short *pVram = (short*)((int)(pDest)&0xfffffffe);
         unsigned short tmp = *pVram;
         if ((unsigned char*)pVram==pDest)
         {
                 *pVram = ((tmp&0xff00)+byte);
         }
         else
         {
                 *pVram = (tmp&0xff)+(byte<<8);
         }

}

--
Best regards,
  Aleksey                            mailto:vivid@...

Although there are some LZ77 compression sources
available, does anyone knows what kind of
modifications (or code) does these compressors need to
be decompressed directly to VRAM? (like the VRAM safe
option in the GBA Crusher) .
I know its related tot the fact that the compressed
data should not reference to the previous byte in the
uncompressed data because it may not have been written
yet by 16-bit, VRAM sized BIOS function.

Any help will be appreciated, thanks

Ron