Hello. I am working on a complete disassembly of Sonic 1 Master System for the purposes of a full editing suite for the game. I am working toward porting the ROM from 256K to 512K. This requires properly labelling and structuring the disassembly so that the code and data is portable and can be moved around the different banks. I am using WLA DX and whilst it is an excellent tool for the job I am coming across instances of code and data that are not simple enough to make portable. I would like to ask for the help of a C-programmer to add some new functions to WLA DX in order to solve some portability problems in the code. Here's my first proposal for a new function: ".TABLE": Portable indexes Here's a real-world problem I want to solve: making index numbers used in data, portable. In Sonic 1 SMS each level has a list of which objects (enemies, powerups &c.) appear where in the level. In the ROM a pointer table provides which object index number runs which code. This style of index-based functionality is very common, I imagine in most other games too. How can we add to / remove from / rearrange the object code and function pointer list in the game without making all the level data invalid; pointing to the wrong objects? The current situation is that nobody bothers and just works around the ugly picture. The lists are included as binary and the pointer tables are only appended to. This is not flexible enough for me, especially if I want to head toward providing an editing suite with total-conversion capabilities. My proposal is a new declaration for WLA DX: ".TABLE". First you define the 'columns' of your table using a standard .STRUCT definition. Code (Text): .STRUCT pointerList address: dw .ENDST Here's where the magic happens. Each row has it's own label, this label does not point to the output address of that data, but instead provides the index number of the row. I.e. 'badnick_motobug` = 2 Code (Text): .TABLE objectPointers INSTANCEOF pointerList .ROW badnick_crabmeat DATA $1234 .ROW badnick_chopper DATA $5678 .ROW badnick_motobug DATA $9ABC [...] .ENDT Now in your data statements you can refer to these labels rather than hard values Code (Text): ;list of objects in the level: (object ID, X, Y) .db badnick_chopper, $20, $20 .db monitor_ring, $43, $12 [...] .TABLE is also excellent for data that combines different data types (bytes, words, strings &c.). Currently in WLA DX this quite painful, e.g. Code (Text): .db $FF .dw $1234 .db $80 [...repeat 100 times...] Doing this with .TABLE will be far more elegant and flexible: Code (Text): .STRUCT hypotheticalTableDef first: db second: dw third: db .ENDST .TABLE hypotheticalTable INSTANCEOF hypotheticalTableDef .ROW DATA $FF, $1234, $80 .ROW DATA $11, $5678, $A0 [...] .ENDT .TABLE would also define `_sizeof_[table name]` which will give how many rows are in the table -- perfect for initialising your loop in a flexible, portable way! [hr] I also have a proposal for a block form of .DSTRUCT that will help with self-documentation, but I will post details of this soon. Is there any one out there that would be willing to volunteer their efforts to help?