Bouncy's obstacle course

Almost everything I have made for the TI-99/4A requires a RAM expansion. I wanted to try something else.

Here is a preview of a smooth scrolling game that runs on an unexpanded TI-99/4A from an 8K ROM cartridge - no 32K RAM or disk drive required.

The game is currently 6.2K and has 4 levels of 256x20 characters, 2 of which are shown in the video. The reason that is possible is due to lz4 data compressiom, thanks to Tursi and others. The cool thing is that it's running at 60Hz despite storing the map in VDP RAM, and for now it's actually only using 2/5 of the CPU.

I might decide to add another ROM bank of 8K for the full game, but the essential thing is that this could have been produced and sold in 1982, which is not true for a game like Flying Shark that requires a 512K ROM + 32K RAM.

Challenge notwithstanding, I think you should do the second bank. This needs a soundtrack!

Thanks, and yes it needs a soundtrack, but it's challenging since I can't use your vgm/spf player because it uses too much RAM. For the sound fx I'm currently using a simple player where each effect only takes 4-6 bytes of data (basically just start and step for frequency and volume). I might extend that to be able to combine sound effects into tunes.

Thanks, and yes it need a soundtrack, but it's challenging since I can't use your vgm/spf player because it uses too much RAM. For the sound fx I'm currently using a simple player where each effect only takes 4-6 bytes of data (basically just start and step for frequency and volume). I might extend that to be able to combine sound effects into tunes.

Ah, yeah, scratchpad and all. You could trade CPU time for memory and store its data in VDP, but it wouldn't be terribly speedy.

I do have a pending update that reduces the requirements, but it probably still won't be terribly scratchpad-friendly.

If you are sticking to the old 80s model, is there too much data transfer through the VDP to use sound lists in VDP RAM? You could use the native ISR player, or figure the longest frame will be 13 bytes (byte counter, 3 bytes each tone including attenuation, 2 bytes for the noise including attenuation, duration.) You would need a source location pointer of one or two bytes, so if you have 14 or 15 bytes to spare in CPU RAM (a lot to spare, sadly) you could set up a buffer there, use your own ISR routine, and transfer what you need from VDP RAM when you need it. For that matter, you might could do with the list source in the same bank of ROM and forget the idea of a CPU RAM buffer.

ISR lists can be severely clunky, obnoxiously long with duplication, just have to plan around that issue, maybe using some modifications of the sound list (extra command for looping, etc.) I have a script which converts from VGM to sound list, though it slips up on some tricks like frequency sweeps where only the second byte of the command gets sent.

ISR lists can be severely clunky, obnoxiously long with duplication, just have to plan around that issue, maybe using some modifications of the sound list (extra command for looping, etc.) I have a script which converts from VGM to sound list, though it slips up on some tricks like frequency sweeps where only the second byte of the command gets sent.

I guess the reason so few TI games have music playing during the game is that the ISR player is single channel, i.e. it doesn't allow a music sound list to play at the same time as one or more sound fx play lists?

I guess the reason so few TI games have music playing during the game is that the ISR player is single channel, i.e. it doesn't allow a music sound list to play at the same time as one or more sound fx play lists?

Likely the case for the built-in ISR. The only way around this would be to stay ahead of the frame and do manual mixing.

What I don't have is an editor for sound lists that's close to being as easy to use as MOD2PSG2. Perhaps the solution is to use OLD CS1's script for converting VGM into sound lists, but changing it to use calls and repeats is probably not an easy task. Changing my own sound list ripper to support calls and repeats is another option.

I'm also considering using your EPSGMOD player again, but did that use less RAM than the VGM player? And didn't it have problems with the pitch of periodic noise used as bass?

At the point you are having to make a lot of changes, I see no reason to not use a more advanced player if you can get its memory usage down. In any case, if you want to use my script it is in Rexx. I can run it against any VGM you like. Think we did that in another thread some time ago.

I'm also considering using your EPSGMOD player again, but did that use less RAM than the VGM player? And didn't it have problems with the pitch of periodic noise used as bass?

It looks like it uses about 134 bytes, so IIRC that's comparable. I believe there was some way to correct the bass notes (as the tracker assumes 16-bit shifts), but it's been quite a while since I've looked at that. It was a nice tracker though... I still recommend it for VGM export.

It may be more work than you want to do, but although the "e"psgmod format was kept private, the full psgmod format that the tracker can save in was public information (again, IIRC). You could write a converter from that to your list format that calls each pattern, thus preserving your jumps. Alternately (and this is horrible but something I'd probably do) write each section as a separate VGM, run the converter to playlist, and then just write the core block that calls each section by hand.

It looks like it uses about 134 bytes, so IIRC that's comparable. I believe there was some way to correct the bass notes (as the tracker assumes 16-bit shifts), but it's been quite a while since I've looked at that. It was a nice tracker though... I still recommend it for VGM export.

It may be more work than you want to do, but although the "e"psgmod format was kept private, the full psgmod format that the tracker can save in was public information (again, IIRC). You could write a converter from that to your list format that calls each pattern, thus preserving your jumps. Alternately (and this is horrible but something I'd probably do) write each section as a separate VGM, run the converter to playlist, and then just write the core block that calls each section by hand.

I forgot that wrote a Java program to adjust the bass notes in epsgmods 5-6 years ago.