#116769 - Slainte - Mon Jan 29, 2007 8:28 am
Hi there, it's been a while since i joined to the GBA coding world, but it's not been since some weeks ago I really had my hands into the "big" thing...
Anyway my gcc background has not been involved to much with LD fine tunning so I thought maybe someone here could help with this:
I want to get rid of the gcc CRTs, that is... I want to have my own CRT instead of gba_crt0 (and possibly the common crt0)
As far I could determine I'll be needing a new ld script and define my own section scheme, entry-point and all... (and in fact getting rid of gba_crt0 seems quite easy and obvious) but my doubts lie within removing crt0 (wich in first place is not so obvius is already there and what the hell it does though i'd aim for the debug mapped symbols in the map export from the linker :P)
Any docs or insight on the subject would really help as my aim is to provide my own game engine runtime in place of this one and allow for pseudo-filesystem (something in the line of gbafs) allowing the following scheme:
You have the common runtime (basically a bytecode loader & interpreter)
you have your game code in a totally external language
you compile your game code as bytecode and pack the needed files in place with the codeblock (Bytecode+padding+virtual_FileSystem)
you "build" your *.gba cart file appending the runtime and the codepack and fix the header so you can use it in a flash cart (maybe an mb mode would be in there but I have not yet approached that point)
All the process should work fully without gcc being involved once you have the runtime.
The final goal is porting an stablished indie 2d game engine currently quite popular in PC/Mac/BeOS/GP32/GPX2/Dreamcast as a lite flavour to GBA and allow for some kind of multiplatform capacity to it
#116775 - keldon - Mon Jan 29, 2007 11:22 am
You don't need to edit CRT to do this. All you need to do is have your program look for an entry file in the file system!
#116814 - Slainte - Mon Jan 29, 2007 11:25 pm
hmmm, maybe i got it all wrong but i really thought gba carts did not have a file system... (as having one would really nullify things like GBAFS)
#116815 - tepples - Mon Jan 29, 2007 11:33 pm
GBA Game Paks do not have a file system. Flash carts containing multiple games do, where the loader interprets the file system and sets up the bankswitching hardware, but the layout and access methods vary per make and model of flash cart.
Is it that you want to allow the user to compile code and store it in a GBFS file, and then load and run it? Perhaps what you really want is Lua.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116816 - Slainte - Mon Jan 29, 2007 11:43 pm
I know of Lua... maybe you know of Fenix... I am currently one of the project owners for Fenix project. It is a 2d Rich media oriented interpreted language based on protable Lil' endian bytecode files with also protable raw/gz resource files.
I am experimenting with a lite version of the interpreter for gba and maybe for DS later in the year. The real aim is producing bootable cart files (i.e. suitable for commercial/indy distribution) without real gba coding involved. Ppl can develop their game on PC and test it with current PC version (PC/Mac/BeOS) and then with a simple tool move them into the gba. Currently there is a very popular GP32/GPX2 version maintained by Chui (SDL for GP) and it has proven a widely and easy to use coding solution there.
Getting rid of the common runtime is more a space & resource optimization than anything else... Changing the crt from the current ram dumping on boot aoutoloader to some loader that gets fenix runtime and loads it in place, gets the entry point for the bytecode and resources package and fires the interpreter main loop... major drawbacks lie on what the common crt is really doing (apart from debugging hooks)
#116817 - tepples - Mon Jan 29, 2007 11:51 pm
| Slainte wrote: |
| Getting rid of the common runtime is more a space & resource optimization than anything else... Changing the crt from the current ram dumping on boot aoutoloader to some loader that gets fenix runtime and loads it in place, gets the entry point for the bytecode and resources package and fires the interpreter main loop... major drawbacks lie on what the common crt is really doing |
The GBA's crt0 does very little that would justify combing through it byte by byte. Mostly it just clears BSS and copies the EWRAM and IWRAM segments from ROM into RAM. The minimal GBA program that I gave in this post, using the default crt0 of devkitARM, produces a 900 byte .gba file.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116819 - Slainte - Tue Jan 30, 2007 12:04 am
yes... in fact it is a very small code, but it is somewhat useless to me right now and i'd prefer to have it reused for bytecode detection in the rom or something... also my gcc skills are a bit rusty :P and tampering with sections is killing me
#116821 - sajiimori - Tue Jan 30, 2007 12:20 am
If wasting a few hundred bytes of ROM is a problem, you'd better write your whole project in assembler. Even if you write just a few routines in C, you'll likely end up wasting thousands of bytes!
#116824 - chishm - Tue Jan 30, 2007 12:54 am
If I understand you right, you want a simple binary that you can append a bytecode file to and have that run on the GBA. In this case, the binary will be an interpreter most likely written in a HLL (probably C or C++).
The code generated by the compiler expects the system to be set up in a particular way, which the crt0 takes care of. You need the crt0, it's saving you the trouble of setting up your globals, clearing memory, setting up the stack, and a few more things.
If you don't think you need the crt0, then you also should be using ASM to code the entire thing, in which case the startup function will perform a similar function to the crt0.
If you don't care to take this advice, then look into -nostartfiles.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#116852 - Slainte - Tue Jan 30, 2007 7:49 am
Thnx for the info...
Let's see... basically it is as you stated an interpreter but I'd really stick to mostly ASM... interpreting is by far slower than direct execution, add also poorly coded user programs and not too well selected resources... Add to the pack common text fonts, common palettes (just in case the user is not initializing any of those things and wants to use them...) The runtime and base resources it really needs can take quite a load of bits. Coding it all in ASM is an approach (but i need to increase my ARM/THUMB asm fluency :( prior to that) so for now it will be mostly a heavy mix.
My idea was to change gba_crt0 by my own loader that would basically put the interpreter in place, start the virtual machine stack, find the entry point for the virtual filesystem, init the base palette and text system and start a basic graphics mode (that can lately be changed... but you wouldn't really believe the big load of ppl directly sending things to screen before even thinking on initializing it...)
The end language (the interpreted one) is really high high level, derived from a mixture on Pascal, C and Basic... with a pseudo OOP scheme based on graphic processes.
I will tamper a bit with it all and see what it comes from it... thnx for the info so far
#116857 - keldon - Tue Jan 30, 2007 10:26 am
Maybe try to avoid a specific language and interpret your own custom byte code and have whatever language you use compile to it. That way you have free reign over the language.
And no matter what happens after, is there really much need to change your crt file? It isn't going to affect your performance after all! And writing in assembler isn't always the solution that leads to faster execution; compare the speed of the Nessie NES emulator (written completely in ASM) to the Nesticle emulator (written in C)!!! As a note Nesticle runs on a 66Mhz 486, Nessie [I am sure] requires far more!
#116873 - tepples - Tue Jan 30, 2007 4:37 pm
Nesticle runs fast because it uses only a first-order approximation to the behavior of the NES. It takes four lines of 6502 assembly language for a program to distinguish the NES environment from the Nesticle environment.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#116919 - keldon - Wed Jan 31, 2007 12:15 am
First order approximation for what? And I know that you can easily detirmine whether you are in Nesticle but I have to wonder what extra functionality forces Nessie to be slower that much slower. I have looked at its source and see nothing out of the ordinary; but you have to ask yourself what justifies/explains the difference in speed.
#116922 - gmiller - Wed Jan 31, 2007 12:22 am
It appears from the comments on the web posting about the emulation that it is not the speed but the accuracy of the emulation that is in question. Bad blank emulation ...
VBA has the same problem with interrupts with button input ....
#116926 - keldon - Wed Jan 31, 2007 1:43 am
| gmiller wrote: |
It appears from the comments on the web posting about the emulation that it is not the speed but the accuracy of the emulation that is in question. Bad blank emulation ...
VBA has the same problem with interrupts with button input .... |
Both are discussed here. Nesticle written in c and Nessie written in asm. The accuracy of Nessie is supposed to be the reason for its reduced speed in comparison with Nesticle; but they are both still emulating a system not far from the DMG!
#116927 - tepples - Wed Jan 31, 2007 2:07 am
Yes, the NES is far from the DMG (original Game Boy). Game Boy doesn't have mappers that can bankswitch tile data in response to the raster (MMC2) or generate interrupts in response to the VRAM read address (MMC3, MMC5). In fact, Game Boy can't even bankswitch tile data at all. In addition, raster effects are simpler to handle on Game Boy due to its VCOUNT interrupt, so fewer games need to rely on timed code like they do on NES.
All this accuracy is necessary for NES titles such as Battletoads, where the refresh daemon contains cycle-timed code such that running one cycle too long or too short can cause the game to crash. And accuracy takes time.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.