--- In gbadev@yahoogroups.com, Josh DeBonis <joshdebonis@y...> wrote:
> I'm trying to mix 2 sound samples on the GBA.  When I
> play them individually, they sound great. When I mix
> them together, a sound is produced, but it's not
> pretty.  I am simply adding the values of each sample
> together (it is a sample of the amplitude). I have
> tried scaling down the amplitudes before I add them,
> to prevent clipping, and this does not prevent the
> problem. Do I have to do any strange adding because of
> twos complement?  Anyone know what I might be missing?
>
> Thanks,
> Joshua

For example, at
http://www.work.de/nocash/gbatek.htm#soundchannelaandbdmasound you
can find that GBA's Direct Sound channels can reproduce sound of
signed 8bit data. therefore, if your input digitized sounds are 8b
signed, you needn't adjust it in any way.
mixing of 2 channels means:
1) doing average out of each input samples (in case of 2 channels it
really is: (sampleA+sampleB)/2)
2) clipping the result value to range of signed 8 bits ie. -
128...127.

btw. isn't the problem anywhere else? are you sure that, 4xmpl the
DMA suffices to the mixing speed, etc?
good day

Hi,
Im a graphic artist looking to hopefully teamup with somebody here to
perhaps work on a couple homebrew Ereader card games. Not only can I
do the artwork for the cards, and take them to get professionally
printed and cut, but I can also do sprite work. I'm hoping someone
else is out there with similar ideas. If your interested in
previewing my art, you can view my webpage(in sig below), and if your
interested in my previous sprite work, I can go through some backup
cds to see what I still have lying around. I think it would be a
unique summer project.

Regards,
Jesse
http://www.ayun.net/nomadik/

> Hello all I am new to the group and a novice gameboy developer. All
> the pages that I read say that you should download and install the
> gbdevkit. I have done that, but just looking at the zip file it seems
> just to be lcc. I already have lcc on my system do in need to install
> it again in the gbdevkit. Is there some file or zip that has just the
> gameboy specific files and tutorials that I need?

   It's gcc, and it's compiled for ARM support, I don't think your lcc is
compiled for cross development with ARM CPU support. (I forget the details
about lcc, but I'm suspicious it's x86 only)

   Also I think the build process of such gcc version was not as smooth, as
the Intel x86 and other common branches of gcc builds, and some patching
and editing was needed. (but I did never build it by myself, so I can be
wrong with those 3.x newer versions)

   I'm not aware of any GBA specific package as an add-on to standart ARM
gcc.

   On the other hand I had very positive experience with devkitadvance. If
you are at least a bit familiar with command line development and don't
mind gnu make, etc..., you will probably like the whole package too.
   I just recently tried to develop for PalmOS and Nokia S60 Symbian phones,
and their packages are lot less friendly to free developers, actually the
PalmOS doesn't support gcc at all for OS6.0+ (i.e. full ARM applications),
only the 5.0 is supported, and there you can make either M68K application
(which runs emulated on newer PalmOS devices) or use special protocol to
detect ARM processor inside M68K application and run the ARM code stored
as data by special interface. I was really put down by all the hassle.
   The Nokia S60 support is a bit better in some way. There's once again gcc
inside (builded upon some old 2.9.1 or so), it is used for "for device"
compilation and it's free and usable out of box. You can't build the newer
gcc with their ARM+SymbianOS support easily, this branch is not actually
supported by gcc development crew, so you are stuck to that 2.9. (unless
you are familiar with gcc code, and you can fix it by yourself)
   But still the debug build for "phone emulator" (it's simulator in fact)
is done by either Metrowerks Codewarrior or MS Visual C++, because the
simulator is running x86 binaries, simulating only entry points to
SymbianOS API.

   That's my recent experience with different embedded platforms, It may be
wrong at point or two, feel free to correct me, if you know more.
   But honestly I find the gbadevkit afterwards as very smooth and pleasant
experience to work with, if you want everything free and legal. (sort of,
beucase Nintendo never liked free developers)
   (if you don't mind to buy/get MS Visual Studio, the Nokia Symbian SDK
looks worth of try, PalmOS is worst, and unless you are really determined
to develop for it (or you need only M68K code, which will work w/o problem
for smaller applications, where you don't need CPU power)), don't try it
IMHO, it's not good for hobby developing)

   As stated above, it's personal experience, and I may be overlooking some
facts, and doing some stupid mistakes, resulting into poor experience.

   Err, the conclusion for you:
- don't bother, get devkitadv + some sources from free projects, and put
it on disc as different directory, don't mess with other gcc/lcc
installations, you will run sooner or later into problems not know by
others in community, and your non standard setup will make it hard to help
you in such case.

                    PED - Peter Helcmanovsky - wishing to have 48h days
               Braniskova 7 Kosice 04001 Slovakia / phone +420 721308701
     (_               -- actually in Brno, so don't look after me --
    "~/\~"      -=- deRATized RAT -=-  Being beyond Yer imagination  -=-
    ,_oo_,      7 GODS demo group WWW pages: http://7gods.org
      `'

Hello all I am new to the group and a novice gameboy developer. All
the pages that I read say that you should download and install the
gbdevkit. I have done that, but just looking at the zip file it seems
just to be lcc. I already have lcc on my system do in need to install
it again in the gbdevkit. Is there some file or zip that has just the
gameboy specific files and tutorials that I need?

> -----Original Message-----
> From: Ulrich Hecht [mailto:uli@...]
> >
> > "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?

32bit words - this is nothing to do with the SMS stick itself but rather
part of the GBA multiboot protocol. I'm surprised the stick loader doesn't
take care of this automatically but there you go. You might also care to
note that the image must be a minimum of 448 bytes (not including the
header) but I don't think that's likely to be a problem :)

Dave

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
> >
> >
> >
> >
> >