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

[marc.hull]

My priority is storage for people who don't have storage. And if you already have storage, you can ignore the TIPI DSK stuff and just use the TIPI's TIPI. device name.

 

I don't have HFDC, or SCSI or IDE cards from the past to test with. I thought I was doing well by being able to get up and out of the way, so you can still use the network function of TIPI.

 

If the use case is you really want TIPI to map directories to DSK7, then that isn't too hard, and I have ROM space for options here...

 

I don't like implementing use cases I don't have myself. So I always push back trying to find the value in the use case.

 

I'd still like to understand why you'd want DSK7 on TIPI when you can TIPI. or continue to use your HFDC? My DSK4 alias which exist in TIPI so that dm2k can be used with levels 2 io, might be a legit issue, but I believe the alternative DSK0 works with dm2k as well.

 

-M@

Maybe I am misunderstanding. Correct my assumptions.

 

If I have a TIPI set at cru $1000 then I can access the Emulated DSK1-4 on TIPI but I cannot access the FDC or physical disks ?

[+jedimatt42]

No, you can still access the disks. If TIPI doesn't have a DSKx mapped to a directory, then it returns 0 to DSRLNK, and DSRLNK continues on to the next DSR that handles that device name.

 

This mapping is in a file on the PI, and exposed as a DIS/VAR file called PI.CONFIG. It can be set or remove the mapping by editing that file or using TIPICFG program.

 

-M@

[marc.hull]

So. A reference to DSKx is actually a reference to a sub directory on the PI ?

 

Reread your reply and think I understand better your answers.

 

How about you rename your TI side to TSKx. You get to keep your DSR as is and you can shit can the whole DSKx clash.

 

Outside the box Matt. It looks good , then It's ugly, good again then fugly and back to good. But definitely a different approach to TI land. You're on to something.

 

Polish your scheme.

Edited July 26, 2018 by marc.hull

[Omega-TI]

So. A reference to DSKx is actually a reference to a sub directory on the PI ?

 

Exactly!

If you do not fill in the DSK1 - 3 names, it'll ignore them, so you'll be able to use your systems actual hardware instead. Od course you'll still be able to access ANYTHING via the TIPI.xxxx.xxxx method.

[+arcadeshopper]

So. A reference to DSKx is actually a reference to a sub directory on the PI ?

 

Reread your reply and think I understand better your answers.

 

How about you rename your TI side to TSKx. You get to keep your DSR as is and you can shit can the whole DSKx clash.

 

Outside the box Matt. It looks good , then It's ugly, good again then fugly and back to good. But definitely a different approach to TI land. You're on to something.

 

Polish your scheme.

So to be clear you had no idea how it worked. You didn't want to read the source or watch the videos on YouTube that were posted here and include the demos shown at Chicago and fest west to see exactly what you were talking about before taking a stand.

 

The TIPI works fine with everything so far. The only thing that doesn't work is the DSK1,2,3 device folder redirect if you have another device that does those device names at a lower CRU address. By the way this is what happens when you try any other card that does the same trick.

 

It works great with my personality card but I needed to put the TIPI at a higher CRU address as mpc is at 1000 to intercept DSK1 before the floppy controller. So i chose to keep TIPI at 1000 and remove the slow aged sasi to mfm subsystem as the TIPI does everything it does plus much more. Who needs a tiny mfm drive or RAM disk when you can get 64gb on the TIPI drive with basically unlimited files and folders. And it's plenty fast.

 

This device is ground breaking the Ti never had it so good and you are stressing yourself to find a way to poop at it. Sheesh! And to top it off you are totally off base.

 

The entire thing is open source. Changes are not Matt's sole duty. The DSR is in github fork away Marc. Make the device whatever you want. That's the beauty of his design. You find something you want to add or change go for it. If it doesn't break the design it may even get accepted and included in the master branch.

 

Greg

 

Sent from my LG-H872 using Tapatalk

[+jedimatt42]

The wiki isn't very end-user oriented. Maybe it would help if I wrote a narrative of some primary use cases it targets... When my eyes sting from soldering this weekend, I'll see what I can do as a writer.

 

-M@

[+InsaneMultitasker]

You didn't want to read the source or watch the videos on YouTube that were posted here and include the demos shown at Chicago and fest west to see exactly what you were talking about before taking a stand.

 

To some extent by your statement we may as well get rid of the forums, point everyone to a few static pages, and stop asking questions. There's my hyperbole for the week.

 

I've been following the TIPI threads for a while and still have questions about functionality. Things change. Questions arise. I'm sure more will arise as the PEB card is sold and gets into the wild. And isn't that a point of having a discussion forum? It's not like many of us have test cards in our PEBs so these questions will pop up as people think through their own situations. I certainly don't have time to learn every nuance before I have a card, as hard as I might want to try.

 

On a more personal note the /need/ for an MFM drive or Ramdisk is an odd comment. To me that's like comparing TIPI speed to other device's speeds. Some will see TIPI as slow, others as fast. Much of our hardware need and want and expectation is relative. When I get a TIPI, I won't be assembling MDOS with it because I already know the throughput is too slow for that purpose. Doesn't mean I won't use TIPI in many other ways WITH one or more of my other storage devices. Maybe I'll change how the devices work for me, who knows. That's one nice thing about the PEB - put in what you want, take out what you want. No need to poo-poo those devices at its expense, they all serve a purpose. Just because Marc is looking for certain interoperability doesn't mean he is off base, either. Matt's done a good job of working things together but there are still some clumsy aspects to how TIPI works based on individual preference and desire. Not sure we can ever fully get away from that with so many storage-related options at our disposal.

 

Anyway, gotta remember these comparative discussions are a double-edged sword. Not even sure they belong in the development thread, but that's for a different discussion. I'm looking forward to testing some code if and when the card works with a standard Geneve and beyond that I'll watch the development continue through the forums.

[+arcadeshopper]

You missed the point. The point is clearly not about my opinion on using a mfm controller or ram disk with my TIPI.

 

It's about criticising a device before you understand what it does. Asking about it gains knowledge. Discussing options is great. Criticising and requiring change when it's not needed is not ganing anything.

 

You can debate the functionality in your specific setup all you like. But telling Matt he did wrong and to change something that doesn't need changing. That's not constructive. It is not encouraging to the developer to keep working on it.

 

This also happens to be a great open platform that is not necessarily designed to work on a Geneve. It will possibly work in Matt's Geneve pbox. It didn't in mine. Ymmv.

 

Greg

 

 

 

 

 

Sent from my LG-H872 using Tapatalk

[+jedimatt42]

Most of the messages I type in on Atariage never get sent.

 

-M@

[+InsaneMultitasker]

You missed the point.

No, I didn't miss any of your points. Yes, I did interpret Marc's comments differently than you did.

[+arcadeshopper]

Most of the messages I type in on Atariage never get sent.

 

-M@

 

This is so weird, as i have the opposite experience. It usually posts what I try to post 2-3 times..

[+arcadeshopper]

No, I didn't miss any of your points. Yes, I did interpret Marc's comments differently than you did.

 

Yep that much is true.. I am happy to discuss anything regarding the actual use of the device.

 

Then I'll telnet into the bbs and then play some snek and see if I can somehow beat this crazy high score that is collated over the internet from TIPI owners around the world. I will keep loading disk images onto TIPI with a drop of the file on the filesystem and map DSK1 to that directory and run ti-artist or a game.. or just run the game with a CALL TIPI("TIPI.GAMES.EA5.CLICKITY") from the volume.. oh and use the mouse on the TIPI with ti-artist too.. I will get back to converting a BBS game to run across the internet with multiple users on multiple TI's in different places.. oh and there's always loading chatti from BOOT with URI1.CHATTI which points to the website http://myti99.com/CHATTIwith that filename.. and then leave Omega another note to let him know he's not online with CHATTI when I am

[+9640News]

I'm looking forward to a TIPI as well. Hopefully, with my stock Geneve, I will be able to get some functionality from it as the verdict seems out on whether it will function on a stock Geneve. If not, I will move it over to the 4A and use it there.

 

There are storage aspects of it I will use, but my personal interests are more Telnet related. So, if someone builds a HRD 4000 I will get one (maybe 2) of those as well. I'm already waiting for 9/1 to arrive when I can place an order for a couple of DREM emulated MFM drives. Between Telnet capability, and mass storage, I will be really close to the point of going with diskless media where anything can be plugged into a Win10 computer and backed up as well.

 

My 2 cents.

Beery

[Casey]

So. A reference to DSKx is actually a reference to a sub directory on the PI ?

 

How about you rename your TI side to TSKx. You get to keep your DSR as is and you can shit can the whole DSKx clash.

 

For those of us who only have a TIPI, won't doing this break our software that requires DSKx references? If I have a disk image of Multiplan in a subdirectory named TIMP, the program won't know to go look at TSK1 and I don't think there is a way to tell it that. Not every program allows a custom device name for its storage device...

[marc.hull]

So to be clear you had no idea how it worked. You didn't want to read the source or watch the videos on YouTube that were posted here and include the demos shown at Chicago and fest west to see exactly what you were talking about before taking a stand.

 

The TIPI works fine with everything so far. The only thing that doesn't work is the DSK1,2,3 device folder redirect if you have another device that does those device names at a lower CRU address. By the way this is what happens when you try any other card that does the same trick.

 

It works great with my personality card but I needed to put the TIPI at a higher CRU address as mpc is at 1000 to intercept DSK1 before the floppy controller. So i chose to keep TIPI at 1000 and remove the slow aged sasi to mfm subsystem as the TIPI does everything it does plus much more. Who needs a tiny mfm drive or RAM disk when you can get 64gb on the TIPI drive with basically unlimited files and folders. And it's plenty fast.

 

This device is ground breaking the Ti never had it so good and you are stressing yourself to find a way to poop at it. Sheesh! And to top it off you are totally off base.

 

The entire thing is open source. Changes are not Matt's sole duty. The DSR is in github fork away Marc. Make the device whatever you want. That's the beauty of his design. You find something you want to add or change go for it. If it doesn't break the design it may even get accepted and included in the master branch.

 

Greg

 

Sent from my LG-H872 using Tapatalk

I'm not ripping on anything. I'm asking questions and Matt is answering. You will still get your opportunity to make money on the PEB version so lighten up.

[+jedimatt42]

Most of what I write to Atariage doesn't get posted because I don't hit the 'post' button. I like to stop and remember that Atariage is a tool I use in my hobby, and ask, do I need to send this? Do I need to say it that way.

Now, let's move back to understanding what TIPI provides...

 

----

 

 

I've made comments that you don't need x or y legacy hardware, or you can use your x and y, and skip the storage features of TIPI. That is my catch-all stance on coexistence.

 

My goal isn't compatibility, but coexistence, and availability.

 

I hate the nanopeb usage model. It is the only storage option available today beside TI floppy controllers and Goteks. I don't own a nanopeb. It is entirely possible I just use it wrong. I see that Lee has streamlined the usage model while you are in fbForth. That is a great example of constructive behavior.

 

I don't have a PEB full of HRD's and HFDC's. If I did, I wouldn't have built TIPI at all. I would have just explored the IO features of the UberGrom... It is entirely probable that I have no idea what their real value add is. I've given up on ever obtaining those things. I just hope you all have your TI hoards properly dealt with in your will.

 

----

 

All I know from my youth is this trick with the crubase and intercepting DSRLNK requests before the conventional device gets a go.

 

What I was trying to say about 'clash' I will attempt to re-explain:

 

TIPI's primary device name is 'TIPI', it supports subdirectories, and all level 3 IO, and level 2 IO except for >10, using the same subroutine names as a floppy.

 

The TI DSRLNK routine allows for a device to reply that it did not handle the request in a non-error fashion, such that the DSRLNK can continue asking devices with a higher CRUBASE if they will handle it.

TIPI uses this feature to provide DSK1, DSK2, DSK3, DSK4, and DSK.<volumename> device support by allowing you to map a directory under 'TIPI.' to DSK1-3.

DSK4 is an alias for TIPI's base directory that works well with legacy programs that use level 2 IO.

 

On the sideport version of TIPI, I ship with the CRUBASE set to >1100, so it uses the same space as a floppy controller would.

 

For the PEB, I ship with the CRUBASE set to >1000. This allows TIPI to have a shot before the TI Floppy Controller.

 

The TI Floppy controller does not respond to missing disks in a way that allows the DSRLNK to cascade to devices at higher CRUBASE. To my knowledge, only one device in you PEB gets to intercept DSK1-4, since all the floppy controllers sit at >1100, leaving only >1000 in play for interception.

 

I believe the HFDC can provide interception because it is both the hard and floppy controller, sitting at >1100.

HRD and other ramdisks appear to use >1000 to provide interception.

 

I'm suggesting if you have faster things with sector IO support, you let TIPI sit at the higher CRUBASE, and give up TIPI's DSK1-4 & DSK aliasing. You still get access to "TIPI." and the "URIx." and "PI." devices. Along with the low level stuff like TCP/IP and mouse support.

Or if you want to play with TIPI's DSK1-4 & DSK devices, you move one of your legacy devices out of the way, either by changing it's crubase, or physically removing it.

 

You could remove your floppy controller if you want and just run TIPI at >1100.. Then your HRD can still be at >1000 providing fast DSK1 support. Even before TIPI, I never really used my floppy drives. If a piece of software didn't work from Fred's HDX1, I just didn't run it. This will of course be an undesirable configuration for most with an HFDC.

 

----

 

If you, like me, have nothing exotic in your PEB, then you have no worries. TIPI is designed for you! cause you're like me, and it is designed for me first.

 

----

 

All the remaining parts arrived yesterday. So maybe a few will be built and in stock sometime next week.

 

-M@

[+arcadeshopper]

I'm not ripping on anything. I'm asking questions and Matt is answering. You will still get your opportunity to make money on the PEB version so lighten up.

I make almost nothing on sales Marc it has nothing to do with that.

 

I just want to see this in everyone's system. And get people like you, who can code and understand the power this device has to change the Ti world, to participate positively in the project. Once you have one the options are there.

 

We have really only scratched the surface of what this can do.

 

Sent from my LG-H872 using Tapatalk

[+FarmerPotato]

Hi Matt,

 

Trivia: the Myarc Personality Card used crubase >1000 to intercept DSK1 etc. Probably the first example of doing so.

 

I was lucky to have one, ca 1984, and a copy of BUGOUT, to poke around in the DSR ROM. That was my lesson on how DSRs worked.

 

I agree with your idea on coexistence of peripherals. I use NanoPEB but it's a dead end.

For myself, I would not want to make a device that plugged into your 32k expansion header AND clashed with the 32k space.

[marc.hull]

So we're I to buy one of these I could simply change the D's in DSK to T' s as in TSK in the EPROM and be good or does the PI side need the DSK string passed ?

[Omega-TI]

 

I agree with your idea on coexistence of peripherals. I use NanoPEB but it's a dead end.

For myself, I would not want to make a device that plugged into your 32k expansion header AND clashed with the 32k space.

 

Yeah, the Nano is a dead end for sure. When Matt came out with the TIPI I was blow away with it's capabilities. I totally agree with Greg, that we've not even scratched the surface yet of what this thing is going to do for us and the community as a whole. For sure, the TIPI is NO dead end!

 

I actually believe the new PEB-TIPI will make P-Boxes popular again. If you consider how much it can cost to buy cases for the 32K/TIPI unit and the Rpi, the P-Box will still be a little more, but well worth it if you have the room to spare. You'll not be limited to 32K either, you'll be able to run the SAMS card as well as *most* other cards... and future cards as well.

 

ArcadeShopper might consider stocking a "Light Pipe Kit", so people can see the RPi status lights (if they want to) if it's mounted internally. It might require a couple of 3D printed pieces of plastic though for mounting and routing.

[+arcadeshopper]

So we're I to buy one of these I could simply change the D's in DSK to T' s as in TSK in the EPROM and be good or does the PI side need the DSK string passed ?

May also require a python change

 

Sent from my LG-H872 using Tapatalk

[marc.hull]

I make almost nothing on sales Marc it has nothing to do with that.

 

I just want to see this in everyone's system. And get people like you, who can code and understand the power this device has to change the Ti world, to participate positively in the project. Once you have one the options are there.

 

We have really only scratched the surface of what this can do.

 

Sent from my LG-H872 using Tapatalk

 

That's fine and was a bit of a cheap shot by me in response to your venom. Water under the bridge.My personal take on this project is that the side car was brilliant as it allowed those without a PEB to have a DISK system and more. The PEB version looks like a clone of the side port system which is fine but does not take into account the different environment. I would bet that most if not all PEB's contain a FDC and drives. Shit canning them in order to access TIPI drive storage is a little bit over the top for me especially when you consider how easy it would be to resolve the conflicts. That's just me though. Doesn't mean it's a bad project or it won't get used as I'm sure the hard drive ability will attract many as well as the other features. It appears on the surface to be either an attempt at forcing a paradigm change or a some ignorance on Matt's part as to how cards could be and have been compatible. And then, I could be full of shit on both counts.FYI (Matt) Maybe this will help for the next revision.AFAIK the only times a card needs to preempt another card with lower the CRU address is when a hard disk controller is holding a valid DSK1 emulation folder or a card has a power up routine that takes control of the system. Name tables have nothing to do with the CRU.The HFDC had the ability to be a chameleon. If the CARD was set @ CRU >1100 then the disks were called DSK1....DSK4. If the card was set at a Different CRU address then the ROM was paged and the drives were DSK5....DSK8 (My explanation may be flawed but the gist is the same.) This allowed two floppy controllers to exist in the PBOX without causing issues. That would have been a good tidbit for you to know. Maybe on your next revision ?HRD's because they have RAM in the DSR space do not work by preempting the CRU. They can exist with FDC's and hard drive cards because the user has the ability to name the drives whatever the user likes(example DSK1-9...A-Z.) This allows the card to exist anywhere in the CRU space. Now obviously you cannot get away with duplicating names but you are not forced into a situation where you can't use both. Removing good hardware to accommodate new stuff is a bit of a stretch for me currently but hopefully this will get resolved down the road.Lastly (and this is not a shot at Matt but an over all observation as it happens here on occasion) but claiming that a project was "built for your personal use and needs" is fine and acceptable until it starts being offered as a product. At that point the statement becomes a little disingenuous and appears to be an excuse as to why something is broken. DSK storage on the PEB TIPI is most definitely broken. I hope it gets fixed and takes off like a scalded dog. MARC

[+arcadeshopper]

We will have to disagree as I'm using it just fine with my floppy controller in the mix in my pbox. Using TIPI for disk emu is optional. Not breaking anything

 

Sent from my LG-H872 using Tapatalk

[marc.hull]

You can use TIPI storage and FDC storage at the same time ?

[+arcadeshopper]

Yep

I just loaded DSK1.LOAD off TIPI, which loads BOOT off DSK1.. DSK1. is currently pointed to TIPI.BOOT which is my boot folder.

 

then I exited to xb and typed OLD DSK1.TEST (doesn't exist on TIPI) and it went to the floppy disk and tried to find it..