Talk:83Plus:OS:84 Plus USB Information/1
This is another page to use for your discussions, as the first page was getting long.
Contents
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)
Dan, which cable are you using to plug your peripherals to your 84P? A B receptacle/mini-A plug doesn't seem to be very common in stores... --ExtendeD 12:27, 13 Jul 2005 (PDT)
- I'm using the GoldX five-in-one converter cable. I ordered it online, but I recently saw it in an office supply store (Office Max). They're a bit bulky though, so I recently ordered a couple of smaller cables from serialio. I haven't gotten them yet, but they look like they should do the trick. --Dan Englender 14:11, 13 Jul 2005 (PDT)
- I saw an appropriate universal cable at Wal-mart for $15 dollars. It has all the tips you could ever need. --Andy Janata 17:42, 13 Jul 2005 (PDT)
- I have been looking for an adapter for a few days in France without success. A few French online stores selling such adapters charge €15 just for the shipping, it's really too much. I have even bought a universal cable in the only non-online store selling an adapter similar to your "GoldX five-in-one" (and perhaps the one Andy has found). But what I expected to be a mini-A plug was actually a "Mitsumi Mini-USB" plug! (a kind of non-standard 4 pin mini-plug). Stupid package without instructions and incompetent shop assistant...I am not sure I will be able to get a refund on this €21-gadget. I have just received Romain Liévin's Titanium and I can't test anything :( --ExtendeD 15:31, 15 Jul 2005 (PDT)
- I saw an appropriate universal cable at Wal-mart for $15 dollars. It has all the tips you could ever need. --Andy Janata 17:42, 13 Jul 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)
- Forget what I have previously said about some ports in 2x and 3x ranges on Titanium: they are not mirrors on anything, actually there are not used at all. I was using a Titarom-patched version of AMS, and it had badly patched these ports (Titarom is a patcher I had released to make VTI accept a Titanium's image. Now TiEmu can be used with a native ROM image, but it wasn't Titanium-compatible when I started to work on USB). So there are actually no 2x ports, and the only 3x ports used are 31 and 39. TI84P's port 3A doesn't seem to be used on Titanium.
- 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 have now rewritten a part of the interrupt handler to replace AMS's one, and added a logging system to trace what's happening. Maybe this will help us to find out what are the functions of some currently unknown ports. --ExtendeD 02:16, 18 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)
- [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)
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)
- On Titanium, when acting as device, bit 2 of port 86 means the device is being reset by the host, and should move to the default state. It seems to be used also when acting as host, but I don't know yet what it means. --ExtendeD 10:57, 20 Jul 2005 (PDT)
89T information txt file
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.
- This looks possible, you are probably right (I have currently no Titanium to test, and AMS uses of course only bit 0 and 1). --ExtendeD 02:44, 10 Jul 2005 (PDT)
- 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 correspond to the description you've given it, so perhaps the 84P and 89t differ in this respect. The output value of 00 appears to happen once: during the setup procedure for the E00F device.
- I'm still rather confused about what 87 and 89 are doing on the 84P. I'll try to provide some more detail of what's going on, and maybe you can see how this matches with what happens on the 89t. The "normal" state of port 87 seems to be FF. I guess this could be reconciled by saying that it just keeps all the pipes enabled at all times. For E00F initialization it sets the value to 00, but I'm not worried about E00F yet. The odd thing is that right before the address is set, when the calc is a device and gets a set address request, it changes the value to 7F. I can't imagine it would want to do anything with pipe A7, so I don't know what it could be for. --Dan Englender 12:31, 10 Jul 2005 (PDT)
- "right before the address is set": you mean at the end of the status stage, before the address is written to port 80? On Titanium, the device is moved to the address state: among other things, 1 is written to port 87, and 0 is written to port 89. I really don't understand what's going on with your ports 87 and 89. Titanium's behavior with them is consistent. Each configured endpoint has an associated configuration structure, with a field I have called enabling_mask. Its value is 1 << buffer_index (buffer_index is 1 for A1 for example). To enable the outgoing flow of the pipe, I have a (in C) wio(87, rio(87) | enabling_mask); (wio/rio are C macros). To disable it, I have a wio(87,~config->enabling_mask & rio(87));, and so on. --ExtendeD 13:16, 10 Jul 2005 (PDT)
- I meant right after it reads and parses the set address request, before it actually outputs to port 80. It seems way too strange to have everything else be exactly the same and the behavior of these two ports be completely different between the two calculators. I'll have to think about it further and see if I can make any sense out of I guess --Dan Englender 13:25, 10 Jul 2005 (PDT)
- "right before the address is set": you mean at the end of the status stage, before the address is written to port 80? On Titanium, the device is moved to the address state: among other things, 1 is written to port 87, and 0 is written to port 89. I really don't understand what's going on with your ports 87 and 89. Titanium's behavior with them is consistent. Each configured endpoint has an associated configuration structure, with a field I have called enabling_mask. Its value is 1 << buffer_index (buffer_index is 1 for A1 for example). To enable the outgoing flow of the pipe, I have a (in C) wio(87, rio(87) | enabling_mask); (wio/rio are C macros). To disable it, I have a wio(87,~config->enabling_mask & rio(87));, and so on. --ExtendeD 13:16, 10 Jul 2005 (PDT)
- I'm still rather confused about what 87 and 89 are doing on the 84P. I'll try to provide some more detail of what's going on, and maybe you can see how this matches with what happens on the 89t. The "normal" state of port 87 seems to be FF. I guess this could be reconciled by saying that it just keeps all the pipes enabled at all times. For E00F initialization it sets the value to 00, but I'm not worried about E00F yet. The odd thing is that right before the address is set, when the calc is a device and gets a set address request, it changes the value to 7F. I can't imagine it would want to do anything with pipe A7, so I don't know what it could be for. --Dan Englender 12:31, 10 Jul 2005 (PDT)
- Port 89: I have to look in more detail to see what port 89 is doing on the 84P
- The "normal" state of port 89 seems to be 0E. I guess bit 0 is reset because the control port is treated like an outgoing port. Why bits 1-3 are set is odd though, because probably only one of them should be used for incoming, and port A3 is never used at all. When a Vernier device is connected, the value is set to 02. This makes sense: A1 is used as the interrupt in pipe for this device. However, in the code which, I think, is the bulk recieve for linking and/or silent linking, the port value is set to FF until all packets are received, and then reset to 0E. During E00F set-up the port is set to 0 (but I'm not worrying about that, because E00F seems to behave different altogether). But the FF and 0E stuff is a little confusing. --Dan Englender 12:31, 10 Jul 2005 (PDT)
- 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?
- No, only bit 0, 1 and 2 are used... --ExtendeD 02:44, 10 Jul 2005 (PDT)
- I believe bit 0 might be to enable HNP from the host side. --Dan Englender 12:46, 10 Jul 2005 (PDT) ---- Changed my mind. It has something to do with HNP, but I haven't figured out what yet.
- On Titanium, this bit is set to enable HNP on the device side (after a set_feature request by the host). Strangely, it is also set by the device... during HNP! The OTG spec requires to check if a set_feature has been sent by the host before continuing HNP, but AMS as device seems to enable it by itself... BTW I am currently working on HNP handling routines. This is so complicated, I have been on this for hours. This will hopefully demystify the role of many ports. I am trying to cross-check AMS's routines and OTG spec's state diagrams, but I am far from having anything useful for the moment. I think we will soon have to switch our vocabulary from "as host" to "a B-device acting as host" for example, else we'll soon be confused when detailing HNP and SRP. This would be great if you could find 84P's equivalent routines, to cross-check the 2 implementations. I can try to give you hints for this if you want. --ExtendeD 13:54, 10 Jul 2005 (PDT)
- I believe I've found the HNP handling routines as well, and was mapping them out, but got sidetracked by the strange things I found with port 3A. I'll get back to the HNP stuff later tonight. Let me know what you find out and I'll see how it matches up to what I see on the 84P. --Dan Englender 14:05, 10 Jul 2005 (PDT)
- On Titanium, this bit is set to enable HNP on the device side (after a set_feature request by the host). Strangely, it is also set by the device... during HNP! The OTG spec requires to check if a set_feature has been sent by the host before continuing HNP, but AMS as device seems to enable it by itself... BTW I am currently working on HNP handling routines. This is so complicated, I have been on this for hours. This will hopefully demystify the role of many ports. I am trying to cross-check AMS's routines and OTG spec's state diagrams, but I am far from having anything useful for the moment. I think we will soon have to switch our vocabulary from "as host" to "a B-device acting as host" for example, else we'll soon be confused when detailing HNP and SRP. This would be great if you could find 84P's equivalent routines, to cross-check the 2 implementations. I can try to give you hints for this if you want. --ExtendeD 13:54, 10 Jul 2005 (PDT)
- On the 84P only bits 0, 2, and 7 are used. It seems like bits 0 is set if the USB has activated at all. Bit 1 always seems to be 0, so far as I can tell. Bit 2 is set if the device is acting as host. Bit 3 seems to be the same as bit 2. Bit 4 always seems to be the negation of bit 2. Bit 5 seems to always be 0. Bit 6 seems to be the same as bit 2. Bit 7 seems to be 1 is b-cable is connected or 0 if a-cable is connected. --Dan Englender 23:51, 10 Jul 2005 (PDT)
- I believe bit 0 might be to enable HNP from the host side. --Dan Englender 12:46, 10 Jul 2005 (PDT) ---- Changed my mind. It has something to do with HNP, but I haven't figured out what yet.
- No, only bit 0, 1 and 2 are used... --ExtendeD 02:44, 10 Jul 2005 (PDT)
- 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.
- I'm going to make another complete guess: The ports that seem to have each bit mapped to a different endpoint/pipe, for example ports 82 (in my model), 84, 87 (in your model), and 89 (in your model) all have another port directly after them that is never used anywhere in the operating system (on the 84P at least). I'm going to guess that the total number of available pipes is 16 (A0 through AF) and that the first of the ports, the ones that we've written about, controls A0 through A7, and the second one, that the OS never touches, controls A8 through AF. --Dan Englender 22:51, 9 Jul 2005 (PDT)
- This looks good. The only thing which annoys me is that ports '87' and '89' are odd addresses, I would expect even ones. --ExtendeD 02:44, 10 Jul 2005 (PDT)
--Dan Englender 16:58, 9 Jul 2005 (PDT)
Dan, I had forgotten to upload the latest version of the file. Here is a diff [1] of it for the few missing additions you have not read. --ExtendeD 03:09, 10 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)
- Glad to be of service :) As for the RTC ports, I haven't the faintest idea how they work on the 89t, but on the 84P, they work as follows: Ports 45 through 48 (MSB) hold the current value of the clock, as seconds since January 1st 1997 12 AM. Bit 0 of port 40 is set if the clock is enabled, and reset if not. To set a new value of the clock load the value you want to ports 41 through 44, and then set port 40 to 01 then 03 in succession. --Dan Englender 21:59, 9 Jul 2005 (PDT)
- Noted. I'll check out if it matches what the Titanium OS does about a week from now, unless Olivier (ExtendeD) beats me to the punch. --Kevin Kofler 00:54, 10 Jul 2005 (PDT)
- <<Ports 45 through 48 (MSB) hold the current value of the clock, as seconds since January 1st 1997 12 AM>> I can confirm this. While I was working on clock support for TiLP, I had to understand how the clock was encoded in the packet. It's encoded like you mentionned: a 32-bits value which holds the current value of the clock, as seconds since January 1st 1997 12 AM. But, I will add this: it is assumed there are _always_ 365 days in a year (no 1996, 2000, specific years). --Romain Liévin 23:14, 11 Jul 2005
- So no leap years? That's silly. Does the OS simply not allow one to set a February 29 in years mod 4 = 0 (plus those other restrictions)? --AndyJ 14:46, 11 Jul 2005 (PDT)
- No leap years but I have tried to set February 29, 2000 and TI84+ accepts it. Strange ?! --Romain Liévin 08:45, 12 Jul 2005
- Well, TI84+ has leap year support in fact. The 32-bits value represents the seconds elapsed since midnight (00:00:00), January 1, 1997, almost like coordinated universal time (UTC, 1970) provided by <time.h> (primitives like mktime & localtime).
- --Romain Liévin 00:13, 13 Jul 2005
- So no leap years? That's silly. Does the OS simply not allow one to set a February 29 in years mod 4 = 0 (plus those other restrictions)? --AndyJ 14:46, 11 Jul 2005 (PDT)
- <<Ports 45 through 48 (MSB) hold the current value of the clock, as seconds since January 1st 1997 12 AM>> I can confirm this. While I was working on clock support for TiLP, I had to understand how the clock was encoded in the packet. It's encoded like you mentionned: a 32-bits value which holds the current value of the clock, as seconds since January 1st 1997 12 AM. But, I will add this: it is assumed there are _always_ 365 days in a year (no 1996, 2000, specific years). --Romain Liévin 23:14, 11 Jul 2005
- From my looks at AMS and ExtendeD's description of it, it looks like on the Titanium, the RTC ports are essentially the same, but numbered differently. 45 through 48 is 710046 through 710049, 41 through 44 is 710040 through 710043, 40 is 71005F and there is a port at 710044 I don't quite understand the purpose for, it's usually set to 0 whenever the clock is set (in OneSecondTimerSet as ExtendeD calls it). Similarly, GetOneSecondTimer reads some value from 710045. --Kevin Kofler 17:56, 12 Jul 2005 (PDT)
- Apparently, 0x710045 is some sort of atomicity lock (just like the input and output ports are separate to guarantee atomicity): after reading the ports, AMS checks whether it is zero, and only accepts the value read if it is. I guess this is set to 0 when 0x710046 is read and to some non-0 value when the RTC is incremented, implementing the "non-blocking write" synchronization protocol. This doesn't explain what 0x710044 is for though. --Kevin Kofler 19:34, 14 Jul 2005 (PDT)
- Actually there is also a 1/16th of second timer on Titanium (port 45 to read it, port 44 to initialize it). Don't you have anything similar on TI84P? --ExtendeD 17:51, 23 Jul 2005 (PDT)
- Apparently, 0x710045 is some sort of atomicity lock (just like the input and output ports are separate to guarantee atomicity): after reading the ports, AMS checks whether it is zero, and only accepts the value read if it is. I guess this is set to 0 when 0x710046 is read and to some non-0 value when the RTC is incremented, implementing the "non-blocking write" synchronization protocol. This doesn't explain what 0x710044 is for though. --Kevin Kofler 19:34, 14 Jul 2005 (PDT)
- Noted. I'll check out if it matches what the Titanium OS does about a week from now, unless Olivier (ExtendeD) beats me to the punch. --Kevin Kofler 00:54, 10 Jul 2005 (PDT)
- I have thought about this for a while, it would be really helpful to debug any USB-related software written. The problem is that nothing has been tested yet on a real Titanium (Romain Liévin was to bring his calc to me during his weekend in Paris, but it seems we have missed each other). There are also many other ports we have not yet thought about. Perhaps you should wait for more information and for the current details to be stabilized.
- About the RTC, I think we have everything needed to implement it in my titanium-info.txt (in Titarom's package). --ExtendeD 02:44, 10 Jul 2005 (PDT)