It is currently Fri Nov 15, 2019 4:11 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Wed May 29, 2019 9:10 am 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
To avoid wearing out the cartridge connector on my console, I'd like to be able to feed it test programs without having to swap cartridge over to my INL programmer every time I want to test something. Using a self-flashable Mapper 30 board, it would seem like it should be simple to use an FTDI "UART" cable to feed data to the NES which could then program such information into flash using either a joystick port or a connector plugged into the expansion connector. Has anyone else done such a thing? Would anyone have any suggestions as to how best to make the connection?


Top
 Profile  
 
PostPosted: Wed May 29, 2019 9:53 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 587
Location: Poland
You can use OuT0 and one or more of the data pins to build bidirectional serial connection between PC and NES.

Have in mind that joypad side can only force low on state on $4016-D0/3/4 and $4017-D0/3/4 (as a result of presence of diodes, at least in PAL version), while they're pulled up by 10k resistors inside NES. Plus the presence of 330p caps to ground limits rising edge speed on those pins and thus maximum PC->NES transfer ($4016-D2 and $4017-D2 which are present only in the EXP connector does not have that limitation)


Top
 Profile  
 
PostPosted: Wed May 29, 2019 11:38 am 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 632
Location: Central Illinois, USA
supercat wrote:
To avoid wearing out the cartridge connector on my console, I'd like to be able to feed it test programs without having to swap cartridge over to my INL programmer every time I want to test something. Using a self-flashable Mapper 30 board, it would seem like it should be simple to use an FTDI "UART" cable to feed data to the NES which could then program such information into flash using either a joystick port or a connector plugged into the expansion connector. Has anyone else done such a thing? Would anyone have any suggestions as to how best to make the connection?


The programmer for Memblers' GTROM dev kit uses a usb serial to NES controller port cable. There's a bootloader on a modified game genie that listens for an upload on the controller port, and writes the data to the cart. It works well, but it's pretty slow if you're uploading a large game.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
PostPosted: Wed May 29, 2019 4:17 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3756
Location: Indianapolis
Other chips that should work:
PL2303 (depending on the chip version, in Windows you may have to install and manually select some older drivers)
CP2102
CH340

If you buy a "USB to TTL" adapter on ebay, aliexpress, etc., it will come with one of those and you can find some that come in a plastic USB housing that opens up easily (with an x-acto knife, spudger, or whatever's thin). For the the NES to USB adapters, I solder NES extension cable to it, and drill out the strain relief so it fits the NES cable, it comes out looking pretty good. OUT0 as NES transmit, D0 as NES receive, GND, leave 5V disconnected (it has a 5V connection but at least on the PL2303 boards I know it's intended as a supply rather than input).

The Cheapocabra devkit uses a Game Genie, with it's firmware replaced with a bootloader. It's EPROM but supports software updates by allowing the bootloader to load another bootloader. into NES internal RAM or cart Flash. It's XMODEM at 19200 baud, so it really slow. The NES can definitely do 57600 and even 115200. blargg has used those speeds before too, as well as made a really impressive bootloader (I wanted to use it, but sometimes blargg's stuff is too clever for me to easily understand, I went with what worked). And thefox made a loader for the PowerPak that also transfers at 115.2k. It's pretty nice because it loads the mapper file too.

I wrote some code that "interleaves" 115.2k receive with SST39SF040 programming. There are very few idle cycles between bits at 115.2k, but there is enough.. potentially making a Flash cart about as fast as a RAM cart. What I haven't done though is write out the protocol that uses it. I also hoped to put some kind of fletcher checksum thing for every byte received, just not sure if it can be fast enough (using 2 stop bits would help, but would transmit slower). So I figured it's probably best to have it just receive and write, and check it on a bank boundary, or when it's fully done.

I also came up with some IRQ tricks that help with 115.2k receiving. Frame IRQ and DPCM IRQ can be used for both short and long timeouts. At that speed, there isn't enough time to exit the polling loop when you wait for the start bit, so the timeout IRQ prevents an infinite loop. When data starts coming in, it switches to a short timeout, so when the data stops coming, it wastes less time waiting.

I could post code for that stuff, it's free to use if it's useful. I've intended to do that eventually, just haven't cleaned it up and haven't finished the most interesting parts of it.


Top
 Profile  
 
PostPosted: Thu May 30, 2019 1:09 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 992
Apparently you can solder an USB port to the Everdrive N8.


Top
 Profile  
 
PostPosted: Fri May 31, 2019 5:28 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 466
calima wrote:
Apparently you can solder an USB port to the Everdrive N8.


Actually, you can get it pre-soldered on the Everdrive N8 at no extra cost if you ask nicely when placing your order. Or well, that worked for me when I ordered mine around 2 years ago.

The USB feature is indeed awesome and transfers both NES and FPGA bitfile in seconds. Though for extensive FPGA debugging, I've found the Powerpak to be more convenient, just because it connects all the EXP pins to the FPGA and allows hooking them up to a logic analyzer. So I tend to switch between the Everdrive/Powerpak depending on whether I'm doing 6502 or Verilog...


Top
 Profile  
 
PostPosted: Fri May 31, 2019 5:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7629
Location: Canada
IIRC someone (thefox?) made a patched PowerPak menu ROM that listened for data on the controller 2 port, and sent ROMs across that way.

CopyNES also lets you attach USB to your NES, but it's a pretty hefty mod job.


Top
 Profile  
 
PostPosted: Sat Jun 01, 2019 4:05 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1051
Bananmos wrote:
The USB feature is indeed awesome and transfers both NES and FPGA bitfile in seconds.

I don't like seconds too much... How slow/fast is that in kbytes per second?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Wed Jun 05, 2019 3:22 pm 
Offline

Joined: Thu Apr 18, 2019 9:13 am
Posts: 161
Memblers wrote:
If you buy a "USB to TTL" adapter on ebay, aliexpress, etc., it will come with one of those and you can find some that come in a plastic USB housing that opens up easily (with an x-acto knife, spudger, or whatever's thin). For the the NES to USB adapters, I solder NES extension cable to it, and drill out the strain relief so it fits the NES cable, it comes out looking pretty good. OUT0 as NES transmit, D0 as NES receive, GND, leave 5V disconnected (it has a 5V connection but at least on the PL2303 boards I know it's intended as a supply rather than input).

I wrote some code that "interleaves" 115.2k receive with SST39SF040 programming. There are very few idle cycles between bits at 115.2k, but there is enough.. potentially making a Flash cart about as fast as a RAM cart. What I haven't done though is write out the protocol that uses it. I also hoped to put some kind of fletcher checksum thing for every byte received, just not sure if it can be fast enough (using 2 stop bits would help, but would transmit slower). So I figured it's probably best to have it just receive and write, and check it on a bank boundary, or when it's fully done.

I also came up with some IRQ tricks that help with 115.2k receiving. Frame IRQ and DPCM IRQ can be used for both short and long timeouts. At that speed, there isn't enough time to exit the polling loop when you wait for the start bit, so the timeout IRQ prevents an infinite loop. When data starts coming in, it switches to a short timeout, so when the data stops coming, it wastes less time waiting.

I could post code for that stuff, it's free to use if it's useful. I've intended to do that eventually, just haven't cleaned it up and haven't finished the most interesting parts of it.


Sounds interesting. Any data that arrives while an interrupt is being serviced is going to get missed, so I was thinking of using a protocol based on packets that start with e.g. 00 00 01 and end with 00 02. Code which is looking for a zero byte won't mis-identify it as anything else; if code is willing to accept a packet which is preceded by either 00 00 01 or 00 01, and resets a DPC-based timeout whenever it sees anything that looks like it might be data, that should avoid the possibility of an IRQ hitting in the middle of a packet.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

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