Yep, it wont stop the copying , but then if a machine has to read
something (Cd / Rom / Dvd) , then anyone who can program can remove
protection , just by stepping though hex. But if it's a HW protection
that's another story

Copy protection is only intended to stop the casual copyier (i.e Numpty
with a burner), and if the crackers didn't release the crack , then 99%
of the peeps out there without the knowledge would either buy or not use

It's the 1% that can hack/crack that we will never stop , oh and the big
Hong Kong Copiers/Dupers are included in that :)

And don't forget that a Very high % of the stuff that ends up In WAREZ ,
was release from Dev/Beta/Duplicators before it even hits the streets,
and that just stupid we are kill our own jobs

C


-- Sig On --
Ppps. I know i can't spell and all my grammer is wrong , so there's no
need to point it out :)
-- Sig Off --


-----Original Message-----
From: groepaz [mailto:groepaz@...]
Sent: 01 June 2002 00:18
To: Chris White
Subject: Re: [gbadev] Re: To all unpublished developers - You may find
this very interesting...


Hello Chris,

Friday, May 31, 2002, 11:17:29 PM, you wrote:

CW> Okay heres my 2p (maybe go for 5p) worth of opinion

CW>         The Id key mentioned @ beginning of thread I think was
CW> intended for the PROGRAMMER , and only his Burner could program his
CW> carts (i.e someone wouldn't be able to take his DEMO/GAME , and
CW> overwrite it with there own i.e nick his rom)

CW>         And beens as this would then be a HW issue external from GBA

CW> , then hacking would be irrelevent . Unless they are into hacking
CW> Electronics etc (and that's not impossible for any HW)

err? that might be a possible solution for your specific problem, but
its kinda useless for copy-protection purposes dont you think?

--
Best regards,
  groepaz                            mailto:groepaz@...







Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

Hello Chris,

Friday, May 31, 2002, 11:17:29 PM, you wrote:

CW> Okay heres my 2p (maybe go for 5p) worth of opinion

CW>         The Id key mentioned @ beginning of thread I think was intended
CW> for the PROGRAMMER , and only his Burner could program his carts (i.e
CW> someone wouldn't be able to take his DEMO/GAME , and overwrite it with
CW> there own i.e nick his rom)

CW>         And beens as this would then be a HW issue external from GBA ,
CW> then hacking would be irrelevent . Unless they are into hacking
CW> Electronics etc (and that’s not impossible for any HW)

err? that might be a possible solution for your specific problem, but
its kinda useless for copy-protection purposes dont you think?

--
Best regards,
  groepaz                            mailto:groepaz@...

>A slightly different angle on the bleakness of it all :)
>
>Personally I don't think theres any point worrying or even
>considering piracy as an issue - piracy is always going to be there
>with any software based business

I agree completely.  Besides being easy to work around, protection
mechanisms like this bug me because they penalize the honest consumer
that wants to move the software from one unit to another.

I think ID software had the right idea when they released DOOM as
shareware instead of trying to wrangle a commercial distribution deal
up front.  Even people that had shamelessly pirated a great many
commercial games went ahead and sent ID money, simply because they felt
DOOM was so good.

Anyway, consider the following hypothetical business model for homebrew
GBA stuff:

1) authors release demos along with a contact address for donations.
2) the author maintains a homepage showing the amount of donations
received so far.
3) when the donations reach a certain level, the author is obligated to
make the final version of their game public.

This way, the authors make all the money they need before_ releasing
the game.

The money an author receives will be stimulated by the author's
reputation, the quality of the demo, and their past track record.

Piracy is not an issue at all.  In fact, the general public would be
encouraged to download and play and release games (demos or finished
products) whether or not they contributed to a past donation drive.

The release game serves as advertisement for future efforts.


__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

Okay heres my 2p (maybe go for 5p) worth of opinion

	 The Id key mentioned @ beginning of thread I think was intended
for the PROGRAMMER , and only his Burner could program his carts (i.e
someone wouldn't be able to take his DEMO/GAME , and overwrite it with
there own i.e nick his rom)

	 And beens as this would then be a HW issue external from GBA ,
then hacking would be irrelevent . Unless they are into hacking
Electronics etc (and that’s not impossible for any HW)

	 Which if this was the intended reason for the ID , then I would
love to have one, saves the risk of losing a £100 when some publisher
has you demo for evaluation, and LOOSES it (yeah right)

C


-- Sig On --
Ppps. I know i can't spell and all my grammer is wrong , so there's no
need to point it out :)
-- Sig Off --


-----Original Message-----
From: TJ [mailto:comfortably_numb_@...]
Sent: 31 May 2002 21:51
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] Re: To all unpublished developers - You may find
this very interesting...


Amen to that... the Big N has gotten away with a lot of twisting the
laws and actually puts up wrong information on it's page about how it is
illegal to own ram carts, etc. Fact is is that there are just as many
ppl using it for legitimate reasons than those that are not... some
probably use them for both. But they are amazing pieces of hardware that
hopefully will never be banned because they help the little guys so much
by knowing how theyre projects will work on real hardware before they
spend thousands on the 'official' devkit from N.
   ----- Original Message -----
   From: bryanedds
   To: gbadev@yahoogroups.com
   Sent: Friday, May 31, 2002 2:44 PM
   Subject: [gbadev] Re: To all unpublished developers - You may find
this very interesting...


   Nintendo doesn't make laws, and there are no laws that say you must
   be licensed to sell games for any system. Look at the Game Genie...
   it was never licensed! Legality isn't the question, but whether or
   not Visoly has the legal defense fund to keep Nintendo from warping
   current laws enough to sue is a question.






Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/

How about a petition to Visoly to show them how interested we are in
this product? Right now it's still in the air whether they will start
production or not. Perhaps some encouragement will do well?

--- In gbadev@y..., "bryanedds" <bryanedds@y...> wrote:
> Seeing as how publishers won't take risks on small developers, I
came
> up with an idea to circumvent the publishers and the entire
licensing
> process... But it required a special cartridge. Being no hardware
> engineer / manufacturer myself, I decided to give the idea to
> Visoly... the results were significantly better than I could have
> ever hoped... Here's the correspondence...
>
>
> From me -
> ----- Original Message -----
> From: "BryaN Edds" <bryanedds@y...>
> To: <info@v...>
> Sent: Saturday, May 25, 2002 12:11 PM
> Subject: How Visoly could help unlicensed developers to publish GBA
> games for free
>
> > If Visoly could manufacture a custom GBA RAM cartridge
> > that could store game images AND contain identifying
> > information unique to each card, then unlicensed
> > developers could publish to the GBA without obtaining
> > a license or finding / being screwed by a publisher.
> > You see, the game developer would create a game. Then
> > the customer would buy Visoly's GBA RAM cartridges
> > that have a unique ID. The game developer would then
> > create a game image that ONLY works on the GBA RAM
> > cartidge with the customer's ID. The customer then
> > downloads the unique game from the internet and
> > downloads the game onto Visoly's GBA RAM cartridge.
> > The customer will then put the cartridge into his GBA
> > and enjoy!
> > What are your thoughts?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
>
> From Visoly-
> Dear Sir,
>
> thank you for your interest in our products.
>
> We already looked into this and might offer this service to our
> customers
> end of 2002 or in 2003
>
> thank you for your kind attention.
>
> regards
> Lee/Sales Manager
> Visoly Inc.
>
>
> All I can say is WOW! Could this be the homebrewer's N-dependence
> Day? Write Visoly and tell if you're excited about this oppurtunity
> as I am! A little encouragement could move up / solidify their
> release date!

Amen to that... the Big N has gotten away with a lot of twisting the laws and
actually puts up wrong information on it's page about how it is illegal to own
ram carts, etc. Fact is is that there are just as many ppl using it for
legitimate reasons than those that are not... some probably use them for both.
But they are amazing pieces of hardware that hopefully will never be banned
because they help the little guys so much by knowing how theyre projects will
work on real hardware before they spend thousands on the 'official' devkit from
N.
   ----- Original Message -----
   From: bryanedds
   To: gbadev@yahoogroups.com
   Sent: Friday, May 31, 2002 2:44 PM
   Subject: [gbadev] Re: To all unpublished developers - You may find this very
interesting...


   Nintendo doesn't make laws, and there are no laws that say you must
   be licensed to sell games for any system. Look at the Game Genie...
   it was never licensed! Legality isn't the question, but whether or
   not Visoly has the legal defense fund to keep Nintendo from warping
   current laws enough to sue is a question.

I dont think the copy protection will work, I hate to say it but I think its
a big waste of time.  Most everyone in this forum can or should be
able to hack anything developed to protect the existing gba platform
(the platform itself was not built to discourage piracy so you have lost
before you started), of those some will have the motivation to do this,
of those some or one will either publish the tools or publish cleaned
binaries...

Low cost, one time programmable carts are the key, as well as control
over the carts and cart programmer.  I assume the
official licensees have access or have a cart programmer as well
as the ability to purchase blank carts.  If we truly think big N hasnt
a legal leg to stand on then someone like V should develop these
carts above and allow anyone who is willing to risk a reasonable fee
(like $50 - $100) to submit a game for distribution. (and not worry
about Ns license or copyright or patent or lawyers) V would control
distribution
or license it.  Whether this takes place or not I think those
who do distribute games should make OEM versions available (maybe
they are now I just havent looked).  You get rid of the fancy box and
glossy color manuals (and the other junk that lasts no more than 30 seconds
on its way to the trash can) and simply program a blank cart,
maybe / maybe not stick label on it, drop it in an envelope and put
about 50 cents worth of postage on it.  Increased sales, increased profit
margin,
etc: win-win  If V took over distribution you, me, and the person down the
street, could put up our own web page with the manual, etc, point to Vs
online store where the customer could purchase my game for $15 plus 50 cents
shipping and its win-win all around (even Nintendo and the current
licensees win)...
Even if we are limited to the existing licencees lower cost higher volume
sales could
encourage or allow more of us to publish...

Otherwise, if things stay as they are I can buy a PDA that does more,
faster, more memory,
free developer tools, no barrier to entry,  at a competitive price.  Only,
right now,
it lacks good buttons for gaming.  Actually Nintendo should chunk the GBA and
use their plants to build PDAs that have an emphasis on gaming...  I think the
current barriers to market are already forcing developers to other
platforms like
PDAs...Hell the PDA market is about to get hit by the cell phone market, it
wont
be long until your playing the current Tony Hawk game on your cell phone,
pause it,
check your calendar, and write your grandma an email for mothers day (or
just give
her a call)...

...sigh...

The REprogrammable carts really need to remain high priced enough
to discourage their use for piracy but reasonable enough to allow
developers into the market.  If you drop their price to within reach
of the OTP carts or such that they could compete with OTP carts
then there will be no more non-programmable cartridges sold and you
WILL get a call from many lawyers.  Likewise if otp carts and
cart programmers are cheap and easily available, same deal, download
the binary of your favorite game (they are all already on the net now for free,
and will continue to be) burn it onto your $15 blank and you have your own
personal copy for half price...Controlling the cartridge programmers will help
this, although many can hack that programmable device, of those some could
and will build a programming fixture, of those some or one will publish the
schematic and software...You need to lock it up, just not as tight as it is
now...

David

At 06:06 PM 5/31/2002 +0000, you wrote:
>--- In gbadev@y..., "ninge" <ninge@a...> wrote:
> > its a bit bleak really,
> > but i honestly dont see this working at all. think about it - can
>you
> > honestly say that this wouldnt be the case??
> >
>
>A slightly different angle on the bleakness of it all :)
>
>Personally I don't think theres any point worrying or even
>considering piracy as an issue - piracy is always going to be there
>with any software based business, the big problem with this whole
>concept as far as i can see would be the big N!
>
>Basically I reckon for this idea to succeed(financially), the
>cartriges would have to be marketed on a different scale to normal
>dev/piracy flash carts.
>
>The cartriges would have to be sold via retail outlets along side the
>standard ninty/GBA fair.  This would be great, make sure the set came
>with a couple of kicking games and plenty of cool game demos. Have a
>booklet of info with URLs for licencing/buying new games.
>
>The problem (apart from money) is that you need 'positive' exposure
>in the video game press which is mostly in the pocket of big N et al.
>So you're mostly going to see ass licking articles about how these
>carts will be the death of gaming etc...
>Big N will put HEAVY pressure on retail chains to block sales of the
>set.
>
>You need someone like wallmart to take it on - someone with enough
>clout behind them to give N the finger :) - but then wallmart have
>you over a barrel etc...
>
>Maybe A 'respected' company like Interact(gameShark) could get away
>with it - make the cart 3.5Mbit to stop piracy of standard games...
>they already have the retail ties established etc...
>
>cheers,
>col
>
>
>
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

> Now I assumed that the only reason to use the official
> library function to save game data was to allow it to
> automatically be routed to whatever type of backup
> memory the final production cart had (SRAM or
> EEPROM with possibly different h/w). I didn't believe

Nope, the official libs dont even do that. They just act as a communication
layer between your program and the hardware. That way Nintendo can be sure
the hardware is being accessed correctly.

> that it was involved with routing to the correct part
> of SRAM on a backup cart. I would have thought that
> diverting save game RAM addresses was down to
> the backup cart manufacturer.

Well, as you only normally have one game on a cart, the entire backup RAM is
available to the programmer to do as they will. My only guess is that the
ROM gets patched by the multi-cart writer to access different areas of SRAM
/ whatever for each ROM image.

I had assumed they would use a memory menagement type chip as they do with
the ROM images (as I understand), but maybe not...

Cheers,

--James

--- In gbadev@y..., "gb_feedback" <gb_feedback@y...> wrote:
>
> I have had a report that, when using the Book Reader in a
> multicart, it overwrites other saved games. I have also
> seen similar reports about other programs. A statement
> I read was that if a game did not use the standard
> Nintendo library function to save data in the cart then
> it had to be the first game on a multicart.

I can't see how any Nintendo library would anticipate
independent multicarts.

> For example what do the official [save game] library calls
> look like.

I am not a licensed developer, but if Nintendo developers think
the same way I think, they'd probably look like filesystem calls.

> And how does a Visoly cart separate the save games?

Bankswitching.  A Visoly 256 Mbit cart has four 64 KB banks of
battery-backed SRAM.  The "BSOD" looking menu assigns the first
three banks for the first three games on the cartridge and the
last bank for the rest of the games.  I have verified this by
writing several copies of my SRAM hex-editor to my cart.

--
Damian

Nintendo doesn't make laws, and there are no laws that say you must
be licensed to sell games for any system. Look at the Game Genie...
it was never licensed! Legality isn't the question, but whether or
not Visoly has the legal defense fund to keep Nintendo from warping
current laws enough to sue is a question.
--- In gbadev@y..., "Giuseppe Crugliano" <g.crugliano@a...> wrote:
> With Visoly cart there's already piracy problem.You can find on the
www many
> and many original rom downloaded from the original carts.So the
question is
> quite different...what Nintendo think of this idea?Is it legal this
kind of
> commercial operation??I don't know...
>       Giuseppe Crugliano
> Game Designer/Programmer

--- In gbadev@y..., "colinraybrown" <user@c...> wrote:
> Basically I reckon for this idea to succeed(financially), the
> cartriges would have to be marketed on a different scale to normal
> dev/piracy flash carts.
>
> The cartriges would have to be sold via retail outlets along side
> the standard ninty/GBA fair.  This would be great, make sure the set
> came with a couple of kicking games and plenty of cool game demos.

Perhaps we could contact the compo winners about licensing their
games for distribution on CD with the retail flash kit.
I'd certainly be happy to pitch in some games, demos, and apps.

> You need someone like Wal*Mart to take [on selling flash carts
> at retail] - someone with enough clout behind them to give N
> the finger :) - but then Wal*Mart have you over a barrel etc...
>
> Maybe A 'respected' company like Interact(gameShark) could
> get away with it

However, last time I checked, Interact sold both unlicensed and
licensed products.

> - make the cart 3.5Mbit to stop piracy of standard games

In other words, put mask ROM in the first four 128 KB banks of
the cart.  I'm assuming it would be relatively easy to change
devkit advance to use an origin of 0x08080000 instead of
0x08000000.  This might be just the ticket.

BUT... You'll then see unlawful "hacks" of popular games,
designed to relocate them to 0x08080000.

--
Damian

I am having a problem understanding saving 'games'.

In my Book Reader program I have been saving the
reading position, and bookmarks by writing them to
SRAM locations 0E000000h and making sure that
I write a byte at a time. This works fine (and obviously
assumes that the cartridge *has* static RAM.)

I have had a report that, when using the Book Reader in a
multicart, it overwrites other saved games. I have also
seen similar reports about other programs. A statement
I read was that if a game did not use the standard
Nintendo library function to save data in the cart then
it had to be the first game on a multicart.

Now I assumed that the only reason to use the official
library function to save game data was to allow it to
automatically be routed to whatever type of backup
memory the final production cart had (SRAM or
EEPROM with possibly different h/w). I didn't believe
that it was involved with routing to the correct part
of SRAM on a backup cart. I would have thought that
diverting save game RAM addresses was down to
the backup cart manufacturer.

Does anyone have any insight to help me here.
For example what do the official library calls
look like. (In principle only, if it offends anyone that I ask
such a specific question). And how does a Visoly
cart separate the save games?

--- In gbadev@y..., "ninge" <ninge@a...> wrote:
> its a bit bleak really,
> but i honestly dont see this working at all. think about it - can
you
> honestly say that this wouldnt be the case??
>

A slightly different angle on the bleakness of it all :)

Personally I don't think theres any point worrying or even
considering piracy as an issue - piracy is always going to be there
with any software based business, the big problem with this whole
concept as far as i can see would be the big N!

Basically I reckon for this idea to succeed(financially), the
cartriges would have to be marketed on a different scale to normal
dev/piracy flash carts.

The cartriges would have to be sold via retail outlets along side the
standard ninty/GBA fair.  This would be great, make sure the set came
with a couple of kicking games and plenty of cool game demos. Have a
booklet of info with URLs for licencing/buying new games.

The problem (apart from money) is that you need 'positive' exposure
in the video game press which is mostly in the pocket of big N et al.
So you're mostly going to see ass licking articles about how these
carts will be the death of gaming etc...
Big N will put HEAVY pressure on retail chains to block sales of the
set.

You need someone like wallmart to take it on - someone with enough
clout behind them to give N the finger :) - but then wallmart have
you over a barrel etc...

Maybe A 'respected' company like Interact(gameShark) could get away
with it - make the cart 3.5Mbit to stop piracy of standard games...
they already have the retail ties established etc...

cheers,
col

--- In gbadev@y..., Markus Glanzer <markus.glanzer@c...> wrote:
>
>
> > after all, they dont seem to mind that their  carts happily
> > circumvent nintendo's protection
>
> uhm, WHAT protection?

The primary protection on GBA carts lies in two measures:
* electrical interface uses a multiplexed address and data bus
* first 192 or so bytes of ROM must contain a valid header

Nintendo may have a patent on the electrical interface, but
multiplexed address and data buses have been around since
Intellivision.
http://tripoint.org/kevtris/intv/

In addition, ATA may constitute prior art.  Think of the
non-sequential read as a "seek then read" and the sequential
read as a "read".

Nintendo may have a trademark and/or copyright on the logo data
in the header, but in the United States, the Sega v. Accolade
decision rules out any possibility of enforcing this.
http://www.eff.org/Legal/Cases/sega_v_accolade_977f2d1510_decision.html

--- In gbadev@y..., "psx_nemesis" <jlawton@s...> wrote:
> Anyone have any suggestions on how I might [load binary assets such
> as images] in HAM C?  How do I get my code to reference something
> beyond the .GBA that is loaded in memory?

Take a look at GBFS, an archive format designed to store game assets
such as images and sounds.  The GBA-side library, written in C, is
under the MIT license and is clear for use in free and proprietary
software.  The tools are GPL'd.

To use GBFS:
  1. Pad your binary to a multiple of 256 bytes.
  2. Concatenate your binary and asset archive(s) into a .gba file.
  3. From the program, you can linear search for the first GBFS file
     in the ROM.  Then you can find other GBFS files.
  4. You can load objects by name.  In the next release, you will also
     be able to load objects by number.

Get it at http://pineight.com/gba/

--
Damian

Hello ninge,

Friday, May 31, 2002, 6:36:29 PM, you wrote:

n> sorry - I guess I should have added: [Please Note: heavy use of sarcasm] to
n> my last email..

n> what I ment was its all well and good them saying they are going to provide
n> these locked cartridges so that people can write their software and charge
n> people to download it - but in reality they are more than likely to be just
n> as happy to release non-locked carts or versions where the lock number can
n> be changed... after all, they dont seem to mind that their carts happily
n> circumvent nintendo's protection - so why would they worry about protecting
n> a small set of home developers?

n> the answer is that they wont. Or, if one company does, then another one will
n> pop up and make a cart that wont and then home-brew devs will have all the
n> same pirtating problems as official developers!

n> except of course that the people that buy these locked carts are likely to
n> be far more aware of these things and therefore more likely to end up
n> getting the dodgy carts to play the homebrew games.. its a bit bleak really,
n> but i honestly dont see this working at all. think about it - can you
n> honestly say that this wouldnt be the case??

thing is....even IF it worked (noone comes up with a cartridge to
circumvent the protection) its still a matter of a few weeks until
that protection would be cracked by "standard" methods - look whats
the situation with gp32 for that matter :)

--
Best regards,
  groepaz                            mailto:groepaz@...

> after all, they dont seem to mind that their  carts happily
> circumvent nintendo's protection

uhm, WHAT protection?

sorry - I guess I should have added: [Please Note: heavy use of sarcasm] to
my last email..

what I ment was its all well and good them saying they are going to provide
these locked cartridges so that people can write their software and charge
people to download it - but in reality they are more than likely to be just
as happy to release non-locked carts or versions where the lock number can
be changed... after all, they dont seem to mind that their carts happily
circumvent nintendo's protection - so why would they worry about protecting
a small set of home developers?

the answer is that they wont. Or, if one company does, then another one will
pop up and make a cart that wont and then home-brew devs will have all the
same pirtating problems as official developers!

except of course that the people that buy these locked carts are likely to
be far more aware of these things and therefore more likely to end up
getting the dodgy carts to play the homebrew games.. its a bit bleak really,
but i honestly dont see this working at all. think about it - can you
honestly say that this wouldnt be the case??

ninge

   -----Original Message-----
   From: groepaz [mailto:groepaz@...]
   Sent: 31 May 2002 16:43
   To: ninge
   Subject: Re[2]: [gbadev] Re: To all unpublished developers - You may find
this very interesting...


   Hello ninge,

   Friday, May 31, 2002, 5:05:32 PM, you wrote:

   n> yeah - and im sure the same people that make flash carts capable of
pirating
   n> commercial software will think twice before making ones capable of
pirating
   n> homebrew games! :rolleyes

   err? why? dont you think they make much more money by selling
   flashcarts to ppl who play pirated games than by selling flashcards to
   a handful of homebrew developers ?

   --
   Best regards,
   groepaz                            mailto:groepaz@...




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has scanned this email for all known viruses (www.inty.com)

Hello psx_nemesis,

Friday, May 31, 2002, 6:12:55 PM, you wrote:

p> He all,

p>   I scanned through the archives, and I couldn't find anything on
p> this topic, so I thought I would ask here...

p> I am using HAM GCC to compile my code.

p> Problem :  I have a routine that can read a buffer that is in my
p> format and display a menu so you can select an image from a little
p> menu.  I wrote some code that outputs a C array that I can compile in
p> my code that contains all the images, pallettes, and a little menu.

p> Display example :

p> Image 1
p> Image 2
p> Image 3

p> You can use up and down, and (A) to select the image, (B) to call the
p> menu back up.  Everything works fine.

p> Now the problem.  I want to be able to attach the data after I
p> compile the GBA code, and then be able to access the data buffer that
p> is appended to my compiled .GBA file.

p> Anyone have any suggestions on how I might do this in HAM C?  How do
p> I get my code to reference something beyond the .GBA that is loaded
p> in memory?

p> This would allow the slide show program to be a little more useful,
p> because I would be able to have a lot of images attached to the .GBA
p> without having to compile the image structures into my code.

p> Thanks for any help in advance.

very simple... just compile your data into a seperate object file...
the FAQ should give a couple of hints on how to do that


--
Best regards,
  groepaz                            mailto:groepaz@...

> n> yeah - and im sure the same people that make flash carts
> capable of pirating
> n> commercial software will think twice before making ones
> capable of pirating
> n> homebrew games! :rolleyes
>
> err? why? dont you think they make much more money by selling
> flashcarts to ppl who play pirated games than by selling flashcards to
> a handful of homebrew developers ?

heh, groepaz, don't you spot sarcasm when it slaps your face? :)

He all,

   I scanned through the archives, and I couldn't find anything on
this topic, so I thought I would ask here...

I am using HAM GCC to compile my code.

Problem :  I have a routine that can read a buffer that is in my
format and display a menu so you can select an image from a little
menu.  I wrote some code that outputs a C array that I can compile in
my code that contains all the images, pallettes, and a little menu.

Display example :

Image 1
Image 2
Image 3

You can use up and down, and (A) to select the image, (B) to call the
menu back up.  Everything works fine.

Now the problem.  I want to be able to attach the data after I
compile the GBA code, and then be able to access the data buffer that
is appended to my compiled .GBA file.

Anyone have any suggestions on how I might do this in HAM C?  How do
I get my code to reference something beyond the .GBA that is loaded
in memory?

This would allow the slide show program to be a little more useful,
because I would be able to have a lot of images attached to the .GBA
without having to compile the image structures into my code.

Thanks for any help in advance.

Regards,

Jeff

Hello ninge,

Friday, May 31, 2002, 5:05:32 PM, you wrote:

n> yeah - and im sure the same people that make flash carts capable of pirating
n> commercial software will think twice before making ones capable of pirating
n> homebrew games! :rolleyes

err? why? dont you think they make much more money by selling
flashcarts to ppl who play pirated games than by selling flashcards to
a handful of homebrew developers ?

--
Best regards,
  groepaz                            mailto:groepaz@...

With Visoly cart there's already piracy problem.You can find on the www many
and many original rom downloaded from the original carts.So the question is
quite different...what Nintendo think of this idea?Is it legal this kind of
commercial operation??I don't know...
       Giuseppe Crugliano
Game Designer/Programmer
----------------------------------------------------------------------------
-------------

  A  R  T  E  M  A  T  I  C  A  hi technology digital arts

  L'uomo ha imparato  prima a giocare, poi a scrivere.
   L'homme a d'abord appris à jouer, ensuite a écrire.

- Phone : +39 (0) 185 324660  -  Fax : +39 (0) 185 368490
- Mail artematica@... - Web www.artematica.com

----------------------------------------------------------------------------
-------------

----- Original Message -----
From: "Dave Mariner" <dave@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, May 31, 2002 11:09 AM
Subject: Re: [gbadev] To all unpublished developers - You may find this very
interesting...


> That sounds cool although there is one thing that springs IMMEDIATELY to
> mind.
>
> I presume that the UID is to stop piracy, yeah? Well, it would take the
> average cracker probably about 30 seconds to remove the protection
measures
> from the cart and release the crack on the net to make the game work on a
> standard flashcart.

[cropped by mod]

yeah - and im sure the same people that make flash carts capable of pirating
commercial software will think twice before making ones capable of pirating
homebrew games! :rolleyes

ninge
   -----Original Message-----
   From: a_bloke_from_ireland [mailto:a_bloke_from_ireland@...]
   Sent: 31 May 2002 13:50
   To: gbadev@yahoogroups.com
   Subject: [gbadev] Re: To all unpublished developers - You may find this
very interesting...


   I like the idea of games compiled to order so to speak.

   How about if the game title has a number of continuous security-
   checking mechanisms built in. See the following article at Gamasutra
   for what I am on about:
   http://www.gamasutra.com/features/20011017/dodd_01.htm

   Obviously the entire security hangs on the CART ID, so the trick is
   to make sure that the ID can't be replicated on an ordinary Flash
   Cart (A Read Only memory address not present on an ordinary CART).
   This means, the Flash Cart manufactures would also need to agree to
   never ever produce a CART where this ID code can be programmed by the
   games buying public.

   Emu authors could also do their bit for the cause and check for
   accesses to this location and abort if so.

   Did I just speak complete Boll@X?

   Niall :)


   --- In gbadev@y..., "Dave Mariner" <dave@m...> wrote:
   > That sounds cool although there is one thing that springs
   IMMEDIATELY to
   > mind.
   >
   > I presume that the UID is to stop piracy, yeah? Well, it would take
   the
   > average cracker probably about 30 seconds to remove the protection
   measures
   > from the cart and release the crack on the net to make the game
   work on a
   > standard flashcart.


   [cropped by mod]


   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has scanned this email for all known viruses (www.inty.com)

[snip]
>
> Emu authors could also do their bit for the cause
> and check for
> accesses to this location and abort if so.

Even if the emu coder takes care of this anti-piracy
check a cracker may modify the emu to ignore the code
check... or more simply can modify the game bin and
burn it on a normal flash card


______________________________________________________________________
Scommetti gratis sui Mondiali con Unibet.com!
http://it.yahoo.com/mail_it/foot/?http://ads.unibet.com/adverts/it/yahoo/

I like the idea of games compiled to order so to speak.

How about if the game title has a number of continuous security-
checking mechanisms built in. See the following article at Gamasutra
for what I am on about:
http://www.gamasutra.com/features/20011017/dodd_01.htm

Obviously the entire security hangs on the CART ID, so the trick is
to make sure that the ID can't be replicated on an ordinary Flash
Cart (A Read Only memory address not present on an ordinary CART).
This means, the Flash Cart manufactures would also need to agree to
never ever produce a CART where this ID code can be programmed by the
games buying public.

Emu authors could also do their bit for the cause and check for
accesses to this location and abort if so.

Did I just speak complete Boll@X?

Niall :)


--- In gbadev@y..., "Dave Mariner" <dave@m...> wrote:
> That sounds cool although there is one thing that springs
IMMEDIATELY to
> mind.
>
> I presume that the UID is to stop piracy, yeah? Well, it would take
the
> average cracker probably about 30 seconds to remove the protection
measures
> from the cart and release the crack on the net to make the game
work on a
> standard flashcart.


[cropped by mod]

that is correct im afraid..

honestly on a system like the gba having a managed "stack" of memory is
pretty over the top - my memory manager consists of a single pointer to the
start of free WRAM - as things get "allocated" (by either being dma'd there
or, more usually, decompressed there) this pointer gets updated.. at the end
of a the level I simply reset the pointer to the start of iwram and start
again.

dynamic allocation / de-allocation of memory is not really needed.

ninge
   -----Original Message-----
   From: James Daniels [mailto:james.daniels@...]
   Sent: 31 May 2002 00:10
   To: gbadev@yahoogroups.com
   Subject: Re: [gbadev] Emulator accuracy and imalloc


   Hi Tom,

   > Complete wrong attitude.  A couple of K of ram on a GBA is alot.
   > Recall this thing only has 384K of ram total.

   I know how much RAM it's got but I'd rather spend my time optimising
   other areas of the game than reducing RAM usage by 1 or 2 percent. Of
   course, if I really need the extra space then I'll write my own memory
   manager but for the time being I just want to be able to write data to
   IWRAM without risking overwriting my code or the stack. (Although I'm
   starting to get the impression that the only way I can do this is by
   managing IWRAM manually. Is this correct?)
   --
   Cheers,
   James.

       /\  apex                                 James Daniels
      //\\  designs            james.daniels@...
     //__\\                       http://www.apex-designs.net




   Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
         intY has scanned this email for all known viruses (www.inty.com)

As a side note...
I would not use -O3 with GCC. I have come across several verified compiler
bugs to do with function argument passing and inline problems. I would only
use -O2 and save yourself the hassle of tracking down a compiler bug that
will happen later on.


-----Original Message-----
From: colinraybrown [mailto:user@...]
Sent: 30 May 2002 22:08
To: gbadev@yahoogroups.com
Subject: [gbadev] Re: passing > 4 args to asm, is there a bug?


I seem to have got it working now -O3 and all - thanks for the help
guys.

[..]

That sounds cool although there is one thing that springs IMMEDIATELY to
mind.

I presume that the UID is to stop piracy, yeah? Well, it would take the
average cracker probably about 30 seconds to remove the protection measures
from the cart and release the crack on the net to make the game work on a
standard flashcart. Now this wouldn't be an immediate killer, apart from the
fact that the typical customer of Visoly products is likely to be tech-savvy
enough to be able to find these cracks. Also they'd be more likely to buy
the cart that'll run all games, as opposed to the cart that'll run only one.

Sorry to put a downer on you, as the concept is a good one...it's just that
the implementation is unlikely to work as a business model.

I hope I get proved wrong though ;o)

Best regards,


             Dave


----- Original Message -----
From: "bryanedds" <bryanedds@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, May 31, 2002 4:59 AM
Subject: [gbadev] To all unpublished developers - You may find this very
interesting...


> Seeing as how publishers won't take risks on small developers, I came
> up with an idea to circumvent the publishers and the entire licensing
> process... But it required a special cartridge. Being no hardware
> engineer / manufacturer myself, I decided to give the idea to
> Visoly... the results were significantly better than I could have
> ever hoped... Here's the correspondence...
>
>
> >From me -
> ----- Original Message -----
> From: "BryaN Edds" <bryanedds@...>
> To: <info@...>
> Sent: Saturday, May 25, 2002 12:11 PM
> Subject: How Visoly could help unlicensed developers to publish GBA
> games for free
>
> > If Visoly could manufacture a custom GBA RAM cartridge
> > that could store game images AND contain identifying
> > information unique to each card, then unlicensed
> > developers could publish to the GBA without obtaining
> > a license or finding / being screwed by a publisher.
> > You see, the game developer would create a game. Then
> > the customer would buy Visoly's GBA RAM cartridges
> > that have a unique ID. The game developer would then
> > create a game image that ONLY works on the GBA RAM
> > cartidge with the customer's ID. The customer then
> > downloads the unique game from the internet and
> > downloads the game onto Visoly's GBA RAM cartridge.
> > The customer will then put the cartridge into his GBA
> > and enjoy!
> > What are your thoughts?
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> >
>
> >From Visoly-
> Dear Sir,
>
> thank you for your interest in our products.
>
> We already looked into this and might offer this service to our
> customers
> end of 2002 or in 2003
>
> thank you for your kind attention.
>
> regards
> Lee/Sales Manager
> Visoly Inc.
>
>
> All I can say is WOW! Could this be the homebrewer's N-dependence
> Day? Write Visoly and tell if you're excited about this oppurtunity
> as I am! A little encouragement could move up / solidify their
> release date!
>
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On 31 May 2002 at 0:40, Jason Emery wrote:

>
> 1) What is the most accurate GBA emulator? By accurate I mean which
> one
> simulates the speed of a real GBA most realistically. In particular,
> do
> they simulate the difference in performance between IWRAM, EWRAM, ROM
> and VRAM?
>
> So far Mappy appears to simulate the difference as far as I can
> tell. I'm working pretty closely with it to figure out how fast my
> code is and make everything as quick as I can. IWRAM indeed operates
> much faster than ROM, for example, and yes I've run across the memory
> overwrite problem. (Had too many variables.)
MappyVM is pretty cool when it comes to debugging, but I wouldn't say it
emulates the hardware very accurately. I've seen many projects (including our
current one) that
don't work with Mappy and work perfectly with VisualBoyAdvance (no. 1 IMHO, when
it comes to emulation accuracy) and "the real thing" (of course). I don't know
what's
the latest version but I recall that it had problems with smull instructions at
some point, timers weren't working the way they were supposed to, etc.

--
-Maciej