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

[+InsaneMultitasker]

Maybe I missed the process, but what is the process to attempt to get a TiPi card to allow the Geneve to boot through it?

The next step is to confirm whether or not TIPI works with a standard Geneve. For that we have to wait until the PEB card is available. I'm not doing anything further with the boot code until then. What I can say at this point is that my test code worked on Matt's Genmod Geneve. The program loads MDOS via the TIPI, in GPL with ROMPAGE active, to simulate an EPROM load.

[+arcadeshopper]

The next step is to confirm whether or not TIPI works with a standard Geneve. For that we have to wait until the PEB card is available. I'm not doing anything further with the boot code until then. What I can say at this point is that my test code worked on Matt's Genmod Geneve. The program loads MDOS via the TIPI, in GPL with ROMPAGE active, to simulate an EPROM load.

I shipped 4 out Monday

 

Sent from my LG-H872 using Tapatalk

[+jedimatt42]

phone failed to show me more meaningful replies already in thread...

 

-M@

Edited August 9, 2018 by jedimatt42

[Shift838]

The next step is to confirm whether or not TIPI works with a standard Geneve. For that we have to wait until the PEB card is available. I'm not doing anything further with the boot code until then. What I can say at this point is that my test code worked on Matt's Genmod Geneve. The program loads MDOS via the TIPI, in GPL with ROMPAGE active, to simulate an EPROM load.

 

My TiPi PEB cards are going to arrive today (8/9/18)....so i'm game for testing, i just need to know how.

Edited August 9, 2018 by Shift838

[Omega-TI]

I've run into my first issue, I'll have to try again after dinner, but I cannot seem to COPY a file from a TIPI directory to my DSK1 in the P-Box.

[+jedimatt42]

I've run into my first issue, I'll have to try again after dinner, but I cannot seem to COPY a file from a TIPI directory to my DSK1 in the P-Box.

What program are you trying to use?

DM2K should work, using DSK4 or DSK0 as the TIPI drive alias.

 

What else is in your PEB? What crubase did you select?

 

None of the disk manager type tools know how to work for "TIPI."

 

-M@

[Omega-TI]

Attached are the screen shots of what is happening....

 

As you can see I do NOT have DSK1. mapped in the TIPI so I can use my Lotharek HxC as DSK1.

Even so I'm unable to COPY anything, even though I can directory it.

[Omega-TI]

What program are you trying to use?

DM2K should work, using DSK4 or DSK0 as the TIPI drive alias.

 

What else is in your PEB? What crubase did you select?

 

None of the disk manager type tools know how to work for "TIPI."

 

-M@

 

I'll try again as DSK0.DOS and see what happens....

[Omega-TI]

What program are you trying to use?

DM2K should work, using DSK4 or DSK0 as the TIPI drive alias.

 

What else is in your PEB? What crubase did you select?

 

None of the disk manager type tools know how to work for "TIPI."

 

 

DSK0.DOS did not work...

 

Besides the TIPI all I have it a SAMS card, Triple Tech Card, TI-FDC and the Flex Card... pretty bare.

[Omega-TI]

I was just able to copy FROM DSK1. TO the mapped DSK3. okay... weird.

[+jedimatt42]

Try using DSK4. instead of DSK0.

 

I listed them in order of preference. I have tested mapped drives and DSK4. I thought Arcadeshopper told me DSK0 worked for him. But, I guess I was mistaken.

 

Somewhere in my docs I say that DSK4 is there for DM2K compatibility.

 

-M@

 

-M@

[+jedimatt42]

So far all of this except your DOS cartridge issue are expected behavior.

 

---

Also, It confused me that these were over here in the dev thread instead of the support thread. It would be best for all if end user usage issues are discussed in the support thread.

 

I'll summarize and repost there later.

 

 

 

-M@

[+jedimatt42]

 

Not sure whether this is important, but one should also keep in mind that the byte order is different between the TI console and other TI processors. The databus multiplexer of the TI console first accessed the odd byte (LSB), then the even byte (MSB), while the TMS9980A and the TMS9995 use a MSB-LSB order. This may have an effect for memory-mapped devices.

 

 

Does the Geneve screw with this, or will the timing diagrams from the processor datasheet be sufficient?

 

The 4A multiplexer does an odd thing, in that the WE and MEMEN signals don't change between addressing the high and low byte. So MEMEN transitions are useless.

 

This all works on my Genmod Geneve, but doesn't on other Geneves... 2 confirmed now. It simply appears as though WE is never signaled. Behaviorally... cause I don't have a problem-geneve (that's what I'm going to call everyone else's from now on )

 

Other thoughts, are if there is anything in that custom array that decides this write operaton leaves the geneve, and this one doesn't... on mine, I believe all of the memory is on the memex card, sometimes... TIMODE switch in TI MODE is supposed to pull back and use the Geneve's onboard ram for certain purposes... The explanations didn't make enough sense for me to retain... Ah... GROM emulations doesn't work if the memory is external.. first page of the Genod instructions...

 

Since things like HDX work where you have to program the RAM that is in the DSR space while in ROMPAGE mode, that being memory mapped isn't a problem... I just have to rewrite the decoding of write operations to my memory mapped latches inside the CPLD... but without time on a problem-geneve, it takes weeks per experiment.

 

-M@

[+InsaneMultitasker]

 

Since things like HDX work where you have to program the RAM that is in the DSR space while in ROMPAGE mode, that being memory mapped isn't a problem... I just have to rewrite the decoding of write operations to my memory mapped latches inside the CPLD... but without time on a problem-geneve, it takes weeks per experiment.

 

-M@

I believe I still have one spare, standard Geneve sitting on my shelf that I am happy to send to you for testing if nothing obvious materializes from your experimentation and queries.

[+InsaneMultitasker]

If I may make a suggestion...

 

For the TIPI PEB cards only, give consideration to changing DSK drive numbers from 1,2,3,4 to 5,6,7 [and maybe 8] via EPROM banking. This would eliminate the unit number conflict and the DSK conflict - both of which can occur in different programs at different times, based on order of CRU scan - whenever a floppy controller is present in the system.

 

Drives 5,6,7,[8] should also remove the potential conflict with DSK4 (non-TI controllers) and allow RAMdisk users to use DSK8,9 and letters A-Z for their needs.

 

If you are unhappy with the WDS support, perhaps replace it with this option. If a person has a floppy controller, they can flip to an EPROM bank containing drives 5,6,7,[8]. If the person gets comfortable enough with using the TIPI for all their file, they can pull the disk controller out and flip the switch back to the drives 1,2,3,4.

As a bonus if Fred is willing and able to implement your new floppy subdirectory level 2 routine >17, he could probably support subdirectories on the TIPI DSK devices with relatively little change, provided he has the program space to add the support. He'll want to scan the cards for TIPI device to ensure the right card/routine is used. I'm doing this for the Geneve loader and added that same code to another program of mine now that I know how it works with unit #0.

[+jedimatt42]

If I may make a suggestion...

 

For the TIPI PEB cards only, give consideration to changing DSK drive numbers from 1,2,3,4 to 5,6,7 [and maybe 8] via EPROM banking. This would eliminate the unit number conflict and the DSK conflict - both of which can occur in different programs at different times, based on order of CRU scan - whenever a floppy controller is present in the system.

 

Drives 5,6,7,[8] should also remove the potential conflict with DSK4 (non-TI controllers) and allow RAMdisk users to use DSK8,9 and letters A-Z for their needs.

 

If you are unhappy with the WDS support, perhaps replace it with this option. If a person has a floppy controller, they can flip to an EPROM bank containing drives 5,6,7,[8]. If the person gets comfortable enough with using the TIPI for all their file, they can pull the disk controller out and flip the switch back to the drives 1,2,3,4.

As a bonus if Fred is willing and able to implement your new floppy subdirectory level 2 routine >17, he could probably support subdirectories on the TIPI DSK devices with relatively little change, provided he has the program space to add the support. He'll want to scan the cards for TIPI device to ensure the right card/routine is used. I'm doing this for the Geneve loader and added that same code to another program of mine now that I know how it works with unit #0.

 

The only problem I have with this idea, is I don't understand why someone would want it? You use the word 'comfortable' ... So there is an emotional aspect I cannot yet grasp. The part you are meant to acclimate to is TIPI., not DSK1. I'm not trying to provide more DSKs... just allow some legacy software that assumes DSK1-3 to work from TIPI stored files... Having those renamed DSK5... doesn't help...

So why would you want DSK5? DSK6? DSK7? What would you use that for? They would be all new and just as incompatible with Level 2 IO as "TIPI." is.

 

If you don't want to use TIPI's DSK1, and there is a conflict, can you not just set the tipi's CRUBASE to >1800 or something above >1100 and TIPI will stay out of the way of your real drives? You'll still have full access to "TIPI."

 

I just don't get it... And I'd have to support it, and test it, and it gets burdensome cause it's no longer features I am sharing, it's request-for-features... If people really want that, there are a dozen of you with the skills to to make that change in about a day of rampup or less. Feel free to fork TIPI and make it your own. Or explain a use case you actually have.. I don't relate as well to proposed solutions, as I do to problem statements and use cases. If I don't understand what the problem is, I can't see the value in the solution... just cost in the form of more support expense.

 

---

 

My latest fixes allow copying from tipi hosted filesystem to DSK1 on the TI floppy controller, by going into TIPICFG, and pressing 'M' for myarc mode... Then without shutting off the console, go into DM2K. At this point TIPI doesn't have any DSKx's... it is just "TIPI." and "WDS1." and they are equivalent locations of the tipi hosted filesystem. But now the Level 2 io routines that are supported, are >4x instead of >1x names...

 

DM2K can copy with WDS1. as the source and legacy DSK?. as the destination. As well as the other way... Of course this may have other issues for you if you have a WDS1 already... I don't know... I can't even remember which piece of hardware provided that. It's all just myths and legends to me.

 

In TI mode, DM2K can copy from TIFDC DSK? disks to DSK4, or tipi mapped DSK? drives.

 

-M@

[+InsaneMultitasker]

My "comfortable" comment referred to the someone who might eventually decide to remove the disk/floppy controller and physical drives from their PEB, opting to use ONLY the TIPI PEB card. I was not referring to the device names like DSKx. or TIPI. or their uses.

 

Bumping TIPI DSK1-4 to TIPI DSK5-8. would be a simple means to eliminate all conflict between physical DSKx. and TIPI DSKx. devices. Why would I want it? To have unique DSKx. device names and unit numbers between the floppy controller and TIPI card, something a CRU base change cannot ensure. Nothing mysterious intended. [Edit: As noted later, the mapping function resolves this issue to a great degree]

 

I do not understand what you mean by "[DSK5-8] would be just as incompatible with level 2 IO as TIPI is". If you were referring to DSK-based sub-directory support then yes, I agree, otherwise we have a disconnect.

 

Latest fixes noted.

 

I wrote my suggestions after reading a few posts about disk copy issues, your comment that "The 'Myarc' mode doesn't work well enough to recommend either, as DM2K appears to assume something else about buffers that I will never know how to account for." and an earlier comment about having to write your own disk manager software. I should have included a bit of context earlier but that's why I posted in the development topic.

Edited August 13, 2018 by InsaneMultitasker

[+arcadeshopper]

My "comfortable" comment referred to the someone who might eventually decide to remove the disk/floppy controller and physical drives from their PEB, opting to use ONLY the TIPI PEB card. I was not referring to the device names like DSKx. or TIPI. or their uses.

 

Bumping TIPI DSK1-4 to TIPI DSK5-8. would be a simple means to eliminate all conflict between physical DSKx. and TIPI DSKx. devices. Why would I want it? To have unique DSKx. device names and unit numbers between the floppy controller and TIPI card, something a CRU base change cannot ensure. Nothing mysterious intended.

 

I do not understand what you mean by "[DSK5-8] would be just as incompatible with level 2 IO as TIPI is". If you were referring to DSK-based sub-directory support then yes, I agree, otherwise we have a disconnect.

 

Latest fixes noted.

 

I wrote my suggestions after reading a few posts about disk copy issues, your comment that "The 'Myarc' mode doesn't work well enough to recommend either, as DM2K appears to assume something else about buffers that I will never know how to account for." and an earlier comment about having to write your own disk manager software. I should have included a bit of context earlier but that's why I posted in the development topic.

 

 

There is no conflict. only a feature of TIPI to allow you to map a folder to DSK1,2,3 if you CHOOSE to do so. the level2 io issue is a software problem in disk manager. TIPI can be moved to a higher CRU to avoid it taking any DSK calls for physical drives.. it will still respond on the TIPI. device regardless

 

Perhaps also Fred will get a TIPI and add code to support it. This is due to the code in DM2K expecting a floppy DSR and not finding it. Matt's temp solution is to implement WDS1 mode which works for now..

 

Greg

[+jedimatt42]

It is my understanding that legacy software would be just as mystified by "DSK<5-7>." as they are with "TIPI.", is that not true?

 

What does a program like DM2K assume about DSK5? Looking at the binary, it appears to just map Level 2 IO types based on the prefix (first 3 letters) of the device name... Is that the norm? Will all the other software have followed that pattern? I expect large amounts of software to just HONK at me if I suggest to it there is a DSK5. Since 5 is greater than 3, or 4 if the software was 'progressive'

 

----

 

Anyway, thanks for hanging in there Tim!

 

----

 

What I'd like to know still is why... and everyone thinks they've told me why, but I haven't seen a single reason why yet. Eliminating the "conflict" isn't a use case, it is a solution approach. Having the "conflict" and exploiting it is my solution approach to old software.

 

A use case would be like: I run PageExtreme-2005, from my HRD mapped as DSK1-3 for the program disks, and it only allows DSKx for font disks, so I'd like to use folders on the TIPI as DSKA-Z for my alphabetized sub-directories of fonts and clip-art..

 

I'd respond with: 1) "Do you actually still use PageExtreme-2005?" And an example of someone actually using productivity software would say 'yep' , and then I'd be, "damn... ok, that's a real problem. So where do I find this software, and the manuals for it? Maybe I can work something up, but I want to test it."

 

? Does that make sense?

 

-M@

[tschak909]

Is there a way to detect the presence of the TIPI, programmatically? PLATOTerm crashes the emulator environment when it tries to do calls like tipi_on() to a nonexistent expansion.

 

-Thom

[+jedimatt42]

Is there a way to detect the presence of the TIPI, programmatically? PLATOTerm crashes the emulator environment when it tries to do calls like tipi_on() to a nonexistent expansion.

 

-Thom

 

In tipi_msg.c , there is the routine tipi_lib_init, which leaves tipi_crubase == 0 if no tipi is in the system.

 

You can modify the tipi_msg.h to make the variable extern, and provide a header/prototype declaration for the tipi_lib_init.... Then if you call that yourself before tipi_on, you can check for if the tipi is there. ..

 

Or you might be happy just tweaking tipi_on and tipi_off to do nothing if tipi_crubase is still == 0.

 

I'd probably evolve it to a 'boolean hasTipi()' function that is exposed, but is basically:

 

boolean hasTipi() {

tipi_lib_init()

return tipi_crubase() != 0;

}

 

-M@

[tschak909]

MrGW was able to successfully connect to IRATA and see the initial greeting, but the connection hangs, before the login screen is displayed... urgh.

 

-Thom

[tschak909]

For reference:

https://github.com/tschak909/platoterm99/blob/add_initial_tipi/io.c

https://github.com/tschak909/platoterm99/blob/add_initial_tipi/main.c

 

ok, so I've gone back and forth and double checked what I should be doing. I am calling my io_main() loop, which subsequently does a VDP interrupt poll, and then reads from the socket, if there is a non zero buffer, the buffer and length are passed to my protocol decoder, which handles the bulk of the terminal logic.

 

But it seems to hang... am I taking too long to process the socket data?

 

-Thom

[+InsaneMultitasker]

Just to be clear, I am not pressing for a change to the current TIPI DSR configuration.

 

It is my understanding that legacy software would be just as mystified by "DSK<5-7>." as they are with "TIPI.", is that not true?

 

What does a program like DM2K assume about DSK5? Looking at the binary, it appears to just map Level 2 IO types based on the prefix (first 3 letters) of the device name... Is that the norm? Will all the other software have followed that pattern? I expect large amounts of software to just HONK at me if I suggest to it there is a DSK5. Since 5 is greater than 3, or 4 if the software was 'progressive'

 

DSK5-9 should behave like any other floppy DSKx. device, so long as the software is not artificially limiting the device number, most often seen in older programs /or/ programs that rely upon sector IO, the latter being irrelevant to this discussion. I suppose old programs that only ask for a drive number might also limit the device number to 1-3? Honestly, I don't recall the last time I encountered or used a program that could only open drives 1-3.

 

The 3-letter prefix mapping to device/CRU is fairly 'recent'. It is necessary in programs that (a) rely upon level 2 IO and (b) support more than one hard drive card and © expect the user to type in the device name. This device mapping would almost never be used with DSK device (floppy controller, ramdisk, etc) as their DSRs try to avoid device duplicity wherever possible.

 

 

What I'd like to know still is why... and everyone thinks they've told me why, but I haven't seen a single reason why yet. Eliminating the "conflict" isn't a use case, it is a solution approach. Having the "conflict" and exploiting it is my solution approach to old software.

 

A use case would be like: I run PageExtreme-2005, from my HRD mapped as DSK1-3 for the program disks, and it only allows DSKx for font disks, so I'd like to use folders on the TIPI as DSKA-Z for my alphabetized sub-directories of fonts and clip-art..

 

I'd respond with: 1) "Do you actually still use PageExtreme-2005?" And an example of someone actually using productivity software would say 'yep' , and then I'd be, "damn... ok, that's a real problem. So where do I find this software, and the manuals for it? Maybe I can work something up, but I want to test it."

 

? Does that make sense?

 

-M@

I understand the approach. You and I tackle use cases and solutions differently.

 

If the workarounds and options are adequate for developer and users alike, then I see not further need to poke at the DSK5-8 suggestion. I'll leave the use case issues to the users who encounter them.

 

The "conflict" code is good and necessary; this is true whether or not you implemented the mapping feature. That reminds me of something I wanted to check within the Horizon RAMdisk DSR related to device duplication; I'll get back to you on that.

 

 

 

 

There is no conflict. only a feature of TIPI to allow you to map a folder to DSK1,2,3 if you CHOOSE to do so. the level2 io issue is a software problem in disk manager. TIPI can be moved to a higher CRU to avoid it taking any DSK calls for physical drives.. it will still respond on the TIPI. device regardless

 

Perhaps also Fred will get a TIPI and add code to support it. This is due to the code in DM2K expecting a floppy DSR and not finding it. Matt's temp solution is to implement WDS1 mode which works for now..

Technically yes, there is a conflict, better described as device duplicity, and it is partly responsible for how devices respond or fail. This isn't strictly a software issue created by the disk manager.

 

Anyway, asking Fred to support the TIPI device sounds like a winner to me. I'm already adding some TIPI device support to my test code and will try the folder mapping when I get a card.

Edited August 12, 2018 by InsaneMultitasker

[+9640News]

I've got a question or three, and maybe someone has already done this, or maybe it needs a tweak or two.

 

The Horizon Ramdisk had a Boot Menu program that would automatically load when the TI was turned on. Is there such an option for a TIPI system in some type of configuration? Maybe an extended basic program that autoload's DSK1.LOAD that in turn loads Boot? or an Autostart option "somehow"?

 

Looking at some way of accessing a number of TIPI's programs from a Menu without calling things from TI Basic.

 

I've got the FinalGrom99, so if there is a FinalGrom "module" that can accomplish the same thing, maybe that is another option.

 

On the Geneve in GPL mode, there was the ability to replace some of the GPL files with the BOOT menu. I do not think this is an option for the FinalGrom99 and TIPI, but if I am mistaken, or if something can be modified, it would be nice.

 

Anyways, just probing looking for some insight.

Beery