Ok! makes sense!
About the colons, I agree, also, without the colons, since macros could potentially start without indentation, there could also be inconsistencies depending on the name you give to your macros. So, I like to add colons in all the labels too. Even when they have an equ.
end: jr end ; Glass does not like "end" as a label, so this does not compile
I am confused about why can't we use "end" as a label, since "end" is not any of the reserved keywords in Glass (like "endm" or "ends"), right?
Hey Santi, I fixed this issue.
The problem was that the global scope should be the parent of the scope of the top level source file, however it was incorrectly defined as its direct scope. So this caused a label redefinition error (and not just for end
).
(I also documented the end
directive, it’s been supported since the very first release.)
Would anyone be bothered if I changed the source file encoding from ISO-8859-1 (Latin-1) to UTF-8?
I think no-one should be impacted by this; I don’t expect anyone to be using non-ASCII characters in strings, since no Z80 platform uses the ISO-8859-1 character encoding anyway. And for comments the file encoding does not really matter either way.
Oh, nice! Thanks for the fix! I'll update MDL's support for Glass in the next release to account for this! As for the encoding, UTF-8 sounds good to me too. The only place where I do see non ASCII characters some times in assembler codebases is in the comments (accents, etc. for Spanish/French/Brazilian code). But since comments do not affect the binary, I think this should be fine
Would anyone be bothered if I changed the source file encoding from ISO-8859-1 (Latin-1) to UTF-8?
I think no-one should be impacted by this; I don’t expect anyone to be using non-ASCII characters in strings, since no Z80 platform uses the ISO-8859-1 character encoding anyway. And for comments the file encoding does not really matter either way.
No, not really.
Cool Glass updates
I Grauw, just for fun, I was trying to compile some of the players that come with Arkos Tracker ( http://www.julien-nevo.com/arkostracker/ ), and they use an undocumented instruction of the Z80 which I think might not be supported by Glass. Specifically, the Arkos player uses:
out (c),0
Which is undocumented ( http://z80-heaven.wikidot.com/instructions-set:out ). When I try to compile with Glass, it complains about invalid arguments. Looking at the code in which this is used in the Arkos player, however, I see that this instruction is used to save a few cycles when sending data to the PSG, which is pretty cool :)
Hey Santiontanon, I don’t support that because it doesn’t work on the R800. Same applies to “sll
”.
The supported undocumented instructions are the ones involving ixh / ixl, etc., and in (c)
(which actually is documented by Zilog… kinda). See the list here.
Of course you can still code the opcode with db
, or make a macro for it.
The R800 does not support it?!?! darn it! ok, ok... then I should reconsider the optimizations I had in mind... but in any case, even if the R800 does not support it, I think having a compiler flag to support it would be good, just for completeness sake :)
To clarify a little bit the situation with “out (c),0” (ED F1 opcode):
This outputs 0 to I/O port C on NMOS Z80 CPUs like the Zilog Z80 and Sharp LH0080.
This outputs 255 to I/O port C on CMOS Z80 CPUs like the Toshiba TMPZ84C00A (in MSX-ENGINE).
So even if you disregard the R800, this undocumented instruction is completely incompatible between different MSX models.
I Grauw, just for fun, I was trying to compile some of the players that come with Arkos Tracker ( http://www.julien-nevo.com/arkostracker/ ), and they use an undocumented instruction of the Z80 which I think might not be supported by Glass. Specifically, the Arkos player uses:
out (c),0
Which is undocumented ( http://z80-heaven.wikidot.com/instructions-set:out ). When I try to compile with Glass, it complains about invalid arguments. Looking at the code in which this is used in the Arkos player, however, I see that this instruction is used to save a few cycles when sending data to the PSG, which is pretty cool :)
Hey Santiontanon, I don’t support that because it doesn’t work on the R800. Same applies to “sll
”.
The supported undocumented instructions are the ones involving ixh / ixl, etc., and in (c)
(which actually is documented by Zilog… kinda). See the list here.
Of course you can still code the opcode with db
, or make a macro for it.
The R800 does not support it?!?! darn it! ok, ok... then I should reconsider the optimizations I had in mind... but in any case, even if the R800 does not support it, I think having a compiler flag to support it would be good, just for completeness sake :)
To clarify a little bit the situation with “out (c),0” (ED F1 opcode):
This outputs 0 to I/O port C on NMOS Z80 CPUs like the Zilog Z80 and Sharp LH0080.
This outputs 255 to I/O port C on CMOS Z80 CPUs like the Toshiba TMPZ84C00A (in MSX-ENGINE).
So even if you disregard the R800, this undocumented instruction is completely incompatible between different MSX models.
Usually I assemble arkos players following the suggested way:
First assembling them with Rasm assembler, then "translating" them to plain assembler using Disark (wich, using the symbol file generated from Rasm, produces a fully labeled source). Then I insert the obtained source in my project and it can be assembled by Glass without problems (so I think that the process gets rid of out (c),0 and replaces it with db way, but I have to check for this)
(so I think that the process gets rid of out (c),0 and replaces it with db way, but I have to check for this)
So it just replaces the syntax, but the instruction is still there… If the player expects to output a 0 to I/O port C, it won’t do that on at least the following machines:
MSX: Fenner FPC-500, Sanyo MPC-1, Sanyo MPC-2, Sanyo MPC-200, Al Fateh 100, Al Fateh 123, Gradiente Expert DDPlus, Gradiente Expert Plus, Sakhr AX-170, Sakhr AX-230, Toshiba HX-51, Toshiba HX-52
MSX2: Panasonic FS-A1FM, Sakhr AX-370, Sanyo PHC-55FD2
MSX2+: Panasonic FS-A1FX, Panasonic FS-A1WSX, Panasonic FS-A1WX, Sanyo PHC-35J, Sanyo PHC-70FD, Sanyo PHC-70FD2
MSX Turbo R: Aucnet NIA-2001, Panasonic FS-A1GT, Panasonic FS-A1ST
So the list is quite large and spanning all generations, making the instruction very incompatible.
For more information see openMSX issue 1408.
I have to check it. But maybe the players that Santi was trying to assemble were the ones for Amstrad CPC (there is a variable to set the desired hardware so it changes the way the source will be assembled)