| View previous topic :: View next topic |
| Author |
Message |
neviksti
Joined: 08 Mar 2004
Posts: 9
|
 Posted: Sun Aug 29, 2004 5:13 am Post subject: |
 |
|
Is it possible to make a device driver that all software must go through to access the parallel port? Then you could easily see what the protocal was.
There's definitely provisions in the CPU itself to do something like this. So I'd be amazed if it couldn't be done ... plus, it would be useful enough that there's probably software that already does just that.
EDIT: How does the software currently obtain access to the parallel port in Win XP or NT environments? Is there a DLL?
(I don't own a tototek flash cart yet. If I do get one, you can bet that I'll be tearing through it. So maybe I'll be able to help with the reverse-engineering.) |
|
| Back to top |
|
 |
JohnDie
Joined: 12 Jul 2004
Posts: 28
Location: Germany
|
| Posted: Sun Aug 29, 2004 10:42 am Post subject: |
|
|
| neviksti wrote: | How does the software currently obtain access to the parallel port in Win XP or NT environments? Is there a DLL?
(I don't own a tototek flash cart yet. If I do get one, you can bet that I'll be tearing through it. So maybe I'll be able to help with the reverse-engineering.) |
It uses a driver from http://www.specosoft.com/en/zlportio.html. |
|
| Back to top |
|
|
The Dumper
Joined: 05 Oct 2003
Posts: 49
|
| Posted: Sun Aug 29, 2004 4:18 pm Post subject: |
|
|
| Source code is nice, of course, but even if they don't want to release source it would help immensely if they released the hardware programming manual. Is this possible? |
|
| Back to top |
|
|
neviksti
Joined: 08 Mar 2004
Posts: 9
|
| Posted: Sun Aug 29, 2004 7:20 pm Post subject: |
|
|
Well, it looks like the driver allows:
{ 1.20: + Added new function (zliosetiopm) for enabling direct access to ports}
So they might not be going through the driver anyway. So we might not be able to trap the read/writes easily by modifying the driver.
| The Dumper wrote: | | Source code is nice, of course, but even if they don't want to release source it would help immensely if they released the hardware programming manual. Is this possible? |
?? hardware programming manual
I may just be messy, but usually I don't have documentation worth sharing for the devices I make (at least when I know that only I need to work with the info). It's probably something similar here.
Anyway, dbjh can you clarify?
They won't share source code AND they won't answer questions about the protocal? |
|
| Back to top |
|
|
dbjh
Joined: 02 Aug 2003
Posts: 167
|
| Posted: Sun Aug 29, 2004 10:34 pm Post subject: |
|
|
| neviksti wrote: | | So they might not be going through the driver anyway. So we might not be able to trap the read/writes easily by modifying the driver. |
The official software most probably doesn't use zlportio.sys under Win 9x/ME. I think zlportio.sys is an NT device driver. So, if you want to reverse engineer the official software by analysing the I/O you should do it under Windows NT/2000/XP. I myself am not a fan of reverse engineering by looking at the I/O.
| neviksti wrote: | | The Dumper wrote: | | Source code is nice, of course, but even if they don't want to release source it would help immensely if they released the hardware programming manual. Is this possible? |
?? hardware programming manual
I may just be messy, but usually I don't have documentation worth sharing for the devices I make (at least when I know that only I need to work with the info). It's probably something similar here.
Anyway, dbjh can you clarify? |
I asked if we could at least get some specifications. I'll let you know when I know more.
| neviksti wrote: | | They won't share source code AND they won't answer questions about the protocal? |
It's not as simple as that. It would be nice if Tomy posted a message so that I know what I can and what I cannot say. For now I think we're on our own. BTW JohnDie could dump the contents of his flash card with the MD-PRO code (-xmd). |
|
| Back to top |
|
|
The Dumper
Joined: 05 Oct 2003
Posts: 49
|
| Posted: Mon Aug 30, 2004 5:05 am Post subject: |
|
|
| neviksti wrote: | ?? hardware programming manual
I may just be messy, but usually I don't have documentation worth sharing for the devices I make (at least when I know that only I need to work with the info). It's probably something similar here. |
True, if I were developing something for myself I'd probably be remiss about making a good manual. But, usually when a company develops a product to sell the company creates product documention, to help sell its product and to insure that it can continue development even if the original developers leave the company. So, unless we're dealing with a one person fly by night company I'd expect some documentation to exist. Tototek should have it. They may not be licensed to distribute it though since from what I'm hearing they just resell the product, they didn't develop it.
It looks like we do it the fun way. |
|
| Back to top |
|
|
JohnDie
Joined: 12 Jul 2004
Posts: 28
Location: Germany
|
| Posted: Tue Aug 31, 2004 5:08 pm Post subject: |
|
|
| Just wanted to say, that we made some very good progress with this. I'm really confident that it'll be supported soon. |
|
| Back to top |
|
|
Jagasian
Joined: 08 Jun 2004
Posts: 159
|
| Posted: Wed Sep 01, 2004 8:50 pm Post subject: |
|
|
| JohnDie wrote: | | Just wanted to say, that we made some very good progress with this. I'm really confident that it'll be supported soon. |
...thats good because I think I found an old copy of Windows 98, and I was considering installing it, but I an too chicken to repartition my ext3 formatted drives to make room for a Windows 98 install. I would also have to make sure that I do not set up any kind of networking so that it doesn't get hacked. This would mean that I would have to copy roms onto the Windows partition from Linux...
That whole mess and the fact that I do my best to avoid Microsoft products, and well it would just be nice to keep my Linux uptime. |
|
| Back to top |
|
|
dbjh
Joined: 02 Aug 2003
Posts: 167
|
| Posted: Sun Sep 05, 2004 9:26 pm Post subject: |
|
|
JohnDie finished adding initial Super Flash support. Grab the source code from CVS. You can get the loader from the uCON64 home page.
Dumping cartridges is not yet supported, but uCON64 already has one advantage: you can write Tales of Phantasia *and* another game (smaller or equal to 16 Mbit) to the same flash card. |
|
| Back to top |
|
|
Jagasian
Joined: 08 Jun 2004
Posts: 159
|
| Posted: Tue Sep 07, 2004 10:00 pm Post subject: |
|
|
| dbjh wrote: | JohnDie finished adding initial Super Flash support. Grab the source code from CVS. You can get the loader from the uCON64 home page.
Dumping cartridges is not yet supported, but uCON64 already has one advantage: you can write Tales of Phantasia *and* another game (smaller or equal to 16 Mbit) to the same flash card. |
Hehehe, I figured you guys would add some features to uCON64 that wouldn't be available elsewhere  Another useful feature would be an option to auto-hack ROMs so that they don't wipe-out eachother's save information. It might be hard to automatically recognize save game access points... but I bet it could be done with some flow analysis, so as to differentiate between code and data - not possible in general (i.e. would break some games), but then again it would be an option... and I bet it could be made to work for most games.
By the way, why couldn't the SuperFlash software put ToP and another game on the same card at the same time? I have yet to get to ToP... but I am systematically playing and completing every SNES game ever made  |
|
| Back to top |
|
|
matty_m
Joined: 12 Aug 2004
Posts: 6
|
| Posted: Sat Sep 11, 2004 10:41 pm Post subject: |
|
|
I can't seem to compile the CVS code correctly, I keep getting the following errors:
parallel.obj : error LNK2001: unresolved external symbol _inp
cd64.lib(cd64io.obj) : error LNK2001: unresolved external symbol _inp
parallel.obj : error LNK2001: unresolved external symbol _inpw
parallel.obj : error LNK2001: unresolved external symbol _outp
cd64.lib(cd64io.obj) : error LNK2001: unresolved external symbol _outp
parallel.obj : error LNK2001: unresolved external symbol _outpw
ucon64.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
I'm using VC++ 6.0....but its been a long time since I've coded so any help would be great. |
|
| Back to top |
|
|
dbjh
Joined: 02 Aug 2003
Posts: 167
|
| Posted: Mon Sep 13, 2004 7:24 pm Post subject: |
|
|
Thanks for trying to compile the code yourself. I'm always interested to know if something is missing from the FAQ.
Could you perhaps describe the steps you took? You reached the linking phase, so the compiler *did* find declarations/prototypes of the I/O functions. Stranger still, inp{w}() and outp{w}() are macro's, so you shouldn't get linker errors. Are you compiling via nmake (from the command line)? Did you change any settings? Did you follow the steps as described in the answer to question 3 of the FAQ?
[edit]
I checked your other posts. I hope I don't disappoint you, but dumping cartridges is not yet implemented. Implementing that functionality is not very difficult, but takes time and a Super Flash ;-) I think I will order one this month (if there's enough money left after paying all my bills). |
|
| Back to top |
|
|
matty_m
Joined: 12 Aug 2004
Posts: 6
|
| Posted: Mon Sep 13, 2004 8:35 pm Post subject: |
|
|
Hi, I followed the instructions on the ucon64 website exactly. I'm following the VC++ instructions, so I am using nmake like it says. Its strange, I cant seem to figure out why this error is showing up. Maybe Ill try my hand at the djgpp version when I get a chance.
... will there be a windows binary of this cvs code released anytime soon? if its soon, I'll just wait for that, I'm a busy man haha. |
|
| Back to top |
|
|
dbjh
Joined: 02 Aug 2003
Posts: 167
|
| Posted: Mon Sep 13, 2004 9:09 pm Post subject: |
|
|
| matty_m wrote: | | Maybe Ill try my hand at the djgpp version when I get a chance. |
If you would like to try another compiler I suggest MinGW. Like DJGPP, also a port of GCC, but it creates Windows executables - a bit more useful when you're using Windows NT.
I don't know why the code doesn't compile with your VC setup. IIRC my VC setup is patched with Service Pack 5.
| matty_m wrote: | | ... will there be a windows binary of this cvs code released anytime soon? if its soon, I'll just wait for that, I'm a busy man haha. |
:-) I'm waiting for Dirk's final patch. After that I expect that it will take another week before I'm comfortable enough with the code to release binaries.
I could send you a binary if you want. Just PM me your e-mail address. Of course, I would prefer to hear about your experiences with MinGW ;-) |
|
| Back to top |
|
|
DragonBoy
Joined: 18 May 2004
Posts: 9
|
| Posted: Thu Oct 14, 2004 9:31 am Post subject: |
|
|
dbjh, could you please explain how to download the source from cvs please? I tryed the links in the faq but they're not working. Also I found that link: http://cvs.sourceforge.net/viewcvs.py/ucon64/ucon64/src/ but I can't download all the files at once,only one at the time  . Is it possible that you or someone else pm/email me or explain here how to get them?  |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
