Ok, I just finished and built it.
I can go to run game and play it, but that is all that works.
When I try to dump a game, it starts playing the game instead of dumping it.
Is there anyway to debug this thing? Find out why its not working correctly?
Hmmm, you can play a game with the CopyNES board plugged in so that is good. I am wondering, are you using the parallel port cable that Kevin sent in the kit? Or are you using a different cable? The reason I ask, it sounds like the PC is not even connected to the CopyNES port.
-CFB
I am using the cable he sent with the kit.
I guess I should make it more clear.
I am able to select "play cart" from the Qbasic menu and that works, and it correctly stops playing the game when I hit a key.
I also noticed that the options do NOT follow what the paths are set to in the copynes.ini file,
Code:
.PRG Save Path :.\parts\
.CHR Save Path :.\parts\
WRAM .SAV Save Path :.\parts\
Finished .NES Save Path :.\parts\
CRC .TXT Save Path :.\parts\
.NSF File Path :.\parts\
Plugin File Path :.\parts\
I'm starting to wonder if the problem is in software.
Another thing, his BIOS.BIN does not match the EPROM I was sent with the kit. I tried burning BIOS.BIN and running it, and it doesn't work at all.
Interesting. I will check my laptop and see if my software matches. I just unzipped the CopyNESsofware into the c:\.
I will also dump my 2764 and compare my bios against the bios file in copyNES zip file.
Actually, what cartridge are you trying to dump?
I tried an NROM cart (SMB1), and SMB3 (MMC3).
It doesn't seem to matter what I try dumping, it always starts running the game.
Also, I doubled checked that all the parts I put in are correctly in place.
Nevermind,
Its working now....
I took my old Pentium 90 out of the attic and tried it, and it works.
I'm relieved that copynes is working, but not so happy that I need ancient hardware to run it on.
Anyway,
I tried 5 different machines and only the old pentium worked.
I think Kevtris should make bigger deal that you need a slower, more compatible "parallel" port machine.
I'd be willing to start a MB compatibility list, if anyone is interested.
Thanks for your help, though!
Aha, so my second post was right. Your PC was not connected properly because of HW/Software. It doesn't suprise me. I am using an old WIN95 486 laptop. I tried running CopyNES on WINNT (I know don't ask) but it didn't work. The newer Operating Systems don't allow direct access to the Parallel Port hence all the problems with WinNT, W2K, WinXP.
BTW, my bios didn't match either.
Actually, its not the OS, I'm running Win98 on these machines, and I booted into true DOS to test this.
I can always pop in a DOS boot CD and I always keep a small FAT32 partition available for things like this.
The parallel ports on these new machines just aren't the same as they used to be.
I spoke to Kev and the bios on the EPROM is new, he just hasn't got around to uploading it to his site yet.
I bet, on the newer machines, you could try tweaking your parallel port settings. If you are using ECP that might not work well. I know that there are several parallel port communication modes.
I've tried all the different settings, no go. (Tried ECP, EPP 1.7 & 1.9, and SPP). Also messed around with the X bit I/O recovery time.
Ah well, old computers are still useful I guess.
Ok, here we go.
I was diagnosing the problem, and found the fault to be none other than QBasic.
As soon as you call the OUT (port) function, it locks up the parallel port. All the data lines get stuck on, and I cannot reset them.
I'll be working on a solution in the mean time.
You're welcome to try the current CopyNESW build (
http://www.qmtpro.com/~nes/copynes/), though there's no guarantee that any of it will work (since I haven't had a chance to test it).
Ack, this is driving me nuts. Its not QBasic after all.
I thought it was.... Grrr.
First of all, the voltage drops from 4.5V to 2.9V when CopyNES is plugged in on the machine that does NOT work.
Second of all, when the control port bit 5 is set (Bi-Directional mode), all the data outputs go high, and it takes about 10 mA to bring the voltage down to 1V. Seems a little much to me.
I'll give that program a shot,
Thanks
drk421 wrote:
Ok, I just finished and built it.
I can go to run game and play it, but that is all that works.
When I try to dump a game, it starts playing the game instead of dumping it.
Is there anyway to debug this thing? Find out why its not working correctly?
When I first tried running mine, that is the exact same behaviour I got. Fortunatly switching to EPP mode solved all the problems.
The box I'm running CopyNES from is fairly new, although I am booting from a Win98 startup disk and then just made a small FAT partition to store copynes and dump data in.
Quietust wrote:
You're welcome to try the current CopyNESW build (
http://qmt.ath.cx/~nes/copynesw.zip), though there's no guarantee that any of it will work (since I haven't had a chance to test it).
I didn't fuss it too much, but here what happened with that. When you turn on the NES, the cart starts but there is no video (you hear music). Your program sits for a few seconds and then you get a little dialog saying "WriteByte: Timeout on data transer" It is managing to do something in the background, as the NES will reset as soon as your program starts.
After you get the error message, your stuck with a ghost in the taskbar which you have to kill the process to get rid of. If you try running the program again with the "ghost" still there, then you get an error about the par port being in use, but when you close this one, you actually get the main dialog of the program, but with all main functions disabled.
Would you be willing to share your source for it? I might be able to debug it. Out of curiousity, how does one go about gaining port access in your own program without relying on some external driver. I had messed with port access on something else in the past but never got very far. How do you compile something so it doesn't run in user mode?
BootGod wrote:
After you get the error message, your stuck with a ghost in the taskbar which you have to kill the process to get rid of.
Strange - didn't you click OK on the status dialog? Doing that should drop you back to the menu. What messages were printed in it before that WriteByte timeout?
BootGod wrote:
Would you be willing to share your source for it? I might be able to debug it. Out of curiousity, how does one go about gaining port access in your own program without relying on some external driver. I had messed with port access on something else in the past but never got very far. How do you compile something so it doesn't run in user mode?
I use hwinterface.sys, the driver enclosed within inpout32.dll (I compiled it into my application, since the DLL was compiled in C++ without "extern C" and was thus unusable from a C program).
The source for the program is mostly identical to the QBASIC version, except ported to C (it behaves exactly the same), so it's possible that your parallel port is being emulated in software (by hooking the port I/O) and said software is crashing (causing a lockup) from both QBASIC and my client program.
I'm not getting any dialog or error.
I load the program and it just sits with an empty taskbar.
Anyway to debug this thing?
I'm running on a Win98 system, I'll try it on my XP system as well. (which I have Userport running on).
BootGod wrote:
drk421 wrote:
Ok, I just finished and built it.
After you get the error message, your stuck with a ghost in the taskbar which you have to kill the process to get rid of. If you try running the program again with the "ghost" still there, then you get an error about the par port being in use, but when you close this one, you actually get the main dialog of the program, but with all main functions disabled.
Exactly the same thing here on the same machine that works fine with QBASIC.
ahh crap, should have logged in..sorry for the messy post...
Quote:
Fortunatly switching to EPP mode solved all the problems.
Could you please go into more detail?
What Motherboard/CPU have you go? (I've got an Abit BM6/550 Celeron)
What BIOS do you have? (I have Award, and the machine that it works on is AMI)
EPP mode 1.7 or 1.9?
What did you set the I/O recover time to? (16/8)
Thanks
It sounds like Windows 9x doesn't like the way my program tries to open its status dialog - it works just fine under Windows 2000.
Upon inspection, it was opening the Status window using SW_SHOWDEFAULT, which could have opened the window minimized. I've uploaded a new build (using SW_SHOW instead) - hopefully it will work better under 9x.
drk421 wrote:
Could you please go into more detail?
What Motherboard/CPU have you go? (I've got an Abit BM6/550 Celeron)
What BIOS do you have? (I have Award, and the machine that it works on is AMI)
EPP mode 1.7 or 1.9?
What did you set the I/O recover time to? (16/8)
Thanks
The box i'm currently using for CopyNES has a MSI KT4 Ultra board using an AMI BIOS. Using EPP 1.9 and there are no options for recovery time. It runs WinXP with NTFS formatted disks, but I made a small FAT partition for CopyNES use and then boot it with a Win98 start-up disk.
I've also tested it to work on my roommates old pre-built hunk of crap which has a Asus P2B-VT board with a PhoenixBIOS. Using EPP and no settings for EPP version or recovery time. This thing runs Win98.
Quietust wrote:
Strange - didn't you click OK on the status dialog? Doing that should drop you back to the menu. What messages were printed in it before that WriteByte timeout?
I should mention that I was trying this from WinXP on the same machine I use for CopyNES otherwise.
If the NES is
off when you start CopyNESW, this is when you get the WriteByte timeout, which makes sense because the NES isn't on, but when you click ok, the main dialog never shows up, just the blank taskbar item.
If the NES is
on when you start it, you get no errors, just the blank taskbar item.
If you try running the program again without killing the old process, then you get the error about the port being in use. But this time the main dialog will show up, but with all main functions greyed out.
ack, this board hates me for some reason, likes to log me off behind my back. Anyways post above is me.
Oh I forgot to mention, I did try the new build of CopyNESW, with same results.
Quote:
If the NES is off when you start CopyNESW, this is when you get the WriteByte timeout, which makes sense because the NES isn't on, but when you click ok, the main dialog never shows up, just the blank taskbar item.
If the NES is on when you start it, you get no errors, just the blank taskbar item.
I get the exact same results on win98 and winxp.
Hurray, I got my own little C port working in WinXP! (thanks for the heads up on that driver Quietust!)
So far I've only ported the "Play Cart" and "Dump Cart" functionality, but it seems to work fine. It's just a little command line deal at the moment. I'll spruce it up a bit and release it ASAP for others to try.
Boy that QBASIC code is a mess! No offense kevtris
I still don't understand why the status dialog does not appear under Windows XP, because it appears just fine under Windows 2000.
I've made a few other tweaks to clean up the window procedures and hopefully get the status window to always display properly. Even now, it still works fine under Windows 2000, though I have no idea what's wrong with your XP installations that would cause this to not work.
http://qmt.ath.cx/~nes/copynesw.zip
It seems to almost work now, when it starts, it queries the bios version and correctly id's it. If you hit play cart, it will play, If you try to dump, it makes it until it tries to load a plugin, then it fails.
I dunno if your doing this or not, but I had to add some sleep time in a couple spots to get my program to work.
In the resetnes function, kevtris had 2 generic time wasters right at the end. I changed them to Sleep(50).
At the very end of the loadplugin function I also added a Sleep(50). This was neccessary for me, otherwise it would crap out when runcode() was run. Seeing as how it dies in the same place with your prog, this might be all you need to do.
I just picked 50 ms out of the air, you may be able to go less, not that it matters at all.
I had delays in all of the places the QBASIC version had them, but it's possible that the I/O driver is allowing me to communicate too quickly.
I just added an extra pause at the end of LoadPlugin - see if it works better now.
YES! It works!
Thanks Quietust! You ROCK!
It kept erroring out at first, so I went and screwed around with my BIOS settings until it worked.
I finally ended up with the following settings:
8 bit I/O Recovery Time: 8
16 bit I/O Recovery Time: 4
Under Integrated Peripherals, I used EPP Parallel port mode, EPP 1.9.
Also, one other thing, the parallel cable that Kevtris sent is very unrealiable with some machines. It won't work at all on my notebook, but works fine on my Pentium 90. I ended up using a 2 foot cable to get it to work.
Thanks again.
Oh yeah, has anyone documented how to control CopyNES?
Hmm it still craps out for me in the same place :/ It's hard to say why it isn't working even with that delay for me, as this is the same computer I've been running my version from and it hasn't given me any problems. Don't worry about it too much, I've got mine built into my DB entry program now, so I'm happy and it seems to work for others.
I doubt the cable is the problem. I buttload of parallel programs, especially for console copier/dumper type devices will not work on notebooks due to a shittier parallel controller used in most notebooks. It seems a desktop is required for many of these applications.
-Rob
Well, actually, it does work if I use a shorter cable.
The output impedance of the parallel port on some PCs is very high, which makes it more susceptible to noise and the capacitance of the cable. I'm wondering exactly what is causing the data to get corrupted, with a long cable.
drk421 wrote:
The output impedance of the parallel port on some PCs is very high
Low fanout, right? What could be done to buffer the signals? Would a hex inverter (74HCT04) or similar part work?
Quote:
Well, actually, it does work if I use a shorter cable.
The output impedance of the parallel port on some PCs is very high, which makes it more susceptible to noise and the capacitance of the cable. I'm wondering exactly what is causing the data to get corrupted, with a long cable.
Wow...that's interesting. Never heard of that before. Good to know.
-Rob
rbudrick wrote:
Quote:
Well, actually, it does work if I use a shorter cable.
The output impedance of the parallel port on some PCs is very high, which makes it more susceptible to noise and the capacitance of the cable. I'm wondering exactly what is causing the data to get corrupted, with a long cable.
Wow...that's interesting. Never heard of that before. Good to know.
-Rob
Yes, there is a reason the parallel interface has been phased out. It just can't handle long runs of wire, and by long I mean more than a couple of feet. Getting a thick shielded cable will help, but only to a degree. Generally, with any electrical signal you want the shortest possible path (of course there are exceptions
). That's why the people who are into super hi-def audio/video cut their own cables to the correct length for their setups.
A Hex inverter or buffer right at the output would help (you could also buffer it with transistors), but that would kill the bi-directional mode.
Finaly got around to installing my copynes today. Went off without a hitch thanks to $10 radio shack desoldering iron. Only one problem encountered. The Q basic version of the software did not work for me on win server 2k3. Q's windows version worked great though. Thanks kevin and Q...this should be fun to play with.