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.