retroclouds

I guess it will depend on where the compiled game loads in memory, I presume somewhere near >A000 ? Games directly running from the module space need to start at >6000 and also need their own routines for writing to VDP etc. It'll also depend how much memory space the game takes. You have 8K of memory in the module space, if you need more you have to use multiple banks and do bank switching. But I suppose the easiest solution by far is to build some assembly wrapper code, that copies the actual game code where it needs to go. Ofcourse this also means you need 32K memory expansion. * Cartridge header * Wrapper code for copying game code to >A000 * Your game

Say no more. Vulgus has been added. It sure would be nice in a game, but doesn't have a lot of characters defined. I try and match only TI ASCII characters and leave out game characters and other special stuff. Very nice! Thank you!

thanks for the update Would CAPCOM fonts work well, e.g. the font used in VULGUS ?

Thanks for you hard work on this. Really interested seeing how this further evolves.

Just played with the import function. Very cool I tried to import Tutankham VDP dump but could only get it to partly import. Dunno what is causing the issue, most likely I goofed up when doing the export from the emulator. Will play a bit more with it and let you know.

Looking forward to that Have some more ideas for a future version, but just want to see what's in the newest one first ok, here's one anyway Suppose you have a map that contains something like the screen below. ............................. ....---..........123......... .................456......... .......---.......789......... ............................. Would it be possible to "group" the characters that make up 123456789 to an object (you know like you can with Powerpoint). With this object you could then do stuff, like: 1. Clone to another position (similar to what's already in place) 2. Move the object to another position 3. Mirror/flip/rotate the object as such 4. Pixel move the object. That would work on the patterns that makes up the object. (You kinda can do that now by manually working on each character individually). Ofcourse one would have to be aware that if, the pattern is used at another location, that character will shift too. I know this was asked before, but it would really be cool if one could undo the previous actions. I find myself saving the map project a lot each time when I do an action, because I mess it up a lot. Do understand that is hard to do. How about if Magellan would save the map project to "memory" in the background when one does an action ? An undo would be a re-open from the file in memory. ok, this might not be the most efficient option, but perhaps still a possibility ? Anyway, that's a great tool you have there

Just bumping the thread. Any news on the new Magellan version ? I'd really love to give the VDP dump import feature a try ? Edit: oh, perhaps you could also show the Magellan version number in the window title or something. That way it's easy to find out if you are having the most recent version

Excellent idea! I sure can use some fonts for my future games. Thanks!

In section 1.7 "Applicable Documents" the "System Monitor Specification" is mentioned. I believe this is refering to the TI-99/4A OS; does anyone know if this document is available somewhere ? I'd sure love to get a scan of that one.

Here it is; a scan of the original GPL Programmers Guide by Texas Instruments. Special thanks go to my belgian friend rocky007 who helped me in ordering, paying and shipping The document sure makes an interesting read and is a nice enhancement to the TI-Intern book. Enjoy! GPL Programmers Guide PDF The original GPL programming reference manual from Texas Instruments. Covers all opcodes and advanced stuff like coincidence detection, I/O routines, etc.

Added GPL Programmers Guide

Looking at the Youtube Vid's you get very close to the original. Definitely have to try it out this evening Mind sharing some more details on how the development was done ? How did you convert the graphics ? So the game was written in pure TI Basic and then compiled with Harry Wilhem's Basic Compiler ? If it is written in TI Basic it means no sprites were used at all, I'm pretty impressed with the results. I don't know this compiler, is it publicly available ? Perhaps we can get the authorisation for adding it to the Development Resources thread. Very nice! :thumbsup:

Very nice!

Excellent stuff Owen! Very well done indeed! Would love to read more stuff from you in the future

We bought our TI-99/4A systems (2) in Belgium and we had the PAL modulator (even though the TI-99/4A came in a box with french packaging). Can you attach a picture how the TI-99/4A with scart connector looks like ? I think the picture quality should be better as with the PAL anntenna thing ?

The TI-99/4A Tutankham prototype has minor graphic changes compared to the colecovison version. Also it behaves a bit differently, however it's very hard to tell by only looking at the short video on the Videogame House. Would be willing to give it a try if I can get some more information on what the differences are. Remember: no one has ever played this prototype, except for Toucan.

As far as I know, we don't have any means to detect if we are on a PAL or NTSC TI-99/4A. The colecovision has a specific BIOS ROM address that contains "50" for PAL and "60" for NTSC. That way software can easily figure out if it needs to adjust sound loops, timers, etc. Guess one should be able to figure out the same by running a tight assembler loop in scratchpad memory counting VDP interrupts. Dunno how well that would work on hacked TI-99/4A's, SNUG systems or Geneves. I don't care as those ain't my target machines anyway. For what it is worth: Pitfall just runs a tick slower on a PAL system.

I completely forgot about the X instruction. Never used that one. hhmm, I guess if it could be used to write a compact "push registers" subroutine. Seem to recall that the X instruction is rather slow ? But what if it resides in scratch-pad memory. Then again, could write some self modifying code there

Didn't have a chance to check this out earlier. Looks perfect! Very well done

I like the idea of letting FlyGuy hhmhm... fly Perhaps you could introduce something like "warp pils". You start with 5 and you collect some while you proceed. Using a warp pil will let flyGuy take off. Wonder how it would look like if FluyGuy is bigger while he is flying. (like in the racing game Bump 'n Jump when the car jumps). How about adding a Mrs. FlyGuy to the match ? As far as the levels are concerned: now that Magellan is in place, a small contest where the atariage members design the levels could perhaps be an option. It would save you from having to design all the levels yourself. The level designers could be credited (in the manual or something) Well, these are just some ideas. I think that FlyGuy will be a big success

This is very cool. I'm currently redesigning my SPECTRA assembly game library and one of the key elements is that it's stack based. I'm currenlty redoing that part and its nice seeing the ideas you came up with for the stack handling. For 'popping' the registers of the stack I'll be having a small subroutine in scratch-pad memory. I don't know any C myself, but I presume that the C implementation will be using some of the registers and memory for handling its own requirements. * Will scratch-pad memory be used by the compiler generated program ? * Do you mind sharing which registers are "taboo" for external assembly routines. * What conventions should assembly routines stick to for being callable from a C program ?

Welcome MäSäXi ! It's always nice to have fellow home computer buddies check out our little group here Your nickame sounds familiar. Can it be that you are on the MSX resource ? I check that one out on a regular basis (as a lurker). Ah the MSX and the MSX DEV homebrew games; very nice.... I like Malaika a lot

Well, even though my progress on Tutankham is rather slow, my friend ti99userclub has been very busy Check out his beautiful artwork on the manual cover