Kerm: I tried the Link test program that you gave me, and I monitored the USB (in linux using the kernel-level usbmon debug module), and I am getting nothing. If I fire up tilp-2, however, it gets responses just like it should (for example hitting the "Ready?" button causes both a submission on the USB line, and the appropriate response from the calculator)
So the silverlink is definitely not working right for GCN usage (or your link test program doesn't work with the TI-84+ SE)
Hmm, that's no good at all. I'm fairly positive the test program works on the TI-84+ series. What say we speak to the TiLP team and see what they say?
go for it
EDIT: From libticables/src/linux/link_slv.c
Quote:
/* TI-GRAPH LINK USB and direct USB cable support (lib-usb) */
/*
Some important remarks... (http://lpg.ticalc.org/prj_usb/index.html)
This link cable use Bulk mode with packets. The max size of a packet is
32/64 bytes (MAX_PACKET_SIZE/BULKUSB_MAX_TRANSFER_SIZE).
This is transparent for the user because the libusb manages all these
things for us. Nethertheless, this fact has some consequences:
- it is better (for USB & OS performances) to read/write a set of bytes
rather than byte per byte.
- for reading, we have to read up to 32 bytes at a time (even if we need
only 1 byte) and to store them in a buffer for subsequent accesses.
In fact, if we try and get byte per byte, it will not work.
- [ for writing, we don't store bytes in a buffer. It seems better to send
data byte per byte (latency ?!). But, this make data-rate significantly
decrease (1KB/s instead of 5KB/s).
Another way is to use partially buffered write operations: send consecutive
blocks as a whole but partial block byte per byte. This is the best
compromise and it works fine ! ] => not needed any more
- another particular effect (quirk): sometimes (usually when calc need to
reply and takes a while), a read call can returns with neither data
nor timeout. Simply retry a read call and it works fine. The best example
is to get IDLIST.
- for checking, under Linux, we use a hack by Kevin Kofler (based on the
libusb source code, and inspired by Romain's Windows driver). This is for
Linux ONLY, not for other POSIX-like systems (it directly uses Linux kernel
interfaces).
Of particular importance is that it read/writes in blocks rather than bytes (appears to be due to the silverlink and not a design choice), further eliminating any chance of an unmodified silverlink or similar to be used
If you read carefully, you can write byte by byte, but not read by bytes. You can, however, read a single byte by reading in a block and ignoring all but one.
KermMartian wrote:
If you read carefully, you can write byte by byte, but not read by bytes. You can, however, read a single byte by reading in a block and ignoring all but one.
/me cries over the inefficiency of it all
/me also cries over the lack of information about the clockline.
KermMartian wrote:
If you read carefully, you can write byte by byte, but not read by bytes. You can, however, read a single byte by reading in a block and ignoring all but one.
but thats ignoring that I need BIT PER BIT for GCN, as the silverlink doesn't understand it, and is ignoring it as bad data
However, I just got my PIC18F4550 and I'm going to test that out with GCN - should work quite well 
Excellent. Since it's been ten days, have you succeeded with this project?
Sorta. I got it all hooked up in a breadboard, but minus the USB (since it doesn't fit in the breadboard due to its 2x2 pin arrangement). I have a through-board to solder it to, but I haven't gotten around to doing that yet. There seems to be a problem with the schematic, though...
http://www.create.ucsb.edu/~dano/CUI/MediaInterfaceCircuit.jpg
Pins 31 and 32 have a .1uf and a 100uf capacitor between them (supposedly), but if I have the 100uf capacitor there, it won't work (as in it isn't recognized by the PIC programmer). I tried a different capacitor, and double checked that I had it in the right way. This is where I left off at. I'll get around to soldering it soon so that I can use the USB, but I didn't want to do that before I made sure that I didn't need the 100uf capacitor...
That usually should be a 100pF cap if I recall correctly... it's to dampen out noise from the power source.
ugh, I don't have one of those laying around - how critical is it?
Kllrnohj wrote:
ugh, I don't have one of those laying around - how critical is it?
Not very; you should be ok with just the 0.1uF cap.
cool - now I just need some free time...
Hmm, I might be able to solder this up tonight after work...
Kllrnohj wrote:
cool - now I just need some free time...
Hmm, I might be able to solder this up tonight after work...
Well? Did it work out, a month and a half ago?
KermMartian wrote:
Well? Did it work out, a month and a half ago?
Yes. I'll be making a new thread for it as soon as the video "proof" finishes uploading 
(<grumble> stupid configuration bits messing everything up for months and making me go crazy... </grumble>)
Kllrnohj wrote:
KermMartian wrote:
Well? Did it work out, a month and a half ago?
Yes. I'll be making a new thread for it as soon as the video "proof" finishes uploading (<grumble> stupid configuration bits messing everything up for months and making me go crazy... </grumble>)
YAY!!!!! PWNIFY!!! hehe, idea: buy mouse, remove buttons, make gCn cable
Mouse wouldn't work (as it would be rather hard to use your computer if your mouse is flipping out clicking randomly
), but a joystick or gamepad would totally work (I'm guessing) - at least, I see no reason why it wouldn't (other than perhaps it not being fast enough to keep up)
heh joysticks tend to be more expensive.....
how much would it cost you to manufacture and sell these?
I don't see why a mouse wouldn't work - can't you do some usb higgery-jiggery any disable the mouse cursor movement while a transfer is in progress...
KermMartian wrote:
I don't see why a mouse wouldn't work - can't you do some usb higgery-jiggery any disable the mouse cursor movement while a transfer is in progress...
No, at least, not that I know of without writing a driver. It is possible in Windows, as you can 'layer' drivers (so I could filter the events that are passed on to the HID driver), but I know of no way on Linux, or that doesn't involve writing a driver (which can lead to blue screens and other such nasties if it fails). Besides, disabling the cursor would prevent the computer from being used - which would probably piss off just about everyone who decided to use a USB mouse for this
@Elf: It cost about $25 in parts, but you could get by with a smaller chip (say, a 20 pin one instead of the 40 pin one I used). Here is the product page for the chip used, and the gcn is obviously only using 2 of the many I/O pins available (16): http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1335&dDocName=en010300
Also, I see no reason why a parallel port cable can't be used, I just don't have a parallel port on my new computer to try it with
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
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
