Raspberry pi in a NES cart
Moderator: Moderators
Re: Raspberry pi in a NES cart
Could just set the full set of sprites to a 64x128 pixel block somewhere with a fixed palette and let the extra fetches (since rasteri is already providing data for all the fetches) provide a 3-color overlay.
Makes the quantization logic harder, tho.
Makes the quantization logic harder, tho.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Raspberry pi in a NES cart
A (well, potentially) more dynamic approach somewhere in between those two would be to have a few metasprite objects set to different sizes.
Just winging an example:
2 4x4 sprites
6 2x2 sprites
8 objects, 56 sprites. These are field coverage as if they were bg tiles (mostly?). I think aligning them to a grid would help.
lastly, a number of (low-priority?) stand-alone sprites
8 objects, 8 sprites:
These are for details with higher colour fidelity or where the background and/or field coverage objects are too clumsy.
Get both some block coverage and details; update 16 objects between frames.
Avoids a very squarey block looking more colourful.
Wether to go 8x8 or 8x16, i guess it is a coverage vs complexity balance.
8x16 could either mean larger fields, more details, or something in-between.
I think the bg layer would need to be calculated as if there was no sprite overlay, so it never looks glitchy when sprites get choked by the scanline limit. Then sprites would be applied to fields where the posterization has been the most severe compared to the original frame.
Just winging an example:
2 4x4 sprites
6 2x2 sprites
8 objects, 56 sprites. These are field coverage as if they were bg tiles (mostly?). I think aligning them to a grid would help.
lastly, a number of (low-priority?) stand-alone sprites
8 objects, 8 sprites:
These are for details with higher colour fidelity or where the background and/or field coverage objects are too clumsy.
Get both some block coverage and details; update 16 objects between frames.
Avoids a very squarey block looking more colourful.
Wether to go 8x8 or 8x16, i guess it is a coverage vs complexity balance.
8x16 could either mean larger fields, more details, or something in-between.
I think the bg layer would need to be calculated as if there was no sprite overlay, so it never looks glitchy when sprites get choked by the scanline limit. Then sprites would be applied to fields where the posterization has been the most severe compared to the original frame.
Re: Raspberry pi in a NES cart
It is very noticeable. It doesn't look like a new colour, but like two actually flickering colours, what it actually is.nesrocks wrote:Flickering on a CRT and real NES is practically unoticeable. It is the way to go if you want to simulate more colors.
Re: Raspberry pi in a NES cart
Some 18bit consumer LCD panels use temporal dithering to simulate 24bit color, but they're flickering between two very similar colors - on a NES, the two colors you're flickering between will have a significant color distance, which I think will make it more noticable.
I'm gonna try anyway though. I think I've found an NTSC CRT locally.
I'm gonna try anyway though. I think I've found an NTSC CRT locally.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Raspberry pi in a NES cart
At least you have principally more leeway with hues than with brightness tiers.
Re: Raspberry pi in a NES cart
Good luck! I think it can look very impressive, even if doing distant hue/brightness which makes the flickering noticeable. The tradeoff is totally worth it, especially on busy moving scenes or even full screen animation/video.rasteri wrote:Some 18bit consumer LCD panels use temporal dithering to simulate 24bit color, but they're flickering between two very similar colors - on a NES, the two colors you're flickering between will have a significant color distance, which I think will make it more noticable.
I'm gonna try anyway though. I think I've found an NTSC CRT locally.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: Raspberry pi in a NES cart
Yeah it'd be great if it can be made to work acceptably.
I have another question - how much current can the NES safely supply through the cartridge port? The raspi will use upwards of 200mA and I don't wanna start blowing up people's 5v regulators.
I have another question - how much current can the NES safely supply through the cartridge port? The raspi will use upwards of 200mA and I don't wanna start blowing up people's 5v regulators.
- FrankenGraphics
- Formerly WheelInventor
- Posts: 2064
- Joined: Thu Apr 14, 2016 2:55 am
- Location: Gothenburg, Sweden
- Contact:
Re: Raspberry pi in a NES cart
Not an answer to that, but:
you did use a first-gen rpi before?
Rpi3 (and 2) are relatively power hungry, but rpi zero is both a lot quicker in single-threaded operation than models A+ and B+, while being somewhere in-between A+ and B+ in power consumption. Reference.
you did use a first-gen rpi before?
Rpi3 (and 2) are relatively power hungry, but rpi zero is both a lot quicker in single-threaded operation than models A+ and B+, while being somewhere in-between A+ and B+ in power consumption. Reference.
Re: Raspberry pi in a NES cart
The CPU and PPU draw somewhere around 300-400mA, and there's a 1A regulator on the mainboard. You're likely ok, but I'd worry a little about surge current when you turn things on.
Re: Raspberry pi in a NES cart
That's reassuring.lidnariq wrote:The CPU and PPU draw somewhere around 300-400mA, and there's a 1A regulator on the mainboard.
The raspi doesn't have any huge capacitors on it or anything. If neccesary I'll use an NTC. Or just a resistor, haha.lidnariq wrote:You're likely ok, but I'd worry a little about surge current when you turn things on.
Re: Raspberry pi in a NES cart
You should run a NES emulator on the Pi
Re: Raspberry pi in a NES cart
Haha, don't think I haven't considered that
Another question - I'm considering designing cart PCBs that have an FT232H as well as a small PRG eeprom, to make development easier. I haven't been immediately able to find any decent technical drawings of the cart PCB. Does anyone have one, or even better a premade library for Altium/Eagle/whatever?
Another question - I'm considering designing cart PCBs that have an FT232H as well as a small PRG eeprom, to make development easier. I haven't been immediately able to find any decent technical drawings of the cart PCB. Does anyone have one, or even better a premade library for Altium/Eagle/whatever?
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Raspberry pi in a NES cart
If you're open to giving designspark a try, I've got PCB outline along with my current component library posted in this topic. Should have most of what you're looking for in terms of edge connector, EPROM, SRAM, etc.
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
Re: Raspberry pi in a NES cart
I'm certainly willing to try designspark long enough to steal your dimensionsinfiniteneslives wrote:If you're open to giving designspark a try, I've got PCB outline along with my current component library posted in this topic. Should have most of what you're looking for in terms of edge connector, EPROM, SRAM, etc.
I really just need the board outline and edge connector spacing (which I hear is 2.5mm rather than .1"/2.54mm for some bizarre reason)
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
Re: Raspberry pi in a NES cart
Yes that's true. Interestingly enough, (American) NES is metric pitch, and Japanese Famicom is English/standard (2.54mm pitch). Perhaps it has something to do with the custom design nature of the NES's ZIF connector, where as the famicom used off the shelf 'standardized' female edge connectors.rasteri wrote:I really just need the board outline and edge connector spacing (which I hear is 2.5mm rather than .1"/2.54mm for some bizarre reason)
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers