Glass Z80 assembler 0.5

Trying to... not quite there yet, but trying to...

I'm looking for a good disassembler.

I try to be as supportive of OOP style in Glass as I can, because it is how I write my software myself. However things like polymorphic calls and how objects are created etc. is more about the libraries and implementation choices of code and not so much about the assembler itself.

E.g. there are several ways to instantiate objects, statically, on a heap, with or without a template, etc. And there are also several ways to do virtual calls, with different performance, memory usage and flexibility trade-offs. The assembler isn’t much of a help there except to try and facilitate it.

For example I define and use a class as follows:

ClassTest: MACRO
	dummy:
		db 0
	_size:
	ENDM

ClassTest_class: Class ClassTest, Heap_main

; ix = this
ClassTest_Construct:
	ld (ix + ClassTest.dummy),255
	ret

; ix = this
ClassTest_Destruct:
	ret

ClassTest_Test:
	call ClassTest_TestConstructDestruct
	ret

ClassTest_TestConstructDestruct:
	call ClassTest_class.New
	call ClassTest_Construct
	call ClassTest_Destruct
	call ClassTest_class.Delete
	ret

There are some syntactic sugar things where Glass is helpful here, e.g. being able to pass ClassTest into the Class definition macro, to determine its size, instantiate a template, and to reference .New and .Delete static members on it. In principle OOP can be done in any assembler, however definitely I started work on Glass to simplify the syntax of these things for me.

Hi Wlcracks,

Thanks for checking out Glass.

I reluctantly added the 0x support that was submitted because there’s one or two assemblers (e.g. Sjasm) which support it as well, so there was some argument for interoperability with them. However it’s not standard assembly syntax at all, so code using the 0x prefix will not be portable, and 0b even less so. I don’t think it’s good to introduce more C syntax into assembly (like 0b or // comments).

I don’t recommend using 0x. I recommend to use H and B suffixes, or # / $ and %, which are fairly universally supported. You will get used to it very quickly.

Just a noobisch question.
1000H is fine
9000H is fine
but A000H gives an error
seems it needs a leading zero, so 0A000H
Can you please tell me the story behind this?
When do you add this extra zero and why?
loading 16bits registers require a extra 8 bit?

Feel free to ask!

It is only required when the hexadecimal number starts with a letter.

It’s certainly not a glitch, nor has to do with limited memory . Every assembler requires this extra 0 for H/B suffix notation, and there’s a very logical reason for it:

In the grammar of assembly language, every symbol (label) starts with a letter, so number literals can not. Otherwise they are not distinguishable. E.g. consider a symbol ADDH, it would be very surprising if that would be generating the number 2781. A000H is a symbol as well, not a number.

If the leading 0 bothers you, you can also use # and % prefixes, which don’t require a leading zero because the prefix already distinguishes it from a symbol.

p.s. This isn’t an extra 4 bits, A0 and 0A0 are the same number, just like in decimal 0010 is exactly the same number as 10. Glass actually stores 32-bit numbers internally, and truncates them to 8 or 16-bit when output. This is so you can do math more easily (like 1000 * 555 / 111) without running into precision problems.

Interesting, I did not know this was an issue. I guess not all assemblers have this problem/issue, at least not the one I use (tniasm 1.0).

I tried sjasm earlier but that resulted in error in labels when I changed 0xsomething to somethingh so for now I guess tniasm 1.0 is the only exception to the rule?

Are there any other oddness/quirks similar to this in general? Would be nice to know if before I think there is something wrong with the code i've written

I guess not a bug in glass, its a logical response but i am not sure this is what the ideal situation would be:

1.

in glass:

equ_SB1_Color_data equ ((equ_VDP_Color_Gray << 4) + equ_VDP_Color_Yellow)

ld hl, equ_VDP_color_table_screenblock1_address ; HL - Destination
ld bc, equ_VDP_color_table_screenblock1_lenght ; BC - Fill lenght
ld a, equ_SB1_Color_data ; A - Fill data
call FILVRM ; fill vram

OpenMSX debugger reports:

ld hl,#2000
ld bc,#0800
ld a,(#00ea)
call #0056

2.

in glass:

equ_SB1_Color_data equ (equ_VDP_Color_Gray << 4) + equ_VDP_Color_Yellow

ld hl, equ_VDP_color_table_screenblock1_address ; HL - Destination
ld bc, equ_VDP_color_table_screenblock1_lenght ; BC - Fill lenght
ld a, equ_SB1_Color_data ; A - Fill data
call FILVRM ; fill vram

OpenMSX debugger reports:

ld hl,#2000
ld bc,#0800
ld a,#ea
call #0056

Situation 1. would be expected when ld a,(equ_SB1_Color_data)
?

Grauw, you getting bored of me already?

ok cool thanks.
next q

I want to reserve a area for a konami mega rom mapper mechanism. I want to lock the 0x4000-0x7fff for now and be able to page as shown in:
http://112-226-144-85.ftth.glasoperator.nl/msx/MegaROM.htm

This small example doesnt want build a file greater then 64kb.
---
ROM_Page00_01: ds #4000
ROM_Page02: ds #2000
ROM_Page03: ds #2000
ROM_Page04: ds #2000
ROM_Page05: ds #2000
ROM_Page06: ds #2000
;ROM_Page07: ds #2000
;ROM_Page08: ds #2000
;ROM_Page09: ds #2000
;ROM_Page10: ds #2000
RAM: ds VIRTUAL #1000

; ROM Page 0, 1 locked on 0x4000 - 0x7fff

SECTION ROM_Page00_01

org #4000 ; expansion ROM header

db #41 ; "A"
db #42 ; "B"
dw Init ; start of the init code, 0 if no initcode
dw #0000 ; pointer to CALL statement handler, 0 if no such handler
dw #0000 ; pointer to expansion device handler, 0 if no such handler
dw #0000 ; pointer to the start of a tokenized basicprogram, 0 if no basicprogram
dw #0000 ; room reserved for future extensions
dw #0000
dw #0000

Init:
ret

ENDS

SECTION ROM_Page02
db "PAGE02"
ENDS

SECTION ROM_Page03
db "PAGE03"
ENDS

SECTION ROM_Page04
db "PAGE04"
ENDS

SECTION ROM_Page05
db "PAGE05"
ENDS

SECTION ROM_Page06
db "PAGE06"
ENDS

;SECTION ROM_Page07
;db "PAGE07"
;ENDS

SECTION RAM
db 0
ENDS
---

Adding page07 and higher doesnt work. I seems fine for the lower pages.

Errors reported:
---
>java -jar c:\prg\glass\glass-0.5.jar test_mega_rom.asm test_mega_rom.rom
Exception in thread "main" nl.grauw.glass.AssemblyException: Address out of range: 10000H
[at test_mega_rom.asm:7]
;ROM_Page08: ds #2000
at nl.grauw.glass.Scope.setAddress(Scope.java:42)
at nl.grauw.glass.instructions.InstructionObject.resolve(InstructionObject.java:18)
at nl.grauw.glass.Line.resolve(Line.java:113)
at nl.grauw.glass.Source.resolve(Source.java:82)
at nl.grauw.glass.Source.resolve(Source.java:77)
at nl.grauw.glass.Source.assemble(Source.java:60)
at nl.grauw.glass.Assembler.writeObject(Assembler.java:55)
at nl.grauw.glass.Assembler.main(Assembler.java:44)
---
Thanks again.

Hello Grauw, Thank you, nice to hear glass is still in development. I will try your solution.

Sorry to bother again, working hard for Njimegen!!. But is there a C like way to rem - out large blocks of code in Glass

e.g.
/*
disabled or long stories
*/

Thanks

Ok, thanks, just making sure i am doing it right.

That is legal, but probably doesn’t do exactly what you want, because it will output 807H bytes.

Replace the variables with DS VIRTUAL to increment the address pointer without actually outputting any data:

var_ScratchMemory: equ #c000
    ds #800

    org var_ScratchMemory
var_A: ds virtual 1
var_B: ds virtual 2

    org var_ScratchMemory
var_C: ds virtual 2
var_D: ds virtual 1
var_E: ds virtual 1

Alternatively you could use macros to define offsets and use those, e.g.:

structure1: MACRO
    var_A: db 0
    var_B: dw 0
    ENDM

structure2: MACRO
    var_C: dw 0
    var_D: db 0
    var_E: db 0
    ENDM

    org #c000
var_ScratchMemory:
    ds #800

And then access it like:

    ld a,(var_ScratchMemory + structure1.var_A)
    ld ix,var_ScratchMemory
    ld e,(ix + structure2.var_E)

Etc.

tok tok is this on

Ofcourse an other question
what is the "correct" way of loading the low byte of a 16bitter.

ld a, equ_VDP_pattern_name_table_screenblock1_address ; only lowest byte?

or

ld a, equ_VDP_pattern_name_table_screenblock1_address&#ff ; only lowest byte?

? i dont have a clue

high byte seems fine:

ld a, (equ_VDP_pattern_name_table_screenblock1_address>>8)|#40

Seems to work but to avoid future unexplainable bugs i would like to do it correctly.

Thanks again

Both are ok. In principle it’s this:

ld e,address & 0FFH       ; lsb
ld d,address >> 8         ; msb

But as you showed you can also omit the & 0FFH since the value is clipped down to 8 bits anyway. It’s a matter of preference, how explicit you want to be. Personally I prefer to be explicit because that works in all contexts (also calculations and 16-bit loads), and the pattern of >> 8 and & 0FFH is very recognisable so the intent is clear quickly.

p.s. Here’s what I do the other way around, composing a 16-bit value out of two 8-bit ones:

ld de,msb << 8 | lsb

Here you are;

macro.zip

Changing the the flag in enum.inc will get it assembling or not. Not sure its a bug could be an "nesting" or a wrong approach from my side.

Thank you again, also for the other answers, very helpful. Glass is spot on and a delight to work with.

awesome thanks!

The macros in Glass are not treated like preprocessing directives as in other assemblers, so variables can’t be “pasted” into labels or strings like that.

There are two things here, firstly the string concatenation, in db pseudoinstructions you can combine strings with the , operator but that doesn’t work for incbin at the moment. I should add that, shouldn’t even be very difficult, so I’ve made an issue for it. I don’t think I’ll have time for it before the Nijmegen fair next week, but I should be able to after.

Secondly, labels can’t be built from strings. However they do exist in the scope of the macro, so you can define the macro like this and access the fields inside as a structure:

macro_SC2_include: MACRO ?filename
SC2:
PGT_B1:
    incbin "gfx/",?filename,".PGT_B1.mom"
CT_B1:
    incbin "gfx/",?filename,".CT_B1.mom"
PGT_B2:
    incbin "gfx/",?filename,".PGT_B2.mom"
CT_B2:
    incbin "gfx/",?filename,".CT_B2.mom"
PGT_B3:
    incbin "gfx/",?filename,".PGT_B3.mom"
CT_B3:
    incbin "gfx/",?filename,".CT_B3.mom"
    ENDM

Field: macro_SC2_include "field"
House: macro_SC2_include "house"
Basement: macro_SC2_include "basement"

And then access the fields as follows:

    ld hl,Field.PGT_B1
    ld de,House.CT_B3
    ld ix,Basement.SC2

Etc.

But as said, the string concatenation doesn’t work yet, so until I implement that you’d need some other way. One option is to not use a macro for this for now and copy/paste the code that’s currently in it. Alternatively you could consider though to concatenate the six files into one so they can be included in one go, and make a macro just for the offsets in it:

macro_SC2_include: MACRO ?filename
SC2:
    incbin ?filename
PGT_B1: equ SC2
CT_B1: equ PGT_B1 + 2048
PGT_B2: equ CT_B1 + 2048
CT_B2: equ PGT_B2 + 2048
PGT_B3: equ CT_B2 + 2048
CT_B3: equ PGT_B3 + 2048
    ENDM

Field: macro_SC2_include "gfx/field.mom"

Having fun in glass.
But it would be cool to have some kind of general reporting.
WARNING could work
But just a general PRINT
and the possibility to do something like:
PRINT ?define_LastRomByte
PRINT ?code_Lenght
or PRINT "Codelenght: "?code_Lenght
would be awesome!
I know the .sym is there but (calculated) equ's are not in the file.
I guess this could be an easy one since WARNING is already there??
When you have time? Sometime?