B_CALL 4EE2h sends the 4 bytes at header...throws ERR:XMIT if problems. Does scary TI-Keyboard stuff if a link transfer is currently going on. B_CALL 4EE8h is SendAByte, only it's C, not A. B_CALL 4F00h is some kinda keyboard thing (if conditions are right, it at least receives one byte). (iy+1Bh) is used to identify which device to talk to with DSUB protocol: Bit 1: set means 95h. Bit 2: set means 82h. Bit 3: set means 83h. Bit 4: set means 03h. If all of those are reset, 73h is assumed. Bits 0, 5, and 6 are used as flags: Bit 5: create link delay after receiving bytes? (ioFlag) is very complicated. It appears individual bits aren't used, but rather whole bytes that mean things. 00h: silent link? (sendRecState) is also very complicated and uses whole bytes for meaning. B_CALL 5182h zeroes out bits 1-4 (that's all it does), which I suppose means it sets the machine ID to 73h. B_CALL 4EC7h sends a header packet (pass the number in A, like 06h, 0A2h, or 0C9h). Make sure and set up (iy+1Bh) beforehand. B_CALL 4A0Eh has something to do with sending the continue packet. B_CALL 4A17h is some kind of variant on _SendVarCmd. B_CALL 4ECAh sends the skip/exit packet. Pass 1 in A to exit, 2 to skip, 3 for out-of-memory, 5 for some kind of command refused or rejected, and 12 for low batteries. 4 and other numbers mean something, too. B_CALL 4ECDh sends an acknowledge packet and the current screen contents in the form of a data packet. It will expect an acknowledge back. B_CALL 4ED0h sends the data packet for a variable (pointer to data in HL) in RAM ONLY. Also receives acknowledge. B_CALL 4ED3h sends whatever packet you want (command is in A). Seems to only be good for data packet (15h), though. Pass pointer to variable data in HL and size of packet you want to send (data portion) in DE (must be in RAM). B_CALL 4F3Fh sends whatever packet you want (command is in A). Seems to only be good for data packet (15h), though. Pass pointer to variable data in BHL and size of packet you want to send (data portion) in DE. B_CALL 4ED6h sends the data packet like 4ED3h, but before the actual data, it'll send the four bytes at header. (header+2) must be data size. B_CALL 4ED9h receives an acknowledge packet or throws (errNo). Machine ID is returned in B. B_CALL 4EDCh sends a 4-byte packet of your choice (command in H) and receives an acknowledgement. Set up (iy+1Bh) beforehand. B_CALL 4EDFh sends one byte (passed in C) and adds it to the 16-bit value at (header+4). B_CALL 4EEBh is very closely related to 5092h. Receives at most 14 bytes. B_CALL 4EF1h sends acknowledge packet. Set up (iy+1Bh) for machine ID. B_CALL 4EF7h is the same as 4EF4h, only it doesn't receive the first byte, you pass it in A. B_CALL 4F06h sets up the cxMain vectors for the duplicate variable dialog...B_CALL Mon right after it. It has a lot of crazy inputs I don't know yet. B_CALL 4F09h is more crazy link stuff, though it uses the variable in OP1 and falls through to 4F06h. B_CALL 4F0Ch is even more crazy stuff, a subroutine of 4F09h. I think it sends the continue packet and then waits for the data one. Lots of inputs. B_CALL 4F15h sets comFailed,(iy+getSendFlg). If var in OP1 does not exist, sends exit packet. If it does, attempts to send data packet with command in A and finish transfer. I'm not sure of the intent of this function, but if you set (sndRecState) to 0Ah and pass it a var name in OP1, it'll successfully send a variable (it won't send EOT, but the receiving calculator will still take it). B_CALL 4F18h turns on the cursor and APD, gets four bytes, and returns the second one (command) in A. At least I think so. B_CALL 4F1Bh is...the same thing as 4F18h? Except no cursor. Maybe. B_CALL 4F21h is a response to the "request directory" silent link request. It begins by sending a data packet with free memory and then sending header packets of each variable and then Flash application (receiving acknowledgement each time), then finally sends EOT and receives acknowledgement. B_CALL 4F24h returns immediately if machine ID (iy+1Bh) is 95h, 82h, 83h, or 03h. Otherwise, it sends the ready packet (83h,68h,00h,00h) and receives four bytes. If the machine ID of the received packet is 73h, 3,(iy+1Bh) (meaning 83h) is set. B_CALL 4F2Dh...*sigh* I have no idea. It sends a header packet of size 10, receives acknowledge and continue packets, then sends a series of data packets with received acknowledgements (the data comes from the certificate page). Then it sends EOT and gets an acknowledge. Flash must be unlocked to even call this, so...don't. B_CALL 4F30h is...something. Definitely link-related and completes a transfer of some sort like 4F2Dh. Calls FindOSHeaderSubField looking for field 8080h (whatever that is). B_CALL 4F48h attempts to send 73h,87h,A,00h. If it fails, bit 5,(iy+33h) is reset. I have no idea what this packet is. B_CALL 4F4Bh is actually a link activity hook which the OS itself uses. Calling it yourself will cause it to receive a packet (of any size), and then send the skip/exit packet with a value of 5. Command refusal? It's pretty stupid to make this a BCALL because it will execute the hook byte (add a,e). So whatever you intend to pass it in A, subtract E from it first. B_CALL 4F4Eh is called by the link activity hook and you should use it as well. It waits until the link port data lines match the value you pass in A (mask out upper 6 bits, this is also the input to the hook) or it times out. B_CALL 4EF4h receives 4 bytes to header...throws (errNo) if problems. If 1,(iy+1Bh) is set, 95h is the assumed first byte. The first byte must be either 95h, 73h, 23h, 74h, 82h, 02h, 12h, 83h, 03h, 13h, or 08h. If it is not, the second byte is then checked for either 68h, 47h, 74h, or 2Dh...if it is none of these, it jumps to JErrorNo. B_CALL 807Bh receives one byte through the link assist, so don't use this on the 83+. Returns byte in C. B_CALL 50A1h sends the data packet, but this requires some setup: header needs to contain the start of the data packet (this is 83h,15h,(size+2)low,(size+2)high or whatever). (pagedPN) contains the page where data is stored (0 if in RAM). (iMathPtr5) needs to contain the pointer to the start of the data if in RAM. (pagedGetPtr) needs to contain the pointer to the start of the data if archived. It also receives the acknowledgement packet and throws an error if anything is funky. B_CALL 5092h receives the data packet (NOT the first 4 bytes, call 4F1Bh and make sure A is 15h first). B_CALL 4EEEh, however, DOES receive it all. (header+2) must contain number of bytes to receive (which 4F1Bh will do for you). (iMathPtr5) is the pointer to the data. (arcInfo) is the page of the data (if archived). A subroutine of B_CALL 5092h unlocks Flash, writes a data byte for you, and locks it back. You can call this directly on OS 2.41 at 7C:6A6Fh to write at any data page/address: http://www.brandonw.net/calcstuff/flashwrite.txt B_CALL 4F8Ah is actually the same thing as 5092h, except that it will load ioData-1 to (iMathPtr5) and throw ERR:XMIT if you try to receive 15 or more bytes. Your guess is as good as mine. B_CALL 4F2Ah does nothing. Really. Just "ret." This scares me because of above paragraph. A full send to another calculator could (in theory) be done like so: B_CALL _SendVarCmd B_CALL 4ED9h (receive acknowledge). B_CALL 4ED9h (receive continue). B_CALL 4EF1h (send acknowledge packet). B_CALL 50A1h (send data packet and receive acknowledge). B_CALL 4EDCh (send EOT and receive acknowledge).