Banshaku wrote:The goal is to try to get as close that I can from the original with the current assets and color is one of the many issue with it

I guess that the parallax in the buildings was the first thing to go!
So success/failure is different in this project since it's a tentative re-creation of what Danilo's did. If it fails then oh well, it fails and will figure out something.
Well, he obviously didn't care for the actual limitations of the system when making that, he just went with the typical "NES feel" pixel artists seem to love so much (which is basically "4-color areas", but everything else is game), so it's no surprise that the conversion process isn't exactly going smoothly.
As for testing on hardware, I just made that quick port based on my current engine and it proved that it's possible to adapt it to something else, which is good, so I didn't test it yet. I guess I should try it soon.
These things that mess with the PPU during rendering are always problematic, and emulated with varying levels of accuracy, so it's best to check on hardware ASAP so you don't end up making decisions based on misleading test results.
As for the sprites, I wasn't aware of that so that may become a reason that I will have to drop it in the end, if it glitches too much

Yeah, the PPU is always processing sprites and backgrounds in parallel, and it evaluates sprites one scanline in advance, so if you interrupt that evaluation, at the very least you'll end up with no sprites for one scanline.
For glitching OAM, wasn't aware of that too so I should be careful then.
The type of RAM used for OAM is DRAM (Dynamic RAM), which needs to be refreshed (read and written back) constantly or it loses its contents, and turning rendering off can interrupt the refresh process that the PPU is constantly doing, so when you enable rendering again this process resumes and may end up writing back values to the wrong memory positions. This is particularly nasty because it can even corrupt sprites on the *next* frame, if you happen to disable rendering near the end of the frame for some extra VRAM access time, even if you do an OAM DMA during vblank, since the corruption happens when rendering resumes, which's after the DMA, in the beginning of the next frame.
Anyway, feel free to keep trying to come up with something usable, I was just pointing some of the things you have to look out for.