retroclouds

Hey you other TMS9900 assembly language programmers out there What format would you guys propose ? For starters my proposal would be to go for a basic export format. Something not too complicated nor optimized. This would keep both the Magellan exporter and the assembly player code easy (as long as no final format has been established). That is why I also requested the possibility to export color/map/pattern data as a raw binary file. That way if a developer sees a need, he can write his own converter for his specific needs. Any thoughts on that ?

If you are interested you also might want to checkout the TECH MANUALS section in the development resources sticky thread. Look for the "VDP Programmer's guide" for further details on the VDP. The thing is that the tables in VDP memory which are responsible for holding characters definitions, colors and tiles, sprites etc. are controlled by a bunch of VDP registers. In assembler these tables pretty much can be located according to the programmers' needs. Now in Basic and Extended Basic there are a lot more constraints as far as the size and location of the tables is concerned. And I have to mention it again, after having played with Mangellan a bit, this is a mighty fine tool

ok, I took the assembler export output of citymerg.mag and was able to make it work in editor/assembler after tweaking it a bit. I used the winasm99 cross-assembler and did the testing with the classic99 emulator. For testing you can just drop the MAGELLAN.obj file in your classic99 DSK1 folder and load it using EA#3. **WARNING** This is not an actual player. It's merely a dumb assembler program for testing the export functionality. magellan_asm.zip I made some adjustments that I'll try to explain below. Before we get into the details; Here is how I did the VDP setup for graphics screen mode 1. *************************************************************** * VDP graphics mode 1 ********@*****@*********************@************************** * VDP#0 Control bits * bit 6=0: M3 | Graphics 1 mode * bit 7=0: Disable external VDP input * VDP#1 Control bits * bit 0=1: 16K selection * bit 1=1: Enable display * bit 2=1: Enable VDP interrupt * bit 3=0: M1 \ Graphics 1 mode * bit 4=0: M2 / * bit 5=0: reserved * bit 6=1: 16x16 sprites * bit 7=0: Sprite magnification (1x) * * VDP#2 PNT (Pattern name table) at >0000 (>00 * >400) * VDP#3 PCT (Pattern color table) at >0380 (>0E * >040) * VDP#4 PDT (Pattern descriptor table) at >0800 (>01 * >800) * VDP#5 SAT (sprite attribute list) at >0300 (>06 * >080) * VDP#6 SPT (Sprite pattern table) at >0400 (>80 * >008) * VDP#7 Set background color to gray *************************************************************** VMODE1 DATA >0000,>01E2,>0200,>030E,>0401,>0506,>0680,>070E Color definitions * In assembler you only need 1 byte for setting both the foreground and background color of a color set. * Also the colors start with base 0 instead of 1 * This is my colorset statement. Note that I used BYTE instead of DATA here. CLRSET BYTE >10,>10,>10,>10,>10,>10,>10,>10,>00,>BA,>3C,>45,>61,>10 Patterns * I did a raw dump to the VDP in a continious block. This means I first stripped the character code and inserted some empty patterns in the assembly source. Actually the idea of having the character code in front of the pattern code isn't bad. However it would be best to make this optional and go for a table driven solution as suggested by Matthew. Map data * I noticed that even though there are 3 screens, it repeatedly exports the same screen. Anyway, great job Howard! :thumbsup:

Thanks! I'm very excited about this and looking forward giving it a spin this evening when I get home from work

hmmm, I'd go for concatenated hex strings Keep up the good work

Another thing that comes to mind is to dump the pattern data and map data as binary files. That way a game developer could write their own converter for doing what they want do for their specific need (e.g. add RLE compression, colecovision format, ...).

Here is an idea for a basic exporter for assembly language. It's real simple as it doesn't invoke any RLE compression or such. However, the advantage would be is that the generated source is not heavily depending on specific player code. (You could just dump it to the VDP with VMBW for example). It means you basically just dump the data as a text file. EDIT: Coming to think of it, perhaps it makes sense to add an option for generating 2 files (1 with the color & pattern data and 1 for the map data). For the pattern data, I would propose to: 1) Add possibility to automatically generate a label for each pattern For the data map, I would propose to: 1) Add a label for each row (max label length; 6 characters). You could add some kind of autoincrement label generating thingy. 2) Put 8 tiles in 1 assembly source row. That way if -in a future version- you have like maps with 80 columns you just add the additional source rows. *************************************************************** * Color data *************************************************************** BGCOLR DATA 15 ; COLORS DATA >0B0D,>F000,>8060,>B0A0 ; DATA >7050,>F0E0,>F0F0,>E0E0 ; DATA >E0F0,>F0F0,>C0A0,>7030 ; DATA >0000,>0000,>0000,>0000 ; *************************************************************** * Pattern data *************************************************************** PAT1 DATA >FFFF,>FFFF,>FFFF,>FFFF ; PAT2 DATA >AF81,>0180,>1988,>85DB ; PAT3 DATA >36C0,>20A0,>9088,>00DD ; PAT4 DATA >6F03,>1D20,>0101,>01DF ; PAT5 DATA >0000,>0000,>0000,>0000 ; PAT6 DATA >0000,>0000,>0000,>0000 ; PAT7 DATA >0000,>0000,>0000,>0000 ; PAT8 DATA >0000,>0000,>0000,>0000 ; PAT9 DATA >0000,>0000,>0000,>0000 ; PAT10 DATA >021E,>7C7D,>FBFB,>F734 ; PAT11 DATA >203E,>CFEF,>DF3E,>7840 ; PAT12 DATA >3058,>68FE,>954A,>6438 ; PAT13 DATA >0000,>0000,>0000,>0000 ; PAT14 DATA >0000,>0000,>0000,>0000 ; PAT15 DATA >0000,>0000,>0000,>0000 ; PAT16 DATA >0000,>0000,>0000,>0000 ; .... *************************************************************** * MAP Data *************************************************************** *-------------------------------------------------------------- * Line 0 *-------------------------------------------------------------- LABEL0 DATA >0203,>0000,>0000,>0203 ; 0-7 DATA >0000,>0000,>0000,>0000 ; 8-15 DATA >0000,>0000,>0000,>0000 ; 16-23 DATA >0000,>0000,>3038,>020A ; 24-31 *-------------------------------------------------------------- * Line 1 *-------------------------------------------------------------- LABEL1 DATA >0203,>0000,>0000,>0203 ; 0-7 DATA >0000,>0000,>0000,>0000 ; 8-15 DATA >0000,>0000,>0000,>0000 ; 16-23 DATA >0000,>0000,>3038,>020A ; 24-31 *-------------------------------------------------------------- * Line 2 *-------------------------------------------------------------- LABEL2 DATA >0000,>0000,>0000,>0000 ; 0-7 DATA >0000,>0000,>0000,>0000 ; 8-15 DATA >0000,>0000,>0000,>0000 ; 16-23 DATA >0000,>0000,>0000,>0203 ; 24-31 .....

Thanks for the update! Just gave the "character look" a try. One suggestion; would it be possible to show the character definition without having to click on the tile on the map, e.g. by just "hovering" over the map? Dunno if this might cause a performance issue. Also once you click, the "character look" mode ends automatically. Would be cool if it would stay in that mode until it gets explicitly turned off by the user. Anyway, these are just some suggestions. Magellan is already very intuitive and I like to play around with it. Here are some more suggestions: 1) Would be cool if you could define "areas" in the map that serve a special purpose (e.g. exit for maze or stuff like that). In magellan you could then add a code + description to these areas. I know this would highly depend on the export format AND the game engine processing the map. But you could define extra data statements that contain the code + tile positions of these "areas". 2) Sprites: Not really sure hiw to fit them in. But you could add a sprite layer on top of the tiles. 3) Except for the format of the data it exports, Magellan is actually a TMS9918 drawing tool so it would be easy to support colecovision as well. Just an idea

Get them while you can, it seems there are currently 3 CF7+ devices up for sale at ebay. Check here: eBay Auction -- Item Number: 200462657139 retroclouds

Hi Bones-69, why not start your own thread on your adventure game here in the TI-99/4A programming subgroup Would you might sharing some more details on the storyline and also what programming language you will be using. Will it require the 32K memory expansion and disk ?

If you are in to programming TI-Basic you might also want to check our TI-99/4A Games Programming subgroup at atariage. Check out the development resources sticky thread for manuals on programming Basic and Extended Basic.

You can grab the module archive right here. The .bin files are ROM/GROM dumps that you can use in one of the popular TI emulators. If you want to run the modules on a real TI-99/4A you will need to transfer them to a disk or CF7+ disk image AND you will need a gram kracker or comparable device. Most of the games also exist in a "disk" version allowing them to run from 32K RAM memory expansion. These are either hacked or prototype versions. Dunno if these are available in a single collection, so you'll have to look around for those.

Played around with Magellan during my lunchbreak, and it looks very promising. Well done! For Tutankham I'm thinking of doing some additional levels. Perhaps even make a little contest out of it where folks can submit a screen and the best ones get included. I was thinking of building a map editor myself, but after seeing Magellan ... :-) Here are some more ideas: * It would be nice if you could toggle a mode where you don't set a character tile in the map. Instead if you move over a grid cell it could highlight the matching character in the charset and show its pattern. * Possibility to have multiple screens in memory where you can jump from one screen into the next one. * Possibility to set number of columns/rows on a per screen basis. * Example: Screen 1 = screen of 22 rows with 60 columnsm, screen of 22 rows with 100 columns, ... * I know that adding more and more features can easily make a tool unusable for novice users, perhaps a menu level "novice" or "pro" could then be set for hiding the more advanced features. * Would be cool if you could "import" screen data into Magellan, e.g. raw VDP dump. Guess that the map file format is not yet finalized, would you mind sharing details how it is setup ? * Export functions for assembly language usage (I'd love to do something for SPECTRA)

All of the cartridge games as well? Tempest yes, PM sent.

hhmmm, I think all games are available in .DSK format

I'm afraid it won't work like that. If you bought a bare TI-99/4A console it only has 256 bytes real memory. It does have 16K memory attached to the video processor but you can't run assembly programs there. The easiest way to get going is to get a CF7+ compact flash device. The CF7+ has 32K real memory and most of the game roms are also available in a disk version which you can store on the compact flash card. It should be possible to load the disk version of the assembly game via cassette, but you still need the 32K memory. There was an article about that in one of the Smart Programmer issues. Then again I don't think it's that much fun waiting for ages while the game loads from tape.

Looking forward seeing how this further develops. Tried it with my company computer (which has an older java runtime) and can confirm that it doesn't work there. Will try with my home computer, I mean my PC at home As far as the export function is concerned; You might want to add an option for generating the DATA statement for inclusion in assembly language source. If this turns into a real map editor, we could perhaps work out a format for easily drawing the generated screens in assembly language? I would be interested in adding such routines to my SPECTRA library

Jaime has a CF7+ up on ebay. Grab it while you can. Check here: eBay Auction -- Item Number: 200460142569

Excellent work, thank you!

* What level of understanding should I assume the reader has? I'd say the reader should already have some assembly language experience on other retro console/computer systems. * What level of detail do I need to go down to? Tough question. Perhaps it would be good to release intermediate versions of the articles and get feedback from the audience. That way you'd get a feeling where the attention needs to go to. Good luck!

Agree, that is why I was thinking of a tutorial for homebrewers who already have programmed assembly language on other retro systems.

Updated the resources: TECH MANUALS 1. Assembly Language - Added reference to COMPUTE'S Beginner's Guide to Assembly Language on the TI-99/4A 2. Basic / Extended Basic - Added reference to COMPUTE!'s Programmer's Reference Guide to the TI-99/4A - Added reference to COMPUTE!'s TI Collection volume one

Thanks for putting this up!

Although I'm not so impressed with the book now, it is the book that opened the door of 9900 assembly to me and made it possible for me to make working programs; so for that I will always give it due credit (and I will not give up the copy I have had since 1984.) As for beginner tutorials, I am willing to write some (I have already started, although it is panning out to be more of a book than individual tutorials.) However, instead of trying to guess what to write, if anyone has something they would like to see in the way of a tutorial, please post it here and I (or anyone else who is interested) will try to write it up. If you plan on making a request, please be somewhat specific, since "how do I write a game in 9900 assembly" is not a tutorial. Matthew Well reading your posts about the assembly language sound player, I'd say you have a clear, precise and interesting way to describe stuff. I'd love to see you write a full tutorial (book) on "how do I write a game in 9900 assembly" Seriously, something in the line of the Lottrup book, but updated and addressing todays' needs. I don't think we have homebrewers who want to code using the mini memory line-by-line assembler Perhaps a tutorial focusing on coders from other retro gaming platforms (atari 2600, 7800, colecovision, ...) who already know how to program assembler. Here are some of the topics I can think about (in no particular order) 1. Short introduction on TMS9900 CPU (register usage, TI memory architecture) and cross-assemblers targeting the TMS9900. 2. How do I communicate with the VDP processor (VDP memory, graphic modes, SAT, color tables, pattern tables, ...) 3. How to setup sprites in assembly language, how to move them without using ISR routine. 4. Collision detection for sprites without using ISR routine. 5. How do I play a sound or tune. 6. How do I read the keyboard and joysticks 7. How to use the speech synthesizer in assembler 8. How to deal with 256 bytes of scratch pad memory 9. How to setup a game loop (or basic task scheduler) 10. Format of the cartridge header 11. What is bank-switching, how do I use it (trampoline code in scratchpad, jump tables in each bank, ...) 12. Debugging tricks, how to test using MESS debugger and classic99 debugger. How to test on the TI-99/4A using a 8K supercart. It would be great that, after reading the book, the future homebrewer has a good overview on how to write a (bank-switched) game running from the cartridge space

Just gave it a try in classic99. Love the introduction theme This game reminds me of a popular Atari game I used to play at the arcade (and I wasn't any better at it back then as I am now)