retroclouds

Thanks Matthew and Tursi for the code offering. I'll gladly come back to the offer when I get there

I was out of the TI scene for a very long time. I have to say I don't know any of these products (sorry). Do you mind explaining what each of the hardware products are. Thanks

Thanks for pointing that out sometimes99er! I checked out the mentioned RXB download at 99.net, the only backdraw is that the cartridge is in a proprietary format only to be used in Win994A. So no chance to use this in classic99 or MESS Dunno, perhaps it's floating around somewhere in MESS bin format. Guess we'll have to do some digging on whtech.

Until now I haven't done any experimenting with random number in assembly language, so this does make an interesting read. This is good stuff!

Yeah, the scanner and tokenizer are neat, and building a parse tree is pretty cool. After that though, you will be tested by how badly you want to make the language. Using a parse tree to actually do code generation is very non-trivial. Of course an assembler has an advantage that it is not really a "language" but simply a human-readable form of machine code with some labels and such sprinkled in. There is always lex and yacc I suppose, but I like doing things the hard way (it's more fun that way.) Matthew Yeah, at present I'm not yet sure if I'll be using one of the existing perl parser modules (lex/yacc pendants) or if I'll be cooking something myself. With perls' powerful regular expressions I'm up to the task. As you mentioned assembler does have the advantage there is no complicated syntax. On the other hand it needs to eat expressions too and these could get out of hand easily. hhmmm.... it just occured to me that if I don't want to evaluate the expression myself I could also pass it to the built-in perl interpreter. We'll see. After all this is about fun and learning, so I'm considering/experimenting with both possibilities at this time

Nice write-up. And yes, turn off the ISR if your going 100% assembly language. It will make your life a lot easier. Actually I had the first early Pitfall prototypes completely running from the ISR hook. I was so convinced I was doing the right thing. What was I thinking??!!

I've uploaded the version 0.2 prototype. Biggest modification is that I now have the level 2 maze in place and teleporters are working too. Don't have any youtube video footage yet. Just run to the exit of level 1 for getting to level 2

hehe, pretty confident that will be you I needed a break from writing Tutankham and had this cooking for a while, just didn't get to do much coding yet. Most likely I won't be having all mentioned features in, but I'm thinking in small steps here. The cool thing is that language parsing actually is fun!

As always; very cool

A little while ago I started working on a new cross-assembler targeting the TMS9900 (as used in the TI-99/4A Home Computer). The main reason for doing so, is because I want to have certain features in that I haven't found in any of the existing TMS9900 assemblers. And last but no least because it's plain fun writing an assembler :-) The assembler itself is written in PERL (my favourite language), but that shouldn't be a concern to the end-user as I'll deliver a binary for Windows (and linux if there is a demand). Project name for now is "booster" Here are some of the requirements: * Concentrates on game development (e.g. possibility to include binary files, Magellan maps, Support for SPECTRA, ...) * Both command-line and GUI version * Preprocessor and macro support * Strong expression parsing * Possibility for automatic code-layout in ROM banks. And some of the advanced features I'm thinking about: * API for running assembler from external programs * Possibility for running different front-ends (TMS9900, MSP430, Z80 subset) * Built-in scripting language As mentioned in the requirements I'm considering adding multiple front-ends. This means that you could for example process MSP430 assembler source code and the frontend will do a mapping to one or more matching TMS9900 statements. This would perhaps allow to use some of the MSP430 development tools (MSPGCC tool-chain, ...). The C compiler generates MSP430 assembly source which in turns get processed by my assembler. Taking this idea one step further the same could be possible for a Z80 subset as well. Ofcourse those are just ideas and if they'll eventually make it into the assembler is a big question at this time. +---+ +------------------+ | | | SCANNER/LEXER | | P | ---> | FOR TMS9900 | ----------------+ | R | +------------------+ | | E | | | P | | | R | +------------------+ | | O | | SCANNER/LEXER | | | C | ---> | FOR MSP430 | -------------+ | | E | +------------------+ | | | S | | | | S | | | | O | | | | R | +------------------+ | | | | | SCANNER/LEXER | | | | | ---> | FOR Z80 SUBSET | ----------+ | | +---+ +------------------+ | | | | | | V V V +---------------------+ | | | OPTIMIZER | | AND | ----------> EA3 object code | BACKEND FOR TMS9900 | ----------> PROGRAM image files | | ----------> ROM banks +---------------------+ ----------> Listing file, symbol table, ... I'm starting from the backend and I'm working my way up to the frontend(s). Nothing much to show yet, but I do am able to successfully generate object code for formats 1-9, so that's something I'm already quite happy about. The parsing stuff really is very fascinating and there's still much to learn, so we'll see how it goes. After all, this is a long-term project

I'm actually more worried about destroying assembler game programming as we know it. Future plans might include exports to other engines like Basic4GL, ColecoVision, Flash and J2ME. Recalling yesterdays' chat, I think Strawberry will be a blast. I wouldn't worry about destroying assembler game programming. We'll just see more software running at warp speed ... and that's a good thing Perhaps we'll even see way more homebrew games on cartridge in the future EDIT: It would be very very cool if you'd be able to output colecovision binaries too :-)

This is really turning into something very useful. I'd love to see all those articles combined in a text-only or PDF for offline viewing. Thinking about it; you could also add a "cookbook" to go with it. With recipes/small examples for dealing with the common TI game development tasks: setting up a game loop, check for sprite collision, ... You could then refer to the corresponding articles for getting all required background information. Either way, very nice Matthew!

Very impressive Looking at the video, it seems that you have call color, call hchar, ... variables, loops, expressions and random function working. Might sharing some light on how you did the implementation especially in regards to the expression handling ?

Very nice Matthew! I love reading your posts

Nice work rocky007! So if I understand correctly, you can take a screenshot, scale it for matching the TI screen resolution and then extract the pattern data. I am sure this will come in handy

Thanks for the binary Daniel Add the below to your classic99.ini file for playing around with the 128K image in classic99, ofcourse changing the file path according to your needs: [usercart0] name=Disk Utilities rom0=3|0000|20000|D:\emulator\ti\classic99\MODS\fredcarts.bin

Thanks for the update Codex! Appreciate it a lot. I'm especially looking forward digging into the clone tool and binary format export

Had to leave for an unexpected business trip on Sunday, so couldn't join in the chat. Just got home this evening and I'm now reading this weeks' interesting topics. It seems I missed a lot of interesting discussions Anyway, the plan is to definitly have a chat this Sunday. I'll send out the reminder/invitations on Saturday

EDIT: If you have 5 sprites in a row, you could also rotate the sprite entries in the sprite attribute table. That way you will get some flicker, but if done in a smart way it should be quite acceptable.

You could try to make Bruce Lee and Ninja a combination of sprites and tiles

Thanks Codex! Looking forward giving it a spin this evening

hi rocky007, wow, Bruce Lee on the TI-99/4A that will be a blast Looking forward seeing how this further develops. Don't forget that Jons' cartridge boards can sport up to 64K (8 x 8K banks). So with compression I think you should be able to stuff the screens in. Depending if you want the game to require 32K memory you could decompress to RAM, but I think this kind of game should be possible also with only 256 bytes scratch-pad memory run on a bare console (256 bytes memory)

If I understand correctly, want you want is like running multiple threads at a time. You would have 1 thread that is handling the motion of the hero and another could be used to read the keyboard or handle the sprites position. You might want to check how I handle this kind of stuff in the SPECTRA library. Check the "TIMERS" section starting page 64. The PDF is here.

The castle looks quite impressive! :thumbsup:

Jaime has one for sale right now: eBay Auction -- Item Number: 200470866865