These are all fully understood except the following: B_CALL 4F1Eh: no idea, but called after receiving a var in _GetVarCmd, name in OP1 B_CALL 4F27h: no idea, subroutine of 4F1Eh B_CALL 4F21h: no idea, but sends directory contents, goes to _JForceCmdNoChar. B_CALL 4F2Dh: no idea, but Flash must be unlocked so forget it. Might send ID list. B_CALL 4F30h: no idea, but sends header packet and other crap. B_CALL 4F33h: no idea, but sends the data at 7A:4000h in header and data packets. B_CALL 4F42h: no idea, but sends the data at 7A:4000h (almost) in header and data packets. B_CALL 4F36h: no idea, but appears to send OS page in A. B_CALL 4F39h: no idea, but sends all the OS pages in header, data, and EOT packets. B_CALL 4EC7h: SendHeaderPacket: Sends a header packet and receives an acknowledgement. Input: OP1 is name and type of program (IMPORTANT that it be zero'd out) If sending to 83+, (OP2+9) is pointer to VAT entry DE is size of variable data (including size bytes) A is command to send (6 for normal transfer, 0A2h or 0C9h for silent link) iy+1Bh set up accordingly Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems B_CALL 4A0Eh: SendSkipExitPacket: Sends skip/exit packet and receives acknowledgement. Input: A is skip/exit code (1 to exit, 2 for skip, 3 for out-of-memory, etc.) iy+1Bh set up accordingly Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems B_CALL 4ECAh: CancelTransmission: Sends skip/exit packet and receives acknowledgement. Input: A is skip/exit code (1 to exit, 2 for skip, 3 for out-of-memory, etc.) iy+1Bh set up accordingly DE is number of bytes to send (theoretically, this is for other skip/exit codes with data attached) Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems B_CALL 4ECDh: SendScreenContents: Responds to a silent link screenshot request by sending an acknowledgement packet, the current LCD contents in the form of a data packet, and receives acknowledgement. Input: iy+1Bh set up accordingly Output: Packets sent/received ERR:LINK thrown if any problems B_CALL 4ED0h: SendRAMVarData: Sends data from RAM variable in data packets and receives acknowledgement. Input: iy+1Bh set up accordingly HL is address of variable data DE is size of variable data (including size bytes) Output: Data packet sent and acknowledgement received. ERR:LINK thrown if any problems This behaves very, very strangely when (sndRecState)=08h, (varClass)=0Ah, and DE>=037Dh, so you should probably zero out (sndRecState) just in case. B_CALL 4ED3h: SendRAMCmd: Sends almost any packet you want that contains data and receives acknowledgement. Input: iy+1Bh set up accordingly A is command to send (15h for data, 06h/0A2h/0C9h for variable header, etc.) HL is address of variable data if sending data packet (must be in RAM) DE is size of packet Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems Just like SendRAMVarData, you should probably zero out (sndRecState) so this doesn't get weird. B_CALL 4F3Fh: SendCmd: Sends almost any packet you want that contains data and receives acknowledgement. Input: iy+1Bh set up accordingly BHL is page:address of variable data if sending data packet DE is size of packet Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems Pretty much identical to SendRAMCmd. B_CALL 4ED6h: SendPacket: Sends almost any packet you want that contains data and receives acknowledgement. Input: iy+1Bh set up accordingly (iMathPtr5) is address of data header contains start of packet (4 bytes; machine ID, command, size word) Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems B_CALL 50A1h: SendArcPacket: Sends almost any packet you want that contains data and receives acknowledgement. Input: iy+1Bh set up accordingly (pagedGetPtr) and (pagedPN) are address and page of data header contains start of packet (4 bytes; machine ID, command, size word) Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems B_CALL 4ED9h: ReceiveAck: Receives 4-byte acknowledgement packet. Input: None Output: 4-byte acknowledgement packet is received ERR:LINK thrown if any other packet received B_CALL 4EDCh: Send4BytePacket: Sends 4-byte packet and receives acknowledgement packet. Input: header+2 is last 2 bytes; these can be changed iy+1Bh set up accordingly H is command to send (such as 09h) Output: Packet sent and acknowledgement received ERR:LINK thrown if any problems, including receiving non-acknowledgement packet B_CALL 4EDFh: SendDataByte: Sends byte and adds to checksum at (header+4). Input: C is byte to send (header+4) is old checksum value Output: Byte sent and checksum updated ERR:LINK thrown if any problems Set (header+4) to 0 before first call to this. B_CALL 4EE2h: Send4Bytes: Sends any 4 bytes. Input: header contains 4 bytes to send Output: Bytes sent ERR:LINK thrown if any problems B_CALL 4EE8h: SendCByte: Sends a byte. Input: C is byte to send Output: Byte sent ERR:LINK thrown if any problems This is identical to SendAByte, only C is the input, not A. B_CALL 4EEBh: GetSmallPacket: Gets at most 14 bytes of a data packet and sends acknowledge if the checksum checks out. Input: (header+2) is size of packet data iy+1Bh set up accordingly Output: Bytes are received to ioData If checksum valid, acknowledgement is sent, otherwise 5Ah packet (bad checksum) ERR:LINK thrown if any problems (including bad checksum) This DOES NOT receive the first 4 bytes of the data packet (machine ID, command, and size bytes). Set this up yourself. B_CALL 4F8Ah is identical to this, except it receives the bytes to ioData-1 (your guess is as good as mine). B_CALL 4EEEh: GetDataPacket: Receives data packet and sends either acknowledgement or bad checksum packet. Input: iy+1Bh set up accordingly DE is address to receive data BC is expected number of bytes to receive (arcInfo) is page of address to receive data (if in Flash ROM) Output: Bytes are received If checksum is valid, acknowledgement is sent, otherwise 5Ah packet (bad checksum) ERR:LINK thrown if any problems Pretty much GetSmallPacket except it gets the first 4 bytes. B_CALL 5092h: GetVariableData: Receives data packet's data (NOT the first 4 bytes) and sends either acknowledgement or bad checksum packet. Input: iy+1Bh set up accordingly (header+2) is size of packet data (iMathPtr5) is address to receive data (arcInfo) is page to receive data (if in Flash ROM) Output: Bytes are received If checksum is valid, acknowledgement is sent, otherwise 5Ah packet (bad checksum) ERR:LINK thrown if any problems This is a subroutine of GetDataPacket. B_CALL 4EF1h: SendAck: Sends acknowledgement packet. Input: iy+1Bh set up accordingly (header+2) is last 2 bytes of acknowledgement packet Output: Acknowledgement packet sent ERR:LINK thrown if any problems B_CALL 4F24h: SendReadyPacket: Sends ready packet. Input: Bits 1-4 of iy+1Bh reset Output: If (iy+1Bh) is already set up, this routine immediately returns Ready packet sent and acknowledgement received If other calculator is 83, 3,(iy+1Bh) is set Basically, you should assume you're talking to an 83+, and then call this. If the other calculator is really an 83, this routine sets that up for you. B_CALL 4EF4h: Get4Bytes: Gets 4 bytes. Input: None Output: Bytes received to header ERR:LINK thrown if any problems This doesn't receive just any 4 bytes...it must be the beginning of a packet. B_CALL 4EF7h: Get3Bytes: Gets 3 bytes. Input: A is first byte Output: Bytes received to header+1 (A is copied to header) ERR:LINK thrown if any problems This is just like Get4Bytes, only you pass the first byte in A; it doesn't receive it. B_CALL 4A17h: SendScreenshot: Sends a screenshot to a computer. Input: iy+1Bh set up accordingly Output: Screenshot is sent This will not throw an error, but will fail if the machine ID of the receiving device is not 03h or 13h. The packet which the calculator sends is 73h,06h,03h,00h,00h,03h,12h,checksumLow,checksumHigh. It then receives an acknowledge and continue, then sends acknowledge and data packet of LCD contents, then receives acknowledge. B_CALL 4F18h: Get4BytesCursor: Gets 4 bytes with the cursor enabled. Input: None Output: 4 bytes received to header A contains second byte B_CALL 4F1Bh: Get4BytesNC: Gets 4 bytes without the cursor enabled. Input: None Output: 4 bytes received to header A contains second byte B_CALL 5182h: SetMachineID: Sets the machine ID to 73h so that other routines can work properly. Input: None Output: Bits 1-4 of iy+1Bh are reset B_CALL 4F2Ah: It's just "ret." B_CALL 4F4Eh: CheckLinkLines: Checks the link port data lines to see if they match the value in A. Input: A is value to check against (mask out bits 2-7) Output: Z if link port is same as value in A This is a pretty dumb entry point. I suppose it could be checking for a stable link. The OS link hook uses this. B_CALL 4F4Bh: RejectCommand: Finishes receiving a silent link command and then rejects it by sending an acknowledge packet and the skip/exit packet with a value of 5. Input: E must be zero A is the current value of port 0 Output: Acknowledge and skip/exit packets are sent, acknowledge received This is the link activity hook used by the OS. "add a,e" is actually run when you BCALL it, so make sure E is zero. I can't fathom why they did this. You also probably shouldn't call it unless you have detected link activity (so use it as a hook). B_CALL 4F48h: SendGetKeyPress: Sends a GetKey keypress remotely to another TI-83 Plus. Input: A is keypress Output: Keypress is sent