Brass - 1.0.5.3 update [06/02/2014]

Post by **benryves** » Thu 26 Oct, 2006 5:12 pm

One place I know it is used as filler is when creating something that runs as a "complete" Z80 program - that is, something like an operating system for the calculator or a Master System ROM.

In any case, some sort of directive to allow people to relocate the PC and output the filler bytes would be useful. .orga (absolute origin) is used by WLA-DX to set an absolute origin within the ROM (as opposed to a relative one within the page) so is not a good idea.

CoBB · Post by **CoBB** » Thu 26 Oct, 2006 5:40 pm

Well, there is a very simple way even in TASM to simulate a filling .org: .block new_address-$.

CoBB · Post by **CoBB** » Sat 11 Nov, 2006 9:43 pm

Regarding internationalisation issues I think allowing any letter outside the English alphabet is a bad idea, except for comments and string literals. I presume that the default mapping for strings is a TIOS-friendly one. If there’s no mapping defined for a character, you should signal an error and not try to emit utf-8 or anything like that silently (it’s not clear to me what you planned here).

A minor issue: in my humble opinion allowing the d suffix for decimals creates potential problems without adding anything of real value. Everyone remembers the famous broken ION headers, but who uses this notation for decimal numbers otherwise?

Also, I guess that forward references shouldn’t be allowed in expressions after .org directives.

Expression handling seems to be generally fine this way. It’s indeed easy to establish two-way communication between Brass and the language specific assembler plugin. On the other hand, I don’t see why you’d like to constrain operator tokens. For instance, I’m of the weird kind who prefers the arrow notation for autocopy instructions. The current system can’t handle that.

Post by **benryves** » Mon 13 Nov, 2006 12:58 pm

CoBB wrote:Regarding internationalisation issues I think allowing any letter outside the English alphabet is a bad idea, except for comments and string literals.

It would probably cause the least confusion.

I presume that the default mapping for strings is a TIOS-friendly one.

No, as the TIOS mapping is pretty mental. Rather than having a fixed table, I'll use a hash table which maps a char to a char (char as in 16-bit character, not as in C's "byte" type). This table would be empty at the start, however...

If there’s no mapping defined for a character, you should signal an error and not try to emit utf-8 or anything like that silently (it’s not clear to me what you planned here).

...in this case, it might be sensible to substitute in the "original" value if the input character code is between 32 and 127, otherwise display an error.

A minor issue: in my humble opinion allowing the d suffix for decimals creates potential problems without adding anything of real value. Everyone remembers the famous broken ION headers, but who uses this notation for decimal numbers otherwise?

I'm not sure what problems could be caused, nor am I aware of the broken Ion headers, but I do see your point. I'll remove it.

Also, I guess that forward references shouldn’t be allowed in expressions after .org directives.

Well, absolutely.

Expression handling seems to be generally fine this way. It’s indeed easy to establish two-way communication between Brass and the language specific assembler plugin. On the other hand, I don’t see why you’d like to constrain operator tokens. For instance, I’m of the weird kind who prefers the arrow notation for autocopy instructions. The current system can’t handle that.

I'm aware that some assemblers will have to hack about with the input - for example, with the Z80 index instructions the Z80 plugin would have to remove the IX or IY token before the expression is evaluated. I'm not sure what that means for the arrow notation (not that I've ever seen the arrow notation)...

CoBB · Post by **CoBB** » Mon 13 Nov, 2006 7:12 pm

benryves wrote:No, as the TIOS mapping is pretty mental. Rather than having a fixed table, I'll use a hash table which maps a char to a char (char as in 16-bit character, not as in C's "byte" type). This table would be empty at the start, however...

I imagined so, except for the initial empty state.

benryves wrote:...in this case, it might be sensible to substitute in the "original" value if the input character code is between 32 and 127, otherwise display an error.

At least that much, yes. And I think you should add as many characters as possible to the initial table (like Greek letters with TIOS support).

benryves wrote:I'm not sure what problems could be caused, nor am I aware of the broken Ion headers, but I do see your point. I'll remove it.

Come on, you can’t say you’ve never heard of the infamous ‘.byte $bb, 6d’ incident!

benryves wrote:I'm aware that some assemblers will have to hack about with the input - for example, with the Z80 index instructions the Z80 plugin would have to remove the IX or IY token before the expression is evaluated.

Why is that a problem? Expressions are nicely tokenised and passed in a structured form. You can’t really avoid that with a general parser.

benryves wrote:I'm not sure what that means for the arrow notation (not that I've ever seen the arrow notation)...

I’ve come across these notations so far, and I was thinking of the last one:

rlc b,(ix) / set b,0,(ix)
ld b,rlc (ix) / ld b,set 0,(ix)
rlc (ix)->b / set 0,(ix)->b

All of them are perverse in some way, but so are these instructions.

Post by **benryves** » Tue 14 Nov, 2006 11:35 am

I'm not so sure I'd want TIOS-specific mappings to be part of the assembler. I'd certainly put them in a template, though.

Though, "" is treated as a translated string and '' is treated as an untranslated string. For the untranslated version, do we just truncate to whatever size we want (be it a byte or a word)?

And yes, I do remember the 6d incident now.

I found your Excel spreadsheet with opcodes yesterday and noticed that syntax there. Every other document only mentions the other two, though I'd agree the arrow notation is the 'best' (and isn't misleading, like the 'ld' one).

CoBB · Post by **CoBB** » Tue 14 Nov, 2006 11:55 am

I’m absolutely sure I didn’t make it up myself. But where did I see it then?

Post by **benryves** » Tue 14 Nov, 2006 12:30 pm

I'm missing "I have seen" after "every other document".

You do also list srl b=(ix+$48 ) as yet another option, though.

CoBB · Post by **CoBB** » Tue 14 Nov, 2006 12:42 pm

Yes, I saw that somewhere too, but I wouldn’t really like to see it again, if you ask me.

King Harold · Post by **King Harold** » Fri 24 Nov, 2006 5:06 pm

will brass 2 be able to .echo hexadecimal numbers?
like this:

Code: Select all

.echo $h

..or something like that..
$ being the current instuction adres and h a suffix
that looks odd though, maybe some other notation would be better..

Post by **benryves** » Fri 24 Nov, 2006 5:32 pm

It already can, and uses the String.Format() style syntax from .NET.

Code: Select all

.echo "format string", arg0, arg1, arg2, ...

For your example, you'd do:

Code: Select all

.echo "{0:X4}", $

Take a gander at MSDN for the other types, or just here for the standard numeric types.

In the example, the 0 refers to "argument zero", and the bit after the colon means "upper case hexadecimal padded to 4 characters".

King Harold · Post by **King Harold** » Fri 24 Nov, 2006 5:36 pm

oh - there's nothing about that in the manual

Post by **benryves** » Fri 24 Nov, 2006 5:39 pm

So it isn't, and I'm sure I documented it at some point. Bah. Now you know how to do it, at any rate

King Harold · Post by **King Harold** » Fri 24 Nov, 2006 5:42 pm

Yea, thanx

those decimal numbers were giving me a headache

Post by **benryves** » Wed 17 Jan, 2007 10:42 am

Brass 1.0.4.9 fixes a bug with app branch tables causing it to fail to write debug log files.

I had been hacking code in and out of Brass for Brass 2, so if you find any other oddities let me know ASAP.