orbitaldecay

Yes! I was so happy when I read this in the ycombinator thread:

I will certainly be happy to share the code I have written once it is released, and I'm sure Asmusr will be too. So you can expect to read up on some new tricks once we have this thing out in the wild

The site cannot be accessed without an invitation. The unspoken demoscene rule is to remain quiet about what we're working on until it is finished for maximum wow factor Code is being actively developed at this time and I don't want it distributed (yet). But you can expect some screen shots to get posted here as progress is made.

Pretty much all discussion of this project has moved over to the (very active) slack page at https://ti-994megademo.slack.com. If you're interested in contributing art, music, or code then shoot me an e-mail at orbitaldecay@gmail.com and I'll get you hooked up with a login.

For anyone else who may be wondering, I was making two mistakes: 1. I was using a PSGMOD file when I should have been using an EPSGMOD file (there is a difference) 2. VDP register one didn't have interrupts enabled!

Thanks for the clarification, Tursi. I also managed to get better results with the Lena pic by tweaking the Luma and turning on the histogram. Yeah, that's pretty good thinking. Right now I'm toying with keeping the control code and various common routines in lower 8k (like the music player -- there is also plenty of space leftover for character sets and what not) and then keeping the currently playing song in the upper 24k. This will make it easy to have one song play over multiple screens (and it's pretty much the only place a song will fit contiguously). Depending on the song, there will probably be some memory leftover for various screens to tinker with. Edit: Also, Tursi, any clue why the following code isn't working when I have a psgmod 2.04 example song loaded at >A000? LI R0,>A000 BL @SGPLAY SPIN LIMI 2 LIMI 0 JMP SPIN

@Lee: Thanks for posting your example. That way is nice because it doesn't require any assembler specific directives. @Asmusr that's more along the lines of what I was looking for. Too bad it isn't supported in more assemblers.

Hey Lee, thanks for your response. I am quite interested in your method for loading coding into RAM from the cartridge and jumping to it. How do you set the origin of the labels appropriately without using AORG or something similar?

This question is specifically about cartridge development using assembly language. I have noticed with all of the assemblers that I've used, it is necessary to set AORG >6000 at the begining of the file to produce any output (otherwise the resulting binary file is filled with zeros). If I set the origin to >6000 at the begining of the file, then copy some code (say to >2000) and attempt to set AORG >2000 later, the subsequent symbols have the proper values, but the output past the second AORG is all zeros! Does anyone know why this is, or how I can achieve what I am attempting to achieve? If it helps, I'm currently using xa99 for assembling and l99 for linking. Thanks! Edit: I have also tried RORG and DORG, though I admittedly don't really understand what these are supposed to do

Oh duh, great idea. This solves so many of the problems I was thinking about. It's pretty likely that the entirety of the code will fit in the 32K expansion and we can just do bank switching to access the data that's necessary at any given point. I'll start working on some code to do that.

Thank you again. Is any of this documented anywhere other than the classic99 source code? Neither changing C to 8, nor changing C to 8 and padding the file up to 32K seem to work (in both cases I don't even get a menu option) Edit: Also tried [usercart0] ; *** Lena name="Lena" rom0=8|6000|2000|mods\lenac.bin rom1=8|6000|2000|mods\lenad.bin rom2=8|6000|2000|mods\lenae.bin with inverted and non-inverted bank switching to no avail. Edit x2: Nevermind. It appears I made a mistake. The magic words to get the rom running in classic99 are: copy /b .\src\bin\lenac.bin+.\src\bin\lenad.bin+.\src\bin\lenae.bin+.\src\bin\lenae.bin .\lena8.bin and load lena8.bin with Catridge -> User -> Open. Notice lenae.bin is added twice to pad up to 32K. Thank you again for your help! Onto the more interesting question: what are your thoughts on the build system and banking code?

Thanks for your help. When I do copy /b .\src\bin\lenac.bin+.\src\bin\lenad.bin+.\src\bin\lenae.bin .\lena8.bin and loading lena8.bin with Cartridge -> User -> Open, the option doesn't even show up on the menu. When I add [usercart0] ; *** Lena name="Lena" rom0=C|6000|6000|mods\lena8.bin to the INI, then clearing >6000, >6002, or >6004 switches to bank 0. :/

Ok, I am loading a cartridge with the Cartridge -> User -> Open dialog. It sounds like that's the default behavior of classic99 and I probably need to modify the ini for it to do something else. I'll read into this and report back for anyone who is wondering. Edit: I RTFM and dropping the .bin files in the MODS directory and adding the following lines to my INI file does something strange: [usercart0] ; *** Lena name="Lena" rom0=C|6000|2000|mods\lenac.bin rom1=C|6000|2000|mods\lenad.bin rom2=C|6000|2000|mods\lenae.bin Clearing >6000, >6002, or >6004 switches to rom2! Tursi, help!

Nice to see you here, Ramon. I am working on getting together a toolchain for building a (up to) 64 bank cartridge. Obviously running Asm994a 64 times is not how we want to build this thing while we're developing it. Currently I'm using xa99 and l99 in a batch script. Attached is what I have so far (just unzip and run make.bat; the .bin files show up in \src\bin). I'm interested in hearing feedback on how I have setup the bank switching mechanism and the build scripts (particularly from people who might be interested in contributing to this). There is a file (MAIN.A99) that gets COPYed into the begining of each bank which contains a NBANK (next bank) function, which will switch to the next bank when called and jump to the end of the common header (stuff in MAIN.A99). Also, there is apparently something I am not understanding about the default bank switching on classic99. When I clear >6000, it switches to bank 0 (in this case LENAC.BIN). When I clear >6002, it switches to bank 1 (in this case LENAD.BIN), but when I clear >6004, it switches to bank 0 again! Why doesn't it switch to bank 2 (i.e. LENAE.BIN)? Do I simply need to modify the .ini to get this to work properly? I am sure there are many bank switching mechanisms in use. Any good links for reading more on this? Lena.zip

Thanks for the tips.. I'm by no means proficient with the software

This evening I made a multi-bank cart that loads an image. Took a little research to figure out how to do it, so I thought I'd share my results in this thread in case anyone else is trying to do the same (after all, what is a good megademo without some nice graphics?) Dithering didn't come out so well, but even convert9918 has its limitations. Anyway, you get the idea. LENAC.A99 LENAC.bin LENAD.A99 LENAD.bin LENAE.A99 LENAE.bin

Yeah, as Asmusr points out, the later has been done on MSX. I had never seen it done on TI, though after some reading and thinking it seems that this can be done on TI as well? Cool B) Quite excited to see the results of this! Also, does anyone know how the name table should be laid out for Tursi's convert9918 program using the Bitmap 9918A format? I'm doing a regular 00, 01, ..., FF, 00, 01, ..., FF, 00, 01, ..., FF but I'm getting some patterns swapped around Edit: 00, 01, ..., FF, 00, 01, ..., FF, 00, 01, ..., FF is right. I just had a bug in my code!

Excellent. I need to dig into the source for your 48 sprite code I think you posted that in the thread? Ah, OK. After some reading I think I follow this now. Good to know. Thanks for the info. I think it is a good idea to stick within 512k at this point for all of the reasons you folks have provided.

I was thinking of some of the tricks that are used on the MSX1 to vary output color which aren't available on the TI, but I believe you are correct in saying that the palette on the TMS9918 is always technically fixed. Forgive me; I don't know much about bank switching. When you say "bank the whole thing", do you mean that the entire 8K is swapped out when a bank switch occurs? I assume a switch is triggered by writing to some address in cart space. Is this expensive in terms of clock cycles (which would obviously limit the possibility of having tables larger than 8K)? If it's hard to burn a cart larger than 512k, then that's one more reason to keep it under 512k

Yeah, I figured anything close to accurate scanline timing would be impossible from my limited experimentation with the TI. Your 48 sprite demo is particularly impressive and seems relatively easy to do. I can see such an approach being very useful for some fake bob effects. Something like the bob effects in this intro I watched recently and has been on my mind: I thought I remembered correctly that a cart swap reboots the machine. Bummer. I agree that 512k is probably plenty. An uncompressed fullscreen bitmap in graphics mode II will use somewhere around 13k I think, throw a few of those in, some animated sprites, music, etc. Precomputed tables (sine tables, etc.) stored on the cart might be my biggest concern when it comes to space requirements. I imagine the largest contiguous array is limited by some bank switching mechanism that is desirable not to use too frequently? I would be interested in how this works in code, if there are any examples floating around. (Edit: As an afterthought, this seems like a really great opportunity to come up with some new tricks ) The memory map here seems to suggest that there is only a 4K window for the cart (edit x 2: actually, it looks like 8k of contiguous cartridge memory is available at any given time?). It will be interesting to see what can be done by simply polling the VDP status alone. Creativity thrives on restriction, in my experience

Cool! Any level of involvement is welcome, even just consultation and ideas would be very useful Per your and Asmusr's recommendation, the VGM compressor and playback tool sounds like the way to go. Thanks for the links! I would like to see a TI-99/4A category on pouet as well, but first we need to make some demos Per 512 KB cart: I'm 95% sure this will be big enough to store everything we'll have the time and energy to make, but in the event that we need more space has anyone ever experimented with multicart software? I can't seem to remember if swapping out the cart reboots the machine? Magellan is exactly the sort of tool I was looking for, what is the full screen limitation all about? I'll just have to take a closer look at it. I don't exactly have a list what sections and effects I'd like to see in the demo, but there are some obvious classics that will work on the platform. A lot of inspiration comes from dvik and joyrex, who did things with the MSX VDP that no one thought was possible. Some of what is in the following links will be nearly impossible to do with the CPU in the TI, but inspiration comes in the form of: (still haven't figured out how half of that is possible) ... etc. The fixed palette and lack of vblank interrupt make it tricky / impossible to do some effects, as you've mentioned. Of course, this challenge is exactly why I'm so interested in this platform Not OT at all. This is exactly the kind of stuff I was looking for. Thanks for the link! Thanks for all the kind words everyone. I'm going to be a little busy over the next month, but I'd like to get started on this project after that. If you're interested in participating, start thinking about ideas for screens and effects now

I've answered question (2), as PSGMOD can be found in this thread. Are any of the authors available to share current status in terms of permitted use? There seems to be some debate in that thread as to whether or not what is posted is actually permitted to be used.

Myself and some of my comrades have been tinkering with the idea of writing a megademo for the TI-99/4A as, to my knowledge, no one has endeavored to do such a thing. If you aren't familiar with demos or the demoscene, please read some of these links. I have several questions to pose to the community as a whole: 1. Do any of you know of any useful tools for creating fullscreen graphics to be displayed on a TI-99? Some of the tools for the MSX might be useful here as they use the same VDP, but the fixed palette on the TI-99 might be a problem. 2. I vaguely recall hearing about some music player code having already been written. Does anyone know where I can find this offhand? Is there a tracker or VST plugin for this? 3. I am a programmer, and I have cross-assembled TI-99 cartridge code before, though I have not written any code to be loaded from a floppy (which would obviously be necessary for a demo containing lots of graphics and music). Does anyone know offhand how painful it would be to write code to span multiple floppies? 4. Are YOU interested in helping out? I know several artists and musicians who are interested in this project and can deliver, but so far I am the only coder on board. It's going to be a nice first for the platform and would be a cool thing to have your name attached to. Just sayin' Timeline for the project will be roughly the next 8 months, as I'd like to release it in January 2017 at the Synchrony demoparty in NYC (so bonus if you're on the U.S. east coast and interested in attending). If that particular party doesn't materialize, the release date will probably be July 2017 at @party in Boston. Thanks for reading, and I hope this tickles the fancy of some of you kind folks.

Sweet. Thanks artrag and Asmusr-M!

Thanks so much for sharing source for the software sprites. They look very nice. Let me know if you find the thread or source for the vector graphics. I was thinking of doing something similar and would love to see how you chose to implement it.