It is currently Sun Nov 18, 2018 10:42 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 37 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: 11
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 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7720
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: 11
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: 11
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 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7720
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: 310
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: 274
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  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 37 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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