pixelpedant

New, shorter variation on my contribution. This one, rather than asking for user input for colour and pattern, just randomly selects a (background-contrasting) colour, and randomly seeds the generated animation pattern. Patterns are also a little more diverse. Bringing the sum total down to 7 somewhat shorter lines, instead of 9: 10 RANDOMIZE 20 CALL CLEAR 30 CALL COLOR(1,2+INT(RND*7)*2,13) 40 P=P*-(P<9)+RND*6+1 50 SP$=SP$&STR$(INT(P)) 60 CALL CHAR(32,SP$) 70 IF LEN(SP$)<30 THEN 40

Here is a succinct TI BASIC animated demo that I've put together. I felt like doing a 10 liner. Though it ended up as a 9 liner, as it turns out. User input defines color and seeds a pattern for an animation. Generated animation patterns are reasonably varied if not numerous. And any out of range values for the inputs are just treated as "0" in both cases. 10 CALL CLEAR 20 INPUT "PICK A COLOR (0-7)":C 30 INPUT "PICK A PATTERN (0-7)":S 40 CALL CLEAR 50 CALL COLOR(1,2+C*(C<8)*(C>=0)*2,13) 60 P=P*-(P<9)+S*(S<8)*(S>=0)+1 70 SP$=SP$&STR$(P) 80 CALL CHAR(32,SP$) 90 IF LEN(SP$)<30 THEN 60 The conclusion of the animation is displayed on screen for a few seconds statically before exiting automatically.

Well if any given solution assumes the availability of CTRL and FCTN key combos, no dice, right? Also, no direct input of the following characters { | } ~ ` \ [ ] could interfere. I would think any feature-rich terminal software not designed for compatibility with the 99/4 keyboard would fail for simple lack of analogous keys.

I have used TI's own TI PILOT to a degree. You can see some limited use of it in a video I did a while ago on the p-code card and p-system. Note that Pilot99 (provided in the above-attached file) is not the same thing as TI PILOT. It is an independently and separately produced freeware implementation of the Pilot language for TI-99/4A. TI's own TI PILOT is a p-code program (implementing the Pilot language) whose capabilities are consequently largely defined by those of TI's provided p-system libraries (but further limited by its extremely simple syntax). So that being the case, I find TI PILOT per se pretty uninteresting. Since it's just a less feature-rich, less flexible, less performant way to access capabilities the p-system provides you via Pascal. It's intended to be a very stripped-down educational language. And I don't see much shine in it outside that very specific application, personally. Here is the disk for TI PILOT itself (requiring the p-code card and p-system environment): TI Pilot [PHD 5066].dsk

I'm very pleased with how the overall vision came together, though it's perhaps an absurdly overambitious one (which is trying to be more so a proper RPG, with a totally different dungeon generation/exploration model). I do hope to get back to it in earnest. TI stuff has just taken a back seat lately, and I haven't been online in the retrocomputing space much at all. I'll hopefully get myself back in the swing of things, in the next month. Real life has just taken precedence, of late.

TI's early home productivity carts are TI BASIC, yeah, but at least some include supplementary subroutines not otherwise available to TI BASIC (like PRK has a DISPLAY AT equivalent - CALL D - for example), and so cannot be regarded as pure TI Console BASIC. Notably, regular TI BASIC programs can access these subroutines when the cartridge is inserted, making PRK a de facto Very Slightly Extended BASIC.

Midnite Mason, TI Invaders, and Munch Man all have very good difficulty curves which always leave a greater challenge to be overcome.

Cool that folks are still discovering it! And I seem to have produced enough copies to address relatively long-term demand. Though I'm kind of glad demand hasn't kept up indefinitely. Recording and testing and producing the pack-in materials was rather time-consuming. Two threads talking about it this week means more encouragement for me to actually finish the sequel, eventually. Which is all to the good.

TI seems to use the term "console" or "control console" or "system console" pretty widely in its 990 materials as well. See for example:

The "displaying one room at a time (upon opening any of its doors)" exploration mechanic was initially just forced by how long it would take to generate an entire floor all at once. Given not just the dimensions but also 1) the contents of the room and 2) their positioning, and 3) the positions of any new doors also need to be determined, then drawn. But in the long run, it's also just more interesting to explore as you go, I think, so as much as it was forced, it was also what I wanted. Procedural dungeon generation in TI BASIC continues to be a fascination of mine, and one which will be further elaborated on if I ever finish Hell's Halls' sequel (Hell's Heart), which uses a freer and more organic (less "grid-like") dungeon generation system.

Huh. Basically a "solid state software" 99/4A in all regards, but missing the joystick port and power switch.

Cool bit of trivia there. Thanks for that. It and Stargazer 1, 2 & 3 are probably my top third party education games (and I do have both). So I guess John Phillips gets the nod in that category, for me.

The Great Word Race is actually pretty rare. $35 doesn't seem bad to me for a good condition cart: https://www.ebay.com/itm/314714637808

Incidentally, for anyone looking to compose midi for TI PSG with actual in-application TI PSG audio output behaviour identical to that in the TI-99 (i.e., relevant tone and noise types, relevant restrictions on voices, frequency, etc.), I would recommend using the Socalabs SN76489 VST. Hosted by whatever relevant VST Host (I use LMMS and VeSTige, but this is just one option). A main benefits of this for me is being able to play notes on a MIDI (i.e., piano style) keyboard, with direct TI PSG output, within a MIDI-oriented application.

I'd recommend LMMS, especially since multiple SN76489 implementations exist for it. But that having said, I'm not sure I'd fall it "easy to use", especially in this context. One problem is, a list of CALL SOUND statements is a list of sound events of specified duration which may be interrupted (via negative duration) or played to completion (via positive duration) as desired. While a MIDI file is, on the simplest possible level, a series of statements specifying when any given instrument begins to play and ceases to play respectively. With these being two separate events. So translating a MIDI file to CALL SOUND statements is non-trivial, since you need to infer the duration of each note based on the difference between the time code at which an instrument begins and ceases playing, for every instance of this occurring. It can be done. And I've written a script to do it in the past, as have others I expect. It's just a really big pain.

Here is a relatively high resolution (5700x2500) TI-99/4 promotional spread I've gone to the trouble of photographing in segments, combining and retouching. And individual games aside, I think this one would make for a good framed TI-99 wall item. Fairly rare 99/4 promo flyer, from what I can tell. The release flyer's the more common one. That and the other 99/4 promo stuff is on my catalogues/manuals site. But those are generally paginated as PDFs, and not saved at as high a resolution as this.

Now that I look at the image sources, it appears they're being directly served by Facebook. So that makes sense now. As I outright block Meta's cross-site content. Though I don't know if Facebook allows cross-site image embedding regardless.

Perhaps, but here is how I see the original pics:

Atariage does weird things with embedded images sometimes. Or maybe it's the source host. Regardless, here they are as simple attachments:

High-quality retouched scans of all MBX overlays are also available in my MBX resources thread, so even if you acquire a cart without overlay, you can print one (and laminate, if you're being thorough).

Not really, for the most part, so far. There have usually been copies of various carts kicking around on Ebay. Partly, I would say, just because some carts can *only* be played with an MBX, so their market is inherently vanishingly small, even if their number is also pretty small. They're all relatively uncommon in TI cart terms, but none of the released titles (for which stock was in most cases dumped to employees and a couple vendors very hastily, after the product's cancellation) are all that hard to get. I have assembled a repository of MBX information in this thread here, should you need more:

Nice! So it does sound like most of them at least were built and sold (albeit in absolutely tiny numbers).

Oh, hey John. Nice of you to show up here! I have another couple quick questions for you: A bunch of your games were advertised by Sunware/Exceltec for a little bit circa 1984, long before DBT sold them. Do you know if those carts (Face Chase, Star Trap, Stargazer 1 2 & 3, Beyond Space, etc.) were actually sold by Sunware/Exceltec? And were you duly paid by Sunware and Databiotics for the ones that sold, in each of those cases? Kind of an ugly question, but people not getting paid for their work certainly did happen in that era. Possibly a moot point in some of the Sunware cases though, since I'm not sure they even built any carts, for many of their announced titles.

Video Chess has no such issues for me (across many games) with SAMS and F18A installed. But that's not surprising. There's really no reason it should.

One that snuck up on me in recent times: Midnight/Midnite Mason. I played the DBT cart back in the day, but I didn't much see the appeal. Nowadays though, the interplay between the need to manipulate enemy movement and the need to restructure the level to facilitate that makes for a really cool dynamic, which is a combination of the good things about Pac Man and Lode Runner. But it doesn't have the problem (in our case) TI Runner has, that once you've solved a level, you've pretty much solved it.