ckoba

All, With all of the neat new cartridges that have been coming out (especially Gazoo's compilation work), I spent a bit of time with Affinity Designer and created a bunch of labels intended to be printed on sticker paper. The difference between these labels and the others that I've seen posted is that these are vector-based, not raster. They're small, print fast, and look good at any resolution. Labels are included for TurboForth, Extended Basic 2.7 Suite, the various E/A carts, and Gazoo's game collections. With an appropriate editor, the templates can be used to create a stock-looking label for any module. Mac users, I *strongly* recommend Affinity Designer because it's a) cheap, b) interoperable with Adobe Illustrator, and c) fast as hell. Included in the attached zipfile is the Affinity Designer sourcefile, an EPS export, and a PDF. All of this expects to be on A4 size; since it's vector, it can easily be printed on US letter-size stock without loss of quality. Enjoy, -- Chris TI_Cartridge_Label.zip

That zipfile has the code, and the .dsk that mizapf thoughtfully posted has a GRAM Kracker version of the same (onagi hash). Adding the separate, 6144-byte GROM files as a user cartridge in classic99.ini works, insofar as "SCOTT ADAMS' ADVENTURE" is displayed on the selection screen. My .ini looks like this: [usercart0] name=Ubergrom test ;rom0=C|6000|2000|C:\Program Files\classic99\MODS\phm3189c.bin rom0=G|6000|2000|C:\Program Files\classic99\MODS\xaa-fixed rom1=G|8000|2000|C:\Program Files\classic99\MODS\xab-fixed rom2=G|A000|2000|C:\Program Files\classic99\MODS\xac-fixed rom3=G|C000|2000|C:\Program Files\classic99\MODS\xad-fixed rom4=G|E000|2000|C:\Program Files\classic99\MODS\xae-fixed (The ROM bit is commented out to ensure that it wasn't a factor in the menu display. The cartridge, of course, doesn't work without it, but does work with it). So, in summary, it works fine if it's split into individual files, at the same addresses as mapped into the UberGROM. There's something off about the UberGROM, or at least the way that I'm setting it up (bases on, recovery on, rollover off, flash dev on). The physical UberGROMs I'm using to test with were prepped with ubergrom.hex via the TL866 method and the fuses have been triple-checked. As I said, I've made working cartridges out of GROM-only carts. This is the first GROM-and-EPROM that I've tried.

Thanks for posting that. You're using that with a GRAM Kracker, yes? Once I strip the GRAM Kracker six-byte headers (and chop them down to 6144 bytes), the md5 hash on the files matches those in the RPK ... so we know we are working with a good dump. And, unfortunately, it confirms that the second GROM (at >8000) contains the AA 01 "I am a cartridge" signature.

Nope. Well, a qualified "nope" in that it blue-screens when I hit function-= per Tursi's instructions tucked away in formatter/ReadMe.txt: To be useful, you will need to be able to simulate an UberGROM in emulation. Classic99 has had limited support for a few years now, enough to run this, anyway. Add the following configuration to your Classic99.ini. When you select this cartridge, you will get my EA Complete hack in place of TI BASIC. The UberGROM support is not sufficient to load any cartridges yet, although if load them with GROMCFG they should work until you reset the emulator (so exit with QUIT, not file->reset). I'm assuming that last sentence means that I should see the constructed UberGROM image after I function-quit out of GROMCFG. I don't; it goes blue-screen. If I could get another set of eyes on this, I'd appreciate it. If I understand correctly, no matter how else I screwed it up, if I have an AA 01 at the beginning of any of the GROM banks, the TI *will* at least show it on the menu ...

Interesting idea. I built another image starting at GROM3 (mapping 6 to GROM:3, 8 to GROM:4, and so forth) after adjusting the GROM base images to match ... ... but no dice. And, in retrospect, if that were the case then the Multiplan cart I made wouldn't have worked. Other ideas?

Please ignore "six". I meant "five". Thanks for attaching another copy of RPI. The checksum of the unzipped files matches what I was working from, so it's the same copy. Setting up in classic99 has the same result -- blue screen, both when I try to run the module in the emulator after setup with gromcfg (screenshot of setup attached) and when I dump the setup to disk, transfer to real iron via floppy, and load the whole shebang via gromcfg. Bootloader GROM/ROM scanning issue? Bad luck? (edit: attach right screenshot. It's early here)

s/six/five/g I was watching a boring movie with the wife while writing that, so I was working from memory. The rest of it should be correct.

Re-hijacking the thread back onto my original subject ... ... I've had a few days to revisit this problem, and (to quote what Billy Joel said just now as "Laura" is playing) I feel like a (expletive deleted) fool. I wasn't very clear in my original plea for help. At the micro level, what I was trying to do was to use the UberGROM board to replicate "Return to Pirate's Isle". I own the physical cartridge, but it's beat up and I have this tendency to want a spare of *everything*. It's a ROM+GROM cartridge, with six GROMs and 8k ROM. The ROM doesn't have a "TI cartridge" header, so it's just data or code called by the "real" cartridge in the GROM. Tearing the GROM apart from the RPK I found lying in the ditch by the side of the road, I see that the six GROMs are padded up to 8k. So I split them with "split -b8192" to get the GROMs into rough shape, then "split -b6144" each one to cut them down to actual size. Looking at each GROM, I notice that the second GROM has the magic "AA 01" header; the others don't. Odd, but okay, I'm not so well-versed in cartridge internals, which is why I'm doing this. I then boot up the TI with a prepped UberGROM cartridge, holding down space, and get into GROMCFG via the recovery. I follow procedure (map GROM slots in sequential order, loading the buffer along the way), and all seems well. The EEPROM side of things consists of the same 8k file repeated 64 times to fill out the entire EEPROM space. (EEPROM == 512k at >6000, not the 1284P's internal EEPROM) So, I then powercycle the console ... and blank blue screen. Sometimes I'll see the TI splash screen, but when I hit a key it goes all blue and stays there. If I powercycle with the space bar down, the splash screen always comes up and "Scott Adams Adventure" is an option. Choosing it, however, crashes the console in boring and unexciting ways. I believe my module creation procedure is correct, as I can replicate GROM-only cartridges like Multiplan without problems so long as I follow the rules (one cartridge per bank, keep the GROM data pruned and in order). It's just this one that I can't get working. Am I trying from a bad image? (The RPK works in emulators) Is the first bank not having AA 01 relevant at all? There's something obvious that I'm missing. Anyone? (edit: clarify that I *am* using the "EPROM" side, not the internal 1284P EEPROM when I say "EEPROM")

I have one I'm not using, would be happy to part with it. Works fine; I used it for a bit, got frustrated at the CF compatibility issues, and got a real PEB to replace it. The difficulty is that I'm in Tokyo, so shipping would be expensive. If you want it and are willing to pay shipping, it's yours. Price negotiable, and if you're in the US (or a place that uses US-style wall outlets) I'll throw in a wall wart.

I don't have access to a graphics editor at the moment, but I can describe it to you: * R406 and C402 should form a classic bandpass filter for the signal passed in through pin 8 (ignore L402 for the moment, it's an inductor), connected to what *should* be ground, * pin 9 (supposedly audio-in ground) is isolated from console ground through what's essentially another classic bandpass filter in R409 and C414, * therefore, pin 9 (audio source ground) is and can never be at the same voltage potential as the console, * presto, ground loop. The QI circuit is even weirder, with audio-enable coming into play, but that's basically it. The circuit as described in that schematic should only work right if a) pin 9 is grounded externally at the audio source and b) that ground is common with console ground through another route (i.e., the microphone jack ground). I think the TI design guys got lazy and figured that the microphone ground was good enough, and didn't consider non-mono and non-mike-connect cases. (edit: clarify pin 8 behavior)

(quickly walks upstairs to look at my TI wall wart) Yep, old ungrounded two-prong. That is definitely relevant, and makes a difference. The two devices (sound source and TI) need to see eye-to-eye regarding what ground is, especially when processing audio. I leave my PEB plugged in all the time, and I have the F18A connected to a grounded monitor, so I have two paths from the console to earth ground. If the TI was ungrounded, *and* the microphone jack sleeve ground wasn't somehow connected to the sound source's ground, then the two devices would have no common voltage point of reference. With the added chaos from a signal being introduced into the console on pin 9 (by virtue of the sound source being a stereo jack) ... ... yeah, that's not going to work very well (understatement of the day for me). Good catch. That reinforces my point: tape guys, make sure that you've got a ground connection between the sound source and the TI. The line-out-versus-headphone-out argument, like Communism, is a red herring. Modify your console, wire an interface box, whatever it takes to get those two units to see eye-to-eye on what zero volts actually is. Worry about Shmitzi's "am I using the right audio-out jack" hraka later -- get the fundamentals right first!

(replying for him, because I'm awake and just re-watched the video while writing the above) It was the headphone jack on a pair of external amplified speakers. It wouldn't matter what the interface between those speakers and the PC was; at that point the speaker amp was driving the signal.

Firstly: thank you, Fredrik, for the various test cases. They were much appreciated. That bit that you noticed with the microphone jack not working properly if fully plugged in is a perfect example of the inverse case -- you were basically seeing on the PC for recording what the TI is seeing while listening. So, to bring this thread to some sort of closure, here's the behavior summary as I see it: The TI cassette cable has mono plugs, The audio-in plug therefore shorts the ring (right channel) and sleeve (ground), The TI cassette cable connects the microphone sleeve to console ground, The TI cassette cable connects the audio-in sleeve to ground via (at least) an RC bandpass filter, If the TI cassette cable microphone plug is not plugged into the sound source, there *will* be a ground loop through the audio-in sleeve, Behavior of the system beyond that point depends very highly on the quality of the sound source design, Anecdotally, adding a large amount of amplification (and possibly equalization) to the signal overcomes the ground loop. From an electrical engineering (and, thus, physics-derived) standpoint, here's the summary as I see it: There are at least three different versions of the circuit schematic for the goop connected to the audio-in sleeve, which in turn means ... ... there will be variance in what works for each user, depending on the goop in that particular console and the sound source design, The incoming signal is amplified by a pair of op-amps to +5VDC in the console, so significant signal amplification should not be necessary, In general, ground loops are bad and should be avoided if at all possible, In general, significant signal amplification is wasteful and should be avoided if at all possible. So, here are the possible fixes (in ascending order of desirability) as I see them: Run the signal through a large amount of amplification (as demonstrated by Opry99er's video -- thanks for that) to overcome the ground loop, Plug in the microphone jack *and* use a mono-to-stereo plug converter to isolate the ring from the sleeve on the audio-in jack, Replace the mono-intended cable with a stereo-intended cable wired per the first post in the thread. The first one works for some people (plural of "anecdote" is not "data" , but is electrically incorrect and will not work in all cases. The second and third are functionally equivalent. Or, tl;dr: either amplify the signal a *lot* (and expect it to have issues from time to time) or fix your wiring. Your choice. The first one doesn't take any extra effort, but in electrical engineering, the laws of physics tend to be somewhat authoritative

To disable a soldered RAM chip, you don't need to desolder the whole thing -- just heat the upper right-hand pin of the RAM chip (Vcc) so that the solder dissolves and lift it. That way you can re-enable it if you decide to sell it. I did this with my now-unused nanoPEB (RAM chip was SMD, not socketed nor socketable). (I'm willing to sell it, but shipping from where I'm at would probably be excessive). I've performed the Mainbyte 32kB modification on my console. It appears to work well; be mindful of the metal shields surrounding the VDP RAM, as they actually carry +5VDC (or ground, I forget which). You'll need to bend them, but don't remove them in portion or in full.

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

Oh, no, I left nearly twenty-five years ago. Weyerhauser pulled out, WIDCO sold off the strip-mining operation to whatever holding company owned the Steam Plant, and the antique shops / WalMart invaded. That place has been on life support since the early nineties. I'm on the other side of the planet, in Japan. Not a place I would choose for a get-together, but I'm pretty sure the Eagles lodge would rent the hall for a night at a reasonable rate.

That's my home town.

Nowadays, when I have a gig, I'm either team lead or project manager, yeah. I prefer the former. That "messy setup" is correct. You're not mixing right-channel audio with the TI audio-in ground, so no ground loop and you're good-to-go. Here's mine, for what it's worth: It (and the USB sound converter) sit on top of the PEB under the desk, and that thing on the right is a BeagleBoneBlack with a LCD screen emulating the tape recorder interface.

Be wary of the phone screwing with the signal equalization. At United Fruit we played games pre-DAC (and not tunable in customer OS builds) to optimize the sound experience for people using United Fruit headphones (mostly screwed with the bass); the tape signal is frequency-modulated so you want the signal to be unmolested.

No worries, this is the sort of thing that I was trained to do. Sure wish I could re-use some of those EE brain cells for something else, because I so very rarely get to actually use them at this point in my career arc. When I got back into TI about a year ago, I thought it odd that I couldn't "OLD CS1" unless the microphone plug was also connected, but never really gave it much thought until I had to build a temporary cable (I got ahold of a PEB and a HxC, so I don't usually use tape anymore). I tell you, I had several WTF moments while reading the schematics ... ... anyway, glad to help.

Thanks. Important to know that we're testing like-for-like. As I said just above, this works for most people purely by the power of overamplification overcoming what appears to effectively be a ground loop, per https://en.wikipedia.org/wiki/Ground_loop_%28electricity%29. I don't think TI had stereo 3.5" jacks in mind when they were designing this in the mid-seventies. I truly believe that the right thing to do is to keep any signal from reaching pin 9 ( https://en.wikipedia.org/wiki/Phone_connector_%28audio%29#Mono_and_stereo_compatibility, and also the fact that any true ground connection is going to be on the mike line via pin 3). Like I said, I hope this research and analysis helps someone else from spinning their wheels trying to get a working tape connection ...

Okay, now I think I see why this works for most people -- lots of amplification overcomes the signal drain through the gunk connected to pin 9. If the white jack is connected to a mono source, then the gunk connected to pin 9 works as TI intended (at the very least an RC filter, plus maybe messing with impedance, depending on the schematic you're looking at). If the white jack is connected to a stereo source, you've got a fight between the other half of the stereo signal and the sleeve ground. The gunk hanging off of pin 9 is seeing a faint echo of the "real" signal on pin 8 (because you've now got a ground loop), and since pin 8 and 9 are connected via a cap and a resistor (at least), the real signal is going to be seriously attenuated, thus not giving the pair of op-amps much to work work. So this works for most people because they're throwing a lot of amplification at the problem to overcome a design that didn't expect a signal to be coming in a ground line. Interesting. So, if you don't want to or can't double-amp the signal, try a modified cable/interface box. See if that lessens the need for heavy amplification. I'll bet things will work better if you do.

I did see that video, but I did not make the connection to this. I skimmed it briefly just now looking for bits that would correlate to this. At about 1:50, you're plugging the white wire into the headphone-out on your amplified speakers, not directly into the PC. Electrically that's not the same thing, and that amp is going to be putting out a much stronger signal than the ports on your PC, I think, and impedance may be coming into play. That having been said, the comparative volume between the console "beep" and the program read sounds right. You've got a good ground connection between the console and the speakers, or the speaker amp is loud enough to drive the console. ... do you have the one-cassette or the two-cassette cable?

Oh, neat. If you dig that up, could you do me a favor? * plug a stereo 3.5" male-to-male plug into the earphone jack, * ditto for the microphone jack, * check tip, ring, and sleeve for continuity between each of the plugs. In other words, see if you've got a short between the tip of the earphone plug and the microphone plug (you shouldn't), the ring of the earphone plug and the microphone plug (you probably will), and again with the sleeve (I think you won't). I'm starting to be convinced that the mono audio-out jack of cassette players of the time had its two pickups right next to each other, so audio would be picked up at the tip and ground would be picked up at what was then part of the sleeve (and thus grounding the connection between player and console) but is now the ring (which puts an audio signal into what should be ground, which heavily attenuates the signal based on what I think the TI schematic is doing).

No, I've got it fixed. I built a small box that handles signal and ground properly, and have detailed a workaround for those that want to use the original TI cable. It seems like the cable is expecting to see signal on tip and ground on ring (because it expects to be plugged into a mono jack), but it's seeing signal on both tip and ring and no ground connection at all. That other side of the signal isn't being lost, it's being fed into what the console thinks ground should be (along with being shorted to the source's ground, but impedance seems to be saving us there) and is cancelling out the signal. I think. That's the only explanation that makes sense -- maybe old tape recorders picked up signals from tip and ring, because for mono use ring and sleeve were the same. Anyone feel like taking oscilloscope measurements on an old GE tape deck output, or tearing one apart and seeing where the tines on the headphone jack were placed respective to the jack body? You're right, this could be mitigated by putting a mono-to-stereo 3.5" adaptor between the OEM jack and the audio plug, but that probably wouldn't handle what was being fed from the console to the sleeve via pin 9. In any case, the TI cable a) shorts one channel to ground (which should only attenuate the signal on modern electronics, but could kill that channel's amp on older gear) and as a consequence b) doesn't properly ground the audio input. This is bad, and feels like a design flaw (or, assuming that TI assumed that what was coming in on pin 9 was *only* ground, a very nasty shortcut). This may well be why tape transfers are finicky and erratic. From an electrical engineering standpoint, given the cables that are used and the equipment those cables are plugged into, I recommend either: * building a tape interface box wired per my first post, or * cutting the trace on pin 9 and jumpering pin 3 to pin 9 on the console per my second post, because * the TI console isn't following TRS spec on the audio-in line. Thanks for asking, though.