@jlun2: I fixed the cart RAM domain in GBHawk so your lua script should work now, please retest and let me know if everything is good.
This was unique / troublesome enough that I decided to write down the technically details, anyone interested can read on.
This was actually a pretty weird case that shows how important it is to watch out for garbage collection in managed code in C#.
What went wrong is here:
var CartRam = new MemoryDomainByteArray("CartRAM", MemoryDomain.Endian.Little, cart_RAM, true, 1);
This function takes the whole of cart_RAM as an argument and used in an assignment :
Data = data (where data is cart_RAM in this case.
Data has a setter:
public byte[] Data
{
get => _data;
set
{
_data = value;
Size = _data.LongLength;
}
}
_data is another byte array that is internal to the memory domain.
Internally, this assignment is an assignment by pointer. _data gets a pointer to cart_RAM, even though it doesn't look like it.
In c++, this would be what you want and expect. But in C#, the underlying domain cart_RAM can be moved without you knowing, in an attempt to manage memory for you.
From here on is somewhat speculative, but what I THINK is happening is that memory management moves cart_RAM, but the original copy can't be deleted because their is a pointer to it. So you get left with a stale copy of cart_RAM that the memory domain points to while the actual cart_RAM array getting updated as it should.
This, is super annoying. The solution is to just use the delegate method of defining domains that doesn't rely on a pointer internally. The weird thing is that other cores (ex NESHawk) use this method of defining memory domains by default and I've never seen a case where this has happened before. Probably it should be used for static arrays only (or not at all if it's just going to leave a stale copy clogging up memory.)
Here is one of the best homebrew games for the O2 that is now finally working in BizHawk. This is one of those games that relies on a lot of hardware edge cases and revealed several bugs in the core.
Kill the Attacking Aliens uses some non-intuitive properties of quads to get some really detailed graphics effects that are unique to this game. It's one of those impressive homebrews that could really have helped define a system if it had come out in it's actual lifetime.
This is probably one of the few O2 games that really would be interesting to TAS, so I'm glad it's looking correct now.
I took some time today to redo the vectrex display algorithm. It now looks MUCH better. It's a bit slower now, but I think it's worth the great increase in display quality.
Getting that characteristic vectrex glow is still really hard though, I think this is as good as I can get for now.