Asmusr

Yes the error code is 6.

No, that didn't change anything. Michael, I understand how MESS maps the different PEB slots to different cards, but how does the floppy controller cards map to the floppy drives, e.g. if you have both the tifdc and the hfdc in the PEB?

When I try with the hfdc controller I'm also getting the FILE ERROR message. This is just a generic message I display whenever the DRSLNK OPEN command returns an error. A possible explanation is that I'm using a non-standard DSRLNK routine that I found at: http://atariage.com/forums/topic/163692-ea-file-access/#entry2071618 I'm also using some boot tracking code from "The Art Of Assembly — Part 7. Why A Duck? By Bruce Harrison 1991", but this seems to work because is has correctly detected DSK1. I will try with another DRSLNK routine that Willsy provided to see if that makes a difference.

Yes.

Thank you, yes it's working fine, and so much faster than loading the object file using call load. I noticed this is also somehow based on SysTex, but perhaps only to load the loader?

It's working fine for me in MESS (0149b_x64), it just takes a little while longer to load the files during which time the screen will be blank. You can turn on the F18A mode be pressing F. Are you using Windows or Linux?

Certainly, a great honor for me. But you should be prepared for updates. BTW, here'a a link to the disk for those who are not logged into AtariAge: Sorry, no longer valid.

Sometimes is right that I'm looking for a solution that works on my real console. I have 2 XB carts but unfortunately no RXB cart. [Edit] I should perhaps clarify that I just need to load the code at >A000 and run it. I don't need to return to basic later and I don't need to load or call any console routines.

To return to my original question, the game is now available in the Titanium thread but without an XB loader.

Titanium is my first game for the Ti-99/4A written purely in assembly language. The name is a reference to the C64 game Uridium - a favorite of mine - from which I have borrowed many ideas, and, of course, to the TI. The game engine and the graphics on level 1 are based on my half-bitmap mode, vertical scrolling demo. (I would like to do a proper port of Uridium for the TI at some point, but that should be based on a different technique for the scrolling.) The game requires a disk drive, a 32K memory expansion, and a E/A cart or similar to run it. To start the game, insert the disk in any drive and use E/A option 5 to run DSKX.TITANIUM. I have not tried it with a real floppy drive, but I expect it to work. The gameplay is very simple: shoot all the targets, e.g. pyramids, to reach the next level. Avoid the blinking spheres and the enemy ships. Use joystick 1 or S, D, E, X + space to control the ship. P pauses the game. I don't know if it's too easy or too hard - it's difficult to tell when you have tried it so many times. This is the first game I'm aware that’s using the F18A, but only to avoid the sprite duplication issue that exists in the old VDPs (9918A, 9928A) in half-bitmap mode. If an F18A is detected the program uses a standard half-bitmap mode with only one pattern table. If an F18A is not present it uses three pattern tables, but still only one color table. This eliminates the problem on the old hardware, but also lowers the frame rate because it doubles the amount of data that must be sent to the VDP. If you press F on the start page you can manually switch between F18A mode and standard mode. This allows you to see the sprite duplication problem in action on the old hardware, and can also be used to increase performance on MESS where the F18A is not detected (the F18A is detected in Classic99). I'm using Tursi's mod player for the music on the start page. I tried to compose my own music, but it ended up sounding very similar to the Blade Runner, so I decided to use that as my main theme. Within the game I'm using my own, simpler sound player and excerpts from Bach's 'toccata and fugue in d minor' - a reference to Gyruss, which is another favorite of mine. I consider the game in its present stage a beta version. I welcome suggestions for improving the gameplay, but major additions at this point are likely to slow down the game. For now I will fix any reported bugs and release the first version, and in a month or two when I regain some energy I may release a version 2. More levels/maps could easily be added without affecting performance. I include the full source code and data files. The maps were created using Magellan, the music using mod2psg2. Thank you to everyone who has helped me on this project. It has been very interesting and a great learning experience, and I think it demonstrates that there's still some potential left in the old TI. [Edit 14 Aug 2013] Added version 1.0 attachment. Titanium_1.0.zip. An XB loader is now included, and the E/A 5 file is called TITA. 64K bank switched (379) ROM image: Titanium3.zip

Great, thanks. Rich: it has to run at >A000. It uses all available memory - also >2000->4000 as buffers.

Can anyone help me writing an XB loader for my assembly game? It has to be loaded into high memory AORG >A000 -> D8C6. I tried to use SYSTEX, but it crashes. Thanks.

How about a multicolor mode version? :-)

My 6 yrs old son likes Scratch: http://scratch.mit.edu/ He also enjoys playing zero zap on the TI, but that's another story.

Thank you, this this really helpful to know. A divide by 16 would have been more sensible since this lowers the frequency exactly 4 octaves while a divide by 15 brings it out of tune, right? [edit: or is that wrong because it's tick rates and not frequencies?] I know you're not going to update the mod player any more, but I could in theory make a small conversion routine that takes a epsgmod file and multiplies the tick rate by 15/16 for the relevant nodes. I could also add it to the player code, but I guess that would be slow.

http://www.harmlesslion.com/cgi-bin/showprog.cgi?TI-99/4A

Thanks Marc, but I don't think it's just a numbering issue. The MOD2PSG2 tracker <http://www.smspower.org/Music/Mod2PSG2> has 4 channels: 0-3. Channels 0-2 correspond to tone generators 1-3. Channel 3 is the noise channel, and channel 2 is the channel you can use to control the frequency of periodic noise. In the post above I attached a .psgmod file for the tracker that uses this trick to play some low frequency nodes together with some ordinary nodes. My issue is that this didn't sound right on the TI using Tursi's mod player. I don't have an example ready to demonstrate this, so I will switch to XB instead: This makes a low freq sound. All tone generators are muted. 659 is the freq for a high E node. CALL SOUND(4000,110,30,110,30,659,30,-4,0) Now the first tone generator also plays an E (165 is the freq for a low E), but this is out of tune with the noise 'E': CALL SOUND(4000,165,0,110,30,659,30,-4,0) Now, the MOD2PSG2 tracker was written for the SN76489 chip, or probably for the Sega made clones. According to this article <http://en.wikipedia.org/wiki/Texas_Instruments_SN76489> there is a difference in the noise generator: "Although basic functionality is almost identical to that of the original SN76489A sound processor, a few small differences existed: the randomness for the noise channel is generated differently, and the Game Gear's version includes an extension for stereo audio output. The periodic noise is also 16 stages long on the Sega-made clones; this makes a significant difference for music/programs which use periodic noise, as sounds will play at 6.25% lower pitch than on the TI-made chips." So on the Sega system, the analogue to the second CALL SOUND statement above would probably play in tune. I think this might explain why my mod did not sound right on the TI. Sorry for rambling on. This is probably of little relevance to anyone else, but perhaps Tursi will have some information to add?

I noticed in the MOD2PSG2 tracker that you can produce this effect by controlling the periodic noise using a muted channel 2. If you set the frequency of channel 2 somewhere in the 4-5 octave interval and turn off the volume, and then set the noise channel to periodic noise that follows the frequency of channel 2 you can get some very interesting bass effects. But when I tried to do this on the TI-99/4A an awful high pitched tone was audible. I guess that's because of a difference between the noise generators in the SN76489 and the TMS9919. Is it possible to do the same in the TMS9919? lowfreq.zip

It does have some nice low bass nodes. Are they generated using periodic noise?

Do you mean something like this? X1=X1+SGN(X2-X1) Y1=Y1+SGN(Y2-Y1) Where (X1,Y1) are the coordinates of JR and (X2,Y2) are your coordinates.

Great, thanks.

Tursi, I would like to use your player for the opening screen of my game, if that's alright. I would really like a copy of the tracker v. 2.05 if only for the slightly smaller output file. I don't see why the author should object to that since the development seems to have stopped years ago. Do you think that could be arranged? Thanks, Rasmus.

A really useful feature would be if you could load a list file generated by Asm994a into the Classic99 debugger so you could see your labels and comments in the disassembler view. The code would need to have AORG set and it wouldn't work for self modifying code, but apart from that it doesn't seem to be that difficult to do.

Thanks Matthew. I think I will stick to the polling. Firstly I only have 6 unused bytes left in scratch pad! Secondly I'm writing to the VDP RAM pretty much all of the time, so I don't know when I could enable interrupts. For the interrupt to be useful for me it would have to break into my CPU RAM to VDP RAM copying routine, execute the sprite moving/joystick reading/sound playing routines and then return to the execution of the VDP RAM copying routine. That would ensure that no CPU cycles are wasted, but it doesn't sound like that would be possible.

In my programming I consider those features (auto-motion of sprites, sound processing, or QUIT key processing) undesirable, but the interrupt itself without those features would be nice to have.