online assembler for Z80

Page 1/2
| 2

By Leo

Paragon (1236)

Leo's picture

29-06-2012, 21:45

Hi All,

check this link here below, it looks an online Z80 assembler with load/save , it looks one can build targets for ti83 and spectrum series only , i dont think someone reported it on msx.org :

http://clrhome.org/asm/

ok fine , one more assembler ... LOL!

Login or register to post comments

By RetroTechie

Paragon (1384)

RetroTechie's picture

30-06-2012, 01:55

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! Hannibal Better stick to known good & working assemblers...

By erwinmusik

Master (140)

erwinmusik's picture

30-06-2012, 17:32

Crazy Crazy
plain code seems to right after online assemble, download and disassemble
Online:

    LD	A,0ffh
    LD	HL,3FFFh
    LD	(HL),A
    RET
Z80 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: Hannibal

    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)

By Deep Thought

Supporter (5)

Deep Thought's picture

30-06-2012, 21:52

RetroTechie wrote:

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

erwinmusik wrote:

But this failed: Hannibal

    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 ~

By erwinmusik

Master (140)

erwinmusik's picture

30-06-2012, 22:02

Yes, DEFB and DEFW are Define Byte and Define Word
and DB saves a lot of Bytes
Most Assemblers uses this, I´m shure.

Cheers!
Good work up to this

By Deep Thought

Supporter (5)

Deep Thought's picture

30-06-2012, 22:17

Oh, I see how it works.

The thing is that all the assemblers I've used (TASM, Spasm, Brass) required a dot before directives such as DB and DW, and that's how ORG parses them.

In other words, 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.

By the way, do you have any requests for build formats? I don't know what the MSX file format looks like, but if you could give me a link I can add that to the Build drop-down menu. After all, ORG is meant to be a cross assembler—it can already output as TI-83 Plus programs and apps and as ZX Spectrum tape files, and the more formats it knows, the better.

By RetroTechie

Paragon (1384)

RetroTechie's picture

01-07-2012, 04:09

Deep Thought wrote:

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... oO 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 Wink ). @ That point, no ambiguity remains & extra dots are redundant.

Quote:

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... Smile Not that important though, search-and-replace to turn "DB" into ".DB" is simple enough.

Quote:

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.

By Deep Thought

Supporter (5)

Deep Thought's picture

01-07-2012, 05:23

RetroTechie wrote:
Deep Thought wrote:

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

RetroTechiee wrote:

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.

RetroTechiee wrote:

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 Tongue

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

RetroTechiee wrote:
Quote:

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.

By RetroTechie

Paragon (1384)

RetroTechie's picture

01-07-2012, 07:03

Deep Thought wrote:

.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 $+400

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

Quote:

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?

Quote:

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... Smile Like said, raw binary output is all you need for MSX assembly coding.

By Deep Thought

Supporter (5)

Deep Thought's picture

01-07-2012, 08:16

RetroTechie wrote:
Deep Thought wrote:

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

RetroTechie wrote:

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 $+400

That's what I'm used to, and that's how ORG rolls Smile 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.

RetroTechie wrote:

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.

RetroTechie wrote:
Quote:

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 Tongue

Anyway, thanks for your help! Hope the MSX community finds the ORG project useful as well.

By RetroTechie

Paragon (1384)

RetroTechie's picture

01-07-2012, 20:57

Hehe... xkcd.com/927/

Page 1/2
| 2
My MSX profile