I am working on TIPI, with ElectricLab. It is an open sourced work in progress interface between a TI-99/4A and a Raspberry PI, so that we can provide a 'hosted' filesystem for the TI and leverage networking capabilities of the Raspberry Pi.
The initial designs are prototypes. ElectricLab has a pair wire-wrapped logic boards using 7400 series logic to address memory mapped IO with the Raspberry PI. He has built some really cool software off of that to get two 4A's interacting.
I have been working on making it play nice with the TI OS, giving it a proper DSR. My development borrows from ElectricLab, but I've implemented inside a Mojo Spartan 6 FPGA development board.
Provide memory mapped i/o to Raspberry PI for tinkering
Provide file on a disk Raspberry PI hosted filesystems to the TI-99/4A
Provide medium(TCP/UDP) and high(HTTP/HTTPS) level networking abstractions to the 4A, both in tinker mode and in TI-BASIC accessible Level 3 PAB DSRLNK mode.
Source and theoretical schematics are up on github:
The remainder of this thread should be for community visibility, and a constructive place to solicit advice on the compromises we will invariably have to make.
------ I opened this thread with the following questions / confusion --------
OK, I have a handle on PAB based DSR Rom entry points for the file usage model, referred to as Level 3:
OPEN, CLOSE, READ, WRITE, RESET, LOAD, SAVE, DELETE, SCRATCH, and STATUS...
I demonstrated at Fest West, the OPEN, CLOSE, READ, WRITE, LOAD all working (Although I have only performed a write to a TCP socket, not to a filesystem file yet)
But the Level 2 stuff is seriously an architectural problem... I have tracked down that in the DSR header, these use the facility for adding routines to TI BASIC from a DSR ROM, except the name of the 'CALL' is a single byte. What these bytes do, are the operations like rename, sector read/write, direct file input & output... etc... Leaving all of Level 2 subprograms out and only implementing Level 3 access through PAB would be too limiting.
It appears, that you cannot have two implementations of >13 ( TI FDC File Rename ) in a TI, for example, or at least only the one in the card with the lowest CRU address will be seen. These aren't like PAB routines, that look at the PAB, and say "nah, ask the next guy" ( PLEASE, SOMEONE SHOW ME THAT I'M WRONG ABOUT THIS ) They are each given minimal information such as the # of the DSK, but not the 'DSK' part. This leaves them assuming they are the unique implementor... Consequently, each device type has elected a different high nibble. ( Fred details the values in his 'Level 2 Subprograms' document on www.ti99-geek.nl )
From this I am assuming, you cannot use a Myarc harddisk controller and a Scuzzy controller in the same system, as they both use >20 as the base name for their subprograms.
You can't use 2 floppy controllers that respond to DSK either.
Client programs, such as Disk Manager 2, Myarc's Disk Manager V, and eventually Fred's DM2K, have to look at the device name (DSK, WDS, IDE, HDX) themselves, and then map that to the subroutine name to DSRLNK so they land on one in the correct DSR ROM. This means that each time a newly named device comes out, such as "TIPI.", you have to update any disk management software to know about what subprograms map to that devicename.
This isn't such a problem if I want to build TIPI with DSK1,2,3 and DSK.<diskname> support, and I implement the subprograms as the DSK device with a base of >10. However, existing disk managers won't know what I'm talking about if I use the device name "TIPI." Which I am want to do.
I have two goals for this project:
1st a sidecar variety, in which I could just pretend to be DSK. and DSKn. devices. But I really don't want to trick you into thinking it is simulating a floppy... I'm not trying to build a floppy replica. I will fall short of emulating a floppy. The project has no intention of handling disk image either, except to make it easy to drop them into the 'hard drive' as a directory of TIFILES and map DSKn to that directory.
2nd, to co-exist in the PEB with my TI FDC and HDX card.
Pretending to be a floppy drive with respect to these subprograms is fine, until I want to be able to copy data from a floppy to TIPI, or from TIPI to a floppy. If I want to do that, it seems I MUST pic a new base, and hack at, or beg Fred to update DM2K to understand TIPI ( is that "TIP" with a unit # of uppercase-i ? ) ,
or write a new file manager altogether. That wasn't expected to be in scope originally. I'd rather hard code aliases for SCS1. and IDE1. that map to TIPI. And put a jumper on the eprom so you can pick your damage.
There are questions in there somewhere.... Maybe in short, it is: What have I got right? What have I got wrong?