retroclouds

The example manual page looks great. Just plain crazy what has come out of the contest. Owen your suggestion for adding the program listing on the second page is a great idea. Turning this into a booklet, reminds me of some of the game books I have at home (Compute's first book of TI games, etc.) The big difference is that the quality of the contest entries are at least 10x better to say the least Any chance Codex' manual covers could be fit in somehow ? Either way, if this booklet gets produced, I'd like to buy a copy please

ok, ran out of spare TI time for now. This is what I was able to put in today: * Teleporter functionality (that is when you walk in the white gates). * White flashes when dropping bombs/decrease counter I already had the teleporter functionality cooking for a while, but managed to get it to work today. Happy Happy Joy Joy http://www.youtube.com/watch?v=46FgUhbsJKc&feature=related Hey, you don't get this on the yahoo group

hehe, thanks that are very kind words Owen For me -and I think this also counts for most others here- it's difficult to stay focussed on one topic. There is so much fun stuff to do. I also noticed I have to be in the right mood to work on Tutankham. That's kinda hard to explain; but today is a good day so I'll give it a shot

I contacted Fred (TI99Dir programmer) and asked for some advice on this topic. I think he's currently the one in the TI community who has the most C99 knowledge. He also has written some tools for optimizing the output of the C99 compiler. So perhaps he can chime in on this topic.

yep, same error message here.

Jaime again has 3 CF7+ "slim" models up for sale at Ebay. Grab them while you can. Check here: eBay Auction -- Item Number: 200467295711

Jaime again has 3 CF7+ "slim" models up for sale at Ebay. Grab them while you can. Check here: eBay Auction -- Item Number: 200467295711

wow, almost an hour without Atariage What happened? Was this due to database backup or was there a maintenance. Something happened to the skin too, the fonts appear smaller now. This makes the bold fonts harder to read.

Thanks for pointing this out codex! This is the online version of the Small C Compiler book I mentioned earlier. I looked for the online version for a long time, but didn't get lucky. This is good stuff! :thumbsup:

Not that many, I got sidetracked with too much (non-TI) stuff lately. However, in the meantime I did receive my 50 PCB's + cart cases from Jon. That sure will keep motivation up Plans are for an early 2011 release and that's still quite doable.

I think it would be a great idea to add C99 to the Development resources thread For those who don't program on the TI-99/4A directly (or emulator). There is also an (old) cross-compiler version for running on the PC, available on whtech. I believe that Fred Kaal has programmed most of his disk utilities using this cross-compiler and a custom loader. Anyway, I'll look at my notes and add C99 to the development resources thread. If anyone has URL's/resources to share concerning C99 then please contact me and I can add it to the mentioned thread On a sidenote, I've checked in making SPECTRA compatible with C99 and that certainly looks doable. The main issue is that SPECTRA uses another register as stack pointer and the stack itself grows in the wrong direction, but that would be quite easily to fix in a new version. The reason I would make SPECTRA compatible with C99 is that it would be possible to do a cartridge only game (256 scratch-pad memory). Ofcourse you would also have to fiddle with the C99 library itself, but should be doable. I got myself the "a small C compiler book", which not only explains small C, but also explains the inner workings of the compiler. Even though not directly TI-99/4A related a very interesting read (haven't found this book in an online version).

Excellent stuff! Looking forward seeing how this continues

Congratulations on the contest :thumbsup: I think this is one of the best TI game development years in a very long time

Played around with the latest version. The below screenshot shows I definitly have zero drawing skills While playing with Magellan, I noticed following things would be nice. 1. Undo functionality: Revert the latest modification(s) 2. Would be cool if you could move/copy certain parts of the screen. e.g. in my screenshot copy letters to complete the title screen as "FRANKY AND FRANK". In this example I would only need to add one additional letter. Now I have to draw them all again. 3. When the "look at character mode" is active it would be nice if the matching character in the character set would be highlighted as well. That way you know exactly what character you are looking at. 4. Possibility to shift character pattern 1 pixel left/right or up/down. 5. Copy character patterns by drag and drop in the character set. This is only minor as there is a workaround; go the character pattern; select hex codes, go to other pattern, insert hex codes. Anyway, Magellan rocks

Sounds great. Thinking of it more, you could add new sections following (E) as Magellan evolves. They again would contain a header and a data section. For the first 12 bytes, they could also follow the same format as the map header. Suppose you are adding a new section for sprites positions per map. F) MAP SPRITE HEADER ==================== byte 0-3 4b: Magellan option flags for sprites in current map byte 4-11 8b: Size of (G) in bytes byte 12-xx Some Specific stuff for sprites G) MAP SPRITE DATA ================== byte 0-xxxx Sprite data

If you are on a PC, I don't think it's that important. You have XML parsers for about any language you can think about. I mainly program perl and like to do things myself, that is why I mainly opted for a binary format. Also thinking that I could dump the binary file directly to ROM (Sorry was more thinking about Colecovision here). It's not that hard to write a converter for turning the XML structures in binary format, so I won't complain that hard if we get an XML structure in the end

Even though I use XML on a regular basis, I think its a bit of overkill for what we are trying to accomplish here. I understand that when doing an import from XML, it could help you to get the different sections nicely separated into your programs' memory and may help in terms of extendability. However, if you are writing a converter, you have to know what to access when for generating your output anyway. Nonetheless, as far as the data structures in the export file itself are concerned, I don't think it will make that much of a difference if they are wrapped in XML or are plain binary, so I'd say let the majority and Howard decide

Thinking about this: Adding the possibility to run an executable file after the export has finished would make this a pretty transparent process. You could define the command line options in a Magellan settings file.

I have a proposal for the binary file format to use when exporting map data. Note that this proposed file format is only for the map data itself. For the patterns and colors, I think we have a good solution with the PNG format. The reason I'm proposing this file format for binary export, is because the export format for the source data statements will be havily depending on the actual player code and the language it's written in (Assembler, Extended Basic, Forth, C99). By using an intermediate binary format the game developer can write his own "converter" for turning the maps into source code focussing on his particular needs. Data map export: Proposal for binary file format ================================================ <FILE HEADER> <MAP 0 - MAP HEADER> <MAP 0 - MAP DATA> <MAP 1 - MAP HEADER> <MAP 1 - MAP DATA> . . A) FILE HEADER ============== byte 0-1 2b: String constant MG byte 2-3 2b: Magellan version identifier byte 4 1b: Number of maps in file B) MAP HEADER ============= byte 0-3 4b: Magellan option flags for map byte 4-11 8b: Size of (C) in bytes byte 12-13 2b: Number of columns in map byte 14-15 2b: Number of rows in map byte 16 1b: Screen background color C) MAP DATA =========== byte 0-xxxx Tile character values (0-255) or RLE encoded data Remarks * Note that bytes 0-3 in the map header (B) can be used for setting Magellan map status flags. Would be up to Codex to decide what to put in there. An example could be a status bit telling if RLE compression is on for (C ). * Byte 16 in the map header (B) indicates the screen background color. I added this as I presume this is not present in the PNG format. We can easily drop byte 16 should the background color be present in the PNG.

Jaime has 3 CF7+ up for sale at ebay. They're the new slim model. Check it out here

Have to check this out. I thought you can't write to (VDP) memory from the classic99 debugger ? This reminds me of openmsx (MSX emulator). They have those TCL scripts for doing "stuff" while a game is running. I seem to remind a youtube video where they demo writing to the VDP from such script while a game is running.

I'm for sure no expert on this. But the bin files are basically dumps of the bankswitched ROMs. Unless the source code for this game shows up, the only way to make this a disk-only game running from the 32K memory expansion would be to disassemble the ROMs. Re-allign all branches and relocate code to high memory. Also you'd have to remove the bank-switching. So basically you would have to disassemble the game and understand what part of code is doing what. I'm not saying it's not possible but it is a big task. You'd write some kind of disassembler/scanner first. Considering the amount of effort that would need to be invested, I guess you could as well rewrite the game from scratch.

Picked up my 50 PCB's and 50 cartridges at customs today. Guess they have tracked me now Costed me 74 euros. And the lady from customs, man let me tell you; I thought I was facing russian KGB this time. The boards do make up for it nicely. It was well worth it. They are of the finest quality! Also the way everything was shipped, very very professional. If there ever will be a next shipment, I won't mind the electroshocks at customs.... hmmmm not really Thanks for the hard work on this Jon! Appreciate it a lot. retroclouds

hhmmm, that sounds like a good idea. I think we can all benefit if we would have a "standardized" format. ok, have to go now. Have to pickup my 50 PCB's I ordered from Jon.

I think the multiplier is >800 as with the PDT. Yep, I just checked the VDP programmer's guide: the multiplier for VDP#6 is >0800 Lucky for me I wasn't using any sprites.