Let me show you abbreviated code to answer this:
|How does DoorsCS implement direct USB functionality? I'm especially interested in any OS calls you make, any direct USB hardware ports you access or poll directly, OS flags you look at, etc.
;receive code here:
;play with $8E, $94, $96, $A2, $8B, and other fun things
;if the Cn2.2 frame is complete, great. Otherwise:
;sets im1 from inside the Cn2.2 interrupt, ei, halt, di
;to let more data fill the USB buffer
;repeats while bit 5,(iy+41h) is reset
;skips to fail if turned off
;repeat receiving processing
ex af, af'
exx ;swap to normal registers
;push all the registers
in a,($05) ;$C000 port
;copy ALL the data out of the buffer!
ld ($90AA),hl ;timeout counter
res 0,(iy+43h) ;timeout flag
set 3,(iy+41h) ;force it not to kill the USB connection??
rlc a ;rotate carry into bit 0
out ($33),a ;Turn off Timer 2
res 3,(iy+41h) ;let it resolve issues with the host again
;restore all the registers!
ex af, af' ;save to shadow registers
rr a ;roll bit 0 back to carry
It does not, as far as I can tell.
|If I recall correctly, you use _SendUSBData (BCALL 50F2h), check the OS' 5,(iy+41h) flag for bulk data ready to be received, as well as a routine to receive bytes to RAM. Does this routine handle both host and peripheral mode? (Meaning, does it take a different path depending on bit 2 of port 8Fh?)
I could certainly live with that.
|I would like to see about using the USB link activity hook to hook into DoorsCS' functionality and allow DUSB gCn functionality using other cable configurations, such as tethering with an Android phone's internet connection. In such a situation, the calculator is host, not peripheral, so DoorsCS' routines might have to be modified.
The biggest problem would be lack of space inside Doors CS, at this point. I'm up to probably having to clip features to fit more stuff.
|Ideally, I'd like to just tweak DoorsCS' USB routines so that everything continues to work as-is as well as supporting this new configuration.
I think that it would definitely be cool, but again, space constraints (and backwards-compatibility) are my main concerns.
|But I think the more flexible solution would be to allow hooking into this functionality from an assembly program or Flash application.
I think that the BCALL _RunAppLib (http://wikiti.brandonw.net/index.php?title=83Plus:BCALLs:50EC) would be good to use for this.
You could simply call this, passing in a predetermined function name as a string to determine whether a "USB extension" exists oncalc, and if so, use its routines instead of the ones you have built in.
HasgCnSp [Has gCn Support?], which returns whether this application supports and wants to hook into DoorsCS gCn support.
IsDatRdy [Is Data Ready?], which returns whether incoming data is ready to be received.
RecvData [Receive Data], which actually receives USB data.
SendData [Send Data], which actually sends USB data.
IsConnRd [Is Connection ready?], which returns whether USB is ready to be used right now.
The above is just off the top of my head and certainly not set in stone, I just want to see what you think of this -- or if nothing else, if you could post/attach the relevant DUSB gCn source code, that would be helpful.