pixelpedant

I've got some 99/4 promotional materials I intend to post digital copies of fairly imminently. But to get started, here's a TI-99/4 Price List, Effective October 4, 1980, which is probably the most useful of them, to me. And also, a TI-99/4 Brochure in quite perfect condition: TI-994 Brochure 2.pdf There is at least one existing scan of that one, but in relatively poor quality/resolution, so this is an improvement on that. Alternatively, as source JPEGs:

This is why I included "Corridor Shooter" as one of the options in my thread about underserved genres on the system. I feel like we're weirdly missing the maze/hallway shooter (or otherwise, maze action game) genre. Even a primitive MIDI Maze style maze shooter would be cool. The closest I can think of that we've got is Wizard's Lair/Wizard's Doom. Which is a maze game involving real time enemy movement and real time combat (a la Dungeons of Daggorath, kind of). But it's clearly an RPG by design and intent - not an action game.

Untested (external) disk memory drive: https://www.ebay.com/itm/394283736875 Who's feeling reckless and spendy?

Photos of some 99/4 brochures that arrived in the mail for me today: Also (not pictured) a 1980 price list. Will have to scan.

No idea where I found it originally, but it works just fine. Running ASTIROIDS as EA3. astiroids.dsk

Likewise, and there's a lot of potential to develop that sort of thing pretty easily these days. Particularly given senior_falcon's TML Graphic Adventure Extended BASIC toolset. Which dedicates the upper portion of the screen to full bitmap graphics, and the bottom of the screen to bitmap text. With compiling such programmings being an option. As shown at the timecode linked here:

Well, I wouldn't call GPL a high-level language.

Sort of. There are a few simple games. A couple were evidently created by students as class projects. The most complete is I suppose FROGO, a LOGO frogger clone. The other few I've found are very basic. A_FROGO I've never found anything that really exploits LOGO's potential (in particular, to control large sprite groups efficiently). Imagining something like my TI LOGO II "PLANES" demo from a while back, extrapolated into a game of some sort: Planes v4 - shorter.mp4

Perhaps F18A video, ForTI music, and MBX synth, just for good measure.

There are a few more languages and dialects which made some sort of appearance on the TI-99 natively, to be sure. Though receiving very little actual use. If one of those is in your plans, even better. My list of priorities is probably: 1) TI BASIC (likely use: major long-term game project) 2) TI Extended BASIC (likely use: major synth project) 3) TI LOGO (likely use: action game project) 4) UCSD Pascal (likely use: not sure yet)

Looking at the responses to the videos I've done on a whole pile of different topics in BASIC and Extended BASIC programming (and the various supporting libraries), it seems to me there are actually a lot of people out there (most of whom don't post here) who are interested in programming on the TI-99. Who find it to be an interesting topic of discussion and sandbox to play around in. And I get lots of people responding about their own little experiments or intended experiments. It's just that there's a huge leap in work and effort involved in moving from these piecemeal experiments to designing and coding and debugging and testing a satisfying and playable game. And I think the number of people interested in doing the latter is greatly smaller, regardless of the language in which a project is created. It is one of the great strengths of the TI-99 that you can boot it up with Extended BASIC plugged in and type CALL SPRITE and CALL SOUND and CALL SAY and make it do a bunch of cool things in BASIC with very little technical knowledge of any kind. It's really easy to get people in at the ground floor doing some of these cool experiments. And people seem genuinely interested in doing them. It's just that the next step is a doozy. The XB Game Development Package definitely provides one fascinating, compelling option for a transition to larger projects which actually produce enjoyable, playable games. But still, the move from playing around with the machine's capabilities in little ways and actually developing a game is a rather large one. As for me, I'm probably still hopelessly hitching my wagon to TI BASIC, for what comes next. I've got too many TI BASIC development ideas which came out of Hell's Halls but which couldn't be implemented in that project for various reasons. After that though, who knows.

Well, it seems like a city Sim (whether a straight up SimCity port or otherwise) is the winner here. Here's hoping we get this some day, or something like it:

Maybe late for a feature request, but would you consider adding a Shift+838 cheat screen for tweaking a few key engine physics variables? This is something included in some legacy titles, and even if the consequences of such alterations were largely silly or unplayable, it would likely serve to entertain.

I do feel like SimCity could be done just fine with conventional 9918A (or even 9918) graphics. The Spectrum version is pretty much proof of that. I suppose I see a stronger argument for SAMS than F18A, given any game like this involving a large, complex, dynamic map is going to be mighty memory-hungry.

Needless to say, I can't name every video game genre that is, has been, or ever shall be. But these are a few genres which were represented on 80s hardware, which feel like they could want for more representation on TI-99. For my pick, I'd love to see a good rail shooter (see: various 8-bit Space Harrier ports, including MSX1).

Hah! Figures "sorry mate" just wouldn't process, for my Canadian brain. And the samples are being encoded by Python Wizard using TMS5200 reflection coefficient values?

Nice. Speech is mostly without issues in this version for me on original hardware. But I am still getting speech problems in two places where I've gotten them before. And the manner of the distortion is always the same for each sample concerned, through many repetitions over 20ish minutes of play, and is always present: (unsure of sample intended here): bug 1.mp4 "Game Over": bug 2.mp4

I see what you mean, yeah. I'm getting that too.

I can confirm that this 1.2 version greatly alleviates garbled speech for me on original hardware. All speech samples play understandably and no speech-associated temporary freezes occurred through 15 minutes of gameplay. At this point, the only discernible issue with speech is small skips and slightly garbled bits in a few select samples, as here: Speech Skipping (1.2).mp4 But everything now plays, and most of them play completely without issue.

I will just echo the last comment here - on both original TI + speech synthesizer (as well as emulators), I do get a fair amount of garbled speech in the 1.1 version of the game. Some events seem more prone to it than others. One particularly problematic case is, when the ball traverses the "games" lane, whatever speech event is intended there seems to often freeze the game for me: freeze on top tunnel.mp4 But note that the speech event immediately before that played fine. That is on original hardware, incidentally. Another minor bug is, the ball can (but does not usually) pass in the wrong direction through the left gate at the top of the board: ball passing through left gate.mp4

Thanks! A couple hints: - Since timing for attacks is quite tight (especially as of level 2 and up), it can be easier and more effective to preemptively hold down the attack button in any given desired direction for each attack and release it immediately upon the attack's execution, rather than tapping it only precisely when an attack is intended. TI BASIC just doesn't have the luxury of fast input handling, so control is a little odd in this way. - The Main Game's timer offers only enough time to complete the dungeon by finding efficient paths and picking up items along the way in an expedient manner, that maximises gold collected while minimising steps. Only in the Second Quest game variant can one really explore the dungeon levels completely without worrying about a timer.

Most of this video is about scrolling techniques in XB and Compiled XB (via the XB Game Developer's Package). So this may be of interest:

By popular demand (well, that may be going a bit far, but a few people did ask for such a thing or suggest it be offered), I've added a Digital Download Edition of Hell's Halls to my site, with both of the game's two (Side A and Side B) versions in all possibly desirable formats, as well as the game's pack-in materials, cassette labels, and a revised and improved version of the type-in version posted here (with more comments, throughout). If you purchased the game previously and would like the Digital Download Edition as well (with the updated type-in version magazine spread being the main reason one might want it, it seems to me), just message me with your name or the top-secret identity under which you purchased (some of you I know of course, but some I don't) and I'll send you a link. You do not need to purchase it again.

With that toolset (i.e., what you already have in XB+NanoPEB), you have the means to compile BASIC programs or play sound lists. And with that ability, you have the potential to write music in BASIC (with all its simplicity) while taking advantage of techniques which require faster processing of sound commands than the BASIC interpreter affords. So that may be something you want to look at. While I myself take a great interest in squeezing as much as possible out of the TI-99's sound in plain old TI BASIC, it very much is an exercise in squeezing blood from a stone, given the time required to process each CALL SOUND command. So investigating faster solutions is not unwise, if one leans more in the direction of results-oriented goals than "compelling challenge" oriented goals.

Thanks for catching those lines being duplicated in the listing! I didn't catch that, naturally, as entering the same line twice has no detrimental effect. And yes, that's correct, there are no lines in the 200s. The sequence of lines jumps around rather weirdly, since, with GOTOs and GOSUBs handling all control flow, major changes to line numbers would have presented major challenges during development (by frustrating my ability to recognise subprograms by line number). So mostly, beginning line numbers for any given section of the program or subprogram reflect those of an earlier and drastically different stage of development. A BAD SUBSCRIPT at line 3340 might indicate a problem with this line: 3320 IF (D(2)=W)+(RY=4) THEN 3400 Or otherwise, if a door existed at the bottom row of the screen (which it should not), this line: 3300 IF RY=4 THEN 3310