[N8VEM: 19452] Problem with z80asm ORG statement

[Ants Pants]

Hi Guys,

im having problems with z80asm compiling a simple test program. im using
the org statement so the code gets compiled to run at 0xB000, but whenever
i compile with z80asm it gives me back the program starting at 0x0000, i
have ported the source for compatibility with TASM and compiled it with
this and i get what is expect, code at 0xB000. i have been through the
manual for z80asm but i cant seem to figure out what im doing wrong.
included below is the source ive attempted to compile with z80asm and the
output in intel .hex format - that i have but spaces in between the
bytecount/address/rtype/Data/check for easier reading:

;--------------------------------------------------------------
gpport: equ 0x21
ORG 0xB000
start:
LD A, 0xFf
out (gpport), a
call DELAY2
LD A, 0xF0
out (gpport), a
call DELAY2
jp start
DELAY2:
LD C,0x91 ;d1
LD B,0xE1 ;d2
LD A,0x23 ;d3
again31:
DEC C
JP Z, again30
JP again31
again30:
DEC B
JP Z, again32
JP again31
again32:
DEC A
JP Z, again33
JP again31
again33:
RET
;--------------------------------------------------------------

:20 0000 00 3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230DCA1EB0C317B005C
A19
:0D 0020 00 25B0C317B03DCA2CB0C317B0C9 3E
:00 0000 01 FF

with the starting address in pink z80asm compiled to start at 0x0000


As compared to TASM with a similar source, just modifications to syntax:

;--------------------------------------------------------------
gpport: .equ $21
.ORG $B000
start:
LD A, $Ff
out (gpport), a
call DELAY2
LD A, $F0
out (gpport), a
call DELAY2
jp start
DELAY2:
LD C,$91 ;d1
LD B,$E1 ;d2
LD A,$23 ;d3
again31:
DEC C
JP Z, again30
JP again31
again30:
DEC B
JP Z, again32
JP again31
again32:
DEC A
JP Z, again33
JP again31
again33:
RET
.END
;--------------------------------------------------------------



:18 B000 00 3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230D 62
:15 B018 00 CA1EB0C317B005CA25B0C317B03DCA2CB0C317B0C9 9D
:00 0000 01 FF

with the starting address in pink TASM compiled to start at 0xB000

As you can see the machine code is the same, just the org address is
different in the hex file. anyone have an idea of what im doing wrong in
the first source to be compiled with z80asm?

Many thanks,
Antony

[Michael Petry]

I gave your source a compile using the SLR Z80ASM that I use (Version 1.32) and it gave lots of syntax errors. It doesn’t like the 0Xnn syntax and prefers the nnnnH syntax for hex constants. I changed the
ORG 0XB000
to
ORG 0B0000H

It gave the correct ORG in the HEX file. The other hex constants also need changing.

Got to love all the syntaxes for constants and op codes.

Mike


I>z80asm bar/h

Z80ASM Copyright (C) 1983-86 by SLR Systems Rel. 1.32 #AB1234

BAR/H
BAR.Z80 - Bad Number Line 00001
gpport equ 0x21
BAR.Z80 - Bad Number Line 00004
LD A, 0xFf
BAR.Z80 - Bad Number Line 00007
LD A, 0xF0
BAR.Z80 - Bad Number Line 00012
LD C,0x91 ;d1
BAR.Z80 - Bad Number Line 00013
LD B,0xE1 ;d2
BAR.Z80 - Bad Number Line 00014
LD A,0x23 ;d3
End of file Pass 1
6 Error(s) Detected.
45 Absolute Bytes. 7 Symbols Detected.


I>type bar.hex
:20B000003E00D300CD11B03E00D300CD11B0C300B00E0006003E000DCA1EB0C317B005CA2F
:0DB0200025B0C317B03DCA2CB0C317B0C98E
:00000001FF

Post by Ants Pants
Hi Guys,
;--------------------------------------------------------------
gpport: equ 0x21
ORG 0xB000
LD A, 0xFf
out (gpport), a
call DELAY2
LD A, 0xF0
out (gpport), a
call DELAY2
jp start
LD C,0x91 ;d1
LD B,0xE1 ;d2
LD A,0x23 ;d3
DEC C
JP Z, again30
JP again31
DEC B
JP Z, again32
JP again31
DEC A
JP Z, again33
JP again31
RET
;--------------------------------------------------------------
:20 0000 00 3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230DCA1EB0C317B005C A19
:0D 0020 00 25B0C317B03DCA2CB0C317B0C9 3E
:00 0000 01 FF
with the starting address in pink z80asm compiled to start at 0x0000
;--------------------------------------------------------------
gpport: .equ $21
.ORG $B000
LD A, $Ff
out (gpport), a
call DELAY2
LD A, $F0
out (gpport), a
call DELAY2
jp start
LD C,$91 ;d1
LD B,$E1 ;d2
LD A,$23 ;d3
DEC C
JP Z, again30
JP again31
DEC B
JP Z, again32
JP again31
DEC A
JP Z, again33
JP again31
RET
.END
;--------------------------------------------------------------
:18 B000 00 3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230D 62
:15 B018 00 CA1EB0C317B005CA25B0C317B03DCA2CB0C317B0C9 9D
:00 0000 01 FF
with the starting address in pink TASM compiled to start at 0xB000
As you can see the machine code is the same, just the org address is different in the hex file. anyone have an idea of what im doing wrong in the first source to be compiled with z80asm?
Many thanks,
Antony
--
You received this message because you are subscribed to the Google Groups "N8VEM" group.
Visit this group at http://groups.google.com/group/n8vem <http://groups.google.com/group/n8vem>.
For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

[Ants Pants]

Hi Mike,

thanks for the reply, i can confirm what you have done is correct output, i
compiled with the altair simulator:

Z80 ASSEMBLER Copyright (C) 1983 by SLR Systems Rel. 1.30 #F10268

M40 FH
End of file Pass 1
End of file Pass 2
0 Error(s) Detected.
45 Absolute Bytes. 7 Symbols Detected.

;------------------------------------ source -----------------
gpport equ 021H
ORG 0B000H
start:
LD A, 0FFH
out (gpport), a
call DELAY2
LD A, 0F0H
out (gpport), a
call DELAY2
jp start
DELAY2:
LD C,091H
LD B,0E1H
LD A,023H
again31:
DEC C
JP Z, again30
JP again31
again30:
DEC B
JP Z, again32
JP again31
again32:
DEC A
JP Z, again33
JP again31
again33:
RET
;------------------------------------ source -----------------

to get code at 0xB000:

:20 B000 00
3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230DCA1EB0C317B005CA 69
:0D B020 00 25B0C317B03DCA2CB0C317B0C9 8E
:00 0000 01 FF

However i atill cant seem to get the "org" statement working in under
Win7x86 or even z80asm in Linux:

for windows i was using: Z80 Module Assembler 1.1.19 (03.11.2012), (c)
InterLogic 1993-2009, Paulo Custod
and Linux z80asm via apt-get



Antony

[Nikolay Dimitrov]

Hi Antony,

Post by Ants Pants
Hi Guys,
im having problems with z80asm compiling a simple test program. im
using the org statement so the code gets compiled to run at 0xB000,
but whenever i compile with z80asm it gives me back the program
starting at 0x0000, i have ported the source for compatibility with
TASM and compiled it with this and i get what is expect, code at
0xB000. i have been through the manual for z80asm but i cant seem to
figure out what im doing wrong. included below is the source ive
attempted to compile with z80asm and the output in intel .hex format
- that i have but spaces in between the
;--------------------------------------------------------------
gpport: equ 0x21 ORG 0xB000 start: LDA, 0xFf out (gpport), a call
LDC,0x91;d1 LDB,0xE1;d2 LDA,0x23;d3 again31: DECC JPZ, again30 JP
again31 again30: DECB JPZ, again32 JP again31 again32: DECA JPZ,
again33 JP again31 again33: RET
;--------------------------------------------------------------
:20 0000 00
3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230DCA1EB0C317B005C A19
:0D 0020 00 25B0C317B03DCA2CB0C317B0C9 3E :00 0000 01 FF
with the starting address in pink z80asm compiled to start at 0x0000
;--------------------------------------------------------------
gpport: .equ $21 .ORG $B000 start: LDA, $Ff out (gpport), a call
LDC,$91;d1 LDB,$E1;d2 LDA,$23;d3 again31: DECC JPZ, again30 JP
again31 again30: DECB JPZ, again32 JP again31 again32: DECA JPZ,
again33 JP again31 again33: RET .END
;--------------------------------------------------------------
:18 B000 00 3EFFD321CD11B03EF0D321CD11B0C300B00E9106E13E230D 62 :15
B018 00 CA1EB0C317B005CA25B0C317B03DCA2CB0C317B0C9 9D :00 0000 01 FF
with the starting address in pink TASM compiled to start at 0xB000
As you can see the machine code is the same, just the org address is
different in the hex file. anyone have an idea of what im doing
wrong in the first source to be compiled with z80asm?
Many thanks, Antony

Here's what I get with z80asm v1.8 on Debian Linux:

$ z80asm example.asm --list=example.lst

# File example.asm
0000 gpport: equ 0x21
0000
0000 org 0xB000
b000
b000 start:
b000 3e ff LD A, 0xFF
b002 d3 21 OUT(gpport), A
b004 cd 11 b0 CALL delay2
b007 3e f0 LD A, 0xF0
b009 d3 21 OUT(gpport), A
b00b cd 11 b0 CALL delay2
b00e c3 00 b0 JP start
b011
b011 delay2:
b011 0e 91 LD C, 0x91
b013 06 e1 LD B, 0xE1
b015 3e 23 LD A, 0x23
b017
b017 again31:
b017 0d DEC C
b018 ca 1e b0 JP Z, again30
b01b c3 17 b0 JP again31
b01e
b01e again30:
b01e 05 DEC B
b01f ca 25 b0 JP Z, again32
b022 c3 25 b0 JP again32
b025
b025 again32:
b025 3d DEC A
b026 ca 2c b0 JP Z, again33
b029 c3 17 b0 JP again31
b02c
b02c again33:
b02c c9 RET
# End of file example.asm
b02d

Looking at the listing, I think that the addresses are OK (JP points to
the right address each time). The resulting a.bin file doesn't have the
ORG statement embedded (no way to do this), so if you try to convert the
BIN to HEX, it's quite normal to see what you see.

If you want to get your BIN at the proper offset, you have several options:
1. Force z80asm to directly generate the HEX, so it can retain the ORG
offset without any conversion (I'm not sure z80asm supports this)
2. Give an offset argument to your HEX conversion tool, so it can add
the ORG offset to the output
3. Use the BIN file as-is, just load it in your EPROM programming
software at the desired offset.

Hope this helps. Regards,
Nikolay

[Ants Pants]

Hi Nikolay
thanks for the reply, i can confirm the .lst file you produced via z80asm i
get the same thing, however (see below pics) if i input the .bin file i
still end up with machine code starting at 0x0000 and nothing at 0xB000. i
have tried inputting the file into multiple different prom/flash programmer
software and the same result, the below pics are with the GQ software for a
GQ-4X i use for some uv-prom, another example is with programmer software
for CH341A.. code still starts at 0x0000 and nothing but 0xFF at address
0xB000


<Loading Image...>


<Loading Image...>


<Loading Image...>

[A A]

Post by Ants Pants
thanks for the reply, i can confirm the .lst file you produced via z80asm
i get the same thing, however (see below pics) if i input the .bin file i
still end up with machine code starting at 0x0000 and nothing at 0xB000. i
have tried inputting the file into multiple different prom/flash programmer
software and the same result, the below pics are with the GQ software for a
GQ-4X i use for some uv-prom, another example is with programmer software
for CH341A.. code still starts at 0x0000 and nothing but 0xFF at address
0xB000

Hi Antony,

Post by Ants Pants
for windows i was using: Z80 Module Assembler 1.1.19 (03.11.2012), (c)

InterLogic 1993-2009, Paulo Custod
and Linux z80asm via apt-get

(This is the assembler from the z88dk compiler package.)

The output is a raw binary without any org information embedded. It's just
pure bytes that you are expected to place at the org address. If you're
just passing that to your tools without telling them that they need to
place the binary at such and such address, you're just going to get the
binary placed at address 0 as you are finding.

Picmaster has already mentioned what you need to do with a raw binary.
Option #1 (force z80asm to generate ihex format) is out as z80asm doesn't
do ihex format.

However, z80asm is normally bundled with appmake inside z88dk. appmake
contains, among other things, options to manipulate rom images including an
option to generate ihex format files from the raw binaries generated by
z80asm.

As an example of creating an ihex format file from a binary in a windows
shell:

1. dir test_CODE.bin ;; this is a raw binary image generated by z80asm
-> 11649 test_CODE.bin

2. appmake +rom -b test_CODE.bin -o tester.bin --org 32768 -s 11649 --ihex
-> 11649 test_CODE.bin
-> 11649 tester.bin
-> 32058 tester.ihx

+rom = invoke generating rom images subroutine
-b filename = source binary
-o filename = output binary
--org n = org address (this only affects ihex)
-s n = final size of output binary (the output will be padded)

Normally appmake +rom is used to manipulate raw binary images so that's why
the convoluted syntax options here.

Another thing you can do is create a binary image for the entire rom. The
binary in this example is ORGed at address 0x8000. Suppose my system has a
32k rom mapped to the top 32k of memory.

1. Generate a blank 32k rom image:

appmake +rom -o test_blank.rom -s 32768
-> 32768 test_blank.rom

"test_blank.rom" is a 32k rom image filled with 0xff bytes by default.

2. Insert the raw binary into the rom image at the correct offset. In this
case the raw binary is ORGed at 32768 and the rom image is going to be
mapped at 32768. So the offset is 0.

appmake +inject -b test_blank.rom -i test_CODE.bin -s 0 -o test_image.rom
-> 32768 test_image.rom

+inject = invoke inject into binary subroutine
-b filename = source binary
-i filename = binary to insert into the source
-o filename = output binary
-s n = offset into source binary where insert will begin

After this "test_image.rom" is a 32k rom image with "test_CODE.bin"
appearing at offset 0.

Anyway, you can solve the problem without resorting to these tools and
probably just by telling your eprom software to use the raw binary at some
offset address. If you want to play with appmake and a newer version of
z80asm, they are found in z88dk: http://nightly.z88dk.org/ inside z88dk/bin

[Nikolay Dimitrov]

Hi Alvin, Antony,

Post by Ants Pants
thanks for the reply, i can confirm the .lst file you produced via
z80asm i get the same thing, however (see below pics) if i input the
.bin file i still end up with machine code starting at 0x0000 and
nothing at 0xB000. i have tried inputting the file into multiple
different prom/flash programmer software and the same result, the
below pics are with the GQ software for a GQ-4X i use for some
uv-prom, another example is with programmer software for CH341A..
code still starts at 0x0000 and nothing but 0xFF at address 0xB000
Hi Antony,

Post by Ants Pants
for windows i was using: Z80 Module Assembler 1.1.19 (03.11.2012),

(c) InterLogic 1993-2009, Paulo Custod and Linux z80asm via apt-get
(This is the assembler from the z88dk compiler package.)
The output is a raw binary without any org information embedded.
It's just pure bytes that you are expected to place at the org
address. If you're just passing that to your tools without telling
them that they need to place the binary at such and such address,
you're just going to get the binary placed at address 0 as you are
finding.
Picmaster has already mentioned what you need to do with a raw
binary. Option #1 (force z80asm to generate ihex format) is out as
z80asm doesn't do ihex format.
However, z80asm is normally bundled with appmake inside z88dk.
appmake contains, among other things, options to manipulate rom
images including an option to generate ihex format files from the raw
binaries generated by z80asm.
As an example of creating an ihex format file from a binary in a
1. dir test_CODE.bin ;; this is a raw binary image generated by
z80asm -> 11649 test_CODE.bin
2. appmake +rom -b test_CODE.bin -o tester.bin --org 32768 -s 11649
--ihex -> 11649 test_CODE.bin -> 11649 tester.bin -> 32058
tester.ihx
+rom = invoke generating rom images subroutine -b filename = source
binary -o filename = output binary --org n = org address (this only
affects ihex) -s n = final size of output binary (the output will be
padded)
Normally appmake +rom is used to manipulate raw binary images so
that's why the convoluted syntax options here.
Another thing you can do is create a binary image for the entire rom.
The binary in this example is ORGed at address 0x8000. Suppose my
system has a 32k rom mapped to the top 32k of memory.
appmake +rom -o test_blank.rom -s 32768 -> 32768 test_blank.rom
"test_blank.rom" is a 32k rom image filled with 0xff bytes by
default.
2. Insert the raw binary into the rom image at the correct offset.
In this case the raw binary is ORGed at 32768 and the rom image is
going to be mapped at 32768. So the offset is 0.
appmake +inject -b test_blank.rom -i test_CODE.bin -s 0 -o
test_image.rom -> 32768 test_image.rom
+inject = invoke inject into binary subroutine -b filename = source
binary -i filename = binary to insert into the source -o filename =
output binary -s n = offset into source binary where insert will
begin
After this "test_image.rom" is a 32k rom image with "test_CODE.bin"
appearing at offset 0.
Anyway, you can solve the problem without resorting to these tools
and probably just by telling your eprom software to use the raw
binary at some offset address. If you want to play with appmake and
http://nightly.z88dk.org/ inside z88dk/bin

Yes, I remember playing with Z88DK some months ago, and the toolchain
had an option to insert padding bytes before the ORG, so you can get a
"complete" binary.

Regards,
Nikolay

[t***@old-computers.com]

Hi Antony,

If you use Windows, you can do that:

fsutil file createnew empty.bin 32768 <- that will create an empty 32KB
file (filled with 0)
copy /B empty.bin+your_file.bin your_rom.rom

You'll get a "your_rom.rom" file with your code starting at 0x8000