Jump to content

retroclouds

+AtariAge Subscriber
  • Content Count

    2,123
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by retroclouds


  1. 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??!! :-o


  2. I wonder who will finish their assembler first, you or me? :-)

     

    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!


  3. 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" :D

     

    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 :D

    • Like 1

  4. Man!!! This is really taking shape!!! I hope this thing comes to fruition.... There will be some very pissed off people if you shelf this thing. :)

     

    Great job, buddy. This may well revolutionize the TI cartridge market. :)

    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 :D

     

    EDIT: It would be very very cool if you'd be able to output colecovision binaries too :-)


  5. 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! :D


  6. 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 ?


  7. 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 :)


  8. Well, about the sprites per scanline thing...

     

    The original version of Bruce Lee is for the Atari 800, and it seems to entirely use the player graphics for the player and his enemies (not the static moving things, those seem to be part of the background). The player graphics allows for 5 objects on screen, or 4 players and 4 missiles, but in this case it seems like they did the "display 5th player instead of missiles" thing. Both the Green Sumo and Bruce Lee have 2 colors each, and the black ninja is 1 color.

     

    Then I noticed that for both the Green Sumo and Bruce Lee, actually only 3 sprites would be needed most of the time because their bottom part is monochrome (green on Green Sumo and black on Bruce Lee). There is one exception, however... both Green Sumo and Bruce Lee need a fourth sprite when they are performing the foot strike move. But this only applies to their lower part where they are monochrome anyway... or at least they are monochrome in their lower part while performing this move.

     

    So, all in all, I think 5 is the maximum number of sprites that could possibly appear on one scanline. I'd arrange the sprites so that this has the lowest possible impact... so that the first sprite to disappear if more than four are on one scanline would be Green Sumo's black body parts, which are relatively sparse, then Bruce Lee's upper flesh parts. When performing the foot strike move, I'd first remove the rear part of the character performing this move if necessary (because the front part is the kicking one).

     

    By the way, when programming in assembly, the sprites and the background do not have to share the same graphics tiles... they only do this in XBasic to save memory for the actual code. But in assembly, the sprite pattern table can be on a different address in VDP RAM than the main pattern table... so you have 256 tiles for the background and another 256 for the sprites.

     

    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.


  9. hi rocky007,

     

    wow, Bruce Lee on the TI-99/4A that will be a blast :D

    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)

    • Like 1

  10. 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.


  11. Another one for my TI friends. ;)

     

    http://www.atariage.com/forums/topic/162806-ti-logo/

     

    Thank you :) I was looking through it last night and noticed that around the end of the document the pages turn red with no content displayed. Do you want to check it out?

     

    That may be an issue with the Scribd issue. I've seen red pages when browsing through their archives.

    It happens when the page is not yet available for viewing.

     

    On a sidenote: I downloaded the PDF version from Scribd and it's complete ;)


  12. This is to let you know the poll will be closed on Wednesday evening (May 12th).

    We have 16 votes so far.

    So if you haven't voted yet, then take your chance now.

     

    The first official chat will take place on the weekend of May 15th/16th.

     

    The results so far seem to indicate the following:

     

    * Chat starts at 9 o'clock in the evening.

    * Preferred day is either Saturday or Sunday (6 votes each).

     

    I'll send out an invitation reminder to the atariage folks at the TI-99/4A programming

    subgroup the day before the chat takes place.

×
×
  • Create New...