Jump to content
IGNORED

Project "booster" - a new assembler for the TI-99/4A


Recommended Posts

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
Link to comment
Share on other sites

Very cool! I'm about two-thirds done with my 9900 assembler, then I got off on other tangents like FlyGuy II, writing tutorials, super secret hardware projects, etc. I wonder who will finish their assembler first, you or me? :-)

 

I like writing language parsers (got into it recently), but I'm currently coding in C so I know I can compile anywhere. My plans are to have a Win,MAC,Unix native compiler, with both a GUI and command line versions. I'm not big on pre-processing though, so I don't currently have any plans for that. Just something E/A compatible with some enhancements to make things a little easier (like longer label names!)

 

The more the merrier IMHO. Keep us posted!

 

Matthew

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

The cool thing is that language parsing actually is fun!

 

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

Link to comment
Share on other sites

Fantastic news Filip, the TI programming renaissance continues! Looking forward to what both you and Matthew are cooking up here. With tools like these it will be fun getting back into assembly again. :thumbsup:

 

 

I'm pretty stoked to see this thing rolling!!! With Magellan, Tadataka, SPECTRA, booster, and all the other excellent tools, I'm betting we have the best year EVER (at least in the last 25 years) for TI homebrews!

Link to comment
Share on other sites

Where do you guys get the TIME to do all this amazing stuff???? I am lucky if I can touch my TI more than once a week :(

In any case, this is really great news, even though I personally still program on the real thing.

As Owen said, this is really a renaissance for our little machine :)

Link to comment
Share on other sites

The cool thing is that language parsing actually is fun!

 

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

Link to comment
Share on other sites

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

 

Expressions are not that hard. Also, in assembly they are handled at assembly time, not runtime, so everything you need to resolve the expression is available. If you check in the E/A manual, I believe you will see that the TI assembler has some pretty strict requirements on the expressions.

 

Either way, it is not that hard. I can probably dig up some examples if you have never looked at expression handling code. I'm strictly talking about math expressions here, *not* regex stuff. I don't see why you would have regex in your assembler anyway, but I'm just making sure.

 

Matthew

Link to comment
Share on other sites

Regexp in macros would be nice, you could do some seriously powerful code generation then.

 

I have some old stack-based math parsing code I wrote, supports order of operations, parentheses, constant folding, andfour function math plus exponents. It's tailored to generating Jaguar RISC assembly, but the concepts are close enough and it's designed to be portable. It's written in C, if that's useful.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...