ouch. I'm not sure I have the desired level to convert the pixels of my SchoolZone to such limited rules yet. Not that it makes GameScript-to-68000 machine code less interesting, but it would require a different art set, for sure.

like 4 palettes for sprites + 4 other palettes for BG ?

On a MegaDrive, you've got 64KB total, but part of it is reserved to tilemaps and SAT (OAM).
https://twitter.com/i_am_sverx/status/970600835561508864

edit: oh, sure you've seen that already. 

indeed but I overlooked the numbers :-/

Please explain what you need to do, we can discuss the thing together

Well, I thought the major barrier would be the CPU speed. I'm running bytecode-based expressions evaluation on the NDS (at 66MHz) and it works correctly, and I expected the need to convert that into native code expressions (thus compiling the former into e.g. 68000 machine code).

But I'm realizing that even the art itself might be over the specs. I loaded 64K of tiles for the playground, almost another 64K for the parallax background and yet another 64K for the sprites. I would have to re-think the art so that it works in 4bpp, first, but even that might not be enough to fit everything into a 16-bit console's video memory, at least not on SNES. I couldn't work with such "static tilesets" on 16-bit. I'd need a strong algorithm to move data between ROM and VRAM, and tracking what will be referenced next and what isn't. And maybe even delaying the transition to an attack move of a monster if the DMA pipeline is already full for this frame. Significant work, thus.

I don't know exactly what you need to do, but the MD is quite powerful. I wouldn't say 50% the GBA, though - that's lower IMHO.
Please explain what you need to do, we can discuss the thing together