TIPI Usage and Support

[+Vorticon]

5 minutes ago, jedimatt42 said:

@Vorticon, next time this happens, capture the var/log/daemon.log before power cycling the PI. It should point at the problem...

I'll try to remember that. Thankfully everything is backed up.

[+jedimatt42]

3 hours ago, mizapf said:

Links on jedimatt's page have changed: https://jedimatt42.com/dl

I've added a redirect so the old link should get you there automatically, now. 

[+mizapf]

3 hours ago, jedimatt42 said:

If you are going to emulate TIPI and allow other cards in the virtual peb, you must allow the user to set the crubase.

Sure, this is already possible. The only question is: What is a reasonable default setting?

 

The average MAME user starts the emulation, glad to have found a suitable command line, and typically checks the CRU setting after things did not work. ?

 

Obviously, I'm sometimes such an average user, because I forgot that GeneveOS 7.30 needs the base set to 1800.

[+jedimatt42]

Reasonable clearly depends on if Geneve or if 4A... 

 

Older Geneve OS versions (6.5) are probably fine with nearly any crubase using rompage.

 

Maybe fix the "geneve" script/add a "geneve-tipi" script.. IDK...    

 

Is the Mame TIPI support expected to be working yet? 

[GDMike]

6 hours ago, Vorticon said:

When I tried to upgrade my TIPI last night, it got stuck on the message "upgrade in process" for ever, so I eventually shut it down, and now of course it won't come up again with CALL TIPI. I can still access it via ssh.  This has happened before and the only recourse is to reflash the SD card. Anyone else here has had similar issues?

The only probs I've had is when the power was shut down overnight and then pi won't boot.

[+mizapf]

1 hour ago, jedimatt42 said:

Reasonable clearly depends on if Geneve or if 4A... 

Older Geneve OS versions (6.5) are probably fine with nearly any crubase using rompage.

Maybe fix the "geneve" script/add a "geneve-tipi" script.. IDK...    

 

That's easier to say than to achieve in MAME. CRU settings are DIP settings and as such not settable in the command line, only within the emulation. They are stored in a config file and restored next time. So one could manipulate that config file, but it's a hassle.

 

Also, I can only provide one TIPI card, not a Geneve or a TI version. There is only one real card, so I should not consider creating different ones in emulation.

 

So in the end, I may leave it to the default that is suitable for the majority, i.e. for the TI console. After all, the next GeneveOS will fix it.

 

1 hour ago, jedimatt42 said:

Is the Mame TIPI support expected to be working yet? 

Yes.

[+dhe]

Just have to say how much I love TIPI backup and restore. Makes a man fearless in changing things!

[+InsaneMultitasker]

Looking for clarification to the WIKI entries below.  Maybe a table to describe the four possible CRU selections and associated 8K bank addresses? 

The bank switching and DSR rom descriptions for bits 2 and 3 seem contradictory.  Also, is the WDSx bank still supported or deprecated? 

Design · jedimatt42/tipi Wiki · GitHub

DSR Bank Switching

TIPI's current DSR ROM is well within the 8k (minus 8bytes) size limit of the TI memory map. However 32K eproms are used. So CRU bits at offset 2 and 3 control the state of the upper address lines.

Currently the DSR build script builds 2 8K ROM images. 1 has DSK0-4 and DSK devices, and the other has a WDS1 device. The Level 2 IO routine have appropriate names as well. This is controlled by CRU bit offset 3.

DSR ROM

The DSR rom contains standard TI headers that allow the TI operating system to lookup the routines that handle the different device names and named functions.

It is a 32K ROM, CRU bits 2 and 3 control switching in 8k banks.

If CRU bits 2 and 3 are not-set, then the DSR provides DSK1-4 aliases for level 3 IO, and level 2 IO routines in the >1x range.

If CRU bits 2 is set, and 3 is not-set, then the DSR provides WSD1 alias for level 3 IO, and level 2 IO routines in the >4x range. (note: this mode is for debugging issues and may go away in the future)

[+InsaneMultitasker]

I forgot to mention the reason I ask:  I have encountered a few instances where the TIPI device has suddenly been unavailable and I when I went snooping around with SBUG (debugger) the >4000 space was 0x0000 for the entire 8k space.  I cleared bits 2 and 3, and the DSR began responding again.  I have since burned a new EPROM image for my card that repeats bank 0 in bank 1,2,3 though I'm trying to figure out what might have caused the bit flipping in the first place.  

[+jedimatt42]

Yep, that was outdated text... the EPROM is all in the first 6k-ish of the 32k. The cru based bank switching is not used.

 

crubit 0 ( dsr-on )

crubit 1 ( TipiService reset )

crubit 2 & 3 control address lines of the 32K rom... 

 

but everything beyond the first 6k ish of the ROM is zerooooo... 

 

crubit 2 & 3 should always be 'sbz' 0 / clear / unset

 

[+InsaneMultitasker]

9 minutes ago, jedimatt42 said:

Yep, that was outdated text... the EPROM is all in the first 6k-ish of the 32k. The cru based bank switching is not used.

 

crubit 0 ( dsr-on )

crubit 1 ( TipiService reset )

crubit 2 & 3 control address lines of the 32K rom... 

 

but everything beyond the first 6k ish of the ROM is zerooooo... 

 

crubit 2 & 3 should always be 'sbz' 0 / clear / unset

 

Appreciate the quick response.  I was starting to think I had a hardware problem. I encountered this issue primarily with the Geneve system but I suspect it is the same thing I had happen with my TI.  Does a hardware reset or TIPI reset modify these bits or are they persistent?

[+jedimatt42]

the state of all the crubits in the TIPI live in the CPLD.

 

The 2 in question are never set by any software from me. Sadly this includes the register power on state in the CPLD. I don't set the default state to 0 in the verilog, but I've never observed it having any other value. So the power on state is whatever the default is in verilog, and I didn't learn enough verilog to know the answer to that. 

 

(the answer from the internet seems to be 'undefined' / don't do that.. / use a different language than verilog such as system-verilog that enforces initialization)

 

The TIPI does not have a hardware reset circuit.

[Duewester]

Hello Ti 99ers

First I wanna say that the forums here are of great interest and value, and I didn't realize there were so many 99ers.

I searched through all 83 (as of 6/29/2022) pages of this particular topic and I still have a issue and questions.

My setup:

Ti 99 4a (of course)

FinalGROM99

32K sidecar from Arcade shopper

TIPI (TIPI DSR ROM v.19APR21) CRUEBASE1 Jumper installed as received across bottom two pins, attached to 32K module

99 is connected to HDMI via composite cable and adapter.

Using 99 to power the sidecar and TIPI.

Raspberry Pi 02W with female socket attached only to last ten GPIO on Pi. So, no cable involved. Powered by separate power supply.

  Two different SD cards (32gb SanDisk HCI A1 and SanDisk Edge 16gb HCI A1) that have same image and can be accessed via ssh when not plugged into TIPI. Both cards created using Raspberry Pi Imager tool. Both cards with tipi as user and password on my home network. (Took like seemed forever to get tipi image on any card)

 

Used Extended Basic from FinalGROM99 to verify 32K Sidecar is working.

Plugged TIPI without Pi and used call tipi and CALL TIPI and received message Bad Name.

Added Pi to TIPI and booted the Pi. Waited for activity LED to stop blinking (usually means no activity) so assume Pi is booted.

Turned on 99. Used built in Basic to call tipi and CALL TIPI with same result - Bad Name, used EB via FinalGROM to call tipi and CALL TIPI with same Bad Name result.

 

Other observations:

Neither LED on 32k sidecar nor Tipi ever lights or blinks

5v on top left pin of TIPI (looking at 44 pins with Pi connector on right

Reseated jumper and ROM

 

I read here that Bad Name means no power or fried tipi. Is there something I can test via T2 - T5 to confirm cooked TIPI (I'm not sure how I could have cooked it because the Pi can only be connected one way)

 

I feel that I'm a reasonably competent troubleshooter with more tools than I need so, any suggestions?

 

Thank you to all for taking the time to read my lengthy post and I look forward to additional posts on the subject. 

[+InsaneMultitasker]

On 6/25/2022 at 8:00 PM, jedimatt42 said:

The TIPI does not have a hardware reset circuit.

Got it.   For the Geneve, I traced down the issue to the 30+ year old assumption that there is "always" a floppy controller at CRU >1100.  The OS  does not validate the EPROM header byte >AA and twiddles bits, including 2 and 3, during the detection phase, thus setting to a different bank; I've dealt with this in the OS.  As for the /4A problem, I haven't tracked down the cause and it hasn't recurred, so I won't pursue it any further. Worst case, I'll toss a bank-mirrored EPROM into that card too. Thanks.

[dgrissom]

On 6/29/2022 at 11:33 AM, Duewester said:

...

Using 99 to power the sidecar and TIPI.

.. .

I've used a similar setup.  (Currently using a SAMs sidecar and TIPI.)

If using a speech synthesizer, make sure that it has the power pass through mod.

In some of the threads there was a discussion that indicated that the console may not have enough power to power the sidecars as you have configured.

I was able to power everything with a TIPI/32 card setup.  Using separate cards, it won't work.  

On my SAMs / TIPI combo, I use a USB splitter cable to for power.

 

Hope this helps.

 

DG

[+jedimatt42]

On 6/29/2022 at 9:33 AM, Duewester said:

Hello Ti 99ers

First I wanna say that the forums here are of great interest and value, and I didn't realize there were so many 99ers.

I searched through all 83 (as of 6/29/2022) pages of this particular topic and I still have a issue and questions.

My setup:

Ti 99 4a (of course)

FinalGROM99

32K sidecar from Arcade shopper

TIPI (TIPI DSR ROM v.19APR21) CRUEBASE1 Jumper installed as received across bottom two pins, attached to 32K module

99 is connected to HDMI via composite cable and adapter.

Using 99 to power the sidecar and TIPI.

Raspberry Pi 02W with female socket attached only to last ten GPIO on Pi. So, no cable involved. Powered by separate power supply.

  Two different SD cards (32gb SanDisk HCI A1 and SanDisk Edge 16gb HCI A1) that have same image and can be accessed via ssh when not plugged into TIPI. Both cards created using Raspberry Pi Imager tool. Both cards with tipi as user and password on my home network. (Took like seemed forever to get tipi image on any card)

 

Used Extended Basic from FinalGROM99 to verify 32K Sidecar is working.

Plugged TIPI without Pi and used call tipi and CALL TIPI and received message Bad Name.

Added Pi to TIPI and booted the Pi. Waited for activity LED to stop blinking (usually means no activity) so assume Pi is booted.

Turned on 99. Used built in Basic to call tipi and CALL TIPI with same result - Bad Name, used EB via FinalGROM to call tipi and CALL TIPI with same Bad Name result.

 

Other observations:

Neither LED on 32k sidecar nor Tipi ever lights or blinks

5v on top left pin of TIPI (looking at 44 pins with Pi connector on right

Reseated jumper and ROM

 

I read here that Bad Name means no power or fried tipi. Is there something I can test via T2 - T5 to confirm cooked TIPI (I'm not sure how I could have cooked it because the Pi can only be connected one way)

 

I feel that I'm a reasonably competent troubleshooter with more tools than I need so, any suggestions?

 

Thank you to all for taking the time to read my lengthy post and I look forward to additional posts on the subject. 

Somehow I hadn't seen this post... 

 

The test pads are not programmed to do anything in the released designs. 

 

The led on a TIPI should blink when the console scans for power up routines in the ROM during console initialization. 

 

Since it isn't responding, I guess I would test for the correct voltage at all the chips on the board. 

 

Additionally, bad name specifically indicates the eprom isn't getting mapped in, or the '245 chip isn't enabled in the correct direction when addressed, or the CPLD isn't controlling the eprom selection or upper address lines correctly. The CPLD is solely responsible for decoding the crubit that enables the eprom and the LED. 

 

The CPLD is also static sensitive. I have personally lost a TIPI board to the air-conditioning consequences.

[+arcadeshopper]

On 6/29/2022 at 9:33 AM, Duewester said:

Hello Ti 99ers

First I wanna say that the forums here are of great interest and value, and I didn't realize there were so many 99ers.

I searched through all 83 (as of 6/29/2022) pages of this particular topic and I still have a issue and questions.

My setup:

Ti 99 4a (of course)

FinalGROM99

32K sidecar from Arcade shopper

TIPI (TIPI DSR ROM v.19APR21) CRUEBASE1 Jumper installed as received across bottom two pins, attached to 32K module

99 is connected to HDMI via composite cable and adapter.

Using 99 to power the sidecar and TIPI.

Raspberry Pi 02W with female socket attached only to last ten GPIO on Pi. So, no cable involved. Powered by separate power supply.

  Two different SD cards (32gb SanDisk HCI A1 and SanDisk Edge 16gb HCI A1) that have same image and can be accessed via ssh when not plugged into TIPI. Both cards created using Raspberry Pi Imager tool. Both cards with tipi as user and password on my home network. (Took like seemed forever to get tipi image on any card)

 

Used Extended Basic from FinalGROM99 to verify 32K Sidecar is working.

Plugged TIPI without Pi and used call tipi and CALL TIPI and received message Bad Name.

Added Pi to TIPI and booted the Pi. Waited for activity LED to stop blinking (usually means no activity) so assume Pi is booted.

Turned on 99. Used built in Basic to call tipi and CALL TIPI with same result - Bad Name, used EB via FinalGROM to call tipi and CALL TIPI with same Bad Name result.

 

Other observations:

Neither LED on 32k sidecar nor Tipi ever lights or blinks

5v on top left pin of TIPI (looking at 44 pins with Pi connector on right

Reseated jumper and ROM

 

I read here that Bad Name means no power or fried tipi. Is there something I can test via T2 - T5 to confirm cooked TIPI (I'm not sure how I could have cooked it because the Pi can only be connected one way)

 

I feel that I'm a reasonably competent troubleshooter with more tools than I need so, any suggestions?

 

Thank you to all for taking the time to read my lengthy post and I look forward to additional posts on the subject. 

- always power the memory card from external if you are using a TIPI.. console power supplies are old, and not always enough power to get it to work

- the 32K LED only blinks when you use it If you load an assembly program like DM2K it will stay on

 

- 

[Duewester]

Thank you +jedimatt42, +arcadeshopper, thank you both for the responses.

I have been powering the two boards from the console without the speech synthesizer. I'll look around and see if I have a 5v ps, I've got a bunch, it's just a matter of finding one with the correct plug.

I suspected the T pads weren't used but didn't want to probe them without knowing.

Again, thanks for the feedback.

[Duewester]

?Happy days. Thank you+jedimatt42 and +arcadeshopper.

I found a 5v 2a center positive little ps in a drawer with a dozen or so ps's of various voltages and amps.

Here was my process (if anyone is interested)

1.) Turn on TI 99 4a (Console) and verify Console and Finalgrom99 are working. Power down console.

2.) Set Selector sw on 32k sidecar to internal. Install 32KSC to Console. Power on the console.

3.) Reset FG99 and press spacebar. FG99 Menu appears.

4.) Select A- Dev, Select an EB.

5.) Enter size command and get response about memory (11840 stack, 24480 program). ?

6.) Function QUIT and power down console.

7.) Switch 32KSC to EXT and plug in/Apply power to 32KSC - Red LED lights.

9.) Apply power to console. SC LED goes out and console boots up.

10.) Reset FG99, select DEV and an EB. Size cmd displays same results as previous. ?

11.) Power Down Console and SC.

12.) Plug in Tipi. Plug in Pi 02 W to TiPi and power up the Pi. Wait for green light on Pi to stop blinking.

13.) Apply 5v to 32KSC. Turn on console - Green LED flashes and goes out.

14.) Reset FG99, select FG99, Dev, and an EB.

15.) Size is consistent with prior results.?

16.) MOMENT of TRUTH - call tipi. Blank Screen for a moment and then...

17.) TIPICFG v11 Pi Version: 2.17 and so on. ?

Entered and Wrote SSID and PSK. Now doing the upgrade 2.37 with fingers crossed.

 

OK wow. I expected issues about the upgrade but, everything has completed. Now...

 

Edited July 9, 2022 by Duewester

[Duewester]

On 7/8/2022 at 2:03 PM, dgrissom said:

I've used a similar setup.  (Currently using a SAMs sidecar and TIPI.)

If using a speech synthesizer, make sure that it has the power pass through mod.

In some of the threads there was a discussion that indicated that the console may not have enough power to power the sidecars as you have configured.

I was able to power everything with a TIPI/32 card setup.  Using separate cards, it won't work.  

On my SAMs / TIPI combo, I use a USB splitter cable to for power.

 

Hope this helps.

 

DG

Thank you +dgrissom for the response.

I have a speech synthesizer but I'm not using it -yet. I had applied the jumper modification for 5v but, my solder job was too chunky and my 32k sidecar wouldn't fit. So, I'm working without it.

I have one of the new 32k tipi combo cards coming and I might try the ss as the second card, might even just remove the jumper on the ss. 

Again, thank you for the response and the suggestions, of which I'm going to look into a power splitter for the 32k and the Pi. I'm using the newer Pi 02w and it's a little more power demanding than a plain Pi0 ( the price to pay for more cores). Maybe a USB c ps for one of my Pi4bs'. Ought to be enough current there to power both the 32k and Pi 02w.

Edited July 10, 2022 by Duewester

[+jedimatt42]

So one thing maybe not clear with my 32K board design, cause that thread is hardly ever looked at... is when the jumper/switch is set to internal power, the 5v pin on the expansion port has no power... so a TIPI attached gets no power.  The 32k board was designed with the use case of FlashROM cartridge users that needed memory expansion and as a building block for myself. The sideport +5v is rated at 50ma by Texas Instruments. So when I designed the 32k board, I decided that if an addon ( of which none existed yet ) would be built, then it would require the external power. 

 

So, it isn't that the TIPI won't get enough power when the 32k is in internal power mode. It is that the TIPI is granted no power intentionally. 

[Duewester]

On 7/10/2022 at 5:58 PM, jedimatt42 said:

So one thing maybe not clear with my 32K board design, cause that thread is hardly ever looked at... is when the jumper/switch is set to internal power, the 5v pin on the expansion port has no power... so a TIPI attached gets no power.  The 32k board was designed with the use case of FlashROM cartridge users that needed memory expansion and as a building block for myself. The sideport +5v is rated at 50ma by Texas Instruments. So when I designed the 32k board, I decided that if an addon ( of which none existed yet ) would be built, then it would require the external power. 

 

So, it isn't that the TIPI won't get enough power when the 32k is in internal power mode. It is that the TIPI is granted no power intentionally. 

OOOOHHHH!! NOW things make sense. I never thought to look at the 32k thread because I wasn't having any 32k issues.

Thank you +jedimatt42.

Off topic: Any special notes about the 32k/tipi combo board? I have one on order and in the "Processing" stage.

[+jedimatt42]

11 hours ago, Duewester said:

OOOOHHHH!! NOW things make sense. I never thought to look at the 32k thread because I wasn't having any 32k issues.

Thank you +jedimatt42.

Off topic: Any special notes about the 32k/tipi combo board? I have one on order and in the "Processing" stage.

J-Data has provided specifics for the combo here: https://github.com/jgparker/tipi/wiki

[+jedimatt42]

Update 2.38 - 2022-07-22

 

- Improvements to DSK mapping in TIPI web-ui.

  - Mapping lists folder as link to jump right there.

  - Mapping list includes X button to delete the mapping. 

 

- Sector read/write support

  - This is used along with the updated EPROM code for 0x10 sector read/write support.

  - Uploading a DSK file will preserve the sector dump as a '.sectors' file inside the generated directory.

  - .sectors file shows up in web-ui with a floppy icon.

  - a transient sector image is created if sector access is used on mapped folder that has no .sectors file.

  - this should provide catalog compatibility with some of those old programs that do that (TI-Artist/FunnelWeb)

  - Works with PLATO disks

  - Works with PCODE disks

  - more to try...

 

Updated ROM - https://jedimatt42.com/downloads/tipi-dsr-2022-07-18.zip

( TIPI PI side software degrades gracefully in the absence of this ROM update )

 

- Adds sector read/write basic subroutine 0x10 for used with mapped DSK1-4. 

 

If you have uploaded a plato or pcode disk, you will need to re-upload it for the sector dump to be preserved.

 

PLATO disks are consumed in a hybrid sector and record read mode. So you'll get something like this when you upload the DSK:

 

 

PCODE disks have a single TI file in them but are accessed purely through sector io. You'll get something like this when you upload the DSK:

 

 

The '/sectors' files do not show up in a catalog on the 4A. 

 

For best results:

 

Operate the TIPI at crubase >1100 for PLATO software.

Operate the TIPI at crubase >1000 along with a floppy controller for PCODE, where all PCODE disks are provided through the TIPI. 

 

All 3rd party TI software is what you would call homebrew today. It was not likely written with the vision of hardware extensibility that TI enabled. If you have trouble with something that requires sector access to operate and your TIPI is not at crubase >1100, then change your TIPI to crubase >1100 and try again. ( If you have a real floppy controller, that means removing it )

 

I haven't written anything of this up on the TIPI wiki yet... That'll come tomorrow. 

 

[+Vorticon]

Awesome work Matt! For pcode compatibility, the TIPI should be ar 1000 and the disk controller at 1100, correct?