APPENDTO not respecting slot

[lajohnston]

Hi there,

It looks like appending data to another RAMSECTION doesn't append it to the same slot.

.ramsection "someRamData" slot 3
    someByte: db
.ends

.ramsection "someMoreData" appendto someRamData
    anotherByte:     db
.ends

The above results in wla-z80 mapping the following:

RAM slot 0 bank 0 (1 bytes (0.01%) used)
  - .RAMSECTION "someMoreData" (1 bytes).
RAM slot 3 bank 0 (1 bytes (0.01%) used)
  - .RAMSECTION "someRamData" (1 bytes).

I would expect it to append to the same slot and bank, but is the current behaviour intentional? It seems even if I change defaultslot to another value it still goes to slot 0. Assigning the slot in the appendto section results in it mapping as I'd expect. I haven't seen this issue with sections so I'm not sure if those are affected as well.

EDIT: It looks like it does affect sections too

[vhelin]

Thanks for the report! I'll try to fix this latest on Wednesday this week...

[vhelin]

I think the issue here is that the assembler doesn't to any appending of .SECTIONs or .RAMSECTIONs and reports what is just written in the code. If you link the object containing this code you should see WLALINK doing the appending (here I inserted this code to the code in https://github.com/vhelin/wla-dx/issues/630 and got this in the end:

What is interesting here that here in the output we have a report about the SLOT where the APPENDTO .RAMSECTION was put initially (0). Found out that it's a bug in WLALINK...

linked.sym:

Seems like WLALINK appends just fine, it just reports a bit wrong...

[vhelin]

I could also try to make the assembler sniff around the code and report in your case correctly what is going to happen... unless linkfile for WLALINK specifies a new slot/bank for these .RAMSECTIONs, then the assembler would be wrong. :)

[lajohnston]

great thanks :) Yes it looks like with the latest version, wlalink is reporting it fine, and wla-z80 is misreporting it in the verbose output. I'm just using a basic linkfile so no slot/bank mapping there

[lajohnston]

A somewhat related feature request, would it be desirable/possible at some point to implement an optional DEFAULTRAMSLOT directive within the MEMORYMAP, which works alongside DEFAULTSLOT but acts as the default for RAMSECTIONs? I'm not sure about other systems, but for the SMS at least I believe the RAM always occupies the same slot so it perhaps makes sense to define it in one place and have all RAMSECTIONs use it

[vhelin]

DEFAULTRAMSLOT sounds like a useful feature so I'll try to implement it later this week