On Monday 30 June 2003 18:31, nru wrote:
> Here is what I have
>
> . official Nintendo eprom carts for GBA (yes also SP)
> . official Nintendo eprom carts for GBC
>
> They *DO REQUIRE* official Nintendo development kit in order to be able to
> use them.  Without it, they are useless.  I am just trying to recover some
> of the money which was spent as these carts are no longer of use for our
> current projects.
>
> price: 50% of what Nintendo currently charges.  (Official developers
> approved by Nintendo can get this information so please do not ask me what
> the price is)

interisting how you can sell something that you have to give back to nintendo
after use.... care to explain? :o)

gpz

> > Here is what I have
> >
> > . official Nintendo eprom carts for GBA (yes also SP)
> > . official Nintendo eprom carts for GBC
> >
> > They *DO REQUIRE* official Nintendo development kit in order
> > to be able to use them.
>
> So the GBA carts aren't the kind where you can move a resistor and
> write to them with a Visoly Flash Advance linker, right?

Watch out for being flamed :)  He used CAPS!

Developers I know of don't use those carts. Publishers do. Well, that's my
experience.


Jan-Lieuwe

--- In gbadev@yahoogroups.com, nru <twkatx@a...> wrote:
> Here is what I have
>
> . official Nintendo eprom carts for GBA (yes also SP)
> . official Nintendo eprom carts for GBC
>
> They *DO REQUIRE* official Nintendo development kit in order
> to be able to use them.

So the GBA carts aren't the kind where you can move a resistor and
write to them with a Visoly Flash Advance linker, right?

--
Damian

Here is what I have

. official Nintendo eprom carts for GBA (yes also SP)
. official Nintendo eprom carts for GBC

They *DO REQUIRE* official Nintendo development kit in order to be able to
use them.  Without it, they are useless.  I am just trying to recover some
of the money which was spent as these carts are no longer of use for our
current projects.

price: 50% of what Nintendo currently charges.  (Official developers
approved by Nintendo can get this information so please do not ask me what
the price is)

Hi Pete

Not sure if this is what you're after. It's a technique I used to get the start
of the heap on the PSX.

You can assign values to variables from a link script.

Say you define a variable like:
extern unsigned long foo[];

You can then have a line in your ldscript like:
     foo = . ;

which will assign the current address being linked (ie. as far as the linker has
got) to "foo".

You might be able to use this so that you don't need to fix things at an
address.


Or, if you're really up with the fixing-at-address thing, you could *probably*
do it by:

- putting your code into a special section: "__attribute__
((section(".myhandler")))

- adding something like the following, probably after the ".text" section in
your ldscript:

     .myhandler <address you want to put the handler at> :
     {
         *(.myhandler)
     }

- assuming you're using Jeff's ldscript, you'd probably need to make sure that
the "__text_end = . ;" line came *after* your section.


I think that should do it, but my ldscript is a bit rusty ;)

Let me know how you get on

lx:)


Pete wrote:

On Fri, 27 Jun 2003, Damian Yerrick wrote:

--- In gbadev@yahoogroups.com, Pete <dooby@b...> wrote:

I want to implement either a Multiboot image or ROM (or preferably,
an easy switch between the two) which handles one or more of the
'magic' SWIs which jump to RAM areas.

Dangerous.  If these "magic SWIs" you speak of are what I think they
are (words in the range [0x02000000:0x03ffffff] that happen to follow
the SWI dispatch table), then they may change in future versions of
the GBA BIOS, breaking your program.


That's true, but it's only for demos really so I'm not too fussed. The
overall objective is to have a way to jump from USER mode to FIQ mode,
preferably without waiting for an interrupt.

I suppose I could hook onto the undef vector to be safer, but that still
requires a big cartridge and some fixed-address code.

Anyway, you'd have to write your own link script that places a
code section starting at a particular address in IWRAM.


That's the bit I'm rusty on :-) Any takers? Just a pointer to an example
demo which does this would do!

Cheers, Pete
--
http://www.bits.bris.ac.uk/dooby/






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

--- In gbadev@yahoogroups.com, "Justin Grimm" <grimmj1@b...> wrote:
> The code won't be huge, mainly little programs so I can use the gba
to program my robot via the serial port. Will this suit my needs?

In order to debug serial port code, you may want to get a UART cable.
There's one built into the MBV2.

> Is success compu good to order from?

You may find these Success stories useful:
http://forum.gbadev.org/viewtopic.php?t=1011

Conclusion: The shop lives up to its name.

--
Damian

Hi
I'm planning on buying a 64Mb flash2advance bundle pack with a USB linker from
success compu.
I want to develop code using goldroad and load it into the cart through a usb
port. The code won't be huge, mainly little programs so I can use the gba to
program my robot via the serial port. Will this suit my needs? Is success compu
good to order from?

Thanks in advance
Justin

From: "James Daniels" <james.daniels@...>

> How do I tell "as" that a certain symbol represents a register? So, for
> example, if "fubar" was set to be equivalent to "r2" then this..
[...snerp...]

what you want is the .req (register equate) directive.

fubar  .req  r2
     mov fubar, #0

one catch is that the name must be in all lowercase, which is annoying.  i
think it's gotta be left margin aligned, too.  bleh.

using it liberally has upped the readability of my arm assembly code 1000%.

regards,
matthew.

Hi all,

How do I tell "as" that a certain symbol represents a register? So, for
example, if "fubar" was set to be equivalent to "r2" then this..

mov fubar,#0

..would be equivalent to this..

mov r2,#0

I've tried .equ and .set but they don't seem to do what I want them to.
Obviously, I can still code without this feature but it would be a lot
more readable if I can find out what the appropriate directive is. (I
have checked the manual but I still can't figure out how to do what I want.)

Thanks for your help,
James.
--
     /\  apex                                 James Daniels
    //\\  designs            james.daniels@...
   //__\\                       http://www.apex-designs.net

A question asked previously was:
> i cannot get the a flash2adanvce card working using linux.
> as i use the fl programm from devrs.com together with the parport
> cable which cam with the card, the programm complains that it cannot
> find a connected flash linker.

Which card is it?

The 256Mb F2A cart uses two interleaved Intel i28F128J3A flash roms, just
like the old Visoly 256Mb FA Turbo.  It works as-is with mb (and most
likely fl).

On the other hand, the 64Mb and 128Mb F2A carts use different flashroms:
they both contain interleaved 28F320C3 flash roms.  The 64Mb has two
interleaved 28F320C3-Bs, and the 128Mb is the same, except that a second
pair follow.  I don't know if there is a simple way to detect whether a
64Mb or 128Mb is in use, but one can always try to unlock the first block
of the third flashrom and check whether it unlocked the first block of the
first flashrom instead.

Important differences between the J3 and C3 are that the C3 doesn't have
buffered writes and the 28F320C3-B has 8 blocks of 8192 bytes each and
then 63 blocks of 65536 bytes each.

Intel Advanced+ Boot Block Flash Memory (C3) page:
http://www.intel.com/design/flcomp/prodbref/298188.htm


Steven Fuller

On Fri, 27 Jun 2003, Damian Yerrick wrote:

> --- In gbadev@yahoogroups.com, Pete <dooby@b...> wrote:
> >
> > I want to implement either a Multiboot image or ROM (or preferably,
> > an easy switch between the two) which handles one or more of the
> > 'magic' SWIs which jump to RAM areas.
>
> Dangerous.  If these "magic SWIs" you speak of are what I think they
> are (words in the range [0x02000000:0x03ffffff] that happen to follow
> the SWI dispatch table), then they may change in future versions of
> the GBA BIOS, breaking your program.

That's true, but it's only for demos really so I'm not too fussed. The
overall objective is to have a way to jump from USER mode to FIQ mode,
preferably without waiting for an interrupt.

I suppose I could hook onto the undef vector to be safer, but that still
requires a big cartridge and some fixed-address code.

> Anyway, you'd have to write your own link script that places a
> code section starting at a particular address in IWRAM.

That's the bit I'm rusty on :-) Any takers? Just a pointer to an example
demo which does this would do!

Cheers, Pete
--
http://www.bits.bris.ac.uk/dooby/

--- In gbadev@yahoogroups.com, Pete <dooby@b...> wrote:
>
> I want to implement either a Multiboot image or ROM (or preferably,
> an easy switch between the two) which handles one or more of the
> 'magic' SWIs which jump to RAM areas.

Dangerous.  If these "magic SWIs" you speak of are what I think they
are (words in the range [0x02000000:0x03ffffff] that happen to follow
the SWI dispatch table), then they may change in future versions of
the GBA BIOS, breaking your program.

Anyway, you'd have to write your own link script that places a
code section starting at a particular address in IWRAM.

--
Damian

Hi all,

I want to implement either a Multiboot image or ROM (or preferably, an
easy switch between the two) which handles one or more of the 'magic' SWIs
which jump to RAM areas.

Ideally I'd like to catch one of the ones callable from ARM code, but I
can't find how to hook the two instructions I want (I guess):

ldr temp, =handler_location
ldr pc, [temp]

to a specific area of memory. I don't know whether this breaks the way the
linker puts code/data around it or if it takes care of such things.

Any hints? Cheers, Pete
--
http://www.bits.bris.ac.uk/dooby/

Hi all,

I know it's been done before but it's been ages since I released anything,
so here's a snapshot of something I'm working on. It's a rotating
texture-mapped cube, with full source (mostly in C). It has 3 textures,
one static and 2 generated, and manages a steady 60FPS in Mode 4 with no
pixel-doubling tricks.

L, R and D-pad modify angular rotation speeds. A shows usage - if the
green touches the bottom it means I've dropped below 60FPS which I don't
*think* it does ATM.

You can modify it to switch between 64x64 pixel textures or 32x32 pixel
textures by changing the TEXTURE_SIZE #define and the gfx link to
whichever you want. It makes no difference to the speed but the 64x64
looks higher resolution if a little 'grainy'.

You can also see the effect of a division Look Up Table (LUT) versus
calculated (either in EWRAM or IWRAM) by modifying the new_gba_div
#defines.

Finally, the size of the cube can be easily altered using the SCALE
#define.

Hopefully someone brave will implement a flame effect or plasma generated
texture and send me the results ;-)

Feel free to have a play, and mail me those bugs you find!

It's at the top of http://www.bits.bris.ac.uk/dooby/gba/index.html

Cheers, Pete
--
http://www.bits.bris.ac.uk/dooby/

Officiall comments by Alex Kampl / Lik Sang Intl.

I hope with the following Information I am able to give you a little
insight into the recent happenings and about the misleading press
release of Nintendo.

Before the Nintendo Press release has been distributed, I have delivered a
Notice of Appeal to Nintendo, as well as to the High Court of Hong Kong. I
am not exactly sure why Nintendo.s press department didn.t mention a word
about it. The Judgment was not a real trial yet, it was a Summary Judgment
with a single Judge. Usually such Summary Judgments are in case of bounced
bank checks where no trial is needed and everything is straight forward.

With all due respect to the High Court of Hong Kong, but no Intellectual
Property (IP) specialist was assigned to this case. Already at the first
hearing the Judge mentioned that it.s a pity Hong Kong has no IP specialist
anymore and that he finds the Copyright Law of Hong Kong very confusing.
After some research, it looks like the Judge is a specialist for maritime
laws. He made several comments during the hearings which seemed to observers
like this was his first IP case ever.

The Summary Judgment itself was based on the Section 273 of the Hong Kong
Copyright Ordinance about .circumventing a copy-protection.. No
copy-protection exists in the Gameboy or Gameboy Advance game cartridges.
The Judge didn.t hear a specialist or at least an independent 3rd party
expert opinion - he took it for granted from the explanations by Nintendo
that there is a copy-protection.

Furthermore, the Judge found that .by analogy with drugs, it[the setcion
273] is not aimed at the drug addict but at the drug trafficker.. I fail to
understand his logic, as this would mean that the drug store selling the
injection needles to drug addicts or maybe even the manufacturer of the
container where the drug addict keeps the drug could be held liable?

After legal actions in the USA against Bung Enterprises in the late nineties
(for selling and manufacturing videogame development and backup equipment)
this was the second Court Judgment ever regarding products of this nature.
Regarding information made available to me in the Court Room, the case
against Bung and its US distributor Carl Industries Inc was brought to an
end in their disfavor by Bung not complying with Court Orders and not paying
ordered penalties. The actual judgment was written by Nintendo
representatives, without the Judge properly going through the arguments.
The legality or illegality of the products in question has therefore never
been argued in a real trial anywhere in the world. A serious trial, with
competent Judges, is nowdefinitely needed to settle the question once and
for all. This is why I have decided to appeal.

I am not happy about the direction where this is heading, neither are
supporters and legitimate users of the tools. Again, I have to stress once
more, that the very same hardware under attack is used by thousands of
hobbyist users and even professional developers for legitimate purpose.
Very embarrassing for Nintendo: even the large publisher, who made the
original game used in Court for demonstrating purpose, bought hundreds and
hundreds of Flash Cartridges from my company for beta testing. And so did
numerous other top 10 publishers listed in the stock market.

The products I have sold are not circumventing any copy protections, same
as a Floppy Disk Drive and a 3.5" Disk doesn't. in fact there is no
copy-protection existing, as commonly known by the gaming industry.

I completely understand Nintendo.s fight against piracy, but I believe they
are aiming at the wrong targets. With Digital Media and the Internet
nowadays, publishers will have to change their strategy. They just can't
win the fight against the Progress without removing our primary rights:
presumption of innocence and the right for backup. Nintendo doesn't need
to prove you are a pirate anymore, it is assumed you all are if you have
the technical means to copy.

On Friday 20 June 2003 07:23, TJ wrote:
> I would like to know what this 'embedded security' is? I'm sure the entire
> case was dependant upon this so called 'embedded security'. As we all know
> the GB/C nor GBA had any security devices other than having to use the logo
> data in order to start up. And I'm sure everyone knows about Sega V.
> Accolade. There goes homebrewing and the cheap alternative to buying
> Nintendo's development kits...

embedded security == not user writeable ROM cartridge.

i am personally waiting for cd-r beeing declared illegal :=P

gpz

Will the multiboot cable still be available?

Luckly for the hard core home brew person there are already plans for flash
carts for the agb.  As long as the multiboot cable can be purchased or a good
set of plans are available then one can still get the job done.

How will this case affect the emulators?  Most of the kids I have seen do not
flash pirate gba games, but play them on their desktop pc.

I would like to know what this 'embedded security' is? I'm sure the entire case
was dependant upon this so called 'embedded security'. As we all know the GB/C
nor GBA had any security devices other than having to use the logo data in order
to start up. And I'm sure everyone knows about Sega V. Accolade. There goes
homebrewing and the cheap alternative to buying Nintendo's development kits...
   ----- Original Message -----
   From: Samuel Watson
   To: gbadev@yahoogroups.com
   Sent: Thursday, June 19, 2003 1:23 PM
   Subject: [gbadev] Nintendo against LikSang


   Hi,
   I just came accross that news about the case opposing Nintendo to LikSang. I
   thought it might be of interest... So I guess people have to rush to FLinker
   and the like...

   [06.19.03]


   Nintendo Scores Victory Against Chinese Piracy

   In a victory against software pirates in China, Nintendo said today that it
   won a court battle against Lik Sang International, which made a device that
   bypasses the embedded security in Game Boy and GBA games.

   Nintendo described the victory as one of its "most significant anti-piracy
   judgments ever", after a Hong Kong judge ordered LSI to pay an interim
   amount of HK$5 million (US$641,000) in damages. The device, called the Flash
   Linker, plugged in to the printer port of a PC and could send and receive
   game ROM data to and from Game Boy and Game Boy Advance Flash cartridges.
   While the devices were marketed as "backup" solutions for players, games
   quickly found their way onto the Internet, and widespread piracy of Game Boy
   and GBA games ensued. (The company also sold rewriteable Flash cartriges.)

   Nintendo sought US$20 million in damages in its original complaint, for lost
   revenues in 2001 and 2002.

   LSI has been under legal attack from Sony, Microsoft and Nintendo since last
   year, due to the numerous mod chips products it formerly sold. The company
   agreed to be acquired by a larger firm, Pacific Game Technology, in large
   part to help underwrite its court costs. instantanée de France

Hi,
I just came accross that news about the case opposing Nintendo to LikSang. I
thought it might be of interest... So I guess people have to rush to FLinker
and the like...

[06.19.03]


Nintendo Scores Victory Against Chinese Piracy

  In a victory against software pirates in China, Nintendo said today that it
won a court battle against Lik Sang International, which made a device that
bypasses the embedded security in Game Boy and GBA games.

Nintendo described the victory as one of its "most significant anti-piracy
judgments ever", after a Hong Kong judge ordered LSI to pay an interim
amount of HK$5 million (US$641,000) in damages. The device, called the Flash
Linker, plugged in to the printer port of a PC and could send and receive
game ROM data to and from Game Boy and Game Boy Advance Flash cartridges.
While the devices were marketed as "backup" solutions for players, games
quickly found their way onto the Internet, and widespread piracy of Game Boy
and GBA games ensued. (The company also sold rewriteable Flash cartriges.)

Nintendo sought US$20 million in damages in its original complaint, for lost
revenues in 2001 and 2002.

LSI has been under legal attack from Sony, Microsoft and Nintendo since last
year, due to the numerous mod chips products it formerly sold. The company
agreed to be acquired by a larger firm, Pacific Game Technology, in large
part to help underwrite its court costs. instantanée de France

Hi me,

> My question is this: which register is the "multiplier operand"? Is it
> Rm or Rs?

I just managed to find out the answer to the question on my own. It's
Rs. Still, it might be a useful optimisation technique so hopefully
you'll forgive me for the otherwise pointless post(s). :/

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

Hi folks,

The ARM docs say that multiply takes 1+m cycles to execute, where m is:
   + 1 if bits 32-8 of the multiplier operand are all zero or one
   + 2 if bits 32-16 of the multiplier operand are all zero or one
   + 3 if bits 32-24 of the multiplier operand are all zero or one

They also give the following template for the MUL instruction:
   MUL{cond}{S} Rd,Rm,Rs

My question is this: which register is the "multiplier operand"? Is it
Rm or Rs?

It might be useful optimisation technique when multiplying a big number
by a small number since it would twice as fast if the small number were
the multiplier operand.
--
Cheers,
James.

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

1) bl does this :
lr = pc (r14 = r15)
pc = target

2) You can't. If you haven't saved lr by the time you do
a second "bl", the return address is lost forever.
You can't simply nest "bl" like you would with CALL on x86.
In essence it only does part of CALL's job. It's up to you
to save lr (to the stack, generally) on procedure entry
and restore it on procedure exit.

You should take a look at some compiler-generated
procedures to get a better understanding of this.

Cheers,
--Jonathan

----- Original Message -----
From: Daniel
To: gbadev@yahoogroups.com
Sent: Wednesday, June 18, 2003 4:37 PM
Subject: [lists] [gbadev] assembly branching


2 Questions:
1) What registers are affected by using " bl" ?

2)How many times can I nest "BL" before I have problems?
i.e.
    code
    bl there        ;brach to sub routine
    code
End


there
     code
     bl AnotherPlace
     code
     mov pc.lr        ;return (rts)

AnotherPlace
         bl LastBranch
         mov    pc,lr

LastBranch
     code
     mov pc.lr

Yahoo! Groups Sponsor



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

'BL' Puts the PC into r14 before jumping to the new address. If you want to
nest them then you must move r14 in to a temporary register or on to a
stack.


-----Original Message-----
From: Daniel [mailto:webmaster@...]
Sent: 18 June 2003 15:37
To: gbadev@yahoogroups.com
Subject: [gbadev] assembly branching


2 Questions:
1) What registers are affected by using " bl" ?

2)How many times can I nest "BL" before I have problems?
i.e.
    code
    bl there        ;brach to sub routine
    code
End


there
     code
     bl AnotherPlace
     code
     mov pc.lr        ;return (rts)

AnotherPlace
         bl LastBranch
         mov    pc,lr

LastBranch
     code
     mov pc.lr

Yahoo! Groups Sponsor

<http://rd.yahoo.com/M=251812.3170658.4537139.1261774/D=egroupweb/S=17050551
96:HM/A=1564416/R=0/SIG=11ti81skc/*http://www.netflix.com/Default?mqso=60164
797&partid=3170658>

<http://us.adserver.yahoo.com/l?M=251812.3170658.4537139.1261774/D=egroupmai
l/S=:HM/A=1564416/rand=815368454>

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .

I don't think there are any tools for Mac. Maybe it would work to use Virtual
PC, etc to use one of the Windows/DOS send tools?
   ----- Original Message -----
   From: Mark Bishop
   To: gbadev@yahoogroups.com
   Sent: Monday, June 16, 2003 11:29 AM
   Subject: [gbadev] USB linkers


   Just a quick query; are there any USB linkers which have Mac OS X
   compatible software? If so, which? Does anybody have any
   recommendations? Also, does anybody know of any reliable dealers of such
   USB linkers in the UK?

   Thanks!


         Mark

Just a quick query; are there any USB linkers which have Mac OS X
compatible software? If so, which? Does anybody have any
recommendations? Also, does anybody know of any reliable dealers of such
USB linkers in the UK?

Thanks!


	 Mark


People demand freedom of speech as a compensation for the freedom of
thought which they seldom use.
	 ~Soren Kierkegaard

In DKA5 beta 3, if you load a .elf file and try to step through the
startup code using the disassembler, VisualBoy Advance crashes.  There
appears to be an instruction which it does not like to dissassemble.  You
can either attempt to scroll through the startup code, or you can step and
it will crash when it executes the branch at 0x08000112.

--
            The Phoenix - NekoCo - The Artistic Intuition Company
DevKitAdvance*MirrorReflex*Teapot*PhoenixQuake*Caelius*Zen-X*InfiniteRealms

hiya

quick question:
is it safe to call a swi in interrupt handler
(that is - swi within a swi :)
or this can lead to crash/locking condition?

ph0x

--- In gbadev@yahoogroups.com, Chuck Mason <cemason@h...> wrote:
> Could you provide more information on how the MBV2 cable
> programs visoly carts?

Once I've built a ROM image with PogoShell's tools, I write it to
my Visoly Flash Advance 256 Mbit cart by inserting the cart into
the GBA, connecting the MBV2 cable to the GBA, turning on the GBA
while holding select+start, waiting for "Nintendo" to disappear
(with a sound roughly like "pausing" in old NES games), and then
running a batch file that does this:

C:\gba\pogo>mb -p flashme.bin -w 200

Some people claim it works on F2A carts as well; some report
that it doesn't.  It may have something to do with hardware
differences among 64 Mbit vs. 128 Mbit vs. 256 Mbit F2A carts.

> Is there a website for the mbv2 cable?

MBV2 FAQ
http://www.devrs.com/gba/files/mbv2faqs.php

--
Damian

?=
Date: Fri, 13 Jun 2003 21:47:51 +0100
User-Agent: KMail/1.5.9
References: <ba39s4+ba34@eGroups.com> <1055469667.8630.12.camel@tower>
<1055532093.6187.28.camel@...>
In-Reply-To: <1055532093.6187.28.camel@...>
X-KMail-Link-Message: 67
X-KMail-Link-Type: reply
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
   charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <200306132147.52295.tb100@...>
Status: RO
X-Status: Q
X-KMail-EncryptionState:
X-KMail-SignatureState:
X-KMail-MDN-Sent:

On Friday 13 Jun 2003 20:21, Dennis Munsie wrote:
> Hi,
>
> Just curious as to why you aren't interested in the Multiboot cables?
> The MBV2 programs Visoly carts just fine -- and not all that slow.
> Plus, if it's development that you want to do, it's awfully nice to be
> able to insert printf's into your code, run it on the GBA, and see the
> output on the PC.
>
> I've been using this setup for a few months now (Linux, MBV2, GBA SP,
> Visoly Cart) and it works great for me.

I have the exact same setup and it works really nicely. The ability to
transfer small amounts of data in realtime while a program is running is a
really nice way to debug/test complex algorithms.

Tom