gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Almost there with MultiBoot!

#25517 - Krakken - Tue Aug 24, 2004 9:47 am

Hi,

For some very strange reason, which I can't yet pinpoint, my multiboot sender ROM is not completing the transfer of data to the slave GBA. Everything seems absolutely fine up until it would normally be executed where it just freezes (the Nintendo logo stops flashing).

It works on no$gba when I take the v-blank wait from inside the send routine (although the ROM prints all the send-recieve to the screen and there doesn't seem to be any difference regardless). It tries to execute too quickly on the GBA so it needs the vblank wait.

The ROM is aligned to 10h bytes (by extending the length by x bytes). Originally I thought it may have been an alignment problem at the start but it all seems fine. The start starts at ROM + 0xC0 and ends at ROM + 0xC0 + Length.

I have tested everything and everything seems okay. I just don't understand why it won't work with a vblank wait in the transfer routine seeing as the transfer routine still seems to execute as it should.

It's the same on hardware. Anyone have any ideas?

Thanks,
Krakken.

#25520 - Krakken - Tue Aug 24, 2004 12:05 pm

Haha I got it. It was a silly mistake on my behalf. I was setting the client code AFTER sending the handshake by mistake. This didn't matter when it went fast as the "junk" data sent after the handshake seemed to be the same as the client code but different when a delay was there. (Maybe BIOS didn't have time to set a new value?)

Anyways, now I have this working I can work on some more multiplayer stuff.

#25546 - ProblemBaby - Tue Aug 24, 2004 9:15 pm

Do you want to help me??
Ive tried to do multiboot code but never got it to work in no$gba and on hardware only at hardware with the example from www.devrs.com.
Ive no idea of what iam doing wrong iam doing exaclty as it stand in the gba spec. and recieve correct data. but when I try to run the BIOS-routine i got ROM-image crashed.

Do you have any ideas?

#25557 - Krakken - Wed Aug 25, 2004 1:39 am

Yup this stumped me for a while. There are two reasons it is doing that.

Firstly: The ROM image that is provided does not seem to be a valid one. Don't ask me why maybe something went wrong somewhere along the lines. Just use b2o or b2x to convert any MULTIBOOT rom to a file that you can include and use. (If you use b2x change the array so it has const at the beginning or it'll go in IWRAM).

Secondly: I found that I had to download my GBA BIOS to a file so that the emulator would start like a real emulator. You need to call this no$gba.rom or gba.rom and place it in the same folder as your no$gba executable. Then you need to tell the options to use it. (I'm not 100% sure this step is required but i'd recommend it anyway if you are using ANY of the BIOS routines).

That "should" solve your problems. If you have any other questions i'll be happy to help.

#25586 - ProblemBaby - Wed Aug 25, 2004 3:10 pm

It was a problem with the ROM! so now it works in no$gba but not in hardware=/ any ideas?
except for that, Thanks a lot for the information.
I want to ask two other questions that I don't really understand...

1.
In the demo att devrs he sets a variable named pc: pc = 0xD1
what is that it isnt mentioned in the GBA spec. is it important to have it to make it work??

2.
the palette data I dont understand how it is calculated or what it is...
they talk about: direction, speed and color???? but seems to work even if I change it (in no$gba)

#25587 - Krakken - Wed Aug 25, 2004 4:19 pm

1.
The "pc" variable isn't needed. it makes no difference if you use it or not. I think it might be something to do with debug. Also, the header that is provided in that example is a bit of an overkill. You can just use char arrays for the reserved bytes, you don't need seperate variables when reserved bytes are next to each other.

2.
Basically, the values you give the palette variable determines how the palette will display when the ROM image is loading on the slave GBA units. There are 7 colours, 4 speeds and 2 directions that can be used. I haven't actually tested the direction variable yet but I think it's to do with how the colour table is sorted. Each of the colours 0 through 6 represents a different colour on the table. 0 = Pink, 1 = Blue, 2 = Light Blue, 3 = Green and so on (I think that's right). If you want the colour to stay the same while the ROM loads use "0xF1 + COLOUR * 2" if you want the palette to change during load use "0x81 + COLOUR * 0x10 + DIRECTION * 8 + SPEED * 2". I haven't actually tested direction but to get a nice FAST flashing of blue use "0x81 + 1 * 0x10 + 0 * 8 + 3 * 2" --> "0x81 + 0x10 + 0 + 6" --> "0x97"

Hope this answers your questions.

#25592 - ProblemBaby - Wed Aug 25, 2004 7:07 pm

Yes that was nice to know!
anyway I cant get it to work in real hardware...
(notice that this works in no$gba)
I recieve correct values from the hardware (I think)
and Ihave response after all I send and after the BIOS-function I recieve
1 from the BIOS function that means that something goes wrong.
can it be something wrong in what I send or is it probably something wrong with the MB-structure?

#25604 - ProblemBaby - Wed Aug 25, 2004 10:22 pm

I fixed it=)
I really dont know what I did but now it works!=)