Z88dk: Build producing empty .bin files and "ORG address cannot be determined" on Windows

[Fortyseven]

I've just recently started working with z88dk. A new guy with an eye towards building for the ZX Spectrum Next (but starting with plain vanilla Spectrum to get to know the platform first). :)

After reading up and getting it installed on Windows 10 (64-bit 1909, Build 18363.1016), I was able to run make on the directory of Spectrum examples -- they all compiled just fine and ran in cspect.

A couple days passed, and in the morning I created an empty main.c file that just has return -1 in main, as a placeholder. It compiled fine, though -- of course -- it did nothing, as expected.

But I came back later the evening after work, and this time, I got an error: zx: Error: ORG address cannot be determined. I tried everything, with no luck. The .bin file generated is always 0 bytes.

I even did a sanity check on my environment variables (Z80_OZFILES=C:\z88dk\lib and ZCCCFG=C:\z88dk\lib\config), and even went back into the examples directory and ran the Makefile -- all of the projects that built before, now also failed with the same ORG address error.

Several thousand hairs off my head later, I finally just nuked c:\z88dk and unpacked the from the same zip I'd pulled down -- no luck.

So I pulled down the latest nightly at the time, which was newer by a couple days (2020-08-18 03:28).

Same thing.

So... I'm kind of out of options, without knowing the system better.

I did a build of my simple return -1 project with -v, and here's the output of that:

zcc +zx -vn  -create-app -Cz"--sna" -v main.c

PROCESSING main.c
z88dk-ucpp -iquote"." -D__Z88DK -D__SPECTRUM -DSPECTRUM -D__SPECTRUM__ -D__Z80 -DZ80  -DSCCZ80 -DSMALL_C -D__SCCZ80 -isystem"C:\z88dk\lib\config\..\..\/include"    "main.c" "D:\WinTemp\zcc0000129C139A2.i2"
z88dk-zpragma -sccz80 -zcc-opt=D:\WinTemp\zcc0000129C139A3/zcc_opt.def < "D:\WinTemp\zcc0000129C139A2.i2" > "D:\WinTemp\zcc0000129C139A2.i"
sccz80  -ext=opt -mz80 -zcc-opt=D:\WinTemp\zcc0000129C139A3/zcc_opt.def -standard-escape-chars   "D:\WinTemp\zcc0000129C139A2.i" -o "D:\WinTemp\zcc0000129C139A2.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.9" < "D:\WinTemp\zcc0000129C139A2.opt" > "D:\WinTemp\zcc0000129C139A2.op1"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.2" < "D:\WinTemp\zcc0000129C139A2.op1" > "D:\WinTemp\zcc0000129C139A2.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.1" < "D:\WinTemp\zcc0000129C139A2.opt" > "D:\WinTemp\zcc0000129C139A2.asm"
type "D:\WinTemp\zcc0000129C139A2.asm" >> "D:\WinTemp\zcc0000129C139A2.tmp"
type "D:\WinTemp\zcc0000129C139A2.tmp" >> "D:\WinTemp\zcc0000129C139A2.asm"
z80asm -I"C:\z88dk\lib\config\..\..\\lib\target\zx\def" -I"D:\WinTemp\zcc0000129C139A3" -D__SCCZ80  -s  -mz80 -I"C:\z88dk\lib\config\..\..\/lib" "D:\WinTemp\zcc0000129C139A2.asm"

PROCESSING C:\z88dk\lib\config\..\..\\lib\target\zx\classic\spec_crt0.asm
type "C:\z88dk\lib\config\..\..\\lib\target\zx\classic\spec_crt0.asm" >> "D:\WinTemp\zcc0000129C139A4.asm"
type "D:\WinTemp\zcc0000129C139A4.asm" >> "D:\WinTemp\zcc0000129C139A4.tmp"
type "D:\WinTemp\zcc0000129C139A4.tmp" >> "D:\WinTemp\zcc0000129C139A4.asm"
WILL ACT AS CRT

GENERATING OUTPUT

PROCESSING CRT
z80asm -I"C:\z88dk\lib\config\..\..\\lib\target\zx\def" -I"D:\WinTemp\zcc0000129C139A3" -D__SCCZ80  -s  -mz80 -I"C:\z88dk\lib\config\..\..\/lib" -I"C:\z88dk\lib\config\..\..\\lib\target\zx\classic"  "D:\WinTemp\zcc0000129C139A4.asm"

z80asm -mz80 -b -d  -o"a.bin" -m -s -L.   -I"D:\WinTemp\zcc0000129C139A3" -D__SCCZ80 -L"C:\z88dk\lib\config\..\..\/lib/clibs" -I"C:\z88dk\lib\config\..\..\/lib" -lzx_clib -l"z80_crt0"     "D:\WinTemp\zcc0000129C139A4.o" "D:\WinTemp\zcc0000129C139A2.o"
appmake --sna +zx  -b "a.bin" -c "D:\WinTemp\zcc0000129C139A4"
zx: Error: ORG address cannot be determined
Building application code failed
make: *** [Makefile:5: main.sna] Error 1

Any ideas? Or any further information I can supply that might make this make sense?

[Fortyseven]

My working theory is zx: Error: ORG address cannot be determined is a side effect of the empty .bin file fed to the appmake step.

[suborb]

I’m not near a keyboard at the moment. But can you try one or both of the following:

1. Add -clib=new to the command line
2. Remove -Cz—sna

I think there’s a mixing happening between classic and newlib - it looks like sna output isn’t supported by classic.

[Fortyseven]

No dice. Tried it both ways. I even stripped it down to just zcc +zx main.c (with and without -clib=new)

[D:\Home\Dev\zx\project\src] zcc +zx main.c -clib=new -v

PROCESSING main.c
z88dk-ucpp -iquote"." -D__Z88DK -D__SPECTRUM -DSPECTRUM -D__SPECTRUM__ -D__Z80 -DZ80 -D__SCCZ80 -isystem"C:\z88dk\lib\config\..\..\\include\_DEVELOPMENT\sccz80"  -DSCCZ80 -DSMALL_C -D__SCCZ80  "main.c" "D:\WinTemp\zcc00005464FCD12.i2"
z88dk-zpragma -sccz80 -zcc-opt=D:\WinTemp\zcc00005464FCD13/zcc_opt.def < "D:\WinTemp\zcc00005464FCD12.i2" > "D:\WinTemp\zcc00005464FCD12.i"
sccz80  -ext=opt -mz80 -zcc-opt=D:\WinTemp\zcc00005464FCD13/zcc_opt.def -standard-escape-chars   "D:\WinTemp\zcc00005464FCD12.i" -o "D:\WinTemp\zcc00005464FCD12.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.9" < "D:\WinTemp\zcc00005464FCD12.opt" > "D:\WinTemp\zcc00005464FCD12.op1"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.2" < "D:\WinTemp\zcc00005464FCD12.op1" > "D:\WinTemp\zcc00005464FCD12.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.1" < "D:\WinTemp\zcc00005464FCD12.opt" > "D:\WinTemp\zcc00005464FCD12.asm"
type "D:\WinTemp\zcc00005464FCD12.asm" >> "D:\WinTemp\zcc00005464FCD12.tmp"
type "D:\WinTemp\zcc00005464FCD12.tmp" >> "D:\WinTemp\zcc00005464FCD12.asm"
z80asm -I"C:\z88dk\lib\config\..\..\\lib\target\zx\def" -I"C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx" -I"D:\WinTemp\zcc00005464FCD13" -D__SCCZ80  -s  -mz80 -I"C:\z88dk\lib\config\..\..\/lib" "D:\WinTemp\zcc00005464FCD12.asm"

PROCESSING C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx\zx_crt.asm.m4
m4 -I "C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx" -I "D:\WinTemp\zcc00005464FCD13" -I "C:\z88dk\lib\config\..\..\/src/m4"   < "C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx\zx_crt.asm.m4" > "D:\WinTemp\zcc00005464FCD14"
type "D:\WinTemp\zcc00005464FCD14" >> "C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx\zx_crt.asm"
type "C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx\zx_crt.asm" >> "D:\WinTemp\zcc00005464FCD14.asm"
type "D:\WinTemp\zcc00005464FCD14.asm" >> "D:\WinTemp\zcc00005464FCD14.tmp"
type "D:\WinTemp\zcc00005464FCD14.tmp" >> "D:\WinTemp\zcc00005464FCD14.asm"
WILL ACT AS CRT

GENERATING OUTPUT

PROCESSING CRT
z80asm -I"C:\z88dk\lib\config\..\..\\lib\target\zx\def" -I"C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx" -I"D:\WinTemp\zcc00005464FCD13" -D__SCCZ80  -s  -mz80 -I"C:\z88dk\lib\config\..\..\/lib" -I"C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx"  "D:\WinTemp\zcc00005464FCD14.asm"

z80asm -mz80 -b -d  -o"a.bin" -L.  -L"C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\lib\sccz80"   -I"C:\z88dk\lib\config\..\..\\libsrc\_DEVELOPMENT\target\zx" -I"D:\WinTemp\zcc00005464FCD13" -D__SCCZ80 -lzx    "D:\WinTemp\zcc00005464FCD14.o" "D:\WinTemp\zcc00005464FCD12.o"

[D:\Home\Dev\zx\project\src]ls -l
-rwxrwx---+ 1 Fortyseven None     0 Aug 20 00:32 a.bin
-rwxrwx---+ 1 Fortyseven None    27 Aug 19 07:56 main.c

Just for kicks, I tried +sms and +c128 configs to see if that made any difference, but still 0 bytes.

[suborb]

Hmmm. Okay so it is the zero sized file. Which shouldn’t be zero sized - return -1 should be 4 bytes.

So let’s work backwards and see where things are going awry.

If you add -c to zcc you’ll get the object file - you can then run z80nm on it to see what’s in it - I forget the option unfortunately.

If you add -a you should get the assembler output from the compiler - is there anything in main.c.asm.

Likewise you can add -E and get the output of the preprocessor.

[Fortyseven]

Okay, that did produce an object file.

Running z80nm on it in any form results in an error: file 'main.o' not object nor library error.

Here's the contents of main.o:

00000000  ff fe 5a 00 38 00 30 00  52 00 4d 00 46 00 31 00  |..Z.8.0.R.M.F.1.|
00000010  34 00 1c 00 00 00 00 00  00 00 a0 00 a0 00 a0 00  |4...............|
00000020  a0 00 a0 00 a0 00 a0 00  a0 00 a0 00 a0 00 a0 00  |................|
00000030  a0 00 a0 00 a0 00 a0 00  a0 00 06 00 6d 00 61 00  |............m.a.|
00000040  69 00 6e 00 5f 00 63 00                           |i.n._.c.|
00000048

Here's the output of main.o.asm:

;* * * * *  Small-C/Plus z88dk * * * * *
;  Version: 16893-d914de1-20200818
;
;   Reconstructed for z80 Module Assembler
;
;   Module compile time: Thu Aug 20 00:54:38 2020


    C_LINE  0,"main.c"

    MODULE  main_c


    INCLUDE "z80_crt0.hdr"


    C_LINE  1,"main.c"
    SECTION code_compiler

; Function main flags 0x00000000 __stdc 
; int main()
    C_LINE  1,"main.c::main"
._main
    ld  hl,65535    ;const
    ret



; --- Start of Static Variables ---

    SECTION bss_compiler
    SECTION code_compiler


; --- Start of Scope Defns ---

    GLOBAL  _main


; --- End of Scope Defns ---


; --- End of Compilation ---

And the preprocessor output:

#line 1 "main.c"
int main() {
    return -1;
}

[Fortyseven]

I compiled the assembler output (z80asm main.c.asm), and that created a valid .o file.

Object  file main.c.o at $0000: Z80RMF14
  Name: main.c

Hex dump:

00000000  5a 38 30 52 4d 46 31 34  1c 00 00 00 ff ff ff ff  |Z80RMF14........|
00000010  ff ff ff ff ff ff ff ff  ff ff ff ff 06 6d 61 69  |.............mai|
00000020  6e 2e 63                                          |n.c|
00000023

Interesting that the 'bad' one has null bytes inserted every other byte...

[Fortyseven]

z80asm -b main.c.asm -> zero byte main.c.bin, fwiw. (That 'valid' object file has nothing in it, either, now that I look closer at it. :P)

[ped7g]

That hex-dump of invalid object file looks like some text editor did convert original file to UTF-16 and added BOM mark at beginning. (I'm not z88dk user to try out myself easily, just lurking around github following the project ... but I would be seriously shocked if this is the real output of zcc, that would be like doing utf16 text output for object file. I would first verify there's no external thing tampering with the file and it's really what goes out of the zcc.

(still no ld hl,** opcode in either of them, that should be 21 FF FF (ld hl,0xFFFF) - you are right about that part)

[Fortyseven]

Good eye. I just noticed the generated z80.c.asm also has a UTF-16 encoding. (main.c is just regular ASCII, however.)

[ped7g]

I would seriously suspect something on your local machine first (text editor/IDE?), converting it from ASCII to utf16 on your behalf...
(but somebody who actually knows z88dk will confirm it if can produce utf16 ... sounds ridiculous to me :D )

[suborb]

Correct. None of the tools should output utf16

That object file looks empty - as if there’s nothing to assemble.

Did the .c.i file have the same issue?

With a simple c file without any includes you should be able to run sccz80 file.c and generate a .asm file - does that have the markers.

The line that stands out to me is the type command to copy the generated assembly file around - maybe that is modifying the file format though that would be a strange thing for it to do.

Apologies for just asking questions - I’m away at the moment so working from a phone only!

[Fortyseven]

I had a whoooooooooole bunch of information here in this response, but I've just deleted it because I found out what it was.

Thanks! * *closes ticket **

(I'm kidding, I wouldn't leave you hanging like that. 😏)

The line that stands out to me is the type command to copy the generated assembly file around

Your strange suspicion was on target. I walked through each step of the zcc -a process:

PROCESSING main.c
z88dk-ucpp -iquote"." -D__Z88DK -D__SPECTRUM -DSPECTRUM -D__SPECTRUM__ -D__Z80 -DZ80  -DSCCZ80 -DSMALL_C -D__SCCZ80 -isystem"C:\z88dk\lib\config\..\..\/include"    "main.c" "D:\WinTemp\zcc000022E8B69B2.i2"
z88dk-zpragma -sccz80 -zcc-opt=D:\WinTemp\zcc000022E8B69B3/zcc_opt.def < "D:\WinTemp\zcc000022E8B69B2.i2" > "D:\WinTemp\zcc000022E8B69B2.i"
sccz80  -ext=opt -mz80 -zcc-opt=D:\WinTemp\zcc000022E8B69B3/zcc_opt.def -standard-escape-chars   "D:\WinTemp\zcc000022E8B69B2.i" -o "D:\WinTemp\zcc000022E8B69B2.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.9" < "D:\WinTemp\zcc000022E8B69B2.opt" > "D:\WinTemp\zcc000022E8B69B2.op1"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.2" < "D:\WinTemp\zcc000022E8B69B2.op1" > "D:\WinTemp\zcc000022E8B69B2.opt"
z88dk-copt  "C:\z88dk\lib\config\..\..\/lib/z80rules.1" < "D:\WinTemp\zcc000022E8B69B2.opt" > "D:\WinTemp\zcc000022E8B69B2.asm"

GENERATING OUTPUT
type "D:\WinTemp\zcc000022E8B69B2.asm" >> "main.c.asm"

And noted the file format of the intermediate files at each step:

d:\WinTemp\zcc000050E0B3C32.i2: C source, ASCII text, with CRLF line terminators
d:\WinTemp\zcc000050E0B3C32.i: C source, ASCII text, with CRLF line terminators
d:\WinTemp\zcc000050E0B3C33\zcc_opt.def: empty
d:\WinTemp\zcc000050E0B3C32.op1: C source, ASCII text, with CRLF line terminators
d:\WinTemp\zcc000050E0B3C32.asm: C source, ASCII text, with CRLF line terminators
main.c.asm: C source, Little-endian UTF-16 Unicode text, with CRLF, CR line terminators

No way. 😨

type main.c > main.utf.c:

main.c:     C source, ASCII text
main.utf.c: C source, Little-endian UTF-16 Unicode text

Holy crap, it WAS the type command doing the conversion.

So, turns out I've been using an alternate cmd shell under Windows for a LONG time now. Since XP at least. TCC/LE. It's been with me for so long that I never considered it might be the cause of a problem (though now I have to think back to a whole mini-lifetime of problems and wonder 😏).

To confirm, I loaded up regular ol' cmd and ran all the same tests -- sure enough: plain ASCII. No conversion going on. And all the example Spectrum programs compiled just fine.

I did have a stock cmd shell open during my initial exploration of z88dk. And then later in the evening moved over to my TCC-powered shell...

Soooo... mystery solved. :)

I'm not bitter, though. I learned about a terrible side effect of a tool I trusted, and I got to learn a whole lot more about z88dk than I would have normally at this point.

Very grateful for everyone's help! A strange, but nice introduction to the community here. Heheh. ;)

(By the way, I tried to create an account on the site forums but it never sent me an email back. Same name as on here: Fortyseven; who should I contact about that?)

[suborb]

Great investigation and thank you for not leaving me hanging! I’ll stick this one as a gotcha on the installation page when I get a chance.

Re the forum account - it looks like the mail is stuck in tls negotatiation limbo. I need to decide what I’m going to do with that server soon and this is another nail in it.