pixelpedant

For anyone who subsequently finds themself coming to this thread still looking for a copy, I have added a "Notify me when back in stock" option to the product page, which will provide for immediate notification of new supply. But perhaps even more importantly from my point of view, it will give me a sense of how many people still want a copy, so I know what to prepare for.

I am now sold out of the original batch of 18 as well as 2 more I made last night. Fittingly, the last of those 20 went to Adamantyr - who better than the king of the TI RPG himself? Since demand has been significant and orders have now been placed and games packed for a few key people I wanted to be sure got a chance to order one, I'll do a final review of what I have and how many more I can make with it (probably 2 or 3) and put those up at some point soon. It looks like the tape and tape packaging supplier I worked with on this little run could potentially support another run at some point, but that's merely hypothetical at this point.

I really should go to the trouble at some point, but honestly, I just use VB syntax highlighting. It gets things mostly right I'm so used to the highlighting this approach results in at this point that any change to it would probably just drive me up the wall. So I'll probably just stick with it as is. But it's pretty good generally. e.g. (as seen in that video)

Classic99 and Notepad++ mostly. So a bit of a middle ground. In that I wrote it mainly just by typing it into a text editor and designed the overall program's control flow and logic mainly just by remembering line numbers (of subprogram entry points and DATA statement locations), and by keeping lists of DATA and Subprogram line numbers in separate documents during development. I also managed the difficult problem of mutual interference of subprogram variable values (i.e., if the game is six GOSUBs deep, as it often is, is it "safe" to use an "X" variable in a given subprogram?) by keeping track of "local" variables to each subprogram and "global" variables which should never be used for subprogram-specific purposes. So most of that strategy is all stuff you could do on a piece of paper back in the day. Which I would prefer it to be. I didn't want to use any tools which generate code for me. And the program's line number sequence is kind of bonkers because this approach made use of RES impossible. By RESequencing it, I'd lose almost everything relevant to navigation and use and reading of the program code. And lines like this would now be meaningless gobbledigook, instead of mostly meaningful to me: 1310 ON 339/GC GOTO 1100,1100,1450,1460,1400,1100,1500,1400,1430,1650 So my most invaluable tool during development was really just "making lists", which is pretty era-agnostic stuff. Simple stuff like this: Low Number GC Values 1=1450 - Additional high number values 2=1460 - Wildcard Tile 3=1400 - Damaged Tile (behaves exactly like floor) 4=1100 - NOTHING 5=1500 - CLOSED V/H DOOR 6=1400 - OPEN V/H DOOR 7=1430 - WALLS 8=1650 - STAIRS High number GC values 1=2600 - Explosive Tile (R) 2-1100 - Nothing 3=2600 - Explosive Tile (B) 4=1400 - Floor 5=2730 - Healing 6=2700 - Gold Though modern spreadsheets were very helpful in working out some of the more complicated math.

Yeah, I started with a bulk cassette copier, but testing the results, the failure rate was unacceptably high. Also tried PC line out (playing the WAV file) to cassette recorder. Also seemed too finicky. In the end, I've ended up doing them all with a Program Recorder and TI-99, which, while time-consuming, basically always *just works* for non-faulty tapes.

Thanks for your orders everyone! I'll work on getting the first batch of orders shipped today. Down to 8 left now, of this batch I've made, so it looks like they will in fact probably sell out in fairly short order.

Clever idea. God knows, we need all the help we can get, when it comes to making this medium reliable, despite everything arrayed against it.

We'll just have to see But I do think it can grow, and I've got my eyes on where to go from here with some of the things I cooked up for this one, absolutely. After a break from putting so much work into this project in recent months. The main thing that took a long time to cook up, but is a really tempting tool for any subsequent project is just the bytecode I've used to encode nearly all the CALL HCHAR/VCHAR/SOUND/COLOR data the program uses. So for example, this DATA statement is several HCHAR/VCHAR commands interleaved with 21 CALL SOUNDs (in groups of 3), and a CALL COLOR: 9600 DATA "ABB}JA~'DA`}J7~'RA`}J>~'TKL}J4~'VJN}J7~'XIP}J'~'EL3}J7~'EU3" With tokens within the DATA statement identifying data types for the purpose of an "interpreter", and passing control to relevant subprograms for the ensuing data accordingly. It allows for quite compact music and scene graphics, and positioning of text. And it's very likely I would reuse this strategy and encoding in subsequent projects, consequently. Since in 16K TI BASIC programs, "compact" is everything.

I've gone silent about my TI BASIC 16K cassette game project Hell's Halls lately for the most part here. But it's for the best of reasons. Namely, that I've been too busy working on it. And in the end, I'm really happy with the outcome, and really do think it's a great demonstration of what a TI-99/4A can do with only the console's ROM BASIC and cassette. A sampling of the game is here: So to recapitulate, Hell's Halls is a dungeon adventure written in TI BASIC for the unexpanded TI-99/4 and 99/4A featuring pseudo-random dungeon generation and some use of scene graphics and story text. It uses ESDX control for dungeon navigation and combat. I wanted to make the best game which in principle I could have written back in the day, using only the TI-99 console and Program Recorder. That is to say, using only what can be directly typed in via TI BASIC and saved to cassette. And the good news is, I've finally gotten the game to a release stage. Or rather, I've gotten two versions of it to a release stage, one of which I call the Main Quest and one of which I call the Second Quest. Ultimately, these are meant to complement each other and have slightly different priorities, and also to conveniently occupy two sides of the game cassette. And that last part is genuinely a major motivation for me. Because I've been all in on this project and intent on making it one of the most ambitious TI BASIC cassette games out there. And it couldn't be any of that if it didn't have proper physical materials. Hence my doing up a small batch of them on cassette, in cases with the look that I want for the game, and accompanied by the supporting materials it deserves. I have absolutely no idea how many people are actually interested in a branded and packaged 16K TI BASIC cassette game in the year 2022. We'll just have to see. But regardless, putting these together is fairly time-consuming, so I'm just doing a small run of about 20 game packages (as I lack materials for more, right now), and posting here first, so folks around here get a crack at it before I take it to YouTube or Twitter. Technical Considerations: The game (in either of its two variants) does not require the total absence of VDP buffers associated with a disk controller. It does require that CALL FILES(1) be used, however, in the customary manner. Recording length is about 2m40s in both cases, but the tapes are 5m per side so as to minimize rewind time when changing sides. Use of Extended BASIC is not recommended, as the game has been heavily optimized around TI BASIC timings and performance idiosyncrasies. And compiling will not be possible, due to extensive use (and abuse) of floating point math. But Can I Play It? Like Now? Yes. I am releasing the main quest here. The game package with the second game variant (which features different and more randomized quest text and scenes) I'm releasing with the physical release (on Side B, with the Main Quest on Side A). But here is the main quest: https://pixelpedant.com/HALLS-MAIN.wav And How Can I Buy It? The very small batch of 20 or so that I've mostly now finished is currently available here: https://shop.pixelpedant.com/products/hells-halls-for-ti-99-4a Items will ship from Canada, where I am located, and should ship fairly quickly, as most of the materials are ready to go, as I say: If you strongly prefer US domestic ordering, ordering via ArcadeShopper will likely be an option shortly, as long as they don't just sell out, and I actually have stock to send him.

Just to be clear, the Mark III *is* the Master System. Just the original Japanese release of it. And subsequently, even Japan got a Master System branded release resembling the one more familiar in the West. Anyway, the Mark III contains an SN76489 clone, just like the North American Master System (and Game Gear). The Mark III did get an FM chip via add-on peripheral, and this was built in to the final Japanese Master System model. But the Mark III/Master System Space Harrier releases (which are identical to one another) don't use it. Space Harrier 3-D does (it has both PSG and FM soundtracks). But actually, I kind of slightly prefer the PSG soundtrack. Maybe I'm just biased, as far as that goes. But it really is a very good PSG soundtrack.

Making sprites more than one colour on the TI-99 (under any circumstance, TML or otherwise) is achieved by stacking multiple sprites. Any individual sprite can only be one colour. Giving a sprite the appearance of containing more than one colour can also be achieved by modifying background tiles in real time in tandem with sprite motion, but this usually won't be practical in a high level interpreted language. Among high-level interpreted languages, Logo and TML make sprite stacking more practical by providing the means to control sprite movement in groups (rather than individually and sequentially). See my discussion and demonstration of sprite stacking, at this point in this video here:

Well, books you won't find, but the TML manual is very comprehensive, as are all Harry's manuals: https://pixelpedant.com/items/show/309 The TML 2.0 disk can be found here (but TML is also included in XB GEM) https://pixelpedant.com/dsk/The MissingLink2.DSK Who's Behind the Mexican UFOs is the most complete game product which runs via The Missing Link: https://pixelpedant.com/dsk/Mexico.zip And its manual is here: https://pixelpedant.com/items/show/332 And I did this video on The Missing Link:

With no carts or other expansion hardware, the only way to test the speech module in any way shape or form would be to write a tiny scratchpad program (residing in available areas of the 256 byte of CPU RAM) and do something very rudimentary there. This would be a relatively technical exercise. Unlike Extended BASIC, TI BASIC (the one built in to the console) provides no inbuilt support for loading machine language programs, and so abuse of an exploit is required to load code via Console BASIC and cassette, and writing such a program would require a good understanding of the hardware. That having said, there are *tonnes* of speech carts, and most of them are dirt cheap. So this isn't a question I've ever run into before. With any given handful of worthless, very common TI-99 carts (education carts and such), you've usually got a couple that use speech.

Well, I suppose I shouldn't say there is no performance overhead, but in the practical context and scale of BASIC timing with which I'm concerned, it's never been a substantive one in my testing. I was curious nonetheless to dig deeper, so I just did a long enough test to see a difference (20,000 loops), and the difference between Z=1 Q=0 and Z=1::Q=0 was 0.3ms, in that test. So while that's something, it still falls below my threshold of interest, in a language where a PRINT X takes 90ms. But just because I don't care doesn't mean it isn't there!

Indeed, the author of the software writes excellent documentation. So the advice to read it as a complete reference on the package and dialect is well founded. It will genuinely tell you everything you need to know. It won't teach you to write TI BASIC or teach you how a TI-99 works. But it'll take you from there to using the package pretty comprehensively. In practice, XB256 is almost inherently used to write compiled Extended BASIC programs. In principle, you could use it as a regular interpreted dialect with no intention of compiling, but as far as I can tell, just about nobody other than me has, given the incredible appeal of seeing your program's execution speed hugely increased with pretty much no work at all (and no additional knowledge required), by compiling. I have done an in-depth video on the use of XB256 (and the XB Game Developer's Package) as a compiled BASIC here:

But yeah, minimising line count is a benefit in TI BASIC and XB, if you're doing everything you can to save every byte. Not where performance is concerned though. There is no performance advantage in putting multiple statements on a line in XB. Only a program memory footprint advantage. And honestly, the difference between 10 PRINT 20 PRINT And 10 PRINT::PRINT Is five bytes. So while there is in principle a memory savings there, one is compelled to ask whether those five bytes are actually the difference between whatever given XB program executing or exceeding program memory limitations. In a world where 99 out of 100 XB programs do not use all the memory available to them. And also, one is compelled to ask whether any strategy for reducing line count involves basically *any* additional code complexity at all. Because if it does, you might actually end up consuming more memory in fewer lines. Meaning nothing is achieved by the exercise.

There is a tiny performance cost to using a variable rather than a constant in an IF comparison. But it is truly tiny. Under a millisecond. However, the speed of a comparison involving a constant is proportional to its length. So while X=0 is faster than X=W (where W is undefined), X=999.9999 is slower than X=W, where W=999.9999. And yeah, _ and \ and @ and [ (among other things) are legit variables (if you want them to be) in good old TI BASIC and Extended BASIC. As a consequence of which, this is a functioning Extended BASIC program I wrote a while back, just to be perverse: 5 ON WARNING NEXT 10 ]\]=[/[ 15 [=[-]=] 20 DEF ]\(_)=(_)/[ 21 CALL CLEAR::ON ERROR 81::CALL SOUND(]\(),[\],]\],]\]) 22 CALL ERR([\,[\],[\],\]) 23 CALL HCHAR(]\([\])/[--[\],]\([\])/[--[\],\]-[\)::ON ERROR 22::PRINT::RETURN NEXT 81 ON ERROR 22 82 CALL SOUND(]\(),[\],]\],]\]) 119 CALL SOUND(]\(),[\],]\],]\]) 128 CALL SOUND(]\(),[\],]\],]\]) 130 CALL SOUND(]\(),[\],]\],]\]) 135 CALL SOUND(]\(),[\],]\],]\]) 139 CALL SOUND([-],[/[,[/[,]) 141 CALL SOUND([-],[/[,[/[,]) 147 CALL SOUND([-],[/[,[/[,]) 180 CALL SOUND([-],[/[,[/[,]) 188 CALL SOUND([-],[/[,[/[,]) 190 CALL SOUND([-],[/[,[/[,]) Which prints the following text. While containing no numeric or string constants, and no alphanumeric variables.

Following up on this somewhat belatedly - I can certainly see the appeal of this from a practical standpoint. But in the end, I think I went into this wanting to overcome (or at least hide) the slowness of TI BASIC by any means necessary (like loading the great majority of characters in small pauses in between animations and text during the title sequence). So I feel like making startup more cumbersome would be unfortunate in that context. Mind you, I'm already succumbing in various respects to a willingness to make things slower/cludgier in the name of memory economy (mainly, storing all sound and nearly all HCHAR/VCHAR data in strings, which is inherently slower, but not painfully so). So who knows where I'll succumb next. Heck, in a recent desperation move, all instances of =0 or >0 or <0 in my program have been replaced with =W and >W and <W. Where W is a variable that does not exist. That, while some hideous nonsense, saved me 40 bytes in numeric constant tokens.

In a perfect world, as I say, one would calculate the frequencies of notes on the chromatic scale (for the purpose of storing musical "note" values packed into strings then feeding them to CALL SOUND) via the actual formula for calculating these frequencies. But that formula happens to involve a fractional exponent. And TI BASIC is brutally slow at handling fractional exponents. So I ended up improving on my original approach while not doing that (and satisfying performance requirements) by just coming up with a simple arithmetic expression (handled quickly enough by TI BASIC) which results in frequencies diverging (based on input character value) at a rate roughly satisfactory to the range of musical frequencies I'm dealing with. Which happened to be (where A is the ASCII value of a character) A*A*A/14400+25 Such that ASC("I")=73 and 73*73*73/14400+25 = 52 (Hz) whereas G#1 = 51.91Hz such that "I" = (roughly) G#1. Fun fact: A*A*A is much, much faster than A^3 in TI BASIC. So for printable character input values of 32, 33, 34, etc. this results in apparent frequencies from 27.28Hz to 163.915Hz. That's five octaves, which is way more than enough. Possibly an even more compressed "scale" would be desirable. This frequency is itself really just a reference point though. It isn't directly used by CALL SOUND. It's used to derive the tone generator 3 frequency required to generate periodic noise at that frequency, and the overtones desirable in that context. No tone generator is actually set to that frequency.

Updated intro sequence and startup for the latest version of Hell's Halls. Much that is changed is obviously "behind the scenes" stuff to make things more extensible and reusable to develop more content within memory limitations, but there are also fairly obvious changes you'll notice. Sound design especially (and the way it's stored) is completely revamped. Principally in order to sound much more sinister. 2022-06-28 13-49-23.mp4

Indeed. You don't get this kind of thing from a modern computer: 2022-03-17 12-40-18.mp4 Though that's XB.

I have poked away at Ken Gilliland's disks, indeed. And though those are XB programs with consequently very different capabilities from those available under TI BASIC, I suppose somewhat along those lines, one thing I'm considering at present is in fact after completing the cassette version, doing a disk version which exploits the potential to load comparatively gigantic amounts of pattern/palette/music/text data on demand. Even in an SSSD context, if I were to stick with legacy TI spec, which I likely would, 90K is leagues ahead of the 3K or so of DATA statements I can reasonably make room for in my present cassette program. But time-wise, 90% of the work on this and 90% of the fun of the exercise, especially through its last month, has been figuring out ways to cram the program and its data into 11K in ways that are sufficiently performant under TI BASIC (and compatible with its limited toolset). So I do not for a moment regret that aspect of the exercise and the way it is imposed by the medium. Cramming a complex game (and its subroutines and data) into ever smaller spaces has very much been the joy (and most of the time investment) of this business, for me. But as for places to go subsequently, another possibility encouraged by a disk version would be integration of support for TEII speech and sound. I just don't have the space for the data or supporting subroutines in the current program. But being able to load any speech data from disk would make it viable. On the other hand (and because it will always be the most obvious upgrade), I don't think an XB version would make sense. The program is (and its current army of subroutines are) at this point far too hugely focused on figuring out ways to make interesting things happen with CALL HCHAR, CALL VCHAR, and CALL COLOR while compressing the arguments for those commands to strings. Once DISPLAY AT and real sprites enter the picture, one might as well just throw out the whole thing and start over. Because giant strings of CALL HCHAR/VCHAR/COLOR/SOUND argument data aren't a good way to accomplish anything, in that context. And it would not be easy to translate the current program data back into a saner format. Just for example, these are the last lines of the program as currently written: 9500 DATA "A.,'%'''%'","HBBABB","A@$ $","B@!]# !]#","C@% $ %","E@\\\\\" 9510 DATA "AOBHGB","A..","H@AND SO IN DEATH","A))","L@IT IS YOUR FATE","A''" 9515 DATA "P@TO HAUNT MY HALLS","A%%","T@NOW AND FOREVER","A''","W@**<<<++" Aside from the odd bit of text, most of the data isn't human-readable discrete values anymore, so it's just not very portable.

The more I experiment with TMS9919 sound, the more I think it's entirely possible to do really worthwhile things with it, even without making sample-based audio happen in software, and the biggest impediment is just that, to get a nice, rich instrumental sound using any of the popular advanced techniques, you've got to devote at least two but often three tone generators to the purpose, and if you want bass notes, you've got to dedicate both your only noise generator and at least one tone generator (but preferably all three) to the purpose (one silently furnishing the noise frequency, one or preferably two handling overtones). Which is severely constraining, less so in terms of what sounds are possible than in terms of how many of them you can make at once (i.e., often just one). For all these reasons, I really like the basic idea behind the ForTI card. Because I really do think simply having *more TMS9919s* opens up an array of possibilities that aren't there, with only one. It's no surprise a number of arcade machines used multiple SN76489s. And happily for us, chips in the SN76489 family are a dime a dozen. Turning a TMS9919/SN76489 into various kinds of appealing single-voice instrument is very viable and fairly easy. But one such voice doesn't really cut it. So it'd be great to have more.

I congratulate you on your self-control. I've been trying to show some myself, lately, when it comes to TI purchases. Looks like someone else didn't have quite as much restraint as far as that MBX goes, as it appears now to have sold.

Reasonable price for a CIB good condition MBX, as such things go: https://www.ebay.com/itm/275360266765?hash=item401cc03a0d:g:oLcAAOSwouNitKQx