DASM is the only non-.NET dependency in the project. Replacing it with a .NET-compatible assembler will be necessary for full portability.

6502.Net looks to be the best candidate to replace DASM with, though it currently targets .NET Framework.

Given the maturity of DASM, it might be best to abstract out how assembly code is emitted. That way we can easily toggle between DASM and an alternative implementation to gauge if everything works right.

Automated tests have been completely neglected and I don't think even compile anymore. Given all the features and optimizations that have been added, it would be very nice to have some tests.

In no particular order:

• negateFromStack with a constant should be done at compile time.

A conventional for loop over a RomData<> works great if its type argument has a size of 1 byte. Larger sizes run into a significant issue with indexing. The address of the data goes from a simple byteData[i] to byteData[i * stride]. The 6502 has no multiplication instructions. Which means we'd have to either resort to very slow ways of calculating it, or add lookup tables to the ROM to aid in calculating the index. Neither are particularly great.

We could also add a method to fetch data by byte offset, and try to encourage the user to use something like i += sizeof(MyType), but that's pretty unfriendly.

Other compilers seem to get around this using a "strength reduction" optimizations that change the loop variable to use addition instead of multiplication, basically what's suggested above. That's nothing like our existing peephole optimizations though, so I imagine it'll be very difficult to add it.

A much more idiomatic option though is to support foreach loops over RomData<> types. A naive implementation would probably be 5 bytes in size (pointer to data, length, index, stride), which is pretty expensive memory and CPU-wise. What we might be able to do though, is use code generation to create specialized enumerables for each specific RomData<>.

For example, take a [RomDataGenerator("FooGenerator")]RomData<UserStruct> foo field, where UserStruct is 3 bytes in size. A code generator could see that and generate a RomData_FooGenerator_Iterator struct. RomData_FooGenerator_Iterator could be generated with a RomData<> field marked with [RomDataGenerator("FooGenerator")]RomData<UserStruct> data. This would give it access to the address, length, and stride as compile-time constants (after optimization). All the struct would need to store then is a single byte for the current index.

Given the complexities of strength reduction, and the potential optimizability of the foreach loop, the latter seems like the much more realistic option right now.

It's essential to be able to read from the cartridge ROM, and there's currently no way to do that.

There are a few options to consider for how to implement this:

• Pointer types (e.g. byte*)
• Array types (e.g. byte[])
• Custom type (e.g. a RomData type)

Actually instructing the compiler to insert data into ROM will most likely be done with a RomDataAttribute. It can be placed on a field of one of the above types, and can accept a byte[] as a constructor parameter. The compiler will then place that data in ROM and set the value of the field to refer to that address. It will be best to enforce that such a variable can never be reassigned, so we can always know what address it points to at compile time.

Performance is critical here given that the ROM will often be accessed inside kernels. A simple LDA with absolute addressing will be best when we can statically determine the address and offset. If we can statically determine the address but not the offset, LDA with absolute indexed is the next best option. If we can't statically determine address or offset, it's probably going to be a mess.

• Throw if a single generator emits more than 256 bytes.
• Throw if a single generator emits more than 256 elements.
• Throw if type argument for RomData<> is non-public (prevents dynamic from working).
• Throw it type containing generator method is non-public (same reason as above, probably have to traverse whole hierarchy tree).
• Throw on 0 elements emitted?
• Throw on RomData<> type being used for local variable or argument.

Logging is a mess and currently consists of a ton of unrelated code just spamming the console, making it very difficult to pick out only the things you care about. We should pull in a proper logging library and redo all of it.

It could be useful to have some rudimentary support for throwing errors at runtime. The errors could be represented by a single color that fills the screen, or an audio tone.

It would be nice to support the throws syntax but it seems unlikely, since you have to throw objects.

Instead, may just want to provide a regular function that has this effect, while leaving memory as untouched as possible (for better debugging).

I'm attempting to build but am getting:

VCSCompiler\Optimizations.cs(7,26,7,42): error CS0234: The type or namespace name 'RomDataUtilities' does not exist in the namespace 'VCSCompiler' (are you missing an assembly reference?)

I've checked the repo and it doesn't seem to exist.

The compiler supports only a subset of the C#, so there are many language features that will never be fully supported. It would be helpful to have an analyzer point out in the IDE if a user tries to use an unsupported feature.