| BrandonW wrote: |
| 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. |
Let me show you abbreviated code to answer this:
| Code: |
Cn2_Int_ReceiveFrame_USB:
bit 5,(iy+41h)
jp z,Cn2_Int_CheckPendSend
;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 |
| Code: |
Cn2_Int_SendFrame_USB:
ex af, af'
exx ;swap to normal registers
;push all the registers
in a,($05) ;$C000 port
ld b,a
ld a,3
out ($05),a
;copy ALL the data out of the buffer!
out ($05),a
xor a
out ($33),a
ld a,$43
out ($33),a
ld a,$3
out ($34),a
ld hl,$0014
ld ($90AA),hl ;timeout counter
ld l,a
out ($35),a
res 0,(iy+43h) ;timeout flag
set 3,(iy+41h) ;force it not to kill the USB connection??
ld hl,Cn2_RAMPage3_Buffer+$4000
im 1
ei
bcall(50F2h) ;SendUSBData
di
rlc a ;rotate carry into bit 0
ld (Cn2_SafeRAM_7b),a
xor a
out ($33),a ;Turn off Timer 2
out ($34),a
res 3,(iy+41h) ;let it resolve issues with the host again
;restore all the registers!
ex af, af' ;save to shadow registers
exx
res 0,(iy+41h)
res 5,(iy+41h)
ld a,(Cn2_SafeRAM_7b)
rr a ;roll bit 0 back to carry
jp c,Cn2_Int_Done_QuitOK
jp Cn2_Int_SendSuccess |
| Quote: |
| 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?) |
It does not, as far as I can tell.
| Quote: |
| 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. |
I could certainly live with that.
| Quote: |
| 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. |
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.
| Quote: |
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.
For example:
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. |
I think that it would definitely be cool, but again, space constraints (and backwards-compatibility) are my main concerns. |
