#27974 - Outlaw - Mon Oct 25, 2004 5:47 pm
Hi folks,
not long ago I found the beautiful GBA and started coding it using assembly language and the really nice GoldRoad Assembler. But 'cause it's a bit strange to code some nice effects only in plain assembly I switched back to the PC (win32), learned C-language and used the nice LCC Compiler.
Now, I want to do some codings for GBA using C-language.
and now my question ;-)
Is there any nice, short C-Compiler for the GBA (DOS/Win) ? I know, that there are some compilers discussed, like the GCC or DEVkit and so on ... but I don't want that huge ugly compilers which have to get installed with a lot of trouble ...
I don't need special libraries (except the standard-libraries), don't need a GUI or that stuff (Notepad rules :-) - I am a self made coder (oldschool :-) ... so, just a straight forward C ARM Compiler, nothing more ..
... okay, thanks a lot
[my search for compilers wasn't successful neither using google nor here in the forum ...]
Bye
Outlaw/yakuza
www.yakuza.de.be
#27976 - tepples - Mon Oct 25, 2004 6:00 pm
DevkitARM is a C compiler targeting ARM7TDMI, and I didn't find it all that difficult to install. Just unzip, set your path, and start compiling. If you're worried about install footprint, it'd take deleting less than a dozen pirated MP3s to make room for it.
I think LCC has an ARM7T* target, but I don't know how its code generator compares to GCC's.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27978 - Outlaw - Mon Oct 25, 2004 6:06 pm
Hi,
| tepples wrote: |
| DevkitARM is a C compiler targeting ARM7TDMI, and I didn't find it all that difficult to install. Just unzip, set your path, and start compiling. |
Yeah, I tried that stuff .. Devkit, GCC etc. ... and I didn't get it work; they compiled , but that stuff didn't run on the emulators. Btw. I don't like the installation-overhead ...
| tepples wrote: |
it'd take deleting less than a dozen pirated MP3s to make room for it.
|
hm .. ?????
| Quote: |
I think LCC has an ARM7T* target, but I don't know how its code generator compares to GCC's. |
I'll try it ...
Bye
Outlaw/yakuza
www.yakuza.de.be
#27979 - DiscoStew - Mon Oct 25, 2004 6:06 pm
DevKitARM is not very hard to install since the instructions to installing it are on the main site ("devkit.tk", under "Setting Up"). You may take a little bit to download it if you have a dial-up modem, but compared to the DevKitAdv compiler, DevKitARM is much smaller. You'll also need to install MSYS, as makefiles require it (I guess). If you need help with makefiles, search the forums on that.
EDIT:
DOH! I got here too late...
EDIT #2:
| Outlaw wrote: |
| Yeah, I tried that stuff .. Devkit, GCC etc. ... and I didn't get it work; they compiled , but that stuff didn't run on the emulators |
Did you try your own code, or someone elses. If something doesn't seem to be working, and you don't know why, try working with little pieces of code, like a blank 'main' function, then work one step at a time bringing the rest of your code into it, compiling every few sets of added code. For me, I usually find some problems with a non-working function(s) when I examine them piece by piece.
_________________
DS - It's all about DiscoStew
#27982 - Outlaw - Mon Oct 25, 2004 6:25 pm
hi,
| discostew wrote: |
| Did you try your own code, or someone elses. If something doesn't seem to be working, and you don't know why, try working with little pieces of code, like a blank 'main' function, then work one step at a time bringing the rest of your code into it, compiling every few sets of added code. For me, I usually find some problems with a non-working function(s) when I examine them piece by piece. |
Yeah, that was the way I tried ... simple short piece of code; debugged it and didn't find anything of that code :-( ... [and I know how debugging is done :-)]
Bye
Outlaw
www.yakuza.de.be
#27983 - pyros - Mon Oct 25, 2004 6:34 pm
| Outlaw wrote: |
Is there any nice, short C-Compiler for the GBA (DOS/Win) ? I know, that there are some compilers discussed, like the GCC or DEVkit and so on ... but I don't want that huge ugly compilers which have to get installed with a lot of trouble ...
|
I think i understand what you mean. I used to code only assembly, and the assemblers i used were only a few k.b., stored in one executable without having masses of supporting files, and worked very cleanly and efficiently.
It would indeed be nice if there were a similar ARM C compiler. However, i think the best you would get would be a commercial compiler.
I'm using devkitadv (gcc) which is the only setup i got to work easily, and even that took a some fiddling with makefiles. Instead of a few k.b. it uses 44.5Mb, and 425 files in 26 different folders :( It isn't particularly surprising that such a seemingly inefficient setup seems to produce not-particularly fast/efficient compiled code :(
However, it does work, it is free, and I don't think there is much alternative. If you do find a significant improvement on this, i'll be pleased to hear of it.
#27984 - allenu - Mon Oct 25, 2004 7:41 pm
| Outlaw wrote: |
Hi,
Yeah, I tried that stuff .. Devkit, GCC etc. ... and I didn't get it work; they compiled , but that stuff didn't run on the emulators. Btw. I don't like the installation-overhead ...
|
I recommend trying gcc et al again. I don't know how painful it is to install in Windows, but it can't be all that bad. Besides, you only do it once ever and that's it. You can start building with it. gcc also does not use an IDE. You can use whatever editors you want to build your apps and just call gcc on the command-line. gcc is pretty much standard and used on a variety of platforms, so I don't know if you can get any better than that.
#27985 - sajiimori - Mon Oct 25, 2004 7:46 pm
I don't really understand the problem. Hard drive space is cheap, and if you're having trouble creating a working ROM, blaming the compiler is silly.
Instead of taking the approach of "I know how to do this-and-that, but it's not working for me anyway," why not bite the bullet and follow some of the tutorials?
#27987 - sgeos - Mon Oct 25, 2004 7:58 pm
When I first started coding for the GBA none of my programs worked. I did not know that I had to use objcopy:
| Code: |
gcc -o file.elf file.c
objcopy -v -O binary file.elf file.gba |
-Brendan
#28006 - yaustar - Tue Oct 26, 2004 12:08 am
Is there a direct tutorial to compiling with the devkitarm? I remember trying it out instead of devkitadv and ended up with a rom image but nothing working.
Example Batch File:
| Code: |
path=d:\devkitarm\bin
arm-elf-gcc -mthumb -mthumb-interwork -g -specs=gba.specs -o main.elf main.cpp
arm-elf-objcopy -O binary main.elf main.gba
pause |
_________________
[Blog] [Portfolio]
#28008 - tepples - Tue Oct 26, 2004 12:13 am
| Outlaw wrote: |
| tepples wrote: | | DevkitARM is a C compiler targeting ARM7TDMI, and I didn't find it all that difficult to install. Just unzip, set your path, and start compiling. |
Yeah, I tried that stuff .. Devkit, GCC etc. ... and I didn't get it work; they compiled , but that stuff didn't run on the emulators. Btw. I don't like the installation-overhead ... |
One thing that gets people who switch to devkitARM is that you have to specify -specs=gba.specs when linking or when compiling and linking.
| Quote: |
| tepples wrote: |
it'd take deleting less than a dozen pirated MP3s to make room for it.
|
hm .. ????? |
I was merely remarking that it isn't such a big deal to free up space for such a download. And if you're on dial-up, try downloading while you're reading the forum.
And what is the content of main.cpp ? If you're not sure it's source code for a working program, try compiling this instead to determine what's at fault:
| Code: |
/* begin hw.c */
typedef unsigned short u16;
#define LCDMODE (*(volatile u16 *)0x04000000)
#define LCDMODE_BG2 0x0400
#define VRAM ((u16 *)0x06000000)
#define RGB(r,g,b) ((r)|(g)<<5|(b)<<10)
int main(void)
{
LCDMODE = 3 | LCDMODE_BG2;
VRAM[120+80*240] = RGB( 0,31, 0);
while(1) {}
}
/* end hw.c */
|
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#28010 - Dracula-X - Tue Oct 26, 2004 3:50 am
I'd recommend DevkitARM, it is a relatively small download and it was fairly easy to migrate our project from DevkitAdv. I believe the DevkitARM site (www.devkit.tk) has some example code which you can test your environment with; if they compile and run ok, you should have a decent base to start your own work with.
-DX
#28012 - Gene Ostrowski - Tue Oct 26, 2004 4:27 am
Try the HAMDevKit at http://www.ngine.de/site/index.php.
It was a "one-click" install and most importantly allowed me to create something that actually ran on hardware without mucking with a single makefile, without having to "configure" anything, and without having to weed through (too many) docs just to get something working. My first attempt with DEVKITADV took a couple of days to get working, while the HAMKIT took about 15 minutes. It also comes with many examples, most of which compile and run in both HW and EMU the first time you try them. Good for dissecting to see how things are supposed to be working...
The nice thing is that it comes with some stuff that will make things easier to learn until you become more comfortable with the environment, which is not like programming the PC. Once you understand how things are compiling, linking, working, etc., you can begin to wean yourself off of the kit (sorry emanuel!) and do these things yourself. The point is that the GBA is difficult enough to get a grasp of in the beginning, without having to "fight" the compiler or the environment.
Unless you are extremely comfortable with linker scripts, makefiles, and "Unix" style compiling, you may find the transition easier using HAMKIT.
Hope it helps.
_________________
------------------
Gene Ostrowski
#28055 - keldon - Tue Oct 26, 2004 4:31 pm
yes, I think some may find it offputting having to learn 1000 things in order to achieve a hello world program. It was easier to write a hello world app in windows with a rotating sprite over a paralax-scrolling semi-transparent para-filter in assembler than it was to set up and understand DevKitArm and DevKitAdv.
#28059 - Gene Ostrowski - Tue Oct 26, 2004 4:57 pm
Amen!
_________________
------------------
Gene Ostrowski
#28076 - Outlaw - Tue Oct 26, 2004 7:04 pm
Hi folks,
| keldon wrote: |
| yes, I think some may find it offputting having to learn 1000 things in order to achieve a hello world program. It was easier to write a hello world app in windows with a rotating sprite over a paralax-scrolling semi-transparent para-filter in assembler than it was to set up and understand DevKitArm and DevKitAdv. |
jo, that's exactly what I mean ... and that's why i love assembly and the LCC-Win32 compiler ... just download, copy to the destination directory and start working ... a compiler which needs to be configured in thousands of config files just sucks, and unfortunately this is the most problem of that open source and freeware stuff (yes, I have a lot of cool open source software, just look at Goldroad :-). I want to code and not to beta-test software and write comments to forum how to get it work ...
The only guy who doesn't understand the "minimalist" prinzip seems to be sajiimori .. it's not a question of hardspace; i would install a compiler which takes GB's of space if it would run after installation .. perhaps you understand what I think, if you read the comments of the other guys ...
thanks to all other guys for giving tips ...
I give that products another try ;-)
Greetz
Outlaw
www.yakuza.de.be
#28077 - Outlaw - Tue Oct 26, 2004 7:10 pm
Hi guys,
btw. I like that statement from the HAM Site:
| Quote: |
What is HAM? Why did you write it? When I started out on GBA development, there was little aid. The only way to start development on this precious little machine was by getting some tarballs off a GNU site, compile your cross environment, write your own linker scripts, fiddle endlessly with compiler parameters, and all that before you could even add two numbers together on the Gameboy Advance. If you were not up for this, there was no way to program this neat little machine in C or C++. |
Greetz
Outlaw
www.yakuza.de.be
#28078 - Abscissa - Tue Oct 26, 2004 7:10 pm
| keldon wrote: |
| yes, I think some may find it offputting having to learn 1000 things in order to achieve a hello world program. It was easier to write a hello world app in windows with a rotating sprite over a paralax-scrolling semi-transparent para-filter in assembler than it was to set up and understand DevKitArm and DevKitAdv. |
I'm not sure I totally understand these experiences people have been having. The only trouble I ever had installing and using DevKitARM (DevKitAdv isn't really even relevant anymore) was knowing to use "arm-elf-gcc" instead of "gcc" and to use the "-specs=gba.specs" param. And all of that can be found by just glancing at the sample makefiles.
About what HAM's site says about the purpose of HAM (how it was hard to setup gcc to make GBA apps) hasn't been relevant since the DevKitARM. Unless wintermute can correct me, that was the whole purpose of the DevKitARM, so you didn't have to do all of that GCC patching and recompiling that HAM quote talks about.
#28079 - Outlaw - Tue Oct 26, 2004 7:14 pm
Hi,
| Abscissa wrote: |
| keldon wrote: | | yes, I think some may find it offputting having to learn 1000 things in order to achieve a hello world program. It was easier to write a hello world app in windows with a rotating sprite over a paralax-scrolling semi-transparent para-filter in assembler than it was to set up and understand DevKitArm and DevKitAdv. |
I'm not sure I totally understand these experiences people have been having. The only trouble I ever had installing and using DevKitARM (DevKitAdv isn't really even relevant anymore) was knowing to use "arm-elf-gcc" instead of "gcc" and to use the "-specs=gba.specs" param. And all of that can be found by just glancing at the sample makefiles. |
Yeah, may be, I'm not sure ... but these simple thinks can be quite ugly if you couldn't find it on the websites ....
... IMHO : if I download a "GBA C Ompiler" I can expect, that this software creates Code for GBA without any special parameters or that kind of stuff ...
Greetz
Outlaw
www.yakuza.de.be
#28080 - isildur - Tue Oct 26, 2004 7:25 pm
You can always follow this thread in the forum:
http://forum.gbadev.org/viewtopic.php?t=3991
It gives a great example on using makefiles. Once you set this stuff up, you won't have to bother with it anymore.
#28081 - keldon - Tue Oct 26, 2004 7:28 pm
Well when I downloaded the tutorials from the pern project; it didn't work .. so I tried on of his updated versions (but bear in mind the old ones worked at some point) and they compiled.
Also when I worked with the GB it was straight forward; the tools cannot be matched by what the GBA tools have to offer .. so it's not so seamless and rapid. Maybe it's down to me not knowing the tools enough and how to use them because everyone gets on fine. But I honestly had less trouble going through the ASM code of nessie than I did in getting GCC to compile my code.
#28085 - Gene Ostrowski - Tue Oct 26, 2004 8:56 pm
Abscissa wrote:
| Quote: |
| I'm not sure I totally understand these experiences people have been having. The only trouble I ever had installing and using DevKitARM (DevKitAdv isn't really even relevant anymore) was knowing to use "arm-elf-gcc" instead of "gcc" and to use the "-specs=gba.specs" param. And all of that can be found by just glancing at the sample makefiles. |
You need to realize that many experienced programmers may not know some of these things, and that what seems simple and common knowledge to you may not be to someone else. I've edited your comment:
| Quote: |
| I'm not sure I totally understand these experiences people have been having. The only trouble I ever had installing and using DevKitARM (DevKitAdv isn't really even relevant anymore) was knowing to use "arm-elf-gcc" instead of "gcc" [because of my experience with gcc and the compile chain] and to use the "-specs=gba.specs" param [because I realized it needed it]. And all of that can be found by just glancing at the sample makefiles [if you know how makefiles work]. |
Once the IDE was "invented", I for one spent ten years developing software without ever having to see the inner workings of a makefile or the compile chain. Depending on when you got into development or what systems you worked on, the process can be difficult for many people, even people with a lot of programming experience (esp. Windows) to understand.
_________________
------------------
Gene Ostrowski
#28086 - Abscissa - Tue Oct 26, 2004 9:11 pm
| Gene Ostrowski wrote: |
| You need to realize that many experienced programmers may not know some of these things, and that what seems simple and common knowledge to you may not be to someone else. I've edited your comment: |
That's a good point, you're right about that.
Although since Outlaw was talking about having used Assembly and a command-line assembler rather than an IDE (Goldroad's just command-line, right? Or am I mistaken?) I assumed that he was on the more experienced end. So that's why I was thinking along the lines of more experienced developers. I agree, GCC or something like the DevKits can be intimidating to GCC beginners.
#28088 - isildur - Tue Oct 26, 2004 9:14 pm
Gene, when I started with gba development, I was very used to the Visual Studio suite. I had no idea on how to work with makefiles and gcc. So, I downloaded a couple of gba projects with source code and within an hour, I managed to find out how to use gcc and all. Just a little googling and reading tuts was enough.
At first, I thought it was a hassle but in the end, I learned something. A lot of stuff in gba deving is not easy, so I guess we just have to get used to going through that kind of hassle. Have you tried debugging with gdb? I mean, it's not Visual Studio's debugger.
And if we don't like it, we are always free to create a better compiler with an IDE and all. But it might be an even bigger hassle ;-)
#28091 - poslundc - Tue Oct 26, 2004 9:31 pm
By all means, if quicker, more sophisticated and easier tools exist than the ones we old-timers put up with, then feel free to use them.
Just
don't
complain
when
they
don't
do
what
you
want.
I wouldn't be surprised if the majority of posters in this forum were first exposed to makefiles from GBA programming. I know I was. We learned to use them out of necessity, not because we wanted or cared to.
I think makefiles are crude and unfriendly, and taxing even to experienced programmers. But any competent programmer should be able to go digging into a pre-existing one and work out what it's doing if they have a bug to clobber. I don't get annoyed by people who have trouble doing this, just the ones that throw up their hands and don't try to begin with.
Programming for anything larger than "hello world" is going to be messy. No matter how many tutorials help and guide you on the way, sooner or later you will get stuck with something unexpected and ugly you don't want or shouldn't have to deal with. My unsolicited advice to the rest of the world: learn to deal with it, cuz there's no avoiding it.
Dan.
#28093 - Gene Ostrowski - Tue Oct 26, 2004 9:40 pm
Abscissa:
I started ASM programming back in around '84. Even when I moved to C in '88, I did not move to a "MAKE"-driven C environment-- all my MAKE-sytle tools were hand crafted. Then came IDEs which hid MAKE effectively as well. It wasn't until a few years ago that I had to get in there and muck with them on a personal level, even though I had a dozen years of hardcore programming experience under my belt. I understand the pain associated with toiling over a makefile because I've been there-- they are still somewhat ugly beasts. So, Outlaw could still be on the experienced end, just not necessarily on the makefile-experienced end :)
isildur:
Yes, I come from a VS-heavy background as well. I really like the suite, from all aspects. I've managed to get my build cycle to be almost completely driven from VS, which is great, since I get all the nice features of the package to play with. The only thing I really miss are the "reference library" tools (call graphs, symbol refs, definitions, etc), that I use all the time in my Windows apps. If I could only get the gcc symbol files into the VC database format I'd be in heaven.
Yeah, I've debugged using gdb and find the experience painful at best, especially since my circa '89 Turbo C compiler had a better debugger in it. I usually end up using VBA as my primary debugging tool.
_________________
------------------
Gene Ostrowski
#28099 - keldon - Tue Oct 26, 2004 10:08 pm
It's not simply the Makefiles, the amount of people posting in asking how to include audio etc. Or you get a tool with a binary output so people ask how to include binary. When you have no clue, you can only guess or ask people; and some times the answers can be little more than helpful ( not to say a lot are not helpful ).
Also it does not help with the cryptic messages; and hay-stacks over the needle when you search a website for how to include binary files for example. That's not to say the scene is awful to get into; but when you want to learn to drive you sometimes don't want to know how to do mouth to mouth incase you hit a paedestrian who couldn't keep their eyes on the road; you just want to drift into the horizon right?
In comparison with the GB development scene; GBA development is tedios until you have your working makefiles and tools set up; and even then there are too many broken links on Devrs to compare to Liz Taylor's marriages. And there is no direction to specific toolsets and processes to get a project going ( bearing in mind there are some 100 downloads to pick from when you include all the tools you *could* be using).
#28125 - isildur - Wed Oct 27, 2004 1:57 am
Maybe that's what makes it more rewarding :) But I agree with you that sometimes the responses on this forum can be rude for newbies, and even for experienced devrs...
#28133 - allenu - Wed Oct 27, 2004 4:43 am
| poslundc wrote: |
Programming for anything larger than "hello world" is going to be messy. No matter how many tutorials help and guide you on the way, sooner or later you will get stuck with something unexpected and ugly you don't want or shouldn't have to deal with. My unsolicited advice to the rest of the world: learn to deal with it, cuz there's no avoiding it.
|
I agree.
The thing is people using these tools have to realize is that the devkit tools
are built upon existing toolchains (gcc and the rest of the GNU tools). They
are standard tools, and can be painful to use for newbies, but they weren't
built from for the ground up for GBA development. That said, I think they're
great, but I like unix-based tools. I think it's kind of silly to put down things
like Makefiles. They've been around a while and they work.
#28151 - keldon - Wed Oct 27, 2004 2:13 pm
I never complain that my friends mum can't cook; he doesn't even notice himself. All he knows is that it fills him up, and so what if he throws up half of the time.
But whenever I ask him how to stomach it, he looks at me like I'm an alien and expects the whole world to like frozen peas dipped in gravy. I'm not complaining here though, but maybe if his mum could cook, I could eat it much easier.
=D
#28171 - Outlaw - Wed Oct 27, 2004 5:15 pm
Hi folks,
interesting discussion :-) ... yeah, I don't like Make-Files and compiler-configuration and it was never necessary for me to use them 'cause I used to code with Pascal and Assembly ... now I switched to C ( the only reason was the TinyPTC-Library (framebuffer library) for Using DirectX without knowing DirectX in detail), and I like it as language ...
Then I was looking for C Compilers (to write intros and that stuff in Win32) that were such simple to use like my (Free)Pascal or Fasm ... I tested GCC and it was just pain (even to install), I test VC, and I didn't like it 'cause using it for my needs is just like killing a fly using a Bazooka ... as I mentioned before: my needs are fullfilled when I create the Hello-World-Example, give it via command line to the compiler and I get - "Compiled & Linked successfully" and it runs ... simple test - but effective. The only compiler that passed this test was LCC-Win32 (great stuff).
This doesn't mean that I have no idea of software and coding, it's a hobby for me for 15 years ... but in former DOS times there were great tools like Turbo C or Turbo Pascal ... I "grew up" with these great compilers and do not understand why a lot of up-to-date stuff isn't such user friendly as these software was.
Yes, a lot of freeware stuff comes from the linux szene - they do a great job, no question ! - but these guys often think using and understanding "vi" (or GCC :-) is how "computer expert" is defined. It's an attitude that can be found in their software-development like a red-line.... (the second problem is, that a lot of coders are not experienced (or willing) in writing understandable manuals for their software. An example (or thousands) is no replacement for good manuals or logical, self-explaining software...)
Okay , I guess it's enough to explain my point of view ... :-)
Greetz
Outlaw
www.yakuza.de.be
#28173 - allenu - Wed Oct 27, 2004 5:43 pm
| Outlaw wrote: |
Yes, a lot of freeware stuff comes from the linux szene - they do a great job, no question ! - but these guys often think using and understanding "vi" (or GCC :-) is how "computer expert" is defined. It's an attitude that can be found in their software-development like a red-line.... (the second problem is, that a lot of coders are not experienced (or willing) in writing understandable manuals for their software. An example (or thousands) is no replacement for good manuals or logical, self-explaining software...)
|
Well, I guess it comes down to differing philosophies. For people who
have struggled with unix-like tools and eventually got used to them and
realize their power, it's tough to go back.
Speaking for myself, I used to program in DOS as well. It's how I got into
programming. I used MASM and Turbo C/C++ and the like. However,
I later started using DJGPP (gcc for DOS) and after the initial pain, used
it more frequently, and then Makefiles as well. So I agree it is a pain
initially to move to it, but I think in the long run, it's well worth it. Sure,
it's not as user-friendly, but I guess the attitude is that if you use it
enough, you "understand" why it works the way it does. For people
who've grown accustomed to the quirks and realize it gets the job done
very well, it doesn't matter as much that it's not as easy to learn as
other tools on other platforms.
Additionally, I use Emacs for text editing now versus Notepad or anything
else. It's got to be the most unfriendly editing tool (other than vi) on the
planet, but once you get used to it, it's amazingly powerful.
#28180 - keldon - Wed Oct 27, 2004 6:03 pm
I used turbo C++ aswell; amazing package. But I also used to try out my ASM code in Debug =D Sometimes when you get something working on Linux that took you long you feel relieved, but sometimes I like to DO something rather than MAKE something :)
GCC is pretty good with what it does with makefiles. But I really do get put off with source downloads when you have to check for dependancies. Because you only find out after you've done configure (or the other command), and my linux does not have Internet; so imagine the fustration.
It sucks more when you're trying to compile a modem driver and it gives you a cryptic response saying, "you can no longer do this in this version of linux; if you are a developer rewrite your kernel-header include file." And most packages don't tell you how to check for the version of a package you have (which some do).
If everything came in a package that worked first time, it would all be good. I might try ham;
#28184 - allenu - Wed Oct 27, 2004 6:15 pm
| keldon wrote: |
It sucks more when you're trying to compile a modem driver and it gives you a cryptic response saying, "you can no longer do this in this version of linux; if you are a developer rewrite your kernel-header include file." And most packages don't tell you how to check for the version of a package you have (which some do).
|
Yeah, linux can be a pain to set up, but it's definitely rewarding when
you get it working. And you learn something along the way.
The funny thing for me was that I used to use Mandrake Linux and use
Red Hat's RPM system. But I got tired of all the dependency issues,
so I moved to Slackware instead. Now I just download the sources
to things and build it and most of the time it just builds and works!
However, there are odd times when the build fails and I'm not keen
on figuring out why, so I just scrap whatever app it is I'm trying to
build. For development, though, I just love using Linux. I have
a bunch of terminal windows open to different directories and with
Emacs, it's just so much quicker for me to build things than to use
Windows.
Allen
#28186 - keldon - Wed Oct 27, 2004 6:28 pm
That's the thing; linux when working is a killer OS. But it's default settings for most distributions pretty much suck ?!? Also an entire OS is thrown at you so you have no idea where you should look for this and that. And I too usually scrap the tool if it's too much to install, although I do give it a good try first =D
#28191 - Outlaw - Wed Oct 27, 2004 7:07 pm
Hi guys,
I'll try HAM ... but I am a little bit confused: when I open the download page of the home page, I see different versions from 2.50 to 2.80 ..
Only version 2.50 is called "freeware" ... I can not see if HAM 2.80 is a free version too or has to be registered ... ?!?!
(Does it make any difference if I use HAM 2.50 or HAM 2.80 ?)
Greetz
Outlaw
www.yakuza.de.be
#28209 - Abscissa - Wed Oct 27, 2004 8:15 pm
| Outlaw wrote: |
yeah, I don't like Make-Files
I test VC, and I didn't like it 'cause using it for my needs is just like killing a fly using a Bazooka ... as I mentioned before: my needs are fullfilled when I create the Hello-World-Example, give it via command line to the compiler and I get - "Compiled & Linked successfully" and it runs ... simple test - but effective. The only compiler that passed this test was LCC-Win32 (great stuff). |
You know, I've gotten fairly familiar with makefiles, and they still drive me nuts ;)
About a simple-to-use command line compiler: after thinking about it, it dosn't seem like it would be all that difficult to create a command-line-based front-end to DevKitARM that would simplify everything. What does everyone else think?
#28211 - poslundc - Wed Oct 27, 2004 8:29 pm
| Abscissa wrote: |
| About a simple-to-use command line compiler: after thinking about it, it dosn't seem like it would be all that difficult to create a command-line-based front-end to DevKitARM that would simplify everything. What does everyone else think? |
I think that's probably how "make" got started. ;)
Dan.
#28212 - keldon - Wed Oct 27, 2004 8:34 pm
Using make was not much of a problem; it's the problem with specific keys and the millions of them. And sometimes their compatability changes (just try pern project Day 1_1).
Just looking at posts, I can't count the amount of people asking how to link; and it's difficult to know what tools to pick - - I think that's the difficulties people mostly have.
I do think the problems people have need to be examined. I most certainly would prefer people to be developing on the GBA than for the PC; we have a better community and gamers do actually play our games =D
#28214 - allenu - Wed Oct 27, 2004 8:43 pm
| keldon wrote: |
I do think the problems people have need to be examined. I most certainly would prefer people to be developing on the GBA than for the PC; we have a better community and gamers do actually play our games =D |
Maybe somebody should start a GBA-development Wiki? It would contain links, documents, and tutorials on various subjects like the toolchains, programming languages, development tools and so on.
My only gripe with learning GBA development was faulty header files. A lot of times, the defined macros were just plain wrong. That was really annoying.
#29186 - greenllll - Sat Nov 13, 2004 5:53 am
To a noob like me, this info is quite frightening! I admire those who can program the GBA. You guys rock.
#29209 - tepples - Sat Nov 13, 2004 9:10 pm
You mean a Wiki like the one the NES community set up? Except I'd suggest using MediaWiki instead of 'Tavi.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#29210 - allenu - Sat Nov 13, 2004 9:19 pm
Yes, something like that would be great. Actually, I think it would be more useful for the Nintendo DS once it's released. It would help with the gathering of info to hack the device.
#29213 - tepples - Sat Nov 13, 2004 9:37 pm
| allenu wrote: |
| I think [a wiki] would be more useful for the Nintendo DS once it's released. |
Here's your DS wiki. Have fun!
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#29214 - allenu - Sun Nov 14, 2004 12:56 am
Wow, that's awesome. Thanks for the link.
#29273 - SmileyDude - Mon Nov 15, 2004 8:10 pm
i realize that different people work differently, but what I've always liked about the Unix way is that once you learn it, it works pretty much anywhere.
Makefiles -- originally Unix, now I use them to build for Unix, Linux, MacOS X, Windows, and the GBA. And they pretty much work the same anywhere I go...
command line -- ditto. With things like Cygwin, even the Windows guys can get into the act.
vim/emacs -- personally, I don't use emacs, but I do use vim everywhere, and again, it works the same where ever i happen to be. I don't have to go hunting around for an editor that's "like" the editor I was used to on another platform. the one that I am used to is already there!
btw, regarding makefiles -- i've written one makefile for GBA programming. One. If you write it generically enough (and if you can't, there are others who would be willing to help you), you don't need to write any more... just copy the makefile into your project directory, and go.
I would much rather have a mostly generic makefile as opposed to a collection of bash or DOS scripts that have to be tailored for each project and that aren't cross platform.
Just something to think about...
_________________
dennis
#29426 - pyros - Fri Nov 19, 2004 10:38 pm
I have been using DevKitADV. Today I upgraded to DevKitARM (a version released in 2004, rather than 2001).
After some experimenting I eventually managed to get make.bat that actually works, AND uses -O2 (-O3 is giving me a hanging blank screen and an eventual error message).
Now, my program is running like lightening! It is MUCH faster. I was going to make a huge (very sexy, algorithmic) optimisation to make it run at a decent speed. However, this is now unnecessary. And I feel either cheated, or as though I am cheating :/
#29427 - sajiimori - Fri Nov 19, 2004 11:02 pm
Ok I'm sorry but the words "sexy" and "algorithmic" just don't go together.
-vocab police
#29429 - tepples - Fri Nov 19, 2004 11:12 pm
| pyros wrote: |
I have been using DevKitADV. Today I upgraded to DevKitARM (a version released in 2004, rather than 2001).
[...]
Now, my program is running like lightening! It is MUCH faster. I was going to make a huge (very sexy, algorithmic) optimisation to make it run at a decent speed. |
Perhaps the new GCC detected your inefficient algorithm and strength-reduced it. But if not, do the hand-optimization anyway if it helps, as each optimization means the code will get to the IntrWait() call sooner, saving batteries.
sajiimori: Replace "sexy" with "clever" if it bothers you.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#29430 - sajiimori - Fri Nov 19, 2004 11:20 pm
It was a joke.
#29433 - pyros - Fri Nov 19, 2004 11:58 pm
| tepples wrote: |
| Perhaps the new GCC detected your inefficient algorithm and strength-reduced it. But if not, do the hand-optimization anyway if it helps, as each optimization means the code will get to the IntrWait() call sooner, saving batteries. |
I'm 99% certain GCC didn't detect it. Basically it involved doing a big memory write (an entire 1024x1024 tilemap), event-triggered approximately every 100 frames, rather than writing portions (approx. 1/4) of two 512x512 tile-maps every single frame.
(this actually is more sexy than it may sound; on the event, less is done, so there is more time for the big write, and the big write can be better optimised and written in inline assembler)
The thing that surprised me a lot is that I had already severly optimised the loops in my code, so i didn't expect so much immediately visible improvement.