Gameboy Development Forum

First of all, welcome !

Here are a couple of things.

If you want to use an emulator for testing, either use BGB or SameBoy. Both of these feature very good debuggers and emulation accuracy.
BGB is especially used, mostly because it's been around for longer :p, but also because it has a more evolved + GUI debugger.
mGBA's GB emulation is still WIP-ish, too.



I've read your code, and here are my impressions. Take them as suggestions, if you prefer writing your code in the way you do, I won't force anything upon you.



Why do you only use one section ? The point of sections is to be independent - thus, you can have `SECTION "Vectors", ROM0[$0000]` and put your RST and interrupt vectors there (or one section per vector), then one `SECTION "Startup", ROM0[$0100]` with the header, entry point, etc.


You should probably use this : https://github.com/tobiasvl/hardware.in … rdware.inc
That file is more or less the standard include file in the community, although not everyone uses it. It's still pretty handy, and standardizes different notations.


Why no RAM sections ? These would let the linker do the allocation for you (and you can force alignment of sections, if you want to do super-optimized wizardry)
Example :

SECTION "DMA routine", HRAM

hDMARoutine::
    ds 11

Instead of `REPT X ; nop ; ENDR`, you may want to use `ds X`, if the value there doesn't matter (it's set to the "fill value", by default 0, but you can change it via command-line params)
I wrote a `dbfill` macros anyways, so I can fill areas with a known value with only one line. RGBDS macros really are awesome.


Why setting all your variables so close to the stack ? You have all of C000-DEFF available, even if you allocate 256 bytes to the stack (I never saw stack usage growing past 64 bytes except with SDCC)


Don't use `memset` to clear OAM, since the 16-bit increment of hl will cause corruption. (BGB would break and warn you of this)


You always push hl (for example in lcd_off), but it's not necessary. On the GBz80, stack ops are much more costly than on the 6502, so personally I prefer to have registers caller-saved (also a lot of the time, I use side effects, eg. I know this function returns with a = 0, so I use that).
You might argue that you often need to save registers, but it hasn't been the case for my game. If you cleverly arrange your registers (eg. BC and DE are basically the same, so if you know there's a subroutine using DE, you might want to use BC for your vars, etc.)


You can turn on the LCD at any time when it's shut down, no need to ensure it's in VBlank. Writing to LCDC with bit 7 set while the LCD is on is also perfectly safe.


VBlank starts at LY = $90, ie. 144, not 145.


Pretty clever joypad routine, I did mostly the same, but `xor b` is more efficient than `and b ; cpl`, nice one !


Regarding your code at line 448-454 to perform sign extension, here's a shorter version :

ld a, [player_dxsub]
ld e, a
rla ; Bit 7 into carry
sbc a, a ; $00 if no carry, $FF if carry
ld d, a

Line 467, you could have removed the `ld e, 0` on the line above, and jumped to the one right before .notHitRight


Line 502, you can save one byte :

and $FC
rrca ; Only 1 byte
rrca
ld b, a
rra ; Carry was 0 because 0 bit was rotated in
and a ; \
rrca  ; / Same in size and speed as `sra a`, I'm just showing an alternative.

Overall, this code isn't as bad as what I have seen people write as their first program. I'm not really seeing anything that would smell like 6502, either.


As for general GB advice ; the GB is much more comfortable to work with than the NES, imo (more interrupts, much more convenient LCD for classy raster effects, and overall I prefer the GBz80/LR35902 to the 6502). Where it bites is graphics : accessing VRAM is always a bottleneck, the screen is really small, and you have barely any sprites to work with. The GBC adds its own twists, both good and bad, to the table.


Again, welcome to the community ! If you want, please also consider joining the IRC channel and/or Discord server.

Thank you for the detailed review.

If you want to use an emulator for testing, either use BGB or SameBoy.

My ThinkPad X61 runs Debian 9. Though beware tests bgb in Wine, bgb is 32-bit only, and it has no source code. These tend to cause problems for some purists (source; source). Some GNU/Linux distributions are even threatening to drop support for running 32-bit applications (which is a rawther Apple-like move). With no source code, there's no way to audit it for ransomware or other malware. What precautions do most users here take when using proprietary emulators?

SameBoy's tile viewer requires macOS (source), which requires Mac hardware, which (as beware pointed out to me in #gbdev on EFnet) has terrible keyboards.

My NES development uses FCEUX, which isn't the most accurate at PPU timing but is reasonably fast, and its CPU is still accurate enough to step through game logic. I'd then test the game authoritatively on a PowerPak, where hardware compatibility issues would become more apparent but input lag was a non-issue. The same was true back when I tried the GBA: Ctrl+R builds and runs in VisualBoyAdvance, then I send the program to the system through a flash cart or MBV2 cable for play testing.

Why do you only use one section ?

The lack of "SECTION" arose from having followed "Tutorial: Making an Empty Game Boy ROM (in RGBDS)". I think the "push hl" habit arises from some other tutorial. Now that I have a working baseline, I'll be able to work on organizing the ROM better.

Why setting all your variables so close to the stack ?

That actually relates to something else I had planned to ask about later, related to how to work around the LR35902's lack of indexed addressing modes. The Z80 has the [IX+n] mode with a small constant offset from a large register pointer, and the 6502 has the aaaa,X mode with a small register offset from a large constant pointer, and the (dd),Y mode with a small register offset from a large memory pointer. The implications of this conspicuous absence on organization of game state data structures could fill another topic, which I plan to post later after I put into place some of the suggested changes. A preview: treating RAM as if it were a 256x32-cell 2D array.

Don't use `memset` to clear OAM, since the 16-bit increment of hl will cause corruption. (BGB would break and warn you of this)

That's a bug. I thought I had already removed that. The first DMA would copy $DE00-$DE9F to $FE00-$FE9F, thereby erasing the corruption anyway.

You can turn on the LCD at any time when it's shut down, no need to ensure it's in VBlank.

Does LY increment while the LCD is off? Does the interrupt handler for vblank get called? I ask because someone else wondered why I'm using a busy wait as opposed to enabling interrupts and using halt, and I want to ensure I understand what's going on now before I dive into interrupts.

VBlank starts at LY = $90, ie. 144, not 145.

I take it there's no NES-style "post-render line", where there's a 1-line gap between and the vertical blank interrupt, and no Super NES-style inclusion of the pre-render pixel pipeline priming line in LY with the top visible line being 1. Do I understand correctly?

Thanks for the sign extension idiom. It'll take me a while to get used to the implications of the carry flag for subtraction having the opposite sense that it does on ARM and 6502. Is there a page for Z80 idioms analogous to the 6502 idioms that NESdev members have collected?

I'm not really seeing anything that would smell like 6502, either.

If you're curious, the code this was based on is nrom-template.

Where it bites is graphics : accessing VRAM is always a bottleneck

But unlike the NES, the Game Boy opens VRAM during hblank. This allows for 20-30 fps engines that do all the calculation in one frame and the VRAM updates in the other, and DMG's slow STN LCD makes 20-30 fps engines far more forgivable.

you have barely any sprites to work with.

On the NES, 64 sprites arranged 8 to a line cover 25% of 128 scanlines. On the Game Boy, 40 sprites arranged 5 to a line also cover 25% of 128 scanlines, and that's more overall coverage to boot.

I joined #gbdev a few hours ago. What Discord server are you referring to? It can't be the one Kaydus the Dragon just started. Is it the one under "Community" on this page?

Now for AntonioND's reply:

But clear the OAM, though!

I have a display list at $DE00-$DE9F, which gets DMA'd to OAM during vblank. The lcd_clear_oam subroutine clears from $DE00+[oam_used] to the end of this display list, which moves all unused sprites offscreen in the display list that gets DMA'd to OAM. I really ought to make this clearer in comments. Or does OAM need to be cleared even before DMAing on top of it?

Well, with the LCD off there aren't VBlank periods at all. The LCD controller is simply disabled.

Is that anything like AMD FreeSync?

My concern with modified routines is that changing from one matrix input to the other one affects a real circuit with higher capacitance than any other access. I'm not sure if doing it any faster is good

In this case, I was optimizing for size, not speed, hence the "call .onenibble". And this "xor b" happens after the read anyway. In any case, it's probably already faster than the serial read one has to use on the NES.

Last edited by PinoBatch (2018-03-22 23:21:27)

I've managed to change all WRAM allocations to SECTION-based. As for HRAM, man 5 rgbasm says "NOTE: If you use this method of allocating HRAM the assembler will NOT choose the short addressing mode in the LD instructions". My best guess is that RGBDS has no counterpart to ca65's ".globalzp" command that asserts at link time that an imported address is a short address.

Is it possible to make multiple WRAM0 or HRAM sections overlap, so that a subroutine can get (say) its own set of local labels at $FF80-$FF8F? In my NES work, I have a calling convention that $0000-$000F is local variables, where each subroutine's doc comment defines which locals it clobbers.

Another frustration I've found is that RGBASM is indentation-sensitive, which clashes with my coding style that uses indentation to delimit the equivalent of compound statements (like if, while, and for in C++, Java, PHP, or JavaScript). I guess I could write a preprocessor that emulates ca65's convention of using a colon to mark off labels. I previously wrote one to add support for C++-style "//" line comments to the m68k assembler in GNU Binutils. GNU as for m68k normally uses "|" as the comment separator, allowing either comments or bitwise OR of bits to go into a register but not both in the same file. My preprocessor stripped C++ comments into a copy of the file in a temporary folder before handing the file off to the assembler.

In order to make sure my HALT support is doing what it's supposed to: Does bgb have an option to test for several consecutive frames with display on and no HALT, like the "Break on" options? I tried logging the ROM under the "Execution profiler" menu, but choosing the number of instructions seen didn't display anything. Should I be looking at the green bar at top right?

Further, there's nothing preventing you from using arrays when relevant. I don't see the point of game state structures -- the game's state is the entirety of the RAM, and how it's laid out doesn't change anything to that.

It affects the speed and size of the code that moves actors of each type.

I prefer 60 fps engines, it's much simpler to have all frames equal, imo.

There's a reason Super Mario Land 2 looks less motion-blurry on a DMG than Super Mario Land, and I don't think it's just sprite outlining. But again, I'll expound on this more in a separate topic.

AntonioND wrote:

You can use UNION to overlap things on WRAM, VRAM, OAM and HRAM sections.

But can I declare the different members of a UNION in different files, such as the file in which (say) a background-updating subroutine is defined and the file in which a sprite-updating subroutine is defined? Or would I have to have one file declaring all the members of that UNION used by all the subroutines in a program? I don't see how that would be any more practical to maintain than allocating locals with EQU.

AntonioND wrote:

Yes, the indentation thing is really annoying, but I'm not sure about changing that.

I made the preprocessor that changes that, and I plan to release it in a couple days once I have the reorganization where I want it.

PinoBatch wrote:

AntonioND wrote:

You can use UNION to overlap things on WRAM, VRAM, OAM and HRAM sections.

But can I declare the different members of a UNION in different files, such as the file in which (say) a background-updating subroutine is defined and the file in which a sprite-updating subroutine is defined? Or would I have to have one file declaring all the members of that UNION used by all the subroutines in a program? I don't see how that would be any more practical to maintain than allocating locals with EQU.

Well, yeah, in that case it is a bit complicated. I wouldn't recommend you to use EQU, but RSRESET, RB, RL, etc: https://rednex.github.io/rgbds/rgbasm.5.html#SYMBOLS EQU is definitely not a good idea because of what ISSOtm has said, it's not maintainable.

You could allocate a section that is X bytes in size and just check with the last label in teh RS group that you're not overflowing the limits.

You could simply declare the labels in a header file and include it:

UNION
INCLUDE "header1.inc"
NEXTU
INCLUDE "header2.inc"
ENDU

PinoBatch wrote:

AntonioND wrote:

Yes, the indentation thing is really annoying, but I'm not sure about changing that.

I made the preprocessor that changes that, and I plan to release it in a couple days once I have the reorganization where I want it.

I'm not a fan of doing this kind of thing because of purely aesthetic reasons, but well, maybe someone will find it useful.

I tried to take most of these suggestions into account.

* Split into separate files paralleling those of nrom-template
* Use RLA SBC A sign extension idiom (suggested by ISSOtm)
* Remove unnecessary and broken OAM clearing
* Add optional zealous memory clearing to satisfy BGB exceptions
* Add doc comments to most subroutines
* lcd_*: Don't push HL so much
* Put global variables and the DMA routine's run address under SECTION control
* Try RSSET/RB to allocate local variables, nearly but not fully eliminating EQU allocation
* Display frame count and initial A, B contents at top
* Change frame count in vblank IRQ, and HALT until it changes
* Explicitly mark MMIO port and local variable accesses as LDH because RGBDS lacks a counterpart to ca65 .importzp. What is this, NESASM? Ref
* Add indentation correction to the build process
* Change padding value to $FF
* makefile: Add BGB as secondary emulator for "make debug"


Video

Download hello-0.02.zip: hello.gb and RGBDS source

nitro2k01 wrote:

you should either clear OAM before turning the LCD on, or make sure sprites are disabled in LCDC until the first DMA has been performed.

As a rule, my NES and Game Boy programs do the latter. On second look, I did mess this one up when I worked around the fact that the Game Boy doesn't assert vblank IRQ if the LCD is off. I plan to fix it in next revision by leaving the LCD on for a frame with both BG and OBJ hidden and then fully populating LCDC after the game loop has run for one full frame (which draws sprites and clears unused Y coordinates). Just clearing OAM (or clearing shadow OAM and doing DMA) would also be "imperfect", showing one frame with background and no sprites.

nitro2k01 wrote:

What type of read did the BGB exception trigger on?

My shadow OAM clearing loop was clearing only the Y coordinate of unused sprites. BGB was giving exceptions when copying the X, tile number, and attribute bytes. Is it important to clear those bytes even if the Y coordinate has a value marking the sprite as unused (namely 0 or 176-255)?

PinoBatch wrote:

My shadow OAM clearing loop was clearing only the Y coordinate of unused sprites. BGB was giving exceptions when copying the X, tile number, and attribute bytes. Is it important to clear those bytes even if the Y coordinate has a value marking the sprite as unused (namely 0 or 176-255)?

No, that's fine. But I'm curious why though. It seems like it would be less effort to fully clear OAM/the OAM DMA source using an existing memory clear function rather than clearing every 4th byte...

Slowly but surely, I'm coming to terms with this hardware.

0.03 (2018-05-12)

* Switch to de facto standard hardware.inc (requested by gbdev Discord members)
* makefile: Use target name for rgbfix instead of hardcoding hello.gb
* Hide BG and sprites before game loop to avoid sprite garbage (reported by nitro2k01)
* Use palette registers instead of LCDC to hide BG and sprites for GBC friendliness (requested by ISSOtm)
* Fade out Nintendo logo while detecting Super Game Boy on DMG
* Add GBC palette approximating that used by nrom-template on NES


Video, now in color

Download hello 0.03 (ROM and source)