Talk:83Plus:OS:84 Plus USB Information

From WikiTI
Revision as of 21:06, 9 July 2005 by Dan Englender (Talk | contribs)

Jump to: navigation, search

I read the bit about device PIDs and theorized that the 89T was the 000F that it rejected... I hooked it up to my computer and it reported PID=E004, which isn't even an option from what he said. Also, in #wikiti: <+Kalimero> exactly, and 84P has pid E008, which makes me think that it drops the E for OnTheGo transfers.. That explains that, but not what the other devices are. I think it'd be safe to theorize that the ViewScreen adapter would be "allowed", but... Didn't it come out after the calculators, so it would have a higher PID? Hold on, I just had another idea in #wikiti: <Andy_J> looking at the PIDs, it would seem that the 84+SE might be 0003, then the 89T would be 0004, then some mysteries, and the 84+ being 0008... maybe they originally planed to just have the 84+SE? So if that were the case, what are 0005 through 0007? Just some random ideas to throw out there. --AndyJ 08:11, 27 May 2005 (PDT)

I'm doing my testing on an 84PSE, by the way. I assume everything about the regular 84P is the same, but I don't have one to check. The CBL2 has to fit in there somewhere. I have one in Ann Arbor, so when I go back there I'll check the PID. This code (that looks for 0008, etc) isn't necessarily the total "allowed" list either, as the code that checks for Vernier devices is elsewhere, it's just some random code that I stumbled upon and thought I'd mention, even though I wasn't planning on checking into the details at the moment. --Dan Englender 11:32, 27 May 2005 (PDT)
Alright, throw that theory out the window. :D --AndyJ 12:02, 27 May 2005 (PDT)
By the way, the 0008 vs E008 has a simple explanation: I was typing up the page at 6 AM and my brain wasn't working very well. I meant E008, E00F, and E003. Oops :) --Dan Englender 12:39, 27 May 2005 (PDT)
In the course of doing some other research, I found that Andy was (almost) right. E008 is the 84P SE, E003 is the 84P regular. Still don't know what E00F is.
From what you've written, it sounds like E00F is almost certainly the presentation link, given that (A) connecting the presentation link presumably requires the screen to be refreshed, and (B) having the presentation link connected prevents any other (software driven) USB devices from being used. From which I suppose we can infer that TI has no plans to support hubs :) FloppusMaximus 10:00, 15 Jun 2005 (PDT)

More info on those PIDs: On Ti-89 Titanium, the only PIDs which seem to be accepted are E004 (Titanium) and E00E (???). Also Romain Liévin pointed out to me a few months ago that Texas Instruments's Win32 driver supports this list of PIDs: 

%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E003 => TI84+
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E004 => Titanium
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E008 => TI84+SE
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E009
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00A
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00B
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00C
%DESCRIPTION%=DriverInstall,USB\VID_0451&PID_E00D

--ExtendeD 16:16, 29 Jun 2005 (PDT)

Ok, I speculate that E00F is the 84+ ViewScreen adapter and E00E is the 89T ViewScreen. We won't know for sure until we get our hands on one of each. --AndyJ 17:57, 29 Jun 2005 (PDT)
I agree that that seems likely. Also, the CBR2 can connect somehow to the 84 via USB. I'm not sure whether it will have a TI or a Vernier ID though. I don't really want to drop the dough for that one to find out. I may buy the Vernier EasyLink when it comes out though. --Dan Englender 19:07, 29 Jun 2005 (PDT)

Source

>> Source code will be going on SourceForge sometime in the near future.

What's the project name, or do you not have it made yet? --AndyJ 14:55, 28 Jun 2005 (PDT)

Haven't made it yet. I hate the overhead of having to use SourceForge, so I'm avoiding it as long as possible. --Dan Englender 15:16, 28 Jun 2005 (PDT)

Ports

Dan: did you notice, as on Titanium, that 0 was written to port 2E instead of port 8E, in the routine handling device requests, before sending an "ACK without data phase", to select endpoint 0? For the other types of acknowledgement (NAK and "ACK with data phase"), its 8E, as you have written. --ExtendeD 13:43, 30 Jun 2005 (PDT)

This isn't the case on the 84P. Regardless of whether there's a data phase, a value of 0 is sent out port 8E. (Port 2E isn't a USB port on the 84P either.) As for the command ports though, I still haven't quite figured out port 94 vs port 91 yet though. It seems like 94 is used for interrupt transfer, and 91 is used for both control and bulk, but I can't see why that makes sense. --Dan Englender 21:42, 30 Jun 2005 (PDT)
This may sound silly, but could it be that the port 2E on the titanium is a typo? Because if endpoint 0 was currently selected by a previous command (which it probably was if you're doing standard device requests), you could probably leave out the setting of port 8E altogether. I only ask because I've found a few very silly typos in the 84P USB code which only happen to work by "luck". --Dan Englender 21:47, 30 Jun 2005 (PDT)
By the way here are the ports used in the USB code of the Titanium, that you haven't yet mentionned:
22, 24, 26, 27, 29, 2E, 2F, 31, 32, 34, 39, 4A, 54, 56, 57, 5A, 67, 81, 89, 8B, 92, 95, 96, 98, 99, 9A
The ports used for output on the 84P are: 39, 3A, 4A, 4B, 4C, 4F, 50, 54, 57, 5B, 80, 81, 87, 89, 8B, 8E, 8F, 90, 91, 92, 93, 94, 95, 98, 9A, 9B. I haven't made a completele list of the input ports yet, but it's something like 39, 3A, 4C, 4D, 4F, 57, 81, 82, 84, 86, 87, 89, 8B, 8C, 8E, 8F, 90, 91, 93, 94, 98, 9A. So it looks like your 80s and 90s might be mapped the same as the 84P, but maybe the other ports aren't? --Dan Englender 12:13, 1 Jul 2005 (PDT)
About port 94: the only bit I have figured out is bit 5: setting it stalls the OUT bulk endpoint (this is what is done when SET FEATURE is sent for feature ENDPOINT_HALT). To unstall the endpoint, 34:7 is set and 34:5 is cleared.
Note that the ports and bits are different for the IN bulk endpoint: 31:4 is set to stall it, 91:6 is set and 91:4 is cleared to unstall it.--ExtendeD 11:20, 1 Jul 2005 (PDT)
Yes, this seems very similar to what's going on on the 84P, but instead of using 31/91, just 91 is used, and instead of 34/94, just 94 is used. But the bits to stall and clear the stall are the same. --Dan Englender 23:29, 1 Jul 2005 (PDT)
Could it be that the 2x ports on the Titanium are 8x ports on the 84+ and the 3x ports are 9x ports? That would make the numbers nicely match up. Maybe the Titanium separates input and output ports that way, whereas the 84+ mixes them? -- Kevin Kofler 17:04, 6 Jul 2005 (PDT)
Actually AMS sometimes uses 2x ports, sometimes 8x ports, and this is the same for ports 3x/9x. There doesn't seem to be any logic in the choice (actually for some ports there is, and for others there isn't). Maybe there are some mirrors in the 7100xx range, and TI is using the possible addresses indifferently (perhaps for debugging purposes, using data breakpoints!). I have asked Romain Liévin to check this on a real Titanium. --ExtendeD 02:30, 7 Jul 2005 (PDT)

I've had a thought that may be nonsense, but also might not be. I'll need to verify it later. It seems like most, if not all, of the ports in the 9X range have two versions: one for incoming pipes and one for outgoing pipes. For example, 90 and 93, 92 and 95, 98 and 9A all seem very similar both based on when they're called, and the values set. It also may be that more than just A0, A1, and A2 can be used for data. Using ports 98 or 9A it might be able to set up other pipes. --Dan Englender 00:18, 1 Jul 2005 (PDT)

I agree that these ports are similar. I would also add 99 and 9B (bInterval), and 87 and 89 (???).--ExtendeD 11:22, 1 Jul 2005 (PDT)

Dan, there is something I don't understand in Titanium's code, perhaps you can help me: only 2 routines write to port A0. The first one writes a packet, reading from a buffer in RAM. The second one that I don't understand) sends a packet formatted like this: 0 | something (seems to be 3 or 6) | address.lower | address.upper | endpoint.lower | endpoint.upper | something (seems to always be 0) | something (seems to always be 0). I am quite sure "address" and "endpoint" represent a device address and an endpoint, but I really can't figure out when this would be sent. Do you have something similar on 84P? --ExtendeD 16:30, 1 Jul 2005 (PDT)

I don't think there's anything like that on the 84P. The closest I see is that during USB device initialization for calc<->calc, a Set Feature of 3 and 4 are sent (00 03 03 and 00 03 04, with the rest of the packet 00). The receiving calculator plays with a couple of memory addresses when it gets these, but doesn't seem to do anything meaningful. What do you mean by address.upper and endpoint.upper, as these aren't 16-bit values. Just a 0? I, also, am not sure what it could be. Do you know if the code is ever actually called in the course of normal calculator operation? I ask because there seems to be some leftover unused code in the 84P operating system that might have been debug code or something like that. --Dan Englender 21:16, 1 Jul 2005 (PDT)
Ok, I have found out, I was completely wrong. The routine sends a setup packet (the "setup stage" of a control transfer). What helped is the Titanium's equivalent of your "5290 BCALL" I have located (by the way I am ok with what you have written about the max size of 8 bytes for the first request). --ExtendeD 03:25, 2 Jul 2005 (PDT)

Hi guys. I'm leaving tomorrow for a week on vacation. I wont have internet access, so I wont be able to post any updates. I'll take along a laptop and will hopefully get some work done, though, so I'll have updates to post when I get back. I'll try to have another cool demo to show :) --Dan Englender 22:07, 1 Jul 2005 (PDT)

I'm back. Unfortunately I forgot to bring with me some of the files I needed, so I didn't get much done. Oh well. --Dan Englender 16:01, 9 Jul 2005 (PDT)

Dan, I agree with your thoughts on ports 9A and AX. Port 9A is used to configure the type of an endpoint. BTW the USB controller supports 3 endpoints, (either as a device or host), 2 of which (at the most) can be in endpoints (IN means "from you to me", ie not in the USB-sense where the host is taken as reference). I don't know if this limit of 2 inendpoints is only a soft one, or a real limit of the USB controller. --ExtendeD 12:21, 2 Jul 2005 (PDT)

Quoting Dan from #WikiTI via his cell phone: 
[15:38:45] <Dan_E> I See What Extended Is Saying About The Three end points from looking at port data        
[15:41:02] <Dan_E> but the whole ax range seems to be mapped as oppossed to the bx range so maybe its an init thing
[15:42:04] <Dan_E> can someone post that to the wiki.  thanks.
--AndyJ 16:26, 2 Jul 2005 (PDT)
[Thanks AndyJ]. So perhaps this limit is only a software one. Anyway the Titanium's OS won't go further than A3. --ExtendeD 01:26, 3 Jul 2005 (PDT)
The 84P OS doesn't use anything past A2. What does the titanium use A3 for? --Dan Englender 16:01, 9 Jul 2005 (PDT)

New stuff of the day which may help you:

- I agree that 8F:2 set means 'calculator-as-host'.

- The features set by 'set feature' device requests which seem to be not standard ones are actually On-The-Go features. These features are not really interesting, except the "Host an Negociation Protocol" enabling which may be used during calc-to-calc transfers (controlled by port 8F:1). Here is a copy/paste of a part of the corresponding structure of Titanium's OS : 

...
int f_remote_wakeup : 1; // PERIPH - feature #1 (DEVICE_REMOTE_WAKEUP, USB specs). If set, the Titanium has remote wakeup enabled  and can wake the host up during suspend.  Read/Write. Doesn't seem to do anything.
int f_b_hnp_enable : 1; // PERIPH - feature #3 (UOTG_B_HNP_ENABLE, OTG specs). Only written. The only feature which may be set by AMS when the Titanium is acting as host. Cannot be cleared. 8F:1 set to enable HNP.
int f_a_hnp_support : 1; // PERIPH - feature #4 (UOTG_A_HNP_SUPPORT, OTG specs). Only written. Doesn't seem to do anything. Cannot be cleared.
int f_a_alt_hnp_support : 1; // PERIPH - feature #5 (UOTG_A_ALT_HNP_SUPPORT, OTG specs). Only written. Doesn't seem to do anything.  Cannot be cleared.
...

- I have started a documention on some ports you have not talked about, or are not yet really detailed. You can integrate this to the Wiki if it also corresponds to the 84P's USB hardware and seems to be correct. http://membres.lycos.fr/extended/usb/titanium_usb_hw.txt . Also can you check what you have written on port 87? I am quite sure of its functioning on Titanium, but it does not appear to follow what is in the Wiki. --ExtendeD 09:06, 4 Jul 2005 (PDT)

I have now quite a good view on control transfers from the host point of view. For port 91, "42 - Done reading data on port A0. (Send an ack?) (host)" should be "Send an OUT token" (see 8.5.3.1 of the USB 2.0 specs). --ExtendeD 10:56, 4 Jul 2005 (PDT)

Dan, for your USB project, are you planning to "hook" the OS (I do not know anything of Ti-83/84+ programming and how this can be done), or to rewrite the whole USB stack? For your mouse demo, did you use any hooks? I am personally thinking of rewriting the stack, but I am still not sure whether some part of the Titanium's OS can be easily reused without confliting with files transfers. BTW I will soon need a real Titanium, I am ready to buy a secondhand one at a reasonable price, if somebody needs to get rid of one... --ExtendeD 12:39, 6 Jul 2005 (PDT)

So far I've written the initialization and set-up completely by hand, but managed to "hook" part of the OS interrupt routine for the purposes of retrieving USB interrupt data (e.g. the mouse demo). I had some problems on my preliminary tests trying to get this method to work with bulk data. So, I may have to use my own interrupt routine do everything without any OS help. --Dan Englender 16:13, 9 Jul 2005 (PDT)

"The presentation link (...) appears to request 16 byte packets?" On Titanium, device E00E has a max packet size of 32 (max_packet_size >> 3 is written to port 90). --ExtendeD 14:06, 9 Jul 2005 (PDT)

I will check this again on the 84P --Dan Englender 16:13, 9 Jul 2005 (PDT)
I checked again and the E00F does in fact use a max packet size of 16 bytes. I guess there's the bigger screen to contend with on the 89t, but I don't really see why TI didn't just make them both the same. *shrug* --Dan Englender 18:33, 9 Jul 2005 (PDT)

In regards to your (ExtendeD's) text file:

  • Port 22/82: I'm not completely sure I agree with your explanation, at least for how it functions on the 84P. From what I see it looks like it may represent whether the last packet (or command) was successfully sent, as you say, but each bit I think may specifically represent a different pipe. Bit 0 for port A0, bit 1 for port A1, bit 2 for port A2. Probably the higher bits are for the higher Ax ports, but these aren't used on the 84P.
  • Port 24/84: I agree with your description.
  • Port 87: The only thing the 84P does to this port is output FF, 7F, 00, or set bit 0. I can't see how this would coorespond to the description you've given it, so perhaps the 84P and 89t differ in this respect.
  • Port 89: I have to look in more detail to see what port 89 is doing on the 84P
  • Port 8F: Your description seems to be accurate for the 84P as well. The 84P also reads the value of bit 7, though. I haven't determined what this is for yet. Does the titanium check this bit?
  • Port 96: I agree with your description. The 84P doesn't use port 97. But it also doesn't transfer packets larger than 256 bytes.
  • "Is this distinction always necessary for port 91?" - On the 84P, sometimes the values are output without regard for the current port value, and sometimes the values are read in first, bits set, then the value output. I assume sometime similar is going on the titanium, and promped your question. I am also not sure why this is done.
  • In general: I think, what we're calling "endpoints" when we're talking about Ax ports, we should be calling "pipes" to be in line with the USB spec.
  • I expect hubs could be supported if you were willing to do the extra programming to write a driver for it.

--Dan Englender 16:58, 9 Jul 2005 (PDT)

Dan, Olivier, I really appreciate the work you're doing on the USB ports. I'm looking forward to USB support in TiEmu, at least for TiEmu-TiEmu virtual linking. Maybe I'll implement it once you get the documentation done. Is anything similar being done for the RTC ports? --Kevin Kofler 19:34, 9 Jul 2005 (PDT)

Retrieved from "https://wikiti.brandonw.net/index.php?title=Talk:83Plus:OS:84_Plus_USB_Information&oldid=1698"