felixjones / gba-toolchain

CMake based toolchain for GBA homebrew development

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GBFS Suggestions

crispyross opened this issue · comments

  1. It seems to me that gba_add_gbfs_target creates a filesystem containing all files, while gba_target_add_gbfs_dependency converts a single given file to a .s file.
    It is kind of confusing to differentiate them. I suggest renaming gba_target_add_gbfs_dependency to something like "gba_target_add_resource_as_asm" since (1) it isn't directly related to a filesystem; it just uses gbfs tools, and (2) it tells you that it makes a ".s" file you can use.

  2. In a few places (e.g. gba_add_gbfs_target), you use add_custom_target to specify how to build a given file. The CMake documentation says the following:

The target has no output file and is always considered out of date even if the commands try to create a file with the name of the target. Use the add_custom_command() command to generate a file with dependencies.

A better way to do this is to use add_custom_command to specify how to build a given file, then add a target with add_custom_target that depends on whatever file is built using add_custom_command.

  1. Is embedding the gbfs into the rom implemented? I didn't see how to do it.
    If it helps, here is how I build the FS image and embed it in the rom:
set(FS_PATH "${CMAKE_CURRENT_BINARY_DIR}/fs.gbfs")
set(FS_CONTENTS test.txt)
add_custom_command(OUTPUT ${FS_PATH}
        COMMAND "${GBA_TOOLCHAIN_GBFS}" "${FS_PATH}" ${FS_CONTENTS}
        WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
        DEPENDS ${ARGN}
        COMMENT "Building filesystem"
        VERBATIM
)
add_custom_target(filesystem DEPENDS ${FS_PATH})
add_dependencies(${PROJECT_NAME} filesystem)

...

add_custom_command(TARGET ${CMAKE_PROJECT_NAME}
        POST_BUILD
        # Copy + strip to binary-only
        COMMAND "${CMAKE_OBJCOPY}" -O binary ${CMAKE_PROJECT_NAME}.elf ${CMAKE_PROJECT_NAME}.gba
        # Pad to nearest 256 byte (needed for gbfs)
        COMMAND "${GBA_TOOLCHAIN_TOOLS}/gbfs/tools/padbin.exe" 256 "${CMAKE_PROJECT_NAME}.gba"
        # Append FS to binary (non-portable; needs CMake 3.18)
        COMMAND ${CMAKE_COMMAND} -E cat fs.gbfs >> ${CMAKE_PROJECT_NAME}.gba
        # Fix header
        COMMAND "${GBA_TOOLCHAIN_GBAFIX}" "${CMAKE_PROJECT_NAME}.gba" "-t${ROM_TITLE}" "-c${ROM_GAME_CODE}" "-m${ROM_MAKER_CODE}" "-r${ROM_VERSION}"
        WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}"
        VERBATIM
)

I'm also not 100% happy with the current scheme.

The intention was to mirror CMake's add_executable/add_library with gba_add_gbfs_target, but I think the use of the word "target" is a mistake here (taken from add_custom_target). Perhaps just gba_add_gbfs would be more obvious.

I can see where it's fallen short of that original intention. gba_add_gbfs should instead create the library project, which would then be linkable by the normal CMake add_dependencies.

Embedding in ROM is not implemented but it is something I want to do, I just haven't had the time to sit down and figure it out. Perhaps really all we need is a generic "pad and concat" command that's not gbfs specific.

Whoops, I didn't see the wiki. Things make a lot more sense now.

I've now implemented some CMake functions for padding a ROM and appending a GBFS file. The GBFS wiki page has more details.
gba_target_object_copy gains an optional final parameter that is "padding boundary", for GBFS this should be 256 to pad to the default 256 boundary that GBFS expects.

gba_target_append_gbfs is used for appending a gbfs target to a given file.

# Object copy with 256 byte boundary padding
gba_target_object_copy( my_target debug.elf rom.gba 256 )

# Create GBFS target
gba_add_gbfs_target( data.gbfs test.txt )
# Append GBFS target to rom.gba
gba_target_append_gbfs( my_target data.gbfs rom.gba )