Something I did on my dungeon crawl I was making to save memory was byte packing. I created string functions to give me bit access in TI Basic. Using 4 bits I could store all 16 possible door option that define a room have 4 more bits in the byte to store room info like bit 5 "does room have a monster yes or no", bit 6 "does room have treasure yes or no", bit 7 "does room have stairs yes or no". This was so helpful for storing info about rooms and about monsters. You can store all the dungeon info in for a 6x6 room dungeon in 36 bytes of info this way. I could store monster info the same way, bit 1 alive dead, bit 2 has treasure, bit 3 is posionous, bit 4 can freeze, bit 5 can burn you, ect.
It's funny because it's true. BASIC is supposed to an easy programming language but in order to efficiently program TI BASIC you end up with a wall of hieroglyphics. Haha. I like how TI BASIC converts Space Invaders and Donkey Kong into turn-based gaming. Realistically you can only have two things moving at one time at most and maintain any level of action. Your game looks great, far superior than anything I ever produced back in the day (83 to 87).
That sound of the TI 99/4A data loading from the cassette still gives me goose bumps. The anticipation and thrill of seeing "DATA OK" at the end of a long program. 🙂 Or the agony of defeat when you saw ERROR IN DATA or NO DATA FOUND
My cassette has given me nothing but NO DATA FOUND on ALL my tapes, since the last time I plugged in the MBX. Every now and then I am reminded why a retro-tech hobby is not ideal for folks with under-developed electronics skills or those of us who are risk-adverse to recapping and soldering. But we don't pick the things we love. I just need a Pixel Pedant type friend living next door so he can deal with rouble shooting and I can have all the fun...
@@PeBoVision lol. agree on that last sentence. Back in the 1980s I knew just barely enough about TI 994/A to be dangerous, and I've since forgotten all of it 😆 One thing you could try is using audacity, or some other computer audio-recording software to record those old TI 99/4A data tapes. After they are stored in audacity, you can "tweak" the audio (equalizing it, amplifying it, noise reduction etc). It may just allow you to get those old programs loaded.
This was my first computer at 10 years old. It’s crazy how something you didn’t know at the time could guide your life. I learned to type on it. By the time I was 13 years old I was typing 80 wpm. By the time I hit 9th grade, I was typing 100 wpm with no mistakes. We could take typing as an elective in high school and basically the first day we had a competence test and the teacher said “you type faster than anyone at this age I’ve ever seen”. She then let me teach the fundamentals of typing on my second day of class and gave me an A+ for the semester right then and there. Since then I’ve worked for companies such as Boeing, NASA, etc. I owe it all to this machine and the inventors of basic that taught me logic and programmatic thinking. I still own it by the way. I will never sell it. It made my life aspirations and life goals come true.
I got a TI99/4A in 1984 because it was being sold with big discount, this was the only computer I could afford and I did not know anything about computer. After a couple of months of learning and programming in basic, I became frustrated at Texas Instruments because their basic did not provide for PEEK/POKE to program and run machine code. I was pretty jealous of my friends with C64 and Oric as result; Sold it about 1 year later to buy the then newly released Amstrad CPC. I m still pretty nostalgic of my TI99 thought.
Excellent sir! You should take a look at my favourite, "Commando" which was one of the games in the Collins Gameswriters pack. It came with a book and a cassette. I should say that I'm a member of TI-99/4A User Group UK. I've shared a couple of your videos with our Facebook group. Keep up the amazing work 🙂 (P.S. brilliant music, reminds me of "The Shining")
The tangle of GOSUBs at the beginning is how business applications were written in BASIC in the 70s. Business minicomputers, the usual hosts for business apps written in BASIC, had a bit more memory than the TI-99/4A, but not much -- and the applications themselves could grow even more complex than your game and even need to support multiple users. A mid-70s 64k minicomputer coukd support eight simultaneous users, run several tasks at once, and run all the financials for a small to medium size business -- in part because the BASIC programmers of the day ruthlessly optimized their code. I'm working on a game for a computer that has been... ill served by graphical games during its lifespan. It's capable of graphics, but not particularly dynamic or fast ones, so I too concluded that a dungeon crawler would be a good choice. I've been further inspired by Hell's Halls to complete this game.
Nice! You don't need much in the way of graphics to make a good dungeon crawl after all. Nice to have if you've got them, but ASCII/PETSCI/ANSI will absolutely do in a pinch, or the Roguelike would never have become the phenomenon it did.
I’m very excited about your game. I think it’s so awesome that we have home brew games. Also I think it’s really really nice that you used stock hardware.
It's easy to run out of memory even with the memory expansion. I'm in the middle of creating a tile based adventure for the TI in XB and even using the memory expansion I have had to make many compromises to make this game close to the quality I want. The game consists of a world made up of 4 levels each consisting of 40 individual tile screens. The screens themselves consist of a play field and a HUD which keeps track of health, gold, equipment and inventory. The HUD is fairly static during game play, updating only when new items are picked up, used, discarded or when health is effected. All the tile definitions and sound and music is first loaded from a separate program. That program then loads the first level program. The first level program and subsequent levels use the definitions defined in the first (graphics) program that was loaded. The play field is smaller than the display area of the normal TI display - it's 22x24 vs the TI 24x32. The rest of the TI display is used for the HUD. I was able to reduce the amount of data needed to draw each screen by using a fairly small but variable size data format that represents each play field. The format is as follows: monster type code monster count base map character code (fills play field) Treasure type code Treasure x LOC Treasure y LOC (Following can repeat and is used for drawing objects on playfield) Special tile code Special tile X LOC Special tile y loc Special tile height Special tile width (-1 terminates the display field data, otherwise additional special characters are read in). So a typical line to define a display screen might look like this: 4310 DATA 3,3,4,199,8,18,24,2,2,22,2,-1 This data would draw a field of grass with a stream running the width of the display at the top of the display. There are 3 snakes for this field and the treasure is a helmet located at 8,18. One thing I had to do is make the graphics and each level load as a new program from disk. This allows me to use the full amount of memory for each level of the game. This probably wouldn't work (at least not easily) for a game on casette.
Hell's Walls? More like HELL YEAH!! If only my 9 year old self with my trusty TI and my TI tape recorder could have made this game!!! Can't wait to play!
I only had basic and cassette when I got my TI99/4a in the mid/late 1980s. I did get Extended Basic in the late 1980s but I did not know its full power. Thanks for doing basic and cassette:)
I was learning basic on a TI99/4A at the same time I was learning Basic on TRS-80 Model III in High School. Always found it interesting why Texas Instruments used phrases like "incorrect statement" rather than "syntax error" or other phrases like " can't do that".
Much of the language that deviates from Microsoft BASIC norms most people were used to by the 80s come down to TI's deriving most of its BASIC conventions from its minicomputer BASICs, which derived their conventions from Dartmouth BASIC and its operating environment. Absolutely nobody else in the 80s home microcomputer sphere went the Dartmouth BASIC/ANSI BASIC route as far as I know. So it definitely makes TI BASIC's conventions a tad odd, in a lot of places.
Wow. You really went to town on this topic! Good going. Lots of interesting information there. I do miss basic programming. Thats not why you turn on a PC anymore. The TI-99/4a was such a great machine to learn on... and you're showing that there's still lots to discover. Thanks!
What a great explanation of how basic works. This helped me understand memory management and why everyone codes with abbreviated values and tags. Thanks a million.
Thinking of computer programmers in the '70s and '80s using "smoke and mirrors" sounds a lot like code for using drugs to fuel the creative coding. I have had the cassette player hooked up to my TI 99/4A for the last 5 months just waiting for this kind of video. This looks awesome...Thanks!
Dude, I wish I would have had your string-data music trick 40 years ago. I would have used that trick in any BASIC I encountered. Brilliant! Also, I always forget about CALL KEY. I've been witring a little speech demo (hanging out on your channel too much methinks) that requires user input, and have been using the INPUT command....think I'll go in and change all those right now. Nice to see your instructional contributions are as valuable as your retrospective reviews. Gotta luv ya brother!
I feel like TI BASIC (and Extended BASIC) sound is something we still have a lot to learn about. Or rediscover, perhaps. There were a couple people who produced really good TI BASIC and XB music back in the day, and employed one or two tricks I'm now using. But I don't get the impression their methods and solutions ever got much attention. Mainly just because BASIC itself always took a back seat.
@@PixelPedant Looking forward to the dungeon crawler you're working on. Do you plan to compile it? Grail of the Gods (both dungeons) has become a daily activity, so I look forward to a Pixel Pedant alternative.
It's probably not going to be easily compiled, due to a fair amount of floating point math (since all numeric variables are floats in TI BASIC, and exploiting that is beneficial) and due to being elaborately timed around TI BASIC timings. Not impossible though, I figure.
@@PixelPedant That's what I figured. With your optimizations I'm not sure if potential performance improvement would make up for the issues that compiling causes. (Downloaded the giant compiled games archive recently, and the timings changes breaks the playability of several favourites - Blox-o-tiz and Grog (two exceptional BASIC games) are rendered nearly unplayable because of the increased speed of key polling) As a result I continue to play them in BASIC. But had to ask.
Great video dude. Came for the TI info stayed for the pedant! You're a great ambassador for this under rated machine. Can't wait to see the full game/next video.
I just tried it out during lunch. Wow. It's leagues above the other TI BASIC games I've been trying. Very playable! Can't wait to see what you do with it! I'm really happy to have found your channel.
Glad you ran into it. So much TI BASIC back in the day just wasn't playing to the strengths (and idiosyncrasies) of the language, as I say. Hope you code some of your own, and add something to the library of software that does!
Amazing video!!! Love the work you have done in Hell's Halls!!! I wish I can do something like that at some point. I just realized that you shared the WAV! I'm definetly playing this!!
I wrote my first TI Basic games back in 1984.Never forget this computer.Unfortunately they were not so quit common here in Germany.But as I got Mechatronic Extended Basic the fun started.Call Sprite etc.
Awesome video! Something I've considered that may (or may not) help you compress those 8-bit floats is to essentially turn one 8-bit float into a place to store multiple. I'm very much not an expert on this, so feel free to call me out if this is wrong: Say you have a space in memory that stores a 4 digit number (0000) , and you have two variables that are themselves 2 digits at maximum (26 and 32). // What you could do instead is: - Deprecate the 4-digit number by the first variable's intended value (0026) - Deprecate the 4-digit number by the second variable's intended value, except multiplied by 100 (3226) // Then, presumably, all one would have to do is: - To read the second variable, divide the number by 100 and throw out the remainder / decimal value without rounding (3226/100=32.26=32) - To read the first variable, divide the number by 100, throw out the remainder / decimal value without rounding, then subtract this resulting value x100 from the original number (3226/100=32.26=32,32*100=3200,3226-3200=26) Perhaps this would be too slow, or perhaps you need a higher maximum value than 99 (you could always adjust this method for smaller or larger variable indexes, such as if you have one with a maximum index of 9 or 999). The thinking here is that, given you have 9 possible digits in the maximum value possible for those 8 bytes (including the two behind the decimal point), you could use those 8 bytes to store values for 2,4, maybe even 9 different variables if they all have indexes limited enough to make that work. I'm aware that the weird numerical limit means that not all digits in the 8-bit float have the same index range, but I'm sure you can figure something out :) Anyways, that's my poor attempt at possibly devising a compression solution for your 8-bit float values: Just use one float value to store multiple values. Hopefully it helps, or if not hopefully it was at least entertaining to read haha.
@@steveyoungwork Good to know! I think my suggestion still holds water, despite being incorrect on how many digits you have available for the number. Sounds like you could have a 4-digit value up to 9999, which then can hold either two 2-digit values or four 1-digit values (unless the way the bytes store the data makes representing them this way impossible).
@@xPLAYnOfficial Your correct, it would work, and I have use something similar decades ago, but working with the two bytes in hex, and converting them as needed if often more efficient.
@@steveyoungwork Well in this case it sounds like the biggest limitation for him was space, so I guess it would depend on how simple he can make the routine to read and write the bytes
Really well done! Been looking to getting back to programming my TI since the 80s and sort out some unfinished business. This is a HUGE help towards understanding what l've got to do! Thanks again!
Growing up, the disk drive with PEB was way out of reach, so cassette it was. I can tell you that I had the Tunnels of Doom cassette loading sound MEMORIZED. It was this computer-song with all these twists and turns and I used to imagine what sounds were loading which parts of the game. There was a pulse, a rhythm. Only recently, 40 years on, have I learned that each bit was sent twice for error-checking... thus creating the rhythm of the song. I can still remember it today: "EEEEEEEEEEEEEEE cha cha chabada chabada choo choo dabada dabada chee chee EEEEEEEE cha cha wabada wabada ..... "
This is really cool. I recently found a TI-99 and got it cleaned up and running again, and all I have is a tape recorder. So this is very interesting to me!
I typed in a program recently from a book that used a variation of the trick you have implemented in your keyscan routine (on K+1 GOTO) and I didn't really get the full syntax of it until I saw yours. Do you recall where you discovered that method? And do you have any specific TI BASIC programming reference books that have those very handy tips that you would recommend one use?
That I didn't get from anywhere in particular. More just a decision made based on the recently tested observation that ON X GOTO is always faster than multiple equiprobable IFs. I'll use a sequence of IFs when 1) one specific value is greatly more probable than the others, and so only the first IF will usually be evaluated (regardless of how many there are in all), or 2) There's just no way to make the values concerned sequential. But "ON GOTO if at all possible" is definitely my outlook nowadays. As for TI BASIC programming reference/instruction books, Stephen Shaw's "Getting Started With the Texas Instruments TI99/4A" has very good coverage of BASIC programming and is available online: shawweb.myzen.co.uk/stephen/book2.htm -
Fascinating presentation. I am a life long amateur computer science nut. What you are doing reminds me about a video about programming the PlayStation game consoles which require a totally different paradigm of data manipulation from the PC Intel Xbox oriented world. You should try a search on PlayStation programming. Seeing how they do things might give you insight into the intricate data manipulations you are getting into.
This looks WAY more decent than I expected. Kudos to your efforts! . I guess it is out of the question to have any kind of first person shooter, like Doom?
There are pseudo-3D "maze games" which were a popular genre of the era, even in TI BASIC. The thing is, one of the few things TI BASIC can do pretty fast is draw a series of identical characters in a straight line. So creating line-drawn "3D" dungeon perspectives similar to Tunnels of Doom (but stripped down to the bare minimum) is possible, even in console BASIC. The games (from Germany) "3D Irrgarten" and (from Italy) "Dedalo" are examples.
Going with vanilla TI Basic and a cassette - while you have XB, extra memory, and a PEB loaded with peripherals - may sound like a masochistic act. But real men do it with as little as possible, exploiting every single CPU cycle and squeezing every bit of the limited memory. Not because it is easy but because it is hard - and for the fun of the challenge. Dungeon crawler was a perfect choice for such a challenge. I wonder if it is possible to somehow squeeze a FOV algorithm in the code, essentially making it a modern roguelike.
An FOV algorithm would indeed be a cool challenge. I tend to think it would just be too slow for pure TI BASIC, though. As currently designed, this game only takes a second or so to draw a room when you enter it. But if it were updating tiles on every step, every step would likely entail that kind of wait, which would probably just be too much.
I remember having a basic game on cassette, a kind of military strategy game. I bought it in the UK, and played it to death. Any ideas what it might have been called? I only have a fuzzy memory of it!
The Plains of Salisbury was a rather good TI BASIC military strategy cassette/type-in game which did a pretty good job making the rounds. Here is a screenshot: pixelpedant.com/salisbury.jpg and here is the TIFILES file: pixelpedant.com/PLAINS in case that is it.
Great video. I spent hundreds of hours in TI basic and was usually disappointed by the slow results. You showed a clip of a racing game - is that road race from 1982 or so? I haven’t seen that in 30 years!
Lord of Spiders can be found here in TIFILES format: HTTPS://pixelpedant.com/tifiles/LORDSPIDER Note that as this is a cassette game designed to exploit all the memory available to BASIC in the *absence* of a disk controller, use as a file on disk requires use of the CALL FILES(1) command to free up enough VDP memory prior to loading the program.
Maybe several data values can be squeezed into normal variables. Since all numbers are 8 bytes (64 bits), maybe several lesser bit numbers can be stored in one variable depending on the bit-length required for the numbers. Since the radix takes away one byte, that leaves 7 bytes to work with as a "stack". The downside would be the BASIC CPU cycles needed to "push" and "pop" those values in/out of the variable. Seven 8-bit values can be "pushed" and "popped" with the appropriate multiplier/divisor, e.g. 256 for the LSB. "PUSH" would be a multiply by 256 plus an add for the 8-bit value being "pushed" into the LSB. Pop would be the difference between the popped stack value (division by 256) and the original stack value. This might could be scaled for arbitrary bit lengths also as may be required. I saw something like this in a chess program written in Fortran.
The SAMS expansion board is the now standard 1MB bank-switched memory solution for TI-99. The solution can in principle support both more and less than 1MB, but 1MB has become the de facto standard for SAMS boards, which are available both as a sidecar and PEB board.
I don't have a TI 99/4A or any of the bits for it as they rarely show up in my area. I do have a basic program that I use to compare various computers of the 70s and 80 and their respective basics. The program draws a 3 dimensional figure shaped vaguely like fedora hat. On the Atari, it takes roughly 3 hours to draw the figure. On a Commodore 128 it takes around 2 hours to complete. I haven't quite finished working on a version for the Commodore 64 but it already takes over three hours and I think the plot routines I had to build could be optimised slightly ( I lifted them directly from the C64 Programmers reference). I'm not trying to optimize the program which is the first thing I get from people, I want to compare the graphic capabilties of the native languages on each computer (along with the floating point packages, etc). I know that the intro level basic on the TI doesn't have many graphic commands, but what would be the minimum requirements that the TI would need to run a point addressable graphics program like the one described? Would it be extended basic or would additional hardware and software be required?
You can draw a "bitmap" image in BASIC or Extended BASIC, sort of, but because you will not have enough unique patterns to cover the screen, this will depend on a large number of repeated patterns, or a subsection of the screen being used. The TI-99 does have two bitmap modes in which every screen tile may have a unique pattern, but these are not available in BASIC or TI Extended BASIC, as these depend on VDP RAM to store nearly all their program data, and a bitmap mode (like the colour bitmap mode usually just called "bitmap mode" these days by users) uses most of VDP RAM for screen data. The minimum requirement for assembly program development using bitmap mode is the Mini Memory cart, but it is otherwise supported by BASIC dialects like The Missing Link and XBII+ using the 32K expansion.
Wow, speaking as someone who has written unexpanded VIC-20 BASIC games, I never knew I had it so good. I'm shocked at how slow printing text in TI BASIC is ... one of the few things I can count on being really fast on the VIC-20 is printing a string. Trying to wrap my head around the TI BASIC limitations, though ... some of my VIC-20/C64 BASIC tricks do come to mind.
Palette switches are for sure one of the top tools in the TI BASIC programmer's arsenal. Above all else, just minimising the number of VDP writes you need to do (whether palette or screen table data) in any given loop, and by any means necessary, is at the crux of everything.
I had that Space Invaders type game for TI BASIC and it was completely unplayable. So glad I had TI Invaders. I guess the programmers had the idea of a Space Invaders game for TI BASIC but it failed. Also there was a book and cassette I owned called Entertainment Games in TI BASIC and Extended BASIC and in there was Arrow Zap which was nothing more than a TI BASIC adaptation of Zero Zap (although the background screen was yellow rather than white) and no surprise, it had nowhere the action or smooth playing of the cartridge. I guess these guys (who were teenagers when they published this book and cassette) proved Zero Zap can be done on TI BASIC although could never be as good as the cartridge version. At least it's a bit more playable than the Space Invaders game as it's a bit more responsive.
I have a bunch of old cassettes in storage that contain old BASIC programs my Dad and I wrote when I was a kid in the 80s. I want to be able to preserve these in a digital format that a TI emulator can read, but I'm on the verge of giving up. I don't have original hardware anymore (apart from the TI99/4A itself with no tape recorder), so I'm trying to do it using an old stereo, a Griffin iMac (USB to 3.5mm adapter) and Audacity. I end up with an audio file that makes all the sounds I expected, but they fail to load in the emulator (the OLD command just sits there, like it's still waiting for more). I know I'm using the emulator correctly because other cassette files I've downloaded from the net work just fine. Does anyone have any ideas as to what I'm doing wrong? I recall our TI being very fussy with volume back in the day, so I've tried all possible volume levels. My guess is: - A stereo isn't ideal for this kind of work, even when playing a mono recording. No one used stereos to save and load back in the day. - The iMic mightn't be good enough. - The cassettes mightn't be in good enough condition anymore. How I'd love to see what's on those old cassettes though.
One thing you may want to try is giving up on the audio/cassette format and attempting to extract the program content for disk use. Tools facilitating this are CS1er and Tape994a. I would recommend starting with CS1er (cs1er.com).
Makes me want to update my surviving 1980 TI BASIC Odyssey2 clone game titled Helicopter Rescue. Perhaps after forty years I can do better? Thanks for the lessons Professor Pix!
2:07 That looks just like a Space Invaders type-in game that was in 99er Magazine. I think it might have even been written by the enigmatic "Regena." I spent hours typing that darn thing in only to get a jerky mess of a slide show instead of a playable game. I was so disappointed :(
Yeah, that is my vague recollection as well. Can't really blame Regena, though. Space Invaders just wasn't going to happen to any acceptable extent in TI BASIC.
@@PixelPedant Maybe you could animate the aliens going side to side a bit using palette changes. Not exactly true to the original because the extent of the left/right motion must be fixed (maybe 3-4 characters). But a better "solution" would of course be to rethink the basic game design. For the VIC-20, the popular game "Blitz" turned the Space Invader concept upside-down, so you were the one moving while the field of targets was fixed. Thus, the only two things that needed to be animated were your airplane and one bomb. I remember a type-in Pac-Man clone which similarly reduced the animation requirements by having only one ghost. It had a classic tree-type maze, so the only way to escape the ghost was to go down one branch while the ghost randomly luckily went down another branch. Quintessentially, the game design made the player's task more interesting by making the maze more difficult, to make up for the fact that there was only one ghost. When I made Robovic (a 20 line BASIC Robotron clone), I kept animation down to three things at a time - you, your bullet, and one random enemy each animation frame. The result was a fun speed up effect. At the start, the robots were very slow, but as you whittled them down they got faster and faster. You'd have to plan out how you were going to take out the last few robots carefully. I couldn't do much animation, nor could I implement any sort of interesting AI, but I was pleasantly surprised that the resulting game was really fun and engaging. (The main loop was: move PLAYER, move BULLET, move random ROBOT, move BULLET, so your bullet move twice as fast as you.)
I've made some games in 8-bit BASIC on the TRS-80 MC-10 and they go pretty fast, but I can see the true challenge would be to try to do it on the TI99/4A! Maybe I'll give it a try. Thanks for your enthusiastic support of a classic machine. Just in case you're interested: ruclips.net/p/PLtYSk7tR7rVxBvqbGYjYUUSFN3iivU7fO
Something I did on my dungeon crawl I was making to save memory was byte packing. I created string functions to give me bit access in TI Basic. Using 4 bits I could store all 16 possible door option that define a room have 4 more bits in the byte to store room info like bit 5 "does room have a monster yes or no", bit 6 "does room have treasure yes or no", bit 7 "does room have stairs yes or no". This was so helpful for storing info about rooms and about monsters. You can store all the dungeon info in for a 6x6 room dungeon in 36 bytes of info this way. I could store monster info the same way, bit 1 alive dead, bit 2 has treasure, bit 3 is posionous, bit 4 can freeze, bit 5 can burn you, ect.
It's funny because it's true.
BASIC is supposed to an easy programming language but in order to efficiently program TI BASIC you end up with a wall of hieroglyphics. Haha.
I like how TI BASIC converts Space Invaders and Donkey Kong into turn-based gaming. Realistically you can only have two things moving at one time at most and maintain any level of action.
Your game looks great, far superior than anything I ever produced back in the day (83 to 87).
That sound of the TI 99/4A data loading from the cassette still gives me goose bumps. The anticipation and thrill of seeing "DATA OK" at the end of a long program. 🙂 Or the agony of defeat when you saw ERROR IN DATA or NO DATA FOUND
My cassette has given me nothing but NO DATA FOUND on ALL my tapes, since the last time I plugged in the MBX.
Every now and then I am reminded why a retro-tech hobby is not ideal for folks with under-developed electronics skills or those of us who are risk-adverse to recapping and soldering. But we don't pick the things we love.
I just need a Pixel Pedant type friend living next door so he can deal with rouble shooting and I can have all the fun...
@@PeBoVision lol. agree on that last sentence. Back in the 1980s I knew just barely enough about TI 994/A to be dangerous, and I've since forgotten all of it 😆 One thing you could try is using audacity, or some other computer audio-recording software to record those old TI 99/4A data tapes. After they are stored in audacity, you can "tweak" the audio (equalizing it, amplifying it, noise reduction etc). It may just allow you to get those old programs loaded.
This was my first computer at 10 years old. It’s crazy how something you didn’t know at the time could guide your life. I learned to type on it. By the time I was 13 years old I was typing 80 wpm. By the time I hit 9th grade, I was typing 100 wpm with no mistakes. We could take typing as an elective in high school and basically the first day we had a competence test and the teacher said “you type faster than anyone at this age I’ve ever seen”. She then let me teach the fundamentals of typing on my second day of class and gave me an A+ for the semester right then and there. Since then I’ve worked for companies such as Boeing, NASA, etc. I owe it all to this machine and the inventors of basic that taught me logic and programmatic thinking. I still own it by the way. I will never sell it. It made my life aspirations and life goals come true.
awesome story! Did you have 'Touch Typing Tutor' back in the day?
Man, great story. I owe a lot to the TI 99/4a too.
@@Guidja68 YES. That is one of the reasons the typing speed got so fast. Loved it and still love this computer.
I got a TI99/4A in 1984 because it was being sold with big discount, this was the only computer I could afford and I did not know anything about computer. After a couple of months of learning and programming in basic, I became frustrated at Texas Instruments because their basic did not provide for PEEK/POKE to program and run machine code. I was pretty jealous of my friends with C64 and Oric as result; Sold it about 1 year later to buy the then newly released Amstrad CPC. I m still pretty nostalgic of my TI99 thought.
Excellent sir! You should take a look at my favourite, "Commando" which was one of the games in the Collins Gameswriters pack. It came with a book and a cassette. I should say that I'm a member of TI-99/4A User Group UK. I've shared a couple of your videos with our Facebook group. Keep up the amazing work 🙂 (P.S. brilliant music, reminds me of "The Shining")
The tangle of GOSUBs at the beginning is how business applications were written in BASIC in the 70s. Business minicomputers, the usual hosts for business apps written in BASIC, had a bit more memory than the TI-99/4A, but not much -- and the applications themselves could grow even more complex than your game and even need to support multiple users. A mid-70s 64k minicomputer coukd support eight simultaneous users, run several tasks at once, and run all the financials for a small to medium size business -- in part because the BASIC programmers of the day ruthlessly optimized their code.
I'm working on a game for a computer that has been... ill served by graphical games during its lifespan. It's capable of graphics, but not particularly dynamic or fast ones, so I too concluded that a dungeon crawler would be a good choice. I've been further inspired by Hell's Halls to complete this game.
Nice! You don't need much in the way of graphics to make a good dungeon crawl after all. Nice to have if you've got them, but ASCII/PETSCI/ANSI will absolutely do in a pinch, or the Roguelike would never have become the phenomenon it did.
I’m very excited about your game. I think it’s so awesome that we have home brew games. Also I think it’s really really nice that you used stock hardware.
It's easy to run out of memory even with the memory expansion. I'm in the middle of creating a tile based adventure for the TI in XB and even using the memory expansion I have had to make many compromises to make this game close to the quality I want.
The game consists of a world made up of 4 levels each consisting of 40 individual tile screens. The screens themselves consist of a play field and a HUD which keeps track of health, gold, equipment and inventory.
The HUD is fairly static during game play, updating only when new items are picked up, used, discarded or when health is effected.
All the tile definitions and sound and music is first loaded from a separate program. That program then loads the first level program. The first level program and subsequent levels use the definitions defined in the first (graphics) program that was loaded.
The play field is smaller than the display area of the normal TI display - it's 22x24 vs the TI 24x32. The rest of the TI display is used for the HUD.
I was able to reduce the amount of data needed to draw each screen by using a fairly small but variable size data format that represents each play field.
The format is as follows:
monster type code
monster count
base map character code (fills play field)
Treasure type code
Treasure x LOC
Treasure y LOC
(Following can repeat and is used for drawing objects on playfield)
Special tile code
Special tile X LOC
Special tile y loc
Special tile height
Special tile width
(-1 terminates the display field data, otherwise additional special characters are read in).
So a typical line to define a display screen might look like this:
4310 DATA 3,3,4,199,8,18,24,2,2,22,2,-1
This data would draw a field of grass with a stream running the width of the display at the top of the display. There are 3 snakes for this field and the treasure is a helmet located at 8,18.
One thing I had to do is make the graphics and each level load as a new program from disk. This allows me to use the full amount of memory for each level of the game. This probably wouldn't work (at least not easily) for a game on casette.
Hell's Walls? More like HELL YEAH!! If only my 9 year old self with my trusty TI and my TI tape recorder could have made this game!!! Can't wait to play!
Good looking stuff!
Insane attention to details, thanks for your work.
I only had basic and cassette when I got my TI99/4a in the mid/late 1980s. I did get Extended Basic in the late 1980s but I did not know its full power. Thanks for doing basic and cassette:)
I was learning basic on a TI99/4A at the same time I was learning Basic on TRS-80 Model III in High School. Always found it interesting why Texas Instruments used phrases like "incorrect statement" rather than "syntax error" or other phrases like " can't do that".
Much of the language that deviates from Microsoft BASIC norms most people were used to by the 80s come down to TI's deriving most of its BASIC conventions from its minicomputer BASICs, which derived their conventions from Dartmouth BASIC and its operating environment. Absolutely nobody else in the 80s home microcomputer sphere went the Dartmouth BASIC/ANSI BASIC route as far as I know. So it definitely makes TI BASIC's conventions a tad odd, in a lot of places.
Wow. You really went to town on this topic! Good going. Lots of interesting information there. I do miss basic programming. Thats not why you turn on a PC anymore. The TI-99/4a was such a great machine to learn on... and you're showing that there's still lots to discover. Thanks!
That was fun. Took me back to the early days.
What a great explanation of how basic works. This helped me understand memory management and why everyone codes with abbreviated values and tags. Thanks a million.
Very impressive games for TI Basic :)
thanks Pixel always interesting arguments and speech ... please continue
Thinking of computer programmers in the '70s and '80s using "smoke and mirrors" sounds a lot like code for using drugs to fuel the creative coding.
I have had the cassette player hooked up to my TI 99/4A for the last 5 months just waiting for this kind of video. This looks awesome...Thanks!
Dude, I wish I would have had your string-data music trick 40 years ago. I would have used that trick in any BASIC I encountered. Brilliant!
Also, I always forget about CALL KEY. I've been witring a little speech demo (hanging out on your channel too much methinks) that requires user input, and have been using the INPUT command....think I'll go in and change all those right now.
Nice to see your instructional contributions are as valuable as your retrospective reviews.
Gotta luv ya brother!
I feel like TI BASIC (and Extended BASIC) sound is something we still have a lot to learn about. Or rediscover, perhaps. There were a couple people who produced really good TI BASIC and XB music back in the day, and employed one or two tricks I'm now using. But I don't get the impression their methods and solutions ever got much attention. Mainly just because BASIC itself always took a back seat.
@@PixelPedant Looking forward to the dungeon crawler you're working on. Do you plan to compile it?
Grail of the Gods (both dungeons) has become a daily activity, so I look forward to a Pixel Pedant alternative.
It's probably not going to be easily compiled, due to a fair amount of floating point math (since all numeric variables are floats in TI BASIC, and exploiting that is beneficial) and due to being elaborately timed around TI BASIC timings. Not impossible though, I figure.
@@PixelPedant That's what I figured.
With your optimizations I'm not sure if potential performance improvement would make up for the issues that compiling causes. (Downloaded the giant compiled games archive recently, and the timings changes breaks the playability of several favourites - Blox-o-tiz and Grog (two exceptional BASIC games) are rendered nearly unplayable because of the increased speed of key polling)
As a result I continue to play them in BASIC.
But had to ask.
Great video dude. Came for the TI info stayed for the pedant!
You're a great ambassador for this under rated machine.
Can't wait to see the full game/next video.
I just tried it out during lunch. Wow. It's leagues above the other TI BASIC games I've been trying. Very playable! Can't wait to see what you do with it! I'm really happy to have found your channel.
Glad you ran into it. So much TI BASIC back in the day just wasn't playing to the strengths (and idiosyncrasies) of the language, as I say. Hope you code some of your own, and add something to the library of software that does!
Stunning!!!
Amazing video!!! Love the work you have done in Hell's Halls!!! I wish I can do something like that at some point.
I just realized that you shared the WAV! I'm definetly playing this!!
I wrote my first TI Basic games back in 1984.Never forget this computer.Unfortunately they were not so quit common here in Germany.But as I got Mechatronic Extended Basic the fun started.Call Sprite etc.
Awesome video! Something I've considered that may (or may not) help you compress those 8-bit floats is to essentially turn one 8-bit float into a place to store multiple. I'm very much not an expert on this, so feel free to call me out if this is wrong:
Say you have a space in memory that stores a 4 digit number (0000) , and you have two variables that are themselves 2 digits at maximum (26 and 32).
// What you could do instead is:
- Deprecate the 4-digit number by the first variable's intended value (0026)
- Deprecate the 4-digit number by the second variable's intended value, except multiplied by 100 (3226)
// Then, presumably, all one would have to do is:
- To read the second variable, divide the number by 100 and throw out the remainder / decimal value without rounding (3226/100=32.26=32)
- To read the first variable, divide the number by 100, throw out the remainder / decimal value without rounding, then subtract this resulting value x100 from the original number (3226/100=32.26=32,32*100=3200,3226-3200=26)
Perhaps this would be too slow, or perhaps you need a higher maximum value than 99 (you could always adjust this method for smaller or larger variable indexes, such as if you have one with a maximum index of 9 or 999). The thinking here is that, given you have 9 possible digits in the maximum value possible for those 8 bytes (including the two behind the decimal point), you could use those 8 bytes to store values for 2,4, maybe even 9 different variables if they all have indexes limited enough to make that work. I'm aware that the weird numerical limit means that not all digits in the 8-bit float have the same index range, but I'm sure you can figure something out :)
Anyways, that's my poor attempt at possibly devising a compression solution for your 8-bit float values: Just use one float value to store multiple values. Hopefully it helps, or if not hopefully it was at least entertaining to read haha.
2 bytes can contain the numbers 0 to 65356
@@steveyoungwork Good to know! I think my suggestion still holds water, despite being incorrect on how many digits you have available for the number. Sounds like you could have a 4-digit value up to 9999, which then can hold either two 2-digit values or four 1-digit values (unless the way the bytes store the data makes representing them this way impossible).
@@xPLAYnOfficial Your correct, it would work, and I have use something similar decades ago, but working with the two bytes in hex, and converting them as needed if often more efficient.
@@steveyoungwork Well in this case it sounds like the biggest limitation for him was space, so I guess it would depend on how simple he can make the routine to read and write the bytes
@@xPLAYnOfficial thats true enough, i dont know if the TI has bit reading or not, if it did your method would work well
Really well done! Been looking to getting back to programming my TI since the 80s and sort out some unfinished business. This is a HUGE help towards understanding what l've got to do! Thanks again!
Nice. Go for it! Sorting out unfinished business is definitely my inspiration as well.
@@PixelPedant l really can't tell you how much l needed this video man. I can't thank you enough!
Growing up, the disk drive with PEB was way out of reach, so cassette it was. I can tell you that I had the Tunnels of Doom cassette loading sound MEMORIZED. It was this computer-song with all these twists and turns and I used to imagine what sounds were loading which parts of the game. There was a pulse, a rhythm. Only recently, 40 years on, have I learned that each bit was sent twice for error-checking... thus creating the rhythm of the song. I can still remember it today: "EEEEEEEEEEEEEEE cha cha chabada chabada choo choo dabada dabada chee chee EEEEEEEE cha cha wabada wabada ..... "
This is really cool. I recently found a TI-99 and got it cleaned up and running again, and all I have is a tape recorder. So this is very interesting to me!
That creeking wooden door sound is priceless
I typed in a program recently from a book that used a variation of the trick you have implemented in your keyscan routine (on K+1 GOTO) and I didn't really get the full syntax of it until I saw yours. Do you recall where you discovered that method? And do you have any specific TI BASIC programming reference books that have those very handy tips that you would recommend one use?
That I didn't get from anywhere in particular. More just a decision made based on the recently tested observation that ON X GOTO is always faster than multiple equiprobable IFs. I'll use a sequence of IFs when 1) one specific value is greatly more probable than the others, and so only the first IF will usually be evaluated (regardless of how many there are in all), or 2) There's just no way to make the values concerned sequential. But "ON GOTO if at all possible" is definitely my outlook nowadays. As for TI BASIC programming reference/instruction books, Stephen Shaw's "Getting Started With the Texas Instruments TI99/4A" has very good coverage of BASIC programming and is available online: shawweb.myzen.co.uk/stephen/book2.htm -
Great work and very nicely presented! Thank you!
Fascinating presentation. I am a life long amateur computer science nut. What you are doing reminds me about a video about programming the PlayStation game consoles which require a totally different paradigm of data manipulation from the PC Intel Xbox oriented world. You should try a search on PlayStation programming. Seeing how they do things might give you insight into the intricate data manipulations you are getting into.
This looks WAY more decent than I expected. Kudos to your efforts! . I guess it is out of the question to have any kind of first person shooter, like Doom?
There are pseudo-3D "maze games" which were a popular genre of the era, even in TI BASIC. The thing is, one of the few things TI BASIC can do pretty fast is draw a series of identical characters in a straight line. So creating line-drawn "3D" dungeon perspectives similar to Tunnels of Doom (but stripped down to the bare minimum) is possible, even in console BASIC. The games (from Germany) "3D Irrgarten" and (from Italy) "Dedalo" are examples.
Damn, that's cool. Greetings from Finland!
Going with vanilla TI Basic and a cassette - while you have XB, extra memory, and a PEB loaded with peripherals - may sound like a masochistic act. But real men do it with as little as possible, exploiting every single CPU cycle and squeezing every bit of the limited memory. Not because it is easy but because it is hard - and for the fun of the challenge.
Dungeon crawler was a perfect choice for such a challenge. I wonder if it is possible to somehow squeeze a FOV algorithm in the code, essentially making it a modern roguelike.
An FOV algorithm would indeed be a cool challenge. I tend to think it would just be too slow for pure TI BASIC, though. As currently designed, this game only takes a second or so to draw a room when you enter it. But if it were updating tiles on every step, every step would likely entail that kind of wait, which would probably just be too much.
I remember having a basic game on cassette, a kind of military strategy game. I bought it in the UK, and played it to death. Any ideas what it might have been called? I only have a fuzzy memory of it!
The Plains of Salisbury was a rather good TI BASIC military strategy cassette/type-in game which did a pretty good job making the rounds. Here is a screenshot: pixelpedant.com/salisbury.jpg and here is the TIFILES file: pixelpedant.com/PLAINS in case that is it.
@@PixelPedant I think that was it! great game!👍
Great video. I spent hundreds of hours in TI basic and was usually disappointed by the slow results. You showed a clip of a racing game - is that road race from 1982 or so? I haven’t seen that in 30 years!
Quite an impressive little crawler you got started here!!
Where might i find "Lord of the Spiders"? (looks impressive too :))
Lord of Spiders can be found here in TIFILES format: HTTPS://pixelpedant.com/tifiles/LORDSPIDER
Note that as this is a cassette game designed to exploit all the memory available to BASIC in the *absence* of a disk controller, use as a file on disk requires use of the CALL FILES(1) command to free up enough VDP memory prior to loading the program.
Maybe several data values can be squeezed into normal variables. Since all numbers are 8 bytes (64 bits), maybe several lesser bit numbers can be stored in one variable depending on the bit-length required for the numbers. Since the radix takes away one byte, that leaves 7 bytes to work with as a "stack". The downside would be the BASIC CPU cycles needed to "push" and "pop" those values in/out of the variable. Seven 8-bit values can be "pushed" and "popped" with the appropriate multiplier/divisor, e.g. 256 for the LSB. "PUSH" would be a multiply by 256 plus an add for the 8-bit value being "pushed" into the LSB. Pop would be the difference between the popped stack value (division by 256) and the original stack value. This might could be scaled for arbitrary bit lengths also as may be required. I saw something like this in a chess program written in Fortran.
Awesome stuff!
How would a person upgrade a standard ti994a to have 1meg of ram?
The SAMS expansion board is the now standard 1MB bank-switched memory solution for TI-99. The solution can in principle support both more and less than 1MB, but 1MB has become the de facto standard for SAMS boards, which are available both as a sidecar and PEB board.
I don't have a TI 99/4A or any of the bits for it as they rarely show up in my area. I do have a basic program that I use to compare various computers of the 70s and 80 and their respective basics. The program draws a 3 dimensional figure shaped vaguely like fedora hat. On the Atari, it takes roughly 3 hours to draw the figure. On a Commodore 128 it takes around 2 hours to complete. I haven't quite finished working on a version for the Commodore 64 but it already takes over three hours and I think the plot routines I had to build could be optimised slightly ( I lifted them directly from the C64 Programmers reference).
I'm not trying to optimize the program which is the first thing I get from people, I want to compare the graphic capabilties of the native languages on each computer (along with the floating point packages, etc).
I know that the intro level basic on the TI doesn't have many graphic commands, but what would be the minimum requirements that the TI would need to run a point addressable graphics program like the one described? Would it be extended basic or would additional hardware and software be required?
You can draw a "bitmap" image in BASIC or Extended BASIC, sort of, but because you will not have enough unique patterns to cover the screen, this will depend on a large number of repeated patterns, or a subsection of the screen being used. The TI-99 does have two bitmap modes in which every screen tile may have a unique pattern, but these are not available in BASIC or TI Extended BASIC, as these depend on VDP RAM to store nearly all their program data, and a bitmap mode (like the colour bitmap mode usually just called "bitmap mode" these days by users) uses most of VDP RAM for screen data. The minimum requirement for assembly program development using bitmap mode is the Mini Memory cart, but it is otherwise supported by BASIC dialects like The Missing Link and XBII+ using the 32K expansion.
Wow, speaking as someone who has written unexpanded VIC-20 BASIC games, I never knew I had it so good. I'm shocked at how slow printing text in TI BASIC is ... one of the few things I can count on being really fast on the VIC-20 is printing a string.
Trying to wrap my head around the TI BASIC limitations, though ... some of my VIC-20/C64 BASIC tricks do come to mind.
Palette switches are for sure one of the top tools in the TI BASIC programmer's arsenal. Above all else, just minimising the number of VDP writes you need to do (whether palette or screen table data) in any given loop, and by any means necessary, is at the crux of everything.
I had that Space Invaders type game for TI BASIC and it was completely unplayable. So glad I had TI Invaders. I guess the programmers had the idea of a Space Invaders game for TI BASIC but it failed. Also there was a book and cassette I owned called Entertainment Games in TI BASIC and Extended BASIC and in there was Arrow Zap which was nothing more than a TI BASIC adaptation of Zero Zap (although the background screen was yellow rather than white) and no surprise, it had nowhere the action or smooth playing of the cartridge. I guess these guys (who were teenagers when they published this book and cassette) proved Zero Zap can be done on TI BASIC although could never be as good as the cartridge version. At least it's a bit more playable than the Space Invaders game as it's a bit more responsive.
I have a bunch of old cassettes in storage that contain old BASIC programs my Dad and I wrote when I was a kid in the 80s. I want to be able to preserve these in a digital format that a TI emulator can read, but I'm on the verge of giving up. I don't have original hardware anymore (apart from the TI99/4A itself with no tape recorder), so I'm trying to do it using an old stereo, a Griffin iMac (USB to 3.5mm adapter) and Audacity. I end up with an audio file that makes all the sounds I expected, but they fail to load in the emulator (the OLD command just sits there, like it's still waiting for more). I know I'm using the emulator correctly because other cassette files I've downloaded from the net work just fine. Does anyone have any ideas as to what I'm doing wrong? I recall our TI being very fussy with volume back in the day, so I've tried all possible volume levels.
My guess is:
- A stereo isn't ideal for this kind of work, even when playing a mono recording. No one used stereos to save and load back in the day.
- The iMic mightn't be good enough.
- The cassettes mightn't be in good enough condition anymore.
How I'd love to see what's on those old cassettes though.
One thing you may want to try is giving up on the audio/cassette format and attempting to extract the program content for disk use. Tools facilitating this are CS1er and Tape994a. I would recommend starting with CS1er (cs1er.com).
@@PixelPedant Thanks for your advice. It’s certainly worth a try. I’ll check this out.
Makes me want to update my surviving 1980 TI BASIC Odyssey2 clone game titled Helicopter Rescue. Perhaps after forty years I can do better? Thanks for the lessons Professor Pix!
I figure we can all do better, at this point. Go for it!
Do you happen to know which is faster, DISPLAY or PRINT? Also, if you timed these, how did you time these commands/statements?
i had flashbacks!
2:07 That looks just like a Space Invaders type-in game that was in 99er Magazine. I think it might have even been written by the enigmatic "Regena." I spent hours typing that darn thing in only to get a jerky mess of a slide show instead of a playable game. I was so disappointed :(
Yeah, that is my vague recollection as well. Can't really blame Regena, though. Space Invaders just wasn't going to happen to any acceptable extent in TI BASIC.
@@PixelPedant Maybe you could animate the aliens going side to side a bit using palette changes. Not exactly true to the original because the extent of the left/right motion must be fixed (maybe 3-4 characters).
But a better "solution" would of course be to rethink the basic game design. For the VIC-20, the popular game "Blitz" turned the Space Invader concept upside-down, so you were the one moving while the field of targets was fixed. Thus, the only two things that needed to be animated were your airplane and one bomb.
I remember a type-in Pac-Man clone which similarly reduced the animation requirements by having only one ghost. It had a classic tree-type maze, so the only way to escape the ghost was to go down one branch while the ghost randomly luckily went down another branch. Quintessentially, the game design made the player's task more interesting by making the maze more difficult, to make up for the fact that there was only one ghost.
When I made Robovic (a 20 line BASIC Robotron clone), I kept animation down to three things at a time - you, your bullet, and one random enemy each animation frame. The result was a fun speed up effect. At the start, the robots were very slow, but as you whittled them down they got faster and faster. You'd have to plan out how you were going to take out the last few robots carefully. I couldn't do much animation, nor could I implement any sort of interesting AI, but I was pleasantly surprised that the resulting game was really fun and engaging. (The main loop was: move PLAYER, move BULLET, move random ROBOT, move BULLET, so your bullet move twice as fast as you.)
I've made some games in 8-bit BASIC on the TRS-80 MC-10 and they go pretty fast, but I can see the true challenge would be to try to do it on the TI99/4A! Maybe I'll give it a try. Thanks for your enthusiastic support of a classic machine. Just in case you're interested: ruclips.net/p/PLtYSk7tR7rVxBvqbGYjYUUSFN3iivU7fO
Must be hell to do such spagetti gramming🤣🤣