ckoba

It's PHA2000 -- the official TI two-cassette cable. I don't have any pictures right now, and I'm too tired to go upstairs and take any. Take my word for it -- it's the stock TI cable, TI logo on the connector and everything. I have two working consoles, both exhibit the same behavior, and maybe this is why everyone treats cassette operations as if they were black magic. The problem isn't the cable per se, I guess, it's what the console is doing on pin 9. The console may be expecting the cassette <-> console ground connection to be through the microphone line, and/or the mono plugs on the recommended tape deck could have had its two connections to tip and ring rather than tip and sleeve (so pin 9 would be grounded at the deck rather than getting an audio signal). This can be fixed console-side by cutting the trace from pin 9 on that DB9 connector and soldering a wire between pin 3 and pin 9. That way you could continue to use the TI cable, I guess, but then you'd have to deal with the tip/sleeve-versus-tip/ring/sleeve issue. Do you have any pertinent comments regarding my analysis of the circuitry surrounding pin 9?

So I've been trying to unravel TMA-1's signal-not-found issues (as detailed in another thread), and I found something interesting. TL;DR: the OEM TI cassette cable tape-audio-1-input jack is wired incorrectly for equipment available now. Leave pin 9 floating and run pin 3 to CS1 plug sleeve and things magically work. Under most circumstances, when wired straight into either the headphone or line-in jack, the signal heard from the TI speaker is low. Really, really low. Much, much lower than I remember it being. And, thus, the TI doesn't see the signal at all. Plugging the microphone jack in sometimes helps, but it's still twitchy. If you screw around with the cable (ground pin 4, plug the mike jack into headphone out and the audio-in jack into line out, and so forth), suddenly the incoming signal volume dramatically increases and the TI sees it. That's ... not right, it's very wrong, and I hope I didn't break anything. I've spent the past two days poring over schematics (the official TI schematics, the SAMS schematics, with an eye towards Thierry's cassette port description) ... and I think I found the problem. Let's start with Thierry's tape description. It looks like this (omitting the ASCII DB9 diagram): # I/O Use - --- ------- 1 > Cass 1 motor control 2 > Ditto (negative) 3 > Output to tape 1 or 2 (neg) 4 > Audio gate 5 > Output to tape 1 or 2 6 > Cass 2 motor control 7 > Ditto (negative) 8 < Input from tape 1 9 < Ditto (neg) According to the schematics, that's mostly correct. There's one thing that's glaringly missing, though -- a ground connection. The way Thierry's diagram *should* read is thus: # I/O Use - --- ------- 1 < Cassette 1 motor control (switch input) 2 > Cassette 1 motor control (switch output) 3 x Ground (connected to cassette 1 and 2 microphone sleeve) 4 > Audio gate (unused, signal not present on cable) 5 > Audio output to both cassette 1 and cassette 2 6 < Cassette 2 motor control (switch input) 7 > Cassette 2 motor control (switch output) 8 < Audio input from cassette 1 9 < Audio input from cassette 1, connected to ground through RC filter Note pins 8 and 9. 8 goes to the tip of the 3.5" jack -- that's the signal. 9 should be grounded, according to the TRS convention where tip and ring carry signal, but sleeve is *always* grounded. This would be why I was never seeing signal without the mike line connected to something; there was no ground continuity between the recorder and the console except through the microphone connector. So as I see it, the fix is simple: connect the sleeve of the audio-in jack to pin 3, as it's supposed to be grounded anyway. I mentioned that I'd built a quick interface when I couldn't find my OEM TI cable a few days ago; I reused those parts and put them in a project box. I've got pin 5 connected to the tip of the microphone plug, pin 8 to the tip of the audio-in plug, and sleeves of both plugs connected to pin 3. That's it. You can wire in cassette 2 and/or motor control (I'm doing the latter, as the display shield on my BeagleBoneBlack has capability for this), but that's the magic signal fix. What exactly is going on with pin 9 is an open question. I haven't done the math to figure out what band that RC filter is passing, and the schematics have different opinions about what else is wired into that part of the circuit. Maybe cassette 2 was originally supposed to have output capability, and there was a last-minute cost-cutting measure. I don't even know how this was working in the first place, but I know this -- leaving pin 9 floating and grounding the sleeve of the audio-in jack makes ALL of the bogons go away. I do hope this helps someone else, because I burned a good ten hours running signals, reading schematics, and replacing the wiring on my keyboard once it broke off (another story). (what IS going on with that circuit? page 23 of http://www.mainbyte.com/ti99/man/ti99_tech.pdf makes it clear that it's an RC filter. The QI circuit on page 30 makes it look like it's boosting the impedance {which might actually work, but I don't have a QI}. The SAMs looks very much like the RC filter variant, except it has another resister in series before the filter that's probably boosting impedance. Can someone with more analog clue than I possess explain what TI was trying to do when they tied that into the audio-in ground line, because it had to work at some point)

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

You wouldn't happen to have a shoebox full of old TI cassette tapes, would you? If so ... well, might I suggest reading them in, converting them to TIFILES format, and putting them on a FTP/website for posterity? The world has lost a *lot* of data (read: "fun games") because steps weren't taken to preserve them, and it'd be a shame if you had something in that shoebox that doesn't exist anywhere else. Just food for thought. Happy New Year.

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.

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 )

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.

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.

I think these 2532As are "real", in that they were actually produced by TI, they're just damaged. I did manage to get two (out of a batch of eight) programmed using the TMS2732 scheme, but one wouldn't re-program after I erased it (to verify that I'd actually gotten a good one). There's this (from the thread that apparently originated the CS->A hack): http://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg804428/#msg804428 ... which refers to: http://www.eevblog.com/forum/blog/eevblog-411-minipro-tl866-universal-programmer-review/msg693248/#msg693248 ... so I'll wire in a switch to short out C22 (thus disabling the overvoltage check) and see if the "bad" ones will program anyway. (The chipid isn't an issue here, as the check is greyed out for TMS2732 on my setup)

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.

Doesn't work when you have a bad batch of possibly-fake 2532As from China. Over-volt protection kicks in every time. I was referring to the lack of 2532 as a natively-supported device (i.e., doesn't need an adapter). No need to bold type everything.

I just did the switch from CS to A (and updated the burner software to 3.50 while I was at it). Looks like it does what it says -- unlocks the in-circuit programming port to handle normally-programmed in-circuit devices. For TI purposes, it turns the unit into an Atmel SPI programmer; kinda worthless if you're already programming the Atmel via non-CS methods, but useful for those on a budget. (3.50 does *not* add 2532 programming support, dammit )

Worked fine on my TL866CS connected via a crappy USB2 hub to a Mac Mini running Windows 7 under VMWare. If it works under those conditions, it'll work anywhere ... and I followed your instructions to the letter, no worries.

Oh, it'll run on Windows too, if you install a Python interpreter. Cross-platform -- my main dev platform is MacOS (though that will change RSN), and I run a mixture of Linux and FreeBSD in production. Go to https://www.activestate.com/activepython/downloads and choose the appropriate installer for your platform, install it, then execute "python.exe ti_bin_to_wav (insert various options here)". A TI guy shouldn't have too much trouble figuring it out with the above snippets Edit: install Python version 2.whatever. They made heavy changes to the language in version 3. It's a nice cross-platform language, but it's stability rivals that of early builds of Okemo (or, God help us, Stowe) on the N71. (I'm a very recent ex-engineer from the United Fruit Company. I have a lot of unresolved anger issues concerning things that happened at Chinese contract manufacturing facilities over the past six years. Please bear with me if I make an angry reference that is difficult to parse by non-UFC engineers) (extra edit for possible United Fruit Company employees or lawyers lurking here: Okemo, Stowe, and N71 are all public and referred to in the various APIs. No NDA has been broken by this mini-rant, so please go enjoy your echo chamber in bum-fsck Zhengzhou. Thank you.)

That's ... weird. Three different conversion programs producing "bad" output from three different source files would usually indicate that there's something off with the console or the cable. 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? (According to the SAMS schematics, there's a RC filter network or two between the cassette port and the logic. One of those caps may be going bad ... they're the weird ceramics that look like resistors but aren't) Edit: make sure that the version of my python program isn't one that's hardcoded to produce .wavs for an overclocked machine. Use the one at https://github.com/christopherkobayashi/TI99Utilities...

Out of curiosity, which FDC chip was this intended to use?

Thank you. It's good to be back. It's been a weird half-year. Lots of forum posts to catch up on. I see that we lost Gazoo; that's unpleasant news.

The instructions at that link are extremely obsolete. Yes, replace every 74LS244, but replace with 74ACT244 (not 74HCT244). Also replace the 74LS245 with a 74ACT245. I'd do this for the bus drivers in the console, on both ends of the firehose, and every card in the PEB. ("why" is documented at https://www.disavowed.jp/index.php?/archives/12-The-TI-994A-PEB-flex-card-tune-up..html... but that one-liner should suffice) (yes, I was gone for awhile. Life got unpleasant. Sorry)

Hello, I've been working through making multicarts using the UBERgrom board, using Tursi's GROMCFG to load things into the Atmel chip. I'm very clear on how to handle GROM-only cartridges (Tursi: I'm seeing a bug in the GROMCFG you released a few days ago, where viewing slot 6 at base 0 always shows the recovery bootstrap image instead of what I've just loaded in). Very easy, works fine. What I'm not clear on is how to handle GROM-and-ROM cartridges (in this case, "Return to Pirate's Isle"). I load the GROMs into a base like any other GROM cartridge, and I put the 8k ROM into the 49F040 at 0x0000. That, of course, doesn't work. I'd have thought that each base would map to an 8k section of the 49F040, but that's not the case. So how should this work? Would I put the ROM-only multicart selector at the top of the EEPROM, as with a '379-based cartridge? If so, where should I be seeing RPI -- by activating the multicart menu? Which would take precedence in a GROM/ROM cartridge image -- the ROM or the GROM? I've scanned through scads of forum posts, and obviously others have this working, but I can't seem to find the "aha" post ... ... thanks in advance for any pointers, even if they're the "read THIS, you idiot!" variety ...

They are from China. They're probably bad. As I said earlier, I'm expecting a pair of 80-track EPROMs to be delivered today, so I'm good there -- thanks for offering. What I'd *really* like, though, is Thierry's fixed RS232 EPROMs. ArcadeShopper (where I sourced the 80-track EPROMs) has them in the list, but they're not a purchase option, so I was really hoping that I could get these 2532As to work

So was I. I built a stacked two-socket adaptor, crossed pins 18/20/21, verified proper continuity, and the blasted MiniPro still gives a "Overcurrent / backwards chip" error using TMS2732A. Programming voltage verified to be 21VDC, per (ancient) datasheet. Could be a bad batch of chips (eBay), or my TL866 may really be junk. Still works with 27©64 and up, though.

Oh, I have a nanoPEB ... I just don't like it. Nice concept, but horrible execution. Having to desolder and lift the power pin to the RAM chip to get it to play nice with my console's 32k internal 16-bit RAM expansion was understandable. Not having a protective case to keep it safe ... okay, it's low-volume hobbyist gear, I can see that. Having to buy a raftload of (obsolete, not-cheap) CF cards to find one that will peacefully coexist with the nanoPEB IDE<->CF bridge is somewhat annoying and a waste of money. Having to resolder every connection on the board until I found the cold joint(s) that was preventing the system from powering up 90% of the time ... that's going past annoying and rapidly approaching "this was a bad purchase" territory. Not being able to dump the logic from the Xilinx CPLD because the part was EOL'ed about ten years ago and I can find no tool to do so ... now we're into firmly "I don't want to depend on this" territory, and I then sourced a real PEB from eBay. But, yeah, I can test XB27 upgrades via nanoPEB if nobody else can. "Can", mind you, not "want to".

Calling out suspected heresy by a techmage/servitor is *never* off-topic, brother, and the Emperor rewards vigilance. (or, alternate interpretation, the alignment required to cast that particular spell is at least "neutral good" from Atmel's point-of-view. Which interpretation you choose depends on whether you prefer AD&D or 40k ...)

Upgrade worked using HxC as DSK1 -- green verification screen. The .hfe was created from your .dsk as DSSD (40-track). Disk controller is a non-80-track-modified TI controller (although the 80-track EPROMs should be arriving today -- curse the TL866 for not programming 2532As even with a 2732 socket adapter). PEB has only a completely stock TI RS232 controller. Interface card had its 74LS244s replaced with 74ACT244s (*not* HCT ... I don't quite understand why HCT was chosen over ACT). PEB is interfaced through a speech synthesizer. Console has a F18A, an on-board 16-bit 32k upgrade, and overclocked to NTSC colorburst speed. So ... I guess I'm saying "it worked for me with my unusual items".

I sure wish folks that truly cared about keeping old iron running would open up the design/production specs for hardware like this. It wouldn't cut into their profits to a noticeable degree (how many Chinese fabs are going to do ten-thousand-plus runs of a nanoPEB on spec?), and it'd ensure that designs are improved and don't die when the originator loses interest. SCSI<->non-SCSI is a wonderful general example. I've had to discard (and in Japan, that means paying several hundreds of dollars in disposal fees) a bunch of old/neat gear (SGI 4D/Indigo/Indy/O2/Octane, VAXen, and a *lot* sun4[cmu]) because I couldn't justify paying eBay shipping costs to replace dead drives, and the ACARDs would freak in interesting ways. If a SCSI<->ATAPI converter were to be implemented in FPGA so that it could be debugged when it didn't work right, then we (I) wouldn't have to get rid of otherwise working gear. Relating this back to TI, it's really a shame that the CF7/nanoPEB specs aren't available. The TI virtually *requires* a PEB to do anything useful. The target audience is limited. The CF7/nanoPEB is available only through a Belgian website with a six-week lead time. It's unreliable (CF card-via-IDE-bridge compatibility). It doesn't play well with onboard 16-bit RAM expansions. It seems to screw with Gazoo's XB2.7 suite. It needs debugging ... but that's not going to happen unless someone with a lot more spare time than I do decides to trace out the PCB, hope the Xilinx isn't fused against dumping, and publishes their work. It would be wonderful if Someone were to make a nanoPEB-like device design freely available. It would only benefit the community. Example is the Hexbus 74LS379 cartridge board, which (as near as I can tell) encouraged development of the '378 board, the ATMega board, and the board for the battery-backed RAM/EA combo. Um, rant over. Sorry. That got away from me a bit there. It's been a *long* week.