retroclouds

Thanks sometimes99er, I have some plans for this font

you mean Peyo? because i'm not from Belgium. Yes, Peyo and yes I know you are not Belgian but I am so am I

I was specifically thinking about the CF7 compact flash device. Guess it won't work there as it emulates normal disk drives ?

Did a cross-post in the colecovision programming section. Check it out here.

Hi colecovision friends, I'd like to point your attention to Magellan. Magellan is a map editor targeting the Texas Instruments TI-99/4A home computer or more generally speaking the TMS9918 VDP. Codex (the programmer) did a great job and Magellan already sports some nice features in the current version. There is no specific colecovision output format at this time, that is why I'm hoping someone could chime in to help with the specs for that. However, Magellan is already able to export binary files. The file format is documented, so a Z80 player could easily be written, I hope Check here for the details. Please note this is still a work in progress. The TI-99/4A and Colecovision communities aren't that large, that is why a joined effort could make sense. We can always use some more ideas for new features, etc.

Check the ninerpedia wiki here. Look for sections 3.5-3.9 I'll update the development resources thread shortly, making reference to the wiki and TI-FAQ.

Yeah, wished I had one of these. Unfortunately I don't have the space for it

Absolutely. I sure hope when things have cooled down a bit, opcode will continue doing his great work

Bumping this thread; just want to check how Magellan development is doing ? I know in the past we talked about a "feature request" list, at one point it was even added to one of the posts. Is that still the most current one, or does a newer version exist ? Would like to suggest to add it to the first post if possible

Thanks for the GPLLNK routine willsy! I'm currently working on my spectra2 arcade game library and would like to have a gate into GPL. Still working on the scratch pad memory setup and maybe I'll be able to squeeze the 32 bytes in

hehe, thanks As a matter of fact I've been looking at GPL a bit closer lately. That is TI-Intern and the GPL programmers manual both available here. GPL does have some very nice features. They for example have the COINC instruction for doing sprite collision checks. Something you don't want to do yourself in assembly language. I dunno of this instruction was ever used though

Are there any good examples on how to do sector and file access in assembler ? Does a PAB always need to reside in VDP memory or can it be in RAM as well ?

If I wanted to call a GPL routine from my assembly language program and return safely, what would be the things I have to take care of ? 1. Setup scratch-pad memory as required, GPL workspace in particular ? 2. Enable interrupts, is that really required ? 3. ????

Yes, it does look like a MSX2 game, but it is an MSX1 game. It won 2nd place in the MSXdev'06 competition. That's a competition for development of new MSX1 games. Check here. It does have very smooth scroll, which we all know is very hard to do on the TMS9918. http://www.youtube.com/watch?v=dH6gtS_2iGM

I'd love to see "Malaika: Prehistoric Quest" ported from MSX1 to the Colecovision (and to the TI-99/4A as well). That is a fine homebrew game indeed. Don't know if it would be possible on the colecovision with 1K of RAM though. Check the screenshots here.

Suprisingly, Car Wars is not an assembly language game. It is written in an interpreted language called GPL (Graphics Programming Language). GPL is noted to be slow. Well, I think Car Wars really shows that fast games are possible in GPL as well

I want to play it now!! Seriously, it really is crazy how life can get in the way. Somehow I wasn't able to do much TI stuff myself lately. Went through the thread and from what I understand you already got real far. I do am looking forward playing this game, when your conversion is done

Very cool

Yes, that would be double buffering. As mentioned, I suppose you are using graphics 1 mode. For displaying a screen in that mode you need 768 bytes [32*24] for the tiles and 2048 bytes [256 * 8] for the patterns that make up the tiles. This means you need a total of 2816 bytes for displaying a screen (not including the color table). Knowing that the VDP has 16K of video ram this leaves plenty of space to "store" multiple screens in the VDP memory. By setting the VDP write-only registers #2 and #4 to the correct values, it will immediately display the new screen. From the VDP programmers' guide .... VDP register 2 ============== Register 2 tells the VDP where the starting address of the Name Table is located in VRAM. The range of its contents is from O-F. The contents of the register form the upper four bits of the 14-bit VDP address, therefore making the location of the Name Table in VRAM equal to (Register 2) * 400 (Hex). VDP register 4 ============== Register 4 tells the VDP where the starting address of the Pattern Table is located in VRAM. The range of its contents is from 0-7. The contents of the register form the upper three bits of the 14 bit VDP address, therefore making the location of the Pattern Table in VRAM equal to (Register 4) * 800 (Hex). Note, perhaps you should create a new development post for your project here on atariage. I'm sure quite some folks will be interested in it

Very nice! Also very interesting. I'm not a colecovision programmer, more of a TI-99'er (which has the same VDP). Do you mind sharing how the writes to the VDP are done ? Could imagine there are a few ways for speeding things up, which most likely you already know. Here is some of the stuff I used to do for the TI when dealing with the VDP. Should in some extent also work for the colecovision I guess: * Use assembly language for speed critical tasks * Use inline code instead of subroutine calls where possible * Avoid many small individual writes, instead use big block writes where possible * Guess the game screen is in graphics1 mode, so you should be able to have multiple pattern and screen image tables in the 16K VDP ram. 1. Fill inactive pattern/screen image table while the VDP registers point to the active pattern/screen image table 2. Switch VDP registers to now point to the filled tables, updating the screen display 3. And back to 1 Anyway, looking forward seeing more of your project

Thanks for asking Owen. I've barely done any TI stuff lately, so no progress. Crazy life got in the way again. Just yesterday I got back home from a trip to Belgium. Went to see my relatives, so I was rather quiet in the forums too The good thing is that I have a 3 week vacation coming up right now. Ask me again at the end of August, I should have something to show you

Thanks for posting, Tim. Yes, you are absolutely right, and just such a thing is certainly the FIRST thing I would do. Here's the only thing though... how many of us have hardware and emulators? A hundred? Two hundred? Of those two hundred, how many are interested in playing video games? Of those interested in video games, how many RPG gamers are there out there? A person willing to play a game for 10-20 hours to beat it.... We're essentially limited in most part to THIS FORUM!!! We're the ones who love games, love programming, and love supporting others to do the same. Over on the list, 90% of those people have never played any of the SSGC games, they don't care about new software, and for the most part--- they are mostly great people who enjoy talking about the TI as something they remember fondly. I love them all, they're all great people. But really... show of hands... Who thinks fdos, epergrem, jacques, tom, or any number of others would really enjoy a CRPG? It's really quite simple if you follow me. The ones in THIS Atariage community who love games are simply co-designers, as far as I"m concerned. I look at this thread like a development document, in a way, with hundreds and hundreds of co-authors. You guys are my inspiration, my BETA testers, my co-conspirators, mentors, all wrapped up into one little community. So, here's the rub. YOU are all co-authors of the game.... you are all on the BETA testing team... so who are we doing this all for? Honestly, I'm hoping we can find a way to go the way of the "wrap" as was suggested previously. That way, this game can be a testament to the /4a. An accessible, understandable, labor of love showcasing the TI and what it can do. "Here, RPG world... you have a new CRPG to play, it's Windows executable, it's well done, it's 100% documented, 100% tested and guaranteed to play well. And best part... It's written on the TI-99/4a home computer.... 16k of RAM, 256 bytes of scratchpad RAM... and we did it in spite of all the limitations and challenges! Come to the /4a-side. See what's possible?" That's what excites me about the project... There is such a HARDCORE community of RPG lovers and enthusiasts who have ALL heard of Tunnels of Doom. Tens of thousands of people who are looking for a project like Adamantyr's "Realms of Antiquity" or my own RPG (to a lesser extent). Let them eat cake. =) I wouldn't mind seeing Beryl as an executable windows file. It would open your game for a further audience. Sometimes, it's these little things that matter. Also "wrapping" the emulator and game as a single executable is not that uncommon in other retro game scenes

Just wondering, could there be a way for TI assembly language software to detect if this controller is attached ?

hmmm thinking about it, I could see A="fire" and B="magic lamp" in Tutankham

Holy cow! That is fantastic! I for one, want to see this happen and I'd love to support it in future games