-----Original Message-----
From: Jeff Frohwein [mailto:jeff@...]
Sent: Thursday, March 01, 2001 7:44 AM
To: gbadev@yahoogroups.com
Subject: [gbadev] RNC2

I just completed an RNC2 decompressor for ARM asm with
example code for GCC. You can find it here as well as
links to Sprite Stripper, tUME, & several ARM tutorials
on the web I dug up.

http://www.devrs.com/gba/

Jeff


unsubscribe: gbadev-unsubscribe@egroups.com



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

I just completed an RNC2 decompressor for ARM asm with
example code for GCC. You can find it here as well as
links to Sprite Stripper, tUME, & several ARM tutorials
on the web I dug up.

  http://www.devrs.com/gba/

  Jeff

Hi all, I don't know if this has been discussed before, but I heard that
there are now GBC games that detect whether or not they are on a GBA unit.
GBC games determine if the system is a GBC based on A being 11 on startup,
but I took a look at the two new Zelda GBC games, since it's touted they
have features that only appear on a GBA, even though it's a GBC game. One
that I took a look at checks the value of B at startup and if it's set to 1
then the game acts differently, the colors are lighter. Does anyone know
about the details of the GBC registers on the GBA when it starts up? Could
it be that B=01 rather than 00 like on the GB/C?

-Dreamer
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

I don't know how many of you remember tUME (the Ultimate Map Editor), but
it's now open source. It's a map editor. It uses tiles from Deluxe Paint.

It's available at http://members.aol.com/opentume/

This was used to create commercial games on the SNES, Genesis, NES, and
possibly others. It previously cost something like $3000 or $4000 to get a
copy.

Hello Nokturn,

Monday, February 26, 2001, 10:19:50 PM, you wrote:

N>  If you wanna have a quick start, just join us @ #gbadev on efnet and enjoy.
ppl will be amused to help you out

Oh, And how can I join #gbadev on efnet ? Is it open for me ?

--
Best regards,
  Viktor                            mailto:urgh@...

Tom Badran wrote:
>
> So your saying if a recompile gcc for the arm, then i will get an arm-gcc and
> my original gcc will be fine?

Yes. Check here for more info:

http://gcc.gnu.org/onlinedocs/gcc_3.html#SEC18

  Jeff

So your saying if a recompile gcc for the arm, then i will get an arm-gcc and
my original gcc will be fine?


--
Microsoft is not the answer, its the question.
And the answer is no.   www.badran.co.uk

> If i compile and setup gcc for arm on my linux box, will it stop me being
> to compile linux software or does it just add a new target? autoconf always
> says my gcc is not a cross compiler (2.95-something) so all i can think is
> that it must replace my version of gcc.
>
> Thanks
>
> Tom

If you cross compile GCC for another target binaries called [target]-gcc,
[target]-gas and so on will be created.

If you need info for compiling gcc for another platform, I think there are
some links at devrs.com/gba.

For compiling arm code then the paths to the cross gcc binaries have to be
set correctly in the makefile configs of course.. and you are set..

hope that helps..

    -Gilligan

Please could som1 tell me where I can download GBA official demos from.
Thanks
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

If i compile and setup gcc for arm on my linux box, will it stop me being to
compile linux software or does it just add a new target? autoconf always says
my gcc is not a cross compiler (2.95-something) so all i can think is that it
must replace my version of gcc.

Thanks

Tom
--
Microsoft is not the answer, its the question.
And the answer is no.   www.badran.co.uk

> Thanks a lot Pete. Now I know how to set these wonderfull Gameboy
> Advance display modes:). Thanks again. :0)

No worries!

- Pete (Fwuffy in #gbadev on efnet)

Thanks a lot Pete. Now I know how to set these wonderfull Gameboy
Advance display modes:). Thanks again. :0)



--- In gbadev@y..., peter@d... wrote:
> > DISPCNT = 0x1140;
>
> That's 0001000101000000 in binary.
>
> The 16-bit DISPCNT register is like this (binary)
>
> KJIHGGGGFEDCBAAA
> 0001000101000000
>
> A - Display mode (0 in this case)
> B - Color gameboy mode (leave this alone - the system sets it)
> C - Frame buffer selection (used for modes with 2 frame buffers)
> D - Disable h-blank obj processing?
> E - OBJ character VRAM mapping format (0 = 2D, 1 = linear)
> F - Force a blank?
> G - Enabled background screens (only BG0 in this case)
> H - Enable object (OBJ/sprite) layer?
> I - Enable Window 0?
> J - Enable Window 1?
> K - Enable OBJ window?
>
> Hope this helps!
> - Pete / Fwuffy

> DISPCNT = 0x1140;

That's 0001000101000000 in binary.

The 16-bit DISPCNT register is like this (binary)

KJIHGGGGFEDCBAAA
0001000101000000

A - Display mode (0 in this case)
B - Color gameboy mode (leave this alone - the system sets it)
C - Frame buffer selection (used for modes with 2 frame buffers)
D - Disable h-blank obj processing?
E - OBJ character VRAM mapping format (0 = 2D, 1 = linear)
F - Force a blank?
G - Enabled background screens (only BG0 in this case)
H - Enable object (OBJ/sprite) layer?
I - Enable Window 0?
J - Enable Window 1?
K - Enable OBJ window?

Hope this helps!
- Pete / Fwuffy

Help! These strange registers have got me all confused. Especially
the one to set up your video mode and your Objects. Here is an
example that I am a bit confused with:

DISPCNT = 0x1140;

Now I have plenty of documentation on the GBA and it's registers
including information about the register above and it's different on
and off values. But nowhere in all the documentation that I have does
it tell me what hex value does what for a register setting. For
example this DISPCNT is made up of 1000+100+40????????
Where are you getting these values from???? Maybe there is some
documentation that I overlooked. I don't know. I'd like to be able to
set different display modes and stuff like that. Hope someone out
there can help me!!!

hmm, well I've been working on TS4 final hardware - and my simple arm
asm rendering engine is drawing in double pixels in mode 4. Using
strb to draw still seems to store the byte in both hi/lo of the 16bit
word. I've not pursued single pixel writing when I first came across
this problem, as my game screen looks okay in chunky pixels :)

Maybe gcc is compiling reading/modify/writeback asm.

--- In gbadev@y..., Jeff Frohwein <jeff@d...> wrote:
> Hey all,
>
>  It is my impression that vram can only be read/written in
> 16bit or 32bit increments. (No 8bit writes, anyway.)
> I just got this email from a developer with real hw
> that might wish to remain anonymous:
>
> > As far as the 16bits writes. I found that it's correct you only
can do 16
> > bits writes in all modes, except mode 4 in which making a (8 bit)
pointer
> > to the VRAM and writing seems to work.
>
>  Anyone can verify on a TS4? I realize that if accurate this is
probably
> an undocumented feature that might disappear in the final hardware.
>
>  Jeff

Hey all,

  It is my impression that vram can only be read/written in
16bit or 32bit increments. (No 8bit writes, anyway.)
I just got this email from a developer with real hw
that might wish to remain anonymous:

> As far as the 16bits writes. I found that it's correct you only can do 16
> bits writes in all modes, except mode 4 in which making a (8 bit) pointer
> to the VRAM and writing seems to work.

  Anyone can verify on a TS4? I realize that if accurate this is probably
an undocumented feature that might disappear in the final hardware.

  Jeff

Dennis Ranke wrote:
> In the angular loop i just noticed that you are using one more instruction
> than neccesairy as you can combine the strh and the pointer increment:
>   strh    r2,[r3],r9

  Ops! Dumb mistake.

> Other than that, it looks fairly optimal, although i still prefer the
> following loop, which uses a fixed time, while your code is sometimes
> faster and sometimes slower. (Depending on how often the branches
> to the other half of the loop are taken...)
>
> .loop
>   strh    r1,[r0],r2     ; store pixel and increment pointer
>   subs    r3,r3,r4       ; update error value
>   addmi   r3,r3,r5       ; up again
>   addmi   r0,r0,r6       ; update pointer
>   subs    r7,r7,#1       ; dec counter
>   bne     loop

  I like this version better as well. It doesn't have the single pixel
starting error that my version does. Good arm work, as always. :)

  Jeff

> etc...are there any most basic tutorials out yet ("Hello
> World"*G*)..everything i could read (sources etc) seemed to be pretty
> complicated...

'Welcome to Newyork'

Just wait. All things will come together soon. Everything will get nice and
simple. I'd say Simpler but I don't think thats a word. No wait... is it?

Hello,

I am pretty new to GBA-developing, i have many many years experience in
programming (C++) though, and i also did some programming on old gameboy
stuff, which was pretty simple to get into at the beginning.

this is probably the question you get to hear every week, but anyway, here
it comes again:

whats a good way to start GBA-Developing with, what do i need to compile
etc...are there any most basic tutorials out yet ("Hello
World"*G*)..everything i could read (sources etc) seemed to be pretty
complicated...

thank you...
Steril





_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Hi Jeff!

>  The line draw routine uses 3 assembly instructions/pixel for horizontal
> vertical lines & 6 asm instr/pixel for angular lines. This could probably
> be speeded up by using dma for horizontal lines, though.

For the horizontal lines i would use stmia's, not dma, as they are faster
when you just want to fill sth.
In the angular loop i just noticed that you are using one more instruction
than neccesairy as you can combine the strh and the pointer increment:
   strh    r2,[r3],r9
Other than that, it looks fairly optimal, although i still prefer the
following loop, which uses a fixed time, while your code is sometimes
faster and sometimes slower. (Depending on how often the branches
to the other half of the loop are taken...)

.loop
   strh    r1,[r0],r2     ; store pixel and increment pointer
   subs    r3,r3,r4       ; update error value
   addmi   r3,r3,r5       ; up again
   addmi   r0,r0,r6       ; update pointer
   subs    r7,r7,#1       ; dec counter
   bne     loop

--
exoticorn/icebird

Hi Erik,

Erik wrote:
>
> I have some programming experience, but not in console programming so
> I have a few questions.
>
> I have noticed some utilities that convert a raw file into an ASM or
> C file for compiling into your project.  Is it common practice in a
> small program to do this, then use a function the copy the data into
> OBJ?

  Sure. If the data is small then it's not a big compile time hit.
Speaking of that, I just updated my B2X tool to include GCC assembler
support:

  http://www.devrs.com/gba   (I just opened my GBA site yesterday btw.)

  The B2X tool converts binary data to .h or .s (GCC asm) format.

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

  Also I just posted the beginnings of my ARM asm graphics library
for GCC. The included demo .bin works on real hardware and VGBA emu.
Included is a fast line draw, ellipse draw, and area fill.

  The line draw routine uses 3 assembly instructions/pixel for horizontal
vertical lines & 6 asm instr/pixel for angular lines. This could probably
be speeded up by using dma for horizontal lines, though.

  Check the link above for this gfxLib.

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

  In a day or so I'll post my short GCC ARM/C interface tutorial.

  Jeff

I have some programming experience, but not in console programming so
I have a few questions.

I have noticed some utilities that convert a raw file into an ASM or
C file for compiling into your project.  Is it common practice in a
small program to do this, then use a function the copy the data into
OBJ?  Or preferably, can you just create a pointer to OBJ and enter
the data right in?  Is there a disadvantage to this that I am not
seeing?

Secondly, I read some specs on how objects are stored in OBJ
(sprite/tile) memory.  Am I correct in understanding that tiles are
natively 8x8, and that any larger object takes up the contiguous
space of multiple 8x8 locations?  What is the advantage of using one
method of storage (2dimensional or linear) over another in OBJ?

Thank you,
Alan Dershowitz

umm.  me too? LOL

Hi Everyone

I'm new to the GBA scene and I'd like to know how sprites should be
drawn. It was easy on the GBC because there was Tile Designer. Now
I'm using Paint Shop Pro to do my graphics and I'm not sure how the
GBA reads in the information. I know the graphics and palette have to
be in a RAW format but do they have to be drawn in a special way. Ie
drawn downwards or can you draw the sprites going from left to right.
Do they have to be drawn right next to each other? Do the sprites
have to be drawn with a width or height limit of any kind? How does
the Assembler take the graphic information from these RAW files???
Any help would be much appreciated. Cheeers.

Steve B.

Great.

Thanx Jeff! ... once again :-)

-----Original Message-----
From: Jeff Frohwein [mailto:jeff@...]
Sent: 22. februar 2001 16:19
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] gcc bins


Hi Thomas,

Thomas Hagen Johansen wrote:
>
> I have downloaded ARM SDT 2.50 Eval version from http://www.gbadev.org
> but would rather like to use gcc. Could you supply a link?

  I also have downloaded the arm SDT but much prefer gcc. The main
reason being that official devers, linux, and regular windows
users can all share the same source code/asm libraries. All
the support FAQs and support example code I write will be written
to compile without modifications for gcc. (Some coming soon.)

  Like some others, I tried the arm gcc bins from http://www.julesdcdev.com
but had no luck compiling or linking some types of code. Here is a gcc
compile
that I got from a friend that appears to compile well. This is gcc, the
binutils,
and the minimum amount of cygwin files needed for a windows arm gcc setup.
Put all of these in the same directory and just add them to your path:

  Note, use this cygwin.dll instead of the latest found on cygwin.com.
gcc linker would not work if I used the latest beta cygwin.dll on
cygwin.com.


gcc -      http://home.hiwaay.net/~jfrohwei/gameboy/armgcc.zip  (4.8mbyte)
    (includes minimum binutils needed for compiling code.)

advanced binutils - http://home.hiwaay.net/~jfrohwei/gameboy/armgcc2.zip
(5mbyte)

cygwin dll - http://home.hiwaay.net/~jfrohwei/gameboy/cygwin.zip
(~300kbytes)

  Jeff


unsubscribe: gbadev-unsubscribe@egroups.com



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