Okay.. got a new problem that I hope someone may be able to help me with. 
As many of you know, I have a DTC Forth system for the GameBoy Advance 
that acts as an intermediate language for a BASIC compiler.

As a quick note before continuing: I use DTC because it allows me to mix 
ARM and THUMB code freely -- something not easily done using a STC model, 
so this is not a viable solution (that I'm willing to consider at the 
moment) to my problem.

The problem that I have is that the GBA requires a very specific 224 byte 
header at the beginning of every game. This header constitutes the 
Nintendo logo which is displayed when the GBA is turned on, and is 
proprietary code copyrighted by Nintendo. My compiler puts this code at 
the beginning so that Joe-hobbyist can load his program onto the GBA and 
run it.

However, Nintendo has recently sent me an email demanding that I remove 
the header from the compiled images. That is their right, and I will 
oblidge. Without a valid header, though, other software in existence will 
prefix the current image with a valid header so that it runs properly. 
This is fine with ARM code, as all branches (including subroutine calls) 
are relative jumps. However, this will break the DTC tokens.

I've tried writing 224 bytes of 0's, hoping the other software will 
simply overwrite it, but that doesn't work either -- it prefixes the 
binary every time. I hope someone here has an idea or has run into a 
problem like this before and has some advice.

Thanks.

-- 
Best regards,
 Jeff Massung       jma[at]mfire.com
 http://www.jm-basic.com/

In article <Xns948BEB71AE3B7jeffmapeoplepccom@216.168.3.50>,
Jeff Massung  <jma[at]nospam.mfire.com> wrote:
<SNIP>
>
>However, Nintendo has recently sent me an email demanding that I remove 
>the header from the compiled images. That is their right, and I will 
>oblidge. 

That this is their right is not sure by a far stretch. 

You have to put the header there to assure interoperability.
It is your legal right to do whatever is necessary to gain 
interoperability with goods you legally obtained, even if
it includes reverse engineering. In most countries that is.

Now they have copyright. That is in order to stimulate them to
produce products of art similar to the Nintendo logo, over
people who reproduce their product, i.e. the logo, for 
benefit. Also their copyright might be infringed if you
try to fool others into thinking yours is a Nintendo product.
Theirs is of course not original Art, and you are not trying to 
rob Nintendo, instead you are stimulating their sales.
So their link with the spirit and intent of the law in this matter
is weak, to say the least.

These rights conflict, and it is a legal matter whose rights prevail.
It is quite possible that a judge will rule that where the logo
apparently is there to prevent you from exercising your legal rights,
and for no other reason, the copyright is void, or at least overruled.

The least I would do in your case is spend 100 bucks for a lawyer, and
send them a cease and desist letter, to refrain from refusing a
program that contains your company logo. So you put your own logo in
front of your program and complain that it doesn't run. Then send a
copy of the letter to your representative in parliament. Point out that
they are up against free market competition by preventing your
programs from running. 
Try to interest consumer organisations as well. 

Depending on their answer the lawyer may decide to take it up
on a no cure no pay basis. Then you could settle for a written
statement that anybody using the logo to assure interoperability 
can do so, and several thousands bucks for the lawyer and the
trouble it has taken you. Make sure not to overlook things for
your estimate, e.g. the time it has taken you to read this message.
Let the lawyer decide what is a reasonable hourly rate for your 
person. (You might be in for a surprise!)

>Without a valid header, though, other software in existence will 
>prefix the current image with a valid header so that it runs properly. 
>This is fine with ARM code, as all branches (including subroutine calls) 
>are relative jumps. However, this will break the DTC tokens.

Leave out these technical details in court. They are irrelevant.

>I've tried writing 224 bytes of 0's, hoping the other software will 
>simply overwrite it, but that doesn't work either -- it prefixes the 
>binary every time. I hope someone here has an idea or has run into a 
>problem like this before and has some advice.

My advice: Fight! Even if you don't win.

The second path is : make a loader that prefixes your program with 
the required header. If it is possible for the loader to copy 
the logo from where Nintendo put it themselves, so much the better.
If the program has functionality besides this logo stuff, so much
the better. Then distribute that program separately.
Where this program never shows the logo (which is a visual thing),
just copies it around to other place from where it is shown neither,
the copyright infringement case is weakened further.
In the worst case you put the loader program on a Warez site,
anonymously. There is of course nothing morally wrong with this. You
back off merely because you are acting legally, but can't win legally. 

>Thanks.
>
>-- 
>Best regards,
> Jeff Massung       jma[at]mfire.com
> http://www.jm-basic.com/



-- 
-- 
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
        One man-hour to invent,
                One man-week to implement,
                        One lawyer-year to patent.

"Jeff Massung" <jma[at]nospam.mfire.com> wrote in message
news:Xns948BEB71AE3B7jeffmapeoplepccom@216.168.3.50...
>> The problem that I have is that the GBA requires a very specific 224 byte
> header at the beginning of every game. This header constitutes the
> Nintendo logo which is displayed when the GBA is turned on, and is
> proprietary code copyrighted by Nintendo. My compiler puts this code at
> the beginning so that Joe-hobbyist can load his program onto the GBA and
> run it.
>
> However, Nintendo has recently sent me an email demanding that I remove
> the header from the compiled images. That is their right, and I will
> oblidge. Without a valid header, though, other software in existence will
> prefix the current image with a valid header so that it runs properly.
> This is fine with ARM code, as all branches (including subroutine calls)
> are relative jumps. However, this will break the DTC tokens.

Tell them to take a running jump.

Sega tried this and got laughed at:
http://apache.slashdot.org/comments.pl?sid=11633&cid=295668
and more detail at:
http://www.eff.org/Legal/Cases/sega_v_accolade_977f2d1510_decision.html

quote:
" We hold that when there is no other method
  of access to the computer that is known or readily available to rival
cartridge
  manufacturers, the use of the initialization code by a rival does not
violate the Act even
  though that use triggers a misleading trademark display."

Sam

"Jeff Massung" <jma[at]nospam.mfire.com> wrote in message
news:Xns948BEB71AE3B7jeffmapeoplepccom@216.168.3.50...

> oblidge. Without a valid header, though, other software in existence will
> prefix the current image with a valid header so that it runs properly.
> This is fine with ARM code, as all branches (including subroutine calls)
> are relative jumps. However, this will break the DTC tokens.

I take it speed is not a major problem. You will have to handle your DTC
tokens as relative to the load location rather than absolute addresses. This
will require adding the load location to the token before using it. This
should only require a small modificaton to NEXT such as:

NEXT:
  get next token to W register
  add load location to W
  relative branch to [W]

Bruce Hoyt

"Bruce Hoyt" <bhoyt@globe.net.nz> wrote in news:402a9e8b@clear.net.nz:

> 
> "Jeff Massung" <jma[at]nospam.mfire.com> wrote in message
> news:Xns948BEB71AE3B7jeffmapeoplepccom@216.168.3.50...
> 
>> oblidge. Without a valid header, though, other software in existence
>> will prefix the current image with a valid header so that it runs
>> properly. This is fine with ARM code, as all branches (including
>> subroutine calls) are relative jumps. However, this will break the
>> DTC tokens. 
> 
> I take it speed is not a major problem. You will have to handle your
> DTC tokens as relative to the load location rather than absolute
> addresses. This will require adding the load location to the token
> before using it. This should only require a small modificaton to NEXT
> such as: 

I was hoping not to have to do this, but it may be my best option. At 
least it is a simple ADD instruction, though, and is only 1 more cycle. 
Speed is a big issue to me, I just consider being able to switch between 
ARM and THUMB modes more important...

-- 
Best regards,
 Jeff			jma[at]mfire.com
 http://www.jm-basic.com

Quoth Jeff Massung:
> However, Nintendo has recently sent me an email demanding that I
> remove the header from the compiled images. That is their right, and I
> will oblidge. Without a valid header, though, other software in
> existence will prefix the current image with a valid header so that it
> runs properly. This is fine with ARM code, as all branches (including
> subroutine calls) are relative jumps. However, this will break the DTC
> tokens.

Given that your compiled images will be self-contained, can you make the
DTC tokens relative too?
-- 
Gwenhwyfaer         (emails need [Private] in the subject)

           some girls wander by themselves

On Wed, 11 Feb 2004 22:01:38 -0000, Jeff Massung
<jma@NOSPAM.mfire.com> wrote:

>I was hoping not to have to do this, but it may be my best option. At 
>least it is a simple ADD instruction, though, and is only 1 more cycle. 
>Speed is a big issue to me, I just consider being able to switch between 
>ARM and THUMB modes more important...

Is this on architecture 4T or 5T? If it is 5T the BLX and BX
instructions are your saviour. Note also that the ARM ARM shows
you how to use the BX R15 instruction to switch modes inline -
see page A7-33. In theory, this would permit you to perform
all token handling in ARM mode with the rest of the code in
Thumb mode. I suggest searching www.arm.com on the topic of
"interworking".

You can also use:
  LDR/STR Rd, [ Rn, Rm ]
with one register as a base register.

STC might actually be easier. However, really good Thumb code
generation is not easy; Thumb is very much designed for frame
stack languages. There's one part of the VFX code generator that
is really wonderful in ARM mode, but a real pig in Thumb mode.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) wrote in 
news:402adbf4.42704546@192.168.0.1:

> Is this on architecture 4T or 5T? If it is 5T the BLX and BX
> instructions are your saviour. Note also that the ARM ARM shows
> you how to use the BX R15 instruction to switch modes inline -

Some of the GBA handhelds are 5T, but not many. Most are still 4T, so the 
BLX instructions aren't an option (oh, how I wish they were). I hadn't 
come across the BX PC instruction before to switch modes, so this may be 
a good option... reading the data sheet now.

> see page A7-33. In theory, this would permit you to perform
> all token handling in ARM mode with the rest of the code in
> Thumb mode. I suggest searching www.arm.com on the topic of
> "interworking".
> 
> You can also use:
>   LDR/STR Rd, [ Rn, Rm ]

I'm a little confused on how this would solve the problem I'm facing. 
Loading the tokens isn't a problem, but rather where they point to. 
Perhaps I'm just being a dolt :)

> STC might actually be easier. However, really good Thumb code
> generation is not easy; Thumb is very much designed for frame
> stack languages.

Yes. A version I made that was STC was actually easier to code (I was 
actually quite surprised to find a STC was easier than an ITC or DTC 
model in this case).

The reason for using THUMB code instead of ARM (most of the time) is that 
the GBA ROM is only 16-bits wide, so THUMB code will execute around 160% 
faster (in ROM) than equivelant ARM code. I only intend to use ARM for 
various routines that would benefit from the barrel shifter and a 
plethora of registers (like Bresenham line drawing, etc.)

-- 
Best regards,
 Jeff			jma[at]mfire.com
 http://www.jm-basic.com

On Thu, 12 Feb 2004 14:33:45 -0000, Jeff Massung
<jma@NOSPAM.mfire.com> wrote:

>> You can also use:
>>   LDR/STR Rd, [ Rn, Rm ]
>
>I'm a little confused on how this would solve the problem I'm facing. 
>Loading the tokens isn't a problem, but rather where they point to. 

Make the tokens relative to the start of the program. Load the
base register withe the address of the start of the program.

l: start
  b    entry
  ...
l: setbase
  mov  Rbase, link
  mov  pc, link
  ...
l: entry
  bl   setbase
l: LinkPointedHere
  sub  Rbase, # LinkPointedHere - start

At this point Rbase contains the runtime address of start, so if all
tokens are based from start
  LDR Rd [ Rtoken, Rbase ]
always points to the right place. This technique works with a wide
range of CPUs with reg1+reg2 addressing.

Stephen
--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) wrote in 
news:402ba645.94496859@192.168.0.1:

> On Thu, 12 Feb 2004 14:33:45 -0000, Jeff Massung
> <jma@NOSPAM.mfire.com> wrote:
> 
>>> You can also use:
>>>   LDR/STR Rd, [ Rn, Rm ]
>>
>>I'm a little confused on how this would solve the problem I'm facing. 
>>Loading the tokens isn't a problem, but rather where they point to. 
> 
> Make the tokens relative to the start of the program. Load the
> base register withe the address of the start of the program.
> 

[...]

Gotchya! Thanks. Very nice :)

-- 
Best regards,
 Jeff			jma[at]mfire.com
 http://www.jm-basic.com