Brass 3 (Under Development)

[driesguldolf]

hmm Ben?

[benryves]

Sorry, I missed your post! I've downloaded a copy and will work on it as soon as possible.

Which version of IE do you have installed? Does the square still appear if you look at the online version in another browser? I suspect you do not have the correct font installed (try installing East Asian support?) but I'll try and remedy it.

Forward referencing with .echoln shouldn't work at all (this is by design).

The translation capability is not a feature of Brass, it's handled automatically by the .NET framework. .NET uses the UI thread's culture (set by the edition of Windows you own) to determine which satellite assemblies to load. You can spoof this (for testing purposes) by manually setting the thread culture with another app. I can release a tool that lets you specify the desired culture if you so wish? If you don't want to use the Dutch translation, delete the satellite assembly (nl\Brass.resources.dll).

The recompile button is a great idea.

Another bug is that certain errors are reported at the last line of the last source file to be used (rather than their actual line). This has been fixed.

[driesguldolf]

Sorry, I missed your post! I've downloaded a copy and will work on it as soon as possible.

Hey, don't worry, I've got exams coming so I won't be able to program at all. That's also why I don't come here often any more

Which version of IE do you have installed? Does the square still appear if you look at the online version in another browser? I suspect you do not have the correct font installed (try installing East Asian support?) but I'll try and remedy it.

I used the help executable, all other arrows display correctly and I never use IE, Firefox FTW!

Forward referencing with .echoln shouldn't work at all (this is by design).

Huh? Why did you designed it this way? I'll see if I didn't put a libs_start before it somehow...

The translation capability is not a feature of Brass, it's handled automatically by the .NET framework. .NET uses the UI thread's culture (set by the edition of Windows you own) to determine which satellite assemblies to load. You can spoof this (for testing purposes) by manually setting the thread culture with another app. I can release a tool that lets you specify the desired culture if you so wish? If you don't want to use the Dutch translation, delete the satellite assembly (nl\Brass.resources.dll).

If you mean that you'll include it in the distribution then I think that's a good idea.

The recompile button is a great idea.

Make sure I don't forget a stay on top checkbox (or set it by default).
I mainly suggested this because it takes a long time (uh... 5 secs, yes I am that impatient) to start Brass, so if it were possible to keep it in RAM, that should speed up loading time.

[benryves]

I used the help executable, all other arrows display correctly and I never use IE, Firefox FTW!

If you use the help viewer, you're using IE. (Same goes for the graphical builder, that too is IE-based).

Huh? Why did you designed it this way? I'll see if I didn't put a libs_start before it somehow...

Having each directive try and handle itself in two different ways (depending on the current pass) caused some nasty bugs. For example, a naïve implementation of .echoln would only run in the second pass, which would "fix" the forward referencing issue. However, what if you did this?

Code: Select all

x = 0
.echoln x = 1
.if x
    ld a,10
.endif

In the first pass, x would still be zero, so ld a,10 wouldn't be assembled. In the second pass, x would be one, so ld a,10 would attempt to be assembled and break the synchronisation between passes. Of course, I could block assignments, but then you would get another problem:

Code: Select all

.function x()
    .db "Hello"
.endfunction

.echoln x()

If you mean that you'll include it in the distribution then I think that's a good idea.

It could only really be for debugging purposes, eg "RunLoc en-US Brass Project.xml".

Make sure I don't forget a stay on top checkbox (or set it by default).
I mainly suggested this because it takes a long time (uh... 5 secs, yes I am that impatient) to start Brass, so if it were possible to keep it in RAM, that should speed up loading time.

Hehe, OK.

I could of course mention the fact that the source code is available in the zip, so if you want to have a go at writing your own front-end to rebuild projects (and maybe launch a debugger or something for you) take a look at the bundled projects and the .chm Brass class library reference.

[driesguldolf]

I could of course mention the fact that the source code is available in the zip, so if you want to have a go at writing your own front-end to rebuild projects (and maybe launch a debugger or something for you) take a look at the bundled projects and the .chm Brass class library reference.

Hmm...

Btw, I'm missing .relocate, .endrelocate, .deflong and .enddeflong?
Did I missed something?

EDIT: Ah yes, .macro replaced .deflong, correct?
EDIT2: And for .relocate I need to modify the program counter (but leave the output counter alone)

[benryves]

Hm, sorry, I found a couple of label resolution bugs but have not thoroughly tested the fix yet. :\

.relocate/.endrelocate haven't been implemented (but, as you say, changing $ should be enough). There is no .deflong, but .macro or .function should do the trick!

[driesguldolf]

Now I'm confused, in which thread am I supposed to post bug reports now?

anyway, not really a bug, just an inconvenience.
If you forget an end quote (of a string) then brass thinks the next lines are all part of the string.
This might be intended, but a warning would be better I think.

Code: Select all

Duplicate label 'bytes'.
	.include "XBall\\engine.inc

.echoln "XBall:      ", $-start_of_code, " bytes (engine: ", engine.size, " bytes)."
.endmodule

;====================
; End of file
;====================

Also while writing this I found out that brass is too attached to shortcut keys, ctrl-c doesn't work, neither does right clicking. Drag and drop does work however.

Suggestion: It might be interesting if brass gave a warning if a local label stretches multiple files.
Something like this:

File "file1.txt"

Code: Select all

-  jp +

File "file2.txt"

Code: Select all

+  jp -

Is perfectly valid and could cause some severe headaches
(same for modules/sections etc.)

More on that:

Code: Select all

-  jp {-}

gives an error... I haven't tested it in an expression however. (brass 3 doesn't like the {})

EDIT: the forum also formats text wrong in quotes if that quote includes code

[benryves]

You should really use the other thread for bug reports (this is a pretty much a dead thread).

Strings constants continuing past the end of the line is by design, maybe I could C#-ise this capability with an @ sign in front of the string, eg:

Code: Select all

.db @"This
is
a
multiline
string", 0

I disabled all shortcut keys in IE again, I think I need to reenable them again and hopefully it'll work this time..!

Triggering an event when you leave the current file (when assembling) could be used to detect cross-file problems I suppose. Reusable labels could be an especially big problem.