online assembler for Z80
Nice! However, when I input assembly for a small hello world-like .bin, it assembles
.db "Hello world!",0
as a single 0-byte (above line unmodified from the example snippet).
--> Fail! 
Better stick to known good & working assemblers...
plain code seems to right after online assemble, download and disassemble
Online:
LD A,0ffh
LD HL,3FFFh
LD (HL),A
RETZ80 DISASSEMBLER LISTING Line Addr Opcodes Label Instruction -------------------------------------------------- 0001 0000 3E FF LD A,0FFH 0002 0002 21 FF 3F LD HL,3FFFH 0003 0005 77 LD (HL),A 0004 0006 C9 RET
But this failed:
DEFB 0FFh
DEFW 0AAAAh
LD A,0ffh
LD HL,3FFFh
LD (HL),A
RET
DB "TEST"
Error parsing line (line " DEFB 0FFh" in hello_z80)Error parsing line (line " DEFW 0AAAAh" in hello_z80)Error parsing line (line " DB "TEST"" in hello_z80)
Nice! However, when I input assembly for a small hello world-like .bin, it assembles
.db "Hello world!",0
as a single 0-byte (above line unmodified from the example snippet).
--> Fail! Better stick to known good & working assemblers...
I accidentally created that bug yesterday (I typed a 0 instead of a 1, and it screwed up all string data). I've just fixed it.
But this failed:
DEFB 0FFh
DEFW 0AAAAh
LD A,0ffh
LD HL,3FFFh
LD (HL),A
RET
DB "TEST"
Error parsing line (line " DEFB 0FFh" in hello_z80)Error parsing line (line " DEFW 0AAAAh" in hello_z80)Error parsing line (line " DB "TEST"" in hello_z80)
I'm sorry, I've never seen the instructions DEFB or DEFW before. (The assemblers I usually use don't have that feature.) Are they equivalent to .db and .dw? If so, I can easily add them.
Anyway, hi, I'm the author of ORG. Cheers ~
I'm sorry, I've never seen the instructions DEFB or DEFW before. (The assemblers I usually use don't have that feature.)
That's a-typical for a Z80 programmer... 
At least for the Z80, these are pretty common pseudo-ops (but I've seen these in assembler listings for other architectures too). Along with DEFS <count>[,value] to include X number of bytes in the code (in contrast with ORG which is used for similar purpose, but shouldn't generate code by itself). And DEFM "string" as a separate pseudo-op to output ASCII string data. Which is kind of redundant, since a decent assembler takes DEFB "string" as well.
DB, DW, DM and DS are simply short form synonyms. Some assemblers may recognize only those, some assemblers may recognize only the long form, a good Z80 assembler should recognize both forms I think. And no biggie if DM/DEFM isn't recognized.
Requiring dots before pseudo-ops might make sense to tell regular instructions and pseudo-ops apart, but I don't really see the point. If it's not a Z80 instruction, then it's either a pseudo-op, a label, or a syntax error. So all you need is a way to tell labels apart from other instructions (like require that they start on beginning of a line, or should end with ":", that they're used somewhere, whatever). Requiring that a label can never match a Z80 mnemonic is simple enough, you might also require that label names can't match a pseudo-op (a Z80 programmer that uses for example "DB" as label is an idiot anyway so who cares 
). @ That point, no ambiguity remains & extra dots are redundant.
I can easily add .defb and .defw, but to allow them not to have dots before (as in DEFB and DEFW), I'd have to rewrite most of the engine. As it is now, DB, DEFB, END, and so on are valid identifiers for equates and labels as long as they're not preceded by a dot.
Okay I can dig that... Seems like a basic choice between "allow pseudo-ops as label names" vs. "no dots needed, label names can't be pseudo-ops". Guess I already stated my personal preference on that... 
Not that important though, search-and-replace to turn "DB" into ".DB" is simple enough.
By the way, do you have any requests for build formats?
There's really 3 formats for MSX:
.COM: no header of any kind, ORG set to 0100h.
.BIN: 7 byte header containing FEh, load address, last address, start address. No default value for ORG (so default to 0 for example).
.ROM: 16 byte header, contents depending on type of ROM, ORG usually set to 4000h or 8000h.
IMHO no special support for any of the above is necessary - raw binary output is fine for any MSX assembly programmer that knows what (s)he is doing.
I'm sorry, I've never seen the instructions DEFB or DEFW before. (The assemblers I usually use don't have that feature.)
That's a-typical for a Z80 programmer... At least for the Z80, these are pretty common pseudo-ops (but I've seen these in assembler listings for other architectures too). Along with DEFS <count>[,value] to include X number of bytes in the code (in contrast with ORG which is used for similar purpose, but shouldn't generate code by itself).
I've always been used to the .block and .fill directives serving that purpose, and that's what ORG uses. .block takes one argument which is the number of null bytes to insert, and .fill can take one or two—if two are given, m and n, it'll insert m bytes of char n, and if only one is given, it'll insert that many $FF bytes.
Sounds like DEFS is a pretty close substitution for these directives though. I'll add it when I get the chance.
And DEFM "string" as a separate pseudo-op to output ASCII string data. Which is kind of redundant, since a decent assembler takes DEFB "string" as well.
I see. I've always used .db for that (.dw can take a string too, but it inserts the UTF-16 equivalent of that string which I guess isn't terribly useful). I just looked up some docs, and it seems DEFM is now essentially equivalent to .db, so I can add that fairly easily, as .defm.
DB, DW, DM and DS are simply short form synonyms. Some assemblers may recognize only those, some assemblers may recognize only the long form, a good Z80 assembler should recognize both forms I think. And no biggie if DM/DEFM isn't recognized.
I see. I'll add the long forms just as an extra convenience, but they will still require a dot before, partly for consistency and partly because I'm too lazy to rewrite the engine 
And funny—I always thought .db and .dw were short forms for .byte and .word (at least that's how it works in TASM syntax).
By the way, do you have any requests for build formats?
There's really 3 formats for MSX:
.COM: no header of any kind, ORG set to 0100h.
.BIN: 7 byte header containing FEh, load address, last address, start address. No default value for ORG (so default to 0 for example).
.ROM: 16 byte header, contents depending on type of ROM, ORG usually set to 4000h or 8000h.
IMHO no special support for any of the above is necessary - raw binary output is fine for any MSX assembly programmer that knows what (s)he is doing.
Thanks, I'll look into them anyway. They're a heckuva lot simpler than the Spectrum TAP files—for those I apparently had to also generate a BASIC program loader and other stuff. BIN is most likely out of the question though because I reserved them for plain binary files, though.
.block takes one argument which is the number of null bytes to insert, and .fill can take one or two—if two are given, m and n, it'll insert m bytes of char n, and if only one is given, it'll insert that many $FF bytes.
If I'm reading the correct docs, then DS (Define Space) and .fill are the same thing.
When you want "include X bytes here in the code", then it's often wise to initialize those bytes to a known value. Either explicit (2nd argument in .fill / DS) or via a known default.
When you want "increase program counter (ORG value) with X, without actually including that # of bytes in the binary": I've encountered a few cases in the past where that might be useful. Usually solved with an ORG expression involving ORG's current value, like:
ORG $+400If you want to have labels, jump addresses etc reflect a 400 byte space, without adding 400 bytes to the size of the binary. Used for relocatable blocks of code and things like that. I suppose that's what .block is for? (just moving the goal posts). If OTOH .block outputs data, I don't see the point since .fill / DS already serves that function.
And funny—I always thought .db and .dw were short forms for .byte and .word (at least that's how it works in TASM syntax).
Hmm yeah... "insert 1-byte value", and "insert 2-byte value". Just many different names for those 2 actions, right?
BIN is most likely out of the question though because I reserved them for plain binary files, though.
Well this online assembler already can produce BLOAD-able .BIN files for an MSX - simply a matter of starting the source with a few appropriate lines... Like said, raw binary output is all you need for MSX assembly coding.
.block takes one argument which is the number of null bytes to insert, and .fill can take one or two—if two are given, m and n, it'll insert m bytes of char n, and if only one is given, it'll insert that many $FF bytes.
If I'm reading the correct docs, then DS (Define Space) and .fill are the same thing.
When you want "include X bytes here in the code", then it's often wise to initialize those bytes to a known value. Either explicit (2nd argument in .fill / DS) or via a known default.
Its a bit weird. Seems they're basically the same except that DEFS defaults to $00 while .fill defaults to $FF (I'm looking at http://www.nongnu.org/z80asm/directives.html and http://home.comcast.net/~tasm/tasmman.htm#ASSEMBLER_DIRECTIVES). Guess I'll throw in both of them and leave it up to user preference.
When you want "increase program counter (ORG value) with X, without actually including that # of bytes in the binary": I've encountered a few cases in the past where that might be useful. Usually solved with an ORG expression involving ORG's current value, like:
ORG $+400That's what I'm used to, and that's how ORG rolls I know some assemblers have a quirk where they actually insert a block of null bytes to make up the difference (essentially acting as an implied DEFS). Glad to hear that's not something you guys would expect.
I suppose that's what .block is for? (just moving the goal posts). If OTOH .block outputs data, I don't see the point since .fill / DS already serves that function.
It does output data. From what I understand .block acts like DEFS without the second argument, inserting a block of null bytes. The thing is that in TASM syntax, .fill defaults to $FF, rather than $00 like DEFS, so .block is there to quickly add $00 bytes.
Again, I'll just make both syntaxes available and leave it up to the user.
And funny—I always thought .db and .dw were short forms for .byte and .word (at least that's how it works in TASM syntax).
Hmm yeah... "insert 1-byte value", and "insert 2-byte value". Just many different names for those 2 actions, right?
Right. The variation among assemblers is really annoying
Anyway, thanks for your help! Hope the MSX community finds the ORG project useful as well.
