#5696 - slip - Tue May 06, 2003 11:20 am
I did a couple of searches but I didn't find any topics that have covered this. Forgive me if there has been.
I'd like to implement a MarioKart type Multiplayer mode where only one cartridge is needed, but I'm not sure how.
I've read the GBATEK specs over and over and over... and from what I gather I have to use UART mode to send the data. is this correct? if it is, I'm happy with setting the REG_SCCNT_L register, but I'm not sure where and when I have to put the data to be sent.
EDIT: And what specific data should be sent? and what causes the slave GBA to boot once data has been sent? Is the data sent supposed to be just a ROM image?
Can anyone help me?
thanks in advance
slip
#5706 - Your_Apprentice - Tue May 06, 2003 3:02 pm
I can say Hi!!
I hope someone helps you out, it sucks when you need it and even when people know, they don't bother to tell you :)
Good luck!! And keep being nice to people even when they don't reply ;)
See ya!
_________________
I'm learning, leave me alone for a few hundred years and I'll get back to you... :P
#5707 - slip - Tue May 06, 2003 3:07 pm
lol... thanks mate.... yeah I've been wondering about this for a while. I only have one cart and it makes it difficult without income to get another... this is a topic I have had little success with finding information. When I gather enough information I'd like to put together my own set of tutorials that range between beginner and advance, on my website. www.ice-d.tk
time for bed now anyway
slip...
#5708 - niltsair - Tue May 06, 2003 3:15 pm
Would seem the term 'mate' is typically an Aussie term, i had a friend who went there 2 years ago, and started using it :-)
AS fro your problem, i never programmed using the communication port, but one obvious thing you have to be aware of, is that the program you want to uplink must be under 256k, which kinda limit things a tad.
Like i said, i never used it, so i dunno how feasible it would be to upload some data dynamicly to compensate for the little amount of space.
#5719 - jenswa - Tue May 06, 2003 9:22 pm
There is a website with two tutorials about the link-port and multiboot.
I only forgot it's adress, but it's not hard to find and there is a little
more info about the multiboot online, if you search for a little.
So you the main rom, then 2 - 4* gba's, which are slave 2 - 4, the gba
with the main rom is the master (slave 1).
You need a send rountine from slave 1, then make sure slave 2 -4 are in multiboot mode, so that they can receive a multiboot image
(a copy of your rom) in their 256k (oh yeah make it a little smaller).
All gba's have 4 registers in which the date from the other (linked) gba's
are stored, but i don't know exactly how they work,
so i can't help you any further.
i don't know the code for all this so don't ask me,
i am also trying to figure this out.
* 2 - 4, depends on how much gba's you want to use,
for the easy way, try with two gba's
_________________
It seems this wasn't lost after all.
#5723 - darkcloud - Wed May 07, 2003 12:04 am
| jenswa wrote: |
There is a website with two tutorials about the link-port and multiboot.
|
Down To You
_________________
Maybe in order to understand mankind, we have to look at the word itself: "Mankind". Basically, it's made up of two separate words - "mank" and "ind". What do these words mean ? It's a mystery, and that's why so is mankind.
#5724 - slip - Wed May 07, 2003 1:07 am
Thanks darkcloud, I just finished making the ROM with a multiboot image. I have to wait another 7 hours before I can test it...
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5736 - Your_Apprentice - Wed May 07, 2003 11:17 am
:) Glad you got the info you wanted
Keep up the good work :P
_________________
I'm learning, leave me alone for a few hundred years and I'll get back to you... :P
#5751 - slip - Thu May 08, 2003 1:31 am
I read the tutorials on multibooting and creating a multiboot image. apparently I have to include these these lines of code at the start of my program. I put this at the start of main.cpp
#define MULTIBOOT volatile const u8 __gba_multiboot;
MULTIBOOT
but I get an error because of MULTIBOOT, I commented this out and it compiled fine. The .mb file, when trying on VBA all I got was a white screen, and after connecting two GBA's together and transfering the data over I get the same result.... My guess is the transfering of the ROM is working fine, its just the actual mb ROM isn't correct.
any ideas?
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5764 - tepples - Thu May 08, 2003 6:54 am
| slip wrote: |
#define MULTIBOOT volatile const u8 __gba_multiboot;
MULTIBOOT
but I get an error because of MULTIBOOT, I commented this out |
Then don't comment it out. Your .mb program failed because you commented it out. What specific error did you get?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#5767 - slip - Thu May 08, 2003 8:09 am
//sytax error before ';' token
//refering to the MULTIBOOT line.
EDIT:
Ok my bad.. I had the code in the wrong spot. I've put it after #include "gba.h" now but I get an
uninitialized const '__gba_multiboot'
Can someone explain to me what the
#define MULTIBOOT volatile const u8 __gba_multiboot;
MULTIBOOT
lines are actually doing? I don't quite understand whats going on.
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5773 - torne - Thu May 08, 2003 1:09 pm
This is the most misleading thing I've found about GBA development so far. =)
All that defining that variable does is, well, define the variable. The linker script, however, has magic in it. If there is a symbol (any variable or function) with the name __gba_multiboot present anywhere in the program, then the linker makes a multiboot image. If there isn't, it doesn't.
Any code which creates that symbol will do:
| Code: |
| volatile const u8 __gba_multiboot = 1; |
will work. The error you have is just because the constant isn't being initialised. This technically 'wastes' a byte of ROM, since it declares a variable, but one byte isn't much of a problem. In asm you can declare the symbol directly, thus using no space at all.
I'm not sure why volatile is included in the declaration, the only thing that comes to mind is preventing the optimiser from deleting the variable due to it not being used; but if that's the reason then it's misguided, as the optimiser will never do that. =)
Hope that helps,
Torne
#5775 - slip - Thu May 08, 2003 2:21 pm
Ok I understand now..... But I still have a problem. I can compile without any errors now. I initalized it to 1. But I still get a blank screen from the sent ROM. any thoughts as to why?
I'm going to write a small test ROM to test. I'll let you know.
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5780 - slip - Thu May 08, 2003 2:47 pm
All is good in wonderland.
I decided to take out const.... and it worked.
Go figure I guess....
Thanks for helping me out guys!
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5781 - torne - Thu May 08, 2003 3:54 pm
Taking out const will allocate the variable in RAM, which means you lose *gasp* one byte of RAM. If that's ok, then, well, go for it. =)
I don't know any way to make a multiboot rom in C without using a byte of rom/ram - it's trivial in asm, tho =)
T
#5792 - tepples - Thu May 08, 2003 6:28 pm
| torne wrote: |
| This technically 'wastes' a byte of ROM |
Jason Wilkins, maintainer of Devkit Advance, told me that Devkit Advance R5 will have a section devoted to these linker configuration pseudo-variables, which will not take up space in the finished ROM or RAM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#5794 - torne - Thu May 08, 2003 6:36 pm
That would work. From asm it's no problem, though; just declare a symbol and set the value of it to one, or something. That becomes just an entry in the elf binary, and is removed when you use objcopy =)
T.
#5819 - slip - Fri May 09, 2003 1:06 am
Right now one byte isn't a problem =P.... I'll look into why I can't use const if it becomes a problem. Thanks again.
_________________
[url="http://www.ice-d.com"]www.ice-d.com[/url]
#5844 - Maverick - Fri May 09, 2003 9:33 pm
The declaration line does not actually have to be
| Code: |
volatile u8 const MULTIBOOT
|
it can just be simply
This does not matter, what does matter however on the startup is the ram address wich must be changed from the default value of
0x08000000
to
0x02000000
This is simply so that it can boot from IWRAM rather than cart ROM
Hope this helps!
Maverick
#5916 - Jason Wilkins - Mon May 12, 2003 7:47 pm
| Quote: |
| I'm not sure why volatile is included in the declaration, the only thing that comes to mind is preventing the optimiser from deleting the variable due to it not being used; but if that's the reason then it's misguided, as the optimiser will never do that. =) |
I guess I'm the one who is misguided, preventing the optimizer from eliminating it was exactly what I was thinking. I came up with the idea for __gba_multiboot and the link script magic. The only thing I regret is that I included a semicolon in the macro. It would be better if the macro was used like:
Otherwise, it can confuse project browsers which might think it is part of the type of the following declaration.
To prevent confusion, the library I will include with the final DevKit Advance R5 will contain a completely new set of macros to replace MULTIBOOT, IN_IWRAM, and IN_EWRAM.
In DevKit Advance R5, you can declare a variable like this and it will not take up any space in your rom and if your code references it, it will have the address 0:
| Code: |
__attribute__ ((section(".devkitadv.config"))) int __gba_multiboot = 1;
|
Anything in a .devkitadv.* section will be discarded from the final image.
I'll provide those new macros in the next release. So be prepared to change your code if you use this between now and then. I would prefer that people use the macros in the header file I will provide with DKA, because it gives me more freedom to fix bad ideas in the future ^_^
lnkscript R5 contains new magic as well. __gba_ewram_data will change the default location of variables from iwram to ewram.
_________________
http://devkitadv.sourceforge.net
#5933 - torne - Tue May 13, 2003 12:18 pm
The compiler can never, ever optimise away a nonstatic variable declared at file scope, because it is impossible to prove that it isn't used. You can't tell for sure even at the final binary link as it may be used by a dynamically linked library. =)
Thanks in advance for the config section stuff; it's a good idea. *grin*
T