Raspberry pi in a NES cart

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

I'm having a lot of problems keeping the FT232 synced with the NES. It only has a 1K buffer so it needs to be fed data at least every 300us, and once DOOM and the encoding threads start competing for context switches - not to mention the USB overhead - the display starts getting pretty marginal. I'm going to experiment with RTlinux but I suspect it's not going to help.

Possible solutions I've thought of :

1. FIFO chips - may be difficult to frame sync (I'm using _WR during the vblank as a frame sync)
2. Dual-port RAM - write the entire 40970 byte frame to a (potentially double-buffered) dual port ram and use counters to generate the address lines
3. Try a different USB FIFO such as the Cypress FX2LP.
4. Run another OS - this would involve porting DOOM/SDL/USB stack

I really liked the elegant 1-component simplicity of the USB FIFO solution so I really don't want to try any of those. It's a shame the only suitable high-speed data bus out of the raspi is USB with all its inherent problems. I'm gonna keep trying though.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Raspberry pi in a NES cart

Post by lidnariq »

At least, it's pretty cheap to get your hands on a PCB containing Cypress's FX2LP. It still only has 4 KiB of RAM for buffering... I don't know if needing to send new data to the endpoint 1/4 as often will help enough.
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

lidnariq wrote:At least, it's pretty cheap to get your hands on a PCB containing Cypress's FX2LP. It still only has 4 KiB of RAM for buffering... I don't know if needing to send new data to the endpoint 1/4 as often will help enough.
It's ALMOST fast enough to keep up with a 1KB buffer, so 4x that much might be enough. The FX2LP however is an actual microcontroller requiring code to be written, and I'm already approaching my "silly project time" threshold for this year, so it may have to wait for a couple months so I can afford to eat :)

Actually I have no idea how the FTDI D2XX library handles blocking (source is not available) so it's possible libftdi or just raw libusb might be more efficient.
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

Quick update, I'm still working on getting the FX2 interfaced properly, but I'm very impressed by it overall. It's almost like a tiny very-easy-to-program CPLD, in that it has a state machine that can be triggered using combinational logic from any internal or external trigger. And everything is configured from a GUI which is great for someone like me who's not really a hardware guy.

It seems to me that I could even get controller input via the PPU just by writing to PPUDATA - the FX2 could just read and relay it back to the Pi. No need for any external glue logic at all.

BTW my naive attempts at temporal dithering (i.e. just adding the error onto the same pixel in the following frame) look terrible. I really want to get it working (especially since it saves so much processor time vs. Floyd-Steinberg or my favorite Atkinson dither) so I'll look into rgb121 some more.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Raspberry pi in a NES cart

Post by lidnariq »

You definitely can't propagate the entirety of the error signal when using temporal dithering. It oscillates problematically.

Some years back I played around with a bunch of different dithering techniques, as I was looking into emitting 3 or 6bpp VGA using an FX2. (Never got far enough). I did write a couple of simulators using SDL to play around with different dithering modes, with varying levels of visual quality.

Unfortunately I didn't take notes as to how well each one worked.

I tried the following:
* Propagate 1/3 the error into the pixel to the right, and 1/3 into the pixel in the next frame
* Propagate 3/7 the error into the next frame. On half the scanlines, propagate 1/7 the error each up/down/right; then on the other scanlines, propagate 3/7 error left.
* Just adding stationary uniformly-distributed noise before quantiziation
* 1st-order sigma delta
* 2nd-order sigma delta

The last produced quite nice results, but is probably wholly inapplicable to moving content.
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Raspberry pi in a NES cart

Post by nesrocks »

So, there's this: https://www.youtube.com/watch?v=ar9WRwCiSr0 Any relation?
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Erockbrox
Posts: 397
Joined: Sun Nov 23, 2014 12:16 pm

Re: Raspberry pi in a NES cart

Post by Erockbrox »

In the video the guy says that he needed to kill an original NES cart for the CIC lockout chip. I'm pretty sure that this community has already solved this. The lockout chip for the SNES has been reversed engineered and you can get a chip burned with that code on it making SNES homebrew possible.

Also to the creator of the video, if you can get a board made where it is easy to hook up the raspberry pie to it I would love to make an NES game with an enhancement chip!

I don't know if you can increase the sprite number or whatever but if you can make very advanced NES games that would be something cool to see.
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

Decided to come back to this project, after learning a bit more about the FX2LP and USB in general.

Got frame sync near-100% stable now.

I was wondering about music - I've seen PCM demos for the NES but I'd (probably) need another FX2LP to stream data in and out of the CPU bus.

Maybe the thing to do is make funky 2A03 chiptune versions of the DOOM soundtrack, haha :) That would be fun.

Vid here - https://www.youtube.com/watch?v=FzVN9kIUNxw
User avatar
za909
Posts: 248
Joined: Fri Jan 24, 2014 9:05 am
Location: Mijn hart woont al in Nederland

Re: Raspberry pi in a NES cart

Post by za909 »

rasteri wrote:I was wondering about music - I've seen PCM demos for the NES but I'd (probably) need another FX2LP to stream data in and out of the CPU bus.
If you want to keep the NES unmodded, try to drive the IRQ line with your external hardware and put the pre-mixed sample for the DAC on a memory-mapped I/O port. To cut the overhead of the IRQ for the NES as short as possible, reading the port should also acknowledge the IRQ and reset whatever time you use to generate the IRQ signal. Make the NES do as little as possible. If the console isn't doing a whole lot, you can expect to get a rate of at least 22kHz.
It's a lovely project so far, though I wonder if the NES itself could run a game that would make use of the Pi for graphics processing only?
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

za909 wrote:try to drive the IRQ line with your external hardware and put the pre-mixed sample for the DAC on a memory-mapped I/O port.
Yeah this is sounding like more work than I really have time for :( Perhaps someone else can do it when I open-source this project (which I will do).

I did a test arrangement of E1M1 in famitracker, it sounds pretty nice IMO : https://www.youtube.com/watch?v=c9Ky79Wpg7o
It's a lovely project so far, though I wonder if the NES itself could run a game that would make use of the Pi for graphics processing only?
I don't see any reason why not.
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

So this is basically stable enough to release now.

Source code and build guide can be found here : https://github.com/rasteri/PiPU

It's still quite basic, and every part of the project could be improved massively, but I'm unlikely to have any more time to work on silly projects until next year.

If anyone feels like tinkering with the code, let me know if you need help setting up a dev environment.

I've also made a video explaining how everything works : https://www.youtube.com/watch?v=gCWhWBtu0LA
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Raspberry pi in a NES cart

Post by tokumaru »

Very cool! Now, you say this is limited to 13 colors on screen at once, but since you're ignoring the address bus, shouldn't it be possible to update a number of consecutive palette entries every hblank, improving the quality of images with more vertical color distribution? Sure this would complicate the graphics conversion process (for each scanline you could maybe pick the least used palette, or the one that caused the most coloring errors, and have it recalculated for the next scanline), and increase the amount of palette data that needs to be sent to the console, but it'd be interesting to see.
rasteri
Posts: 16
Joined: Sat Dec 09, 2017 6:30 pm

Re: Raspberry pi in a NES cart

Post by rasteri »

tokumaru wrote:Very cool! Now, you say this is limited to 13 colors on screen at once, but since you're ignoring the address bus, shouldn't it be possible to update a number of consecutive palette entries every hblank, improving the quality of images with more vertical color distribution?
That would be very cool. Feel free to implement it :) Or maybe I will some day.

How many palette entries could be updated each hblank?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: Raspberry pi in a NES cart

Post by lidnariq »

Since you don't need to restore scroll, you should be able to update one or two (sequential) palette entries every scanline.

0) Write $3F to $2006 early (0 cycles)
1) preload A,X,Y (0 cycles)
2) Write $0 to $2001 to disable rendering (ideally landing on exactly dot 255/6/7) (≈1 cycle during hblank)
3) Write [palette index] to $2006 (4 cycles)
4) Write new color to $2007 (4 cycles)
5a) register pressure (2 cycles maybe)
5b) Write new color to $2007 (4 cycles)
6a) register pressure (2 cycles maybe)
6b) Write $0A to $2001 to re-enable rendering (4 cycles) - must be no later than dot 319. This just barely leaves room for two "register pressure" moments and two new (sequential) colors (1+4+4+2+4+2+4)
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: Raspberry pi in a NES cart

Post by zzo38 »

It is possible with the cartridge that you can then get all points addressable, with 8x1 areas of colours (rather than 16x16). (I guess it does this already.)

On Famicom, you could also use Raspberry pi for audio, too, probably (you could also combine this with 2A03 audio if wanted). And then, (on RF Famicom only) you can also use the microphone with it.

For a game using sprites with additional colours you might also add a 6502 code to set up the sprites, in addition to audio (if used) and controller (including even 2-players and whatever else might be in use; such as, if using a light gun then it can include a code to transmit the hit test data).

I looked at the existing codes; it is a C code, although an assembly code would also do, I think. (Even a game could be made that uses both logic together, somehow.)
(Free Hero Mesh - FOSS puzzle game engine)
Post Reply