|
ToToTEK.COM Help & Support Forum
|
View previous topic :: View next topic |
Author |
Message |
alaterale
Joined: 08 Jan 2008 Posts: 8
|
Posted: Tue May 12, 2009 8:45 pm Post subject: |
|
|
I realize this is an extremely old thread, but I figured I could post some good news. I have finally found one of those devices that does hold the USS720 chip. I didn't end up buying from that place I linked to, but found someone selling the detachable cable version.
Anyway, I'm soon enough going to see what I can do in terms of getting this thing to work with my Super Flash. I'll let you guys know how it goes. I hope since this is one of the few USB->Parallel devices that offers "register" mode or full usage or whatever its called, that I will have some kind of success.. |
|
Back to top |
|
|
alaterale
Joined: 08 Jan 2008 Posts: 8
|
Posted: Tue May 12, 2009 9:43 pm Post subject: |
|
|
Okay, even on just using the ubuntu livecd I was able to get ucon64 running by doing a quick ram compile. But I've run into a problem. Although the system is recognizing the module and turning it on (dmesg), I don't think it's actually assigning the hardware to any actual printer port, and all I get is a base address of 0x0 (not 376 or whatever).
I can read in files, but I imagine it's just static noise atm. No matter what port that shows up I try (the new parportX device files), I get the same thing. Not to mention, I get this message in dmesg:
"partport0: fix this legacy no-device port driver!"
So, I imagine that even though the driver works, I'm missing something to actually get it to see that I have hardware attached. Everything else on dmesg looks fine, and it does say that this hardware can be used for bitbang, which would be necessary for this to work beyond just a simple printer interface.
I also did a random test to see if something like:
ucon64 --xsf --port=/dev/lpasdfasdfas test.bin
would give me the same result, and it does. It gives you a static filled file at first, and the second time you enter the command, it tries to upload that file (standard ucon64 stuff), but then you see the message that it's not seeing the programmer. Same exact results, so I think it's just a linux problem right now.
Anyone here a linux expert that can help make this hardware truly visible as a device driver? I feel like if I could get bitbang working at all on this, I'd have a better shot to see if the programmer works. It's a pity I don't have some other parallel device (aside from my GB transferer which has no linux software support), to test out, but maybe I can pick up a scanner at a salvation army or something. Then it could also be my gender changer for the uss720 device, but I dunno about that. I imagine it's not because even without the gender changer device attached I can't get a realistic base-addr for the converter.
Last edited by alaterale on Tue Mar 22, 2016 2:39 am; edited 1 time in total |
|
Back to top |
|
|
kyuusaku
Joined: 26 Jul 2003 Posts: 941 Location: .ma.us
|
Posted: Wed May 13, 2009 6:09 pm Post subject: |
|
|
Even with the adapter in bit bang mode, remember you're still limited to full speed USB's 1000 frames/second/endpoint and the fact that copiers typically need 2-4 accesses per byte. If the chip were a microcontroller, and the copier had a predictable protocol (or entire copier protocol in the firmware) data could be pipelined up to true LPT speed or faster (especially in buffered EPP mode), but I'd be surprised if the adapter could just reliably handshake with SPP copiers...
Edit: looking at the USS-720 datasheet, while it's not specified outright (EPP section kinda hints at it) it does appear the maximum unbuffered I/O speed is ~1 kilobyte/s which is to be expected if all it uses is it's one control endpoint.
For now I really think the best solution for new computers are full PCIe cards for desktops and ExpressCards for notebooks. |
|
Back to top |
|
|
alaterale
Joined: 08 Jan 2008 Posts: 8
|
Posted: Wed May 13, 2009 6:31 pm Post subject: |
|
|
Darn, I didn't know it was limited by USB 1.0. I was hoping it was 1.1 or (hopefully) 2.0 capable. Well, still, is it so limited by speed though? Even if it transfers slowly, wouldn't it still work if it's only one direction (read or write)? I don't think anyone would mind having it work slow for writing as long as it got there, unless there's some kind of constant checking/timing stuff as the writing is going on? Is 1 kilobyte/s really too slow for writing?
By the way, I looked at the datasheet below, it seems that the forward rate is pretty high, so could this at least be used to read from carts at a fast enough rate for the programmer? Could at least be used to help people backup their originals
digilander.libero.it/demarchidaniele/qcamvc/uss-720.pdf
Certainly, you're more of a hardware expert than I, I'm just trying to find some kind of solution for this. Maybe there is a microcontroller chip out there in an adaptor that supports USB 2.0 or at least meets what these programmers would require. I can't see how it's technically impossible to achieve this kind of thing, just that maybe no one has bothered yet
In any case, I'm still going to try to get this hardware working properly in linux so I can at least test it out. Still finagling with getting it properly usable anyway. |
|
Back to top |
|
|
alaterale
Joined: 08 Jan 2008 Posts: 8
|
Posted: Wed May 13, 2009 6:56 pm Post subject: |
|
|
Additionally, for future usb-to-parallel adaptors (or anyone wanting to make a hobbyist adaptor for these programmers), I noticed this earlier:
http://www.soselectronic.com/?str=675
Not in production yet, but looks promising for high speed transfers (since it uses USB 2.0). Maybe someone with some engineering knack can hack one together when it comes out? I know I'd be willing to pay for one if it worked Maybe tototek could couple such a cable together with the parallel programmers for new buyers I guess. Anyway, that would be a ways off. |
|
Back to top |
|
|
kyuusaku
Joined: 26 Jul 2003 Posts: 941 Location: .ma.us
|
Posted: Thu May 14, 2009 1:04 am Post subject: |
|
|
The USS-720 is USB 1.1 and it is a "full speed" device.
The issue with copiers is that most implement a software handshake. The computer strobes/copier polls for strobe, copier acknowledges/computer polls for acknowledgement and the process repeats. Every single byte transferred this way requires two reads and two writes. Regardless of the USB frame payload, if you can only get 1000 frames per second, you're limited to 1000 bytes per second since parallel ports are 8-bit devices. Theoretically you could transfer at such a slow speed but copiers may implement timeouts...
FTDI chips aren't suitable either, their speed comes from buffered I/O. Whenever your application relies on reads and writes back to back, USB will fail at it. Even in "high speed" (480M) mode, the parallel port performance will be poor, but maybe acceptible, I can't find the figures at the moment via Google. USB 3.0 may offer enough frames/second to do the job, I'm not sure.
Really there are two ways to do it: wait for a USB interface with sufficient frames/sec, or run custom transfer code on a microcontroller which can bulk transfer the data to/from the computer. The second method is the most reliable, but would be a ton of work. |
|
Back to top |
|
|
alaterale
Joined: 08 Jan 2008 Posts: 8
|
Posted: Thu May 14, 2009 1:21 am Post subject: |
|
|
I see what you mean now. I figured with 2.0 they would have increase the frames per second but if they didn't, then it makes sense why it would be slow.
Last edited by alaterale on Tue Mar 22, 2016 2:36 am; edited 1 time in total |
|
Back to top |
|
|
kyuusaku
Joined: 26 Jul 2003 Posts: 941 Location: .ma.us
|
Posted: Thu May 14, 2009 2:15 am Post subject: |
|
|
alaterale wrote: | Btw, when you say the copier, you mean the firmware on the programmer board right? |
Strictly hardware based units like Tototek's most likely don't have a handshake at all so they're probably suitable for buffered programming. Reading/verifying would be an issue though since the hardware needs a write (EPP) or two (SPP) to latch the data and increment the address.
alaterale wrote: | Since you're familiar with these kinds of transfer protocols, would firewire (400 or 800) handle this problem? |
I'm not sure, but I haven't heard of any hobbyist Firewire projects... I don't think it'd be remotely as easy to pull off. |
|
Back to top |
|
|
RGB_Gamer
Joined: 01 Oct 2007 Posts: 879
|
Posted: Mon Jul 20, 2009 2:28 am Post subject: |
|
|
I know this thread is old, but my laptop has no parallel port. Has anyone gotten a PCMCIA parallel port card to work with any of the tototek parallel port products? |
|
Back to top |
|
|
rbudrick
Joined: 26 Mar 2004 Posts: 373
|
Posted: Wed Jul 22, 2009 4:41 am Post subject: |
|
|
I think there has been discussion of this before in more than one thread and the answer was no, no one has. Generally, desktop parallel ports have better compatibility than parallel ports that are even built into laptops, let alone the PCMCIA ones.
-Rob |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You can attach files in this forum You can download files in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|