Difference between revisions of "83Plus:OS:84 Plus USB Information"
(→9C31) |
(→RAM: 9c1a) |
||
| Line 108: | Line 108: | ||
=== 9C1A === | === 9C1A === | ||
| − | This is | + | This is where the device release number is stored. It is populated by at least the 5090 BCALL, and perhaps others. |
| + | |||
=== 9C29 === | === 9C29 === | ||
Revision as of 20:15, 27 May 2005
- I moved this page from Talk:83Plus:BCALLs:5254 to here because it seems to fit better. Please note that this is still a work in progress, and don't take the information as gold. I figured having an option for a Talk page for this would outweigh the moving of it. For the time being, we'll leave the data formatted as-is, since it's still nicely done. --AndyJ 07:44, 27 May 2005 (PDT)
OK, I've started this talk page to post information about the 84 Plus USB. This isn't the ideal place, since not all of this stuff has to do with entry point 5254, but it'll have to do. If anyone else would like to contribute any information or thoughts, please do so. Much of this data has been discovered by analyzing how the EasyData application interacts with the EasyTemp probe. --Dan Englender 22:32, 23 May 2005 (PDT)
Easy Data
The USB entry points that Easy Data uses are:
5254 5257 525A 525D 5260
These routines return carry flag with an error code in A on failure, or no carry on success. On success they return BC=(9C16), DE=(9C1A), and HL=(9C18). 9C16 = Vendor ID. 9C18 = Device ID. 9C1A = ????.
The entry points seem to be called only on initialization and quit. On initialization 5254 then 525D are called, and then 525A six times. On quit, 5254, then 5260, then 5257 are called.
5254 BCALL
The 5254 entry point seems to take a callback address to be passed in A (page) and HL (address). That callback address appears to be called on quit, after 5257 is called.
5260 and 5257 BCALLs
The 5260 and 5257 entry points are called right after each other in the code, and don't seem to take any input. I guess they're some kind of USB shut down. 5260 doesn't do much of anything other than set 9C1E to 0000. 5257 plays with the ports some, and then clears the callback address. Since the call back address gets called, I'm assuming it must also call the callback address somewhere in there.
525A and 525D BCALLs
525A and 525D take some kind of pointer in HL. I'm not sure what yet. The 525D entry point first checks to see if bit 3 of port 4C and bits 0 and 2 of port 8F are set. If they are not, it returns failure. These bits are not set by, say, plugging in the hardware. They are set, however, after 5254 has been called. After checking these bits, 9C1E is set to the passed value of HL. If this value is zero, the routine will return failure. A value of 1 will be stored to HL+2, then a value of 1 will be output to port 8E, a value of 20h to port 94h, and success will be returned.
5290 BCALL
A BCALL to 5290 alone is enough to turn on the LED on EasyTemp. (Though it turns on to a strange orange color which is never seen during EasyData execution). It must do some sort of USB initialization type stuff. If bit 3,(iy+41) is set, 5290 will fail. So this must either be a USB-already-initialized flag, or a Don't-Use-USB flag I guess.
This BCALL appears to do the following:
- Do stuff
- Request the device descriptor with a maximum size of 8 bytes.
- Issue a Set Address Request, with an address of 2
- Request the device descriptor again, this time with a 18 byte maximum data size.
- Check device description for an appropriate TI or Vernier device and quit if not found.
- Do stuff
Why are there two device descriptor requests? Presumably so that the calculator can check the peripheral's max packet size (which is in the first 8 bytes), so that it will know how to segmentize further traffic.
Other
The callback routine appears to recieve some kind of input in B. I'm not sure what yet.
I'm, err, not exactly clear at this point how the app actually gets the temperature data from the EasyTemp probe, as the entry point seem to only be called on init and quit. The callback routine seemed a likely candidate, but it's not that either. Maybe there's something going on in the interrupt that I'm not aware of. Or maybe there are some more entry points used that I missed.
EasyData is automatically started when you plug the EasyTemp into the USB port if: The current app is Home Screen, a program is not currently executing, and EasyTemp is loaded on the calculator. EasyTemp is searched for via the app header table below.
4087 Header
The calculator knows to run EasyData when the Probe is plugged in because it includes a special header at address 4087h. The format is as follows:
db 096h, 0E2h, 00h, 01h dw TablePtr ..... TablePtr: dw 1, TableEntryType, DataPtr ..... DataPtr: ;This is the EasyData data db 03h, 80h, 03h, 00h, 0F7h, 08h, 02h, 00h db 80h, 03h, 00h, 0F7h, 08h, 03h, 00h db 80h, 03h, 00h, 0F7h, 08h, 04h, 00h db 00h, 00h
In theory, the Table should be terminated with a 0000 word. It does not appear that EasyData does this.
Header Table Entries
The TableEntryType value can be one of the follow:
- 1 - This type is checked for in what seems to be unused OS code. There's a string "IsDevice" that is used in conjunction with it. Perhaps it's an unimplemented feature, or perhaps it's debug code that's not active in the release OS. Your guess is as good as mine.
- 2 - This is for the library functions used by OpenLib and ExecLib
- 3 - This is for the USB auto-launch, as used by EasyData
USB Data Table
If the TableEntryType is 3, then the data will be USB data and will be formatted as follows: The first byte will be the number of entries in the USB data table. Then, each entry, starts with a byte. Not sure what that is. Then comes a word. Not really sure what that is either. But weird things happen if the high byte is not 00. And it appears that if the low byte is 01, only the vendor ID will be checked, if it's 03, the vendor ID and the product ID will be checked. If it's something else, well, something else happens. if the low byte was 03, then the next word will be the vendor ID, and the following word will be the product ID. If both of these match a connected USB device, then the app will launch.
FindSpecialAppHeader BCALL
The 50EF BCALL reads the 4087 Header. It is used by the OS. Returns SCF on failure, NC on success. On success, returns in HL the read table value. App name in OP1. Input DE is passed as the table entry to look for. Input A holds whether to look at certain app, or all apps. A = 0 means start at the first app, and search until you find an app with the appropriate header. A = 1 means start searching after the app in OP1. This would be used after the first success returned by A=0, to search the entire app list. A=2 means search only the app named in OP1.
5263 BCALL
The 5263 BCALL reads the 4087 Header. it is used by the OS. This appears to be very similar to the above entry point, except that it searches all the pages by number, instead of searching by name. Input DE = header type to find. Output C on failure, NC on success. HL = table entry value. (appSearchPage) = page it was found on. This only finds the first instance of the header type.
5266 BCALL
This allows you to continue a search you started with the 5263 BCALL. Input page in B.
5269 BCALL
The 5269 BCALL is used by the OS after determining that an app with the USB special app header exists. In general, this entry point seems to compare the values in the USB app header data table with the values at 9C16, 9C18, and 9C1A. Some kind of ID I guess? In specific, it's actually very convoluted and strange code. Input is HL -> data table, A = page.
Hardware
Ports 55h and 56h are initially polled in the interrupt routine to determine USB activity. If activity is detected, 4Dh, 82h, 84h, 86h, 8Fh, 91h, and others may be polled as well.
Port 56
The default value for port 56h is 00. If the USB-B plug (peripheral) is plugged into the port with no connection on the other side, nothing happens. If there is a connection on the other side, bit 6 will be set. If the USB-A plug (host) is plugged into the port bit 4 will be set, regardless of whether there is a device on the other side. If you plug one connector in, unplug, and then plug the other connector in without doing whatever the interrupt routine does to acknowledge the USB status, you will get both bits 4 and 6 set. This should probably never happen in practice.
Port A0
I believe this is a/the data input/output port.
RAM
9C13/9C14
9C13 is the page, and 9C14 is the address of a callback routine. It is set by the 5254 BCALL, and called at various times. I'm not really sure what the callback routine is for yet.
9C16
This is where the vendor ID is stored. It is populated by at least the 5090 BCALL, and perhaps others.
9C18
This is where the product ID is stored. It is populated by at least the 5090 BCALL, and perhaps others.
9C1A
This is where the device release number is stored. It is populated by at least the 5090 BCALL, and perhaps others.
9C29
This is an 8 byte output buffer
9C31
This is an input buffer of undetermined length. Possibly 64 bytes.
Flags
Flag byte 41 appears to be the main USB flag. Bit 0 of byte 43 is also used for something related.
0,(iy+41)
If this flag is set, it will cause a certain part of USB code to abort. This is the code that is called from the interrupt routine when port 55h is 0Fh, and port 56h is 00h. This flag is set in an odd piece of code that loops around an output to port 0A2h. It reads the data to output, however, from RAM pages 02h and 03h. Will have to look into in more detail later.
2,(iy+41)
This flag is set after loading the values of 9C16, 9C18, and 9C1A. But then it's reset if the VID/PID is 0451, E00F. *shrug* In BCALL 5254, it is reset after the bcall to 5290.
3,(iy+41)
If this is set the BCALL 5090 will immediately terminate. So perhaps it is either a Don't-Use-USB flag, or a USB-already-initialized flag.
5,(iy+41)
Reset somewhere in USB code. Not sure what it is.
6,(iy+41)
Reset somewhere in USB code. Not sure what it is.
7,(iy+41)
Reset somewhere in USB code. Not sure what it is.
In Other News
- At some point, TI checks for USB devices VID: 045A, PID: E003, E008, and E00F. It seems to return "ok" on E008 and E003, and error on E00F. E008 is the 84P. No clue what E003 and E00F are. Perhaps one is the Viewscreen connector?
- I have successfully connected my calculator and digital camera, and retrieved the Product ID and Vendor ID from the camera. Yay :)
