CS1er / TAPE994a help

[TMA-1]

 

How do you have this wired up? After you encode to .wav with any program, are you able to re-decode? At which point does it bomb out? Can you hear the faint sound of the data being played back through the TI regular audio port?

 

My hardware configuration works well for other programs. My objective is to get programs onto cassette tape, (drastically retro, I know), so what I have set up is my PC sound output goes to a physically handy stereo system with cassette deck, where I record the .wav on tape. The tape then goes to a "shoebox" cassette machine and my hard TI-99/4A. Again, this works quite well for the other 99% of programs I've tried it with, and yes I hear the tape loading noise from the TV speaker. I actually find the clean signal from Tape994a to my cassette deck produces a better more reliable image than the TI computer itself can output to the portable machine.

 

The 3 problem subject programs, once converted to a .wav file by either CS1er or Tape994a, results in a corrupt .wav. I say this because the .wav (1) will not load into the iron, and (2) when decoded again by either utility results in a FIAD file that does not load into Classic99. Something about the original TI source code has gone goofy. The code was cut and pasted into Classic99 from a text listing file, and then SAVEd by Classic99. The FIAD loads back in fine. It just won't convert to .wav for some reason.

 

Tried your Linux utility (from the website this time) ckoba, but I still can't get those .wav's to load, for any program. Seems to be a separate issue, but one that's equally baffling to me.

[+mizapf]

Already tried MESS?

[ckoba]

 

Tried your Linux utility (from the website this time) ckoba, but I still can't get those .wav's to load, for any program. Seems to be a separate issue, but one that's equally baffling to me.

 

Hmmm. The output from the script is rail-to-rail on volume; I hadn't considered the possibility of sending it to tape instead of directly to console, so the tape recorder's microphone AGC circuit is probably kicking in and making a mess of things.

 

I'll look at adding an option to specify the volume (as a percentage). In the meantime, if you're still interested, you could call up the mixer utility for your soundcard and reduce the output to, say, 60%. My TI is rock-solid at 67%. I should probably mention that tidbit in the readme.

[TMA-1]

 

... so the tape recorder's microphone AGC circuit is probably kicking in and making a mess of things.

 

 

There's no microphone input or AGC in play actually. My sound card speaker output goes to the "Tape 2" RCA inputs of my stereo amp,... dub Tape 2 to Tape 1 (cassette), where I have right/left input volume controls. I set them to "0" on the VU meters, where they remain rock steady because you're outputting a single perfect tone. I'll experiment more with some different volumes, but I've looked at the output from the playback machine on an oscilloscope, and it couldn't look any better.

 

On the other hand I just tonight scored an original TI-99 tape recorder complete with interface cable for $10. So I'll try that too. Who knows?

Edited December 31, 2015 by TMA-1

[ckoba]

 

There's no microphone input or AGC in play actually. My sound card speaker output goes to the "Tape 2" RCA inputs of my stereo amp,... dub Tape 2 to Tape 1 (cassette), where I have right/left input volume controls. I set them to "0" on the VU meters, where they remain rock steady because you're outputting a single perfect tone. I'll experiment more with some different volumes, but I've looked at the output from the playback machine on an oscilloscope, and it couldn't look any better.

 

Oh, you have *real* hardware. That makes this easier.

 

The next thing that comes to mind is the program is being constructed at the wrong frequency. I alluded to this in an earlier post; when I swapped the crystal to overclock my TI from 3MHz to 3.58MHz, .wavs recorded at 1378/689 weren't being detected at all. I don't remember the precise sequence of events, but I might never have tested 1400/700 when I implemented 1600/800 for 3.58MHz.

 

You might try reducing bit_1 to 1380, bit_0 to 690, and numSamples to 30 in the global variable definitions. That should bring you a couple of hertz within nominal for 3MHz.

[TMA-1]

 

You might try reducing bit_1 to 1380, bit_0 to 690, and numSamples to 30 in the global variable definitions. That should bring you a couple of hertz within nominal for 3MHz.

 

Tried it. No joy. Depending on playback volume I still get "no data", or "error detected in data".

 

Other things I've tried just to eliminate possibilities:

• different playback recorder
• different interface cable
• different TI-99/4A console (even though all of these work fine in other transfers)
• direct connection from a Windows PC playing the .wav into the interface cable

The last one was a long shot. The PC in the "retro room" has a quiet sound card and I think the output volume is too low for the TI. (It is not the computer I'm using to create the tape images.)

[ckoba]

 

Tried it. No joy. Depending on playback volume I still get "no data", or "error detected in data".

 

 

Huh. I'm out of ideas, other than a) *really* finicky volume or b) the DC level is shifted between the output and the TI.

 

It's not the frequency, it's not the waveform, and if it's getting "error detected in data" then it's seeing *something*. And I *swear* that it works for me -- Linux on the playback unit in my case.

 

If you've got a compile box (Linux, FreeBSD, whatever) could you please compile "decode.cpp" from ti99sim and see if it decodes correctly? Try the one at http://www.mrousseau.org/programs/ti99sim/archives/ti99sim-0.12.1.src.tar.gz... that's the one I used for my regression testing.

 

cd into src/util and execute "g++ -Dnullptr=NULL -I../../include -o decode decode.cpp ../core/option.cpp"

 

... or use the Linux executable attached to this post, which was built the same way.

 

Here's what I got when I converted CANYON (in TIFILES format):

$ ti_bin_to_wav -i CANYON -o CANYON.wav -t

$ decode-linux CANYON.wav

TI-99/4A Cassette Utility

File "CANYON.wav"
Format: 16-bit Stereo 44,100Hz

Reading file ......................

Searching for data tracks...

          Start time  End time    Approx size
Track  1: 00:00.000 - 01:02.869    4288 bytes (43)

Reading track  1: ....................................................................

$ md5sum track-01.dat
16a5879feaa6e062b428e8e43bb349bf  track-01.dat

$ dd if=CANYON skip=128 bs=1 2>/dev/null | md5sum
16a5879feaa6e062b428e8e43bb349bf  -

So, um, in summary ... you've got a very weird problem there.

Edited December 31, 2015 by ckoba

[ckoba]

Not wanting to watch the idiotic Japanese year-end television program with the rest of the family, I went ahead and tested a few of my .wav files.

 

Apart from a few dumb mistakes I made that I'll get into in a minute, my setup works fine. It's a BeagleBoneBlack running ArchLinux, with a Creative Labs USB sound card with the volume knob set to 8.

 

This is interfaced to the TI via a homebrew cable setup (because I sort of tore my work room apart as I was tracking down company assets when I left United Fruit, so my "real" cable is Somewhere). The headphone jack on the Creative Labs is wired into the correct pins for CS1 (signal on tip, ground on sleeve).

 

The microphone jack is also wired in, because I discovered that leaving it disconnected kept the TI from detecting *any* signal. Tip is connected to pin 8, ring and sleeve are disconnected (although I should ground the sleeve at some point).

 

To save space, the .wav files were gzipped at -9. Playback was "gzip -d -c ${FILENAME}.wav.gz | aplay", with no sound munging (stereo, 16-bit signed, 48000kHz, in other words the native output of the script).

 

No problems whatsoever, once I figured out that pin 9 is not and should not be connected to ground. This was admittedly at 3.58MHz, so 1600/800 for 1/0, but there were no issues with garbled or misdetected data once I sorted out the microphone connection foulup.

 

I doubt that you have a similar cause, as you say that you have other programs that work. I'm just saying that I can't reproduce your problem here with .wavs produced with my script.

 

(and you're right, that signal looks very nice on a 'scope compared to the stock TI output )

[+Schmitzi]

Use the Audio-Out/Line-Out, NOT the Headphone-Out (!)

 

and volume something from 80% up to 100% then

[ckoba]

Use the Audio-Out/Line-Out, NOT the Headphone-Out (!)

 

and volume something from 80% up to 100% then

 

Although I'd already said that "it is working with *this* setup", I've went ahead and tried the line-out jacks just to humor you.

 

As I thought, it worked just fine with no volume changes whatsoever (because, as I've said before, the waveform is rail-to-rail on volume).

 

It's important to note that the official TI documentation says "insert the plug with the white wire into the earphone (or external speaker) jack". "Earphone" means "headphone". TI expected this setup to work with all sorts of crappy transistor amps built into cassette consoles ... I wonder where your "use audio-out!" mantra came from.

 

I tend to believe that knee-jerk statements that "you're doing it wrong!" when I'm clearly *not* doing it wrong, is rather rude and out-of-character for this forum.

 

No offense intended, and have a happy New Year.

[TMA-1]

Traveling for New Year's so it will be a couple of days before I can try this or anything else. Thank-you ckoba for all your time and help. Happy New Year to all.

[+Schmitzi]

 

Although I'd already said that "it is working with *this* setup", I've went ahead and tried the line-out jacks just to humor you.

 

As I thought, it worked just fine with no volume changes whatsoever (because, as I've said before, the waveform is rail-to-rail on volume).

 

It's important to note that the official TI documentation says "insert the plug with the white wire into the earphone (or external speaker) jack". "Earphone" means "headphone". TI expected this setup to work with all sorts of crappy transistor amps built into cassette consoles ... I wonder where your "use audio-out!" mantra came from.

 

I tend to believe that knee-jerk statements that "you're doing it wrong!" when I'm clearly *not* doing it wrong, is rather rude and out-of-character for this forum.

 

No offense intended, and have a happy New Year.

 

 

Yes, of course, if you connect it to the vintage TI´s CassettePlayers´ EarPhone, this is correct.

 

But if you use a soundcard (as described), a MP3-Player, or any device from today, they are often digitally "regulated" on the

EarPhone-connector, to prevent from exploding your ears. Especially on french products (harder health-laws), but on many other devices too.

(Best example here are products from "Thomson")

 

And so, if you need a maximum loudness, this "filter" brings problems. I have experienced and tested this more than once,

i.e. that 85% volume sometimes on some MP3-Players or Notebooks is louder than 95% (on some data-sounds), and volume is "flickering"

 

And, using the Line-Out/Audio-Out then (which is not "filtered), was the mitigation to that.

With using this connector on new devices, then it worked.

TI´s statement here is just a bit old, pre-MP3-players, pre-noise-filtering and pre-ergonomic thoughts

 

 

a Happy New Year to all

xXx

[ckoba]

In summary, my position is: which sound-out port you use depends on the device. In general, line-out should be used when you have an external amplifier, because the output levels are low (typically about 1.6 volts peak-to-peak) and the impedance is higher (on the order of 100 Ohms), otherwise use headphones-out because the output levels are higher and the impedance is so low that it will drive nearly anything.

 

Too-long, didn't read, English is hard: If you don't have a metered amplifier to run the output signal through, use headphone-out and use the volume control.

 

TMA-1 is using an old (probably analog) stereo amplifier. Those had the capability to alter the output waveform (equalizing, or "tone", we called it back then). That would change the amplification of various frequency bands. He's already said that he's not using them, and the waveform looks good on the oscilloscope.

 

I am using a higher-end USB sound converter, with a decent DAC and on-board amplifier. The waveform looks good on my oscilloscope through the headphone jack at maximum volume, and looks exactly the same (except quieter, at 0.8 volts) through line outputs.

 

Now for the caveats:

 

* If you turn the volume up on the headphone jack, you might clip the signal. That's bad. I think that's what you're calling "flickering". Need to make sure that the signal is not too strong for the receiving end. That's trial-and-error.

 

* If you are using an OS or a playback tool that "optimizes" the sound through the headphone jack (which, in this case, means equalization), it must be disabled. Yes, the simplest way of doing so is to use line-out, which Windows doesn't touch IIRC, but the signal still needs amplification and there's an impedance mismatch to overcome.

 

* If your sound converter (USB or otherwise) has a crappy DAC or pre-amp, it doesn't matter which port you use, you're still going to have problems. If the DAC is only approximating the desired waveform, if the onboard pre-amp is marginal, or if there's a bandpass filter on the sound path, you will have poor results.

 

* iDevices, in particular, are borderline unsuitable for listening to music, let alone reproducing a TI signal. The DAC was chosen for size, not for quality, and the manufacturer expects the (nice-looking but marginal quality) bundled headphones to be used. If you have an iDevice, obtain a decent pair of headphones (I like Audio-Technica) and compare how your favorite bit of music sounds between the two headphones.

 

* (edit) Same goes for on-motherboard "sound cards". The inside of a PC is much noisier, electrically speaking, than was a GE tape deck from the early 80's. There's going to be all sorts of interference in the sound circuit, and as above, DAC/amp are chosen for footprint and cost, not quality.

 

For further reading, I recommend starting at https://fr.wikipedia.org/wiki/Niveau_ligne and wikipedia-jumping around from there.

 

(I'm an engineer that's familiar with analog audio (and especially as implemented in portable iDevices), and I suspect that TMA-1 is similar. The references to 'scopes and "clean waveforms" should have been an Atlas-sized clue, but I guess you missed it)

 

End rant, and end discussion (from my side) on the subject. We'll get TMA-1's files working when he gets back

Edited January 1, 2016 by ckoba

[TMA-1]

I'm back. Not even hung over either. Made some progress on this front too.

First ckoba, to your excellent instructions on how to recompile decode.cpp, I'm afraid that although I do have a Linux box "for learning", I've not progressed to the point where I do development on it. The "g++" (or "c++" if that was a typo) simply earned a "command not found" on my system. No matter.

It's tape.

To minimize variables, I coded up a "Hello, World!" program and have been working with that for brevity. I could not get even that to transfer from tape.

In desperation I ran a rather long headphone extension cord from the stereo in my computer room to the electronics bench where the TI-99/4A is set up. I used the headphone interface, because it was convenient. This works. I can load HELLO, and some other programs, quite well.

It's the tape intermediary that causes the problem.

Looking at the output directly from my playback recorder to my oscilloscope, there is a small amount of DC drifting up and down between cycles. Since the TI seems to operate on a frequency shift basis, I didn't expect this to matter much, but evidently it does. (I guess I should have known better since the machine is touchy about volume in the first place.)

Alas, my 3 problematic programs are still problematic. Although they now load with "Data Ok", once I hit <Enter> they report "I/O Error 50".

That makes 3 different program-to-wave facilities that all produce similarly infertile files, although Classic99 loads the original program just fine. I'll have to work on that separately.

Thanks again ckoba, and others, for all your hard work and posts. Your utility is cool. I just tried to push it too far.

[Opry99er]

I/O error 50, eh?

 

Is the code asking for a diskette record to be opened?

[+Ksarul]

If you did get a DATA OK, what happened when you typed LIST before running the program (or even after the later I/O error)?

[+Ksarul]

Another thought is that these programs contained some imbedded Assembly that isn't getting transferred (or which is really mucking up the conversion process when it tries to make the transfer). That would explain why all three transfer methods choke on just these three programs. . .

[TMA-1]

I should have been clearer. I do not get to the point of RUN. The I/O Error 50 occurs when I hit <Enter> at the prompt to stop the tape recorder. Thereafter there is only the ever popular "Warning, no program present".

 

There is no assembly code either. Extended Basic text file listings have been cut & pasted into Classic99 to re-create 4 programs that a friend of mine is selling on eBay. All 4 programs, can be RUN, and can be SAVEd to virtual disk and OLDed back without incident. But we want to have clean .wav files of the programs also, so that we can create reliable tapes for the actual hardware TI-99/4A. 1 of the 4 programs converts successfully; the other 3 do not. Weird huh?

[Fredrik Öhrström]

If the programs is large enough that it requires memory expansion, then perhaps it might not be possible to load from cassette?

 

There was a discussion somewhere here on Atariage about the disk file format used for large basic programs, which is not "Program file" but instead INT/FIXED/255 or something like that.

I cannot find the Atariage discussion right now, can someone else help?

 

//Fredrik

[ckoba]

If the programs is large enough that it requires memory expansion, then perhaps it might not be possible to load from cassette?

 

True. Maximum tape size is 16k, as the tape header block counter is a single byte (so maximum 255 64-byte blocks).

Edited January 5, 2016 by ckoba

[+Lee Stewart]

If the programs is large enough that it requires memory expansion, then perhaps it might not be possible to load from cassette?

 

There was a discussion somewhere here on Atariage about the disk file format used for large basic programs, which is not "Program file" but instead INT/FIXED/255 or something like that.

I cannot find the Atariage discussion right now, can someone else help?

 

//Fredrik

 

It is Internal/Variable/254 format. Here is one discussion: IV254

 

...lee

[TMA-1]

Okay, I think I see what's going on here. (Famous last words?)

First of all, thank-you Fredrik for your kind offer of assistance, and for getting to the root of the problem. Thanks Lee for the pointer to a very revealing thread, and thank-you Dean (author of CS1er) for much needed input offline.

The programs are too darn big. But, they did come originally from tape and from an un-expanded hardware TI-99/4A. Honest they did.

It appears, (and someone correct me if I'm wrong because I'm learning as I go here), that beyond some certain size, a program gets stored in something called "int/var 254" format, rather than the normal default "program" format. This can happen even in an un-expanded TI99.

Classic99 supports this format transparently on the way in and on the way out. Ti99Dir supports it also, and can be used to readily identify a program so afflicted.

Tape994a, CS1er, Fredrik's website engine, and ckoba's bin_to_wav do not currently support IV254.

Finally the history of the Glenn Wright's 4 game programs (which are excellent by the way) begins to make sense to me,...

TI BlackJack is small enough to go under the wire, and converted from tape with Tape994a just fine. Never given me a lick of trouble.

In-Between and DoubleUp-JokerPoker, rattled their way through Tape994a to become FIAD files, but would not then load into Classic99. Tape994a had incorrectly processed them as "program" files. But, when I viewed the damaged files with T99Dir, it managed to show me the source code, intact. So, thought I, I'll just cut and paste the source code into Classic99 and let Classic99 save them for me. This worked, but produced IV254 files that again (or still) will not survive another trip thru any of the file converters.

TI Star Trek is a special case. This very cool implementation of the classic game has been enhanced by me with Glenn's blessing. It was very close to the size limit of an un-expanded TI-99/4A originally. I have increased the size of the source code by making additions, but drastically reduced the space required for variables. I do not currently know if it can fly a hardware TI99. It too is in IV254 format, so it would appear I'm stuck for the moment for a way to get it in there.

Edited January 6, 2016 by TMA-1

[Omega-TI]

... so it would appear I'm stuck for the moment for a way to get it in there.

 

 

<< Here >> is one possible solution for less than $20.00 $15.00... if you already have a soldering iron.

Edited January 6, 2016 by --- Ω ---

[TMA-1]

 

 

<< Here >> is one possible solution for less than $20.00 $15.00... if you already have a soldering iron.

 

Aye, I'm the kind of guy who's been known to take a butane powered soldering iron when he goes tent camping. That's a cool looking mod. But it doesn't address my problem because (1) I want the programs to work in an unmodified TI-99/4A, and (2) it doesn't address the format problem of getting them in there in the first place. I think my options are to write my own utility for IV254 files, or type the programs into the iron by hand. And I'm NOT doing the latter, lol.

[RXB]

 

Aye, I'm the kind of guy who's been known to take a butane powered soldering iron when he goes tent camping. That's a cool looking mod. But it doesn't address my problem because (1) I want the programs to work in an unmodified TI-99/4A, and (2) it doesn't address the format problem of getting them in there in the first place. I think my options are to write my own utility for IV254 files, or type the programs into the iron by hand. And I'm NOT doing the latter, lol.

RXB has a feature to convert XB programs to IV254 Format.

 

OLD DSK1.XBPROGRAM

SAVE DSK1.XBPROGRAM,IV254

 

Toward the end of video I show how it works