TIPI Usage and Support

[+jedimatt42]

If you run the audio through a VGA to HDMI adapter, you likely won't hear the TIPI tones due to the adapter not sync'ing fast enough on power up... but then an FCTN= should let reset, and let you hear my musical genius.

 

-- OH, I forgot... ---

 

The significance of the tones, is it means the TIPI DSR powerup routine executed. A.K.A The ROM is readable and the CPLD handled the CRU and address decoding fine.

 

-M@

[+arcadeshopper]

Just tossed this together as I was tired of typing in the paths in TIPICFG

 

http://ftp.whtech.com/Users/Gregory%20McGill/TIPIMAP

 

runs in Xbasic, lets you arrow to the "folder" you want mapped and hit 1 or 2 or 3 to map to DSK1 DSK2 OR DSK3 should work to move forward/back in directory tree, report bugs to me in a pm please if you find any

 

Greg

[+arcadeshopper]

Just tossed this together as I was tired of typing in the paths in TIPICFG

 

http://ftp.whtech.com/Users/Gregory%20McGill/TIPIMAP

 

runs in Xbasic, lets you arrow to the "folder" you want mapped and hit 1 or 2 or 3 to map to DSK1 DSK2 OR DSK3 should work to move forward/back in directory tree, report bugs to me in a pm please if you find any

 

Greg

 

I already found one, if you go into a empty folder (ie it has no folders) then left arrow back, it wont map correctly.. will fix and update, fixed and updated and added wrap around to the selector screen

[Omega-TI]

I have a question on the TIPICFG program. Is the H)alt option the same as shutting down the Rpi? I was thinking how nice it would be to easily shut the Rpi down if one was going to leave the house for a few days or if they needed to plug or unplug stuff or do anything else. From what I understand removing power without shutting it down first is not recommended.

[+jedimatt42]

I have a question on the TIPICFG program. Is the H)alt option the same as shutting down the Rpi? I was thinking how nice it would be to easily shut the Rpi down if one was going to leave the house for a few days or if they needed to plug or unplug stuff or do anything else. From what I understand removing power without shutting it down first is not recommended.

Good question, that terminology is a bit archaic. But it struck me as important, because you cannot actually power-off a Raspberry PI with a software command. You can only 'halt' the OS like PCs before ATX software controlled powersupplies. (actually I remember now that it also fit on the small TI screen better than shutdown, and s was used for something...)

 

I've just updated the wiki to cover this and explain the rest of TIPICFG. https://github.com/jedimatt42/tipi/wiki/TIPICFG

 

After issuing the halt, wait a bit for the Raspberry PI to flush everything and stop writing to the sd-card. Some have a light. See your Raspberry PI's owners manual for details LOL... Actually lots of the kits come with a piece of paper that explains this.

 

You can also use the webui to halt the Raspberry PI... http://tipi:9900

[HOME AUTOMATION]

Hi all,

My interest in using TIPI is mainly running and hopefully developing assembly language programing. However I have not been successful in saving object code to TIPI. It seems as if the source code reads but then the assembler hangs. Tried all manor of disk alias, naming conventions,etc. Perhaps the assembler uses sector based access or a controller present check? If nothing is wrong with my system, I could use a good work-around!

(I am using E/A PHM 3055)

Edited April 29, 2018 by HOME AUTOMATION

[+jedimatt42]

Hi all,

My interest in using TIPI is mainly running and hopefully developing assembly language programing. However I have not been successful in saving object code to TIPI. It seems as if the source code reads but then the assembler hangs. Tried all manor of disk alias, naming conventions,etc. Perhaps the assembler uses sector based access or a controller present check? If nothing is wrong with my system, I could use a good work-around!

(I am using E/A PHM 3055)

I believe this is a bug in my python code on the Raspberry PI... We recently tried the XB compiler workflow and ran into this same issue. I WILL definitely be fixing this with a software update. Stay tuned! So far I've observed that the system chokes when the assembler writes a zero-byte record for a fixed record length file. BASIC on the other hand, writes a padded record for fixed record files... so I'm missing some handling around that, I believe.

 

I don't have an on-machine workaround. But I've done my assembly work with xdt99's xas99 cross assembler. And then convert the files into TIFILES and copy them onto the tipi using scp or the windows network share. This makefile captures my process for creating the TiArtist mouse driver object code as a TIFILES file: https://github.com/jedimatt42/tipi/blob/master/examples/tiartist/Makefile

 

-M@

[HOME AUTOMATION]

I believe this is a bug in my python code on the Raspberry PI... We recently tried the XB compiler workflow and ran into this same issue. I WILL definitely be fixing this with a software update. Stay tuned! So far I've observed that the system chokes when the assembler writes a zero-byte record for a fixed record length file. BASIC on the other hand, writes a padded record for fixed record files... so I'm missing some handling around that, I believe.

 

I don't have an on-machine workaround. But I've done my assembly work with xdt99's xas99 cross assembler. And then convert the files into TIFILES and copy them onto the tipi using scp or the windows network share. This makefile captures my process for creating the TiArtist mouse driver object code as a TIFILES file: https://github.com/jedimatt42/tipi/blob/master/examples/tiartist/Makefile

 

-M@

Thanx, jedimatt42:)

Good to hear there is hope! It seems I'll have to do a lot of "on machine" coding as I have plenty of prototyping hardware that I connect to the 9901. But you know about that. My eyes went goo goo when I saw your and or ElectricLab's Breadboard in a Youtube video. Right now my debugging system is to simply(not so) review my code and look for err's. I am forced to assemble in MAME (AORG >7000), load to minimem in MAME, transfer to voice recorder using EASYBUG and finally load on the physical TI 99/4a. TIPI will help with this, when I find the right sequence of steps. However my ultimate use for TIPI will be to LOAD, SAVE blocks of programs and data from Assy.

 

I'm unfamiliar with Makefile or Python or shells(need to catch-up). I wonder does anyone know of a disk based assembler(besides L by L) other than TI's E/A package?

[+jedimatt42]

I'll work on getting the TI assembler fixed this week.

 

We ran into thus for the first time just last Thursday. Arcadeshopper tried a few of the other TI assemblers, and they all had the same issue.

 

-M@

[+jedimatt42]

I'll work on getting the TI assembler fixed this week.

 

We ran into thus for the first time just last Thursday. Arcadeshopper tried a few of the other TI assemblers, and they all had the same issue.

 

-M@

Ok, good news, bad news situation:

 

Good news, I've fixed this issue writing Fixed record files from assemblers. And, I'm updating the ROMs for the batch I was about to send to Arcadeshopper yesterday.

 

The bad news, it requires an EPROM upgrade. The eprom image can be found on my website: http://ti994a.cwfk.net/index.html.

 

The TIPI EPROM has a lot of space in it, and folks are throwing around ideas that would require future ROM updates. So I recommended anyone with a TIPI to also own a MiniPro TL866 programmer, or your alternate favorite EPROM programmer, and a UV EPROM eraser. There will be future updates to the ROM, not just for bugs.

 

But, if burning isn't your thing, Arcadeshopper offers this service.

 

---

 

There is also an online update for the PI side of things, that correct some header creation errors (might only happen along with these errors) and fixes the OLED display support. Just use the TIPICFG update mechanism to fetch that.

 

-M@

[Shift838]

figured I would post this here since it's a tipi support thread.

 

I did the new update to b17.

 

after the reboot when trying to access my TIPI my LED just stays lit, nothing, no errors on the TI.

 

When i issue the command:

sudo systemctl status tipi.service

I see the below, this looks like an issue to me. I have rebooted several times.. suggestions ?

May 03 01:55:17 tipi systemd[1]: tipi.service: Main process exited, code=exited,
May 03 01:55:17 tipi systemd[1]: tipi.service: Unit entered failed state.
May 03 01:55:17 tipi systemd[1]: tipi.service: Failed with result 'exit-code'.
May 03 01:55:17 tipi systemd[1]: tipi.service: Service hold-off time over, sched
May 03 01:55:17 tipi systemd[1]: Stopped TI-99/4A DSR Service.
May 03 01:55:17 tipi systemd[1]: tipi.service: Start request repeated too quickl
May 03 01:55:17 tipi systemd[1]: Failed to start TI-99/4A DSR Service.
May 03 01:55:17 tipi systemd[1]: tipi.service: Unit entered failed state.
May 03 01:55:17 tipi systemd[1]: tipi.service: Failed with result 'exit-code'.

 

[+jedimatt42]

You could capture the /var/log/tipi/tipi.log, might be something there.

 

Then just try a: sudo systemctl restart tipi.service

 

I'm sure I have more to learn about systemd

 

-M@

[Shift838]

so I pulled out another SD card and slapped the b12 image on it from Matt's site. I was able to boot again and access the TIPI, but as soon as I told it to upgrade from the TIPI utility and rebooted I was in the same boat.

[+jedimatt42]

so I pulled out another SD card and slapped the b12 image on it from Matt's site. I was able to boot again and access the TIPI, but as soon as I told it to upgrade from the TIPI utility and rebooted I was in the same boat.

Ok, I'll go through that process.

 

But so that I can: please describe what did you reboot, and when? The TI, or the PI?

 

The TIPICFG tool sadly doesn't have a way to monitor the upgrade process... it just triggers it. So it can be some minutes after updating before things are restarted. I'll add it to the todos to find a way to inform when the update is complete.

 

If you reboot the PI while it is still updating, a bunch of software will only be half compiled. And the services won't be enabled or will fail to start because the dependencies are not sound.

 

If this happens, going into the /home/tipi/tipi/setup directory and running the post-upgrade script as root should rebuild things: sudo ./post-upgrade.sh

 

Sadly, in order to not trash your sd-cards, the logs are written to tmpfs. So they are always lost if you reboot. But there should be some indications in the daemon.log and the tipi.log if there are issues during service startup.

 

-M@

[Shift838]

Ok, I'll go through that process.

 

But so that I can: please describe what did you reboot, and when? The TI, or the PI?

 

The TIPICFG tool sadly doesn't have a way to monitor the upgrade process... it just triggers it. So it can be some minutes after updating before things are restarted. I'll add it to the todos to find a way to inform when the update is complete.

 

If you reboot the PI while it is still updating, a bunch of software will only be half compiled. And the services won't be enabled or will fail to start because the dependencies are not sound.

 

If this happens, going into the /home/tipi/tipi/setup directory and running the post-upgrade script as root should rebuild things: sudo ./post-upgrade.sh

 

Sadly, in order to not trash your sd-cards, the logs are written to tmpfs. So they are always lost if you reboot. But there should be some indications in the daemon.log and the tipi.log if there are issues during service startup.

 

-M@

 

This was my process:

 

1. wrote image to SD card
2. booted Pi3 and let it come up
3. booted up 32k, and Console
4. SSH into Pi3
5. Expanded File system
6. Reboot Pi3
7. go in to TIBASIC and CALL TIPI
8. Executed upgrade to b17
9. Reloaded TIPI config and it showed b17
10. Rebooted Pi3

After it came up and I could see the web server I tried to access CALL TIPI again and no dice.

 

if you think I rebooted too quickly then I can do it again and give it a few minutes (I did not have a lot of things configured on it yet), but I was under the assumption that when reloading the TIPI config from the TIPI utility and when it said the new version I was good.

[+jedimatt42]

This was my process:

• wrote image to SD card
• booted Pi3 and let it come up
• booted up 32k, and Console
• SSH into Pi3
• Expanded File system
• Reboot Pi3
• go in to TIBASIC and CALL TIPI
• Executed upgrade to b17
• Reloaded TIPI config and it showed b17
• Rebooted Pi3

After it came up and I could see the web server I tried to access CALL TIPI again and no dice.

 

if you think I rebooted too quickly then I can do it again and give it a few minutes (I did not have a lot of things configured on it yet), but I was under the assumption that when reloading the TIPI config from the TIPI utility and when it said the new version I was good.

 

Nope, I don't think you rebooted too quickly... the 'reload' step shouldn't work until the upgrade is done.

I'm flashing an sd-card now...

 

-M@

[+jedimatt42]

Nope, I don't think you rebooted too quickly... the 'reload' step shouldn't work until the upgrade is done.

I'm flashing an sd-card now...

 

-M@

I said "shouldn't" cause I introduced a bug a while back... and of course that is what happened... The old service was still running. The update actually takes quite a while. The old service read the new version.txt when status was reloaded.

 

You should be able to recover your previous image by booting the PI off that sd-card, from a ssh session by running the post-upgrade.sh (with sudo), and waiting until it completes.

 

---

 

I'm fixing the post-upgrade to stop the services first, so that reloading the config and status in TIPICFG will hang until the upgrade is done and the services are restarted. (like it used to in our early closed beta...)

And, I found the last piece as to why the pioled isn't working. Which is because I forgot to turn it on in that image... ( now that I've fixed 3 other reasons why it wouldn't work ) I am enabling that in the upgrade script.

 

-M@

[+arcadeshopper]

also if you run upgrade and have the oled display it should say upgrading then tipi ready when it's ready

[Shift838]

I used the CLI to upgrade but the services still would not start. Since I did not have much configured I blew the SD card away and started over and upgraded via the TIPI Utility and just let it run for 5 minutes then SSH back into the device and made sure the tipi service was running. Not sure why the first time when I pressed the R to reload the tipi configuration and saw the new version so fast. This time it took a few minutes to load and query. Then I saw a magical glow from the OLED.

 

All is good now. OLED working and everything.

Edited May 3, 2018 by Shift838

[Omega-TI]

Well, RAT FARTS!

I saw that you had success, so I hit the U button when it said build 18 was available. I waited 45 minutes, then hit the R for reload... and I got nothing.

All I get when I call TIPI is a red light. I will not have the time for the next couple of days to start over, so I'm hoping a new upgraded and up-to-date image will be available to download and start all over with.

[Shift838]

Well, RAT FARTS!

I saw that you had success, so I hit the U button when it said build 18 was available. I waited 45 minutes, then hit the R for reload... and I got nothing.

All I get when I call TIPI is a red light. I will not have the time for the next couple of days to start over, so I'm hoping a new upgraded and up-to-date image will be available to download and start all over with.

 

Try and do what Matt suggested. SSH into the Pi

 

go to home/tipi/tipi/setup

 

issue:

 

sudo /.post-upgrade.sh

 

maybe it will work for you and just let it run. once it is finished

 

issue the 'sudo systemctl status tipi.service'

 

see if the tipi service is running. If so you should be good. If not then reflash and start over. I'm also running the latest DSR that Matt updated on his site.

Edited May 3, 2018 by Shift838

[+arcadeshopper]

 

Try and do what Matt suggested. SSH into the Pi

 

go to home/tipi/tipi/setup

 

issue:

 

sudo /.post-upgrade.sh

 

maybe it will work for you and just let it run. once it is finished

 

issue the 'sudo systemctl status tipi.service'

 

see if the tipi service is running. If so you should be good. If not then reflash and start over. I'm also running the latest DSR that Matt updated on his site.

 

this..

 

This is BETA software so you can expect things like this periodically. Also you all need new DSR roms if you want EA to work right with TIPI.. I can burn them for you or you can burn your own on a 27c256

 

Greg

[broettger]

I haven't ever burned an eeprom before. Any guidance on what kind of equipment and software I will need to do this? Since this is just a hobby, an inexpensive solution is preferred.

[+arcadeshopper]

I haven't ever burned an eeprom before. Any guidance on what kind of equipment and software I will need to do this? Since this is just a hobby, an inexpensive solution is preferred.

Minipro and a Windows or Linux computer and blank roms or a eraser

 

 

 

Sent from my LG-H872 using Tapatalk

[Omega-TI]

Matt,

I'm thinking with the 20 TIPI's Greg will be selling soon, the SD image should probably be update for ease of installation for newbies, and those of us who could not successfully update to version 18.