Hello colinraybrown,


>> bit shifting negative numbers might be tricky.
> as long as the compiler uses an asr (arithmetic shift right), is
> shouldn't be a problem - have to check the assembly output.
> If it dosn't, it might be as simple as using  dx/2 and dx/4.
> gcc should optimise these divides into asr instructions...
From my experiences it seems that this depends on variable type
(signed/unsigned).


--
cheers,
-Maciej

--- In gbadev@y..., porneL <pornel@w...> wrote:
>
> you can have it little more precise:
>  while(dx>320 || dy>320) {dx >>= 1; dy >>= 1;}
>  while(dx>256 || dy>256) {dx -= dx>>2; dy -= dy>>2;}
>

Thanks might try this, but for just aiming bullets the cheap and
dirty one is great.


> bit shifting negative numbers might be tricky.

as long as the compiler uses an asr (arithmetic shift right), is
shouldn't be a problem - have to check the assembly output.
If it dosn't, it might be as simple as using  dx/2 and dx/4.
gcc should optimise these divides into asr instructions...

cheers,

col.

> I would also suspect that the numbers of sprites that can be
> rendered changes depending upon how many background layers are
> in use.
>
> - John

I believe that sprites are unaffected by backgrounds in use.  In fact,
AFAIK, the only effect BGs ever have on sprites comes in BG mode - whether
sprites are getting 16k or 32k of tile memory.

max sprites per line:

width        normal obj        rotation/scaling obj

8                    128                    47

16                   76                     29

32                   38                     16

64                   19                      8

128                  --                      4

also - the bigger your "off-screen" sprites are the more time they take to
render - so best to make all sprites you aren't using 8*8 as well as
sticking them at 240,160 :)

ninge

   -----Original Message-----
   From: Phil Stroffolino [mailto:pstroffo@...]
   Sent: 02 May 2002 18:38
   To: gbadev@yahoogroups.com
   Subject: [gbadev] sprite hardware limitations


   I'm working on an isometric view RPG similar to "Breath of Fire 3" that
   supports freely rotating the screen in any direction (through 64
   angles).  It uses rotate-zoom layer for the floor, and heavy use of
   sprites for other graphics objects.

   For sprites, it's using a cache of prerendered sprites (for each view
   angle), along with rotate-zoom sprites for simple 3d objects like walls
   and puddles.

   This yields an excellent frame rate, since no polygons need to be
   rendered in software during normal gameplay.  It works great on
   emulators.

   My concern is: what exactly are the hardware limitations on sprites?
   And what is the behavior if you use too many sprites per line?  Which
   sprites disappear?  I'd like to build these limitations into my video
   hardware simulator so I don't get overzealous with complex scenes.

   I've seen listed figures for "max number of ROZ sprites per scanline"
   but what happens when you mix normal sprites with some smaller number
   of ROZ sprites?  Is there a simple rule I can safely use as a
   constraint?  Let's say for example I have (A) 32x32 sprites, and (B)
   double size 32x32 sprites with ROZ enabled.  What combination of (A)
   and (B) will not cause problems?

   Is there any freely available emulator that is known to enforce these
   limits?

>> angle = atan2(enemy->x - player->x, enemy->y - player->y);
>> dx = COS[angle];
>> dy = SIN[angle];

c> ?isn't there still a divide in that atan2 function?
Yes, there is one. But its the fastest method to calculate (accurate)
unit vector I know.

>> another idea to get normalized vector
>>  while(dx>256 || dy>256) {dx >= 1; dy >= 1;}
>>  // I assume 8.8 fixed point
>>
>>  its very inaccurate, but often enough for hooming missiles.

c> :) this is great thanks - it works fine, and the inaccuracy just
c> gives a little variation in bullet speed - very nice.
c> (another "now why didn't I think of that?" moment)
:)

you can have it little more precise:
  while(dx>320 || dy>320) {dx >>= 1; dy >>= 1;}
  while(dx>256 || dy>256) {dx -= dx>>2; dy -= dy>>2;}


bit shifting negative numbers might be tricky.
either shift 32bit number, and cast it to 16bit (or 16->8)
(I dont remember what ANSI says about it but it works for me:)
or
remember sign before loop and negate result if neccesary (safer).



   bye, porneL


--

1200 603/200 040/25 16M 8.6G 4X 3.1 AGA, GG 989217

For something that small, wouldn't it be better to put it inline than to do
a branch and return?  Unless, of course, you are in thumb mode at the time.
:)

That would shave 3 instructions out -- the load of the routine address, the
bx to the routine, and the bx back.  That should make it faster :)

dennis

-----Original Message-----
From: tomstdenis [mailto:tomstdenis@...]
Sent: Thursday, May 02, 2002 7:09 AM
To: gbadev@yahoogroups.com
Subject: [gbadev] Re: fast 32x32=>64 multiplier for 16.16 fixed point

Very true.  Thanks guys... a small snippet

fmul32:
         @ inputs are in r0 and r1, return in r0
         smull r2,r3,r0,r1
         mov   r1,r2,lsr#16
         orr   r0,r1,r3,lsl#16
         bx lr

Hey Jeff --

it may be slooow, but some machines don't have legacy ports -- Macs, for
example.

I would love to be able to use my MBV2 cable over USB -- then, I could move
my development environment over to my iBook using OS X.  Instead, I get to
use my work laptop with w2k -- the one that won't sleep properly when
docked, which means that I have to reboot it between home and work and back
again.  Usually, I use the iBook to surf the web while waiting for the pc to
boot :D

At least the new flash linker is USB based... :)

dennis

-----Original Message-----
From: Jeff Frohwein [mailto:jeff@...]
Sent: Thursday, May 02, 2002 9:06 AM
To: gbadev@yahoogroups.com
Subject: [gbadev] GameShark USB is slowwwww...


"Thomas Nielsen [Liftoff]" wrote:
> The restriction - and the problem - with Flash linkers is still the fact
> that you need to disconnect cards and put them in your FAL every time
> you want to test something.

  Except if you are using the MBV2: :)

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

> With a modded GameShark, you could possibly get around this.

  I don't think anyone will be very enthusiastic about this approach
once they realize that the GameShark uses a low-speed USB chip that
isn't designed for high data transfer rates. :-\ Just added the following
FAQ:

  http://www.devrs.com/gba/files/gbadevfaqs.php#GSHacking

  Jeff

From: "Phil Stroffolino" <pstroffo@...>
> I've seen listed figures for "max number of ROZ sprites per scanline"
> but what happens when you mix normal sprites with some smaller number
> of ROZ sprites?  Is there a simple rule I can safely use as a
> constraint?  Let's say for example I have (A) 32x32 sprites, and (B)
> double size 32x32 sprites with ROZ enabled.  What combination of (A)
> and (B) will not cause problems?

I've also seen the numbers posted here recently but I don't have them readily
handy.  However, you should be able to get a rough idea by making some
simple calculations.  The limitation is on the amount of time it takes to
process
each sprite.  So if the numbers are that x 32x32 sprites or y ROZ sprites can
be rendered, you can see that the time it takes to render a ROZ sprite is x/y
times the amount of time it takes to render a normal sprite.

Since the total time's units are irrelevant here, assume that you have a total
time
of x units and it takes 1 unit to render a normal sprite.

T = A + B * (x/y)

if T (time to render) <= x, you should be OK.  If T > x, either you will have
problems,
the above assumptions are incorrect, or the starting numbers are incorrect.

From experience with similar hardware in the SNES, some of the sprites will not
appear
on that scan line, or may only partially appear.  Also, if only a few scan lines
have the
convergence of too many sprites, the sprites will appear fine both above and
below those
lines.

I would also suspect that the numbers of sprites that can be rendered changes
depending
upon how many background layers are in use.

- John

I'm working on an isometric view RPG similar to "Breath of Fire 3" that
supports freely rotating the screen in any direction (through 64
angles).  It uses rotate-zoom layer for the floor, and heavy use of
sprites for other graphics objects.

For sprites, it's using a cache of prerendered sprites (for each view
angle), along with rotate-zoom sprites for simple 3d objects like walls
and puddles.

This yields an excellent frame rate, since no polygons need to be
rendered in software during normal gameplay.  It works great on
emulators.

My concern is: what exactly are the hardware limitations on sprites?
And what is the behavior if you use too many sprites per line?  Which
sprites disappear?  I'd like to build these limitations into my video
hardware simulator so I don't get overzealous with complex scenes.

I've seen listed figures for "max number of ROZ sprites per scanline"
but what happens when you mix normal sprites with some smaller number
of ROZ sprites?  Is there a simple rule I can safely use as a
constraint?  Let's say for example I have (A) 32x32 sprites, and (B)
double size 32x32 sprites with ROZ enabled.  What combination of (A)
and (B) will not cause problems?

Is there any freely available emulator that is known to enforce these
limits?


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

> Sounds like you might just need a better power supply going into your
beige
> box to help with the dodgyness.

The same type of crash also happens 9 out of 10 times when I simply insert a
headphone plug to get the sound over headphone or PC speakers. Is that also
caused by a bad power supply?  Anyway, I'm pretty used to it now but I will
try switching to another power supply (earthed and protected).

> The screen position in bitmap mode can be twiddled with via the bg2
> scale/rotate control registers, can it not? You might just have these set
> badly on the emulator unit but by some miracle they are fine if you run it
> from a flash a cart.

Yeah, I tried initializing that one already... Same result.

I also ran a few other commercial ROMs on both TS4 units we have here and
they all show the same glitch (-1,-1 displaced BG2 in bitmap mode 4).

Does anyone else who has a TS4 board see this? Depending on your backdrop
color you can see a line at the bottom of the screen and on the right side
of the screen in bitmap mode 4 (haven't tried to look at other bitmap modes
yet).

For now I'm assuming it's a TS4 bug which was solved in the retail versions
of the GBA.

Eh.. did you try to write about the problem on the Nintendo newsgroup ?

and btw, I never had these problems with the game I did !!!

-Sam

> -----Original Message-----
> From: Jan-Lieuwe Koopmans [mailto:jan-lieuwe@...]
> Sent: Thursday, May 02, 2002 6:17 PM
> To: gbadev@yahoogroups.com
> Subject: Re: [gbadev] TS4 bitmap mode bug?
>
>
> > Um...do you mean TS2 board? A TS4 is a real GBA (release
> version) attached
> > to the dev station. A TS2 is a circuit board with an LCD.
> >
> > The TS2 does have some defects, which you can find info about on
> Nintendo's
> > developer site. If you are using a TS2, I strongly recommend you read up
> on
> > these differences instead of accounting for the differences in code/art.
>
> I mean TS4 board (there's a TS4 sticker on the back of the GBA
> unit). It has
> got a real gameboy advance attached to it, but it is not the same
> thing as a
> real gameboy advance (it easily crashes when I insert a headphone jack or
> turn on the lights in the office and if I press start or select I can see
> the screen become 'darker' in the bottom left corner as if it's
> interfering
> with the LCD... all these things don't happen on the retail version of a
> GBA).
>
> Jan-Lieuwe

> real gameboy advance (it easily crashes when I insert a
> headphone jack or
> turn on the lights in the office and if I press start or
> select I can see
> the screen become 'darker' in the bottom left corner as if
> it's interfering
> with the LCD... all these things don't happen on the retail
> version of a
> GBA).

Sounds like you might just need a better power supply going into your beige
box to help with the dodgyness.

The screen position in bitmap mode can be twiddled with via the bg2
scale/rotate control registers, can it not? You might just have these set
badly on the emulator unit but by some miracle they are fine if you run it
from a flash a cart.


Kriss

> Um...do you mean TS2 board? A TS4 is a real GBA (release version) attached
> to the dev station. A TS2 is a circuit board with an LCD.
>
> The TS2 does have some defects, which you can find info about on
Nintendo's
> developer site. If you are using a TS2, I strongly recommend you read up
on
> these differences instead of accounting for the differences in code/art.

I mean TS4 board (there's a TS4 sticker on the back of the GBA unit). It has
got a real gameboy advance attached to it, but it is not the same thing as a
real gameboy advance (it easily crashes when I insert a headphone jack or
turn on the lights in the office and if I press start or select I can see
the screen become 'darker' in the bottom left corner as if it's interfering
with the LCD... all these things don't happen on the retail version of a
GBA).

Jan-Lieuwe

> >> gSeed = (16807*gSeed)&0x7fffffff;
>well, i just tried it out and without >>16 the results aren't random
>whatsoever :)

There's a typo which Tom pointed out - the correct expression is:
gSeed = (16807*gSeed)%0x7fffffff

Which unfortunately isn't fast at all on a GBA.

http://www.unet.univie.ac.at/aix/libs/basetrf2/rand.htm
has a solid implementation of rand() that doesn't involve modulus.


__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

Um...do you mean TS2 board? A TS4 is a real GBA (release version) attached
to the dev station. A TS2 is a circuit board with an LCD.

The TS2 does have some defects, which you can find info about on Nintendo's
developer site. If you are using a TS2, I strongly recommend you read up on
these differences instead of accounting for the differences in code/art.

     Just Me,
         *SF

"Thomas Nielsen [Liftoff]" wrote:
> The restriction - and the problem - with Flash linkers is still the fact
> that you need to disconnect cards and put them in your FAL every time
> you want to test something.

  Except if you are using the MBV2: :)

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

> With a modded GameShark, you could possibly get around this.

  I don't think anyone will be very enthusiastic about this approach
once they realize that the GameShark uses a low-speed USB chip that
isn't designed for high data transfer rates. :-\ Just added the following FAQ:

  http://www.devrs.com/gba/files/gbadevfaqs.php#GSHacking

  Jeff

--- In gbadev@y..., Martin Piper <martinp@a...> wrote:
> To accurately multiply two 16.16 number you shouldn't need to
split them up
> in to separate 16 bit multiplies, commonly known as "using the
highschool
> math" (sic) method for example.

Very true.  Thanks guys... a small snippet

fmul32:
         @ inputs are in r0 and r1, return in r0
         smull r2,r3,r0,r1
         mov   r1,r2,lsr#16
         orr   r0,r1,r3,lsl#16
         bx lr

Thats the entire function [with corrected orr].  I get 2.5x faster
in VBA [250k/sec].

I will also take your advice with the smula instruction.

Tom

To accurately multiply two 16.16 number you shouldn't need to split them up
in to separate 16 bit multiplies, commonly known as "using the highschool
math" (sic) method for example.

The solution to getting faster multiplication for 16.16 maths is to use the
ARM 64bit SMULL instruction. This instruction takes four registers. From
memory the first two are the 65 bit result and the last two registers are
the two 32 bit registers to multiply.
The bets bit about this instruction is that there is a SMULA (IIRC) that
accumulates in to the 64 bit result registers. This way you can do a series
of 64 bit result multiples with accumulation and then do only one shift down
by 16 bits at the end.

To do the shift at the end you can do:
Assume 64 bit result is in r0,r1 where r1 is the lower 32 bits.
mov r1,r1,lsr#16
orr r1,r0,lsl#16
Again, if I remember correctly. ;-)

Since 16.16 numbers are really useful for 3D maths the 3D maths calculation
functions should be moved in to the 32K of fast RAM and executed as 32 bit
ARM code, not thumb. Just by doing this you will see a speed up of about 3.5
to 4 times.

-----Original Message-----
From: tomstdenis [mailto:tomstdenis@...]
Sent: 02 May 2002 11:24
To: gbadev@yahoogroups.com
Subject: [gbadev] Re: fast 32x32=>64 multiplier for 16.16 fixed point


--- In gbadev@y..., tom st denis <tomstdenis@y...> wrote:
> I didn't find much in the archives for this so I wrote my own....
>
> This routine gets ~27000 multiplies per second in VBA which means
on
[..]

--- In gbadev@y..., tom st denis <tomstdenis@y...> wrote:
> I didn't find much in the archives for this so I wrote my own....
>
> This routine gets ~27000 multiplies per second in VBA which means
on
> the real hardware its probably around ~22000 [my gba broke so I
can't
> test it myself...]
>
> What the code does is a 32x32 multiply then a shift right by 16
bits so
> it emulates a multiply for a 16.16 system.

I've managed to speed up the code 5x and I will tell y'all how.
Really easy using some school math.

Ok so the the basic 16.16 multiply looks like this

x = (a*b)>>16

Where a*b is a 64-bit [or at least 48 bits] product.  Problem:  The
GBA only produces 32 bits of product.  Solution:  Only do 16x16
multiplies!

Let a = AB and b = CD then you have

  AB
*CD
---

Where you must compute [with the right shift taken]

B*D >> 16, D*A, C*B and A*C << 16

So in my new code I do just that.  After taking care of the sign of
the input [all four A,B,C,D must be unsigned at this point] I
proceed to mask/chop off the 16-bit words then I perform the four
multiplications.

In VBA I routinely get >100k worth of multiplications per second
[instead of 20k].  I dunno how VBA emulates the multiplication but I
know one thing for sure this is going to be faster than the my other
method.  My other method had 7 instructions per bit for a total
around 250 instructions.  This routine has ~40 instructions which is
1/5 the size :-)

Because I preshift the values [to keep this all 32 bits] the lower
bits of the fraction are probably not exactly what they should be.
I've tested the routine with various inputs [negative and positive]
and I found it appears to work.

In my new library I've added an Inverse table so you can compute
division easily.  I've also added 16.16 Cos/Sin/Tan tables to my lib
[I already had 8.8 tables...]

Should be enough to implement pretty much any 3d graphics in a
larger world space.

You can see my multiplier code in /lib/amath.s its called "fmul32"
and is fairly well commented assuming you can read ARM assembler.

All of my code is in Thumb mode because the instructions execute
quicker [and I don't have an ARM reference handy...]

http://tomstdenis.home.dhs.org/mylib.zip

I'd still be interested in tweaking my multiplier code if possible
so please reply if you have any ideas.

Also [I'm going to search too but I thought I'd ask....] anyone have
any good info on implementing atan() quickly?  My trig is not 100%
so I could use some help.

Tom

[mod note: I think you should take a look at the ARM MULL instructions for your
own good, this has also been discussed lots and lots previously on the list :]

Hello colinraybrown,

Wednesday, May 01, 2002, 3:54:40 AM, you wrote:

c> --- In gbadev@y..., groepaz <groepaz@g...> wrote:

c> well, I searched the archives carefully and didn't find RNG code like
c> this :-|
c> do you have a note of the eor-constant for 32bit (any other too)
c> pretty please....

Mask (hex)      Width (bits)
03                      2
06                      3
0C                      4
14                      5
30                      6
60                      7
B8                      8
110             9
240             10
500             11
CA0             12
1B00            13
3500            14
6000            15
B400            16
12000           17
20400           18
72000           19
90000           20
140000  21
300000  22
400000  23
D80000  24
1200000 25
3880000 26
7200000 27
9000000 28
14000000        29
32800000        30
48000000        31
A3000000        32


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

Hello colinraybrown,

Monday, April 29, 2002, 9:34:45 PM, you wrote:

> --- In gbadev@y..., Phil Stroffolino <pstroffo@y...> wrote:
>> >First off, does anyone have a free fast arctan algorithm, I've
> been
>>
>> No, but if you are simply looking to steer bullets, you can just
>> normalize the deltas.
>>
>> dx = pEnemy->x - pPlayer->x;
>> dy = pEnemy->y - pPlayer->y;
>> dx = dx*dx;
>> dy = dy*dy;
>> distance = dx+dy; /* make sure to account for distance==0 */
>> dx = (dx<<8)/distance; /* #.8 fixed point */
>> dy = (dy<<8)/distance;
> yeah, this would work ok and was my first thought as well, but there
> are 2 divides which aint so cool for gba :(
You can try to convert this to one divide and two multiplications
(calculte reciprocal). This was faster on old PCs and I guess this
rule also holds for GBA. Also, if you know that your distances are
limited you can try to use look-up table and avoid division (I do it
this way in my texture-mapper, no divisions at all).

--
cheers,
-Maciej

Hi,

When I edit the mapwin.ini file that comes with Mappy (map editor, not the
emu) it doesn't use these new settings. It just assumes the basic ones. I've
closed mappy and re-opened it, nothing..

Anyone?

Greetz,

Collin

I didn't find much in the archives for this so I wrote my own....

This routine gets ~27000 multiplies per second in VBA which means on
the real hardware its probably around ~22000 [my gba broke so I can't
test it myself...]

What the code does is a 32x32 multiply then a shift right by 16 bits so
it emulates a multiply for a 16.16 system.

I used a standard double/add method but I think if I could take
advantage of the ARM multiplier somehow that may prove useful.  However
two major obstacles,  the multiplier is unsigned and it doesn't produce
the upper 32 bits [well at least not in Thumb mode].

The code is at http://tomstdenis.home.dhs.org/mylib.zip

Under /sqrt/sqrt.bin is a precompiled binary for the demo [I used it to
time my sqrt function and then my fmul32].

The source for this function is in GAS assembler code in the files
/lib/amath.s

Anyone else have info on this particular operation?  Could someone
please time this on real hardware?

Tom

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com

--- In gbadev@y..., "Darren Coles" <darrencoles@b...> wrote:
> Ive spent a little time disassembling the flashlinker gamepack menu
and managed to figure out how
> it pages different banks of the rom in. I dont know if anyone has
posted this information before but I certainly
> havent seen it.
>
> I've written a small piece of example code that pulls off a bank
switch and turns the screen red or green
> depending on whether the rom contents changed or not.
>
> This appears to work as it should (green screen on emulator - red
screen on flashlinker).
>
> This information should be enough to help anyone who might want to
code a nice new menu selector
> for the flash linker.
>
> Both the source and binary are available here.
>
> http://www.gbadev.freehosting.net/

Actually, it's not really a secret - it's been available at

http://www.ziegler.desaign.de/GBA/gba.htm

for a while, and I use that info to add execute support to my library
so I could make PogoShell;

http://www.obsession.se/pocket/shell.html

It would be great though if people could add a RESET in their
productions so you didn't have to turn off your GBA all the time;
basically just reset the romstart and do an SWI #1

-- Jonas Minnberg

Hello All,

I just noticed that bitmap modes on a TS4 board are shifted by -1,-1 pixels
(showing the border on the bottom and right edge of the screen). I tried it
out on two TS4 boards and they both show the same bug. A 'real' gameboy does
show the bitmap the way it should (I tried it on two real gameboys).
Emulators show it correctly as well.

Anyone else came across the same problem? Can I assume that what the real
gameboy shows is okay? Or is there a register which is being initialized on
a real gameboy but not on the TS4 board?

(Background info: my game puts sprites on top of the bitmap... on the TS4
they are appearing one pixel lower than on a real gameboy... it makes the
game look weird on a TS4 board.)

Thanks in advance!


Greetings,
Jan-Lieuwe

USB would be VERY handy when running windows xp.  Seems winxp cant use my 3
parallel ports :P  I like to have all my AGB stuff pluged in at once; I hate
cable swaping  ;)  Testing using the flash would be super.  I do wish it
could plug into the multiboot port though as I find my MBV2 very handy.  Oh
well, anything is better than swapping a cart from flash linker to agb so
many times as I test my code on hardware!  Is there anyone here that could
write a windows driver for the gameshark?  I *might* be willing to donate a
gameshark to someone here in the states if they would make a program to
allow us to use it for agb developer uses.

*Might - provided you are capable, and can prove that via other programs you
have writen & have the time to do it(will do it)....


>
> Does anyone know anything about the internals on the game shark?  I
wouldn't
> mind picking one up for hacking with -- it's not too terribly expensive,
and
> having a USB interface would be kinda handy.  Also, depending on the size
of
> the flash, it could possibly be an 'expanded MBV2' cable -- you could
upload
> to the flash if you wanted to -- for those of us who don't think that 256k
> is that small ;)

The restriction - and the problem - with Flash linkers is still the fact
that you need to disconnect cards and put them in your FAL every time
you want to test something. With a modded GameShark, you could possibly
get around this.

/Steve--

-----Original Message-----
From: TJ [mailto:comfortably_numb_@...]
Sent: 1. maj 2002 01:42
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] USB upload cable

Nope, I haven't done this. Once you figured out how to reprogram the
cart it
might make for some useful hardware but you would also have to make a
driver
for it since it is a USB device. After all that I would still think the
flash cart would be way more suited for developing on. It wouldn't be
that
much longer to flash the cart and you would have a normal sized cart to
work
with. The truth is if you are planning on making a program bigger than
the
ram on gba can handle you might as well spring for the flash cart and
basically have no restrictions.

----- Original Message -----
From: "Dennis Munsie" <munsied@...>
To: <gbadev@yahoogroups.com>
Sent: Tuesday, April 30, 2002 2:36 PM
Subject: RE: [gbadev] USB upload cable


> Are you suggesting that you have done something like this or that you
know
> of a way to do this, or are you just telling what would need to be
done?
> Because the way it's worded, it appears that you are answering a FAQ
:)
>
> Does anyone know anything about the internals on the game shark?  I
wouldn't
> mind picking one up for hacking with -- it's not too terribly
expensive,
and
> having a USB interface would be kinda handy.  Also, depending on the
size
of
> the flash, it could possibly be an 'expanded MBV2' cable -- you could
upload
> to the flash if you wanted to -- for those of us who don't think that
256k
> is that small ;)
>
> dennis





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

While we are on the subject, does someone have some example code for
programming the visoly flash carts?

David

I've done a lot of work hacking the gameshark hardware. I'm still not ready to
reflash my gameshark, but I know enough to do so using the official upgrade
program. Using the hardware, you get the ability to communicate with a PC via
USB, and the ability to patch ROM. (ooh)
Before I'll be able to figure out the USB protocol, I still need to learn how
USB works. With the USB protocol, it would be easier to write USB libraries for
the PC and GBA.

Without the proper libraries in the ROM you upload, you'll be unable to use the
USB (obviously) but you'll also be unable to reflash the hardware through USB.
It wouldn't be a problem if someone could edit FLinker to write to gamesharks'
SST flash rom. I tried it once, but I couldn't even read the Product ID from the
chip. I have the info to do it, just none of it works. (ahhh!!)


If you'd like more info, just reply.
~ Parasyte

P.S. using the official USB program to reflash means you could only flash 128KB.
The program requires this file size. Also, you'll need to encrypt your ROM
before the program will accept it - I've written an encryption\decryption
program if it's needed.



--- In gbadev@y..., "TJ" <comfortably_numb_@h...> wrote:
> Nope, I haven't done this. Once you figured out how to reprogram the cart it
> might make for some useful hardware but you would also have to make a driver
> for it since it is a USB device. After all that I would still think the
> flash cart would be way more suited for developing on. It wouldn't be that
> much longer to flash the cart and you would have a normal sized cart to work
> with. The truth is if you are planning on making a program bigger than the
> ram on gba can handle you might as well spring for the flash cart and
> basically have no restrictions.
>
> ----- Original Message -----
> From: "Dennis Munsie" <munsied@m...>
> To: <gbadev@y...>
> Sent: Tuesday, April 30, 2002 2:36 PM
> Subject: RE: [gbadev] USB upload cable
>
>
> > Are you suggesting that you have done something like this or that you know
> > of a way to do this, or are you just telling what would need to be done?
> > Because the way it's worded, it appears that you are answering a FAQ :)
> >
> > Does anyone know anything about the internals on the game shark?  I
> wouldn't
> > mind picking one up for hacking with -- it's not too terribly expensive,
> and
> > having a USB interface would be kinda handy.  Also, depending on the size
> of
> > the flash, it could possibly be an 'expanded MBV2' cable -- you could
> upload
> > to the flash if you wanted to -- for those of us who don't think that 256k
> > is that small ;)
> >
> > dennis

--- In gbadev@y..., groepaz <groepaz@g...> wrote:

well, I searched the archives carefully and didn't find RNG code like
this :-|
do you have a note of the eor-constant for 32bit (any other too)
pretty please....

cheers,

col.

>
> static int _rndseed = 1;
>
> int rand(void) {
>
>     if(_rndseed&1) {
>         _rndseed>>=1;
>         _rndseed^=0xb400;
>     }else{
>         _rndseed>>=1;
>     }
>
>     return(_rndseed);
>
> }
>
> void srand(int r) {
>     _rndseed=r;
> }
>
> what about this? works fine for me :o) (thats for 16bit numbers
> obviously) ... actually, this one has been taken from a discussion
> that came up HERE loooooooooooooong ago :o) search the archives,
there
> are the other eor-constants for various bitlenghts aswell :=)