Talk:83Plus:Ports:3A
Hi guys,
Does anyone have even the faintest clue what this port is about? I've been having some issues with usb8x working on my 84P Black and not working on my 84P Silver. One of the few differences between the two is that my 84P Black has boot version 1.02 (as opposed to 1.00). There's some USB code (in the 1.02 boot) that checks port 3A and branches depending on the value of bit 3, which is 1 on my 84P Silver and 0 on the Black. I'm trying to figure out if this is a software issue or a hardware issue. Any insights would make you a hero.
Also, does anyone have an 84P Black with boot other than 1.02 or 84P Silver with boot other than 1.00? If so, what is the value read from port 3A?
Thanks --Dan Englender 15:01, 7 September 2006 (PDT)
- Someone with an 84P Silver calc with 1.02 boot just tested and the value of port 3A is 0 on his calculator as well. So either there's a hardware difference (which I'm guessing is the most likely explanation) which 1.02 was meant to handle, or the boot code does something differently on 1.02 which causes the different value on port 3A. Either way, I still have no idea what it means. --Dan Englender 15:20, 7 September 2006 (PDT)
The differences between boot 1.00 and 1.02 (I think this is all of them):
- Boot 1.02 on the BE correctly reports the size of the archive (boot 1.00 reports that it has 1504k rather than 480k.)
- Some page numbers used on the BE are changed from 7F to 3F.
- At 6F:4C6E in boot 1.00, an OS has been validated, it's sent the 0006 packet to acknowledge it, and it's just about to boot the newly-loaded OS. It calls 592A (B_CALL 8105). In boot 1.02, it calls 5933 (B_CALL 810E). The only difference between these two routines is that the latter outputs 0 to port 4C.
- At 7F:5B2F in boot 1.00, the boot code is getting ready to receive an OS, and it needs to decide whether to use DBUS or USB, so it polls port 4D. If bits 5 and 6 are both set, it B_CALLs 8108 followed by 810B. These two B_CALLs, located at 5B43, are NOPed out in boot 1.02.
- Curiously, the battery checking routines are changed. In 1.02, they set bit 7 of port 3A when they start, and clear bit 7 when they finish.
I don't think any of these changes affect routines that are called by the OS, though (or any code that's run in a normal startup.) So I think you're probably looking at changed hardware. FloppusMaximus 18:28, 7 September 2006 (PDT)
- So perhaps port 3A has something to do with power. Maybe it either disables the USB port (so accurate battery level will be obtained) or determines how much current can be drawn by the USB port (you don't want a USB device killing the batteries). Or something completely different. --Dan Englender 10:48, 8 September 2006 (PDT)
- Maybe this is a stupid idea, but (theoretically) if it is possible for the USB port to power other devices, isn't it possible for outside sources to power the calc through the USB port? If this is possible, then maybe the battery checking routines are changed so that they won't be thrown off by an external power supply. (then again, I've no idea about USB). Saibot84 16:17, 8 September 2006 (PDT)
- It's possible, yes, but if that were the case, you would expect the battery check routines to querty the value of port 3A (or one of the surrounding ports), not set then reset a bit. In any case, I'm still not sure why any of this would make usb8x function differently since the OS code doesn't seem to differentiate between these two potential hardware versions much. --Dan Englender 19:42, 8 September 2006 (PDT)
- Maybe this is a stupid idea, but (theoretically) if it is possible for the USB port to power other devices, isn't it possible for outside sources to power the calc through the USB port? If this is possible, then maybe the battery checking routines are changed so that they won't be thrown off by an external power supply. (then again, I've no idea about USB). Saibot84 16:17, 8 September 2006 (PDT)
Battery Charging
I've got a theory on the battery charging bit. Maybe, when set to output, it controls whether the charger is enabled. When set to input, it monitors the charger status (done/not done). So it's fancy tri-state logic. Because it would be bad for the charger to be charging off VBus when the calculator itself is supplying VBus, and only the USB controller knows where VBus is coming from.
Or maybe I'm crazy. I'm not an electrical engineer, but it seems odd to use tri-state logic that way. Maybe they were pressed for pins.---Dr. D'nar 07:38, 16 May 2014 (UTC)
