NES to RS-232

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderators: B00daW, Moderators

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Refining design for really low-cost devcart

Post by thefox » Fri Jul 30, 2010 3:48 am

In [url=http://nesdev.com/bbs/viewtopic.php?p=65113#65113]this post[/url], blargg wrote:To allow programming, we're making cheap serial interface cables for the NES, with the NES implementing the UART in software. The basic design uses a MAX232 or equivalent to convert between the NES 5V and RS232 +/-12V signals. An alternate design uses an FTDI TTL-232R cable which has a USB connector on one end, and bare wires on the other with 5V serial signals. While more expensive, the cable can be made by literally just splicing it to a NES controller cable. With some heat-shrink tubing, such a cable would look very elegant. :)
Can you (or somebody else) enlighten me a little how this would work in practice. Are the RTS# and CTS# signals of the TTL-232R used at all? (What are those signals used for?) Also is the NES controller "CLK" used?

I really would like to buy a NES<->USB cable like this or make one myself. So many cool applications when used together with PowerPak.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Jul 30, 2010 4:49 am

No, currently flow control isn't used (the NES has only one output, unfortunately... maybe that could be used as CTS and Tx). byuu is donating an FTDI cable to me in a few days, so I'll know for sure how well they work out. In theory, you just connect GNDs together, NES strobe out to Rx on the FTDI, and NES D0 to Tx on the FTDI. Three splices you could do with just a pair of scissors and some houshold tape, if you had to. That's why despite the cost of the FTDI cable, I believe it has many advantages for cheap construction by anyone. Props to byuu for discovering this cable in the first place.

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Post by thefox » Fri Jul 30, 2010 5:08 am

blargg wrote:No, currently flow control isn't used (the NES has only one output, unfortunately... maybe that could be used as CTS and Tx). byuu is donating an FTDI cable to me in a few days, so I'll know for sure how well they work out. In theory, you just connect GNDs together, NES strobe out to Rx on the FTDI, and NES D0 to Tx on the FTDI. Three splices you could do with just a pair of scissors and some houshold tape, if you had to. That's why despite the cost of the FTDI cable, I believe it has many advantages for cheap construction by anyone. Props to byuu for discovering this cable in the first place.
Ok thanks. Let me know how your tests go. I ordered the FTDI USB cable a second ago so I'll probably test some stuff myself also.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Jul 30, 2010 7:40 am

Here's a super-cheap interface I just built. Works so far at 57600 bps with one serial port I've tested it with. You can of course build both to get bidirectional data transfer. The serial port I tested with outputs about +/-5V signals. The NES-to-PC output only goes down to about -2.6V, which isn't quite to spec, but it works so far. The diodes and transistor are common-variety small-signal.

Image Image

Mods: please split theFox's question and our exchange after that into a separate thread about PC to NES serial interfaces. Thanks.

arfink
Posts: 64
Joined: Fri Apr 28, 2006 7:07 pm
Location: MN, USA

Post by arfink » Fri Jul 30, 2010 9:46 am

I think for my serial cable I'll be using the MAX232 because I want to use it with some hardware that is certainly outside the correct voltage range and has a tendency to get a bit finicky if it doesn't get the expected voltages returned either.

The schematic Blargg posted will probably work fine with 90% of PC serial ports, but I'd personally be careful using it with other serial sources such as vintage computers etc. because of the differences in adherence to RS232 between hardware platforms then and now.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Jul 30, 2010 9:48 am

Cool, flow control is actually working. I just made a duplicate circuit like the NES-to-PC one above and hooked that to CTS, and am able to have the serial receive run with as much delay as I want between bytes without losing any. The host gets garbage bytes in return, but it can just discard those or wait for a header if receiving any data from the NES afterwards.

I also found a page saying that modern serial ports accept 0V and +5V as the two levels, rather than requiring a negative voltage, so the transistor driver above might not even be necessary.

The next step is to try this on a USB-to-RS232 adaptor, and the built-in serial on a different PC, see whether it's just this computer's serial that happens to like this arrangement.

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Fri Jul 30, 2010 10:01 am

What is the practical limit for receiving on a NES? Is 115200 possible at 15.5 cycles / bit? It might be time for me to lose the LPT solutions if everyone jumps on RS232 :P

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Jul 30, 2010 10:59 am

Ahhh, the problem with the higher rate was the lack of time between receiving bytes to process them. This flow control addition might make that possible now! Dusting off the old 115200 routines again...

EDIT: Argh, running into problems with flow control even at 57600. Trying to make sense of the problem. So maybe flow control won't work.

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Fri Jul 30, 2010 2:04 pm

I read that 3% tolerance is common with UART; at 115200 baud on the NES you're you are closer to 4% fast or slow transmitting.. I wonder if this is a significant problem. Timing can be modulated for correct baudrate but the skew would probably throw off the receiver more than the off frequency.

Here's an output routine for 115200 using 16 cycles / bit (111861 baud):

Code: Select all

jsr here    ;6
ldx #9      ;2
asl a       ;2 - 10
loop:
sta $4016	;4
lsr a	    ;2
sta zpg_garbage ;3
sec	      ;2
dex         ;2
bne loop    ;3 - 16*9+15
rts         ;6 - 175 cc total

arfink
Posts: 64
Joined: Fri Apr 28, 2006 7:07 pm
Location: MN, USA

Post by arfink » Fri Jul 30, 2010 2:17 pm

Well, I'm kinda clueless about how best to handle serial communications. The best I can do with serial is vintage computer stuff, and most of my gear actually tops out at 19200 baud.

tepples
Posts: 22087
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Fri Jul 30, 2010 2:26 pm

Are there USB to SPI-slave adapters? The clocked-serial protocol for NES controllers and Game Boy Game Link looks a lot like SPI. Connect SCLK to clock, MOSI to strobe, MISO to D0, and /SS to a one-shot multivibrator from strobe.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Fri Jul 30, 2010 2:31 pm

A big benefit of using serial (even if just a USB-serial adaptor) is that the host-side drivers use a well-worn protocol. You don't have to mess with special drivers or communication models when using serial, so it's easy to port to different operating systems. That's not to say you couldn't have a microcontroller with a USB interface to the PC acting like a serial device, but giving the NES a clocked interface (maybe that was your point). If someone wants to release such a cable for the NES, please do!

User avatar
kyuusaku
Posts: 1665
Joined: Mon Sep 27, 2004 2:13 pm

Post by kyuusaku » Fri Jul 30, 2010 2:52 pm

If anyone wants to step back to LPT days, I have a clocked-serial solution (4-bit I/O w/ handshake) that will fit into a 20 pin GAL/PALCE/PEEL chip (or probably 4x 74 series chips). I believe it can achieve approximately 16KiB/s but haven't bothered to build it. Surely a USB MCU is more convenient, but neither the software nor firmware will exactly be a breeze.

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Sat Jul 31, 2010 6:43 am

OK, now that I'm using something more normal for RS-232 (was using my old Mac, with its RS-485 ports or whatever it has), flow control is working well. This USB adaptor (based on the PL2303) accepts 0 and +5V signals, so no driver transistors are even needed. Now, to try 115200 again.

EDIT: Sweet, 115200 with flow control is working great for the initial tests, and there's plenty of margin for timing error (I can add/subtract around 7 cycles between the start bit detection and the data bit reads before it gets errors).

EDIT: And passes the 4K random data receive test. 115200+flow control is where it's at!

EDIT: I found that on my old Mac, when you deassert CTS, it sends 13 more bytes before it stops! This would explain the problems I had with it. I'm thinking this can be worked around on the NES side, by being ready to buffer a few more bytes after deasserting CTS. Going to try implementing that without lots of overhead.

EDIT: Works. Even with the host sending an extra 13 bytes after deasserting CTS, this doesn't lose any bytes, and the processing code can take as long as it likes. This can handle the host sending up to 255 extra bytes, which is probably more than anything sends after you tell it to stop.

hyarion
Posts: 164
Joined: Tue May 05, 2009 6:12 pm
Contact:

Post by hyarion » Sun Aug 01, 2010 12:34 am

i might add in that i've designed a Console <->USB adapter (~5.5x2.5x3cm box + cables) which uses serial communication with the console and communicates with the computer with a ft232 chip (to make it as robust and cross-platform as possible).

IIRC it should be able to transceive a byte in ~185 cycles, so it should be possible to make it quite fast. it should also be capable of being interrupted by DPCM every now and then without it interfering with the communication.

would anyone be interested in such a device?
Last edited by hyarion on Sun Aug 01, 2010 4:22 am, edited 1 time in total.

Post Reply