Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Netflix on an NES

gizmodo.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Netflix on an NES

#11

Post by memoryhole »

ericfontaine wrote: post #9
jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

I was wondering if maybe they preconverted the videos into a sequence of tilemaps and a set of approximate tiles. I notice they are only using the same 5 colors, which is under-utilizing the capabilites of the nes which should be able to display a 13 colors at the same time. (Each individual tile uses one palette of 4 colors, and there can be max of 4 palette used at a time, but one background color is shared by all…

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.

Re: Netflix on an NES

#12

Post by ericfontaine »

memoryhole wrote: post #11
ericfontaine wrote: post #9

Earlier quoted context omitted.

I was wondering if maybe they preconverted the videos into a sequence of tilemaps and a set of approximate tiles. I notice they are only using the same 5 colors, which is under-utilizing the capabilites of the nes which should be able to display a 13 colors at the same time. (Each individual tile uses one palette of 4 colors, and there can be max of 4 palette used at a time, but one background color is shared by all…

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 ti…

great hack btw! I'm sure you had limited time to waste!

Re: Netflix on an NES

#13

Post by [deleted] »

JoshTriplett wrote: post #7
jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

> There is no way in hell a 1.79Mhz 6502 can play streaming video. It could play streaming video at a sufficiently small resolution, just not HD or SD.

[deleted]

Re: Netflix on an NES

#14

Post by memoryhole »

ericfontaine wrote: post #12
memoryhole wrote: post #11

Earlier quoted context omitted.

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 ti…

great hack btw! I'm sure you had limited time to waste!

Thanks!

Re: Netflix on an NES

#15

Post by gcirino42 »

ericfontaine wrote: post #12
memoryhole wrote: post #11

Earlier quoted context omitted.

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 ti…

great hack btw! I'm sure you had limited time to waste!

Thanks! Alex had been studying getting better compression by repacking the tiles based on a scheme I still haven't quite figured out, but we were getting CPU --> PPU bound in what we could do during vblank. The MMC3 solution let us basically dma our way around the problems and push a much larger screen update far more often. The original version ripped through playback so fast that we had to slow it down to get a decent number of frames into the available 32 CHR ROM banks (it's a mapper 4 NES rom).

The homebrew community was a fantastic resource! Shoutouts to nesdev, Shiru, and the countless articles we googled!

Re: Netflix on an NES

#16

Post by gcirino42 »

to3m wrote: post #8
jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

"This is really hard to do on a 256K cart" - so I'm guessing it just plays back a little bit of pre-converted video. At that screen size and frame rate this is something the 6502 is fast enough to do. (I don't know enough about the NES to say whether there's some complications I'm overlooking.)

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!

Re: Netflix on an NES

#17

Post by Buge »

frikk wrote: post #5
jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

I agree, it's a neat trick. Especially in How did they get it "online"? I'm assuming that's all built into the "cart"? (wifi?)

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

Re: Netflix on an NES

#18

Post by fuzzix »

jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

> There is no way in hell a 1.79Mhz 6502 can play streaming video.

It can't decode MPEG 4 real time, of course, but machines of this class are more than capable of streaming video.

ZX Spectrum streaming with a network interface (~3.5MHz Z80):

https://www.youtube.com/watch?v=ooi9rpx6ECM

Commodore 64 with lots of RAM (~1MHz 6510):

https://www.youtube.com/watch?v=IXLv7UosQXs

Re: Netflix on an NES

#20

Post by gcirino42 »

frikk wrote: post #5
jandrese wrote: post #4

I'm guessing their "cart" is really a Raspberry Pi like device that is using the NES only for video out and controller in. There is no way in hell a 1.79Mhz 6502 can play streaming video. It's a fun party trick though.

I agree, it's a neat trick. Especially in How did they get it "online"? I'm assuming that's all built into the "cart"? (wifi?)

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.

Post reply on HN