Vorticon

How does one access Google Drive with the TI and TIPI? That would work just as well.

I was indeed thinking of the tipi doing all the work, but unfortunately I don't have a good understanding of the underlying work involved in such a task. It would have been so awesome though because then the documents created with STEVI could be backed to the Github with no fear of local hardware crashes and loss of data...

Very cool. Would it be possible to save a file back to the Github?

It is. My traditional method before TIPI was to use the HDX system, which was agonizingly slow. With TIPI, HDX is now essentially obsolete as I can't think of a single case use for it. I'm in the process of transferring all my own programs to the TIPI, and once that's done even the physical disk drives will be hardly used (except for when I am playing with the p-code card). Are we changing the character of the TI with all these modern extensions? I don't believe so. All we are doing is enhancing storage and access solutions, but the soul of the machine remains untouched. It's still quirky as hell

Sure. FOPSTEST

Here you go: 10 PRINT "NUMERIC DATA TEST":PAUSE 20 PRINT "WRITING DATA":PAUSE 2 30 OPEN #1,"100.NUMTEST",OUTPUT,INTERNAL 35 FOR I=1 TO 10:PRINT #1,I:NEXT I:CLOSE #1 40 PRINT "READING DATA":PAUSE 2 50 OPEN #1,"100.NUMTEST",INPUT,INTERNAL 60 FOR I=1 TO 10:INPUT #1,N 70 IF N<>I THEN PRINT "READ ERROR!":PAUSE:CLOSE #1:STOP 80 NEXT I:CLOSE #1 90 PRINT "PASSED NUMERIC TEST!":PAUSE 2 100 PRINT "STRING DATA TEST":PAUSE 110 PRINT "WRITING DATA":PAUSE 2 120 OPEN #1,"100.STRTEST",OUTPUT 130 FOR V=65 TO 75:PRINT #1,CHR$(V):NEXT V:CLOSE #1 140 PRINT "READING DATA":PAUSE 2 150 OPEN #1,"100.STRTEST",INPUT 160 FOR I=1 TO 10:INPUT #1,S$ 170 IF S$<>CHR$(64+I) THEN PRINT "READ ERROR!":PAUSE:CLOSE #1:STOP 180 NEXT I:CLOSE #1 190 PRINT "PASSED STRING TEST!":PAUSE 2 200 PRINT "FILE OPS SUCCESS!":PAUSE

Is it possible to sprain a finger pressing the space bar?

I went ahead and rebooted the TIPI and lo and behold it now worked. Go figure... I wonder if I should just power down my TIPI when not in active use..

Tough game! Very nicely done. I like it a lot 👍👍 I would have liked to see my remaining air level though as this would determine how impulsive I want to get Program name is ALFIE1 by the way.

So I can get file ops to work with numerical values using the INTERNAL file mode and the VARIABLE x option, with x being the maximum length of the numerical values expected, including the decimal point (if dealing with floats). For example, if I write a file with numbers for 1 to 10, then to read them I have to specify OPEN #1, "100.TEST",INPUT,INTERNAL,VARIABLE 2 Any value greater than 2 for this data set will yield a data error when read via INPUT #. Same goes with string data, except here we will omit the INTERNAL specification. Obviously not an ideal solution if you have unpredictable data element lengths, but should work in most common situations otherwise.

OK thanks for the update. I might be able to get it to work for numerical values using INTERNAL and a record length of 1. Let me play with this a bit more and see... As for DISPLAY type, there is also a workaround if the data is formatted with pre-defined separators and read back as a single string which can subsequently be sliced into individual values by the program with the understanding that the file could not exceed 255 characters. Ugly, but feasible...

Yup I know that part, but I noted that TIPI does not automatically create a new folder when you drop a disk image inside a sub-directory. For example, say I have a sub-directory call MYPROG. If I navigate to MYPROG and drop a disk image call TEST.DSK, TIPI will not automatically create a folder called TEST inside the MYPROG directory. This only seems to work when the disk image is dropped in the main TIPI directory, unless I am doing something wrong.

Dropping a disk image into a subdirectory does not create a new subdirectory. I assume this is not an implemented feature, correct?

A little more info on this. It appears that the PRINT # statement is writing the data as one string which can be read as such by the INPUT # statement. Using the code example above, the file will contain a string consisting of "1 2 3 4 5 6 7 8 9 10" instead of 10 records each with a single integer. Obviously not the proper behavior of the PRINT # statement. And if we use INTERNAL records instead of the default DISPLAY, we get a similar string with gibberish inside it.

Only one word comes to mind: damn...

I left that one for last in Adamed as well. It's just not a very exciting or interesting task 😄

How does one set the backspace key in telnet on the tipi in 80 columns? I tried using stty erase fctn-s but it does not register, nor do any other key combinations...

The FC/XB file shows the correct path for the XB program I am trying to load The log files have entries only till 7/19/20 even though I have been actively using the tipi daily and I don't see any errors logged.

There seems to be an issue with file ops from within a Basic program. The OPEN command works fine, and so does the PRINT # command. However, when trying to read back the contents of a file with the INPUT # command, I get a bad data error. Try this out: 10 OPEN #1, "100.TEST", OUTPUT 20 FOR I=1 TO 10:PRINT #1, I:NEXT I 30 CLOSE #1 40 OPEN #1, "100.TEST", INPUT 50 FOR I=1 TO 10:INPUT #1, A:PRINT A:PAUSE:NEXT I 60 CLOSE #1 I checked the contents of TEST using TI99Dir and they are correct. It appears that the INPUT # statement is chocking on the first data element. Any thoughts?

I've noted an issue with FCMDXB. When starting up an XB program from FC, it runs fine. However, if I return to FC via the FCMDXB program and then try to run any XB program, XB gets loaded and I get a SYNTAX ERROR and there is no program present. I am using RXB 2015 as my main XB. Not sure if this is related to RXB or FC. Could someone using another XB please try this out an report back?

I probed the SD shield with a logic probe and the Card Detect is functioning as it should, being HIGH when there is no card present and LOW when one is inserted. On the other hand, the Write Protect pin is stuck at HIGH regardless of the position of the write protect tab on the SD card which explains my initial issues. So I guess my SD shield is defective although still perfectly usable as long as I ground pin 9. No biggy...

FC has ftp capabilities. Just type ftp ftp.whtech.com/tipi and off you go

So some good news: while switching from a micro-SD card to a standard one did not make a difference, grounding pins 8 and 9 solved the problem and I am now able to load, save and read a directory. Awesome! What exactly happened here and how do we proceed?

I actually changed all the regulators on my cards to higher current load versions. Fairly easy to do.

Sure, happy to. I don't think the SD card is the issue because it works fine when I use the Reid files instead. This would also rule out a wire issue, wouldn't it?