Linux build process

[snhirsch]

Unless I'm missing the obvious, this is going to be very invasive. For whatever reason, zasm on Linux requires #included ASM source files to be in the same directory as the source that requires them. So, after cd'ing to the System subdirectory, this fails immediately:

zasm config/config_fdc.asm -u -w -b cpm22.bin

If I symlink CPM22.asm into the config subdirectory it finds the included file. I don't have the energy to dig through the zasm sources, but I'm guessing there's an implicit chdir() to config that does not happen on Windows. None of this would be a problem if zasm respected -I <dir>, but it does not seem to.

[snhirsch]

Looks like we'll either have to fix zasm or hack up all the source files. This is the only way I can get files in subdirectories to build correctly from their parent:

; Include CP/M and BIOS
#include "../CPM22.asm"
#include "../bios.asm"
...
;
;**************************************************************
;*
;*        D E V I C E   D R I V E R   I N C L U D E S
;*
;**************************************************************
;

#include "../dev/nabu_fdc.asm"
#include "../dev/nabu_vdp.asm"
#include "../dev/nabu_prt.asm"
#include "../dev/nabu_sio.asm"

I filed a bug report on zasm a moment ago. If I have time over the weekend I'll try digging into zasm sources and see why it goes off the rails in this situation.

[snhirsch]

I felt motivated and made a quick hack to zasm. If you can explain what this is trying to do I think I can get the Linux build 100% operational (I'm Windows challenged and the ~nf ~xf stuff has me stymied).

REM This loop is needed because winblows sucks
for %%f in (..\..\Directory\*) do (
        copy %%f %%~nf%%~xf >NUL
        echo Writing %%~nf%%~xf to image
        cpmcp -f osborne1 ..\..\Output\Nabu_FDC\ishkur_fdc_ssdd.img %%~nf%%~xf 0:
        cpmcp -f nshd8 ..\..\Output\Nabu_NDSK\NDSK_DEFAULT.IMG %%~nf%%~xf 0:
        del %%~nf%%~xf
)

Update: Nevermind. figured it out. I'm able to build under Linux now. Need to clean things up a bit and maybe revisit the code in zasm that determines location of the listing file. It now places .lst files in the current directory rather than the relative directory where the source is. I'm guessing the zasm folks never did a lot of interplatform testing.

[tergav17]

Seems like you have figured it out. Using cpmcp was a little bit of a headscratcher on Windows because it does not truncate the file path when adding a file to a disk image. For example, I I try to add the file ../Directory/XDIR.COM to an image, it will fail due to it trying to name the destination file as the entire file path.

Good to see that you got building under Linux working. I spent the better part of the morning writing a Makefile to make building on Linux easier. Not quite done yet, but I am getting close. I also refactored all of the config files so they can be built be zasm under Linux.

[snhirsch]

Without major tearup, it's hard to see how the build can work without a zasm that behaves like the Windows code. Here's the mod to make it use the current working directory as base for finding includes:

diff --git a/Source/Z80Assembler.cpp b/Source/Z80Assembler.cpp
index 165017a..410f22b 100644
--- a/Source/Z80Assembler.cpp
+++ b/Source/Z80Assembler.cpp
@@ -202,8 +202,12 @@ cstr Z80Assembler::get_filename(SourceLine& q, bool dir)
                        throw FatalError("Escape from Darthmoore Castle");
        }

-       if (fqn[0] != '/') fqn = catstr(directory_from_path(q.sourcefile), fqn);
-       return fqn;
+       if (fqn[0] != '/')
+        {
+          cstr cwd = cstr(get_current_dir_name());
+          fqn = catstr(cwd, "/", fqn);
+        }
+        return fqn;
 }

 void Z80Assembler::init_c_flags()

[snhirsch]

At some point I'd love to see this project enhanced to build with a more fully-featured Z80 assembler and relocating linker. Among other advantages it would make integration of different BDOS and CCP implementations far simple and enable re-org of the system with minimum hassles. As someone who's coded for CP/M since about 1983, I find most of the currently available cross-assemblers a huge step backwards from the ecosystem available as native tools. If you get a chance, take a look at zmac and ld80: http://www.48k.ca/zmac.html

[snhirsch]

Interestingly, it turns out that the original Windows build process relied on a longstanding bug in zasm. See: https://github.com/Megatokio/zasm/issues/31#issuecomment-1587712502

[tergav17]

Ha! The correct implementation of the search path seems to work best for Makefiles anyways. I tried to make the Windows build script as easy to use as possible, but at this point it is getting slow and cumbersome to maintain. I think I may just fully migrate over to using the Makefile, and build under Windows using cygwin or WSL.