Breaking up a code monolith into modules / pieces

[+Propane13]

Hi folks,

 

For any project I've ever worked on (which at this point is 1-2 decades ago), I used DASM and had one giant assembly source file that would eventually be compiled into a binary.  As I'm now much older and realize I can't really read and understand any of my former code too well, I was curious what strategies I could use in the future to possibly segment sections of code into different files, and then somehow use some definitions to stitch things together in a smart way.

 

To make the discussion easier, let's make these 2 assumptions:

1. We can ignore any page boundary issues for now
2. We can ignore bank-switching-- let's just say for this example, it's a 4K contiguous game

 

I could easily see logical section-breaks for my code:

• MainLoop
• GameLogic1
• Kernel1

• MusicLoop

• MusicData

• Housekeeping

 

But, it's tricky and I think I'm missing a concept somewhere.  Let's take the Music Stuff as an example.  If it is accessed via a "JSR PlayMusic" command from the MainLoop, then MainLoop needs to be aware of the PlayMusic's defined address.  Similarly, MusicLoop requires access to Lookup tables in MusicData, so it must be aware of those addresses as well.  I can clump MusicData and MusicLoop together, but then with that philosophy, I'm just going to end up right back at a monolith file.

 

It feels like I need to somehow divide my compile phase and create a separate link phase, but I'm not sure how to do that.

 

What have others done that has been successful?

 

 

[+SpiceWare]

22 minutes ago, Propane13 said:

Let's take the Music Stuff as an example.  If it is accessed via a "JSR PlayMusic" command from the MainLoop, then MainLoop needs to be aware of the PlayMusic's defined address.

 

Step 13 - add sound effects of my Collect tutorial shows how to do this.

 

Quote

It's common to have a handful of routines that handle sound effects. For Collect, these routines can be found in the new source code file sfx.asm. To add the file to collect.asm we use the include command:
 

        include sfx.asm

 

 

[Dionoid]

What works for me, is splitting everything (i.e. subroutines, graphics, data, etc.) into separate files (with meaningful names!) and then use the include command in your main.asm to tie all the code together. This makes it easier to find the code you need and also allows for reshuffling of the include-files to prevent page boundary issues.

 

Below you can see a screenshot of the setup I used for Tower of Rubble, where all data, graphics, macros and routines live in their own files. And the main.asm uses all these include commands to pull in these files:

 

And then at the bottom of each file, I included the "BYTE_COUNT" macro, which shows the number of bytes that the specific file used in DASM's output.

 

Source code of macros ALIGN_PAGE, BYTE_COUNT and CHECK_PAGE below:

    MAC ALIGN_PAGE
.Align
    align 256
    ECHO "###", [* - .Align]d, "bytes free before", {1}
    ENDM

    MAC BYTE_COUNT 
    ECHO ">>>", {2}, ":", [* - {1}]d, "bytes"
    ENDM

    MAC CHECK_PAGE
.PREV_POS   SET . - 1
        IF >.PREV_POS != >{1}
                ECHO ""
                ECHO "ERROR:", {2}, "crosses page"
                ECHO ""
                ERR
        ENDIF
    ENDM

 

Edited December 27, 2022 by Dionoid

[+Propane13]

These are great suggestions, thanks!

 

 

[+Al_Nafuur]

I am using VS-Code's region folding feature for the 1942 bB project

 

The "cool" thing about regions is that they can be nested and that they can be folded/unfolded with keyboard shortcuts too (which unfortunately you have to get used to).