This is exactly what we did. The video frames were converted to tilesets and stored in the rom image. For playback, the memory mapper (MMC3) is used to swap between the frames without having to rely on too much CPU. Luckily Guy figured out the MMC3, otherwise we'd have only had enough space for a few frames.

Correct as well about the colors. It would have been nice to better utilize them, but we didn't have enough time to do that properly.

You can get even more than 13 simultaneous colours by writing to the palette mid-scanline. With this method it is possible to display all 410 available colours in one frame.

8088 Domination Post-Mortem, Part 1

http://trixter.oldskool.org/2014/06/19/8088-domination-post-...

Hey, I'm Alex, one of the two developers in the video. You are correct, the short video you see is pre-converted and stored statically.

In fact, the original plan we had was to stick a raspberry pi in the cart to handle networking and video conversion. Due to time and resource constraints we ended up building a standalone rom.

and I'm Guy, the other guy ;)

Forgive me, it was a Monday morning when we reshot this. I think the final cart was the original PRGROM + MMC3 / 32 CHRROM banks, so it was probably more like 270k total. The video playback I was commenting on entirely fit into the 256K. In my cursory understanding of the MMC3, I think that's the limit that still fits into a normal mapper 4 and will run on device - I know you can up the PRGROM (add PRGRAM), but that would kill our direct cart --> PPU path for the fast playback.

As for the processor, we were definitely pushing the limit with the design we were coding - we had to back off from glitching quite a bit due to busting the number of cycles we had before PPU. I'm sure we could do better with what we know now, or a lot more assembly tuning, but there was the hard limits on being ready by hackday!

The data used there is cached. We were basically building around having a daughter card handle decoding the video and handling the communication with Netflix servers since there just isn't the memory (and probably not the real time horsepower) to do everything on main CPU. The idea was that an rpi could prime the nametables and communicate via MMC3 style interrupts with the main board, but we wanted to make sure we resisted the temptation of other hacks and simply punch the HDMI jack out of the back of the device and run everything through a primed emulator. We set the rules at "real hardware" and trying to keep true to what you could ship in a cart (though possibly a big one) that a user could put in and play.

Sadly, we had to cut the rpi this time due to time constraints. So we set the data up as if that was doing its job and focused on the current rendering issues and understanding the NES side of things. Hardware interfaces aside (I'm no wiz there), the rpi parts and encoding magic should have been fairly trivial. In the end, we had plenty of CPU cycles left during playback which leave me pretty confident on the rest.

That's not to say we wouldn't have run into some sort of problems with keeping the PPU primed, but we can save that for another (hack?) day.

It's not online. Everything you see was pre stored there.

It's fake