Jump to content
IGNORED

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


Recommended Posts

If you have the standard set of cards {

TIFDC,

RS232,

32 mem, or SAMS,

Flex Cable Interface

}

then you are best off running TIPI at CRUBASE >1000 ( no jumper set ) which is how I will ship them.

 

If you have a horizon ramdisk, or hard drive controller, you will likely be in conflict.

 

-M@

  • Like 1
Link to comment
Share on other sites

If you have the standard set of cards {

TIFDC,

RS232,

32 mem, or SAMS,

Flex Cable Interface

}

then you are best off running TIPI at CRUBASE >1000 ( no jumper set ) which is how I will ship them.

 

If you have a horizon ramdisk, or hard drive controller, you will likely be in conflict.

 

-M@

I removed my personality card which was in conflict as it's redundant with TIPI anyway

 

Sent from my LG-H872 using Tapatalk

  • Like 1
Link to comment
Share on other sites

Excellent information here. I have the standard set of cards - no Horizon Ram or SAMS or HDD controllers, not even an RS232. Just RAM, 32k and FDC. So this uts me at ease. :)

I'll probably be in on the second batch as I haven't seen the sticker shock yet but I'm certain I probably won't be one of the first out of the gate for a PEB version until I settle in on my new budgets.

Link to comment
Share on other sites

Could you rename your drives via a user configure ala the horizon's CONFIG program ?

 

https://github.com/jedimatt42/tipi/wiki/Devices

 

I cannot rename drives, but I can intercept them if the CRUBASE is lower than the floppy controller.

 

So, with the CALL TIPI command which loads TIPI.TIPICFG by default, the drives DSK1, DSK2, and DSK3 can be set to resolve to any directory under the TIPI. drive. If it is not mapped, then DSRLNKs will generally continue to try the next card such as your actuall floppy disk controller.

 

ArcadeShopper has also written an XB program to let you navigate the TIPI. drive and pick the directory to assign to DSK1, 2, or 3. This can be done from BASIC by just writing to the file PI.CONFIG... more details here:

 

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG

 

Maybe this is the feature you are looking for?

 

-M@

Link to comment
Share on other sites

No. I was suggesting a tried and true method to avoid (some of) the device name clash that seems to be occurring.

 

Background...

 

The Horizon CONFIG program has the user select the drive Number. This can be 1-9 and/or A-Z selected by the user in a drive set up routine. Of course the Horizon DSR is in RAM so it's pretty natural but is really effective. Might be worth an exploration on how you could manage around RAM. If worse comes to worse then maybe you could rename your drive look ups to 5,6 & 7. That would at least alleviate the FDC conflicts.

 

The only time you should require your card to be @$1000 is if your trying to do DSK1 emulation from a hard drive (e.g. TIPI.)

Link to comment
Share on other sites

No. I was suggesting a tried and true method to avoid (some of) the device name clash that seems to be occurring.

 

Background...

 

The Horizon CONFIG program has the user select the drive Number. This can be 1-9 and/or A-Z selected by the user in a drive set up routine. Of course the Horizon DSR is in RAM so it's pretty natural but is really effective. Might be worth an exploration on how you could manage around RAM. If worse comes to worse then maybe you could rename your drive look ups to 5,6 & 7. That would at least alleviate the FDC conflicts.

 

The only time you should require your card to be @$1000 is if your trying to do DSK1 emulation from a hard drive (e.g. TIPI.)

 

I don't perceive it as clash. You only need one mass storage device, and you only need one mass storage device that handles floppy drive device names. TIPI only has DSKx support so I can have something not-floppy based. Most of the time I just use the "TIPI." device name...

 

If you have DSK emulation on some other piece of hardware, then you don't need TIPI to do it... and TIPI does not support >10 level 2 sector IO, so you are better off letting your other piece of unobtanium handle it.

There are 2 cru bits in TIPI that control paging the 32k eprom... the DSR is only about 3500 bytes... There is a second version of the dsr in the second 16k, that does not have any of the DSK drives... It has a WSD1 drive and TIPI device name. It also uses the level 2 io routine names as >4x instead of >1x when that is selected. This can be switched with the TIPICFG tool. It doesn't survive poweroff. If you have some case that needs DSK5's or whatever, I'm sure you could figure out how to adjust the eprom and the python code to handle it. Just a few lines would be needed. I can provide assistance if someone genuinely wants to solve a specific configuration need. I believe it would be a linked list entry in the DSR list, and 2 lines in my python code per drive.

 

---

 

TIPI does other things besides storage, so you may want the TCP/IP support, and it doesn't matter what crubase you use for that. I've provided examples in assembly and c for finding the crubase in the form of the TELNET client and the TI-ARTIST mouse driver.

 

---

 

I'll admit, I'm a bit dense regarding the desire for DSK5-9 or more. I personally don't want to remember what is where by a drive number. I find that just ridiculous. Give directory support under TIPI a try. I believe it is nicer.

 

Let's see how it goes.

 

-M@

Link to comment
Share on other sites

 

I'll admit, I'm a bit dense regarding the desire for DSK5-9 or more. I personally don't want to remember what is where by a drive number. I find that just ridiculous. Give directory support under TIPI a try. I believe it is nicer.

 

 

Boy I here ya, sometimes things can get hard to keep track of, so a "set it and forget it" type of situation is preferable. Like you, I use the TIPI.xxxx.xxxxx method and LOVE IT.

 

I'm thinking the real world comes into the mix when some long-time users might be running legacy software that will not recognize longer filename paths. Over time, sector editing in a 5,6,7,8, or 9 to use with an older card was a viable option and it allowed them to customize their systems without interfering with other Plain Jane software that only required DSK1 - DSK3 access.

 

The external TIPI is fortunate that it does not have to compete with a wide assortment of legacy cards owned by various people in multiple configurations that have been tweaked & honed over decades. With that in mind, the P-Box TIPI might have a 'tougher crowd' as people learn to adapt. We'll see!

Link to comment
Share on other sites

Well, if there is a demand for it, I could add in 400 more device names. The config UI gets unwieldy...

 

---

 

I look at it like a home entertainment system...

 

You have your TV which has cable ready tuners in it.

You have your Comcast 3 tuner DVR

And you have your universal remote with 'activities'

 

Because you can, you create an activity for watching the TV tuner, in case the DVR is recording 3 shows at once. But the TV tuner doesn't decode the subscription channels... So it's a little less.

In practice, your wife wants to watch TV. But she should watch the DVR... But the activities are all confusing. In this situation the household is better off pretending the TV doesn't have tuners. In reality you never record 3 things at once, and as years go by you never watch live TV anyway... But you have that activity set up, and have lost a year of your life re-explaining the value of it and that it isn't what you want to pick to watch Starz.

 

---

 

TIPI doesn't need to compete as your storage solution. You can run your legacy software on your legacy hardware. I'll be shipping it configured for people like me, who have come back to the scene after 20/30 years and cannot acquire a legacy mass storage solution. But if you aren't one of us 'refound' 99'ers, then just set the CRUBASE up out of the way, and use the network feature. Screw the storage aspect... you don't need another.

 

---

 

More device names is just an eprom update and a few lines of python... I might re-write the python snippet so it is only ever a DSR name entry change... then if you don't like what I provide, you can easily change the names, and re-assemble, or just dump the rom and hex edit it.

 

Do people want 1-3 & 5-9? I use DSK4. as an alias for TIPI. that is supported by the Level2 IO used in DM2K. It seems to me making the span wider creates more opportunity for confusion, conflict, and frustration.

 

So far, I've only heard 0 requests for this. Just 1 suggestion for something near, and 1 complaint (on yahoo). Not the same thing.

 

-M@

Link to comment
Share on other sites

Matt,

I have Myarc 512 memory cards in both of my systems, amongst other cards of course. They occupy CRU 1000 and 1900. I am assuming that the TIPI card can be configured for a different CRU?

 

Yes, you can use any of the full range >1x00 - where x is 0 - F

 

There is a set of 4 jumpers on the board. The bottom is bit 1, and the top bit 4... you can compose the nibble you want.

 

I will include 1 jumper with the board, but in a not-connected position, so it is at >1000 by default. With just one jumper you can set the crubase to any of:

>1000

>1100

>1200

>1400

>1800

 

-M@

Link to comment
Share on other sites

 

 

Because you can, you create an activity for watching the TV tuner, in case the DVR is recording 3 shows at once. But the TV tuner doesn't decode the subscription channels... So it's a little less.

In practice, your wife wants to watch TV. But she should watch the DVR... But the activities are all confusing. In this situation the household is better off pretending the TV doesn't have tuners. In reality you never record 3 things at once, and as years go by you never watch live TV anyway... But you have that activity set up, and have lost a year of your life re-explaining the value of it and that it isn't what you want to pick to watch Starz.

 

 

 

 

Sadly, at times, my DVR does record 3 or 4 shows simultaneously. Now, it may be later in the week before I can watch those shows, but I do. I've got about 30 TV series I record when new episodes air.

 

Both my TI and Geneve systems have Myarc HFDC's with the TI system also having a Myarc 512K card. Been debating on whether to turn that 512K card into memory expansion for the Geneve or keep it as is so I have Myarc Extended Basic 2.

 

Beery

Link to comment
Share on other sites

Speaking only for myself and having used the “other” way with the NanoPEB, where you have a large number of volumes but can only mount 3 at a given time via CALL MOUNT, I prefer the TIPI way of navigating the file system. I don’t have to remember to put the disk image with the games I want in DSK1 - I can just refer to it with TIPI.GAMES.DISK1.file. It’s a tribute really to how well the TI 99/4A’s operating system was originally designed that it can be extended to work this way.

 

I would never remember which thing I had mounted in which drive. The TI Disk Controller is the lowest common denominator, and it only supports DSK1-3. That the TIPI emulates those 3 device names for software that absolutely requires those names is good enough for my use. Most of the TI written software that can store data either will only use CS1 anyway or allow you to specify a custom device name - TI anticipated that someday DSK1-3 wouldn’t be enough.

  • Like 1
Link to comment
Share on other sites

Got a bit of a programming question regarding the TIPI.

 

This will be on a Geneve. So, let's assume I have used Rompage and done all the configure items necessary, and things are setup and working under the TI-99/4A environment on the Geneve.

 

OK, I power down the Geneve, and then power the Geneve back up and reboot.

 

Without returning to the TI-99/4A environment and using Rompage, I am going to stay in MDOS.

 

Does a power-up routine need to be run on the TIPI card to load any settings or other information before it can be accessed?

 

What I want to do is to be able to use a terminal emulator for Telnet purposes and desire to modify My-Term's RS232 code to talk to the TIPI. I know I will have to map in the DSR page for the CRU the TIPI is using.

 

From an earlier question I had asked a month or two ago, it is my understanding the TIPI will buffer all data coming in and basically only remove it off the stack as I request the individual bytes. Thus, if I told a website to give me a 100K text file listing to display on my terminal, if I am slow in grabbing text, I will not lose anything. Thus, one could have a 100 byte circular buffer instead of multi-K circular buffer and it will only grab the characters as I am ready to display them.

 

If my understanding is correct, I could have four routines:

 

1. Get Telnet character from TIPI

2. Check for keypress from keyboard

3. Transmit key unless special function key

4. Process incoming Telnet character from TIPI

 

And then any other code I desired. Effectively, one would not need to worry about buffer overrun errors even if code was running a large routine consuming time?

 

I just want to make sure my thinking is on the right page. If I am correct in my understanding, then we have really shifted away from baud rate maximums of 38.4K, to a limitation of how fast we can display things on the video. If that is the case, I can focus on other aspects to achieve faster display speeds on a stock Geneve and trim other code and buffers.

 

Thanks for any feedback. I know you are not officially supporting the Geneve as it is a TI-99/4A product. Just trying to identify any hurdles I will need to understand.

 

Beery

Link to comment
Share on other sites

 

I don't perceive it as clash. You only need one mass storage device, and you only need one mass storage device that handles floppy drive device names. TIPI only has DSKx support so I can have something not-floppy based. Most of the time I just use the "TIPI." device name...

 

If you have DSK emulation on some other piece of hardware, then you don't need TIPI to do it... and TIPI does not support >10 level 2 sector IO, so you are better off letting your other piece of unobtanium handle it.

 

There are 2 cru bits in TIPI that control paging the 32k eprom... the DSR is only about 3500 bytes... There is a second version of the dsr in the second 16k, that does not have any of the DSK drives... It has a WSD1 drive and TIPI device name. It also uses the level 2 io routine names as >4x instead of >1x when that is selected. This can be switched with the TIPICFG tool. It doesn't survive poweroff. If you have some case that needs DSK5's or whatever, I'm sure you could figure out how to adjust the eprom and the python code to handle it. Just a few lines would be needed. I can provide assistance if someone genuinely wants to solve a specific configuration need. I believe it would be a linked list entry in the DSR list, and 2 lines in my python code per drive.

 

---

 

TIPI does other things besides storage, so you may want the TCP/IP support, and it doesn't matter what crubase you use for that. I've provided examples in assembly and c for finding the crubase in the form of the TELNET client and the TI-ARTIST mouse driver.

 

---

 

I'll admit, I'm a bit dense regarding the desire for DSK5-9 or more. I personally don't want to remember what is where by a drive number. I find that just ridiculous. Give directory support under TIPI a try. I believe it is nicer.

 

Let's see how it goes.

 

-M@

Well good luck then. I'd like to play in the TIPI pool but you seem to not care about fitting your project in with existing hardware. It's been done before but what do I know ?

Link to comment
Share on other sites

Well good luck then. I'd like to play in the TIPI pool but you seem to not care about fitting your project in with existing hardware. It's been done before but what do I know ?

 

I'm sorry Marc, that wasn't the intent of what I was saying... After more than a year of open discussion, the pcboards are already here from China... it's too late to incorporate RAM in this revision. So I've tried to outline an alternative way to page flip the eprom and enable some flexibiity... My counter solution wasn't meant to disregard your solution, but to work within the constraints of the already fixed/set/physical hardware on my bench.

 

-M@

Link to comment
Share on other sites

Got a bit of a programming question regarding the TIPI.

 

This will be on a Geneve. So, let's assume I have used Rompage and done all the configure items necessary, and things are setup and working under the TI-99/4A environment on the Geneve.

 

OK, I power down the Geneve, and then power the Geneve back up and reboot.

 

Without returning to the TI-99/4A environment and using Rompage, I am going to stay in MDOS.

 

Does a power-up routine need to be run on the TIPI card to load any settings or other information before it can be accessed?

 

The only thing my powerup routine does is write 0s to the latches that the Raspberry PI can read, and then for a short period of time, set cru bit >1x02 on, then back to off, which causes the software service on the PI to be killed and restarted. This ensures that if the PI was hung on a stalled socket, or due to some resource bug, that the program gets a fresh go.

 

You probably don't need to do this in Geneve mode software, unless you've done something that has hung the TIPI mid communication. I'm not sure if ctrl-alt-del re-runs hardware powerup routines, or other ways of exiting a program in MDOS... So it might be a good idea to do this when initializing your program. It's cheap, and ensures all previously open sockets are closed, etc...

 

 

What I want to do is to be able to use a terminal emulator for Telnet purposes and desire to modify My-Term's RS232 code to talk to the TIPI. I know I will have to map in the DSR page for the CRU the TIPI is using.

 

From an earlier question I had asked a month or two ago, it is my understanding the TIPI will buffer all data coming in and basically only remove it off the stack as I request the individual bytes. Thus, if I told a website to give me a 100K text file listing to display on my terminal, if I am slow in grabbing text, I will not lose anything. Thus, one could have a 100 byte circular buffer instead of multi-K circular buffer and it will only grab the characters as I am ready to display them.

 

If my understanding is correct, I could have four routines:

 

1. Get Telnet character from TIPI

2. Check for keypress from keyboard

3. Transmit key unless special function key

4. Process incoming Telnet character from TIPI

 

And then any other code I desired. Effectively, one would not need to worry about buffer overrun errors even if code was running a large routine consuming time?

That is correct, and very much what I do in my 4A TELNET client.

 

I just want to make sure my thinking is on the right page. If I am correct in my understanding, then we have really shifted away from baud rate maximums of 38.4K, to a limitation of how fast we can display things on the video. If that is the case, I can focus on other aspects to achieve faster display speeds on a stock Geneve and trim other code and buffers.

 

Thanks for any feedback. I know you are not officially supporting the Geneve as it is a TI-99/4A product. Just trying to identify any hurdles I will need to understand.

 

Beery

My ability to support it is simply unclear and possibly very limited. I cannot tell if my Geneve is different in a way that matters. It works on mine, not on Gregs. On my 4A's PEB the line used for genmod's AMD (or was it AME) is strong and wrong for a 'not-connected' pin, such that I had to cut the trace. On Electric Labs 4A PEB, we forgot to cut those traces and it worked to my original theory. That's a long way of saying, hopefully ArcadeShopper's Geneve is just not right... ( I hope that for you.. but not for Greg... )

 

It also is working on my Geneve without AMD and AME decode. And my Corcomp, that I've performed the full AMA-AME decoding on, does not work in ROMPAGE. Neither did my TIFDC... So things are screwy...

 

I don't know anything about coding on the Geneve yet, so I secretly (oops, not secret now) hope that you need enough help to exchange proof of concept code back and forth. Ideally the messaging code doesn't use any fixed addresses, so you should be able to BLWP into the ROM and back as I've done in C.

 

 

-M@

Link to comment
Share on other sites

Matt, please see my above message if this question is affirmative. After I thought about it more, I remember a post being made indicated something was working with Rompage and the Geneve. Did the TIPI work with a stock Geneve? Seems like I recalled something being said about it not returning some data to a register. Just need to clear that up.

 

Beery

Link to comment
Share on other sites

Matt, please see my above message if this question is affirmative. After I thought about it more, I remember a post being made indicated something was working with Rompage and the Geneve. Did the TIPI work with a stock Geneve? Seems like I recalled something being said about it not returning some data to a register. Just need to clear that up.

 

Beery

We have not seen it work on a stock Geneve. We are unable to write to the register that lives at >5FFD and >5FFF (from a 4A memory map perspective) on a stock Geneve.

 

It works great on my Genmod Geneve in ROMPAGE, even without AMD and AME decoding.

 

Comically, on my Geneve I have 2 storage devices, floppy and TIPI. TIPI works in ROMPAGE, and floppy does not. Floppy works under the master DSR and TIPI does not. So there is no way for me to copy between without writing special software for that purpose... Hopefully it works better on someone else's machine.

 

-M@

Link to comment
Share on other sites

 

 

The only thing my powerup routine does is write 0s to the latches that the Raspberry PI can read, and then for a short period of time, set cru bit >1x02 on, then back to off, which causes the software service on the PI to be killed and restarted. This ensures that if the PI was hung on a stalled socket, or due to some resource bug, that the program gets a fresh go.

 

You probably don't need to do this in Geneve mode software, unless you've done something that has hung the TIPI mid communication. I'm not sure if ctrl-alt-del re-runs hardware powerup routines, or other ways of exiting a program in MDOS... So it might be a good idea to do this when initializing your program. It's cheap, and ensures all previously open sockets are closed, etc...

 

 

 

That is correct, and very much what I do in my 4A TELNET client.

 

 

My ability to support it is simply unclear and possibly very limited. I cannot tell if my Geneve is different in a way that matters. It works on mine, not on Gregs. On my 4A's PEB the line used for genmod's AMD (or was it AME) is strong and wrong for a 'not-connected' pin, such that I had to cut the trace. On Electric Labs 4A PEB, we forgot to cut those traces and it worked to my original theory. That's a long way of saying, hopefully ArcadeShopper's Geneve is just not right... ( I hope that for you.. but not for Greg... )

 

It also is working on my Geneve without AMD and AME decode. And my Corcomp, that I've performed the full AMA-AME decoding on, does not work in ROMPAGE. Neither did my TIFDC... So things are screwy...

 

I don't know anything about coding on the Geneve yet, so I secretly (oops, not secret now) hope that you need enough help to exchange proof of concept code back and forth. Ideally the messaging code doesn't use any fixed addresses, so you should be able to BLWP into the ROM and back as I've done in C.

 

 

-M@

 

Looks like we were cross posting messages. The good thing is, I do not have a GenMod geneve with the extra decoding lines.

 

It has been so many years, but for some reason, something is telling me several disk controllers did not work with Rompage. I want to say it had something to do with access speed or timing, but not 100% sure. That was over 20 years ago and that has been just too much time. The Myarc HFDC did work, but it seems like there may have been an issue with some other cards. I can not confirm that one way or the other.

 

Yeah, I went digging into your C source code this afternoon for your Telnet app and I think the pieces I will need to understand are there. I know I can page/map the TIPI DSR into the >4000->5FFF space and I saw the SBO/SBZ instructions to turn the card on as well as some strings passed to define buffer lengths. At most, if things do not behave as I think they should, I will need to run some quick snippits of code by you. Those snippits would be the same whether they were on the 4A or the Geneve.

 

Myself, I am thinking of only polling a single character at a time. I know the actual terminal speed is really going to be tied to the screen writes and I have a few tricks I can speed things up there from single character writes.

 

As far as My-Term with RS232 operations, I thought I was missing characters in one place Turned out, my circular buffer (~3K) was being overrun in one place on my BBS I was testing. I increased it to ~11K, and I can still overrun the buffer at 38.4K in one place that pumps out a lot of data to the terminal. I now know where to target that piece of code to resolve which I will address this week. I doubt anyone has seen the issue with My-Term as I think it was limited to a specific menu option and one had to have LOTS of areas to see it.

 

Anyways, sounds promising TIPI will work with the Geneve as anticipated.

 

Beery

  • Like 1
Link to comment
Share on other sites

 

I'm sorry Marc, that wasn't the intent of what I was saying... After more than a year of open discussion, the pcboards are already here from China... it's too late to incorporate RAM in this revision. So I've tried to outline an alternative way to page flip the eprom and enable some flexibiity... My counter solution wasn't meant to disregard your solution, but to work within the constraints of the already fixed/set/physical hardware on my bench.

 

-M@

I sounded shitty and did not mean to but I do believe that if you are making a PEB card then it should play nice with the rest of the rack. Removing a working device to accommodate TIPI is not a good solution.

 

What I meant by DSK5....8 was to rename TIPI's device names to 5-8. That should alleviate FDC clashes.

 

DSK1 emulation on the TI would require a cru of $1000 with a scan starting at $1000 and not $1100 but that is standard fare.

 

Those software changes should make your device compatible with everything except an HFDC set at $1000 ?

Link to comment
Share on other sites

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@

Link to comment
Share on other sites

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@

 

One case senario... legacy software. Say you use a program regularly, but don't want it to reside on DSK1-3, because they change all the time. Well, most of those old E/A 5 programs don't have any leeway for sector editing longer file paths, let alone room for sub-directories, so one can only change the drive number. Having a 'home' for a specific programs default data can be quite useful.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...