TIPI does not have any on board ram. Those device names all have to be baked into the ROM header lists... The powerup routine could ask the PI what the saved state is, and restore the ROM selection.
TIPI does allow for longer filenames, with a munged up shortened alias for intolerant programs. There is a 10 character name alias for any long named file. And directory names of course are part of that path.
It is also a case sensitive file-system, like the TI FDC, even though a number of programs force the user to use only ALL CAPS in their filenames.
What TIPI really needs from TIMXT, is for you and I to work out a programming interface to TCP...
TIPI has 2 assembly language subroutine pointers in the ROM for general use. 'recvmsg' who's address is at 4010, and 'sendmsg' who's address is at 4012. The address to the routine is there.... So to call it, code like:
GPLWS EQU >83E0
SMSGPTR EQU >4012
RMSGPTR EQU >4010
LI R12,>1000 ; or use a CRUBASE you discover by level 3 IO checking status for file "PI.STATUS"
SBO 0 ; puts TIPI in memory map
MOV @SMSGPTR,R3 ; load the address of the sendmsg routine
MOV R0,@GPLWS ; Target WP R0 is length of message to send.
MOV R1,@GPLWS+2 ; Target WP R1 is address of data to send.
recvmsg works the same, but leaves the bytes received count in target WP R0. So after calling you can do:
MOV @GPLWS,R0 ; load the bytes received count into my R0.
(You don't have to use GPLWS, or even change workspace, but sendmsg and receivemsg use R0-R4. And I've only tested these outside the DSR from gcc, where I don't know what the register usage is in the current workspace )
So, we can send and receive data as bytearray messages. I am thinking I'd like to wire up Stuart's UDS-10 emulator into the TIPI service, so that if while TIPI is waiting for DSR requests, you send a message starting with 0x23, then the rest of the message, and all subsequent messages are just bytes that go to the UDS emulator to process. TIPI would stay in UDS mode until an escape sequence was sent to it, telling it to pause the UDS connection, letting it return to DSR mode so you can save files and stuff... then send 0x23 again, and a resume command to get back to the business of data transfer.
The PI would buffer everything. It would be set up so that if there is no data ready to receive, the recvmsg simply sends a 0 byte message. This way you can poll for data in a 256 byte chunk, get what is available, and if there is too much it just waits on the PI side, until you are ready for it.
This is basically how I read mouse data on the TI as well. I send a msg with just the mouse code: 0x20, and it responds with a message of the mouse bytes: x,y,buttons, and then goes back into DSR mode.
This is how many kinds of extensions can be added to TIPI, without a DSR change, just registering a 'RawExtension' object to the python code, that can take over and return control when instructed.
If it is bad and doesn't return control, no big, because the process is killed when you take the TI back to the title screen.
Anyway, this will totally feel like cheating compared to what you've done to get fast transfer out of the RS232... It might not fit the IO model of TIMXT ... There are no interrupts to service. You can poll at your leisure and never miss a byte. I'm not sure if it will kill the experience of being able to hit space to pause the scroll on BBSs, or if the TCP push back is enough for that, as long as the receive buffer is small enough, then it might feel equally interactive.