[Graphics] Bitmap mode problem

[Bonnox]

Good morning people, I?m sadly asking for help due to a rather strange problem that occurs during GBA programming.
The problem relates to the bitmap mode.
First, I follow this guide: http://www.coranac.com/tonc/text/first.htm
This document explains how to compile a simple first program. And that worked well.
The problem is that, if I use the main function alone, compiled with the simple command arm-none-eabi-gcc mthumb mthumb-interwork and then call the injected binary with a callasm, the bitmap mode is not correctly working. The pixels are still at the right place, but appears a black band at the left edge of the screen, whith the effect of shifting the entire canvas to the right. However, if I open the map editor tool, the image is well formed in the emolator?s memory, just shifted.
I thought it was fault of the BG OFS registers, but sadly, after setting them to zero, nothing changed. I don't reckon the map scrolling functions to be the culpript, because after the call, my code is taking all the machine resources, therefore no game freak code is executing.
I?m not that interested in bitmap mode, but who knows, and if it worked straight would be great. Also because this is driving me insane, I would like to know where?s the problem.

Could you please point me in the right direction? thanks

 

[Blah]

Did you clear the vblank callback and Hblank callbacks in the superstate? As well as the c1, and c2 callbacks? These are called as part of the main loop, and need to be set accordingly.

 

[Bonnox]

Did you clear the vblank callback and Hblank callbacks in the superstate?

Well, this is interesting. I don't think to have done it. By "callback" do you mean "interrupt" ? And sorry for annoying you again, what is the superstate? the tiny piece of memory at the end of memory 3 which holds the interrupt vector maybe?

Oh, I just used the brain and maybe have discovered what could be (but did't want to clear the line for recording purposes), is it The register for interrupts at address 0x04000200??? Yeah it's a rather stupid question, but it's late I'm tired sorry.

Now, on much more noble topics... What does the game do at the VBLANK? Synchronization things? Buffering jobs?
I'm using ruby, at the moment, if it helps.

As well as the c1, and c2 callbacks? These are called as part of the main loop, and need to be set accordingly.

No, I thought that calling my code would have gained all the resources (apart from the timer interrupt needed for sound (and needed by me to conveniently not have to implement something so difficult)).
This callback topic is still obscure to me. I mean, I know in theory what they are and all this kind of things, but when it's time to explore them in the ROM (for whathever piece of the game, be it the Fight screen, the contest screen, the pokenav and so on) I miserably fail. Do you know a good guide for undertanding the callbacks, in particular those in the ROM?

anyway, give me some days to set up the environment again (damned compilers, they are distributed in installers, and assume you would not reinstall the OS, or have only one production machine, so they put several useless environment variables. And not to mention IDEs which uses stupid folders like appdata for configuration) and I will report back.


Soo, the business here is to disable the interrupts, right?

However it's strange, how could them interfere? From what I understood, the ROM uses the cooperative multitasking method, why would they be harmful? Could you please explain me?

I Could have shared a clearifying screenshot yet in the first post, if the compiler/IDE didn't leave me alone with the configuration business. Have you ever had this issue?

Again really thank you and have a good night /day

 

[Blah]

you wrote too much and I am too lazy to read all of that

 

[Bonnox]

you wrote too much and I am too lazy to read all of that

ook, so let's restart simplier...

What is a superstate? And how do I clear vblank/hblank callbacks? (note that I already know what hblank and vblank are)
I'm working on ruby at the moment.

thank you

 

[Blah]

ook, so let's restart simplier...

What is a superstate? And how do I clear vblank/hblank callbacks? (note that I already know what hblank and vblank are)
I'm working on ruby at the moment.

thank you

I'm not sure if Ruby handles it the same as in FireRed, but it probably does. You can check the game's main loop to confirm, but I'll be explaining it for FR and you can compare/contrast. I'm certain that this applies to EM, but not sure if it is comparable to Ruby (it probably is).

So the game has this structure called the SuperState, in FireRed this is at 030030F0. It contains various data including OAM data from objects in the game, callbacks, button logging and a couple other IO register mirrors. During the main loop, the game syncs the data in the SuperState to VRAM and also to the IO registers depending on what has been set.
The structure also has things like the vblank, hblank, c1 and c2 callbacks.

The Vblank callback is essentially in IRQ interrupt service routine, and when it's set the game (utilizing it's own interrupt handler system) will set an interrupt to occur during the vblank, flip the switch from ARM to thumb and then execute your routine. Similarly for hblank, however, for hblank you need to set and enable the interrupt yourself. You should use game functions to do this if you are not writing ARM code, as IRQ service routines are expected to be in ARM. On a lower priority, the callback1 and callback2 routines in the superstate are executed during the main loop. These are not vsynced and can potentially execute anytime where callback1 is executed before callback2.

The game often uses these to draw the scene, manipulate the superstate, sync objects to the super state, ect. There is ofcourse one which syncs BGs to VRAM as well. That is what you're looking to disable. Though if you're using the script executor, you can't really get away with this, and you'll have to write your own callbacks, and restore the old ones afterwards.

It would be worthwhile to backup and clear all callbacks, disable interrupts outside the ones you need, and then switch to bitmap mode and display your image.

 

[Bonnox]

This is interesting.

However, I tried setting REG_IE to 0, to disable every interrupt but at the end of my code it made the game crash... :(

It seems that after the vcount reached the max value, you still have to "catch" it, or something like that, otherwise your program goes to the void.

And, a question: if I do a "swi 0x5", does it eventually pass the control back to the ROM? This may be the culpript. But its deactivation failed...

Moreover, I switched from bitmap to tile modes, because they're more important; I'm no more interested in bitmap, one problem less to solve, but it seems I am the only one facing it.

I tried calling a simple function that changed the background position, but immediately it was restored, creating a bad flickering effect. Was it the effect of the superstate which you were talking of?

So, if the direct approach is not working because it seems that the ROM is acting like an "operative system" far more than I thought, could I just change approach?

Currently I'm running a script which ony does "callasm".
Should I recreate a loop in the script like "begin: if a flag is on, callasm. goto begin."
And the "asm called" is my C routine wich uses the superstate to change the values of the registers. Does some processing, reads buttons, sets her "sticky notes" about what to do next time is invoked and leaves control. When finished, put the flag off.
Now the problem is where is this superstate located, and how to interact with it.

PS: I like your post, in case my unlucky connection to this site didn't make it process.

 

[Bonnox]

Did you clear the vblank callback and Hblank callbacks in the superstate? As well as the c1, and c2 callbacks? These are called as part of the main loop, and need to be set accordingly.

hey guys i solved, all i had to do was just

"REG_BG2X=0xfffffff;"

in C code!

now i'm super happy, as i can continue my quest :)