Gameboy Development Forum

FranMatsusaka · 2019-09-26 16:59:15

Hi,

As I said in the other post I'm developing a gb game and it's in its final stage of the development. Still there's a couple of question about some aspects that I can not make work properly ...

1. As every knows all vram access must been done in a small period of time after vblank interruption, otherwise we will have graphical corruption and errors. My game has several bullets and some slowdowns in some given situations. I would like the music to work in normal pace even in slowdown moments. Put the music in the interrupt handler seems to be the solution. But doing this, and if I haven't understood it incorrectly, will I consume a vital part of the period for the vram access? Am I right in this assumption? Is there any workaround to achieve this?

2. In gbc mode I've been trying to change cpu speed in the more critical moments, to avoid slowdowns in color version, but when I do that in the middle of the game it restarts from the begginning. Is only a error of my code, or is this switching can only be used in some particular situations?

Thanks in advance

Tauwasser · 2019-09-26 17:59:30

Hi there.

Regarding your first question: you're mixing up vram blanking and general interrupts. While there may be times when these two would occur simultaneously, your music code shouldn't take a huge amount of cycles to run. So that means you shouldn't relay on using 100% of the available "safe" time during blanking to do the VRAM update.

You don't show any code for your second question, so I'm guessing here. Switching speed on GBC requires some minor setup: you should disable interrupts, set the register to prepare for speed switch, perform the speed switch using the STOP instruction. If you experience crashes on real hardware, it might be that an interrupt fires while performing the speed switch and due to the nature of switching clocks, the CPU might misbehave.

FranMatsusaka · 2019-09-26 18:40:39

Hi Tauwasser, thanks for your replay,

Tauwasser wrote:
Regarding your first question: you're mixing up vram blanking and general interrupts. While there may be times when these two would occur simultaneously, your music code shouldn't take a huge amount of cycles to run. So that means you shouldn't relay on using 100% of the available "safe" time during blanking to do the VRAM update.

I will try.

Tauwasser wrote:
You don't show any code for your second question, so I'm guessing here. Switching speed on GBC requires some minor setup: you should disable interrupts, set the register to prepare for speed switch, perform the speed switch using the STOP instruction. If you experience crashes on real hardware, it might be that an interrupt fires while performing the speed switch and due to the nature of switching clocks, the CPU might misbehave.

The code is this:

Code:

ToggleCPUSpeed:

        di

        ld      hl,rIE
        ld      a,[hl]
        push    af


        xor     a
        ld      [hl],a         ;disable interrupts
        ld      [rIF],a

        ld      a,$30
        ld      [rP1],a

        ld      a,1
        ld      [rKEY1],a

        stop

        pop     af

        ld      [hl],a

        ei

        ret

It's the only code that I could find ion the web. I took it from here:
http://www.devrs.com/gb/files/faqs.html

FranMatsusaka · 2019-09-26 19:17:50

Mmm, I've found in BGB that after the "stop" the "pop af" was not displayed in the debbugger. Also, the "stop" was displayed as a "corrupted stop" ??? I put a "nop" between both and that made the thing work.

ISSOtm · 2019-09-28 05:10:49

STOP appears to be two-byte, actually. Weird that you didn't get it assembled correctly, which version of RGBDS are you using?

FranMatsusaka · 2019-09-28 12:41:00

ISSOtm wrote:
STOP appears to be two-byte, actually. Weird that you didn't get it assembled correctly, which version of RGBDS are you using?

I use WLA-DX

nitro2k01 · 2019-09-28 16:45:07

1) The important thing for avoiding music slowdown is that you keep calling the music routine at regular intervals, even when other code is hogging the CPU. You could approach this in various ways. One way would be to check at the end of the VBlank interrupt handler if it took too much time, and for example call the music routine twice in that case.

Another strategy might be to set up an LCD interrupt for the music player using LY=LYC coincidence mode, and set LYC to something slightly bigger than 0 so the music routine is called when the screen is in the middle of drawing. This would require some tricky interrupt processing though, because you would have to enable interrupts during the VBlank interrupt execution, which could lead to the VBlank interrupt being called a second time while it's already running! You could disable the VBlank interrupt in rIE then run the EI instruction as one way of achieving this goal.

The choice of strategy depends on how much over the allowed time the VBlank handler takes. If it already takes too long, the next pending VBlank interrupt might end up too late so it can't finish writing everything it needs within time either.

The better option is probably to optimize the code so none of this is needed in the first place though. (Easier said than done of course.)

2) The game should not restart when you do the speed switch. This means that your code has some form of bug. However, keep in mind that switching speeds does cause a glitch in the video output, so it's recommended to only do it in transitions between scenes, and not in the middle of a game.

FranMatsusaka · 2019-10-23 08:53:06

nitro2k01 wrote:
1) The important thing for avoiding music slowdown is that you keep calling the music routine at regular intervals, even when other code is hogging the CPU. You could approach this in various ways. One way would be to check at the end of the VBlank interrupt handler if it took too much time, and for example call the music routine twice in that case.

Hi nitro2k01, thanks for your anwser, it was really helpfull. I did exactly like you said, calling music routine twice and now it's working like charm!

nitro2k01 wrote:
2) The game should not restart when you do the speed switch. This means that your code has some form of bug. However, keep in mind that switching speeds does cause a glitch in the video output, so it's recommended to only do it in transitions between scenes, and not in the middle of a game.

I wanted to check in the real device before anwsering... but it happens that I'm switching speed in the middle of the game without any error in the screen. While I was creating the routine I read somewhere that switching speed would make the screen flikering once, as when screen is disabled. But that's not what I see in my game. No flickering, no graphical error, nothing wrong at all. And the game is running smothly at 60 fps all the time, so it can be said that speed mode shitched sucesfully.

FranMatsusaka · 2019-10-23 09:06:30

Besides that, I have a couple of extra questions:

1)I'm trying to save scores in the sram. I'm compilling to MBC1+RAM+BATTERY, but the data is not being saved in $A000 block. Also, BGB emulator says that RAM size and cart type doesn't match. What could be the correct configuration to make it working?

This is the header config:

.gbheader
name "Wing Warriors"
cartridgetype $03 ;$00 ROM ;$01 ROM MBC1 ;$02 ROM MBC1 RAM ;$03 ROM MBC1 RAM BATTERY
ramsize $01 ;$0 None $1 - 2kByte, 1 bank ; $2 - 8kByte, 1 bank
romgbconly
nintendologo
.endgb

2) I'm planning to make a physical edition, and I'm starting to design the box. Should I remove any "Nintendo" and "GameBoy" logos from the box to avoid any legal problem? Tobu tobu girl has removed any reference in the color edition box, but that could be a legal requirement from Kickstarter?

Thanks in advance!

FranMatsusaka · 2019-11-01 04:32:09

FranMatsusaka wrote:
Besides that, I have a couple of extra questions:

1)I'm trying to save scores in the sram. I'm compilling to MBC1+RAM+BATTERY, but the data is not being saved in $A000 block. Also, BGB emulator says that RAM size and cart type doesn't match. What could be the correct configuration to make it working?

This is the header config:

.gbheader
name "Wing Warriors"
cartridgetype $03 ;$00 ROM ;$01 ROM MBC1 ;$02 ROM MBC1 RAM ;$03 ROM MBC1 RAM BATTERY
ramsize $01 ;$0 None $1 - 2kByte, 1 bank ; $2 - 8kByte, 1 bank
romgbconly
nintendologo
.endgb

2) I'm planning to make a physical edition, and I'm starting to design the box. Should I remove any "Nintendo" and "GameBoy" logos from the box to avoid any legal problem? Tobu tobu girl has removed any reference in the color edition box, but that could be a legal requirement from Kickstarter?

Thanks in advance!

I found a solution. For a unknown reason wla-dx doesn't write correctly the RAM size in the checksum, being always 0, even if the directive .ramsize is defined. Editing the gb file with a hex editor fixed the problem. In the position $149 you must write the value you wan't ($0 = None; $1 = 2kByte, 1 bank; $2 = 8kByte...) and substract that same value to the position $14D

Tauwasser · 2019-11-01 07:49:12

Sie 0x01 is actually undefined, use 0x02.

FranMatsusaka · 2019-11-01 18:47:39

Tauwasser wrote:
Sie 0x01 is actually undefined, use 0x02.

Not in MBC1, the only mapper that allows 2kb of external RAM
http://www.dotmatrixgame.com/documentat … eader.html

Also bgb takes it as a valid value... And it works on the real hardware.

Tauwasser · 2019-11-02 13:47:34

I'm afraid you're mistaken. There are simply no official games that use 16 Kibit (=2 KiB) of SRAM, they either use 64 Kibit (= 8KiB) or 256 (=32 KiB). The original software selection forms by Nintendo also don't specify this.

Of course any value works on real hardware as long as there is enough SRAM and it's at the right place, because there is nothing that evaluates the header value to limit SRAM size or something similar.

FranMatsusaka · 2019-11-02 20:50:46

Tauwasser wrote:
I'm afraid you're mistaken. There are simply no official games that use 16 Kibit (=2 KiB) of SRAM, they either use 64 Kibit (= 8KiB) or 256 (=32 KiB). The original software selection forms by Nintendo also don't specify this.

I see. From that point of view I gess you're right. But bgb accept that value, compilers also accept it and in the real hardware works, so it seems to be like an undocumented feature... Thanks for the info anyway, I will take it on account.

Tauwasser wrote:
Of course any value works on real hardware as long as there is enough SRAM and it's at the right place, because there is nothing that evaluates the header value to limit SRAM size or something similar.

That's something very interesting that I wanted to know. Thanks

FranMatsusaka · 2019-11-05 04:05:17

Hi again, I just wanted to share the game to all of you. It is in a release candidate, so some bugs could be fixed until the final version but it's quite stable and polished.

I'm planning in realease a physical version very soon. If anybody is interested ina copy just send me a PM

Link to the game:
https://drive.google.com/open?id=12R5rU … 6YaXQ5cM-K

Gameboy Development Forum

Ads

#1 2019-09-26 16:59:15

Couple of questions from a gb newbie

#2 2019-09-26 17:59:30

Re: Couple of questions from a gb newbie

#3 2019-09-26 18:40:39

Re: Couple of questions from a gb newbie

Tauwasser wrote:

Tauwasser wrote:

Code:

#4 2019-09-26 19:17:50

Re: Couple of questions from a gb newbie

#5 2019-09-28 05:10:49

Re: Couple of questions from a gb newbie

#6 2019-09-28 12:41:00

Re: Couple of questions from a gb newbie

ISSOtm wrote:

#7 2019-09-28 16:45:07

Re: Couple of questions from a gb newbie

#8 2019-10-23 08:53:06

Re: Couple of questions from a gb newbie

nitro2k01 wrote:

nitro2k01 wrote:

#9 2019-10-23 09:06:30

Re: Couple of questions from a gb newbie

#10 2019-11-01 04:32:09

Re: Couple of questions from a gb newbie

FranMatsusaka wrote:

#11 2019-11-01 07:49:12

Re: Couple of questions from a gb newbie

#12 2019-11-01 18:47:39

Re: Couple of questions from a gb newbie

Tauwasser wrote:

#13 2019-11-02 13:47:34

Re: Couple of questions from a gb newbie

#14 2019-11-02 20:50:46

Re: Couple of questions from a gb newbie

Tauwasser wrote:

Tauwasser wrote:

#15 2019-11-05 04:05:17

Re: Couple of questions from a gb newbie

Board footer