pixelpedant

There's a CADD version of the XBII+ manual kicking around though, which is in fact the Mechatronic XBII+ English manual. That being said, a scan of the German manual is very nice to have. Partly because it's a scan per se (unlike the CADD version, which is almost exclusively digital text), and partly because it's the German version.

Awesome stuff, Steve! XBII+ really does seem like one of the most interesting flavours of XB.

There's only so much that can be said for the second best pinball-style game of the 99/4 era (the best in said category being the Pinball game in Video Games 1, in my opinion). Video Games 1 Pinball is actually sort of fun.

If I recall correctly, it was effectively an in-joke. "Polyoptics" was one of the names initially proposed, but as far as that choice of branding goes, they ended up being able to conclude on nothing save that "Polyoptics" was out of the question. So they ended up with "Not Polyoptics". Found a citation to that effect, in a Chicago Newsletter:

Awesome. Thanks for the scan, Jim! I've paginated/rotated/cropped/retouched/OCRed the manual as follows, and of course uploaded to my manuals site: Cosmopoloy - Not Polyoptics - OCR.pdf

While this is a worthwhile observation for certain niche situations (where one previously used CALL key via Key Unit 0, but now want to treat the value in a case-insensitive manner), I guess I don't really understand why one would use Key Unit 0 - an explicitly case-sensitive key scan - for ESDX input, if one specifically desires a case-insensitive key scan (which is otherwise also available). Key Unit 1 will just ignore the state of the caps lock key with no actual work. And another nice thing about Key Unit 1 is that it returns values from 0-6 for keys in the ESDX area (e.g., the WASD keys return 1,2,3,4 while ESDX returns 0,2,3,5) rather than ASCII values (WASD returns 87,65,83,68 while ESDX returns 69,83,68,88). So even case aside these tend to be much more directly useful in their unmodified state (for selecting array values, screen locations, ON GOSUB destinations, etc.)

In this case, I was doing everything to minimise the data payload of the program, so this sort of approach was very desirable. The prepended bytes are of course two bytes, while appending two numeric strings as follows... DATA 10,1,"WRITE THIS AT 10,1" Is going to be seven bytes (unquoted string, length, 1, 0, unquoted string, length, 1), if I've got my tokenisation math right. And those extra bytes every time you write any text to screen are really going to start to add up, in a program which is writing text a great deal.

There are *lots* of TI BASIC subprograms to this effect out there. Since almost every complex TI BASIC program contains one. Here's a working example from an early version of Hell's Halls 1, which I've tried to disentangle from program-specific features. I tried simplifying the one from Hell's Halls 2, but there's no disentangling it from the program's internal interpreter to such an extent as to make it independently useful. The essential strategy here being to prefix any text string with two bytes signifying Y and X positions for the DISPLAY AT, which are treated as possessing their ASCII value - 64 (and hence, A=1, B=2, etc.) Such that "JAWRITE THIS AT 10,1" writes "WRITE THIS AT 10,1" at J=10 (Y) and A=1 (X). Note that N$ can be read from DATA if GOSUB 5000 is used, or read from N$ directly (where a value has been assigned to it prior to the GOSUB) if GOSUB 5005 is used. 1000 DATA "JAWRITE THIS AT 10,1" 1010 CALL CLEAR 1020 GOSUB 5000 1030 END REM DISPLAY AT sub REM DATA STRUCTURE: Y,X,TEXT... 5000 READ N$ REM Pop value from N$ and fetch Y pos as I 5005 GOSUB 7260 5010 Y=I REM Pop X pos 5015 GOSUB 7260 5025 FOR X=W TO LEN(N$)-1 REM Pop character values off string as unmodified value 5050 GOSUB 7385 5055 CALL HCHAR(Y,I+X,A) 5060 NEXT X 5065 RETURN REM SUB: Pop first value off N$ and return A-64 7260 GOSUB 7385 7265 I=A-64 7270 RETURN REM SUB: Put ASC in A and pop first value off N$ 7385 A=ASC(N$) REM Entry point for only popping first value, and not assigning I 7390 N$=SEG$(N$,2,LEN(N$)-1) 7395 RETURN

Yeah, I've never experienced this kind of corruption with either Hell's Halls or its sequel, and in both cases, I'd have Classic99 left running for literally a month without corruption. With versions of Classic99 dating back a couple years, all the way up to today. Especially in the case of Hell's Halls, I was (while using all available memory) pushing nearly all updates by just pasting modified lines into Classic99. But this issue never arose. That's not really the case with the sequel though. There, I need to tokenise externally and reload the program nearly every time I update, as the program uses all characters which can be typed on the TI-99 (including all non-printable characters which may still be typed). And a large subset of those (like 176-198, all of which a TI-99 can type) have no ASCII representation. So they can't just be pasted into Classic99.

Well here's something that was of interest to me from a recent auction, as I had not seen it before. German TI Writer keyboard strip:

Indeed, would be nice if those had something to share, and it were shared. That having said, even if they were TI's own wafertape programs, most of their named wafertape software titles are pretty dry stuff of course:

One other option if you get desperate and you've got a fair number of custom patterns taking up space in your program is you can load your custom patterns into the range from 128 to 159 (which is never reset by BASIC itself) with one program (either on the other side or preceding the main program on the same one), then load and run the main program after. This gives you 32 custom patterns which cost you exactly zero program memory.

Nice. TI BASIC really wanted for more strategy/tactical/turn-based games. Given it can do lovely graphics and complex math and data structures. Just not quickly. I look forward to seeing more.

I and my wife have some friends who are devout in a way we are not, and whom we tend to celebrate a lot of the holidays with (as they see wrangling their lazier friends for such occasions as kind of a mitzvah). This program will provide a delightful excuse for me to engage in my irritating habit of bringing up all things TI-99 at every opportunity, next time we're over at their place for Shabbat.

The way I figure, they just designed around a 4x10 matrix, and added in the supplemental spacebar at the bottom, as a quality-of-life feature. That would have been a very early addition, though. The Dimension 1 and Dimension 4 prototypes (and even the concept art preceding them) have the space bar, in all the examples I've seen. So that's all in the early design stage. As to the Space key in the third row, one reason for there to be a space key in the main 4x10 matrix is that a design idea which seemingly figured into the Dimension N units was the wireless joysticks reduplicating that matrix across two 20 key keypads: You can see that notion of the "remotes" as secondary wireless keyboard represented even better here: All of that becomes moot of course, as in the end, IR is dropped, and the wired remotes are just joysticks. But for the original design to work, it's necessary that there be a space key in the 4x10 matrix.

So having reminded myself and tested, this is indeed the correct means of opening then playing the INT/FIX 255 files output by the synth editor, in this case for a file called "PLNO" located on DSK1: 10 OPEN #1:"DSK1.PLNO",INTERNAL,INPUT,FIXED 255 20 INPUT #1:WRD$ 30 CALL SAY(,WRD$) Note that quotation marks are not required to provide for an initial empty argument for CALL SAY. A comma is fine. With the output (of the mashed up speech) in this case being: 2023-04-07 19-48-51.mp4

I'll have to take a look at my files and get you those details. I used it as recently as about six months ago or thereabouts, to throw together some samples. I'll just have to refresh my memory, as regards how that worked.

One thing that makes it difficult to canonically list cassette games is simply that nearly all cassette games were also distributed on disk at some point, and many disk games were also distributed on cassette. So for example, TI Trek was originally distributed on disk by TI, but almost nobody played the original first-party TI-branded disk version (which is extremely rare). And nearly everyone played later versions (often distributed on cassette). But that having said, one can conclusively identify a category of "cassette-compatible programs", nearly all of which are BASIC programs, and most of which are console BASIC programs (rather than XB). With these being programs that can unequivocally be run from cassette, but will admittedly and inevitably have also and often been distributed on disk. I did a video a while back on the best 1980s era TI BASIC cassette and type-in games. And an archive of all TI BASIC cassette and type-in games discussed there is linked here (and in the description of the video). For outside vendors who principally created cassette games, see Not Polyoptics and ASD&D as examples. See also, as a phenomenal collection of mainly cassette games (nowadays distributed on disk for convenience), the TI BASIC Games listing at TI Game Shelf. Note that while a cassette game need not be a TI BASIC game, the number of assembly games designed to load from cassette is vanishingly small. As the population of users who did have the 32K memory upgrade and a Loading solution, but did not have a disk drive was not really a niche which ever existed.

Oh, and mdude put a tested/working Hexbus Printer 80 up for bidding (not buy it now): https://www.ebay.com/itm/225515335671 Too rich for my blood, and anyway, I don't really have any use for it, if I'm being honest. But a tempting opportunity for some.

A fun quote from the author, posted on a video I did about TI Runner, a while back: Manuals of Interest: - Star Runner (Databiotics cart version) - TI Runner Level Editor - TI Runner

Yep, the HexTIr gives you cheap disk storage and RS-232 that follows TI's standards on their hexbus implementation as closely as one could hope for. More on that here.

Mike Dudek put up a couple more in-box, tested and fully working (no screen defects) CC-40s. One 6K unit and one 18K unit. Fairly expensive, but these don't come around every day.

Yeah, E/A didn't hit store shelves (i.e., achieve general commercial distribution) until Spring '82, though that having said, I know they had it on hand and functioning at Winter CES '82 (so January). And if I recall correctly, the Pittsburgh UG (and maybe a couple other UGs - I don't have my notes handy right now) got a prototype demo in Fall 81. Both Extended BASIC and Editor/Assembler had very lengthy "debuts", to the extent that it was a long time between their first being demonstrated to the TI faithful, and their reaching large-scale production and widespread commercial distribution.

Nice. I've found Inufuto's simpler platformers to be my favourites (though Aerial is also great). So another is very much invited.

I did not actually assemble code. I can corroborate Vorticon's observation, however, that there's some weird and inconsistent (with documentation) behaviour on the part of the ALDS environment, in my case as well. Namely, scrolling sequentially through lines of entered code in the line editor does not succeed as documented (but produces an "Invalid line number" error), and any line which is displayed using the E/EDIT or LIST command will display 00000 as its line number, regardless of line. The code is evidently being stored successfully (i.e., "E 3" or "E 00003" will correctly retrieve the third line as entered). But lines will always be displayed as 00000 {some code} and as a result, editing with the E/EDIT command cannot occur unless the line number is manually corrected in any given case.