While I'm quite enamored with the idea @zce came up with for a hardware-customizable fantasy console, it's… uh… very ambitious to say the least. I think I'm going to try writing a more standard console first and see how that turns out. I'm planning stuff out, so far I'm figuring out Lua integration and its flavor of assembly.
The asm is probably going to be a hybrid of the Game Boy DMG and the TI-99/4A since I'm most familiar with those two consoles, but the asm will be without both of those CPUs' downsides.
Looking at how Lua works when integrating into C, I'll probably be able to follow through with my plan to "downclock" Lua to force using asm for performance bottlenecks or for high performance games
Graphically I think I'm going to have 4 layers to draw on: a background layer, a sprite layer, a "vector" layer, and possibly a "window" layer. I'll have the sprites and vector layer be mutually exclusive, so you can use one or the other. The background will obviously be behind, and the "window" will act like a foreground layer that can be used to have stuff cover sprites, mask out stuff, etc.
For the vector layer, I think I'll go with the "Vectrex" style where you have a beam that you can move to whatever point on a grid you want, and you can set flags to have it be off (
00), on - thin (
01), or on - thick (
@zce I don't want to reimpliment the entirety of Lua in assembly (and I want it to be more integrated into the core). But, in a Lua engine it lets you register function callbacks, so I could reimplement the portions of the Lua stdlib in assembly (I'd also let me restrict the stdlib how I want). I could also replace any builtins with assembly equivalents.
I know it sounds like I'm basically reimplementing the language at that point, but I don't have to implement a lexer or parser which is the biggest gain I can think of in terms of "I will avoid writing those myself at all costs"
masto instance for the tildeverse