CASSETTE POWER

[+arcadeshopper]

17 minutes ago, --- Ω --- said:

I agree even if its just a small routine that sends it over WiFi to the PC, similar to the way the HDX version works.  TIPI.PIO?

the HDX version has a DSR with that capability programmed in, it forwards a serial stream to the TIPRINT server that runs on the same PC as the HDX server, it does all that in the background 

none of that exists for the TIPI.. there's no tiprint server on the pi, there's no protocol and there's no DSR programming

 

also tiprint is not Epson compatible..  it's whatever printers Fred had in the dot matrix days   

[Omega-TI]

Oh well.  If it happens it happens, if not, it'll suck, but I'll live.

[+Vorticon]

I will have to try that once I get my hands of a TIPI-PEB (hint-hint... ?)

[wierd_w]

I recently obtained a Ti 99/A4 (silver) off ebay.  I have fond memories of basic programming, but not on a Ti.

 

I had never used a cassette data system (was a 5150 user, and had diskettes)

 

I am happy to report that the ONN brand (Walmart store brand) shoebox recorder works fine, but it lacks a minute counter.

 

I will have to hold off on getting a tipi or similar device, but for now tape is fine.  I picked up extended basic, a 32k sidecar, and a mini memory off ebay. I can put the tape indexer in the mini memory, and live that way for a while. It's a shame that the Ti cannot rewind or fast forward the tape programmatically.  It would have made cassettes a lot more practical, and allowed better use of cassette files. (But then I couldn't use a Walmart elcheapo cassette recorder. )

 

any other cassette management software out there?

Edited September 13, 2019 by wierd_w

[wierd_w]

OK, I played with the index program a bit.

 

His documentation is really terrible.  Here's a somewhat better description of what the program does, and how to use it.

 

 

This program creates a small basic "cassette file" at the start of the tape that contains the index. It stores 10 file identifiers that are 12 characters long, along with 3 comments.

 

The program assumes you are using a C60 cassette. 

 

It uses a "timed fastforward advance" technique to divide the tape up into 10 hard-set indexes, each ~6 minutes in length.  This is for people without tape counters. (The computer takes the index value you give, multiplies it by an internally set number, then waits that many seconds while fastforwarding the tape before halting the tape motor, and prompting you to press stop. This assures that the tape always stops at the same timestamp index, even without a tape counter.)

 

 

This means setting up the tape has a few loops you need to jump through when getting started.

 

1) Get the tape indexer into your Ti.  The .wav file method works fine for me.

2) connect the cassette recorder

3) run the program

4) When it asks if you are seeking to an index, say no

5) When it asks if the tape has an index, say no.

6) Save the dummy index it generates by following the instructions the program gives.

7) quit the program. (option 5)

8 ) rewind the tape, then press play. (We are listening for the data of the index record. We want it to finish playing, then give about 2 seconds of dead space, then stop the tape.)

9) Perform a SAVE CS1, but DO NOT rewind the tape when it prompts to!

     9A) If you want to check the written data, you will have to rewind the tape then press play and listen for the index data then stop the tape. DO NOT REWIND when prompted, but otherwise follow the prompts.

 

There is a reason for why I do step 9 this way.--

 

When you OLD CS1, it will attempt to load the tape index record data. The TI will give an error (because it is not a program), but will pause the tape immediately after that data (which is very short), and prompt you to stop the tape. You can then OLD CS1 *AGAIN* and quickly get the tape indexer.   We can get away with this, because the tape indexer is rather small, *AND* the indexer actually skips enough of the start of the tape to not overwrite this location when it parks you at index position 1! This gives you either a failsafe copy of the indexer if your MMM battery dies, or if you don't have an MMM, lets you quickly load the indexer reliably while retaining the index tag.

 

 

 

Once the tape has an index, and has the index program stored, you can start adding your desired programs to the tape:

 

1) Load the indexer with OLD CS1 (If you set it up the way I suggested above, the first attempt will fail but that is expected. DO NOT REWIND. Just do another OLD CS1. The program will load on the second attempt.)

2) Run the program.

3) When it asks if you are seeking to an index, say yes.

4) Pick the fixed tape index you want to seek to by entering that number and pressing enter. (1 through 10).

5) Follow the instructions.

6) When it has parked the tape at the desired index, disconnect the cassette player then load the program you want to save (again, I use the .wav file method).

7) Reconnect the cassette player, and do a SAVE CS1.  When it asks if you want to check the data, you have to say no. (there is no good way, without a tape counter anyway, to rewind the tape accurately to do the check.)

 

You will have to repeat that laborious process for each program you want to put on the tape, using the indexer to seek to that position, loading the program you want to save, then saving it to the un-rewound tape.

 

 

Once the tape is set up, AND loaded up with programs, You just need to use the indexer to seek the tape for you, quit the program, then OLD CS1 the queued up program.

 

 

[wierd_w]

I seem to be monopolizing this thread.   Surely I am not the only one interested in better tape handling?

 

All the same; I think I want to re-write this indexer. It has several noteworthy things about it which I find problematic. (and/or, that I think would be very useful to add.)

 

1) Placement of the index data on the cassette.  Putting it right at the start of the cassette is squicky. It makes the user have to either seek past it reliably (not so easy without a tape counter), or do an "Error 50" tape read before getting to the tape indexer.  Better is to have the indexer FIRST, reliably know where to seek to the index in the indexer, and then read the index. That way you load the indexer like a normal cassette, it prompts to rewind, then to fastforward, then to play-- It can then get the index every time, the index program never gets overwritten (It's effectively a "zero'th index"), and things are happier overall.

 

2) It uses fixed indexes.  Not all programs are the same length, and this is wasteful of tape. We are loading a data structure from the tape; why not store how long the program is expected to be? (We know how large the loaded program is after all... We can make this determination.) We can then get reliable results with less wasted tape.

 

3) The program is effectively counting seconds while fastforwarding, AND knows the effective times to fastforward to reach an index.  We can give a useful indicator of progress. Why not give one?

 

4) Why not store what length of cassette this is in the index? We can use this to better judge how many indexes are sensible to make available.

 

5) Why only 10 indexes? As long as there is sufficient data to correctly seek, we could have an arbitrary number of indexes.

 

6) With some work, we could compile this as an assembler routine to get the cassette to be handled more like a (very slow, with user interaction) disk device as a callable handler. (The index data structure would be equivalent to the root directory entry on a diskette, containing lengths and FF-time-locations on the cassette for arbitrarily named files.) Initially loading the tape with OLD CS1 would load the TI BASIC loader, place the binary handler into a suitable section of RAM, call INIT to register the handler, then prompt to read the cassette's index.  After that the user could one-shot off the command line, with something like OLD CS1.MyProgram.  The TI would KNOW where to seek to on the cassette to load that file (Since it is in the index that was loaded, and stored by the handler routine when it was registered), would prompt the user to do the necessary steps to rewind, then fastforward, then play, appropriately-- and the program would get loaded correctly.  We would need to add another handler to update the memory-resident index when the user changes the cassette though. ) Such a handler would allow diskette based games to be adequately (If VERY SLOW to operate on data reads) run from a cassette without modification. 

 

 

[Omega-TI]

On 9/5/2019 at 6:03 AM, sparkdrummer said:

Here is CASSETTE TAPE LABELER put out by Asgard back in the day. Makes a decent J-card for cassettes.

SSSD.dsk 90 kB · 18 downloads CASS_POWER.pdf 18.97 kB · 23 downloads

 

On 9/5/2019 at 4:06 PM, Omega-TI said:

Looks pretty good, but sadly I still have no way to print from the TI. ?

Maybe someday, there will be a "print to PDF" option for the TI so those of us without legacy printers can still use the printing options in many of the old programs.

I love seeing these old threads, especially when I look back and see how some dreams have come true!  I'm going to "re-visit" this program now...

[Omega-TI]

It didn't come out like I expected the first time.  I thought the size might be off a tad, but I never expected the formatting to be off.  I wondered if a .LF or .CR or both would have any effect.

 

Attempt #1:   (PI.PIO)

print_2020_10_14_T22_31_14.pdf (Nope!)

 

Attempt #2:    (PI.PIO.LF)

print_2020_10_14_T22_39_14.pdf (close but no cigar)

 

Attempt #3:     (PI.PIO.LF.CR)

print_2020_10_14_T22_43_50.pdf  (The third time was almost charm!)

 

It prints out a tad too large, but if you reduce it 90% it crops the image.  I'm hoping someone here has a non-convoluted solution.

 

 

 

[GDMike]

Are most of the listed tape source, (text or basic,xb), files somewhere? Not the.wav files, but mainly dsk versions that someone may have put together and grouped together tapes code.

I was going to start a project of gathering all those that I could find and accumulate into whtech.