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.
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.