vhelin / wla-dx

WLA DX - Yet Another GB-Z80/Z80/Z80N/6502/65C02/65CE02/65816/68000/6800/6801/6809/8008/8080/HUC6280/SPC-700/SuperFX Multi Platform Cross Assembler Package
Other
549 stars 98 forks source link

GBZ80 - Unusual ROM bank maps cause WLA-GB to reference garbage memory #497

Closed ToriningenGames closed 2 years ago

ToriningenGames commented 2 years ago

This bug was found on the latest version of WLA-DX (Mar 25, 2022). The following Memory Map and ROM Bank Map cause WLA-GB to reference garbage memory in Bank 1, sometimes crashing:

.MEMORYMAP
SLOTSIZE $8000
DEFAULTSLOT 0
SLOT 0 $0000
.ENDME

.ROMBANKMAP
BANKSTOTAL 2
BANKSIZE $8000
BANKS 1
BANKSIZE $1
BANKS 1
.ENDRO

This bug behaves differently if WLA-GB is being debugged.

For extra information on why I have a Memory Map like this: I am making a 32k game, and would like code/data to bridge the 16k barrier that the standard Memory Map creates, because all the code/data fits into 32k, but not two banks of 16k. I figured such an arrangement wouldn't cause problems on hardware, and doesn't cause problems on emulators.

WLA-GB doesn't support a ROM Bank Map with only one bank (because it doesn't know what to put in the header), so I use this ROM Bank Map: there are two banks, bank 1 is filled with 0 for the checksum to come out correct, and the resulting ROM is trimmed to 32k, deleting bank 1.

I understand if WLA-GB would change its handling of this ROM Bank Map; it is unusual. However, even invalid input should not cause assembler crashes, in my opinion.

ToriningenGames commented 2 years ago

It appears as though WLA-GB treats both banks as the same size, even when the .ROMBANKMAP changes the size. This is difficult to determine; random changes to assembly files cause crashes, and the only suggestion what size WLA is treating the bank is the sporadic usage statistics ouput using -v.

ToriningenGames commented 2 years ago

Oh, I almost forgot example output! main.asm:

.MEMORYMAP          ;Memory Map (For wla-gb)
SLOTSIZE $8000
DEFAULTSLOT 0
SLOT 0 $0000
.ENDME

.ROMBANKMAP         ;ROM Bank Map (no mapping)
BANKSTOTAL 2
BANKSIZE $8000
BANKS 1
BANKSIZE $1
BANKS 1
.ENDRO

.BANK 0 SLOT 0
.ORG 0
.dbcos 1000,$7FFF,1,1,1

console:

C:>wla-gb.exe -v -x -o main.obj main.asm
Pass 1...
Directive checks...
Internal pass 1...
Internal pass 2...
-------------------------------------------------
---                   ROM                     ---
-------------------------------------------------
ROM bank 0 (32768 bytes (100.00%) used)
  - Outside .SECTIONs (32768 bytes)
    - Used space at $0000-$7ffe (32767 bytes).
  - Sections (0 bytes)
    - No .SECTIONs found.
ROM bank 1 (13 bytes (0.04%) used)
  - Outside .SECTIONs (13 bytes)
    - Used space at $0008-$000e (7 bytes).
    - Used space at $0010-$0012 (3 bytes).
    - Used space at $0018-$001a (3 bytes).
  - Sections (0 bytes)
    - No .SECTIONs found.

The unusual part is the Used Space in Bank 1, when no data was defined there. Although this example does not crash on my machine, it is at this point in verbose output that crashes do happen.

vhelin commented 2 years ago

Thanks for the report, I found out that WLA(-GB)'s newish verbose mode summary printer was broken when .ROMBANKMAP had ROM banks of different sizes. If you try the latest sources they should work now better.

I think I'll relax the requirements for the number of ROM banks in WLA-GB next...

vhelin commented 2 years ago

Now what you tried to do initially (one big 32KB ROM bank) should be possible to do...

ToriningenGames commented 2 years ago

Yay! Thank you. One large bank works now, and my initial workaround seems to work too.

Maybe some way to turn off WLA-GB putting things in the header would be useful in the future, for when people (ab)use the header by hand? WLA-GB is an oddball, being more tied to one platform than the other WLAs. But, that's hard to argue, given the CPU doesn't show up anywhere else, and nobody can change that.

vhelin commented 2 years ago

Yeah, WLA-GB was the first WLA to appear and thus it has the biggest historical load of them all, some of its Gameboy related directives are over 20 years old. :)

But sure, we could add such a feature that'd disable writing things into GB ROM's header, I'll open a separate issue for that.