TIPI - TI-99/4A to Raspberry PI interface development

[+InsaneMultitasker]

I'll just toss this out for you to chew on.

 

As someone who has written programs to use level 2, it works well as documented, both for floppy and hard drive devices. IMHO, the 'biggest' trouble comes in when you have two cards with the same subprograms in the same box. TI didn't consider this problem nor did Myarc when they extended the routines into the hard drive realm. Horizon Ramdisks have the same problems. And it was for compatibility that the SCSI DSR uses both WDS and SCS as device names, along with the same >2x subprogram numbers. It was left to the programmers to ensure the right card was called, by trying to figure out the device each time. The second largest problem is mucking around with scratchpad. And thirdly, you call the routine with a device number and a routine number. Meh.

 

From a DSR side the level 2 subprograms should be simpler than the record-based IO routines, once you get past all the DSR gymnastics that go with finding the file via pointers and sectors and FDRs and all that nonsense, something you don't have to contend with in your environment. You'll probably speed right along with the subroutines once you get a few of them working.

 

Since you seem to be heading toward some compatibility, I'd suggest stealing a page from the Geneve DSR. Program TIPI to allow aliasing your device(s) as WDS1,WDS2,WDS3 (and/or SCSIx, IDEx devices) for maximum flexibility. Same goes for aliasing DSKx. Fred's DM2K uses the catalog file (i.e., OPEN #1:"WDS1.") which is much more forgiving and simpler to manage, and should work without much hassle. Just don't expect a few disk manager programs like MDM5 to work - they use sector IO to catalog the disks.

 

Fred's HDX and IDE DSRs use level 2 subprograms >9x and >8x to overcome problems with multiple cards in the same system at the expense of some backward compatibility. I suppose that if you only want the ability to use archiver, terminal emulators, and some other subset of programs you could limit TIPI's implementation to direct input, direct output, and pathname opcodes. Of course, if you go that far... why not implement it all.

 

Personally, it would be nice to see you and Fred follow the Geneve DSR IO standard to implement a PAB-based set of level 2 routines for TIPI, IDE, and HDX, complete with the full path.filename. I've outlined my thoughts on this in the past, perceived hurdles and all. (Edit: this wouldn't solve compatibility across the board; it is more of my pie in the sky wishful thinking).

Edited December 31, 2017 by InsaneMultitasker

[+jedimatt42]

I have setting/clearing 'protect' 0x12 implemented for DSK1-3.

 

What is odd, is the DM2K doesn't even try to call my routine if for instance DSK2 is not mapped... If it is not mapped, the DSR that handled the catalog is not mine, but the TIFDC. So DM2K must be capturing the CRUBASE of the device you are currently looking at, and using that to limit the search for the Level 2 routines.

 

Is that normal?

 

I am trying to code the routines to 'skip' to the next DSR if the drive is not mapped. But in the case of DM2K, it isn't even trying my routine if the catalog came from a different card.

 

Anyway, if I had another card to test with, I wouldn't be doing this project

 

---

 

Another question: DSRLNK, ea manual says pass >8 to link to device service routines (level 3 stuff) and pass >10 to link to subprograms. Are those supposed to be hex >8 and >10 ( 16 ) or are they decimal 8 and 10?... decimal would make more sense as they are then the offset into the ROM header that points to the corresponding linked lists...

 

---

 

And are there any programming guides around the level 2 io? For level 2 IO, I'm guessing the PAB doesn't actually have to exist, but that the word at >8356 must contain the VDP address of the subprogram 'String' ( length byte then characters ) to search for. Other than that values are stuffed in the FAC area as detailed by the GPL Interface Specification for the 99/4 Disk Peripheral ( or Fred's excellent doc. )

 

---

 

I don't know the WDS/SCSI devices to know what makes sense... I don't understand how to get value out of any aliasing there without just getting in the way.

 

I'm thinking less is more, if you are running a program that needs this level of IO, use a drive mapping. map DSK3 to Downloads, and in TIMXT save to DSK3?

Map DSK2 to wherever you want to unarc things to. Then unarc from DSK3 to DSK2.

Save DSK1 for Old Dark Caves... or other things that you want to auto-load from XB

 

DSK0, becomes useless. Except that if you are used to using it as your harddrive in Classic99, then you can here too.

TIPI. is there for my own vanity. And most things work great from there.

 

I don't know how to get value out of adding a PAB based interface to equivalent level 2 routines either, except to author a brand new disk manager that only works on TIPI, since nothing else would support that on the 4A either.

 

-M@

[+mizapf]

It is decimal 8 and 10, or

 

BLWP @DSRLNK
DATA >000A

[+InsaneMultitasker]

For programs that need to be sure they are accessing the proper device, yes, it is normal to capture the device name and then limit the CRU search. It isn't very common in my experience, and mostly appears in programs like DM2K, Archiver, and a handful of other programs that need to be sure they are using the right card when calling the device number. I don't know if Fred does this for all devices or just the hard drive devices; maybe he'll chime in.

 

Now, let me crawl out of the rabbit hole I started digging last night.

 

I like your approach to using level 2 IO only for the DSKx mapped drives. Mount any folder and away you go. Allow TIPI to function as level 3 and allow level 2/3 for the disk mappings. You can use DSK1-9 and DSKA-Z, if needed, similar to the Horizon RAMdisk.

 

Simple example: if I wanted to download TIMXT to TIPI, I could map the folder "downloads" to DSK5. I download the file to DSK5.TIMXT (using level 2 IO). I restart the computer, launch Editor Assembler, and load "TIPI.DOWNLOADS.TIMXT" or "DSK5.TIMXT".

 

Personally, I would completely forget trying to mimic any WDS/SCS/IDE/HDX level 2 routines, unless you are shooting for hard drive compatibility. I don't think it is worth the hassle or the effort, if you have disk mapping and disk drive level 2 io.

 

Not sure about programming guides. Maybe a thread on level 2 IO would be a good idea.

[Tursi]

And are there any programming guides around the level 2 io? For level 2 IO, I'm guessing the PAB doesn't actually have to exist, but that the word at >8356 must contain the VDP address of the subprogram 'String' ( length byte then characters ) to search for. Other than that values are stuffed in the FAC area as detailed by the GPL Interface Specification for the 99/4 Disk Peripheral ( or Fred's excellent doc. )

 

I do have most of the level 2 functions working in Classic99 - though I know you've used it as reference before. I also have the slight advantage that I don't have to work alongside the TI Disk Controller, so indexing is a little simpler (ie: no matter the combination of drives, Classic99 has ONE disk DSR).

 

(edit: Tim's thoughts on copying the Myarc hard drive DSR concepts seems smart to me, since they thought out some of it. ah, I misread Tim's first post, so never mind. My point was Tim's smart. ) For Classic99 I considered their implementation a best effort with no promises for the most part, except for the function to read and write a file by sectors (since that's pretty valuable for copying and file transfer programs). Since you're on hardware you can't fall back on my excuse of "use the Windows file manager" quite as easily.

Edited December 31, 2017 by Tursi

[+jedimatt42]

So I popped open whtech and found the HFDC manual. It seems like the closest thing to my target is how HFDC floppy drives are treated, and support subdirectories.

 

So, Instead of pretending to be IDE, or SCSI, or the Winchesters... I can alias DSK4, DSK0, and TIPI all to be the root of the TIPI filesystem. DM2K likes DSK4.

If you actually have a DSK4 on a 4A already, well, we can adjust later...

 

I've implemented:

 

>12

>13

>17

>18

>19

>1A

 

Next up

>14

>15

 

If I can get them done today, it will have been a good year.

 

-M@

[+jedimatt42]

I do have most of the level 2 functions working in Classic99 - though I know you've used it as reference before. I also have the slight advantage that I don't have to work alongside the TI Disk Controller, so indexing is a little simpler (ie: no matter the combination of drives, Classic99 has ONE disk DSR).

 

(edit: Tim's thoughts on copying the Myarc hard drive DSR concepts seems smart to me, since they thought out some of it. ah, I misread Tim's first post, so never mind. My point was Tim's smart. ) For Classic99 I considered their implementation a best effort with no promises for the most part, except for the function to read and write a file by sectors (since that's pretty valuable for copying and file transfer programs). Since you're on hardware you can't fall back on my excuse of "use the Windows file manager" quite as easily.

I agree Tim's smart I hope I don't come off as disregarding his advice... I'm just also trying to be practical. TIPI's filesystem exceeds my desires already.

 

-M@

[+InsaneMultitasker]

I hope I don't come off as disregarding his advice... I'm just also trying to be practical. TIPI's filesystem exceeds my desires already.

 

-M@

You have nothing to worry about... I often delve into too many details (and sometimes repeat things) just to lay out what is possible or out there now, regardless of how practical or desirable it may be for your project. Far as I can tell, what you have accomplished will handle most needs and the extras are just the icing on the cake.

[Omega-TI]

TIPI's filesystem exceeds my desires already.

 

Far as I can tell, what you have accomplished will handle most needs and the extras are just the icing on the cake.

 

Agreed. No need devoting hundreds of extra hours into programming and development for the .05% of esoteric programs out there that people probably would not use in a TIPI configured system anyway.

 

The FIAD method is simply awesome and overcomes TI's inherent limitations of the time.

[Tursi]

Didn't mean to imply any intent, don't worry! Just rambling!

 

The FIAD method is simply awesome and overcomes TI's inherent limitations of the time.

IMO, the FIAD method is just using the DSR system the way TI intended it to be used... all the limitations came from copying the floppy disk controller. Unlike many systems, the TI DSR wasn't designed for floppy disks, it was fully open and generic.

[+Lee Stewart]

... I'm guessing the PAB doesn't actually have to exist, but that the word at >8356 must contain the VDP address of the subprogram 'String' ( length byte then characters ) to search for. ...

 

I would say that the subprogram string with its preceding count byte is the PAB. It certainly does not have the structure of a level 3 PAB. I suppose it could be more than two bytes long, but that is all I have ever seen: a length byte of 1 and a subprogram “name” that is actually a one-byte subprogram number. Sorry for the digression. Carry on...

 

...lee

[+jedimatt42]

I would say that the subprogram string with its preceding count byte is the PAB. It certainly does not have the structure of a level 3 PAB. I suppose it could be more than two bytes long, but that is all I have ever seen: a length byte of 1 and a subprogram name that is actually a one-byte subprogram number. Sorry for the digression. Carry on...

 

...lee

That's a bit like saying a road-apple is a cow. LOL...

 

I imagine it went down something like this at TI (this is a 100% fiction based on my own experiences as a software developer at a globally dispersed company):

 

The folks on the 990's with their simulator never formatted a disk in their life. They were tasked to make the BASIC for the home computer support their professional file io system.

 

The Disk Memory system team got the spec for the professional file io system. Implemented it. Implemented extensions for the simulator, and everything was fine...

 

But then someone realized: Oh Crap! Home Computer users can't just manage their files on the mini-computer host filesystem ( see what I did there! I'm proposing that TI filesystems were originally hosted on other platforms! Hah! )

 

Some Home computer end-user software team was brought in. These guys are used to the confines of the limited scratch pad, but don't really grasp the positive nuances of the PAB / Level 3 IO system.

 

They look at the specification for the disk memory system, and at this point in time level 2 routines only support Sector IO. And they aren't exposed in the DSR header at all.

 

Being the imaginative sort, they go to town! The Disk Memory System guys are told by the simulator guys, that they must not mess with the Level 3 specification. So, they look for another place to expose the hidden level 2 routines that they need. They are familiar with adding BASIC calls in cartridge headers. ( maybe, I don't know if that works, but EA GROM adds CALL LOAD, so why not )

 

They add sector io to the DSR's BASIC header, hiding it from the BASIC search system ( sort of, BASIC still has to check all these names ), just so they could find these proprietary, internal entry points for the Disk Manager cartridge in case the DSR rom changes. They code of Disk Manager, and iterate back and forth on this until the Disk Manager is complete.

I hope somebody enjoy that little fiction... Maybe it will become a myth I hear told back to me in a decade.

 

-M@

[+jedimatt42]

So I've learned a few things in trying to implement direct input and direct output routines:

 

Caching the CRUBASE after something like a Level 3 status command is massively important if any two boards in your system use the same routine 'names'.

There is no viable cascade mechanism for a level 2 routine implementation to take, so console's DSRLNK, and even EA utils DSRLNK is a poor choice.

 

There is equally no standard on how these are called, to support cascade operations. By cascade, I mean the behavior of Level 3 IO, where DSRLNK will match the device name, call your DSR, and it can still return error 0, device name error.

DSRLNK will then proceed to continue searching for other entries in your ROM, or roms of subsequent cards, to handle this.

 

This is how the Level 3 IO works with my DSK1-3 mappings, along side a TI FDC. It tries my card first. The Raspberry PI checks for a mapping, and if it isn't there, returns back to the TI, the correct error code. Works great, for Level 3.

 

If a client program on the 4a, uses it's own routine to search level 2 sub-program 'names' and restricts it to the CRUBASE of the card being targetted this will work, as long as it discovers what CRUBASE to use with a Level 3 operation.

 

I'm seeing in DM2K, that it does not cache the CRUBASE of the destination device for file copy. So, trying to copy from TIPI to a TIFDC floppy will not work. The CRUBASE of the source does seem to be cached. So I'm able to do things like set protect on mapped or real floppies.

 

To go from TIPI to a floppy, I should actually implement level 2 at a different set of 'names' like >Fx for 'TIPI.", and then have to write a new client or send some beer money to Fred.

 

If I'm totally lucky, DM2K won't cache the destination at all, so if the source is a real floppy, I might be able to copy to a TIPI mapped drive. Which will be something. And it looks like I should be able to go from a tipi drive to a tipi drive.

 

Snark: According to the TI specification, I'm supposed to learn GPL, and provide a GROM based manager module ( they mean cartridge ) ... I was hoping to use Tursi's classic99 make feature to just capture DM2K into a GROM loader That would meat the specification.

 

None of this matters for sideport users without TI FDC's... or peb splitters. But the goal is still a PEB card version that co-exists well with others.

 

-M@

[Sinphaltimus]

Will the PEB version be designed in such a way as to fit in a standard clamshell case AND mount a pi inside?

[+InsaneMultitasker]

Wow. Sounds like more, nice progress!

 

Your latest update reminded me of one nuance: there are programs that expect a disk number as the 4th character of the device name, and will test that value to see if it is in 'range'. That same disk number (in the 4th character) is then used directly as the level 2 device number. Easy way to test, when you run into this, would be to alias to "TIP1."

 

Anyway, if you implement a set of TIPI level 2 subprograms (which you seem on the cusp of doing successfully) be aware that unlike the disk drive controllers, the hard drive controllers manage the current path for each device number through opcode >27 (>87, >97). The path is used for all subsequent level 2 IO on that device/drive number, until changed by another call to >27 for that device number or a system reset.

 

If you are using the same device/number with different paths, say to copy TIPI.FILES to TIPI.TEMP, you would set the current path each time you needed to read from or write to a different directory. Copying a file would look something like this: set path to TIPI.FILES (>27), read the file via level 2 (>24), set path to TIPI.TEMP (>27), and write the file (>25). If the file was larger than the copy buffer, you would repeat these steps until complete.

 

The same current path applies to the rename, protect, and the other level 2 routines. i.e., to protect a file in TIPI.FOLDER2., you would first ensure the current folder is set with routine >27. Lastly, hard drive level 2 routines use a few more bytes in the Additional Info block and scratchpad RAM that you may need to clear for compatibility.

[+jedimatt42]

Will the PEB version be designed in such a way as to fit in a standard clamshell case AND mount a pi inside?

Nope. If you want to be able to use the WIFI on the PI, stuffing it in a metal case like the PEB is probably not your best bet.

 

-M@

[+jedimatt42]

Thanks Tim!

 

I implemented >17 like an HFDC does for floppies. That part is working well.

 

And addition to that nuance, is that when setting the folder with this routine, you include the device name... And you cannot assume an interaction starts with the path set to the root of a drive. So if the >x7 routine is defined by the ROM, then you *must* control it for each device you are working with.

 

Oh, I guess one thing I missed, is that the unit # -> path map should probably be reset on powerup routine. But that is luckily implied by restarting the tipi.service process on the PI each time we visit the powerup routine.

 

---

 

I was on the cusp, as you say, of implementing a >Fx range of level 2 routines, but it buys me nothing, after some analysis.

 

As long as I'm pretending to be DSK1, I have to have >1x routines.

Are the extended record length, and extended bits for start block and number of Level 3 records only used by non-floppies?

It looks like the maximum file size addressable in the fileinfo, without the extended bytes, is 16 megabytes.

 

So I'm thinking I don't get any benefit from a second range of level 2 routines.

 

-M@

[+InsaneMultitasker]

Are the extended record length, and extended bits for start block and number of Level 3 records only used by non-floppies?

It looks like the maximum file size addressable in the fileinfo, without the extended bytes, is 16 megabytes.

 

So I'm thinking I don't get any benefit from a second range of level 2 routines.

 

Yes, for non-floppies. I recall testing large file sizes and even though some stubs are in place, there isn't any real implemented support, even in MDOS. I do not recall whether large record sizes are implemented; if they are, I've never seen them used.

 

As for benefit to the second range of level 2 routines, only two minor benefits come to my mind, applicable mostly to the PEB card option: 1) closer compatibility with the small number of programs like DM2K or Archiver, to go beyond DSKx. mappings and 2) as a way to avoid conflicts with other cards with DSKx.

[Sinphaltimus]

Nope. If you want to be able to use the WIFI on the PI, stuffing it in a metal case like the PEB is probably not your best bet.

 

-M@

But for ethernet...

[+jedimatt42]

Oops I got the days mixed up... Yesterday, was actually the anniversary of the TIPI project. Dec 31st, 2016 - ElectricLab started the conversation that has consumed me for the last year.

 

* I started playing with GALs to decode CRU bits, and finally put my logic-level converters to use ( I ordered some of those the moment I ordered a 4A and joined this forum )

* I learned Verilog - and got an FPGA interfacing to the TI.

* We busted our butts to get something demo-able for last year's Fest West 2017. I had to learn python, and assembly language...

* 30 minutes after Fest West, I had extended it to load PROGRAM image files via URL.

* Then I burned about 3 more months on the rats-nest FPGA prototype trying to get the interfacing to the Raspberry PI less consuming, and still fast.

* I then targeted a smaller version of the CPLD... couldn't get that to fit... refactored all my Verilog code. Moved up to the next bigger CPLD.

* And finally built an addon board for my 32k sideport expansion.

* We've got a budding web-ui file manager.

* In December I brought 3 people into the TIPI beta test program! And things are just happening... They gave me masses of feedback on the first-use experience.

* I wrote a BASIC CALL extension to load EA5 programs (still a major bug there), and by default load TIPI.TIPICFG

* There is an automated upgrade mechanism for the Raspberry PI side, triggered by the TI, and it has worked!

* Adrenalin makes it difficult to go to sleep.

 

Happy Anniversary TIPI!

 

-M@

[Sinphaltimus]

Happy Anniversary.

[+jedimatt42]

Yes, for non-floppies. I recall testing large file sizes and even though some stubs are in place, there isn't any real implemented support, even in MDOS. I do not recall whether large record sizes are implemented; if they are, I've never seen them used.

 

As for benefit to the second range of level 2 routines, only two minor benefits come to my mind, applicable mostly to the PEB card option: 1) closer compatibility with the small number of programs like DM2K or Archiver, to go beyond DSKx. mappings and 2) as a way to avoid conflicts with other cards with DSKx.

The problem is, if I'm going to have DSK? mappings, I have to have >1x routines for compatibility with any older software. And for any software to use a new set of >Fx, it has to be new software, so I'm thinking, why can't it just be made to use the >1x routines in a functional way?

I would only gain compatibility with those programs if I didn't implement >1x routines, and added WDS1.

 

If I forked it, so that for the PEB version, you couldn't say DSK1. was mapped to a TIPI folder, then yes, it would make sense, but then I'd also have to alias as WDS1. and use the same >xx routines as WDS1 for any old software to know what the heck to do.

 

If I want to have a device called TIPI. then there is no lvl2 compatibility with old lvl2 software.

If I want to have a device called DSK?. then there is no 100% compatibility with old lvl2 software.

If I implement the DSK?. and >1x lvl2 routines, then at least most lvl2 software has a chance at working with the DSK? aliases.

 

Every lvl2 program in the history of the 4a, has I presume, had to take this burden of handling every prior card's special-ness. The Myarc HFDC had it best, because it replaced your TIFDC, and didn't have to co-exist.

 

I expect, for co-existence, I'm going to be no different, and have to write a new version of a file manager to allow copying between TI FDC and TIPI.

 

This is a fun challenge. And probably an unsolvable problem, without giving up what I want, and just emulating an existing board, and saying, no, you can't also have that board.

 

-M@

[+jedimatt42]

But for ethernet...

I don't think an RPI3 will fit in standard clamshell case.

 

I am thinking of making the board short, and having mounting points so that the raspberry pi can be bolted to the TIPI-PEB board with the port ends basically to the rear.

 

PI's suck in this regard though... the power supply is then on the bottom. Not too big a deal, but somewhat annoying.

 

PI's are meant to be left running. So I will not be making it easy for people to take power from their PEB. Besides, you want the fileshare available even when your PEB is off so you can load all the same files on classic99.

 

It's gonna get messy inside. I also like the promise of a wireless mouse... That won't like being inside the EMS box either. But you can probably extend usb ports to the drive bays.

 

It'll be interesting to see what people do. I'd like to see a little plastic device build to mount the PI against the PCBoard, up near the rear of the PEB, but I don't want to bring the PCBoard itself up there, as that would add many dollars per board.

 

-M@

[+jedimatt42]

Tim,

 

Ok, I've got... The solution to the impossible problem...

 

Use two ROMs.

 

One that has the header entries for DSK?, and the corresponding level 2 'names'

 

And another that has an HFDC header with its level 2 'names'.

 

Give both, TIPI. as well. And all my PI. and other goodies.

 

Then, use the DSR CRU based banking I designed in, to control which ROM is used.

 

I've got a 32k eprom, 2 cru bits for banking, and so far my ROM code is well under 3k.

 

Just run CALL TIPI to bring up the config tool, and offer setting the mode from there.

 

This way, if I'm trying to copy to a floppy, I just have to be in WDS mode. And if I want to pretend I am a floppy, I just have to switch back.

 

I think this is worth the experiment...

 

-M@

[+InsaneMultitasker]

Does TIPI have any RAM onboard, where you could dynamically build (or add to) the device names and subroutines during powerup, based on the config?

 

Experimentation is good. Might discover some neat tricks that way, too, and better to see what will work together and what needs to be separate.

 

Sort of related note, I made a few changes to TIMXT tonight to prepare for TIPI, specifically in the level 2 DSR routines. I've also tentatively reserved more than the 'standard' 40 characters for path.filename. If files will be allowed to have an extension, or be greater than 10 characters, I will need to figure out how to parse things properly. I will wait until you are a bit further along, which gives me time to think about how to present the devices to the user. I would like to present the current device.path and/or history of previously used paths in the user dialogue, versus forcing the user to type the whole thing in each time (I so hate that aspect of most TI programs).