83Plus:OS:84 Plus USB Information - Revision history

Graphmastur at 23:34, 28 November 2010

2010-11-28T23:34:48Z

Fougere at 14:09, 5 September 2009

2009-09-05T14:09:11Z

Harold: /* Port 8C */ 8C is not always incremented - only when a cable is plugged in (which does not imply activity)

2007-06-07T18:04:40Z

‎Port 8C: 8C is not always incremented - only when a cable is plugged in (which does not imply activity)

Brandonw: put link in wrong section

2006-12-01T02:42:16Z

put link in wrong section

Brandonw: /* USB Data Table */ 5269h

2006-12-01T02:41:00Z

‎USB Data Table: 5269h

Brandonw: /* 5269 BCALL */

2006-12-01T02:29:24Z

‎5269 BCALL

Brandonw: /* 5269 BCALL */

2006-12-01T02:28:24Z

‎5269 BCALL

Dan Englender: /* Hardware */ port 89 w/minor to port87

2006-11-01T17:11:08Z

‎Hardware: port 89 w/minor to port87

Dan Englender: /* Port 87 */ output ports

2006-11-01T17:09:08Z

‎Port 87: output ports

Dan Englender: /* Tested Devices */ removed list, linked to usb8x list

2006-10-11T17:04:44Z

‎Tested Devices: removed list, linked to usb8x list

@@ Line 274: / Line 274: @@
 === 9C78 ===
 Used by the OS to keep track of how many bytes it needs to send for USB device request replies.
 == Flags ==

@@ Line 122: / Line 122: @@
 * bit 6 - Plug-in, B-cable
 * bit 7 - Unplug, B-cable
 === Port 5B ===

@@ Line 151: / Line 151: @@
 === Port 8C ===
-The low byte of the 15-bit frame counter.  It is automatically incremented.  I haven't timed it, but in theory it should be incremented about once per millisecond.
+The low byte of the 15-bit frame counter.  It is automatically incremented if a cable is plugged in.  I haven't timed it, but in theory it should be incremented about once per millisecond.
 === Port 8D ===

@@ Line 81: / Line 81: @@
 === 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, but B_CALL 5269h returns it.  Then comes a word.  Not really sure what that is either.  But weird things happen if the high byte is not 00.  If the high byte is not 00, it will skip two bytes in the table for every bit set. If the low byte is 01, only the vendor ID will be checked, if it's 02, only the product ID will be checked (why?), if it's 03, the vendor ID and the product ID will be checked.  If it's 04, the product revision is checked for being greater than the device's revision.  If it's 08, the product revision is checked for being less than or equal to the device's revision. Depending on the low byte of this word, the words that follow will be (in order) the vendor ID, product ID, and the two device revisions to check against. If the low byte is 03, for example, 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. The full disassembly of this routine on OS 2.41 is [http://www.brandonw.net/calcstuff/5269.txt here].
+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, but B_CALL 5269h returns it.  Then comes a word.  Not really sure what that is either.  But weird things happen if the high byte is not 00.  If the high byte is not 00, it will skip two bytes in the table for every bit set. If the low byte is 01, only the vendor ID will be checked, if it's 02, only the product ID will be checked (why?), if it's 03, the vendor ID and the product ID will be checked.  If it's 04, the product revision is checked for being greater than the device's revision.  If it's 08, the product revision is checked for being less than or equal to the device's revision. Depending on the low byte of this word, the words that follow will be (in order) the vendor ID, product ID, and the two device revisions to check against. If the low byte is 03, for example, 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 ===
@@ Line 93: / Line 93: @@
 === 5269 BCALL ===
-The 5269 BCALL is used by the OS after determining that an app with the USB special app header exists.  This entry point compares the values in the USB app header data table with the values at 9C16, 9C18, and 9C1A (vendor ID, product ID, and product revision, respectively). Input is HL -> data table, B = page. Returns Z if found, NZ if not found. Also returns first byte of vendor/product/revision ID entry in A.
+The 5269 BCALL is used by the OS after determining that an app with the USB special app header exists.  This entry point compares the values in the USB app header data table with the values at 9C16, 9C18, and 9C1A (vendor ID, product ID, and product revision, respectively). Input is HL -> data table, B = page. Returns Z if found, NZ if not found. Also returns first byte of vendor/product/revision ID entry in A. The full disassembly of this routine on OS 2.41 is [http://www.brandonw.net/calcstuff/5269.txt here].
 == Hardware ==

@@ Line 81: / Line 81: @@
 === 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.
+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, but B_CALL 5269h returns it.  Then comes a word.  Not really sure what that is either.  But weird things happen if the high byte is not 00.  If the high byte is not 00, it will skip two bytes in the table for every bit set. If the low byte is 01, only the vendor ID will be checked, if it's 02, only the product ID will be checked (why?), if it's 03, the vendor ID and the product ID will be checked.  If it's 04, the product revision is checked for being greater than the device's revision.  If it's 08, the product revision is checked for being less than or equal to the device's revision. Depending on the low byte of this word, the words that follow will be (in order) the vendor ID, product ID, and the two device revisions to check against. If the low byte is 03, for example, 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. The full disassembly of this routine on OS 2.41 is [http://www.brandonw.net/calcstuff/5269.txt here].
 === FindSpecialAppHeader BCALL ===

@@ Line 145: / Line 145: @@
 === Port 87 ===
-This port might be a bitmap of which pipes in the Ax range are enabled for output.  Port 88 would presumably be a continuation for pipes 8-15.
+This port might be a bitmap of which pipes in the Ax range are enabled for output.  Port 88 would presumably be a continuation for pipes 8 through F.
 === Port 8C ===

@@ Line 374: / Line 374: @@
 === Tested Devices ===
-Below are the devices I've tested my USB interface with.  I've written a demo driver for the bold devices, and they all work.  The italic devices don't work and probably never will.  The rest of the devices should theoretically work, but drivers haven't been written.
+For device compatibility see the [[83Plus:Software:usb8x/Supported_Devices|appropriate page]] in the usb8x documentation.
-−
-* '''Mouse''' - The mouse driver I wrote works perfectly with three mice I tested, but ocassionally has some problems with a fourth.  I think it might be power consumption issues.
-* '''Silverlink''' - I wrote a simple demo driver for silverlink.  Sending data from an 84's USB port to its serial port using TI's serial receive routines runs at a rate of about 2.3 KB/s.
-* '''Keyboard''' - I wrote a simple HID keyboard demo driver.  It works perfectly with the one keyboard I've tested (and runs a million times better than the TI-Keyboard -- there's no roll-over problems).
-* Vernier EasyTemp - Can initialize and configure, but haven't written driver.
-* EMS HID playstation 2 controller adaptor - Can initialize and configure, but haven't written driver.
-* calc<->calc - Can initialize and configure, but haven't written driver.
-* Sandisk Cruzer USB flash drive - Can initialize and configure, but haven't written driver.
-* Canon i850 printer - Can initialize and configure, but haven't written driver (and am not planning on it.  I'd like to get an HP printer (which has open source drivers) working though).
-* ''Ezonics webcam'' - Can initialize, but uses isochronous endpoints (not currently supported), and may require too much power.
-* ''SMC 802.11b adaptor'' - Requires too much power.  Won't initialize.
 === Alpha version driver available ===