In regard to
this and some other threads I can't bother finding right now.
I have written (quite some time ago actually) software to transfer iNES roms from PC over the controller port serial cable to PowerPak without the need to swap the CF card every time. The software is based on blargg's (not yet released) NRPC library/bootloader concept and currently is available for Windows only but the source uses boost and is cross platform. I'll release the source after blargg releases NRPC (which might take a while since blargg hasn't been very active lately).
So far I've only tested it on my PAL NES. Is there anybody out there with the serial cable and a PowerPak that could test it on NTSC NES for me? More PAL testers would also be helpful to verify it works reliably.
Download:
http://kkfos.aspekt.fi/downloads/pc2nes-v01.zip
Are these serial cables for sale anywhere that would ship to the United States, or would I have to solder?
tepples wrote:
Are these serial cables for sale anywhere that would ship to the United States, or would I have to solder?
Yeah you'd have to solder, I don't think anybody sells them at the moment. AFAIK arfink might start selling them if/when Munchausen (the MMC1 flash cart) is ready. For my cable I used
FTDI TTL-232R-5V-WE so soldering was easy.
I'd be happy to build and test this for you on an NTSC top-loader, but I'd need an accurate wiring diagram. The closest I can find
is this, but I have no idea if that's the correct diagram or not (I'm also not sure what upload vs. download means in that specific context).
Basically I need:
1) A diagram that shows me what on the TTL-232R-5V-WE cable (specifically GND, CTS, VCC, TXD, RXD, and RTS) connects to on the NES controller port,
2) Exactly what parts are needed (I see some resistors in the diagram that may or may not be accurate),
3) Some place that sells NES controller plugs (the male end) to either raw wires or solder-friendly terminals.
This will come in handy I'm sure, but the Wiki doesn't appear to list any vendors who sell controller port connectors (male or female). Worst-case scenario I can find someone selling an old NES controller, but I imagine I'll get gouged on shipping.
I should note that with regards to #3, I do have a
RetroUSB NES adapter if that could be used (I do not wish to destroy it, however).
(Also, what the heck is with that "KHAN strikes again" crap at the top of RetroUSB? It almost looks like someone hacked the site but it could be bunnyboy having fun. ;-) )
thefox wrote:
... I'll release the source after blargg releases NRPC (which might take a while since blargg hasn't been very active lately).
Sorry to add a second reply, but I wanted to mention that there's some speculation as far as why he's not around any more. I actually have blargg's contact info (since he's a Parodius user); if people start getting worried, let me know and I can send him personal Email and/or give him a call.
http://nesdev.com/bbs/search.p ... hor=blargg
Blargg hasn't posted since 2010-11-29. I would like to know if he's ok. Koitsu, its been almost three months. If you can contact him, please try.
koitsu wrote:
(Also, what the heck is with that "KHAN strikes again" crap at the top of RetroUSB? It almost looks like someone hacked the site but it could be bunnyboy having fun.
)
Khan Games - Kevin Hanley, Released Sneak 'n Peek.
WhatULive4 wrote:
koitsu wrote:
(Also, what the heck is with that "KHAN strikes again" crap at the top of RetroUSB? It almost looks like someone hacked the site but it could be bunnyboy having fun. ;-) )
Khan Games - Kevin Hanley, Released Sneak 'n Peek.
Oh! *laugh* I hadn't been to their Homebrew section in a while. It would probably do bunnyboy good to turn the text into a link to the product item then. :-) I wonder if the Khan reference is in direct relation to the character in Sneak 'n Peek looking like Spock...
clueless wrote:
http://nesdev.com/bbs/search.php?search_author=blargg
Blargg hasn't posted since 2010-11-29. I would like to know if he's ok. Koitsu, its been almost three months. If you can contact him, please try.
I'll do what I can.
koitsu wrote:
I'd be happy to build and test this for you on an NTSC top-loader, but I'd need an accurate wiring diagram. The closest I can find
is this, but I have no idea if that's the correct diagram or not (I'm also not sure what upload vs. download means in that specific context).
That diagram is for a cheap interface, you don't need it if you use TTL-232R-5V-WE. I think upload means PC->NES.
Quote:
1) A diagram that shows me what on the TTL-232R-5V-WE cable (specifically GND, CTS, VCC, TXD, RXD, and RTS) connects to on the NES controller port,
From my notes:
Code:
FTDI (PC) side:
black = GND
brown = CTS#
red = VCC
orange = TXD
yellow = RXD
green = RTS#
NES side:
white = VCC
orange = strobe (NES->PC)
red = clock
brown = GND
yellow = Din (PC->NES)
NES strobe to FTDI RXD -> NES orange to FTDI yellow
NES Din to FTDI TXD -> NES yellow to FTDI orange
GND to GND -> NES brown to FTDI black
Note that the wire colors are from an euro area controller! They might not be the same in U.S. controllers, let alone expansion cables.
Quote:
2) Exactly what parts are needed (I see some resistors in the diagram that may or may not be accurate),
For TTL-232R-5V-WE you only need to splice a NES controller cable with it.
Quote:
3) Some place that sells NES controller plugs (the male end) to either raw wires or solder-friendly terminals.
This will come in handy I'm sure, but the Wiki doesn't appear to list any vendors who sell controller port connectors (male or female). Worst-case scenario I can find someone selling an old NES controller, but I imagine I'll get gouged on shipping.
That's a tougher one, I figure a 3rd party extension cable should work. Personally I destroyed a crappy controller.
clueless wrote:
Blargg hasn't posted since 2010-11-29. I would like to know if he's ok. Koitsu, its been almost three months. If you can contact him, please try.
+1.
thefox wrote:
<lots of awesome information>
Thanks, I'll give this a shot. I wouldn't have thought of using an extension cable -- good idea! Off I go to place some online orders... :-)
EDIT: FTDI cable ordered from Mouser, and a couple NES extension cords ordered from eBay.
BTW, if you're looking for really cheap RS232, check this out:
http://www.larsen-b.com/Article/370.html
The voltage levels are already 5V, so no extra parts.
I don't know if it's as reliable or fast as the FTDI stuff, but it looks cheap enough to try.
I don't know much about this stuff. Thought the cable could be used. Guess this can't. Or? The pcb in the usb connector itself says:
gnd
rx
dtr
tx
xcc
If it could, I will gladly be a pal tester
The schematic would be found in the MAX202 datasheet. (max202 - or compatible - is the chip you would want to use). Just that part and some .1uF ceramic capacitors is everything.
Hilmarf: I bought some USB cables like that (not that exact model, but a different clone of that clone probably, identifies as a Prolific chip but I forget the model), but haven't been able to get it to work with my setup yet. The TTL part is 3V and not 5V, which could be the problem maybe. I put a series resistor on the output from NES and hoped it would take the 5V, but it doesn't seem to like it.
However I was driving it from a 5V PIC, not from the NES controller port exactly, not sure if that'll make a difference though.
The stuff I ordered from Mouser and eBay arrived today, but I'm at work until 23:00 PST. I'll be building this thing when I get home, assuming I don't fall asleep first.
After managing to destroy my multimeter probes and part of my palm, I'm slowly getting there.
The extension cable doesn't use the same coloured wires as that of a NES controller, so uh, going off of colour is pointless. I didn't say anything before because I was hoping the extension cable was identical, but it isn't. So, let's not focus on cable colour please.
The pin/connection correlation provided
here doesn't match the labelling on
the Wiki, so I need clarification.
Code:
Wiki thefox post
------ ------------
GND GND
CLK Clock
OUT ???
D0 ???
+5V ???
D3 ???
D4 ???
Code:
Wiki thefox post
------ ------------
GND GND
CLK Clock
OUT Strobe
D0 Din
+5V VCC
D3 ???
D4 ???
Awesome, thank you! *back to the kitchen* :D
Hrm, sorry for being such a pain, coming back to the diagram again:
Code:
Wiki thefox post FTDI
----- ------------- ------------
GND GND Ground (Black)
CLK Clock ????
OUT Strobe RxD (Yellow)
D0 Din TxD (Orange)
+5V VCC VCC (Red)
D3 n/c n/c
D4 n/c n/c
Assuming this is right, the two questions are: 1) what does CLK (Clock) connect to on the FTDI cable, and 2) Does +5V (VCC) from the NES port actually go all the way through to the VCC pin on the FTDI cable?
I haven't wired anything up yet, just wanting to make sure I don't start applying voltage to something and blow up my top loader. :P
EDIT: I think I've realised CLK (Clock) isn't connected to anything, and that +5V (VCC) isn't connected to anything either (in fact it seems doing this might be a bad idea; +5V coming from the NES and +5V coming from the USB connector = uh oh). So, only 3 wires to wire up. Gonna try that first.
koitsu wrote:
EDIT: I think I've realised CLK (Clock) isn't connected to anything, and that +5V (VCC) isn't connected to anything either
Yes, only three wires should be connected.
(E: Technical stuff just for completeness, in NES controller CLK clocks the shift register so the next bit is shifted out, it's clocked when reading 4016/4017. Like said, it's not needed for async serial i/o.)
Good deal -- all done. Now to wrap the small section of cable in more electrical tape and try it out:
http://jdc.koitsu.org/nes_usb2serial/I might have to refine the cable -- it would be much more effective to use
some of these.
If all of this takes off, maybe we can find a less-expensive version of the FTDI cable and I can build some for folks (using the above connectors makes it super easy). I'd like to keep the total cost per cable under US$30 (including S/H within the US). Not interested in making money off this, just enjoy doing something cool/useful.
Guess I'll need the software; you can send a copy to jdc at koitsu.org, thefox.
EDIT: By the way, Windows XP requires a USB-to-serial driver, presumably the one from FTDI. Seems they
offer two kinds though -- VCP (INF/COM-port-based) and D2XX (DLL-based). I assume the one I want is the VCP one, but I'm not sure.
koitsu wrote:
Good deal -- all done. Now to wrap the small section of cable in more electrical tape and try it out:
http://jdc.koitsu.org/nes_usb2serial/Looking good
Quote:
Guess I'll need the software; you can send a copy to jdc at koitsu.org, thefox.
I'll send it to you in ~15 minutes, I'm right now packing it all up and writing a short readme.
Quote:
EDIT: By the way, Windows XP requires a USB-to-serial driver, presumably the one from FTDI. Seems they
offer two kinds though -- VCP (INF/COM-port-based) and D2XX (DLL-based). I assume the one I want is the VCP one, but I'm not sure.
Yeah VCP is the one you want (shows up as a normal COM port). I think I have them both installed.
Thanks thefox, got your mail + downloaded the zip.
I've spent the past 30 minutes or so going through zillions of boxes I have (since I moved ~6 months ago), trying to find my PowerPak. I know I have it boxed up somewhere, I'm just not sure WHICH box. Grumble grumble... It's probably down in the garage, along with my bloody ORCA/M manual, haha...
I did get my NES set up though. Heh :-)
Gonna have to punt on completing this 'til tomorrow, it's almost bedtime for me. Will have to scour the garage for stuff tomorrow afternoon.
EDIT: Oh look, it's in this box labelled "NES/Famicom Disks/etc.". :D
It works! :D Sorry for the blurry video, my camera doesn't auto-focus while recording.
The transfer rate sure is slow, even for 115200. I imagine most of the wait time is on the NES CPU transferring data to/from the PowerPak, not that I know how that's done... I think I'm just spoiled and have forgotten the days of my AppleCat modem. ;-) I also noticed that some CHR data in the game was corrupted (I didn't record that), but I'm guessing I have a bad ROM. But that's besides the point; the transfer works fine.
BTW, with regards to the FTDI driver -- I used the VCP driver (automatically installed as COM3).
koitsu wrote:
It works! Sorry for the blurry video, my camera doesn't auto-focus while recording.
Cool! Glad to hear it's working.
Quote:
The transfer rate sure is slow, even for 115200. I imagine most of the wait time is on the NES CPU transferring data to/from the PowerPak, not that I know how that's done... I think I'm just spoiled and have forgotten the days of my AppleCat modem.
Nope it actually writes it to PowerPak as it's transfering so there's no slowdown there. Transfer speed is 115200 bps / 11 = ~10.23 kbytes/sec. And it's not going to get faster than that, NES CPU is too slow for any faster. It might be (a big maybe) possible to get it up to twice that speed (for PRG/CHR transfers) by utilizing the FPGA but that's pretty tricky and I'm not sure if it's worth the trouble... For development purposes the current speed is fine, especially if I make some custom mappers which allow transfering only the differences. It also does RLE already so long strings of 0 etc get compressed.
Quote:
I also noticed that some CHR data in the game was corrupted (I didn't record that), but I'm guessing I have a bad ROM. But that's besides the point; the transfer works fine.
Yeah it checks the CRC so it's probably a bad ROM.
Hilmarf wrote:
I have no idea, but like Memblers said it's probably not 5V. I don't know enough about electronics to help you with this, sorry.
Memblers wrote:
Hilmarf: I bought some USB cables like that (not that exact model, but a different clone of that clone probably, identifies as a Prolific chip but I forget the model), but haven't been able to get it to work with my setup yet. The TTL part is 3V and not 5V, which could be the problem maybe. I put a series resistor on the output from NES and hoped it would take the 5V, but it doesn't seem to like it.
The PL2303 is explicitly 5V tolerant, so I'm a little skeptical that's it. And 3.3V logic certainly looks like it would be compatible with TTL...
What's worst case scenario? Could I fry my NES?..or worse, my PowerPak?
lidnariq wrote:
The PL2303 is explicitly 5V tolerant, so I'm a little skeptical that's it. And 3.3V logic certainly looks like it would be compatible with TTL...
Yeah, well these were adapters that the retail price was like $1.20 or something, I think I found them on 'dinodirect' instead of 'dealextreme'. But cutting it open on revealed a gloptop, at that price I suspect it's a knock-off and maybe just reports being a PL chip for compatibility - but I don't know how to tell for sure. Heh, the driver CD included with it didn't even work for it, but a different driver did.
It had auto baud-rate detection which seemed to work, everything was fine when I wired it as a loop-back. The wires were insanely stupidly thin, making it fairly difficult to strip. No surprise for the price.
Hilmarf: The NES would be safe, I think. Only the 3V part would be in any danger. I put a resistor in series with the 3V input, but I don't know if that was necessary or helped/hurt. Main thing is that hopefully that adapters gets it's power from the USB 5V. Wouldn't hurt to try the dealextreme one out.
thefox wrote:
koitsu wrote:
I also noticed that some CHR data in the game was corrupted (I didn't record that), but I'm guessing I have a bad ROM. But that's besides the point; the transfer works fine.
Yeah it checks the CRC so it's probably a bad ROM.
Sorry for the long delay -- I checked this out today. The ROM is correct (not a bad dump), so something weird is going on with the PowerPak or the PC->NES transfer software. My guess is the PowerPak, maybe it's MMC3 emulation.
EDIT: Yep, restoring the PowerPak to its normal (non PC->NES transfer method) state and using a .NES ROM results in corruption of the same kind, so that rules out the PC->NES stuff. Must be a mapper problem, unless I have a bad PowerPak.
EDIT #2:
This seems quite relevant.
EDIT #3: Yep, loopy's mapper set fixes the problem. Looks like writes-to E000-FFFF asserting WRAM /WE was the problem. :D
Aah, I had forgotten about those issues. Thanks for pointing it out. BTW FYI, my save state mappers can also be used with the transfer software. At some point I may add NES->PC SRAM readback on reset (as an alternative to saving to CF).
Also I should add some switches to the app for game genie codes and transfering WRAM to the cart. But that's probably not going to happen very soon since there hasn't been a whole lot of interest in this.
I can confirm that the dealextreme cable works
this is great!
http://www.dealextreme.com/p/usb-cable- ... 2670-13638
Pinout for that specific cables colors vs european nes cable:
___NES _____________________ USB
BROWN(gnd)----------BLACK(gnd)
ORANGE(out)---------WHITE(rx)
YELLOW(d0)----------RED(tx)
(note: I think american nes cables might have different colors)
However, before you buy that one, you might check out:
http://cgi.ebay.com/USB-RS-232-RS232-Co ... 415099e1bf
Thats supposedly the same prolific clone, not real rs232
...for 1.09$ incl. shipping lol
just made a litte frontend for windows since I hate using command lines
http://www.speedyshare.com/files/276042 ... ontend.exe
edit: just updated it a little... so that it saves settings and let you use filenames that has spaces
Hilmarf wrote:
I can confirm that the dealextreme cable works
this is great!
Great!
Another way to not have to use command line is this:
Result:
Even better ^^
Really enjoy this setup since I have a nes and a TV beside my computer
any chance there will be game genie code loading from txt or somthing in next release? (if there will be one)
Hilmarf wrote:
any chance there will be game genie code loading from txt or somthing in next release? (if there will be one)
Yes, and now that you asked the chance is bigger.
hehehe, great
I added support for WRAM loading and Game Genie codes today. I'll probably release it tomorrow after some testing.
Gief plix x) Someone should make a powerpak manager program and integrate those features. Maybe I can take up on the job. My sucky VB skills should be sufficient.
..btw if anyone consider buying the nokia cable from dealextreme.. it's really really flimsy and poor quality. A blunt knife cut's through it like butter. The cable will probably break real fast.
A better option would maybe be the one on ebay that costs next to nothing with the same prolific clone inside it..
Hilmarf wrote:
Gief plix x)
Oops, forgot to release it. Here you go:
http://kkfos.aspekt.fi/downloads/pc2nes-beta2.zip
What's the GG code limit?
The limit is 5 codes (assuming the corresponding PowerPak mapper implements 5 Game Genie codes -- all the official ones do). The app will warn you if enter too many codes.
can someone reupload the frontend of pc2nes? would be quite helpful - thanks guys :3
New version (v01), no major changes. Added a fix so that the latest version of the save state mappers (with the controller bus capacitance fix) can be transferred. Source code (+ NRPC) was added to the package. Mappers are no longer included in the package.
Download from
http://kkfos.aspekt.fi/downloads/pc2nes-v01.zip
im-pulze wrote:
can someone reupload the frontend of pc2nes? would be quite helpful - thanks guys :3
You could try contacting Hilmarf at NintendoAGE forums.
I bought the dealextreme cable for $4 something, mounted the Nokia-connector end directly in the NES-connector so I didn't get any "fugly" joint mid-cable.
Mine had these colors and designations:
Blue: Rx
White: GND
Green: Tx
It was quite easy to bend the halves of the connector shell apart to check which color was what. I use a USB extension cord with mine, worked on the first try.
Great to be able to do this, guess I should start developing something for the NES now.
Should be possible to mount the dealextreme-cable with a really short cable or maybe skip the cable and glue the NES-connector and USB-shell together into a little adapter that you hook a USB extension cable to. Should be possible to make it pretty small if you want to.
If you don't have a connector that fits perhaps a plain 3.5mm stereo audio female connector could be mounted on the NES - or maybe through a hole in the bottom part. Then solder wires between that and the motherboard and use a plain 3.5mm stereo male plug on the dealextreme-cable end - or whatever cable you have. No need to butcher a controller if you don't have one to spare.
Thanks!
This thread has been dead lately...
Ran into some problems here when using the Original Nintendo Wireless IR equipment "NES Satellite".
It's really hard getting past the intro screen "Waiting for data from PC..." when using a NES Satellite, don't know why exactly, have to press a whole lot of buttons to get past it and then the rest of the menu works as usual.
Perhaps the key press detection is waiting for too long presses or something? When controller is hooked directly there's never a problem. This goes for both European and US machine.
e5frog wrote:
This thread has been dead lately...
Ran into some problems here when using the Original Nintendo Wireless IR equipment "NES Satellite".
It's really hard getting past the intro screen "Waiting for data from PC..." when using a NES Satellite, don't know why exactly, have to press a whole lot of buttons to get past it and then the rest of the menu works as usual.
Perhaps the key press detection is waiting for too long presses or something? When controller is hooked directly there's never a problem. This goes for both European and US machine.
That's strange. I guess it gets confused somehow by the code that checks the 2nd port to see if there's serial data coming (this code was written by blargg). I don't know why that would mess up the 1st controller reads though.
Don't have the slightest idea, I renamed the mapper for now but it would be nice not having to do that.
I'm willing to conduct experiments if you have any program to use for testing.
Perhaps just display on screen what the ports are reading, what was pushed last and for how long it was held? Something like that.
e5frog wrote:
Don't have the slightest idea, I renamed the mapper for now but it would be nice not having to do that.
I'm willing to conduct experiments if you have any program to use for testing.
Perhaps just display on screen what the ports are reading, what was pushed last and for how long it was held? Something like that.
Sorry, I don't have time/interest/programs ready for figuring it out right now.
Not a huge problem, I'll just not use that I.MAP until I need it again.
There is a cheaper USB UART based on the
CP2102 on
BuyInCoins. It is 5-volt tolerant so it should work with the NES.
I don't have a PowerPak so I can't test if it really works for this, but I've used for other stuff (accessing serial console on a ADSL modem) and it works perfectly.
I'd go for the dealextreme version for $4.23 (I did and it worked right away), as there's a shell for it.
http://www.dealextreme.com/p/usb-cable- ... 2670-13638
Is it Dendy-compatible? If you make a version that works from a NROM cartridge and sends a predefined string (for example, a single "A" letter), I woulnd't mint testing it.
socram8888 wrote:
Is it Dendy-compatible? If you make a version that works from an NROM cartridge and sends a predefined string (for example, a single "A" letter), I woulnd't mint testing it.
You can find a NROM bootloader and a very simple test program here:
http://blargg.parodius.com/nes-code/boo ... usage.html
The page only has instructions for how to send the .bin file from command line on Linux, but it's possible to do that on Windows too. (I don't remember the exact details, but I'm pretty sure it can be done using the COPY command with COM3/whatever as destination, after the transfer parameters are set with some other command).
I have both MingW and Cygwin here, so that's no problem. Let's try it...
EDIT: I think my CP2102-based adapter is not compatible, because it is not working even from Linux with a regular PAL NES :/
So I ordered a pair of the dealextreme cables, which arrived two days ago. And after two evenings of frustration I still can't get Windows to recognize it
So to the people who got it working: Did you use the drivers on the Mini-CD? And did you have to do any fiddling to get them working?
According to the short Engrish documentation in "CA-45&CA-50\Nok 5000\Read me.txt", "USB Driver\USB Driver Installer.exe" is the installation program to run. There's also "CA-45&CA-50\Nok 5000\USB Driver\Win Vista Driver Installer.exe". Both of them result in windows letting me know that "Device driver was not successfully installed", and the ugly old exlamation mark in device manager. Error code i either 10 or 37 depending on which of the drivers mentioned above I try to I install.
I am using Windows 7 starter on a Samsung N220 netbook.
Are you sure they are Windows 7 compatible? Also, are you using 32-bit or 64-bit windows?
qbradq wrote:
Also, are you using 32-bit or 64-bit windows?
Starter only comes as 32-bit.
Yay, I finally got it working!!
After trying every possible variant of the prolific device drivers I kind find on the web with no success and having an attempted complete system restore of Windows 7 just resulting in a BSOD, I figured I'd try how Ubuntu would measure up and installed Wubi on my netbook...
Serial adapter worked immediately without having to install any drivers at all. I did have to modify the source code a bit for gcc though and was swearing for at least an hour trying to link with Boost. But finally this command line did it:
Code:
g++ -o pc2nes -I./nrpc-1.2a1 -I/usr/include/boost -L/usr/lib Main.cpp nrpc-1.2a1/nrpc/*.c* -pthread -lboost_system
To my disappointment though, transfer was started with a black screen, but once done and resetting I just got back to the same boot program... after soldering the tied-up wires properly and starting to think if the cable had ended up too long, I figured I'd try changing the define to use 57600 bps instead of 115200. And it got me halfway to a "SENDING PRG" message... soon thereafter I figured out the program was ignoring the define in the later transfers, and after fixing that it looks like I can finally enjoy eprom emulator development speed on a Powerpak
Additionally, FCEUX seems to work in Wine nowadays (didn't last time I tried) so I'm switching to Linux again, maybe for good this time.
I'm attaching the patch to use lo-speed and make the source gcc-friendly. Since compatibility is good and hi-speed transfer obviously seems to give problems for some of us, I'd suggest it to go into the main release as well, but that's up to TheFox of course
Thanks, I'll incorporate the patch at some point. Probably should make transfer speed a command line switch instead of a compile time option.
Did you test on PAL or NTSC NES?
Sorry for the late reply. I have now tested it on both my PAL and my NTSC NES. They both give the same results: 57600 works fine while 115200 fails completely.
I am a bit curious as to why of course. Since other people haven't reported any such problems with the Dealextreme cable, it could just be my computr or Ubuntu limiting it in some weird way. Or slightly more far-fetched: maybe the length of the cable actually starts to matter at this higher speed?
When I get some visitor with a different computer I could try the first two theories, and since I bought two cables I have yet another one for testing the second theory when I'm bored enough to do some more soldering...
Bananmos wrote:
I figured I'd try changing the define to use 57600 bps instead of 115200. And it got me halfway to a "SENDING PRG" message... soon thereafter I figured out the program was ignoring the define in the later transfers, and after fixing that it looks like I can finally enjoy eprom emulator development speed on a Powerpak
Hmm, now that I checked the program, it shouldn't behave in this way. The first transfer should take care of all the data when transferring at 57600 bps, so I'm not sure what the patch accomplishes.
When SEND_115200 is 1, you should typically see something like this:
Code:
sending 123.45 KB to serial port com3 at 57600 bps
sending 111.22 KB to serial port com3 at 115200 bps
When SEND_115200 is 0, you should see this:
Code:
sending 123.45 KB to serial port com3 at 57600 bps
sending 0 KB to serial port com3 at 115200 bps
Are you saying that it was trying to send data at 115200 bps even when SEND_115200 was 0? I can't reproduce this on Windows.
thefox wrote:
Bananmos wrote:
I figured I'd try changing the define to use 57600 bps instead of 115200. And it got me halfway to a "SENDING PRG" message... soon thereafter I figured out the program was ignoring the define in the later transfers, and after fixing that it looks like I can finally enjoy eprom emulator development speed on a Powerpak
Hmm, now that I checked the program, it shouldn't behave in this way. The first transfer should take care of all the data when transferring at 57600 bps, so I'm not sure what the patch accomplishes.
Your code seems to change the baud rate to 115200 even if it will be sending zero bytes at that rate. Maybe the USB-serial adapter doesn't like having the rate changed before it's finished sending all its data at 57600. The patch ensures that 115200 isn't switched to ever if it's not being used. It'd probably be best to just wrap the whole 115200 portion in a conditional rather than rely on robust serial drivers.
blargg wrote:
The patch ensures that 115200 isn't switched to ever if it's not being used. It'd probably be best to just wrap the whole 115200 portion in a conditional rather than rely on robust serial drivers.
Yeah, this seems like the most likely explanation for the behavior Bananmos was seeing. I will release a new version with this fix and a run-time speed switch later. The nice thing is, this could also explain why 115200 transfer wasn't working for Bananmos (the 57600 portion got messed up as the speed was changed mid-transfer), so hopefully that too will work after the fix.
As far as I know, asio::write() should block until it has "written" all of the data, but maybe (probably) it returns right after it has handed the data to the driver's buffer, and not until the data has been actually sent. That may also explain the need for the ~100ms delay between transfers I had to put in there to avoid problems with the transfers on my FTDI chip. If that's the case, I'm not sure what's the correct way in boost::asio to wait for the data transfer to actually have finished.