Jump to content
Sign in to follow this  
matthew180

Asm9900

Recommended Posts

I started my assembler last night and got the scanner part working with a very basic parser for initial testing. Next is full-on parsing and the beginning of code generation. What I really need to know is how each of these directives is supposed to operate:

 

AORG - I'm pretty sure I'm clear on this one, but it is nice to make sure.

 

DORG - I just got a glimpse of using this from Willsy, but having something in stone would be nice.

 

RORG - Again, I *think* I understand what it does, but I'd like confirmation

 

PSEG, DSEG, CSEG. If the AORG, DORG, RORG are working, I don't understand why these are needed?

 

UNL, LIST, PAGE, TITL, IDT. Is there any reason to support these other than recognizing and ignoring the tokens?

 

 

Enhancements I'm planning to add:

 

* Local labels between two new directives: LOCAL and LEND (Local END)

 

* Long label names - up to about 80 characters

 

* Alternate comment tokens (C and C++ style) that can be used anywhere, including commenting out blocks of code: // /* */ ;

 

* No fixed label, command, operand, and comment fields which means code can start at the left edge or be better indented along with comments

 

* Support for the even/odd byte format in separate output binary files that is required to make custom system ROMs

 

* Not case sensitive

 

I'm writing this in POSIX C and plan to make binaries available for Unix, Win, and MAC platforms, and I'll see about a GUI. Comments, suggestions, and feedback are appreciated.

 

Matthew

Share this post


Link to post
Share on other sites

I'm currently also planning on writing an assembler targeting writing games.

The way it looks it will be written in perl.

At first the intention was to go for java, but perl is quite flexible in terms of text manipulation.

 

I've collected some of the requirements in the below text file. It's nothing much but might be interesting anyway. Most of it comes from discussions we had in the online group and by

looking at what other assemblers are capable of.

 

assembler requirements.txt

 

Also have a bunch of hand-written notes that I still have to put in electronical form. It was about doing experiments with how macro's + parameters passing could possible look like.

 

One of the things what might be interesting to know is: How important is backward compatibility to existing assemblers (mainly winasm99).

Edited by retroclouds

Share this post


Link to post
Share on other sites

DORG means Dummy Origin.

 

It's sets the address, just like AORG does, but it does not assemble any code. By that, I mean it writes NO code out to the object file.

 

However, it DOES calculate label addresses, which is exactly what it is used for.

 

Longer label names would be nice, but don't forget, the TI loaders can only handle REFd or DEFd labels up to 6 characters.

Share this post


Link to post
Share on other sites

I'm currently also planning on writing an assembler targeting writing games.

 

Cool. I'm working on something similar, but more in the form of a new language(I'm leaning towards compiled, but maybe interpreted.) It is still far from even being to the Alpha stage yet though.

 

One of the things what might be interesting to know is: How important is backward compatibility to existing assemblers (mainly winasm99).

 

My assembler will be compatible with code that can be compiled with the assembler that came with the E/A package, but I'm not worried about being compatible with any other compiler. This is mostly due to the very reason I have to write the assembler to being with, and that is because all the non-TI assemblers available to us have been abandon or the author can't be bothered or is not interested in being even a little active in the community. I hate having to use using broken or abandon tools.

 

Matthew

Share this post


Link to post
Share on other sites

DORG means Dummy Origin.

 

It's sets the address, just like AORG does, but it does not assemble any code. By that, I mean it writes NO code out to the object file.

 

However, it DOES calculate label addresses, which is exactly what it is used for.\

 

Yup, that is what I got from your other post. Thanks!

 

Longer label names would be nice, but don't forget, the TI loaders can only handle REFd or DEFd labels up to 6 characters.

 

Good point! I'll keep that in mind for anything in the REF or DEF sections.

 

Matthew

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...