Skip to content

WRAM, SRAM: symbol/data misalignment #140

@Narishma-gb

Description

@Narishma-gb

I'm looking over link.asm routines, and I think some of the symbols that have been defined in WRAM and SRAM, don't quite match the data they are referring to. I'm using ax6's notes at https://pastebin.com/NTxjzKGQ, as referenced by 348c5ca, and memory viewer from a debugger.

In WRAM:

SECTION UNION "Overworld Map", WRAM0

; link data members
wLinkPlayerName:: ds NAME_LENGTH
wLinkPartyCount:: db
wLinkPartySpecies:: ds PARTY_LENGTH
wLinkPartyEnd:: db ; older code doesn't check PartyCount

UNION
; link player data
wLinkPlayerData::
; wLinkPlayerPartyMon1 - wLinkPlayerPartyMon6
for n, 1, PARTY_LENGTH + 1
wLinkPlayerPartyMon{d:n}:: party_struct wLinkPlayerPartyMon{d:n}
endr
...

Inside this UNION is the layout for Gen.2 to Gen.2 link. Once the data stream has been cleaned of the serial preamble bytes, and the patch has been applied, wLinkData has this much relevant data:
ld bc, NAME_LENGTH + 1 + PARTY_LENGTH + 1 + 2 + (PARTYMON_STRUCT_LENGTH + NAME_LENGTH * 2) * PARTY_LENGTH

It is no longer raw data, and can directly translate into wLinkPlayerName and following. But player's ID is missing, it should be at wLinkPlayerData, just before wLinkPlayerPartyMon1.
The following code runs after all data has been patched:

.skip_mail
	ld hl, wLinkData
	ld de, wOTPlayerName
	ld bc, NAME_LENGTH
	call CopyBytes

	ld de, wOTPartyCount
	ld bc, 1 + PARTY_LENGTH + 1
	call CopyBytes

	ld de, wOTPlayerID
	ld bc, 2
	call CopyBytes

	ld de, wOTPartyMons
	ld bc, wOTPartyDataEnd - wOTPartyMons
	call CopyBytes

Therefore wOTPartyMon1 currently gets the byte at wLinkPlayerPartyMon1 + 2.

In SRAM:
The discrepancy is minor, and has to do with the definition of *MessageEnd

MACRO mailmsg
\1Message::     ds MAIL_MSG_LENGTH
\1MessageEnd::  db
\1Author::      ds NAME_LENGTH - 1
\1AuthorID::    dw
\1Species::     db
\1Type::        db
\1End::
ENDM

In fact, there is no terminator for mail messages, it is added by the routine that displays message contents.
The extra byte is the middle $4e (<NEXT>) between the 2 lines (allowing easy use of PlaceString). The '@' terminator is placed over the first character of wTempMailAuthor, once its contents has been backed up.

MailGFX_PlaceMessage:
	ld bc, MAIL_STRUCT_LENGTH
	ld de, wTempMail
	ld a, BANK(sPartyMail)
	call OpenSRAM
	call CopyBytes
	call CloseSRAM
	ld hl, wTempMailAuthor
	ld de, wMonOrItemNameBuffer
	ld bc, NAME_LENGTH - 1
	call CopyBytes
	ld a, '@'
	ld [wTempMailAuthor], a
	ld [wMonOrItemNameBuffer + NAME_LENGTH - 1], a
	ld de, wTempMailMessage
	hlcoord 2, 7
	call PlaceString

I suggest redefining the mail macro in a similar way to:

MACRO mailmsg
\1MessageLine1:: ds MAIL_LINE_LENGTH
\1LineBreak::    db
\1MessageLine2:: ds MAIL_LINE_LENGTH
\1Author::       ds NAME_LENGTH - 1
\1AuthorID::     dw
\1Species::      db
\1Type::         db
\1End::
ENDM

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions