MaxCoderz

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.

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

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI

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.

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI

It would probably cause the least confusion.

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...
...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.

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.

Well, absolutely.

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)...

I imagined so, except for the initial empty state.


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).


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


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.


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.

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI

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).

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

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI

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

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

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

_________________
The Independent Z80 Assembly Guide
Acelgoyobis
PindurTI

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

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

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

For your example, you'd do:

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".

oh - there's nothing about that in the manual

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

Yea, thanx
those decimal numbers were giving me a headache

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.