hi all,

just a quick heads up, i released HAM 1.4sr1 today, it
mainly fixes the Win9x/ME support, and a few other quirks
from the initial release. For those who are interested, or
do not know what HAM is:

http://www.ngine.de/ham.html

cheers
Emanuel Schleussinger

apsod wrote:
>
> Hi.
>
> I'm pretty sure that's a very simple thing and that I'm just screwing over
> some stupid detail, but I'm still completly confused...
>
> Basically, I noticed that my interupt routine didn't work when I compiled my
> code with thumb rather than arm code.

  That's because the interrupt entry point must be in ARM (not Thumb) mode:
    http://www.devrs.com/gba/files/gbadevfaqs.php#IntRegs

  So you need some ARM code, even if it's only 2 lines of ARM assembly code.

  If you compile crt0.s on devrs.com/gba with interrupt support enabled:
   .equ __InterruptSupport, 1
and with the fast interrupts mode:
   .equ __FastInterrupts, 1
then all you have to do is name your ARM or Thumb C code routine with the
following name:
   InterruptProcess();
and interrupts should work for you. crt0.s will patch location 0x3007ffc
for you so you don't have to worry about that.

  Jeff

Hi.

I'm pretty sure that's a very simple thing and that I'm just screwing over
some stupid detail, but I'm still completly confused...

Basically, I noticed that my interupt routine didn't work when I compiled my
code with thumb rather than arm code. I tracked the problem down but really
can't understand it. Here's what's happening :

If I branch to my IntRoutine, by simply calling it, like so :

IntRoutine();

the asm generated code is something like :

bl 0x800026C

but if I do something like this :

u32 Bob;
Bob = (u32) IntRoutine

What gets placed into Bob is:

0x800026D

Notice that the function's address was incremented by 1 and is now
misaligned... So when I place my function in the interupt address register
like so :

GR_IRQ_VECTOR = (u32) IntRoutine

the called code is misaligned and pure garbage...


I did the same test with ARM code and the 2 numbers are the same and no
error is produced...
I'm using Devkitadv to compile.

Now, does someone have a clue? There must be some rule or something that I'm
just forgetting there I guess :(

Thanks!

--- In gbadev@y..., Jeff Frohwein <jeff@d...> wrote:
>  I read Martin's notes and the fact that he mentioned that SD is
only
> needed for "double speed" made no sense to me. It is required for
multiboot
> as well unless he knows something that the rest of us don't. AFAIK,
ALL
> of a multiboot image data (header and the rest) is tranferred on the
> SD line. That's how the MBV2 works anyway.

More on Martin's XBOO.COM:
The two modes I mentioned before are both used by his "burst mode
bios", ie you have to install an IRQ handler in your downloaded
code. These modes don't use the encryption, etc.

His tool attempts to use those, but if that fails it falls back
to a slower mode, which sends the data on SI and clocks it with SC.
(set data+clock, clear clock) This mode uses what seems to be
the "normal" encryption.

--- In gbadev@y..., Jeff Frohwein <jeff@d...> wrote:
>
>  I read Martin's notes and the fact that he mentioned that SD is
only
> needed for "double speed" made no sense to me. It is required for
multiboot
> as well unless he knows something that the rest of us don't. AFAIK,
ALL
> of a multiboot image data (header and the rest) is tranferred on the
> SD line. That's how the MBV2 works anyway.

I have not tried making a cable yet, but I have reversed most of
his code. His "1x" routine sends data on SI, clocking one bit on
each edge of SC. His "2x" routine sends a bit on both SI and SD,
again clocked on each edge of SC.

The godsmaze code uses the TSC for timing, so it won't work on
anything less than a Pentium, some non-Intell cpu's, or any OS
which modifies the TSC. (Some unix clones use the TSC for NTP
housekeeping - hence my interest in Martin's code.)

Martin's code appears to run flat out, but it sets the data and
clock with a single out instruction so I would expect some timing
errors.

>    From: Jeff Frohwein <jeff@...>
>Subject: Re: Re: parallel cable
>
>  I read Martin's notes and the fact that he mentioned that SD is only
>needed for "double speed" made no sense to me. It is required for multiboot
>as well unless he knows something that the rest of us don't. AFAIK, ALL
>of a multiboot image data (header and the rest) is tranferred on the
>SD line. That's how the MBV2 works anyway.
>
> > However as it seems the Nintendo logo
> > is transferred (so the whole header) without problem, only the rest of
> > the data (what is uploaded with the NO$ protocol) is missing.
>
>  This makes no sense to me either, as mentioned above. I'm not saying
>you're wrong. I'm just saying I'm perplexicated(tm;) by these findings.
>
>  Jeff

The cable works as diagrammed, I've built one using the first 4 lines as
described in the TXT file and it works perfectly in DOS and a Win95 DOS box.
I had thought that this cable was impossible because it doesn't require the
SD line. Maybe the diagram has incorrect text labels, but using the wire
numbers works perfectly. A few others have tried building it and loading MB
programs with no success. I'm using a GBC link cable that came with one of
my 3rd party accessory sets, probably Pelican. It has all 6 wires in it plus
a ground strap. The parallel port I'm using is in "Output Only" mode, on my
P75 laptop, which I believe is plain SPP mode. The multiboot image you're
loading must be in correct MB format, etc etc etc... and I usually pad mine
to a power of 2 using the fuGBAr util.

-Duo

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

>
> Thanks, this is what I thought too, so I'll try to find a GBA dedicated
> link cable, SD must really be present on those.
>

On most link cables that I've come across you can disassemble the GBA
connector plug to solder in an extra wire, so don't consign it to the junk
pile just yet ;0)


Dave

Jeff Frohwein wrote:
> I read Martin's notes and the fact that he mentioned that SD is only
> needed for "double speed" made no sense to me. It is required for
> multiboot as well unless he knows something that the rest of us
> don't. AFAIK, ALL of a multiboot image data (header and the rest) is
> tranferred on the SD line. That's how the MBV2 works anyway.

Thanks, this is what I thought too, so I'll try to find a GBA dedicated
link cable, SD must really be present on those.

> This makes no sense to me either, as mentioned above. I'm not saying
> you're wrong. I'm just saying I'm perplexicated(tm;) by these
> findings.

Yep, the fact the Nintendo logo always shows up on my GBA with the SI,
SO, SC, GND cable is really strange. This is my first test with a real
GBA so I don't know, but according to everything I read the Nintendo
logo is always displayed from the ROM image (transferred multiboot or on
cart) and not from the BIOS where it also present (to verify the other
one).

Isn't here anyone with direct contact to Martin "NO$" Korth to ask these
questions to the right man? First I wrote him a longer e-mail and only
realised he has no e-mail address anymore when it bounced back.

Credo <credo@...>

Claudio Bizzarri wrote:
>
> I'm using MBV2 for debugging: under w2k I've noticed that fgetc()
> subroutine does not function properly on file that contain 0x1b data, they
> are translated into 0x00. I suspect a problem in mb.exe program.

  You are correct. This bug is now fixed in v1.72 software. Thanks
for catching this problem.

  Jeff

--- In gbadev@y..., the-vigilante@s... wrote:
> Hey everyone,
>
> I have the exact same problem with GCC and Windows XP. First, I
got
> the error message that you're getting, but I fixed that by running
> the gcc .exe files in the /bin/ directory under Windows ME/2000
> compatibility mode. However, now I have a new error message:
>
> "0 [main] arm-agb-elf-gcc -3808 sync_with_child: child 1584(0x708)
> died before initialization with status code 0x1
> 330 [main] arm-agb-elf-gcc -3808 sync_with_child: *** child state
> waiting for longjmp"
>
> Thankfully, according to http://www.io.com/~fenix/devkitadv/
version
> 3.0.2 of GCC, which should be released tomorrow, will work with
> Windows XP.

I'm having this same problem with win xp. Did you or anyone ever
solve it?

Thanks in advance.

~hyperdev

Hello,

I've just noticed this strange thing when using DevKit Advance. I
generated .map file of my project and examined it -- there were this
(anonymous namespace)::foo symbols. I use anonymous namespaces when
I'd like to have my variables/functions/etc static. According to C++
standard I have it's the same as using "static" keyword (3.5
[basic.link].3). Now when I additionally put "static" keyword than all
these symbols are gone (from .map file _and_ some functions (most
probably inlined) are also removed from .gba -- its size decreased)!
Is this my fault or compiler/linker bug?

--
cheers
-Maciej

credo@... wrote:
> What kinda cable do you guys have? I used a Blaze GBC cable with only 4
> wires (no SD) without luck. According to this
> <http://www.work.de/nocash/gba-xboo.htm> the system have to work and
> boot up from the cable even with only SC, SO, SI and GND connection,
> only in half speed. But at the same time according to this
> <http://www.netcolony.com/technology/digitales/pc_gba.html> and this
> <http://members.truepath.com/AndrewMay/GBA.html> the SD line is
> absolutely needed for multiboot.

  I read Martin's notes and the fact that he mentioned that SD is only
needed for "double speed" made no sense to me. It is required for multiboot
as well unless he knows something that the rest of us don't. AFAIK, ALL
of a multiboot image data (header and the rest) is tranferred on the
SD line. That's how the MBV2 works anyway.

> However as it seems the Nintendo logo
> is transferred (so the whole header) without problem, only the rest of
> the data (what is uploaded with the NO$ protocol) is missing.

  This makes no sense to me either, as mentioned above. I'm not saying
you're wrong. I'm just saying I'm perplexicated(tm;) by these findings.

  Jeff

Maciej Sinilo yrp@... XXXXXXXXXXXXXXXXXXXX writes:
  > Hello Ben,
  >
  > Thursday, December 27, 2001, 8:10:01 PM, you wrote:
  >
  > >> Has anyone tried using the C++ Standard Template Library with the
  > >> DevKitAdv or other gcc-based setup?  If so, did you have any luck
  > >> getting it to work?
  > > The problem must be with DevKitAdv:  we use the STL (and Boost)
  > > extensively in our project with the gcc compiler from Nintendo (for
  > > registered developers) without any problems.
  > Aren't you afraid of code bloat? Using STL tends to result in very big
  > code being generated (of course it depends which parts do you use, I

Gcc's STL sucks arse.  If you've used STL elsewhere you'll find the
GNU version very limited.

In my professional experience we've always avoided using STL, but
that's mainly because it's absolutely not portable (which isn't really
a problem here.)  Well, STL itself is portable but each of the
implementations aren't.
--
Toby.

Foca wrote:
> I've tryed it but without any luck :(((
> I0ve seen other schematics the use resistors...it's time to try with
> them???

What kinda cable do you guys have? I used a Blaze GBC cable with only 4
wires (no SD) without luck. According to this
<http://www.work.de/nocash/gba-xboo.htm> the system have to work and
boot up from the cable even with only SC, SO, SI and GND connection,
only in half speed. But at the same time according to this
<http://www.netcolony.com/technology/digitales/pc_gba.html> and this
<http://members.truepath.com/AndrewMay/GBA.html> the SD line is
absolutely needed for multiboot. However as it seems the Nintendo logo
is transferred (so the whole header) without problem, only the rest of
the data (what is uploaded with the NO$ protocol) is missing.

So what is wrong, the NO$ cable docs stating that the system works
without SD? (Unfortunately Martin Korth cannot be contacted anymore.)
And if this is the case what kinda cable should I buy with SD wire? The
Blaze GBC cable was kinda expensive and seems to be useless.

Credo <credo@...>

bobscar.geo conraderj@... XXXXXXXXXXXXXXXXXXXX writes:
  > I would be interested in knowing how you compiled the devkit on BSD.
  >
  > I was trying to get it to work on Mac OS X - a little BSD heritage
  > somewhere in there. I had all kinds of problems getting the compiler
  > set up to do the arm stuff. I finally gave up.
  >
  > Do you have a step by step on how to set the compiler up that would
  > work on BSD (it should be similar for Mac OS X)?

Hrmm, I don't recall having a problem with it for FreeBSD.  OS X *is*
based on FreeBSD 3.2...

All I did was use the patches from devkitadv (the most valuable part)
and applied them and did the standard configure/make/make install.  I
used the included batch file as a rough guide I think, so maybe there
was a little bit of fiddling around but I don't think so.

[Flash back]  Hang on, I *do* remember having to manually put the
patched newlib files in the right place since the patch file wouldn't
work for me.  Are you having trouble with newlib?

What problems are you having specifically?  What version of gcc is
used as the OS X native compiler?
--
Toby.

Hello Ben,

Thursday, December 27, 2001, 8:10:01 PM, you wrote:

>> Has anyone tried using the C++ Standard Template Library with the
>> DevKitAdv or other gcc-based setup?  If so, did you have any luck
>> getting it to work?
> The problem must be with DevKitAdv:  we use the STL (and Boost)
> extensively in our project with the gcc compiler from Nintendo (for
> registered developers) without any problems.
Aren't you afraid of code bloat? Using STL tends to result in very big
code being generated (of course it depends which parts do you use, I
don't expect std::min to add kilobytes, but you wrote you use it
extensively, so I guess you talk about containers/algorithms?).

--
cheers,
-Maciej

It's a FAQ Question:
http://www.devrs.com/gba/files/gbadevfaqs.php#UndefEHFB
I am so shame to ask this question @_@
Thank you for the suggestion.

--- In gbadev@y..., Vitaly Vidmirov <front@p...> wrote:
> Hi lanmachiu!
>
> if it doesn't support interworking, use the libraries with support.
> how? RTFM!
>

> because... that label is not defined.
> I doesn't understand why you need this, but you can modify
> your linker script in this way:
>
> _EH_FRAME_BEGIN__ = .;
>   .eh_frame :
>   {
>     KEEP (*(.eh_frame))
>     . = ALIGN(4);   /* REQUIRED. LD is flaky without it. */
>   } = 0
> /*  laddr += SIZEOF(.eh_frame); */
>
> l> Why these happen?
>
> because of the errors ;)

I'm using MBV2 for debugging: under w2k I've noticed that fgetc()
subroutine does not function properly on file that contain 0x1b data, they
are translated into 0x00. I suspect a problem in mb.exe program.

The only solution that I found is modify the mbv2lib.c in this way:

204a216,219
  >          case __ESC_ESCCHR:
  >             __finstr[finptr++] = __ESCCHR;
  >             finptr &= (__FINBUFSIZE-1);
  >             break;
207,215d221
<             LastChar = 0;
<             break;
<          case __ESC_NADA:
<             LastChar = 0;
<             break;
< //         case __ESC_ESCCHR:
<               case 27:
<             __finstr[finptr++] = 0x1B;
<             finptr &= (__FINBUFSIZE-1);
218c224
<
---
  >       LastChar = 0;

Is a win2k problem, a my problem or a general one?

Claudio

Hi groepaz!

g> sure it doesnt still link in constructor/destructor tables and a bunch
g> of other crap?

mapfile:

.ctors          0x0804b310        0x4
                 0x0804b310                __CTOR_LIST__=.
  *(.ctors)
                 0x0804b310        0x4 LONG 0x0

.dtors
  *(.dtors)

I have no idea of where I should be posting this, since all of the sites
I normally visit seem to be gone or a severe lack of updates.  But
anyway...

I put together some code late yesterday/early today so I could figure
out how to program in Thumb assembly on the GBA.  It's just a small demo
(340 bytes :D), but I think I pretty much commented the code the death :)

It's located at http://homepage.mac.com/munsied/FileSharing2.html -- the
filename is colors.tgz .  It requires DevKitAdvance, or some other
gcc/gas setup to assemble/link it.  I haven't tested it on hardware, but
it worked pretty well with 4 different emulators -- including Mappy.

Please let me know what everyone thinks -- this is my first step into
actual coding on the GBA, as opposed to writing tools for the GBA :)

Also, if you have a site with source code and/or demos, feel free to
post this code there -- I've released it into the public domain, so you
don't even have to tell me about it if you don't want to.

dennis

At 14.00 20/12/2001 -0700, you wrote:
>Hi guys,
>You know, Martin Korth designed a parallel cable to upload multiboot
>programs which doesn't require any hardware, just a simple DOS transfer
>program. Look here for it:
>http://www.work.de/nocash/gba-xboo.htm

I've tryed it but without any luck :(((
I0ve seen other schematics the use resistors...it's time to try with them???



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

> Has anyone tried using the C++ Standard Template Library with the
> DevKitAdv or other gcc-based setup?  If so, did you have any luck
> getting it to work?

The problem must be with DevKitAdv:  we use the STL (and Boost)
extensively in our project with the gcc compiler from Nintendo (for
registered developers) without any problems.

Email me directly if you need more info.

-Ben

--
Ben Nason
  "Writin' in my book of rhymes, all the words past the margins" - Nas

Hello Vitaly,

Thursday, December 27, 2001, 6:59:57 AM, you wrote:

VV> Hi groepaz!

g>> its AgbMain() and NOT main() coz in the latter case gcc would
g>> automagically link in a bunch of stuff that isnt needed for
g>> plain ansi-c programs (but which is necessary for cpp)

VV> My entry point is main().
VV> -nostdlib + 3 function wrapper library
__gccmain,__builtin_new,__builtin_delete
VV> and i'm free from gcc crap.

sure it doesnt still link in constructor/destructor tables and a bunch
of other crap?

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

Hi groepaz!

g> its AgbMain() and NOT main() coz in the latter case gcc would
g> automagically link in a bunch of stuff that isnt needed for
g> plain ansi-c programs (but which is necessary for cpp)

My entry point is main().
-nostdlib + 3 function wrapper library __gccmain,__builtin_new,__builtin_delete
and i'm free from gcc crap.

Hi lanmachiu!

l> /cygdrive/f/Work/GBA/Project/TestCpp/testcpp.cc:2: undefined
l> reference to `__gccmain'

__gccmain isn't defined because libgcc.a doesn't get linked

l> ld: Warning: freer.o does not support interworking, whereas tutor.elf
l> does not

if it doesn't support interworking, use the libraries with support.
how? RTFM!

l> __main.o(.text+0x74): undefined reference to `__EH_FRAME_BEGIN__'

because... that label is not defined.
I doesn't understand why you need this, but you can modify
your linker script in this way:

_EH_FRAME_BEGIN__ = .;
   .eh_frame :
   {
     KEEP (*(.eh_frame))
     . = ALIGN(4);   /* REQUIRED. LD is flaky without it. */
   } = 0
/*  laddr += SIZEOF(.eh_frame); */

l> Why these happen?

because of the errors ;)

I don't know if anybody else got their hands on one of those but I got
mine today and proceeded to rip my agb open to give it a try.

It's very easy to install, easier than putting a reset switch for
example, due to the fact that no soldering is required.

They provide you with a two screwdrivers to open the agb (even the
tri-blade one, cool!) and also supply a new back plastic piece which
includes the docking connector.

You just have to open up the LCD connector on each sides (Jeff describes
that in his intructions to add a reset button) and slide in their own
cable TOGETHER with the normal cable. Close the unit back with the new
plastic piece and prompto, it works.

I don't plan on using it to play but as part of a development system, it
rules. I use a VGA box to display it back on another monitor and the
docking station also provides power.

Little minuses: The back piece is slightly different from the original
one and I had a harder time drilling a whole for my reset button in it.
Some screens are too static (or dark) and it makes either my monitor or
my VGA box (haven't determined yet) switch off thinking there's no
signal.

Anyway, altogether it's a great piece of hardware. Next time I open my
agb will be to put in the frontlight from portable monopoly.

-D

I would be interested in knowing how you compiled the devkit on BSD.

I was trying to get it to work on Mac OS X - a little BSD heritage
somewhere in there. I had all kinds of problems getting the compiler
set up to do the arm stuff. I finally gave up.

Do you have a step by step on how to set the compiler up that would
work on BSD (it should be similar for Mac OS X)?

Thanks,
John

--- In gbadev@y..., "Toby Hutton" <vjfaq5yxe12s001@s...> wrote:
> Hello,
>
> I'm new here, thought I'd delurk.  I'm curious - does anyone use
FreeBSD for GBA dev?  I am just starting out, and the first thing I
did was port ('translate' is probably a better word) Jeff F's flash
linker client for Linux to FreeBSD.  I straight port would be a little
difficult (due to the state of the code - sorry Jeff :)) so I've
rewritten it to use the ppi(4) interface, and in C++.  Is anyone
interested in it?
>
> vgba has a native FreeBSD version which works great and yesterday I
whipped up a Gimp plugin that would save images in a format suitable
for easy Mode 4 loading... GBA devkit makes building arm-agb GNU tools
a breeze... looks like Linux/*BSD are very viable platforms for GBA
development.
>
> Cool.  I like that.
>
> Anyway, back to fiddling with DMA... and the final boss on Wario
Land. :)
>
> Toby.

About 30 minutes ago I got a GameTech TV de Advance in the mail
from Lik Sang. (Unfortunately for European customers, it currently
only comes in NTSC output):

  http://www.lik-sang.com/catalog/product_info.php?category=6&products_id=1496&
  http://www.lik-sang.com/catalog/news.php?artc=2438

  And it works great! (Really... I'm not getting paid to say that. =P)
The picture and sound is really good IMHO. This is the only way to dev
GBA software for me from now on. This will probably extend my eye site
several years due to not having to squint at the small GBA screen. ;)

  It's got two switches along the bottom. One is power on/off and the other
switches between "pixel-correct small mode" and "full screen mode". In the
full screen mode, about every other line is double thickness to expand the
image vertically. (For the GBA racing game I tried, the image quality wasn't
greatly affected in full-screen mode, in my opinion.)
  You can leave the GBA power switch on all the time and just use the
external unit power switch to power on/off. Interestingly, if you turn off
the GBA power switch during game play then you will have a freeze frame
picture of the last game screen.

  The unit comes with a replacement back cover and 2 small screwdrivers.
(One is tri-wing. The other is regular phillips head.) The replacement back
cover comes with a quick-disconnect video connector. When installing the
replacement rear cover, you slide the provided very thin video cable into
the same video cable slot that the GBA screen uses. As a result, both the
GBA internal screen and the external video operate at the same time.

  The external video interface snaps onto the replacement back cover and
has a 10 foot (3 metre) audio/video cable provided. The external video
interface easily disconnects to allow you to use the GBA in portable mode
again. (It also comes with a US style AC adapter that powers the unit as
well as the GBA.)

  Internally, there are only 3 chips. One is probably a RAM chip (for storing
a video frame), on maybe is used for NTSC conversion, and the large chip
is a 100-pin ASIC or FPGA. There weren't any numbers on the chips except
the RAM chip: Q-Mark 02-QMARK-A00 0145

  Jeff

Hi Folks,

Has anyone tried using the C++ Standard Template Library with the
DevKitAdv or other gcc-based setup?  If so, did you have any luck
getting it to work?

When I try to build code using just about any of the STL types, I get
a clean compile but a few of the following linker errors:

     internal error: unsupported relocation error

This is with the latest DevKitAdv (with gcc 3.0.2).  Interestingly,
this is the same error I get when trying to link code using multiple
inheritance (see my post earlier today).  I can certainly live
without the multiple inheritance, but some of those STL classes would
be extremely useful...

Any ideas would be appreciated!

- Brian

>    From: Abel Vincze <abelgba@...>
>And my question is:
>Is this true, that GBA has the double Waveform ram as
>GBC, and only emulators don't support it?

Yes, on the GBC-compatible sound hardware, there is in fact 2 banks of wave
ram. It's accessible from GBA mode only, IIRC, and NOT GBC mode. I don't
know of the support within emu's but they all still pale in comparison to a
REAL GBA to test on. If you've got a GBA, but no flash cart or multiboot
cable because you're too poor, check out Martin Korth's XBOOT cable. It
takes 4 wires, no other hardware to make and runs perfectly well in pure DOS
and Win95 DOS boxes. =)
http://www.work.de/nocash/gba-xboo.htm
That way, you can test your sound code on a REAL gba using multiboot, and
don't have to rely on those emus.

-Duo

_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com