Just letting everyone know that I'm gearing up for another run of copyNES units. This time, it is unlimited. I will be getting 100 boards made. The host code was redesigned some and fixed/cleaned up a bunch so it's better, and I will be offering blank PCBs and possibly some PCB+part kits depending on what people want.
The boards are on order now so in a couple weeks I should have them and that's about that. Once everything is available I will be posting it on my website and on here and a few other forums and such.
If anyone has anything the think would be good to have on copyNES' host code lemme know (i.e. debug features, etc).
How about ability to write to common flash chips (e.g. Atmel) so that we don't have to use sockets anymore on hacked NROM cards?
tepples wrote:
How about ability to write to common flash chips (e.g. Atmel) so that we don't have to use sockets anymore on hacked NROM cards?
Should be no problem, CopyNES loads code plugins from the host PC and when I get one I'll be writing one for Squeedo.
I should mention also that I've never tried flashing CHR-ROM through the PPU, so I don't know if that'd work for sure. It might.
this is great news
what will the price be? I must have one!
edit:
about "host code (i.e. debug features, etc)." I'm not fully sure what is supported of it for now... but I would love things like:
* breakpoints that can be triggerd from a computer
* register viewer so you can watch (and possibly change) registers
* adress watch, so you can watch specific variables for your game (and possibly change them)
* memory viewer
this would be some cool futures I would love to see.. just think of how nice IDE that could be written for computers to write NES games
this is nothing ofcourse that has to be in CopyNES for me to buy one.. but you asked for debug features, and this are some I would love to see (if they are possible)
[ (Slightly) Off topic ]
Any plans for a CopyNES system that uses video out to display status, (instead of an LCD) etc?
Doesn't seem to me that this should be too difficult. I appreciate the simplicity of using the LCD, but could one just stack a RAM IC to setup some pattern tables etc...no? Doesn't even have to be a full 8K - ASCII set can be stored in 2K.
Movax wrote:
[ (Slightly) Off topic ]
Any plans for a CopyNES system that uses video out to display status, (instead of an LCD) etc?
Doesn't seem to me that this should be too difficult. I appreciate the simplicity of using the LCD, but could one just stack a RAM IC to setup some pattern tables etc...no? Doesn't even have to be a full 8K - ASCII set can be stored in 2K.
Can't be done without a major redesign, since CopyNES only overrides the CPU, not the PPU.
Besides, there's no need to indicate status on the NES side (all previous CopyNES units were shipped without the LCD!) since the client software displays all of the necessary status info.
OK guys, I expect everybody to redump every NES and Famicom game and confirm that the previous dumps are good or not. It is allot of hard work, but with 100 more CopyNES systems out there, everybody can chip in 1/100th of the needed work
[quote="dXtr"]this is great news
what will the price be? I must have one!
edit:
about "host code (i.e. debug features, etc)." I'm not fully sure what is supported of it for now... but I would love things like:
* breakpoints that can be triggerd from a computer
* register viewer so you can watch (and possibly change) registers
* adress watch, so you can watch specific variables for your game (and possibly change them)
* memory viewer
Sorry, this is a modified nintendo, not an ICE (in circuit emulator). Doing that stuff is impossible in the traditional sense.
Though, what COULD be done maybe is a user could put debug stuff in their game to use copyNES' BIOS to send and receive stuff through the PC interface. You could have copyNES dump data or upload things or similar. The BIOS sits in some "empty" space on the memory map (well, more specifically it steals some of the mirrored space where the PPU and RAM sit) so it will not affect any kind of bankswitching or RAM/ROM setups.
If you wanted to monitor the value of some memory location, you could put a call to the BIOS "send" routine to blast it out the port to the PC, or alternatively have some kind of mini-dump route to dump the RAM or whatever.
ok.. as you might note I'm not an expert in hardware ^^
and those kind of thinks I proposed was more of a "fun thing to have" then something I can't live with out (all of those things can be done in emulators). so anyways, what about date when you think you can start selling, and price?
so how much are you selling them for?
and I do not mean to offend you but you are a guest how do we know you are the real you and not just some joker
kevtris wrote:
Just letting everyone know that I'm gearing up for another run of copyNES units. This time, it is unlimited. I will be getting 100 boards made. The host code was redesigned some and fixed/cleaned up a bunch so it's better, and I will be offering blank PCBs and possibly some PCB+part kits depending on what people want.
The boards are on order now so in a couple weeks I should have them and that's about that. Once everything is available I will be posting it on my website and on here and a few other forums and such.
If anyone has anything the think would be good to have on copyNES' host code lemme know (i.e. debug features, etc).
Sounds awesome man, ive been waiting a long time for ya to do this =) Do you have a ballpark figure of our much say the pcb+kit would cost? Thanks Alot =)
Quote:
Sounds awesome man, ive been waiting a long time for ya to do this =) Do you have a ballpark figure of our much say the pcb+kit would cost? Thanks Alot =)
It looks like the cost is going to be $125 per conversion, and I haven't decided yet on the bare PCB and kit versions. I got quotes out to several board houses now and I'm waiting for them to get back to me. When I know how much it will cost, I will let everyone know.
When I say "per conversion" this means you send me your *working* nintendo (yes I will check
and I will modify it and test it and return it to you. As for kits I'm not quite sure. I was thinking of selling bare board, board+parts, or a stuffed board (minus CPU). I might offer all 3 styles and see what people want. Once I know more how many orders I will have, I will buy parts and charge accordingly. More people = less cost per unit due to volume discounts on parts.
Quietust wrote:
Besides, there's no need to indicate status on the NES side (all previous CopyNES units were shipped without the LCD!) since the client software displays all of the necessary status info.
Of course , but it would be 'neat'. Make it easier to play around with bits of homebrew code too. (From what I thought I understood about copynes, one could still acess the ppu, the only problem with displaying something is there are no pattern tables with no cart... disable cart pattern tables, enable ppu vram...should work.)
Well, I ordered boards for CopyNES today... so they will be ready in a couple weeks. In the mean time I will order around 20 sets of parts. I have 100 boards coming, and they are full pro boards with soldermask on both sides and silk screen and all that fun jazz.
I haven't set a price for them yet but it looks to be in the $15 area for a bare board. As for a set of parts with the board, I dunno. The conversion is still $125 with you providing a WORKING NES.
More details will be posted when I have more info.
Will it require some crazy rare IDC cables or anything? Will a kit provide a wired CPU socket?
kyuusaku wrote:
Will it require some crazy rare IDC cables or anything? Will a kit provide a wired CPU socket?
Nope, it's fairly straight forward. It uses a pin header that solders between the two boards. You could socket it if you want so that the copyNES board can be removed and the original CPU reinstalled.
The only IDC cable needed is between the DB-25 and the PC board.
btw. would there be any problems using this in a PAL nes?
dXtr wrote:
btw. would there be any problems using this in a PAL nes?
I don't see why not, though it would dump carts slightly more slowly (due to the fact that the PAL CPU only runs at 1.66MHz compared to the NTSC's 1.79MHz).
Quietust wrote:
dXtr wrote:
btw. would there be any problems using this in a PAL nes?
I don't see why not, though it would dump carts slightly more slowly (due to the fact that the PAL CPU only runs at 1.66MHz compared to the NTSC's 1.79MHz).
nice. was afraid there could be some timing-issues or something alike
kevtris wrote:
Quote:
Sounds awesome man, ive been waiting a long time for ya to do this =) Do you have a ballpark figure of our much say the pcb+kit would cost? Thanks Alot =)
It looks like the cost is going to be $125 per conversion, and I haven't decided yet on the bare PCB and kit versions. I got quotes out to several board houses now and I'm waiting for them to get back to me. When I know how much it will cost, I will let everyone know.
When I say "per conversion" this means you send me your *working* nintendo (yes I will check
and I will modify it and test it and return it to you. As for kits I'm not quite sure. I was thinking of selling bare board, board+parts, or a stuffed board (minus CPU). I might offer all 3 styles and see what people want. Once I know more how many orders I will have, I will buy parts and charge accordingly. More people = less cost per unit due to volume discounts on parts.
Sounds Good =) Put me down for 1 of the 100. =) Will it also include the little LCD screen thing like you have on yours? Thanks
Necrosaro420 wrote:
the little LCD screen thing like you have on yours? Thanks
Nope, I never put LCDs on any of the CopyNES units I sold. I only had it on the 1 proto and that was it. There are pads on the board to attach one though. It was pretty worthless so I didn't bother putting it on (not to mention the cost and time involved in doing so). The PC host code has all the progress and status information on it.
Update: CopyNES boards are shipping in 3 weeks or less, and parts shipped today, so I will be ready to go mid-november! I have set prices for everything. Here is the breakdown:
pre-programmed EPROM: $8
Assembled IDC connector: $6 (includes pin header, DB-25, etc)
PCB: $15
PCB+EPROM: $19
All three above: $24
Complete kit: $45 (you add NES, desolder CPU, solder onto copyNES board, etc)
Full conversion: $125 (you send me your *working* NES and I convert it and test it out then send it back)
So there ya go. I will start accepting money when I have boards and everything in my possession!
Cool,
do you have a contact email or shall we PM you?
How big are the pcb? Can it fit well in a New AV Famicom?
I'm most definitely down for one too. Can't wait!
-Rob
I'll go straight for a complete kit
Time to bare the cold and hunt for returnables
I'll take the Assembled IDC connector and PCB,
Thanks
1. Is it possible to make the CopyNES write FDS images to FDS disks, if you attach a Famicom Disk System to the NES?
2. Is it possible to load a FDS image directly into the RAM adapter, using the CopyNES?
Jagasian wrote:
1. Is it possible to make the CopyNES write FDS images to FDS disks, if you attach a Famicom Disk System to the NES?
2. Is it possible to load a FDS image directly into the RAM adapter, using the CopyNES?
You can load FDS to the RAM adaptor but then you won't be able to load again off the disk. As for dumping/writing disks, CopyNES theoretically CAN do it... and even "borrow" the BIOS on the RAM pack to help it along... but I have not written code to do it. I'm sure making a plugin for it would be dead simple.
I just don't really know *how*. Also, getting the FDS RAM pack into copyNES is uh... tricky to say the least
I chained 3 adaptors to do it on mine!
As for it fitting in a toploader, no it won't. It's too big to fit in the toploader and only fits on a front loader.
Quote:
1. Is it possible to make the CopyNES write FDS images to FDS disks, if you attach a Famicom Disk System to the NES?
Ouch.
I've done the 3 adapter route myself. Time to make a CopyFC, Kev!
I actually made a really cool translation of Copy Tool 1 for you folks.. Just waiting for Memblers to post it. BTW, it is a newe and better design rthan Copy Tool 2, so don't ecven bother with Copy Tool 2. Together with FDSLoadr, you wouldn't need much else for dumping, loading and copying FDS disks.
Well, I guess you'd still have some CRC eroors on dumps, but hopefully Tomy will have a good solution to that soon.
-Rob
kevtris wrote:
You can load FDS to the RAM adaptor but then you won't be able to load again off the disk. As for dumping/writing disks, CopyNES theoretically CAN do it... and even "borrow" the BIOS on the RAM pack to help it along... but I have not written code to do it. I'm sure making a plugin for it would be dead simple.
I just don't really know *how*. Also, getting the FDS RAM pack into copyNES is uh... tricky to say the least
I chained 3 adaptors to do it on mine!
.
So there would be no way to play FDS images without writing them to a FDS disk first?
How expensive would it be to make a bunch of FDS to toaster NES adapters? All that is needed is a Famicom to NES adapter that uses a ribbon cable or really long PCB so that the RAM adapter has enough room to be plugged in, right? I'd figure there would be interest in having an all-in-one Famicom, NES, and FDS copier.
BTW, does the Japanese Famicom community know about this upcoming release of the CopyNES? It would be a good thing to get them dumping more carts.
I wouldn't call a CopyNES with extension card an all in one copier exactly, remember CopyNES can't playback bankswitching games.
I don't think there is a FC dumping community really, at least not anymore since all games have been dumped. Anyways, most of the Japanese involved have had Paso devices (which can already backup FDS games and have support for Japanese "mappers") for years. It'll likely be up to westerners to redump FC games in order to verify integrity.
Quote:
I don't think there is a FC dumping community really, at least not anymore since all games have been dumped. Anyways, most of the Japanese involved have had Paso devices (which can already backup FDS games and have support for Japanese "mappers") for years.
But were they dumped properly, to use the right hardware? Some have been hacked to use a more common board. Others use a board subtly different from the major board. I have heard of a FC game or two that fail to work at all because of a bad dump or an improper mapper assignment.
Very few games were hacked, I think most if not all of them have found their way out of GoodNES too (or at least are now recognized as being hacks.) It seems to me though that most of the dump are really good dumps, just not verified as being so. That doesn't mean however though that games aren't assigned a wrong mapper. Lots of games are improperly handled because nobody remembers which titles use what hardware internally and many could be passed off as others, especially the single latch FC ones. It doesn't help that nobody documents FC boards, "if the only known game to use the mapper just uses the first 2 bits of a latch, who cares what the other bits do?" seems to be the sentiment.
rbudrick wrote:
Quote:
1. Is it possible to make the CopyNES write FDS images to FDS disks, if you attach a Famicom Disk System to the NES?
I actually made a really cool translation of Copy Tool 1 for you folks.. Just waiting for Memblers to post it.
-Rob
Memblers, can you post this doc? I have some dying FDS disks to dump before they go bad!
-CFB
Quote:
How expensive would it be to make a bunch of FDS to toaster NES adapters?
Well, about the cost of two 60-72 pin adapters and one 72-60. Put them together and make a case for them, and you'd be good to go. However, a production model of one would be rather inexpensive, I would imagine, if made in bulk. I would almost think making the cases would be more expensive than the boards, if you didn't use the ribbon cable technique and just used a straight board.
-Rob
It's not easy however to buy the 60pin edge.
ChimyFolkButter wrote:
Memblers, can you post this doc? I have some dying FDS disks to dump before they go bad!
-CFB
You don't need Copy Tool to dump disks ;)
Quote:
You don't need Copy Tool to dump disks
Yeah, it doesn't really help you dump them, so much as copy them. Also, copying fds disks is much like copying a cassette tape...though the data on the tape is digital, it is recorded in a very analog fashion...so successive copies of copies lose quality. In other words, don't ever copy copies of copies of copies of disks ("great-grand children" copies of original "parent" disks are about as far as you can go, you might say).
So, if you want to re-write your originals, dump them first to get exact copies, then re-write back to the disk.
There is an interesting thread over on tototek right now concerning FDS backup methods:
https://tototek.com/phpBB2/viewtopic.php?t=548
-Rob
Yeah, I've been wanting to upload those FDS doc scans but it's so huge altogether (100MB+). There's nowhere I can put that much except sharing it myself on emule, and I'll do that if anyone will actually get it. The .doc version is 6MB, which isn't too bad, I still feel like I should ask koitsu first before putting anything that's really large on his server though.
I was meaning to look at finding a way to reduce the filesize (it's black and white, for 12 pages or so that just seems too huge). But I haven't had the time to mess with it, so much stuff going on over here.
The .doc version is pretty small (6MB), since I turned the pages into black and whites (they were monochrome green to begin with, so no big deal) and turned the pages into jpgs instead of fully text-selectable pdfs (the other versions I sent Memblers).
I tried looking for other ways to get them smaller, but I just really hated to lose quality...because anything else I did had major quality loss!
If just the 6MB one went up, beware you won't be able to select any text like in the PDF (the .doc version just has 1 jpg of each page of the original per page of the doc). But the best version of the pdf is about 56MB due to the high quality scans and the buttloads of textboxes.
I even sent Memblers a new Japanese version (I retyped the whole thing over the original...took ages). No more photocopied impossible to read pages! I guess if Tomy's original scans of photocopies were taken down, that would free up 2 MB or so, making the 6MB version only take up an extra 4.
Anyone wanna pony up some permanent bandwidth to Memblers so he can host all the docs?
Sorry these pdfs are so large, folks. I think you'll be extremely pleased with the quality of them. I should have the source docs for Copy Tool 2 soon, but really, Copy Tool 1 is much more updated..there's not much point in Copy Tool 2 other than to see the technical "renovation" that went on for the revised Copy Tool 1 (yeah, basically, the docs were dubbed backwards on nesdev, but no one knew until now).
-Rob
kyuusaku wrote:
You don't need Copy Tool to dump disks
I want to get the circuit to bypass the evil twin chips so I can write my disks.
I tried FDSLOADR for reading the disks but I couldn't test it correctly by writing the dump to disk.
-CFB
rbudrick wrote:
Sorry these pdfs are so large, folks. I think you'll be extremely pleased with the quality of them. I should have the source docs for Copy Tool 2 soon, but really, Copy Tool 1 is much more updated..there's not much point in Copy Tool 2 other than to see the technical "renovation" that went on for the revised Copy Tool 1 (yeah, basically, the docs were dubbed backwards on nesdev, but no one knew until now).
-Rob
Yea, I wanted to read the detail text and figure out the schematic of the doc so I can build this bad boy. Just posting the text will be good. I can see what the parts are and what the reasoning etc .
Thanks,
-CFB
Would be cool to have the full pdf on ed2k or bittorrent for some day util some people have it complete.
Quote:
Yea, I wanted to read the detail text and figure out the schematic of the doc so I can build this bad boy. Just posting the text will be good. I can see what the parts are and what the reasoning etc .
Thanks,
-CFB
Well, I didn't want to do that because it would take 100 years to copy and paste all the text boxes and plus, considering all the work that went into these docs, I really wanted people to get the full effect.
Oh, it looks like Membllers posted them all. Awesome! Thanks, Memblers! You rock!
Please let me know what you think, folks.
-Rob
ChimyFolkButter wrote:
kyuusaku wrote:
You don't need Copy Tool to dump disks ;)
I want to get the circuit to bypass the evil twin chips so I can write my disks.
I tried FDSLOADR for reading the disks but I couldn't test it correctly by writing the dump to disk.
-CFB
Don't write over any "broken" disks! With some persistence I've managed to read dozens of err 22,24,27 disks. If you want to verify your dumps, open them with a hex editor, it will be easy to see if you're on the right track.
Sometimes you can do several runs to get the files that you missed when you get a bad read. Say you can't get the disk dumped in one pass---you get a few bad passes and you can then splice them together, but I'm not sure how...I've only heard of it. Kyuusaku?
Yeah, definitley don't delete "bad" disks, unless you really don't want the data on it and/or have already backed up the data on it. If it's a bad read, chances are the data is in there, more than likely, just your drive isn't in tip-top shape to read it. Sometimes an overwrite can help remagnetize the disk, but make sure you've attempted to backed it up first.
As far as I know, you can only write the WHOLE disk, not parts of it, so unlike floppies, it really is best to be sure with these before you go overwriting them. It's just the way the Quickdisk format was designed. Well, I suppose this puts save files into question though....unless of course, the whole game and the save file is rewritten at the same time every time a save file is saved...I'm not sure actually. Maybe someone knows this?
-Rob
I imagine that rewriting savegames involves reading the game code, ignoring it, and then switching to writing once the head gets to a given sector.
Quote:
imagine that rewriting savegames involves reading the game code, ignoring it, and then switching to writing once the head gets to a given sector.
Well, like I said, I didn't think it could do that...my understanding was that the QD format takes an all or nothing approach. With the disk side already in RAM, I guess it would make sense if it wrote the whole side with the save file over at the same time...kind of a crappy way of doing it, but my understanding was that the qd format just isn't that dynamic, which is why it never really caught on in too many computers. It was faster, but not too versatile.
Of course, any corrections to my notions of its writing techniques are most welcome.
-Rob
Copynes updates:
I received parts for the CopyNES kits/boards/etc... and boards are still on order. I haven't gotten an update yet on PCB production, so once I get that I will forward it.
I socketed my CopyNES BIOS and added the 6502 emulator stuff to it last night and have used it successfully to reverse engineer a 'copy protected' fami cart! It worked much better than I could ever have hoped.
The cart in question is "Earthworm Jim 2". It used just absolutely stupid levels of protection in the code, including 3 hash routines, dynamic code generation, and lots of other crap. Long story short, the game now runs in Nintendulator. I made a text file with info on how it was cracked, complete with a commented disassembly and such:
http://tripoint.org/kevtris/mappers/inc ... j2prot.txt
After doing this, I found a few things I will change in the emulator to make it work even better...
BTW, does anyone have a working Panda Prince fami "pirate original" cart? I have one, but it doesn't work any more. It uses a similar protection to this EWJ2 cart. I have a ROM dump I made before the cart died, but it does me no good without a working cart. I just need to borrow it for awhile to trace the code in a similar fashion to this EWJ2.
I have Panda Prince cart copy protected.
rbudrick wrote:
Sometimes you can do several runs to get the files that you missed when you get a bad read. Say you can't get the disk dumped in one pass---you get a few bad passes and you can then splice them together, but I'm not sure how...I've only heard of it. Kyuusaku?
I suppose you could splice together failed reads with a file compare utility assuming both are the same size but how would you know which is valid?
rbudrick wrote:
As far as I know, you can only write the WHOLE disk, not parts of it, so unlike floppies, it really is best to be sure with these before you go overwriting them. It's just the way the Quickdisk format was designed. Well, I suppose this puts save files into question though....unless of course, the whole game and the save file is rewritten at the same time every time a save file is saved...I'm not sure actually. Maybe someone knows this?
You can write parts of the disk, but the drive does have to make a full pass every time since it can't seek.
PS, let's start another FDS thread, we're kinda taking over Kevtris'
http://nesdev.com/bbs/viewtopi ... =5931#5931
Very good point, Kyuusaku. Sorry, Kev!
Very cool EWJ2 work, Kev. It's amazing how clever some of those pirates were.
-Rob
Why do pirate companies design such ridiculously complicated copy protection schemes? Do they do it as exercises in electrical engineering and 6502 coding? Are they afraid that Nintendo or the third party they stole the game from will have an easier time suing them in court with the code? Are they afraid of people distributing their ROMs and played on emulators instead of buying cartridges? Or is it to stop competitors from including their hacked game on their competitors cartridges?
I think the first and last are by far the most likely. I don't know what the profits are like on pirate cartridges, but I can't imagine them being very high. Nintendo rarely goes after pirates these days because they are hard to find and track down. Back in the day, they could prove an infringement case without the code, all they have to do was to show the similarities during gameplay.
I am sure even pirates take pride in their convoluted schemes. Equally, they don't appreciate the competition in the next two-bit factory over putting out the cartriges they worked so hard to port to the 8-bit hardware. The joys of a free market!
Looks like steal games from pirates is much easier than from nintendo, because pirates couldn't pursuit for stealing it's "copyrights".
Btw, copy protection schemes at all do not stopping copying of hacked versions.
I've released some time ago hacked version of that EWJ2 pirate...
Another way to preserve copyrights is EasterEggs, like in most JY games (mapper 90) and also in some Shin-Shin games (EWJ2, EWJ3, DKC2)...
CaH4e3 wrote:
Looks like steal games from pirates is much easier than from nintendo, because pirates couldn't pursuit for stealing it's "copyrights".
Btw, copy protection schemes at all do not stopping copying of hacked versions.
I've released some time ago hacked version of that EWJ2 pirate...
Another way to preserve copyrights is EasterEggs, like in most JY games (mapper 90) and also in some Shin-Shin games (EWJ2, EWJ3, DKC2)...
Yeah... It's pretty ironic- the pirates write an original game instead of just copying it, and now they want to prevent OTHER pirates from copying it!!! That's the long and short of it I think.
Also yah I downloaded the copy of it you have which was hacked for MMC3 from what I remember. The game seems to use what I call the "submapper" (gotten thru regs at 5800 and 5801) to do the protection routines, and then they switch it off and go with the regular "MMC3" after the protection is done (vectoring all writes to it through RAM to prevent easy hacking). So a determined hacker probably wouldn't have too much trouble porting it to MMC3. Though, the MMC3 it uses has the register writes moved around! The registers are not in the normal order. The just had to make life a bit more "interesting" I guess.
Oh yeah I still have those sachen games I need to send you and some other stuff. I lost your email addy since I moved. BTW do you think I could borrow your Panda Prince cart some time so I can figure that protection out? Doing EWJ2 was kind of a test to see how well I could break this kind of protection, and it looks like it was a success.
Changing registers order is common thing for such carts as I see, mostly "Super Games" titles are have mixed up internal registers and registers mapping to CPU memory space. But one interesting thing: permutation table for H2288 the same as for mapper 114 and 182 (maybe more, i need to collect all known info for cleaning mapper stuff. so many duplicated aor similar mappers... blah...).
Sure, I'll borrow you my Panda Prince, maybe some other carts I have... I have original version of Sonic 3D blast, with the same type of board as Panda (Panda have A9712 number, Sonic A9711)... Original copy protected Somari (not so heavy protection, just some lock register or something... And some more... ;) Just now I haven't any device that will be able to reverse this hardware... If situation is not changed, my carts will be in your CopyNES. ;))
my mail cah4e3 at mail dot ru you are welcome ;)
Sonic 3D blast was actually a Famicom pirate original? Wow...that's news to me.
That reminds me...I heard there were two versions of Wai Xing Zahn Shi, the Phantasy Star IV pirate original. Kev, was it you that dumped the newer version of the rom I heard about? And does anyone know what the differences were? I've gotta find that game one of these days...I've never seen anyone sell a copy.
Kev, what was wrong with your Panda Prince...the broken one? Obviously not repairable, I take it....cracked glop?
-Rob
Update: CopyNES PCB's arrived today!! I am waiting on 1 more part before I will take orders... the special 40 pin header thingers that attach the CopyNES board to the NES-CPU board. This new style header lets you unplug the copyNES board for testing and such.
It won't be too much longer now. The NES "emulator" I wrote for CopyNES was fully debugged and then I added some PPU emulation so that it should be able to (slowly) run some games. As stated before, this is for debugging stubborn ROMs and things like that, and obviously not for playing games
nice.
can't wait to get my hands on one of them ^^
kevtris wrote:
The NES "emulator" I wrote for CopyNES was fully debugged and then I added some PPU emulation so that it should be able to (slowly) run some games.
I think that the "emulation" feature should be called "NES on NES emulation", as it brings to mind "girl on girl action". Little things like that might help marketing
More seriously, is audio also emulated? It might be somewhat useful for people playing around with the NES's sound or at least something fun to play with, though the slow speed would cause distortion, and therefore audio emulation should be optional. Also, have run your NES emulator on your NES emulator on your NES? Is there enough memory for that? It would be a good stress test for the NES on NES emulator.
NES on NES emulation might be another application for the NES overclocking mod. Just how much can the NES be overclocked when using active cooling?
Jagasian wrote:
kevtris wrote:
The NES "emulator" I wrote for CopyNES was fully debugged and then I added some PPU emulation so that it should be able to (slowly) run some games.
I think that the "emulation" feature should be called "NES on NES emulation", as it brings to mind "girl on girl action". Little things like that might help marketing
More seriously, is audio also emulated? It might be somewhat useful for people playing around with the NES's sound or at least something fun to play with, though the slow speed would cause distortion, and therefore audio emulation should be optional. Also, have run your NES emulator on your NES emulator on your NES? Is there enough memory for that? It would be a good stress test for the NES on NES emulator.
NES on NES emulation might be another application for the NES overclocking mod. Just how much can the NES be overclocked when using active cooling?
The audio works like normal, as do controllers and mappers and other things- the "emulator" just reads and writes to memory like usual so if sound regs happen to be there, they get written to. same with mapper regs and what not.
Theoretically, the emulator SHOULD be able to run itself, since it will move the stack around to compensate but it may hit itself due to the way the relocation works.
The entire emulator takes up 18 or so bytes of RAM at the top of stack to run.
This is all very exciting. Will you be also offering the nsf cart and/or a RAM cart to go with? Or is swapping out the ROM with a RAM chip as easy as you make it sound on your site? I'm fairly handy with electronics.... but lazy....
Quote:
I think that the "emulation" feature should be called "NES on NES emulation", as it brings to mind "girl on girl action". Little things like that might help marketing
Shit, I'll buy two. Oh, wait NESS was a male kid in earthbound. Jag, you sick bastard.
NSF carts....Kev, I'd be very interested in buying one too...
-Rob
Kevtris,
Why do you have to put 470 ohm resistors in series with the data lines in some cartridge adapters to stop sprite corruption?
For instance in my homemade NES/Famicom adapter.
http://www.54.org/condev/FC_NES_Conv/FC ... %20004.jpg
Thanks
drk421 wrote:
Kevtris,
Why do you have to put 470 ohm resistors in series with the data lines in some cartridge adapters to stop sprite corruption?
For instance in my homemade NES/Famicom adapter.
http://www.54.org/condev/FC_NES_Conv/FC ... %20004.jpgThanks
I"m not 100% sure why, it seems to have something to do with the speed of the ROM device... you usually see this when using an EPROM emulator. I don't know if the ROM is too FAST or if it's too slow... in any event, the resistor-adaptor is a very good thing to have when dealing with prototyping and hard-core copyNES use. Some carts will actually crash copyNES (very rare.. very very rare) but if they do I have that adaptor. The main culprit was those Sachen games. Never had a problem with just regular old NES carts or most fami's except N106 which can cause problems since it has a register in the same space as copyNES' port chip... this is the only known conflict, however.
Update: I have the NES on NES emulator (hehe good term for it) going for the most part, but it's kinda buggy and I can't seem to find the bugs in the PPU emulation. I've posted the code for anyone who wants to look at it and possibly see if they can find a problem or two, but it may be kinda difficult to figure out without a real CopyNES or something :-/
Other than that, things are going good and I've been polishing the host software and such, and adding more features to it. That connector SHOULD be here this week or next, and then I will start accepting orders.
In the mean time, I have been writing a "CopyNES how to" guide on assembling the PCB, installing it in the console, etc. so when the part comes everything is ready.
Here's the code if anyone wants to poke around.
http://tripoint.org/kevtris/mappers/inc ... scopyn.zip
Note that I use some of those undocumented opcodes here and there to speed things up, and because they are so darned useful
Wherever they are used though is indicated in the code, since I had to enter them manually as a .db followed by a .dw. Unfortunately, the code is pretty hard-core. I've gone over the PPU operations with a fine-toothed comb and can't find anything amiss.
Btw if someone wanted to try running this on an emulator, they could do it by putting RAM at 4800-480f and commenting out the "use port chip" code and uncommenting the "use RAM" code (clearly marked). I was using the port chip registers that were free as extra RAM bytes to save space. "emul8" runs 1 instruction. Note that the actual 6502 emulation part works just fine, and it's only the PPU emulation that is somewhat buggy at the moment.
kevtris wrote:
Note that I use some of those undocumented opcodes here and there to speed things up, and because they are so darned useful
Wherever they are used though is indicated in the code, since I had to enter them manually as a .db followed by a .dw.
Tried making macros for those instructions?
I'm very excited about the CopyNes!
A couple of questions though:
1. I assume it will let me dump carts for at least most known mappers. Will it have any trouble with different boards in these mappers? I have a skeprom board that I'd like to dump without trying to desolder and use a eprom reader. Could people who have dumped using a copynes tell us how it's worked for them?
2. Is the software still dos? Has anyone had any luck with it in dosbox? Should I be looking for a 98 system right now?
3. Do you think there are enough going around that I may be able to get 2? I'd love to get a complete one and also try building one from a kit.
Thanks!
Anonymous wrote:
I'm very excited about the CopyNes!
A couple of questions though:
1. I assume it will let me dump carts for at least most known mappers. Will it have any trouble with different boards in these mappers? I have a skeprom board that I'd like to dump without trying to desolder and use a eprom reader. Could people who have dumped using a copynes tell us how it's worked for them?
Yes, it works with SKEPROM boards and should work with all other proto boards. Just dump it as a plain ol' MMC1 and it should be OK.
Quote:
2. Is the software still dos? Has anyone had any luck with it in dosbox? Should I be looking for a 98 system right now?
3. Do you think there are enough going around that I may be able to get 2? I'd love to get a complete one and also try building one from a kit.
Thanks!
Yeah the software is still DOS, unfortunately... not much I can do about this. It needs W98 or earlier to run because it uses direct port access. It *might* work with a driver on XP that allows direct port access, but I've never tried this so I don't know if it would work or not.
Yah there's enough to go around hopefully.
kevtris wrote:
Yeah the software is still DOS, unfortunately... not much I can do about this. It needs W98 or earlier to run because it uses direct port access. It *might* work with a driver on XP that allows direct port access, but I've never tried this so I don't know if it would work or not.
There is "UserPort" which many people from the early GBA scene (Flash Advance Writer and MBV2 cable) swore by.
Yeah, it "might" work under XP with userport.
Depends on how critical the timing is.
DosBox won't work because it doens't have parport support. Other options include FreeDos on one of the free PC emulators such as Bochs. There is another free PC emulator that I can't remember right now. I've used it on Linux and it works nicely. It has ports to Windows too. I think that the best bet is to open source the PC-side software, so that it can, unofficially, be ported to more modern operating systems.
What I would suggest doing if you have XP is to simply make a DOS 6.22 bootdisk and perhaps a small FAT partition. (My two 250GB RAID 0 drives are formatted for NTFS, but there is 16MB of unformatted space which would be perfect when combined with a CD of NES ROMs.) Whenever you needed to use CopyNES, simply use a bootdisk. Not the most convenient solution, but it will have to do for us advanced folks until someone writes an app that will support parallel ports in Win XP.
Many older Bung-type devices and other copiers have this same issue....must be run in 98 or 95. I have been meaning to make a second partition on my HD for a while. I have Partition Magic, but I have to reread the instructions on how to make a 98 partition. For all the copiers and things I can't use because of this, I'd better do this soon.
Jagasian had a good suggestion too...having it rewritten for XP. Or, maybe even something more portable...
-Rob
rbudrick wrote:
Jagasian had a good suggestion too...having it rewritten for XP. Or, maybe even something more portable...
-Rob
ucon64 supports many parallel port based backup units. If kevtris open'ed up the source code, I am sure they would add support for the copynes.
Jagasian wrote:
rbudrick wrote:
Jagasian had a good suggestion too...having it rewritten for XP. Or, maybe even something more portable...
-Rob
ucon64 supports many parallel port based backup units. If kevtris open'ed up the source code, I am sure they would add support for the copynes.
The source has ALWAYS been open - the client program is written in [uncompiled] QBASIC, and there will soon be a Win32 version available as well.
On a related note, I've run into the exact same issues with my prototype dumper (CopyCart). I've gone with a USB interface which hopefully still will have a lot of life in it, certainly more than parallel or serial ports. Also, I've written the PC side of the dumping software in Python. That way, it's 100% portable between linux and windows (and probably a lot more). Python is slow, but performance isn't an issue.
So what I'm saying is, it would be nice to have someone make an implementation in Java/Python or some other platform independent language. If I had a CopyNES I would volunteer, but my dumper is taking up all my time right now.
I've confirmed that the free and open source PC hardware emulator, QEMU, which can be used to run DOS, FreeDOS, Windows 98, and Linux on either Linux or Windows XP, in fact does support the PC parallel port. AFAIK, parallel port support is only available under Linux, Linux people have been using it for parallel-JTAG software that is Windows only. I have an old copy of Windows 98 SE floating around my house somewhere. I am going to try my GBX first.
Windows XP users might want to check out QEMU to see if they can parallel support working.
Is there some particular reason these devices continue to use parallel ports instead of, say, USB? USB interface ICs are ridiculously inexpensive (or so a college EE friend of mine tells me).
I'm just wondering, since a lot of hardware engineering folk -- even in 2005 -- still swear by the parallel port (which is being phased out, as we can see from the removal of legacy devices on some present-day motherboards).
Just curious.
I see USB as temporary, where the parallel port is timeless ;)
For USB, doing device->computer is very easy if you can use the built in HID drivers (mice, keyboards, etc). If you want to transfer data or do computer->device you need to write your own operating system specific drivers which is far harder than interfacing with the parallel port. It used to be very easy to program the serial and parallel ports, Windows just makes it harder for no reason.
My off topic problem with the CopyNES right now is that my keyboard stops working when a program is run in a dos window!
The reason the parallel port is used is because it's really easy to program it. USB isn't excessively difficult, but it certainly takes some study time. Also, dealing with the PP is very low level - write to a port and flip an io pin. USB is abstracted away pretty far by the OS, so you need to deal with some higher level abstractions (endpoints, interfaces, devices etc.). Lots of low level programmers/hardware people just don't want to spend the time to learn that stuff because it's not very interesting to them.
If you don't need wicked fast transfers, why not just use an
emulated parallel port over USB? Or is there too much latency for it to be useful (as is reportedly the case with USB network adapters and Nintendo DS Ni-Fi)?
Not a single one of those actually emulates a useful parallel port, I haven't seen one that's compatible with more than a printer.
There are however USB <-> ISA translators which may do the trick, not sure if anyone's tried that route.
Really though, if your computer doesn't have a parallel port, there are always PCI parallel ports... IMO, the only excuse why you shouldn't have a parallel port is if you own an Apple, someone should really develop a universal PCI-X card thinking of the future.
kyuusaku wrote:
there are always PCI parallel ports
Which don't work if every PCI slot in your machine is filled. This is likely on "compact" models, which place the PCI cards parallel to the mainboard in order to make the case thinner, such as a Dell Dimension 4500S. A network card and a FireWire card fill the machine's two slots. And even in a more typical ATX case, are quality PCI parallel ports affordable?
Quote:
IMO, the only excuse why you shouldn't have a parallel port is if you own an Apple
Don't be so quick to dis Mac owners. Several Nintendo products have used the same CPU as an Apple product:
- The NES used a "2A03" CPU with a 6502 core (minus decimal mode) and some custom I/O; the 6502 was used in the Apple II, II+, and original IIe computers. I learned 6502 assembly language on an Apple II.
- The Super NES used a CPU with a 65C816 core and some custom I/O; the 65C816 was used in the Apple IIGS computer. Nintendo built the first Super NES devkit around an Apple IIGS because it had a stable 65C816 assembler.
- The Game Boy Advance uses a CPU with an ARM7 core, and the Nintendo DS CPU has two cores, an ARM7 and an ARM9. The iPod music player and the Newton PDA have also used ARM cores.
- The GameCube uses a "GEKKO" CPU with a PowerPC G3 core and some custom I/O; the PowerPC G3 was used in several Macintosh models.
- The Nintendo Revolution will use a "BROADWAY" CPU which includes some sort of PowerPC core and some custom I/O.
Outside of Nintendo:
- Sega Genesis used the same off-the-shelf Motorola MC68000 processor as the original Apple Macintosh.
- Atari Jaguar and Sega Saturn used this same processor as an I/O processor.
- Sega Dreamcast uses an ARM7 similar to the GBA's to control the audio DSP.
- Microsoft Xbox 360 has three dual-thread PowerPC cores. The first Xbox 360 devkit was made of Mac hardware.
- The "Cell" in Sony PS3 has one dual-thread PowerPC core and seven DSPs.
How was I dissing Apple? I've had a love/hate relationship with Apple computers over a decade/over half my life. I have no idea why you felt the need to make a CPU list, are you implying Apple are CPU trendsetters for consoles? That might be the case or it might be coincidence, it's totally irrelevant. Not related but when Apple finally makes the switch to IA64 what will that mean to you? heh
I suggested the PCI-X card because I really do think someone should develop a parallel port compatible with modern computers (including Apples), it'd be one more push for me towards getting a G5 should uCON64 support that parallel port.
PCI parallel ports can be easily had for less than $20 shipped. I don't know what aspect makes one quality, all PCI cards I've seen are EPP compliant, it either works or it doesn't. If someone has a PC without integrated parallel port or a free PCI slot, they may want to reconsider their PC if they intend to interact with legacy hardware.
I'm personally adamant about parallel ports because I use the parallel port to communicate with dozens of backup devices and with 5 or 6 other devices which I cannot afford overpriced USB counterparts of such as my JTAG cables.
Quote:
Not a single one of those actually emulates a useful parallel port, I haven't seen one that's compatible with more than a printer.
There are however USB <-> ISA translators which may do the trick, not sure if anyone's tried that route.
Really though, if your computer doesn't have a parallel port, there are always PCI parallel ports... IMO, the only excuse why you shouldn't have a parallel port is if you own an Apple, someone should really develop a universal PCI-X card thinking of the future.
I have tried the latter two devices. I have an USB2-to-ISA converter that runs a particular midi sound card and do so very well. I also have a PCI Parallel Port (my DFI nF4 DR board no longer has one), and this runs DirectPadPro perfectly. Good solutions, but I think we should be looking forward whenever possible.