adamantyr

It's a custom-built cartridge, unfortunately, with some weird internals for switching banks that doesn't align with FG99.

This largely depends upon if you want to do your compiling on a modern PC and move the resultant code to the TI, or if you want the original experience of compiling on the machine itself. (I don't recommend it, unless you like waiting a LONG time for things to build.) On the TI itself, the Editor/Assembler package is the best and most common system for writing assembly code. You'd get the most support for it by far, as the others (Such as Art Green's RAG time assembler) are not as well known or used these days. In emulation, there's some nifty tools written in Python (Xdt99) that can handle most of your needs. I think the library still uses Python 2, though, so it's a version behind. I myself use A99, which is a rather old compiler tool originally written on the Amiga. I got a copy of the source and binaries from someone on a TI group years ago. I write a lot of my own tools in C# to handle binary copies, translating object code to literal binary code, and so forth and built a package system to create the files for my own CRPG project. This is because I'm using the SAMS memory system, which no current assembler compiler supports natively. At some point I may just write my own compiler in C# just so I got something I can add the bells and whistles I want to easily.

Extended Basic III from Asgard is probably the end of that particular chain. The cartridge is really rare though (I have one, I only got it because I pre-ordered) and for the most part, RXB gives you all the same functionality improvements with the added bonus of being actively supported.

Rich Gilbertson's RXB. In terms of power, flexibility, and awesomeness, it has the crown. Sadly under-utilized as many TI programmers are culturally biased towards sticking with classic TI-Extended BASIC.

The Lotharek is a bit better of a system than Gotek, from my estimation. I have both drives in one system. The TiPi blows both out of the water though for convenience and ease of use. All I do is upload files directly from my PC to the simulated drive, and bam, it's there on my hardware. No converting to disk images or dealing with some weird problem with disk file sectors not aligning properly. Yes, you pay a bit more for it, and you have to wait for the cards to get back in stock and do a bit of setup work yourself, but if your intent is to develop software in emulation and port to the hardware, I can't see it being done any other way without being a major pain, IMHO.

That's from the sequel Dragon's Lair II: Time Warp. Apparently that is Eve, when Dirk travels in time to the Garden of Eden.

1. Tunnels of Doom 2. Dragon's Lair 3. Red Baron Flight Simulator

Wow, some amazing artwork on the manual! Mind you, part of me thinks "The manual is probably 1,000% cooler than the game" simply because you couldn't produce a very long or complex graphic adventure in TI BASIC.

I'll be at the Expo! Name: Adam Haase Handle: Adamantyr Location: Marysville, WA

I'll be there!

I have that cartridge too. Never used it. Heck, if someone wanted to buy it from me, I'd sell it.

That's the TI form of "hexidecimal number". So >DF is like 0xdf in PC land. A sound list is a list of sequential sound commands in a byte format that is interpreted by the ROM routine and played accordingly. All lists are started with a byte count value of how many to process, not including the duration byte at the end. There are commands to "Pass this frequency to voice #1", or "change the attenuation (volume) of voice #1 to this". There are also a few commands to redirect to a different area of memory for the next sound bit. All of them are ended with a duration byte, which indicates how many 1/60 seconds to play. A duration of 0 is the null terminator for the list.

It's doable, but tricky. The method you are describing above is the ISR ROM method of playing music. It takes sound lists and plays back the notes accordingly. It has the advantage that you can just point the routine at a memory area and it will take care of the music for you on interrupts. The disadvantage is it's limited to 1/60 of a second for any given note, doing multiple voices is painful, and having anything other than square tones (no volume decay) requires manual work. It's good for sound effects, not so great for music. For my CRPG, I wrote my own music player, using some of the structures that the late Bruce Harrison (Writer of the excellent "Art of Assembly" articles featured in MICROPendium magazine) did with his own TI company, which produced several disks of music. I've attached a sample of it below, which can be compiled in Editor/Assembler and executed. It features volume decay, and a relatively easy way to program in music via note lists for each voice through equates for the various lengths. The downside? It takes a LONG time to transcribe from sheet music. Also, one annoying factor is that the TI sound chip just, well, isn't as good as the ones featured in slightly later machines. They synced the chip to the 3mhz clock, which means it can't really do base notes, and the total sound range is only about five octaves (10-bit or 1024 unique frequencies). Both the MSX and Colecovision, if I recall, offer a seven octave range and 12-bit frequencies. MUSIC.asm

Indeed the Adventure cartridge is probably one of the best two-word text adventure engines ever made. It's ONLY real problem is the memory limitation of around 12k, since it was designed to run on the base TI console which only had 16K of VRAM for storage.

Congrats to the winners! If only I had used that awesome RXB platform, I may have been more of a contender. *Wink at Rich*

I bought a PAL TI and if you want it, we could do business. I can bring it during the retro expo unless you need it sooner. PM me if interested!

I have also had Classic99 lock up on me as well, on Windows 10 64-bit. Often it happens after I've been running an instance for awhile. I couldn't really point to any particular cause, but the lock-up during Tursi's gameplay of Python is pretty much the same thing I'm seeing; the screen freezes and the emulator ceases to respond to input, and I see CPU usage spike up. Whatever regression it is, it's only started to show up in the last couple releases I think.

Love the videos! Hmm that sneaky python heard your disparagement of his programming language and crashed your emulator it seems...

As I have two entries, I will also not be voting.

Yeah, and sometimes it messes up cut and paste on the modern computers too.

Oh yeah, this bug is in the software itself. My brother and I discovered it back in the 80's while playing Parsec. It had some other weird effects too; we started getting killer satellite's showing up before we hit level 4.

It's not too bad in assembly, the biggest complication is coming up with a module-based approach with code management. I baked my own for my CRPG work, at some point when I'm done with the game I'll discuss it at length. A cross-assembler that could build modules that are dynamically assigned to pages IS possible but I honestly think trying to apply a modern design system to what is essentially 8-bit architecture will get too top-heavy. Just my opinion though. I honestly feel C is too much overhead for the TI-99/4a.

Hi all, So I'm cleaning up my basement and I find these relics... anyone else attend this? Besides Rich, I remember you were there! Adam

What Senior Falcon said, we need some more information on what that routine is doing. I thought at first your screen buffer was being written outside of with a line like LI R0,921, but I realized you're in text mode so that's valid. I'd advise using a mnemonic like SCRADR just to keep them cleaner. Your KSCAN routine is slightly inefficient as well; you can do a CB @STATUS,@SPACEB to check the flag instead of moving and then shifting R0.