This is great feedback Shiru, thank you!
Shiru wrote:More questions, as I'm trying to get my head around this.
What is the intended way to include constant arrays of data, like level maps? They needs to be larger than 256 entries. Another thing that is often needed is an array of pointers, like when I have level maps as separate arrays and want to make a list of them to access by index.
These needs will be addressed in the next release, 0.5. It will introduce structures, arrays of structures, tables (initialized arrays in ROM), and the address data type (pointer).
Shiru wrote:Is the segments (banks) a must? What if I'll have more than 16K code or data to place into a segment, should I break them between segments manually, or there is/will be a way to put them linearly, if bankswitching is not needed?
The segment sizes are 100% a function of the linker memory map. For NROM you'd just use a single 32KB ROM bank.
Shiru wrote:It is also unclear yet how to interact with the hardware, like NMI and pad polling. I guess that should be done in assembly code, but does it have to be inlined, or could it be done in a separate assembly file?
NMI is handled by the "frame" required subroutine. This subroutine is set as the NMI vector, and includes register push and pop code automatically. If you wanted to implement this vector in a separate assembly file, just export the label as "frame".
Pad polling can be done with the port data type. A port is basically an absolute memory reference, but it's intended purpose is to interact with hardware registers. I am working on an input example now.
Currently you can't interact with code from other assembly files (or even other uc files). This will be addressed in release 0.6 with the import statement.