Brass 2: Dropping TASM backwards compatibility.

Post by **benryves** » Tue 10 Oct, 2006 3:17 pm

I've mentioned this, and would like to clarify what I mean.

TASM does things its own way, and Brass 1 tries to follow that and add its own bits too.

In some cases, this causes a problem - supporting TASM's rather strange module system along side Brass's rather more straightforwards one, for example, isn't very nice.

Backwards compatibility with TASM, or even Brass 1, are not going to be features. Some of Brass 1's directives are incredibly messy (for example, the file management, ASCII mapping and image inclusion) and will be stripped down to what I hope will be a far cleaner syntax.

What with the plugin architecture, I don't need to write directives that try to cover each and every possible combination; rather, I can focus on a clean and simplified set of core directives, allowing for people to write their own plugins if they want something more complex.

TASM's modules are one thing I am definitely not directly supporting. I will try and cover most of the things that are in Brass 1, the things that I am dropping will be where there are problems caused by opposing views.

King Harold · Post by **King Harold** » Tue 10 Oct, 2006 6:05 pm

I think that's a good idea, but I also think that most problems regarding opposing views could be solved by adding a define TASM and define Brass, Brass should then compile it like TASM would (without the bugs) or like it would if it were itself. But that's all complicated and messy and basically it would make brass twice as big (or atleast one and a half times). I really hope to see the cool syntax-parsing-highlighting thing you mentioned earlier, it should make newly defined things the right colour and it could even colour label/variable references if you spelled them right.

Good luck

if you need testers to see if it compiles code like it should I would be glad to help. (but since you made Brass1 I doubt you'd need much testing)

Post by **benryves** » Tue 10 Oct, 2006 6:27 pm

With regards to highlighting - well, absolutely. And if you spell them wrong, they get highlighted too - but with a red squiggly underline to inform you that you made a mistake.

Latenite will actually be running Brass in the background, and so can ask Brass about each line and get Brass to respond with what it thinks each line should be highlighted as. This has a number of advantages to me... for example, I can easily spot where parser bug errors are in Brass.

King Harold · Post by **King Harold** » Tue 10 Oct, 2006 6:41 pm

You would see them in a blink, but little bugs in the compiled code could still occur, when forexample Brass makes a little mistake with its output which it doesnt make in the highlighting..
Although you're so scaringly good at programming that it probebly won't happen. (what if you accidentally left a line commented out? I do that all the time, but that's me.)

CoBB · Post by **CoBB** » Wed 11 Oct, 2006 5:08 am

I think you need to give a more precise explanation of semantics than in the current Brass docs. For instance, what’s the order of matching the signatures of a macro (or how do you decide which one to choose if an expression matches several)?

Post by **benryves** » Wed 11 Oct, 2006 10:22 am

Point taken. On that issue, there seem to be a myriad different macro systems out there (TASM, Spencer's, ZDS, WLA-DX, ...) - mine is just a hack on top of TASM's. Any suggestions to what you'd want to see?

CoBB · Post by **CoBB** » Wed 11 Oct, 2006 10:50 am

I don’t think it’s a good idea to make it too complicated, since macros are the worst way to pretend using a high-level language. You should definitely do it from scratch. If someone wants to compile a TASM source, they can always use TASM, and you can add a separate compatibility mode later that doesn’t interfere with the Brass way. And of course provide a well-defined behaviour, otherwise the coder is likely to get stuck as soon as something counter-intuitive happens.

Post by **benryves** » Wed 11 Oct, 2006 11:01 am

Given the plugin-based architecture; if you wanted TASM compatibility, you could write a pair of plugins; a directive one (to respond to #define) and a text processing one (that would be run on each line).

silver calc · Post by **silver calc** » Thu 09 Nov, 2006 5:14 am

Will Brass2 (and LateNite) have support for apps (single and multi-page)?

Post by **tr1p1ea** » Thu 09 Nov, 2006 11:01 am

Its a safe bet, considering that the current version already has support for apps.

When he talks about breaking TASM ompatibility im assuming he is talking about the fact that TASM seems to calculate a few things incorrectly, however BRASS1 made allowences for this.

BRASS2 should be very nice and customisable.

Post by **benryves** » Thu 09 Nov, 2006 12:20 pm

The lost backwards compatibility is on things that Brass handles one way and TASM handles the other (such as modules). TASM has a pretty primitive (and in some cases, rather weird) module system, which Brass implements by default. You need to add all sorts of odd directives to enable Brass modules, which are to my mind slightly more logical. What I am therefore doing is dropping TASM modules completely, and only allowing Brass-style modules.

In terms of application support; all output binaries are exported using a user-customisable "Output" plugin. In the mix_core.dll package will be a the usual suspects (Intel hex and raw binary). There will be a TI-specific plugin package which will contain all of the "standard" output types (8xp, 83p, 82p, ...) and yes, app signing. Probably with the WappSign COM interface as the current one does for the moment.

silver calc · Post by **silver calc** » Sat 11 Nov, 2006 4:00 am

benryves wrote:Probably with the WappSign COM interface as the current one does for the moment.

How do you get a working project using the included template? I tried to modify it but it doesn't produce a working application.

King Harold · Post by **King Harold** » Sat 11 Nov, 2006 8:53 am

you could try this as header.asm

Code: Select all

.variablename "$PROJECT_NAME$"
.binarymode ti8xapp                 ; TI-83+ Application
.deflong bjump(label)               ; Jump macro
    call BRT_JUMP0
    .dw label
.enddeflong
.deflong bcall(label)               ; Call macro
    rst rBR_CALL
    .dw label
.enddeflong
.include "ASCII Mapping.asm"
.include "ParseEquates.inc"
.local
.include "../Program.asm"
.endlocal
.include "TIOS Variables.asm"

and don't forget the app header and page defenitions.
(I had a lot of trouble with this.. but i got it to work)

silver calc · Post by **silver calc** » Sun 12 Nov, 2006 2:54 pm

I tried that header, but it keeps telling me that page0 needs to be 16K long.
I tried this, but it still didn't work:

Code: Select all

.db $80, $0F				 ;Field: Program length
.db $00, $00, $40, $00	;Length

What am I doing wrong?

Post by **benryves** » Mon 13 Nov, 2006 11:25 am

Try using that header, but just before .include "../Program.asm" insert the following:

Code: Select all

.defpage 0, 16*1024, $4000          ; Page 0 definition
.page 0                             ; We're in page 0
                                    ; ← header is added in here for us
    .block 128                      ; Advance 128 bytes for header

Note that the .block 128 is important - otherwise the header overwrites your code, so you need to skip 128 bytes to leave space for it.