SamShady9638@... wrote:
> Hi. Lately me and my brothers Gameboy Advances occasionally display a
> corrupted nintendo logo and the game will not load. Taking out the

This is a programming mailing list (and as I know only the list owner
can let mails into it), I bet you can find some forums somewhere where
people are discussing such a problems. Maybe really the contact is your
problem, maybe some lines or the ROM inside your cartridge is broken or
unstable (try it with another cartridge) and maybe there's a problem
inside your GBAs (however 2 GBAs with the same problem would be
strange), maybe the BIOS itself is broken (what is taking the logo from
your cart and displaying on the screen). My tip is to try some more
cartridges or bring the carts and machines back to the shop where you
bought them.

Credo <credo@...>

I have never used the project manager that comes with arm sdt as I much
prefer the visual C ide.  There are a few tools that make compiling directly
from the IDE posable.  I do not know offhand what thay are though I do know
i got them off of gbadev.org .  I generaly just make a blank project and
create my source files then when I am ready I minimize the ide and compile
with a batch file.  As for an emulator with debugger I use mappy virtual
machine as it is, so far, the best in that regards.  It does not allow
source level debugging though if that is what you are looking for.  At least
not in the version I have.  Hope that helped.
-dovoto
(www.agbdev.net/thepernproject)

-----Original Message-----
From: eagle@... [mailto:eagle@...]
Sent: Saturday, June 30, 2001 1:09 PM
To: gbadev@yahoogroups.com
Subject: [gbadev] PERN Project SDK's and Emulators


First of all  Hat's off to the PERM project and it's author.  Such a
GREAT way for someone to get started using GBA.  Just being able to
run the tutor1 demo proving you can build something gives one
condfidence in developing right off the bat.

I was able also to take the sources and run them directly in the ARM
SDT v2.50 (had to use .s vs. .asm but that was nothing).  I was also
able to step through the code with the debugger.

Dropping tutor.bin onto one of the emulators (iGBA) worked fine also.

I couldn't really figure out how to GENERATE the tutor.bin file in
the project I created directly within the project manager - My guess
is something must be edited into the template of the project.  Does
anyone know how to do that and/or have done it.

The biggest thing needed - and perhaps it exists and someone can
point me there, is the ability to debug AND view what would be on the
screen in pure emulator mode (i.e. if you don't have hardware/cable
to run from the device.

Does anyone have any info on these things?


-Eagle



list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@egroups.com



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

Hi. Lately me and my brothers Gameboy Advances occasionally display a
corrupted nintendo logo and the game will not load. Taking out the game and
replacing it seems to work fine. I called nintendo becauuse I was kind of
pissed about this and the fed me a line about how it probably isn't clean
around the contact areas. Well I know this isn't true because I take great
care with my system and so does my brother, but i bought a cleaning kit and
cleaned the system and it still does it. Is anyone here having a similar
problem and does anyone know why this is happening.


[Non-text portions of this message have been removed]

Dan Potter wrote:
> - All demos I tried out (i.e., hobbyist things) did not work. I tried
> the only header corrector I could find with source code (to recompile
> for Linux) and that didn't help. It might be worth noting that VGBA
> also claims that these have an incorrect "CRC" (actually seems to be
> a checksum).

Don't trust in VGBA's CRC report. Marat mixed up something there. You
know earlier there was a secondary 16 bit CRC planned together with the
8 bit one, but Nintendo finally dropped it and that must be filled with
zeroes (offset beh-bfh) now. Also probably it is good to keep the
filesize at fixed powers of two (I'm not sure there's such a rule, but
all the official ROMs are either 4 or 8 megabyte large). Probably these
confused Marat and now he's verifying the lowest 16 bits of the filesize
with the unused 16 bit CRC I don't know why (I already mentioned him
this before). It is always correct in the official ROMs as 0000h is
stored there by default and the filesize is fixed 4 or 8 megabyte (so
0000h is the lowest 16 bit), but if a hobby stuff isn't padded to a
filesize like this, it's reporting an error, what is not an error. So
don't care about that one and turn it off in VGBA.

> <misc rant>Why do people release simple utilities like header fixers
> without source code? Not like there's some massive secret you're
> hiding in there...</misc rant>

Maybe you mean my stuff (or not), GBAFix, what is conflicting with
another GBAFIX, so I renamed now to GBARM (GBA ROM Manipulator) as this
is one of the few ROM fixers and was released without source. Sorry, I
rarely release source codes, 'coz my C coding style is too ugly, I only
do it in the case I code some tutorials directly to share. Not that it's
something special or there are some tricks. I just found a little bit
free time exactly now to finish and release GBARM, hopefully it will be
on <http://credo.resource.cx/> tonight or tomorrow (just spellchecking
the docs). Its large documentation is also useful without the tool, I
documented the whole header structure heavily, wrote history about the
checksums, formulas, etc too. So there's no secret, everything can be
recoded after the docs in a couple of mins too as these tools are plain
simple.

Credo <credo@...>

It's possible to emulate GBA cart using IO56 interface?
(http://www.ziegler.desaign.de/io56.htm)
Any1 could help me?

Appending my previous message:

I loaded up VMware with Win98 and set my BIOS to EPP+ECP mode (required
to make VMware happy) and ran the Visoly flash linker program. It works
alright. My test program was Chuck's "copper" demo that comes with
libgba. I then used their backup function to read back what was on the
cart and the checksums they inserted into the header are the same that
were reported by GBAFix, and that VGBA complains about. So VGBA's
checksum calculation is wrong.

I also tried reading back the flash cart using flinker and did a cmp on
the two files:

> cmp test2.bin test3.bin
test2.bin test3.bin differ: char 514, line 6

Further inspection shows that test3.bin (which is the flinker output) is
probably the first sector of the flash cart repeated over and over
again.

Hope that helps.

Hi Dan,

Dan Potter wrote:
> Today I compiled the flinker and tried it out on my Linux box. Here is
> the result of those experiments:
>
> - I had to go into my BIOS to set EPP-only mode before it would work.

  I've now got out v1.11 which attempts to correctly setup ECP chipsets
to work in EEP mode but I still have to set my bios to EPP-only mode, as
well, so I didn't gain much, that I can tell, by doing that. Still
working on this one...

> - All demos I tried out (i.e., hobbyist things) did not work. I tried
> the only header corrector I could find with source code (to recompile
> for Linux) and that didn't help. It might be worth noting that VGBA also
> claims that these have an incorrect "CRC" (actually seems to be a
> checksum).

  I'll add header correction as default in the next version. (You will be
able to disable header modification with an option.) In this version
there is no header changes. With my MBV2 software, I just replace the
header (by default) with a know working header. That is not an ideal
option since it messes with more bytes in the header than absolutely
necessary.

  Thanks for the feedback, btw. More stuff soon. I know I can get the
software at least as reliable as the Visoly software since I'm using it
as a guide. ;) I'll do more comparisons to see what I'm doing different.

  BTW, SRAM dumping now works but there is no command line option yet
to access it. It seems the VisolyUnlock code I identified earlier was
actually a ROM read/write mode selection. There is an SRAM read/write
mode selection as well.

Thanks,

  Jeff

Unfortunately I've got bad news too... =)

On Jun 29, Jeff Frohwein wrote:

>  I couldn't get it to work in linux with my parallel port set for ECP+EEP.
> (fl -d reports all zeros for everything.) It wouldn't work in EPP or SPP
> (-m) mode for some reason. Which is strange because other SPP software
> I've written for linux works just fine with the bios set to ECP+EPP mode.
>
>  When I set the port to just EPP mode in the bios then it started working
> fine. I remember someone mentioning a similar problem in Windows when
> using the Visoly PC software.  It sounds like either the Visoly software
> (which I used as a guide) is not properly setting up a ECP+EEP port or
> else I didn't follow their init code exactly.
>
>  Either way, it sounds like there may be a register I need to setup to
> make sure that EPP mode (or SPP) is always properly enabled on startup.
> I'll see what I can dig up.

Today I compiled the flinker and tried it out on my Linux box. Here is
the result of those experiments:

- I had to go into my BIOS to set EPP-only mode before it would work.

- All demos I tried out (i.e., hobbyist things) did not work. I tried
the only header corrector I could find with source code (to recompile
for Linux) and that didn't help. It might be worth noting that VGBA also
claims that these have an incorrect "CRC" (actually seems to be a
checksum).

<misc rant>Why do people release simple utilities like header fixers
without source code? Not like there's some massive secret you're hiding
in there...</misc rant>

- I had previously dumped my Chuchu Rocket and Castlevania just to test
out the flash cart, so I tried loading those up using flinker. Chuchu
Rocket worked fine on the first try. Then I loaded up Castlevania, and
got a corrupted "Nintendo" logo on the boot screen, and it froze. Just
for kicks, I tried loading up Chuchu again and it no longer worked
either (goes past boot screen, but freezes with a blank screen).

I also tried after that using the "-w 500" suggestion, -m mode, etc.. At
this point nothing seems to work using flinker. I am going to install
VMware on my Linux box and try out Visoly's util again (it was with my
roomate's box before) to see if there's some weird hardware
incompatibility but I don't think that's it. The other possibility is
that I might not be using a good enough cable, but I kind of doubt that
since Chuchu Rocket loaded up that first time.

Just for kicks I also tried the -v option a few times in there. When it
worked on the first Chuchu Rocket load, it said that the flash matched
correctly. Now it gives me this for every byte:

Address 200 - Cartridge 2e : File 28
Address 201 - Cartridge 0 : File 91
Address 202 - Cartridge 0 : File 9f
Address 203 - Cartridge ea : File e5
Address 204 - Cartridge 24 : File 3
Address 205 - Cartridge ff : File 61
Address 206 - Cartridge ae : File 82
Address 207 - Cartridge 51 : File e0
Address 208 - Cartridge 69 : File 10
Address 209 - Cartridge 9a : File 70
Address 20a - Cartridge a2 : File 96
... etc ...

This may also be mildly interesting:

./fl -d
...
0a0 - 43 48 55 43 48 55 52 4f 43 4b 45 54 41 43 52 45 CHUCHUROCKETACRE
0b0 - 36 57 96 00 00 00 00 00 00 00 00 00 00 21 00 00 6W...........!..
...

That sort of seems to imply that it's failing on blocks >0.

Anyway, I hope that feedback helps, let me know if I can provide any
other info that might solve the problem. I'm pretty excited to finally
be able (well, once this works =) to bypass the moronic restrictions
Visoly has implicitly placed on their product. Thanks a ton Jeff.

(PS, for anyone who cares -- I don't have something against them
personally, but upon requesting info about programming for it or for
Linux, they said that they wouldn't release it for a while since they
needed to "protect their intellectual property" from competetors.. at
which point I laughed my head off for a minute or so...)

> Hi everyone.   Ok, my first question is... are the palette entries 32-bit
on the GBA?   In the doc by AgentQ, he says the first palette is
0x05000000 - 0x05000200.. so that's 512... 16-bit entries.   Ok, so if
that's true, does the ARM compiler only index by byte values?

Hi Greg, palette entries are indeed 16bit, infact, they're 15bit thus being
BGR = 555. bit 15 is unused.  2nd question, you set a 16bit pointer to
palette, so its a 2-byte index. for example:

void SetPalette(u16 *MyPal, u32 Num)
{
     for (; Num; --Num)
         *BGPALETTE++ = *MyPal++;
}

and call: SetPalette((u16 *)SomePalette, 256);

HTH.

regards,

Peter.

Hi everyone.   Ok, my first question is... are the palette entries 32-bit on the
GBA?   In the doc by AgentQ, he says the first palette is 0x05000000 -
0x05000200.. so that's 512... 16-bit entries.   Ok, so if that's true, does the
ARM compiler only index by byte values?

For example:

for(..........i+=2)
............ = palette[i];

Why should you have to add 2 to i to access the next element in the array?   
The compiler should handle the size of the array elements and offset that number
of bytes automatically....

Is GCC any different?  Or the only compiled for ARM target.   I know standard
GCC for any OS isn't like this.   Or is this a quirk with the actual ARM/GBA
platform?


     Thanks for your help..
                                                         Greg


[Non-text portions of this message have been removed]

First of all  Hat's off to the PERM project and it's author.  Such a
GREAT way for someone to get started using GBA.  Just being able to
run the tutor1 demo proving you can build something gives one
condfidence in developing right off the bat.

I was able also to take the sources and run them directly in the ARM
SDT v2.50 (had to use .s vs. .asm but that was nothing).  I was also
able to step through the code with the debugger.

Dropping tutor.bin onto one of the emulators (iGBA) worked fine also.

I couldn't really figure out how to GENERATE the tutor.bin file in
the project I created directly within the project manager - My guess
is something must be edited into the template of the project.  Does
anyone know how to do that and/or have done it.

The biggest thing needed - and perhaps it exists and someone can
point me there, is the ability to debug AND view what would be on the
screen in pure emulator mode (i.e. if you don't have hardware/cable
to run from the device.

Does anyone have any info on these things?


-Eagle

Here's some code I just got working others may find useful.  You supply the
inverse scale (saves a divide) and the center of rotation on the screen (usually
120,80) and the center of rotation in the world.

It's basically a 2D rotation matrix you can find in any linear algebra book --
the only extra interesting step is that you have to transform the negative of
the screen position through the rot/scale coefficients to compute the proper
anchor point for the upper-left-hand corner of the screen.

I tried several different test cases and they all worked as expected, but please
let me know of any bugs.

void scr_rotate(s32 offs[2],s16 rot[4],int theta,
         int invScaleX, int invScaleY,
         int screenX,int screenY,
         int worldX,int worldY) {

         // invScaleX and invScaleY are .8, and output is .8.
         // screen[XY] and world[XY] are integers
         rot[0] = (invScaleX * fcos(theta)) >> cos_fbits;
         rot[1] = (invScaleX * fsin(theta)) >> cos_fbits;
         rot[2] = (-invScaleY * fsin(theta)) >> cos_fbits;
         rot[3] = (invScaleY * fcos(theta)) >> cos_fbits;

         // Compute final offset
         offs[0] = (worldX << 8) + (rot[0] * -screenX + rot[1] * -screenY);
         offs[1] = (worldY << 8) + (rot[2] * -screenX + rot[3] * -screenY);
}

In case you don't have your own yet, here are my basic trig routines...

// pseudo degrees go from 0 to 255
extern short cos_table[256];
extern __inline int fcos(int x) { return cos_table[x & 255]; }
extern __inline int fsin(int x) { return cos_table[(x - 64) & 255]; }

// number of fractional bits; allows 1.0 to be exact, and leave room for sign.
#define cos_fbits 14

and the code to generate the shared LUT:

#include <math.h>
#include <stdio.h>

void main() {
         int i;
         printf("short cos_table[256] = {\n");
         for (i=0; i<256; i++) {
                 float theta = i * 2 * 3.1415926535897932384626433832795f / 256;
                 printf("\t%d,\n",(int)(cos(theta) * 16384));
         }
         printf("};\n");
}

Hope this helps,

-Dave


[Non-text portions of this message have been removed]

Allthough I much prefer posative feedback, Negative feedback is allways the
most usefull.  As I am focusing must of my time on the next tutorial any
help with fixing the previouse ones would be much apreciated by me and most
of the people who read my site as well.  I do have people working on the
rewrite to proper html so any major corections should probably wait until
the html has been converted.   But I will glady take any sugestions you have
now.
thanks
-dovoto

-----Original Message-----
From: Charlie Kilian [mailto:ck@...]
Sent: Friday, June 29, 2001 8:55 PM
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] The Pern project ...


>
> Day three was posted on friday I think.  If anyone cares I am having
someone
> rewrite them into proper html which should reduce there size quite a bit.
> When I get back I will try to fix all the errors that were found in day
two.
>

I might be interested in revising them for small errors.  I noticed that
there were some misspellings and grammar things, and also some of the
constants and variable names weren't consistant throughout which caused me
some minor problems when I was working through the tutorials.

If it wouldn't offend you too much, I might do a rewrite and get it to
you. I know its never fun to have your work edited, but I thought it might
be helpful to future readers. Would you (dovoto) or anyone else for that
matter be interested in such a thing?

Charlie Kilian
aka tad




list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@egroups.com



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

On Jun 30, D.Cotter wrote:

> you can calculate it using the formulas in the programming manual and a
> little trig. know how
> the hard part is getting into the right form so you dont use divide

I don't know how applicable this comment is to the discussion (because I
haven't looked at that hardware stuff yet), but back in the bad old days
of DOS demos, divide was also an evil operation. What we did then was to
make _everything_ center around powers of two: rotation "degrees" are
0..1023 or 0..2047; Sin goes between -128 and 127 (or -32768 and 32767,
etc). Then when you multiply the numbers, it's usually a matter of
shifting to get back the right scale. Also if you use fixed point with a
binary base this helps a lot (like 16 bits integer / 16 bits fract, or 8
bits integer / 24 bits fract, etc, depending on what you need). A lot of
the time the fixed point numbers can be added, multiplied, etc, directly
as long as you're careful about overflow.

It probably also helps to use some lookup tables because ROM is
relatively cheap in the GBA (so is RAM actually, compared to similar
older systems...).

Hope that helps...

Hi,

I'm trying to add some rotation to my sprite and I am having no
success. I do not have access to the "real" manuals so all my coding
up to now has been from the lists/web and other's samples.

The following code snippet gives the basic idea of what my code does
and I cannot see why it doesn't work!

Any help would be GREATLY appreciated.

Thanks,
Darren (www.sillett.com/gba)

------------
#define OBJ_ROTATION  0x100  // Rotation
#define OBJ_ROTATE(n)  (n << 9) // Use rotation index
n
#define OBJ_ROTATE_MASK  0x3e00

const s32 s32Sin[] =
{ 0x00000000, 0x00000004, 0x00000008, 0x0000000d,
   0x00000011, 0x00000016, 0x0000001a, 0x0000001f,
   0x00000023, .... };

const s32 s32Cos[] =
{ 0x00000100, 0x000000ff, 0x000000ff, 0x000000ff,
   0x000000ff, 0x000000ff, 0x000000fe, 0x000000fe,
   0x000000fd, .... };

typedef struct sGBA_OAMEntry
{
	 u16 attribute0;
	 u16 attribute1;
	 u16 attribute2;
	 u16 attribute3;
} GBA_OAMEntry;

typedef struct sGBA_OAMRotationEntry
{
	 u16 filler1[3];
	 u16 pa;
	 u16 filler2[3];
	 u16 pb;
	 u16 filler3[3];
	 u16 pc;
	 u16 filler4[3];
	 u16 pd;
} GBA_OAMRotationEntry;

GBA_OAMEntry  g_GBA_OAMShadow[128];
GBA_OAMRotationEntry *g_GBA_OAMRotation;

	 g_GBA_OAMRotation = (GBA_OAMRotationEntry *) g_GBA_OAMShadow;

	 g_GBA_OAMShadow[0].attribute0 |= OBJ_ROTATION;
	 g_GBA_OAMShadow[0].attribute1 &= ~OBJ_ROTATE_MASK;
	 g_GBA_OAMShadow[0].attribute1 |= OBJ_ROTATE(0);

	 g_GBA_OAMRotation[0].pa =  s32Cos[_s16Angle];
	 g_GBA_OAMRotation[0].pb =  s32Sin[_s16Angle];
	 g_GBA_OAMRotation[0].pc = -s32Sin[_s16Angle];
	 g_GBA_OAMRotation[0].pd =  s32Cos[_s16Angle];
------------

Many thanks!

> Go to www.zophar.net and look under "Translation Utils". I've got a
> package of 8*8 fonts in Gameboy format at
> www.helsinki.fi/~ammonton/gb/fonts.zip
>
> -Anders

you can calculate it using the formulas in the programming manual and a
little trig. know how
the hard part is getting into the right form so you dont use divide

> I forgot the BG2X/BG2Y are 32 bit registers instead of 16 bit registers
(as
> I had), so when the offset got too big it would wrap around.  Sorry to
keep
> posting to myself, but maybe it will help someone else :)  I still
wouldn't
> mind knowing where that formula came from, though...

I tried the new version and using -w 500 still drops some data.

I'm using a 200Mhz laptop so I can't imagine it's that speed demon
causing the problem. :o)

I will investigate further over the week-end and let you know what I
find.

Thanks,
-D

--- In gbadev@y..., Jeff Frohwein <jeff@d...> wrote:
>  The Visoly version used an incredibly inefficient library call to
> do port input/output which is why their version is slower. My faster
> version is probably too fast for your hardware, if I had to guess.
> As a result, I've added a -w option to v1.1 that is now online. Try
> -w 500 and drop the value until it's no longer reliable then add
> 50% to the number... or something.

>
> Day three was posted on friday I think.  If anyone cares I am having someone
> rewrite them into proper html which should reduce there size quite a bit.
> When I get back I will try to fix all the errors that were found in day two.
>

I might be interested in revising them for small errors.  I noticed that
there were some misspellings and grammar things, and also some of the
constants and variable names weren't consistant throughout which caused me
some minor problems when I was working through the tutorials.

If it wouldn't offend you too much, I might do a rewrite and get it to
you. I know its never fun to have your work edited, but I thought it might
be helpful to future readers. Would you (dovoto) or anyone else for that
matter be interested in such a thing?

Charlie Kilian
aka tad

I coded a tool back at the start of the year to do this, simply
checked the timestamp of a file which was in a public directory on
the works lan, then AGBLOADed it on file update. The IS-Emu program
has a function called Watch File in the Tools menu that does exactly
the same thing. In this way other people on the network can send
stuff to the *public* devkit, while us programmers are
uninterrupted :)

Now a tool that can flash-on-demand, and physcially put the cart in
the burner for you is what we now need ;)


--- In gbadev@y..., "Jack Ukleja" <jack.ukleja@n...> wrote:
> A genius programmer colleague of mine has started to code up a
server/client
> system to allow the IS-AGB devkit to be shared over a network,
upload
> programs remotely etc. If it turns out to be very useful, it could
become
> available for other people to use if interested.
>
> Anyway Jeff, about your MBV2 cables. I've not follwed reccent
goings on, but
> are you planning on making any more of these available? If not,
then would
> you consider selling/licensing it to a hardware manufacter so that
it could
> be 'mass' produced? I just think it would be a really useful tool
for
> artists without having to spend £1000s on devkits, when all they
need to do
> is ocassionally look at graphics!
>
> :-)
>
> Cheers,
> Jack Ukleja

Hi!

> and using a 110v->220v tranformer for every devkit
> will be a bit messy (and expensive).

Buy one then connect a 1:6 adaptor :) Cheap and easy ;)

Bye! :)

Let's go to electronic shop!
You'll find an adpapter from US input tension to UK one!!!
(I did so!)
faustus!
----- Original Message -----
From: "Chris Pepin" <cpepin1@...>
To: <gbadev@yahoogroups.com>
Sent: Friday, June 29, 2001 11:05 PM
Subject: Re: [gbadev] Uk mains adaptor?


>
> >Anyone know where I can find a UK mains adaptor that will supply the
> >correct
> >input for the IS devkits? It needs to out DC10V @ 850mA . I've looked on
> >Maplins but there dosnt seem to be anything suitable. How strict do you
> >reckon these input parameters are? There are many adaptors that output 9V
> >and 12V but none at 10V! (and not the correct ampage either)
> >
> >Thanks to the guys who replied to my question yesterday by the way.
> >
> >Jack Ukleja
>
>
> Have you tried a Super Nintendo or Virtual Boy AC Adaptor?
> Here in the U.S. their specs are 10V DC 850Ma Negative Tip. I'm sure
they're
> the same or very close for the UK.  Doublecheck before using of course.
:-)
> Also, make sure you know what polarity is needed for the dev kit.  If you
> use the wrong polarity you could toast something.
>
> Chris Pepin
> cpepin1@...
>
> --------------------------------------------------
> Tom Swift and His Electronic Web
> http://www.geocities.com/cpepin1976
> --------------------------------------------------
>
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
>
>
>
> list rules: http://www.gbadev.org/rules.txt
> unsubscribe: gbadev-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>

Thanks guys. I dont think it will be very easy to find a good supply of snes
power supplies, and using a 110v->220v tranformer for every devkit will be a
bit messy (and expensive). I will try getting a Unicross 1200R from Maplin
as someone suggested.

Cheers,

----- Original Message -----
From: "Ben Carter" <benml@...>
To: "Chris Pepin" <gbadev@yahoogroups.com>
Sent: Friday, June 29, 2001 10:37 PM
Subject: Re: [gbadev] Uk mains adaptor?


> On Friday, June 29, 2001, 10:05:50 PM, someone wrote:
>
> [snip]
> > Have you tried a Super Nintendo or Virtual Boy AC Adaptor?
> > Here in the U.S. their specs are 10V DC 850Ma Negative Tip. I'm sure
they're
> > the same or very close for the UK.  Doublecheck before using of course.
:-)
> > Also, make sure you know what polarity is needed for the dev kit.  If
you
> > use the wrong polarity you could toast something.
>
>  Watch out here - IIRC the UK SNES PSUs were 10v *AC* (the supply was
> rectified internally by the SNES).
>
>  It's been a while so I could be wrong, but I'm fairly sure this was
> the case - look carefully before plugging anything in!
>
> --
> Ben Carter - Neko Technologies - ben@...
> http://www.neko-tech.com/ - http://www.absoluteterror.com/
> ---------------------------------PGP Key available on request---
> "Broken mirror, a million shades of light,
>  the old echo fades away.
>  But just you and I can find the answer,
>  and then we can run to the end of the world."
>                                 -

Hey D,

dids@... wrote:
>
> I feel bad but I guess I'll be the first one to report a problem.
>
> It seems like my parallel link is droping the top 4 bits of some of
> the bytes during transmissions.

  The Visoly version used an incredibly inefficient library call to
do port input/output which is why their version is slower. My faster
version is probably too fast for your hardware, if I had to guess.
As a result, I've added a -w option to v1.1 that is now online. Try
-w 500 and drop the value until it's no longer reliable then add
50% to the number... or something.

> I'm assuming this is affecting both upload and download as I am yet to
> flash a working executable under linux but the same linker/cable/card
> works fine under windows.

  I couldn't get it to work in linux with my parallel port set for ECP+EEP.
(fl -d reports all zeros for everything.) It wouldn't work in EPP or SPP
(-m) mode for some reason. Which is strange because other SPP software
I've written for linux works just fine with the bios set to ECP+EPP mode.

  When I set the port to just EPP mode in the bios then it started working
fine. I remember someone mentioning a similar problem in Windows when
using the Visoly PC software.  It sounds like either the Visoly software
(which I used as a guide) is not properly setting up a ECP+EEP port or
else I didn't follow their init code exactly.

  Either way, it sounds like there may be a register I need to setup to
make sure that EPP mode (or SPP) is always properly enabled on startup.
I'll see what I can dig up.

  Jeff

On Friday, June 29, 2001, 10:05:50 PM, someone wrote:

[snip]
> Have you tried a Super Nintendo or Virtual Boy AC Adaptor?
> Here in the U.S. their specs are 10V DC 850Ma Negative Tip. I'm sure they're
> the same or very close for the UK.  Doublecheck before using of course. :-)
> Also, make sure you know what polarity is needed for the dev kit.  If you
> use the wrong polarity you could toast something.

  Watch out here - IIRC the UK SNES PSUs were 10v *AC* (the supply was
rectified internally by the SNES).

  It's been a while so I could be wrong, but I'm fairly sure this was
the case - look carefully before plugging anything in!

--
Ben Carter - Neko Technologies - ben@...
http://www.neko-tech.com/ - http://www.absoluteterror.com/
---------------------------------PGP Key available on request---
"Broken mirror, a million shades of light,
  the old echo fades away.
  But just you and I can find the answer,
  and then we can run to the end of the world."
                                 - Small of two pieces, Xenogears

ok, now I'm confused... or maybe I'm not... the definition of
polymorphism I was using is (from Bruce Eckel's Thinking in C++):

Polymorphism (implemented in C++ with virtual functions) is the third
essential feature of an object-oriented programming language, after data
abstraction and inheritance.

But, looking up polymorphism on whatis.com, gave me this:

"In object-oriented programming, polymorphism (from the Greek meaning
"having multiple forms") is the characteristic of being able to assign a
different meaning to a particular symbol or "operator" in different
contexts.

For example, the plus sign (+) can operate on two objects such that it
adds them together (perhaps the most common form of the + operation) or,
as in boolean searching, a + can indicate a logical "and" (meaning that
both words separated by the + operator must be present in order for a
citation to be returned). In another context, the + sign could mean an
operation to concatenate the two objects or strings of letters on either
side of the + sign.

A given operator can also be given yet another meaning when combined
with another operator. For example, in the C++ language, a "++"
following a variable can mean "increment this value by 1". The meaning
of a particular operator is defined as part of a class definition. Since
the programmer can create classes, the programmer can also define how
operators work for this class of objects; in effect, the programmer can
redefine the computing language. "

Looking at both of these definitions, they look like they are talking
about different things.  But looking closer at the whatis definition,
the first sentence summarizes it by saying "different meaning to a
particular symbol or "operator" in different contexts".  This would be
similar to function foo() in class A doing something different than
function foo() in class B.

So, I guess we are both right, since according to the whatis definition,
function overloading and virtual functions are both examples of
polymorphism.

dennis

On Friday, June 29, 2001, at 06:15  AM, Matthew Porth wrote:
> I am not quite sure in what context Dennis is using polymorphism but if
> you
> are using polymorphic class functions (functions with the same name but
> different prototypes) I don't think this will add to the execution time
> at
> all as the correct function is located at compile time
> class rob {
>     bool dan(int joe);
>     bool dan(char *anu);
> };
> A function call robclass->dan(somevariable) should be statically linked
> as
> the type of somevariable is known at compile time.

>Anyone know where I can find a UK mains adaptor that will supply the
>correct
>input for the IS devkits? It needs to out DC10V @ 850mA . I've looked on
>Maplins but there dosnt seem to be anything suitable. How strict do you
>reckon these input parameters are? There are many adaptors that output 9V
>and 12V but none at 10V! (and not the correct ampage either)
>
>Thanks to the guys who replied to my question yesterday by the way.
>
>Jack Ukleja


Have you tried a Super Nintendo or Virtual Boy AC Adaptor?
Here in the U.S. their specs are 10V DC 850Ma Negative Tip. I'm sure they're
the same or very close for the UK.  Doublecheck before using of course. :-)
Also, make sure you know what polarity is needed for the dev kit.  If you
use the wrong polarity you could toast something.

Chris Pepin
cpepin1@...

--------------------------------------------------
Tom Swift and His Electronic Web
http://www.geocities.com/cpepin1976
--------------------------------------------------

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

I feel bad but I guess I'll be the first one to report a problem.

It seems like my parallel link is droping the top 4 bits of some of
the bytes during transmissions.

i.e:

sometimes the chip manufacter is detected as 0x7 instead of 0x17

or

when I flash data and then read it back some bytes have their top 4
bits zeroed out.

I'm assuming this is affecting both upload and download as I am yet
to
flash a working executable under linux but the same linker/cable/card
works fine under windows.

I haven't had time to investigate it very far so I might be missing
something obvious.

-D

> ----- Original Message -----
> From: "Jeff Frohwein" <jeff@d...>
> To: <gbadev@y...>
> Sent: Friday, June 29, 2001 4:31 AM
> Subject: [gbadev] GBA Flinker v1.0 is ready
>
> >  My GBA Flinker v1.0 tool is now online with src code:

I forgot the BG2X/BG2Y are 32 bit registers instead of 16 bit registers (as
I had), so when the offset got too big it would wrap around.  Sorry to keep
posting to myself, but maybe it will help someone else :)  I still wouldn't
mind knowing where that formula came from, though...
Cheers,
-V

-----Original Message-----
From: Dickinson, Vince [mailto:vinced@...]
Sent: Friday, June 29, 2001 12:10 PM
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] rotation scaling register question


Also, I just pulled the BG2X_L, BG2Y_L formulas from another post and, while
I'm excited they let me move the rotation point around, I'd like to know
where they came from.  When I use them that's when the problems start.  If I
leave them alone I can rotate fine around the upper left corner of the
screen.  From where were those formulas derived and are the any special
restrictions on there use?
Thanks 10^6
-Vince

-----Original Message-----
From: Dickinson, Vince [mailto:vinced@...]
Sent: Friday, June 29, 2001 11:14 AM
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] rotation scaling register question


Just curious - I think I'm having the same problem as Kiasecto trying to
rotate my mode 2 background. As I rotate from 0-360 the background flips
around several times (probably at 33deg, 123deg, etc).  I have a 512x512
tiled background that I want to spin around from the center of both the
screen and the tile map and it keeps jumping around to different parts of my
tile map as I rotate.  Did anyone answer this? I couldn't find any response
in the message archives.

FYI, every frame I'm updating:

BG2X_L = 120 - (BkgdY * sin_lut[bkgd_angle_index]) - (BkgdX *
cos_lut[bkgd_angle_index]);
BG2Y_L = 80 - (BkgdY * cos_lut[bkgd_angle_index]) + (BkgdX *
sin_lut[bkgd_angle_index]);
BG2PA = cos_lut[bkgd_angle_index]; //fixed; // PA
BG2PB = sin_lut[bkgd_angle_index]; //fixed; // PB
BG2PC = -1*sin_lut[bkgd_angle_index]; //-1*fixed; // PC
BG2PD = cos_lut[bkgd_angle_index]; //fixed; // PD

With BkgdX,BkgdY being the center of rotation relative to the screen (i.e.
120,80).

Thanks,
Vince

-----Original Message-----
From: Kiasecto [mailto:kiasecto@...]
Sent: Thursday, June 07, 2001 8:34 AM
To: gbadev@yahoogroups.com
Subject: Re: [gbadev] rotation scaling register question


You would think that with the MBV2 cable available emu authors would test
things to make sure,
I funny thing happening with my rot/scal program, it works perfectly on
256x256 or below background sizes, but anything above that causes the
background to flip over at 33degrees, 123degress, etc. and i have no idea
why.


At 19:58 2001-06-07 +1000, you wrote:
>Look, is everyone dead-certain of the format 1:28:8?  (ie:
signed-magnitude,
>1 sign bit, 28 integer bits, 8 fractional?)
>Discussions in #gbadev indicate that rotation values are in fact 2's
>complement, which makes more sense to me.

They are 2 complement. The documents are a bit confusing when it says
1 bit is for the sign, but one could argue that this is the case
with 2 complements as well as signed-magnitude.

Both the dx/dy/dmx/dma and x/y have 8 fractional bits, and a different
number
of bits in total, 16 vs 28.




unsubscribe: gbadev-unsubscribe@egroups.com



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



list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@egroups.com



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



list rules: http://www.gbadev.org/rules.txt
unsubscribe: gbadev-unsubscribe@egroups.com



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

If these were taken from my post I made them up.  It was trial an error
mainly and works fine in mode2 on 128x128 and 256x256 backgrounds.  I have
not tested any further than that so I do not know if there are restrictions.
If you are using my code and find the error I would love to see it
(preferably before I finish day 4 of my tutorial).
thanks
-dovoto

-----Original Message-----
From: Dickinson, Vince [mailto:vinced@...]
Sent: Friday, June 29, 2001 1:10 PM
To: 'gbadev@yahoogroups.com'
Subject: RE: [gbadev] rotation scaling register question


Also, I just pulled the BG2X_L, BG2Y_L formulas from another post and, while
I'm excited they let me move the rotation point around, I'd like to know
where they came from.  When I use them that's when the problems start.  If I
leave them alone I can rotate fine around the upper left corner of the
screen.  From where were those formulas derived and are the any special
restrictions on there use?
Thanks 10^6
-Vince