wondering how smb3 would look like on msx1

Nice!
but i should redraw all gfx these are converted and not fitting wel

what Huey said. + welcome to this forum.
And I hope you like Z80/MSX development, it's fun to work with retro architectures.

Thks, for the support

I had a real msx1 back in the 80's in Brazil. Now I live in Canada and I'm a professional game programmer. I've made some PS3 and Iphone games so far. But I always had the memories of my good old msx and I decided to make something during my commute time

I was thinking in giving screen 4 smooth scroll support, but for that I'll need to use splitscreen. The problem with splitscreen is I'm gonna make intensive use of sprites, I'll be transferring ROM sprites to VRAM all the time. I can't do it in the vsync interrupt, it's is already doing the multiplexiing and screen flush. But if I transfer to VRAM during the gameloop I could miss a splitscreen interrupt when DI, right ? We have 32 visible sprites and we do have room for 64 of them in VRAM, so it's a double buffering I'll be updating the sprites all the time, switching the banks to avoid visible glitches. Yes, it's going to flick a lot when using more than 4 in a row, but who cares, betther than a monochromatic Mario. Also, when switching to screen4, we have extra 16-bytes for each sprite to multiplex too.

Any suggestions ?

you mean not multiplexing from ISR ?
Mario has lots of sprites, also, I need to flip the sprites according to its direction. Mario has 3 colors, thus 6 16x16 sprites only for Mario. Some Mario poses have even more sprites like when kicking the koopa's shell or flying with racoon mario. I'll have to limit the number of enemies on screen, support at maximum 2 fireballs, etc. It's not easy. I'll be copying from ROM to VRAM when the pose or flip changes.

ASCII8 give us lot of memory, so I'll keep the normal and flipped sprites in ROM instead of flipping it in assembly. That could be very expensive, flipping 16 16-bit numbers for 32 sprites in worst case.