It is currently Sat Oct 19, 2019 3:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Thu Dec 21, 2017 10:02 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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.


Top
 Profile  
 
PostPosted: Thu Dec 21, 2017 11:33 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8620
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Thu Dec 21, 2017 4:28 pm 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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.


Top
 Profile  
 
PostPosted: Wed Jan 03, 2018 5:41 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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.


Top
 Profile  
 
PostPosted: Wed Jan 03, 2018 1:01 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8620
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed May 30, 2018 12:55 pm 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 419
Location: Rio de Janeiro - Brazil
So, there's this: https://www.youtube.com/watch?v=ar9WRwCiSr0 Any relation?

_________________
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!


Top
 Profile  
 
PostPosted: Sun Jun 03, 2018 12:07 am 
Offline

Joined: Sun Nov 23, 2014 12:16 pm
Posts: 307
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.


Top
 Profile  
 
PostPosted: Tue Jun 04, 2019 10:36 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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


Top
 Profile  
 
PostPosted: Tue Jun 04, 2019 1:01 pm 
Offline
User avatar

Joined: Fri Jan 24, 2014 9:05 am
Posts: 193
Location: Hungary
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?


Top
 Profile  
 
PostPosted: Wed Jun 05, 2019 12:48 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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

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


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 6:21 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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


Top
 Profile  
 
PostPosted: Wed Aug 28, 2019 7:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11416
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Aug 29, 2019 3:40 am 
Offline

Joined: Sat Dec 09, 2017 6:30 pm
Posts: 15
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?


Top
 Profile  
 
PostPosted: Thu Aug 29, 2019 11:51 am 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8620
Location: Seattle
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)


Top
 Profile  
 
PostPosted: Fri Aug 30, 2019 2:57 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 1042
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.)

_________________
.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 45 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: MSN [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group