Brass does not sign applications itself - it delegates the job to the Wappsign utility supplied as part of the TI-83 Plus SDK. You must have the SDK installed, therefore, to sign applications.

You need to run Wappsign. It should be listed somewhere in the TI-83 Plus Flash Debugger start menu entry, or in the \Utils subdirectory of the Flash Debugger's installation folder. For signing to work, the Wappsign application needs to know where your key file resides. Click the [...] button next to the 'Key File' box, then browse for the 0104.key file. Click 'Yes' on the 'This directory is not in your search path. Add it now?' dialog box. Tick the 'Save Settings on Exit' box, then click 'Close'.

That's almost 50 times faster; running in Debug mode, within the VS IDE, loading three other (also Debug) DLLs as plugins. I'm so, so, sorry.

Anyhow. So far, I have these directives in the 'Core Plugins' collection -

.if/.elseif/.else/.endif - conditional compilation.

.org/.porg - set the origin (.org) or pad up to the origin (.porg).

.align - align to a particular boundary (pads).

.rept/.loop - usual loop-unrolling stuff.

.push/.pop - pushing and popping a value onto a stack.

.db/.dw - the usual byte definition stuff.

Core Plugins also provides a 'Raw' output and an 'IntelHex' output plugin.

'TI Program Files' contains a series of .8?p output plugins, an 'Unsquish' byte transformer plugin and two directive plugins (.unsquish and .squish) that switch the byte transformer plugin on and off. (A byte transformer plugin takes a byte input and returns an array of bytes).

Do people have any particular favourite directives they use that I haven't listed above? (I know it's a rather incomplete list).

Well, include files usually have a ".equ". I might put .equ into a 'TASM' plugin collection, as for most people using the '=' operator should be good enough.

There's also TASM-style #define. I'm puzzling over how best to do this. Do I build function support into the emulator (so calling a function can output code and return a value?) or use a TASM-style text-replacement?

(This post is partially to indicate progress, and partially to post some sample code from the plugin system).

I decided to add functions. They're not that tricky, really... if a constant token is found (a constant being something like 'abcd' or '"fish"' or 763) with an opening parenthesis directly after it, all the stuff between that parenthesis and the matching closing one is removed from the expression and dumped 'inside' the constant token, which is turned into a new 'function' token. When the token is executed, rather than return the label or numeric value associated with it, it's name is looked up from the loaded plugins, and if one matches the arguments that were extracted are sent to the plugin.

I've wrapped up the majority of .NET's Math class as plugins. The Core Plugins package comes with a few classes of its own that can be use to aid plugin development (such as ways to hook in to its conditional compilation system, and in this case a specialised template that accepts a fixed number of comma-delimited arguments, called CommaDelimitedFunction where the third argument added to the constructor is the number of arguments required).

All plugins need the Identifier, so Brass knows when to use it. EasyExecute in this case takes over from the primitive 'Execute' that's exposed by Brass to automatically handle incorrect numbers of arguments and to strip out the commas.

Why do I feel it worth supporting functions? Well, there's the old mess of the trig table generation functions (and remembering argument orders), so you have finer control over them with the above...

Code:

theta = -1.rept 256 .db floor(127 * sin(++theta * pi() / 128)).loop

(I haven't written a for-loop directive yet).

All plugins have a reference to 'Builder compiler'. This is the current compiler, so when called they can control the compiler in some way. In other words, if I was feeling very lazy, and didn't add macro support...

There are a lot of things to sort out - least of all the Z80 assembler plugin isn't even finished - so "when it's done".

I realise it's rude to post previews but not deliver, but I wanted to demonstrate that this complete rewrite is worth it in at least it's a more robust system.

The biggest worry with releasing it is if someone decides to start writing plugins and I revise the way they're handled.

For starters, the current way a source file is represented (as a LinkedList<Command>) is not great as the functionality for compiling the list is built in to it - so you can't have two such lists of commands and build them into a single output, so this is where the returning values from a function problem comes in (it would be easier if I could split the function body into its own list of commands and execute that whenever the function is called) or even support include files!

I've broken down the compiler into an "Overseer" (which still contains all of the methods for controlling the assembly process, such as switching the assembler on/off or jumping around the source using bookmarks) and "Source Segments" (which are a series of commands).

A source segment is typically a single assembly file, but by using two new methods - StartRecording and StopRecording - you can extract a block of code from the main assembly process and run it at a later date. You can run it alongside the main body of code (in the case of an include file) or externally (in the case of a function). Now, this sort of thing is possible:

(I'm using the VB-style return mechanism where the return value is set by assigning to a variable with the same name of the function).

Something's not quite right with running the functions away from the main body of code, and calling another user-defined function from your own doesn't work, and so there's no recursion either. It should hopefully be a simple enough fix. A 'return' statement would also be easy enough; when encountered set the value as required and switch the assembler off for the remainder of the function.

I think the problem is the large number of static variables that still exist from the "one source segment only" idea. It should hopefully be easy enough to fix.

Who is online

Users browsing this forum: No registered users and 0 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum