Tursi

I'm not claiming this one... just merging the other two.

My own c99 games are Super Space Acer, Super Sled Acer, and Waterville Rescue: http://www.harmlesslion.com/cgi-bin/onesoft.cgi?64 http://www.harmlesslion.com/cgi-bin/onesoft.cgi?28 http://www.harmlesslion.com/cgi-bin/onesoft.cgi?67 There's source, but they are very badly written. I've ported Space Acer and Waterville Rescue to the ColecoVision, and will be porting Space Acer back to the TI when I'm done improving it (though I need a new compiler.. )

hehe.. very cool. If you want to use ZomBXB the text file in the zip is about the limit of my writing skill

Heh... so now that the contest is done, Codex, do you mind if I take TI Farmer and mash it up with ZomBXB? I'd like to do an asm version that gets the speed I wanted to see on the Zombie side, and at the same time we'll grant Owen's wish of seeing them together.

I can't get super specific with C99 these days since I don't think I have all the disks anymore (though I'm sure they are online). I did several games with it, though. It's a fairly limited dialect of C and the code it produces is not very efficient -- but it does work. The basic process is first to write your program using the editor of your choice (normally Editor/Assembler, but it doesn't matter). Next, you run C99C in Editor/Assembler, and give it the input and output filenames - this compiles the code into assembly. Finally, run the Assembler to assemble the code into an object file. To run, load the object file, CSUP (which is the C library), any other libraries you need, and I believe START is the program name. You can use the Editor/Assembler image creation tool SAVE with C99 programs.. to do that, load C99PFI as the first modules, and C99PFF as the last one. After that, load SAVE and run it. The program must fit in the 24k bank to work this way. C99 programs used to require the Editor/Assembler cart be loaded, and would hang otherwise. I don't remember if later runtimes fixed that. I tended to use my own startup code which bypassed the copy from GROM and manually loaded the E/A utilities into the load bank by making it one of the program images. That probably isn't going to be a concern when you are starting out. Also... C99 programs will not run on a cartridge-only system, they require the 32k (because the stack is hard coded into the low memory bank). There are no switches to change that behaviour. Feel free to ask questions, and if someone more useful doesn't pop up I can try to remember.

I'm quite happy with ABC. It's short, yes, but I don't mind games for short. It feels like Afterburner but looks beautiful and the play is even faster, so I like the thrill.

I always had that problem, too... never really got it to work with any glasses I tried, including the new ones in the box.

I think he's using the terms himself to mean "Game RAM" and "Game ROM", and they are not the TI GROM or related GRAM devices.

I couldn't reproduce, and the fix I had in mind is already in the code... that said, if you take focus away (click on some other Window), that should completely reset the keyboard code and stop whatever it's doing. I'd like to know what's happening so I can fix it someday...

Is this actually true? I've always been under the impression it doesn't actually do anything but set a flag... have you tested that? Damn it, I have too many things to test...

hehe... though it was a mistaken question, brought on by lack of sleep and memories of a much older bug I once ran into. I've fixed this bug and uploaded a fixed Classic99. The keyboard issue from another thread I'd already fixed the way I expected, and couldn't reproduce, so no change there... The sprite position bug affects any sprite row 1 (XB) and higher (though I still need to test that sprites fade out on the top on a real console.. I can't right now as my cartridge port is otherwise occupied ) http://harmlesslion.com/software/classic99 - v340b

Looks like some nice stuff brewing! One comment on the disk files - there's no difference on the disk between DISPLAY and INTERNAL, it's just a flag in the header.

Have found and fixed the bug, will publish a new version later (with the focus keyboard fix too).... it would specifically affect fade-in from the top including the very top row, row 1, and cause the sprite to be drawn one row lower than it should have been. Thanks for the clear example of the problem!

Confirmed. (And validated on real hardware). Well. This is strange. Will look at it a bit more after work, I'm late.

Neat sounding device, I will definitely take one if orders are still open.

Usually this happens if you use a keyboard shortcut to take focus away, for example, Alt+Tab -- Classic99 sees the alt and the tab down events, but Windows never delivers the up events because it doesn't have focus anymore (now that I think about it, it would be easy to clear the keyboard state when focus is lost, let me take a note on that and I'll code up that fix). If you are running CPU overdrive, the keyboard repeat delay ends up way too short, and my workaround for that doesn't work in Extended BASIC, so you get massive keyboard repeats, although that at least should respect the keyboard. There's no explicit reset built-in, but tapping the key that is repeating should stop it. Tapping Enter should clear any stuck meta-keys (control, alt, shift).

The real question is, "Where are the other sprites?" CALL COINC(ALL) means ALL sprites, not just the ones visible on the screen. XB can actually throw a collision for sprites located off the bottom of the screen, where they all sit till they are in use (as Sometimes99er alluded to). (edit: that statement was full of it ) Just to verify, try bringing up the other sprites and placing them at notably non-touching locations, or like he suggests, try 1 and 2. I believe I tested that real hardware sees collisions off the bottom of the screen... but that was years ago and is worth testing again, since I don't remember coding that in Classic99

The CF7 just pops up on EBay semi-regularly, as far as I know that's the only way to get one. I don't have one, but I don't think you can use the CF7 and the PEB at the same time.

Yeah, there are all kinds of TI keyboard mechs (they are all electrically compatible though)... everything from discrete switches to printed plastic contact sheets. The switch ones seem to last forever unless they are in really dirty environments, the contact sheet ones I've had little luck with (and I don't know if they respond to being cleaned). More than likely the issue is oxidation and lack of use, so it might be possible to scrub them up, but it's generally easier to replace. So many spare keyboards flooded the "experimenters" market after TI dumped the console that they still aren't really rare (I have a box of them myself ).

9228? How very interesting! Slightly higher resolution, it appears (256x210), and 16 full colors from a 512 color palette, plus 80-column text, high resolution (512x192) and hardware scroll. Plus still more... how very cool. It does appear very similar to Sega's chip. This would have been a fantastic chip to have, it has all the features I was wishing for. The datasheet is all over the net... there's a note in an old TI newsletter that the 9938 was derived from the 9928 (but was not compatible), many of the otehr hits are in Japanese. Interesting.. it would have been nice to have had this chip!

Not bad... it's just double-buffering, though (both the screen and the character set). Gives a nice smooth result, though

I took a stab at this actually.... but couldn't quite get the results I wanted (she kept winning!!) Hehe, actually, I didn't do the card side, though it looks like there's more than enough room in 30 lines of code. Anyway, there are way too few characters available in XB to get the graphics I was going for, so I dropped it. Also, couldn't decide on the best colors (so I put in options! heheh...) Even though she didn't turn out well, not sure if I /should/ post screenshots.. maybe source then (NSFW): 1 DATA 1F3FF7E4F8B8C6ECE0A81C8CCCE4E4671CE6FB2D98485F79F3776F0FCDE76004,00000080E061678FE7E1E9EFEFC70F0F010F0D1D7FFFFFFEFFFFFFFFFDFDFDFF 2 DATA F0F0ECE834F4F4F47EBFBDDFDDCFEFFE000000000000000000000080C0E06011,00000000000000000000000000071FFF0000000000000000000000007EFFFFBF 3 DATA 6323313918181C0C0E0606070303010126B380CCE1F379E4473F7F3F9F8FCEEF,3F7FFFFEFFFFFFFF7FCFDFDEEEF0FCFFFFF3FBFF7E98E3FFFFFF7F7FFFFF7F1F 4 DATA FEFF7F7E7EFFEFF3FCFFFFFFF7FFFEFE314F8F00C19FBD10CCCCD1F1F3939133,F3FFFFFFFBFDFEFFFFDFDFFFDBEDFC06FFFFFFFFFFFF7F9FCDFBFFFDFFFFFF7F 5 DATA 00000000000000000000000000000000F1586D3C16080C070000000000000000,FF3FF7FF7FB31FDF0000000000000000C3F0FFFFFFFFFFFF0000000000000000 6 DATA FCF81EF7F1FCFFFF0000000000000000666FC0C18F4FE7E30000000000000000,03007FFFFFFFFFFF0000000000000000FFFF1FC7F1FCFFFF0000000000000000 7 DATA 1E0663C09010004000000080000000060C2600080840030911130F0C0C802004,00000000006003070700000040410000010A010D3CFEFDF0C60FC3C98919380C 8 DATA 9070CCE8242464D01218199888C8C8C600000000000000000000000040002010,00000000000000000000000000031F7B0000000000000000000000003EFFF182 9 DATA 630300310000080C0000040202000000000100C0E04108E047073B3500010C87,14304446C2C180786C8686CEC46060E61E22607A3C00C1FF0C00014140002000 10 DATA 6463202040C0C100080F0CCC262706042104040080040C1084C00030A0800000,A202031F0340C00000000000000864040E5F3D8CCDEF6E0C0D01010000000000 11 DATA 0000000000000000000000000000000080000120000000060000000000000000,2000E0E030300C18000000000000000000200C01000000000000000000000000 12 DATA 08000087200006040000000000000000000000808104E0E00000000000000000,00003CC000000000000000000000000000000000000000000000000000000000 50 C(0)=9 :: D(0)=10 :: C(1)=5 :: D(1)=6 :: C(2)=3 :: D(2)=4 :: C(3)=11 :: D(3)=12 :: C(4)=15 :: D(5)=16 51 PRINT "0-CRAB":"1-AVATAR":"2-FROG":"3-SIMPSONS":"4-ANTIQUE" :: ACCEPT VALIDATE("01234")SIZE(1):A$ :: B=C(VAL(A$)):: F=D(VAL(A$)) 100 CALL CLEAR :: FOR A=12 TO 35 :: READ A$ :: CALL CHAR(A*4,A$):: NEXT A :: FOR A=0 TO 47 :: R=INT(A/16)*2+(A AND 1):: G$(R)=G$(R)&CHR$(A+48):: NEXT A 110 FOR A=3 TO 14 :: CALL COLOR(A,B,1):: NEXT A :: G$(0)=SEG$(G$(0),1,5):: G$(4)=" "&SEG$(G$(4),2,7):: CALL SCREEN(2):: CALL MAGNIFY(3) 120 FOR A=0 TO 4 :: PRINT G$(A):: NEXT A :: FOR A=1 TO 12 :: CALL SPRITE(#A,92+A*4,F,145+INT((A-1)/4)*16,17+((A-1)AND 3)*16):: NEXT A 130 GOTO 130 As for the smack talk, I get enough of that in the Jaguar section.

Moon Patrol offers similar smooth scrolling of its mountains with parallax to boot, but it doesn't get much attention. Of course, it doesn't offer the rest of that, which was indeed well done. I never saw Vanguard, I wouldn't mind seeing what tricks it used. We (well, I) took Parsec's scroll routine apart on the Yahoo list and I think it could have been optimized some. It hasn't been beaten, I feel, more because nobody's done it than because it's the best that can be done. Parsec achieved some kind of legendary status for that little piece of smooth scroll code. I take apart the Parsec code here: http://tech.groups.yahoo.com/group/ti99-4a/message/62752 Since that's the point of interest, I'll copy and paste that one. The point was that someone mentioned that Parsec copied the scroll routine to scratchpad RAM every single frame.

You're sort of crossing ideas here, though. For the scroll trick I am describing to work, you have to have everything predefined. Each table /must/ take 2k because that is the granularity of the VDP. Pre-defining it allows a very fast scroll - just a couple of cycles until you cross a character boundary and have to redraw it. You could try compression, but even full uncompressed writes to VDP would be tough to redescribe the entire character set in a single frame, unfortunately. (2k of data won't fit in vblank, making the scroll visible). You could do it if you restricted the number of characters - but then you are in the same situation as I described above. Restricting the number of characters is not necessarily a killer, it just depends on your background detail. Also, you can do a combination of the two - you have enough characters to define one screen, and dynamically update the character set as you move through the world. You just have to leave space in your character sets for the other VDP tables.. the SIT is the largest at 768 bytes, so that's 96 characters, leaving 160 characters available for the pre-defined scroll. You'd likely want sprites... you could use those 96 characters from one of the other tables for a fully distinct sprite table. That's enough characters for 24 of the 32 sprites, if you don't mind dynamically loading the patterns (which can be more easily staged in vblank). You could likewise double-buffer the sprite patterns, or even more than that, since you'd probably have 6 of the tables with unused space.

Sorry that there is not yet a more intuitive way... core functionality has always been high priority in the very limited time I get to work on it. There is one shortcut - if you are loading ROMs in the 'V9T9' format, which is also what MESS uses, you'll note they end with C.BIN, D.BIN or G.BIN. If all the files in the cart end like that, Classic99 has an auto-loader under Cartridge->User->Open, just select any one of the three files and it will find the others. If it's not in that format, or it's one of the newer bank switch carts, then there's no autodetect, and you must use the INI file method. It's on the TODO list to add the MESS RPK format, which will simplify things nicely (if I can find a non-GPL unzip library....) As for why they are separate files.. just legacy. Each file is a dump from a single type of memory, usually. C is the Cartridge ROM at >6000, up to 8k. D is the second bank of Cartridge ROM at >6000, up to 8k, used for Extended BASIC (and Atarisoft carts). G is GROM space, usually concatenated together into a single file, loading at >6000 and supporting up to 24k. The MESS RPK format zips the files together and includes an XML layout file, which is surely the best way to go forward. XML is nicely extensible so we should be able to add manuals, screenshots, and cover scans to it as well. (edit: and I need to update that doc, apparently.. as far as I remember it supports up to 16 ROMs per cartridge now )