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

[+jedimatt42]

If we don't use an actual RPi, do you think the RPi python code would run on a PC if we replace libtipi with a library that can talk to an emulator?

The primary service, TipiService.py should run fine. Mouse.py is linux specific. The path name mapping in ti_names module might need changing for Windows. The native os file handling will probably have bugs on Windows.

 

-M@

[+jedimatt42]

I've been working on proof that besides in my DSR, I can do the messaging with TIPI from assembly... So here is a proof of concept around a mouse driver for TI Artist Plus:

 

https://github.com/jedimatt42/tipi/tree/master/examples/tiartist

 

(edit: Oops, this only works if TIPI is at CRUBASE >1100, cause I skipped implementing the search routine in assembly... guess I have that to look forward to )

 

Just the binary is in the zip.. the manuals for TI Artist Plus describe how you use this.

 

tipi-artist-driver.zip

 

I found that it is a bit too fast, so I've added a MOUSE_SCALE entry to the PI.CONFIG file, which should be set as a percentage... to set it to 50% enter:

MOUSE_SCALE=50

This will be available in an update that can be applied from inside TIPICFG. ( TI BASIC: CALL TIPI ) Once I publish the update, there will be a 'U' option.

 

that's the default... even if no entry is in the file. Different mice will have different resolutions... some will appear to be decaf, and others more like jolt-cola ( remember that? )

So this is 'service-side' scaling, before the TI gets an x and y delta as bytes.

 

-----------

 

The TI Artist Plus documentation lists all these interaction points, and warns that if you override EXTDSR ( the default joystick driver ) you may not get it back. Then in the disk image, there is a JOYST driver, and it is very different from EXTDSR. EXTDSR provides rubber-banding when using the drawing tools.

 

The example mechatronics mouse source doesn't appear to interact with the rubber-banding... Does anyone recall if that driver supported rubber-banding? or not? It is a disappointing experience without it.

 

When I get some more time, I'll probably have to debug the joystick driver EXTDSR or compare the disassemblies between EXTDSR and JOYST

 

-M@

[+arcadeshopper]

I've been working on proof that besides in my DSR, I can do the messaging with TIPI from assembly... So here is a proof of concept around a mouse driver for TI Artist Plus:

 

https://github.com/jedimatt42/tipi/tree/master/examples/tiartist

 

(edit: Oops, this only works if TIPI is at CRUBASE >1100, cause I skipped implementing the search routine in assembly... guess I have that to look forward to )

 

Just the binary is in the zip.. the manuals for TI Artist Plus describe how you use this.

 

tipi-artist-driver.zip

 

I found that it is a bit too fast, so I've added a MOUSE_SCALE entry to the PI.CONFIG file, which should be set as a percentage... to set it to 50% enter:

MOUSE_SCALE=50

This will be available in an update that can be applied from inside TIPICFG. ( TI BASIC: CALL TIPI ) Once I publish the update, there will be a 'U' option.

 

that's the default... even if no entry is in the file. Different mice will have different resolutions... some will appear to be decaf, and others more like jolt-cola ( remember that? )

So this is 'service-side' scaling, before the TI gets an x and y delta as bytes.

 

-----------

 

The TI Artist Plus documentation lists all these interaction points, and warns that if you override EXTDSR ( the default joystick driver ) you may not get it back. Then in the disk image, there is a JOYST driver, and it is very different from EXTDSR. EXTDSR provides rubber-banding when using the drawing tools.

 

The example mechatronics mouse source doesn't appear to interact with the rubber-banding... Does anyone recall if that driver supported rubber-banding? or not? It is a disappointing experience without it.

 

When I get some more time, I'll probably have to debug the joystick driver EXTDSR or compare the disassemblies between EXTDSR and JOYST

 

-M@

 

[+jedimatt42]

Greg did some play-testing of the mouse driver today, and I've got some usability issues to work out. ( It is well behaved, just too fast and some symantec issues )

 

So don't go deleting Deluxe Paint off your Amiga's yet, TI-Artist Plus and the TIPI mouse aren't quite there yet

 

-M@

[+arcadeshopper]

it's soooo close tho it's great for moving the cursor around.. actual drawing needs just a bit of taming down.. its TOO fast

 

also the first 10 TIPI's are on their way out over the next day

[+FarmerPotato]

Greg did some play-testing of the mouse driver today, and I've got some usability issues to work out. ( It is well behaved, just too fast and some symantec issues )

 

 

I haven't had Symantec issues since I switched to Borland.

[+jedimatt42]

I haven't had Symantec issues since I switched to Borland.

I blame auto-correct (which I used, but my starting point was pretty bad), and years of working next to one of their offices.

 

As a learning exercise: semantic semantic semantic semantic semantic semantic semantic semantic semantic... ok, I'm ready to cheat and use the electronic chalk board's cut-n-paste feature...

 

LOL...

 

-M@

[Sinphaltimus]

I'm very excited about this mouse driver.
My hope is that once it's ready for prime-time, there will be a section added to the TiPi webpage on how to set it up and use it step by step.

[+jedimatt42]

I'm very excited about this mouse driver.

My hope is that once it's ready for prime-time, there will be a section added to the TiPi webpage on how to set it up and use it step by step.

I know so many of us are file hoarders... so the instructions are in the .zip... But pointers to it are now up on the github wiki:

 

https://github.com/jedimatt42/tipi/wiki/Extension-Mouse

 

We now have examples of this in assembly, and gcc-C.

 

-M@

[Sinphaltimus]

I know so many of us are file hoarders... so the instructions are in the .zip... But pointers to it are now up on the github wiki:

 

https://github.com/jedimatt42/tipi/wiki/Extension-Mouse

 

We now have examples of this in assembly, and gcc-C.

 

-M@

 

Sweet! I WILL play with this over the weekend, you'll know when you start seeing my artwork posts.

[broettger]

I just received my TIPI yesterday and started playing around with it. I was wondering if it is possible to support dsk files as a virtual disk sort of like mounting an iso image as a virtual cd/dvd drive on Windows? This idea came to me when browsing the whtech ftp site. I will be the first to admit that I am a complete noob when it comes to using disks with a TI, either real iron or emulated. So, I may be thinking about this all wrong. In either case, some pointers in the right direction are appreciated.

Edited April 17, 2018 by broettger

[Sinphaltimus]

I just received my TIPI yesterday and started playing around with it. I was wondering if it is possible to support dsk files as a virtual disk sort of like mounting an iso image as a virtual cd/dvd drive on Windows? This idea came to me when browsing the whtech ftp site. I will be the first to admit that I am a complete noob when it comes to using disks with a TI, either real iron or emulated. So, I may be thinking about this all wrong. In either case, some pointers in the right direction are appreciated.

There's currently no way to do that however; if you download a dsk file from whtech you can open it with TIImageTool or TI99DIR and copy the files from inside the DSK to a folder in windows. Then use the TIPI web interface to upload those files to where you want them so that TIPI will convert them properly in the case they are not natively TIFiles.

Edited April 17, 2018 by Sinphaltimus

[+jedimatt42]

I just received my TIPI yesterday and started playing around with it. I was wondering if it is possible to support dsk files as a virtual disk sort of like mounting an iso image as a virtual cd/dvd drive on Windows? This idea came to me when browsing the whtech ftp site. I will be the first to admit that I am a complete noob when it comes to using disks with a TI, either real iron or emulated. So, I may be thinking about this all wrong. In either case, some pointers in the right direction are appreciated.

I have ABSOLUTELY no desire to implement DSK support, other than a feature to allow uploading DSK files via the web-ui and having it autoconvert to a properly named directory full of the TIFILES files.

 

But that'll take some time... If anyone has links to the documentation on sector dumps and track dumps, and how to tell one from another, that would be useful.

 

-M@

[+jedimatt42]

Oh, speaking of features, I published an update for the PI side software that fixes some catalog issues for programs trying to get long filenames ( more than 10 characters ) using Tursi's proposed hosted filesystem support.

 

This fixes a bug exposed by his Slideshow program.

 

-M@

[Omega-TI]

I had a thought pop into my head today when thinking about the future P-Box TIPI. Is the Rpi going to be outside the P-box or inside attached to the card TIPI card? The only reason I'm inquiring is because I'm wondering... will the WiFi be able to communicate with the router if it's inside of a METAL BOX?

[+jedimatt42]

I had a thought pop into my head today when thinking about the future P-Box TIPI. Is the Rpi going to be outside the P-box or inside attached to the card TIPI card? The only reason I'm inquiring is because I'm wondering... will the WiFi be able to communicate with the router if it's inside of a METAL BOX?

I started thinking about that again Sunday, so I ripped up most of the routing and have been working on allowing some choice.

 

A PI Zero W has no external antenna option, so it's outside the PEB or under the 'EMS' labelled lid... I don't know anything about radio... but I'm sure being inside the PEB won't help...

 

I'm hoping to offer mounting holes for a PI 3 on the pcboard just inside the case at the top... So, ethernet ports and USB connectors are near the back if the board is mounted inside.

 

The signal wires from the PI to the TIPI board are really prone to noise... So I'm still thinking about what to do about that. That could be better inside the PEB, or it could be worse...

 

Work in progress:

 

I'd still like the PI Zero W to be able to just plug into the back. We'll see how it goes.

 

-M@

[+9640News]

I have been thinking about the PEBox card and the PI. Will the PI draw power from the PEBox, or use its own external power supply source?

 

If it is able to draw power from the PEBox, thoughts on how to properly shut down the PI? Thinking of some kind of switch that senses the supply voltage is gone, and uses some kind of on board battery to provide power for the 30 to 60 seconds to shut the PI down.

 

Otherwise, I would anticipate in my case the PI would always be on. Not sure what you are doing now with the non PEBox version.

 

Just curious.............

 

Beery

[+jedimatt42]

No, I will not provide power to the PI from the PEB, the PI should stay always on in general.

 

Our old PEBs and 4As require power cycling. PIs boot fast, but not that fast.

 

-M@

[Omega-TI]

That an interesting question Beery. Since the TIPI interface will be in the box, I assumed power for the internal TIPI card would also be from the box, albeit stepped down to the requisite 5V via a regulator. The RPi uses the same power requirement as the TIPI, so I suppose passing current through to the Rpi would make for an efficient design.

 

Four AA NiCads would be 4.8v so they could easily be floated in parallel without the need for charging circuitry, although diodes would be required to prevent draining the batteries when not in use, but from my limited point of view, I'd just keep the Rpi on at all times with an external power supply to save on all the engineering and extra components costs associated with sensing power off, and the additional scripting needed to make it shut down. Sometimes easier is better.

[Omega-TI]

Hmm.. I guess Matt answered while I was typing!

[+9640News]

Thanks for the feedback. Just trying to understand what the requirements would be.

 

Beery

[+jedimatt42]

Lots of engineers could come up with better solutions... I saw an MFM emulator that used a beagle-bone-black ( PI like thing ) and it had a bunch of large capacitors on board and issued shutdown to the PI like thing when primary power was removed...

 

but You'd have to wait another year if you want that sort of feature. And I don't want that sort of feature, and I have to build this for myself... I'm just sharing with you guys.

 

-M@

[+arcadeshopper]

That an interesting question Beery. Since the TIPI interface will be in the box, I assumed power for the internal TIPI card would also be from the box, albeit stepped down to the requisite 5V via a regulator. The RPi uses the same power requirement as the TIPI, so I suppose passing current through to the Rpi would make for an efficient design.

 

Four AA NiCads would be 4.8v so they could easily be floated in parallel without the need for charging circuitry, although diodes would be required to prevent draining the batteries when not in use, but from my limited point of view, I'd just keep the Rpi on at all times with an external power supply to save on all the engineering and extra components costs associated with sensing power off, and the additional scripting needed to make it shut down. Sometimes easier is better.

Stop assuming things you can rig your pi however you want externally. But it isn't supported directly by the tipi card.

 

Sent from my LG-H872 using Tapatalk

[Omega-TI]

Lots of engineers could come up with better solutions... I saw an MFM emulator that used a beagle-bone-black ( PI like thing ) and it had a bunch of large capacitors on board and issued shutdown to the PI like thing when primary power was removed...

 

but You'd have to wait another year if you want that sort of feature. And I don't want that sort of feature, and I have to build this for myself... I'm just sharing with you guys.

 

-M@

 

"Better solutions" are often one mans opinion. I like all the stuff I've seen from you so far, it's all very well thought out, well designed and constructed well.

 

Sure, a guy could add a bunch of extra components, raising the price and delaying the release, but all we would get is something more expensive with more to go wrong and for what... just the ability to turn itself off? Screw that!! I don't want to wait! I'll gladly leave it plugged in 24/7 just like I do with the current TIPI setup and it's working just fine!

[Omega-TI]

Stop assuming things you can rig your pi however you want externally. But it isn't supported directly by the tipi card.

 

Sent from my LG-H872 using Tapatalk

 

True, but when Beery posted his message it was an 'unknown' about the RPi power source, until Matt answered it. My assumption was about the TIPI's power source as it only seemed logical. The rest (about the Rpi) was speculation about a design avenue. In the end, I like his solution.