65816 Memory Maps + Vector Directive Aliases

[cr1901]

Looking over my previous SNES examples using WLA got me thinking about a few things:

1. The 65816 backend is currently the only backend which can address more than 64kB without using an external bank switching scheme. The bank switching is just built in :P. Because the bank register is internal to the CPU and placed on the high 8-bits 24-bit address bus when accessing memory, it's easier to envision* an addressing scheme where all 64kB are switched out when a different bank is accessed. Furthermore, it's possible to use the '816 in a Harvard Architecture scheme (the '816 has control signals to distinguish code and data access).
2. Such bank switching/Harvard architecture schemes indicate that it is possible for different banks mixed-code-and-data, separate code and data, or otherwise can take on different .MEMORYMAPS depending on the bank number. The former is hardly unique to the 65816, but I've found that this is the arch where it's most likely to happen. In fact, it happens on the SNES! This is one of those cases where ROM and RAM .SLOTS will overlap, depending on .BANK number. In LOROM parlance:
   • Banks 0-$7D
     • 0-$1FFF Shared RAM
     • $2000-$7FFF I/O Ports
     • $8000-$FFFF ROM
   • $7E
     • 0-$1FFF Shared RAM
     • $2000-$FFFF Unshared RAM
   • $7F
     • 0-$FFFF Unshared RAM
   • $80-$FF
     • Mirrors that don't exactly match 0-$7F. Ignore them.
3. .RAMSECTIONS in and of themselves are bank agnostic. Currently, to use all 128kB of RAM, I have to define 6 .RAMSECTIONS, 3 in banks $7E and $7F using this correct SNES LOROM .MEMORYMAP:

.MEMORYMAP                      ; Begin describing the system architecture.
  SLOTSIZE $8000                ; The default slot is $8000 bytes in size.
  DEFAULTSLOT 2
  SLOT 0 $0 SIZE $2000      ; (Shared) Ram size
  SLOT 1 $2000 SIZE $6000   ; Used for other things
  SLOT 2 $8000                  ; ROM (for most banks)
.ENDME          ; End MemoryMap definition

This works fine, but seems inelegant to have to manually place variables into slots when physically the RAM is in fact contiguous. In other setups, this would also break contiguous ROM sections, because a .MEMORYMAP would have to be split into the finest granularities required across all possible banks (since a .MEMORYMAP is shared across all banks). Additionally, I'm not even SURE how this works for HIROM, where $00-$3F is entirely ROM and the I/O and shared RAM space come after.

1. I have a feeling the above approach is not the correct one, considering that HIROM is indeed possible/implemented in WLA. Is it possible to either specify:
   • .MEMORYMAPs that differ between RAM and ROM for a given bank (Harvard arch)
   • .MEMORYMAPs that differ between banks (for more complicated address spaces where RAM/ROM address space differs depending on bank)
   • .MEMORYMAPs that can span across slots (See bank $7F for rationale).
   • ~~Ensuring that when RAM and ROM do in fact overlap, the assembler can detect if there is a bank collision.~~ (I had a complete thought here. It got lost.)

More importantly, can the above be specified in WLA using .BANKS, .SECTIONS, and other directives more appropriately than I have been doing?

Also as an aside, .SNESEMU/.SNESNATIVEVECTOR should work just fine, but is it possible to add a non-SNES alias so ppl using the '816 for other work won't be confused :P? I want to use WLA for my '816 SBC, whenever I get around to actually building it :P.

[vhelin]

Sorry for taking so long with this email, but when I first read it I didn't understand it all. :)

On Sat, Dec 6, 2014 at 2:28 AM, William D. Jones [email protected] wrote:

Looking over my previous SNES examples using WLA got me thinking about a few things:

The 65816 backend is currently the only backend which can address more than 64kB without using an external bank switching scheme. The bank switching is just built in :P. Because the bank register is internal to the CPU and placed on the high 8-bits 24-bit address bus when accessing memory, it's easier to envision* an addressing scheme where all 64kB are switched out when a different bank is accessed. Furthermore, it's possible to use the '816 in a Harvard Architecture scheme (the '816 has control signals to distinguish code and data access). 2.

Such bank switching/Harvard architecture schemes indicate that it is possible for different banks mixed-code-and-data, separate code and data, or otherwise can take on different .MEMORYMAPS depending on the bank number. The former is hardly unique to the 65816, but I've found that this is the arch where it's most likely to happen. In fact, it happens on the SNES! This is one of those cases where ROM and RAM .SLOTS will overlap, depending on .BANK number. In LOROM parlance: -

  Banks 0-$7D
   - 0-$1FFF Shared RAM
     - $2000-$7FFF I/O Ports
     - $8000-$FFFF ROM
   -

  $7E
   - 0-$1FFF Shared RAM
     - $2000-$FFFF Unshared RAM
   -

  $7F
   - 0-$FFFF Unshared RAM
   -

  $80-$FF
   - Mirrors that don't exactly match 0-$7F. Ignore them.
    3.

.RAMSECTIONS in and of themselves are bank agnostic. Currently, to use all 128kB of RAM, I have to define 6 .RAMSECTIONS, 3 in banks $7E and $7F using this correct SNES LOROM .MEMORYMAP:

.MEMORYMAP ; Begin describing the system architecture. SLOTSIZE $8000 ; The default slot is $8000 bytes in size. DEFAULTSLOT 2 SLOT 0 $0 SIZE $2000 ; (Shared) Ram size SLOT 1 $2000 SIZE $6000 ; Used for other things SLOT 2 $8000 ; ROM (for most banks) .ENDME ; End MemoryMap definition

This works fine, but seems inelegant to have to manually place variables into slots when physically the RAM is in fact contiguous. In other setups, this would also break contiguous ROM sections, because a .MEMORYMAP would have to be split into the finest granularities required across all possible banks (since a .MEMORYMAP is shared across all banks). Additionally, I'm not even SURE how this works for HIROM, where $00-$3F is entirely ROM and the I/O and shared RAM space come after.

1. I have a feeling the above approach is not the correct one, considering that HIROM is indeed possible/implemented in WLA. Is it possible to either specify:
   • .MEMORYMAPs that differ between RAM and ROM for a given bank (Harvard arch)
   • .MEMORYMAPs that differ between banks (for more complicated address spaces where RAM/ROM address space differs depending on bank)
   • .MEMORYMAPs that can span across slots (See bank $7F for rationale).

... I guess the answer is no to all these questions. :P

1. • Ensuring that when RAM and ROM do in fact overlap, the assembler can detect if there is a bank collision. (I had a complete thought here. It got lost.)

More importantly, can the above be specified in WLA using .BANKS, .SECTIONS, and other directives more appropriately than I have been doing?

I guess what you are doing is the only way to do it in WLA... There is just one .MEMORYMAP and when you link files together they should all use the same one. Any ideas how to make WLA better regarding this problem? I tried to think it a bit, but my brain just gets stuck... :P Could allowing a unique .MEMORYMAP per file work? I'm not sure if the linker could handle such a scheme... ?

Also as an aside, .SNESEMU/.SNESNATIVEVECTOR should work just fine, but is it possible to add a non-SNES alias so ppl using the '816 for other work won't be confused :P? I want to use WLA for my '816 SBC, whenever I get around to actually building it :P.

Sure! Any suggestions?

— Reply to this email directly or view it on GitHub https://github.com/vhelin/wla-dx/issues/25.

[jeffythedragonslayer]

Also as an aside, .SNESEMU/.SNESNATIVEVECTOR should work just fine, but is
it possible to add a non-SNES alias so ppl using the '816 for other work
won't be confused :P? I want to use WLA for my '816 SBC, whenever I get
around to actually building it :P.

Sure! Any suggestions?

How about:

.EIGHTSIXTEEN

[vhelin]

@Ramsis-SNES, here's another old issue I'm revisiting. As you've written some 65816 code using WLA DX, how do you see this issue? Have you had similar problems?

[Ramsis-SNES]

At some point, I did plan to implement .RAMSECTIONs in one of my projects but didn't get very far. Assuming this is the main issue the OP intended to raise, I kind of agree on that an extended .MEMORYMAP specification might be worth considering.

But, please give me some time (i.e., a few days) to re-read the documentation on .RAMSECTION and to do some more tests. Development is unfortunately hindered at the moment, but I'll see what I can do.

Thanks! :-)

[vhelin]

Absolutely, take all the time you need! This issue has been here since 2014 so a couple of days or weeks or months don't matter. :)

[vhelin]

If you can come up with improvement ideas to .RAMSECTIONs then feel free to spill the beans! Maybe add another way to define RAM variables?