pixelpedant

ON GOSUB is definitely worth mastering. For complex conditionals with many possible input values, it can produce structures which are both faster and more memory-economic than any equivalent set of IF conditionals. The main 'trick' to it is just understanding that TI BASIC numeric variables are always and only floats, and accordingly, ON GOSUB does not care if its argument is precisely "1" or "2" or "3" or what have you. It only cares that it is closer to "1" (or 2, or 3, and so on) than to any other integer. And this creates a great deal of flexibility, where arbitrary input values can be arithmetically strong-armed into sufficient proximity to these integers. So for example, an ON GOTO from the program I'm currently working on is the following: 7720 ON (B-169)*(B-169)/97 GOTO 7800,7600,7500,6800,7000,6600,6400,6300 The purpose of the equation (B-169)*(B-169)/97 being, to take values of B ranging from 176 to 197, and conflate certain ranges therein, such that ON GOTO sees this as a set of sequential input values ranging from 1 to 8 (with different outcomes for each). Though in practice, it is a set of input values consisting of successive ranges (and in some cases, individual values) from 176 to 197.

Named subroutines aren't too bad from a performance standpoint, but I still more or less never use them, favouring GOSUBs and the extremely useful (and exceedingly fast) ON GOSUB, with both of those being exceedingly fast.

Really, what you generally want to do is use CALL COINC(ALL,X) for your detection of a collision in the game loop (which is quite fast, in XB terms, as the VDP status register flags collisions inherently, but only by indicating that one has occurred). Then, only if necessary and unavoidable, test whether it is a specific collision (which will be significantly slower). Many of the best 80s era XB action games simply pursue a design which is wholly dependent on CALL COINC(ALL,X). Which is to say, only one category of collision may occur (e.g., player touches one of the things that will kill the player), and when a collision (any collision) occurs, its consequence is therefore assumed. And that tendency is just a consequence of testing for individual collisions being so much slower. Still, the method I'd mentioned, where CALL COINC(ALL,X) reports a collision (in general), and CALL DISTANCE or CALL POSITION is then (and only in that case) used to determine which of multiple possible collisions has occurred - that too can work acceptably. Another approach is to ditch automotion and just position your sprites with CALL SPRITE or CALL LOCATE (which are roughly equivalent in performance). Then, just determine collisions based on the already known coordinates of the sprites.

I think that would make a great deal of sense. I'd considered writing a script to do this on my own behalf, actually, just because it would arguably result in more readable DATA statements. Since the character is ultimately not being used for the sake of the character itself in this case - it is being used for its numeric value. And so the Latin1 representation is ultimately meaningless, and a numeric representation, whether hex or decimal, would be more useful, in general.

Well, CALL CHAR uses a numeric value as its character value, so this does originate as a character with a value greater than 127 in the DATA statements from which the value and ensuing pattern string is read, but ends up as a numeric value as far as CALL CHAR is concerned. In any case, all instances of characters greater than 127 (of which there are a great many) are now being successfully read from source and written to disk as desired, so I'm happy. XBAS99.PY is having no trouble with lines like the following, with all the string .encode and .decode methods just using Latin1 by default (and my editor set to Latin1 likewise): 15 DATA "¹RLCONSPIRING¹SMTO DESCEND¸h821928C492462831i9146482184126289¹RNTO CONQUER¹SOIN THE ENDÁBBA¾!9B^!6DZ¸jB2096A92AC219A44k4299244242249942" 16 DATA "¾ =;¼>7ÁBBH¾^8B^^5DZ]7=G>UÁNBAGBH¹KIHELL@S HEART°I°G°F°C³D¸l914E5045A20A7289m924C419205649229n894658A4251A6291oB25C42D684749A01" I shall perhaps have to try the IDEA option, in the future. This project is so built around interpreted data (housed in DATA statements, as above), that conventional code editing tools aren't as useful as they might be, but perhaps when next I have a saner project on my hands.

Just wanted to say that XBAS99.py is making my life a whole lot easier, in my work on Hell's Heart (my next big TI BASIC project), right now. The tool is much appreciated, for its allowing me to get from plaintext source to tokenised code accessible to Classic99 in about 5 seconds flat. That having said, one issue I experienced is just that as written (at least on Windows and Python 3.11), it was necessary to change all the string conversion in XBAS99.PY to Latin1 rather than ASCII, as my program uses the full range of characters available to (i.e., which can be typed under) TI BASIC. Which is to say, 127-159 and 176-198 inclusive. Now, I grant the use of the latter is an oddball rarity (though extremely useful to me under present circumstances, as I need a fairly large number of tokens in a distinct range, separate from characters representing any printable graphic). However, the prior is probably a more typical necessity (given both Extended BASIC and Console BASIC can assign patterns to characters beyond the 7-bit ASCII range, and so read them in from DATA statements or DISPLAY AT the character sequence as a string literal). Anyway, for me, the fix was simply changing any use of the .encode or .decode methods to Latin1. i.e., s.encode(encoding='latin1') Thanks a lot for the tool. The best way to work on (while actively testing) a large TI BASIC or Extended BASIC program, it seems to me.

ere's a very early teaser for the next TI BASIC cassette project I've been working on - Hell's Heart. The teaser just being the in-progress (and doubtless substantially to be revised) intro sequence (and in the background, pattern/palette loading process). This game intends to use more or less the entire range of available patterns (32-159), so pattern loading (and the intro which serves as a distraction, whilst this occurs) is even longer than was the case for Hell's Halls, at present. 2023-01-07 04-19-52.mp4 Project criteria are very similar to Hell's Halls: - TI Console BASIC - Type-in compatible: nothing which can't be typed directly into the TI BASIC interactive mode prompt. Characters 127-159 are used (for graphics) and 176-198 are used (for interpreter tokens), as these can all be typed with 99/4A-specific control/function key combinations. I was quite tickled by the fact that at least one person actually typed in and ran the type-in version of Hell's Halls. So I will definitely repeat that exercise. - Cassette compatible: nothing which can't be loaded from cassette in a single load (I considered loading patterns 128-159 via one program, then the remainder in the main program, immediately following on the same tape, but ultimately dismissed this as too cumbersome a loading process). Differences vis-a-vis Hell's Halls are: - My subprogram for drawing screen graphics (via HCHAR and VCHAR of course, as this is TI BASIC) has been hugely improved, to allow for detailed, compact, relatively fast (in TI BASIC terms) drawing of graphical components. The subprogram uses a (like practically everything here, 8-bit tokenised) data structure supporting repetition of HCHAR or VCHAR commands at specified offsets either horizontally or vertically. Such that, for example, all the graphics in the "table and candles" scene in the title sequence are drawn using the following data string: *MHq,4><CV4<C;)KL(KL>VK?VV which specifies (aside from Y,X,CHAR) a horizontal offset of three with four recurrences for all of 1) the candle flames, 2) candlesticks and 3) candle bases, and a vertical repetition of two for each candlestick. Repetition, Recurrence and Offset arguments are all optional, and so do not add to the length of the command in bytes for those commands not using them. The presence of each of these optional arguments is flagged in a preceding byte (of otherwise unrelated purpose), two earlier in the sequence, so that the subprogram knows whether to expect another argument or a new command. - My sound subprogram has been greatly improved, by virtue of arriving at a satisfactory method for approximating the sequence of frequencies of notes on the chromatic scale via multiplication/division/addition/subtraction alone (crucially, given the speed of exponentiation in TI BASIC). So in a music data string the character "C" now represents the note following "B" which represents the note after "A" etc. - Optional support for allophone speech via TE2 (with restrictions, as part of the allophone range and various allophone speech control characters cannot be typed in TI BASIC). We'll have to see how useful and desirable this ends up being. In any case, use of TE2 will be optional. But including speech has a significant memory cost (mainly due to the file buffer it uses, rather than the speech itself), so unless it's really adding something, it's arguably better to skip it. - Pattern loading is now handled by the interpreter like everything else, so patterns can be inserted into any DATA statement to be loaded, which makes it easier to seamlessly mix pattern loading and other events. Development is currently ongoing, mainly using Classic99 and Ralph Benzinger's xdt99 TI-99 cross-development tools. Though I had to make certain modifications to the latter, mainly to permit the extensive use of non-ASCII (128-159 and 176-198) characters in my program source.

If you want to get really fancy, here is a TI BASIC ESDX movement input routine (i.e., for moving a single-tile character based on input from the ESDX keyboard keys) based on the method I use in Hell's Halls (which I've attempted to disentangle from all the surrounding program logic, since in practice, that program is handling a lot more than motion): 100 CALL KEY(1,K,Z) 110 IF (K>5)+(K=4)+(ABS(K)=1) THEN 100 120 YM=(K=5)-(K<1) 130 XM=(K=2)-(K=3) 140 CALL GCHAR(PY+YM,PX+XM,GC) 150 CALL HCHAR(PY,PX,CT) 160 PY=PY+YM 170 PX=PX+XM 180 CT=GC 190 CALL HCHAR(PY,PX,40+K) So, to summarise, 0,2,3 and 5 (the ESDX direction keys, via CALL KEY Key Unit 1) are valid inputs, as assigned to K, and these values are tested for (or rather, the absence of these values is tested for by exclusion), by the relevant conditional (Line 110), which, in the manner of so many TI BASIC conditionals, uses arithmetic operators as de facto logical operators. If valid input is given, positive or negative adjustments to the X and Y coordinates of the player (PX,PY) are then tested for (Lines 120,130), and assigned to YM and XM (one of which will now equal +1 or -1). Note that we cannot test for K=0, as the 0 returned by CALL KEY is aberrant, and non-equivalent to the constant 0 on the 99/4A (though notably, this bug is absent on the 99/4). Anyway, hence, (K<1). Now we need to know what tile exists in the square the player is trying to move into (a floor tile? a wall tile? An enemy?), and that will be acquired via CALL GCHAR (Line 140). That puts this character into the variable GC for further tests (in practice, a pair of ON GOSUBs which handle 20 or so possible tile values, not shown here). Now that we know what tile we're trying to walk towards let's assume that action is possible or whatever outcome can be handled. So we start by replacing the current player tile (stored in PY and PX) with the character which existed there before the player moved into it (Line 150). This 'current tile' is held in the variable CT at all times. The player coordinates can now be updated with the Y and X modifications implied by the input provided (Lines 160,170). As well, with the player coordinates changed, we can update the current tile value to the new one furnished by CALL GCHAR (Line 180), before overwriting it with the player. Finally, the player character itself can be drawn to the new tile at the new PY/PX coordinates (Line 190). One of the four "directional" representations of the player is selected from the pattern table automatically, as these are located at 40,42,43, and 45. And with the CALL HCHAR command drawing character 40+K, where K is the CALL KEY return value for Key Unit 1, this will equal either 0,2,3 or 5 and hence in sum 40,42,43 or 45.

On the other hand, from the way the Multicolor Mode thread has been the toast of the town recently, I'm getting the feeling that 64x48 might be everybody's New Years Resolution.

Using what emulator? The two options which would seem to suggest themselves being MAME (natively) or Classic99 (via the Steamdeck's WINE equivalent). It's not clear that Emudeck's scripts would actually do anything for you in this context other than install MAME (but without any of the files or configuration steps necessary to TI-99 use). Probably, getting MAME set up for TI-99 use on the Steamdeck will be as hands-on as MAME is anywhere else. And if Classic99 works under the Steamdeck's Windows compatibility layer, that might actually be preferable. You could also just use JS99er.net via a browser.

The new year is almost upon us. What do you want to spend your time on or what do you hope to accomplish in the coming year, where TI-99 and related computers are concerned? For example, for me: - Complete development on Hell's Heart, a sequel to Hell's Halls (also a console BASIC tape game). - Undertake some CC-40 development and get a solid handle on its version of TI BASIC. - Do a longish YouTube video covering the CC-40 in depth.

Ordered some CC-40 stuff from ArcadeShopper which I suppose is a bit of a Christmas gift to myself. Looking forward to doing some CC-40 development, when I get the time. On the flipside, shipped out a couple copies of Hell's Halls in recent times that folks had said they were ordering as a Christmas gift to themself.

Championship Baseball with manual and overlay in good condition for $40 is actually quite reasonable: https://www.ebay.com/itm/255894778765 Though I suppose nearly everyone on earth who has an MBX already has it.

Did a review of all 11 released games, with my personal ranking of the lot:

Jumping the gun a bit holiday-wise. But this is a really nice 1983/1984 "Auld Lang Syne" New Years program in TI BASIC (TIFILES format): AULD-LANG.zip What better way to ring in the New Year?

Most recently, I suppose, Personal Computing with the UCSD p-System Someone asked something about the p-System on one of my YouTube videos which was answered trivially enough, but it got me digging anyway, and revisiting a few of the key texts I had lying around in my p-System directory. But principally, this one.

Fantastic! It's so important for a must-have TI-99 upgrade like this to be available. Don't happen to need one myself at the moment, but I'm delighted on behalf of all the folks I won't have to tell that the F18A is one of the most important TI-99 hardware upgrades, and you (mostly) can't buy it. Though Arcadeshopper and Hans have been able to provide some supply in recent times.

Barrage Black Hole Hustle Jumpy / Q-Maze MASH Championship Baseball (but requires MBX Expansion System) Meteor Belt (MBX game but does not require MBX)

Pretty interesting TI-74 package here. Complete in box Mathematics and Statistics carts (and manuals) and TI-74 itself (with manuals and ROM/RAM cart): https://www.ebay.com/itm/385274537719?hash=item59b426e6f7:g:CY4AAOSwMFdjjVE5 Fairly high price, but a potentially compelling TI-74 starter set.

Yeesh. That is beautiful and wonderful and nuts. MSX developers from forever ago, always showing us how it ought to be done. How dare they.

One other very key piece of the puzzle would be a screen replacement mod. Since the great majority of units have missing pixel rows/columns. With a screen replacement solution, the CC-40 would have everything it needs to be properly enjoyed by as many people as own one.

Likewise. After all, in the same years when a bunch of you were driving to work at the height of the home computer boom, I was driving nowhere (but fast!) on my Tomy Turbo: But seriously, I think those things were rather exciting for about 20 seconds if you were the right age when they released (in 83 apparently). Then it became clear that they don't really *do* much of anything. Pretty exciting for those 20 seconds though.

Yeah, doubtless you've got to strain the sense of the word adjacent pretty far in this context, before you find yourself wandering outside the bounds of the Fetzner Collection.

There are various TI-99/4A-adjacent computers which attract interest here. Geneve, CC-40, Tomy Tutor, TI-74, TI-990, etc. What relative of the TI-99/4A that you haven't seriously delved into yet are you tempted to explore, these days? Either via original hardware, or emulation. Or is the TI-99/4A itself enough for you?

Note as well that in 80 column mode, pixels have an extremely stretched aspect ratio. I discuss my own methods surrounding working with T40XB and T80XB art in my video on developing for T40XB, T80XB, and TMLGA as a component to XB GEM. A key point being that GIMP is able to display pixels at arbitrary aspect ratios on non-square grids. So a grid of 6x8 tiles whose pixels are twice as tall as they are wide can be worked with there. This is quite necessary, since it would not be realistically possible to design graphics for T80XB directly in Magellan, for example. Since what you would need to design is the tiles on the right here, in order to achieve the tiles on the left: So that's how I made the graphics for my "Still TI" voice synth singing demo, for example. In GIMP, with 6x8 tiles and a 1:2 pixel aspect ratio.