User space does not build (nc100 port)

rhaberkorn commented 9 years ago

First of all, thanks for all your efforts! I'm trying to prepare a nc100 card image for playing around with it in nc100em. I will also try it on my real NC100 once I get my hands on one of these expensive PCMCIA memory cards. I'm relatively new to z80 programming and the FUZIX build process is very poorly documented, so please excuse any stupid mistakes on my side.

I am running Ubuntu 10.04 with a hand-built SDCC:

SDCC : z80/z180/gbz80 3.4.3 #9201 (Mar 29 2015) (Linux)

So far I think I've managed to build the kernel "image" (fuzix.bin). First a few remarks on the nc100 kernel build process:

nc100.def is missing. Given the commit log, I assume it must contain something like VIDEO_BASE .equ 0x7000, VIDEO_BASEH .equ 0x7000 (what's that for, anyway?) and VIDEO_SIZE .equ 0x1000. You should also add the corresponding nc200.def.
the Kernel/platform-nc100/Makefile image-target refers to bootblock.cim. This looks like it must be generated from bootblock.s with zmac. Any reason for not adding this step as a Makefile rule?
Also I think that the image rule should be modified/fixed and read dd if=bootblock.cim of=../fuzix.bin bs=1 seek=256 conv=notrunc

If I understand correctly, the fuzix.bin is already a PCMCIA card image, albeit incomplete. Something like a rootfs should be added. I see that this can be done with the mkfs and ucp tools from the Standalone subdirectory. But in reality I assume that the Standalone/filesystem-src/build-filesystem script should be used instead of doing it manually. This needs all of the user space tools of course. Unfortunately, the Applications/util/Makefile won't just work. Right, we need a toolchain first! It appears to be hidden in Library/. Just making it however does not appease the Applications/util build proces as it's referring to files in /opt/fcc/. So I followed the not-so-outdated instructions from the wiki. I think it should be renamed to "Building the toolchain". But now I get the following build errors from Applications/util/Makefile:

$ make 
../../Library/tools/fcc -O2  -c banner.c
../../Library/tools/fcc -O2  banner.rel -o banner

?ASlink-Warning-Undefined Global '_strcpy' referenced by module 'vfprintf'

?ASlink-Warning-Undefined Global '_strcpy' referenced by module 'ltostr'

?ASlink-Warning-Undefined Global '__modulong' referenced by module 'ltostr'

?ASlink-Warning-Undefined Global '__divulong' referenced by module 'ltostr'

?ASlink-Warning-Undefined Global '___sdcc_call_hl' referenced by module 'atexit'

?ASlink-Warning-Undefined Global '_strcat' referenced by module 'vfprintf'

?ASlink-Warning-Undefined Global '_strlen' referenced by module 'banner'

?ASlink-Warning-Undefined Global '_strlen' referenced by module 'vfprintf'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'banner'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'printf'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'stat'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'atexit'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'vfprintf'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'fflush'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'lseek'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'ltostr'

?ASlink-Warning-Undefined Global '___sdcc_enter_ix' referenced by module 'fputc'

?ASlink-Warning-Undefined Global '__modsint' referenced by module 'banner'
make: *** [banner] Error 1

Seems like it doesn't properly link against FUZIX' libc. Any idea why?

Once I get the user space utilities to build and assembled them with build-filesystem, I guess I will have to write it into the fuzix.bin as explained by the nc100 README:

dd if=myfs of=mycard.img bs=16384 seek=20 conv=notrunc

The resulting image should be suitable as a nc100.card image for nc100em, right? The nc100emu.s can then be assembled and used a "boot script" as in

xnc100em nc100emu.cim

Btw. nc100emu.s cannot be assembled with zmac as claimed in the README. But I got it to compile with SDCC's assembler (see bcec50fc1d2663c0323b5b72b8349f3ce4043497), linked with sdcc and converted the intel hex file:

sdasz80 nc100emu.s
sdcc --no-std-crt0 -mz80 nc100emu.rel
objcopy -Iihex -Obinary nc100emu.ihx nc100emu.cim

In case that's right, there should be a Makefile rule for it. A few questions remain:

Do I need the original NC100 ROM image or does FUZIX work with nc100em's default ROM image (written for ZCN)?
If I do need the original ROM image, how do I boot into FUZIX from the Amstrad ROM?

Once I get this sorted out I can also fork and send you a pull-request with the changes discussed above.

erkinalp commented 9 years ago

Alan, I have the same problem.

EtchedPixels commented 9 years ago

nc100.def - fixed missing from git
nc100emu - updated README - it did indeed get converted to sdas but the README was missed. Will look at Makefile bits when I get time
No you don't need the original NC100 ROM, the ZCN image will do plus the nc100emu.cim
If you are using a Amstrad ROM then you do the same as to boot any other PCMCIA app
It has linked with the libc ok, but your libc hasn't included the required bits from the sdcc library. Was SDCC_LIB set correctly when you built the library. The tools/libclean is supposed to generate a base library from the sdcc runtime library that has the clashing stuff removed and this is then incorporated into the userspace library/
bootblock.s -> bootblock.cim ought to be a Makefile rule but it needs zmac and not everyone has zmac around
fork/pull -> definitely!

Have to admit I've been concentrating on some the other bits so nc100 may have bitrotted slightly too. Need to get my NC100 out and test it all again soon.

rhaberkorn commented 9 years ago

Thanks! SDCC_LIB was not set correctly in libclean as I installed my sdcc into /usr/local - I did not know it has to be set up multiple times or exported. I could now build the user space and assembled a rootfs using build-filesystem. I copied it into fuzix.bin with the aforementioned dd command to produce a nc100.card image. Unfortunately, now when I try to boot it with xnc100em nc100emu.cim, I get a white screen (xnc100em display) and nothing else. After all, it should execute /init which should give me something like a login prompt.

Any pointers on how to debug this further?

Regarding zmac: I don't think it would worsen things to require zmac, as currently it is required anyway if you want to produce a working image. Alternatively, if it is not easy to port to sdas, you could add the binary to the repository. I doubt it will change often.

Btw. I tried to cross-compile a program for FUZIX and it did not like C declarations like void foo(); which it appeared to interpret as declarations with an empty-parameter list (as in C++), instead of a declaration with undefined parameters. Is this a known limitation of SDCC?

rhaberkorn commented 9 years ago

Update:

$ xnc100em -s nc100emu.cim 
xnc100em: no ROM found, using builtin PD `ROM'.
UZI[trap_illegal]

This does not look healthy :(

EtchedPixels commented 9 years ago

SDCC is religiously ANSI, it doesn't speak K&R C - which is annoying but rather a big job to fix.

I'll try and give the nc100 codebase a test and see what is up.

EtchedPixels commented 9 years ago

For debug on the NC100 I normally just add more writes to the serial port. The emulator conveniently just outputs bytes even if the port isn't set up properly so it can be used for early debug. I would venture a guess that it hits crt0, and isn't getting something copied or cleared right if it blows up that early. That's an area that has changed a fair bit. Might also do that if you have it built for NC200 and run on NC100.

EtchedPixels commented 9 years ago

Oh a PS: memory cards - Best Electronics still I believe have them. CB103058 = $15 US a card. Thats where I got my supply of them from.

EtchedPixels commented 9 years ago

Fixes pushed

hadn't been updated for a segment/binman change
fixed the bootblock not being dd'd to the right file
made it put kprintf to both serial and vt for easier use with the standard emulator

rhaberkorn commented 9 years ago

Ah I completely overlooked that config.h file that defined NC200 support. It now boots and asks for the boot device, which I figured out should be 256 for the PCMCIA card. This should be the only allowed value on NC100 so I think it could be put in CMDLINE. The root filesystem is now mounted and it attempts to start /init which unfortunately either hangs or the process gets killed.

$ xnc100em -s nc100emu.cim 
xnc100em: no ROM found, using builtin PD `ROM'.
UZIFUZIX version 0.1
Copyright (c) 1988-2002 by H.F.Bower, D.Braun, S.Nitschke, H.Peraza
Copyright (c) 1997-2001 by Arcady Schekochikhin, Adriano C. R. da Cunha
Copyright (c) 2013-2015 Will Sowerbutts <will@sowerbutts.com>
Copyright (c) 2014-2015 Alan Cox <alan@etchedpixels.co.uk>
Devboot
256kB total RAM, 192kB available to processes (15 processes max)
Enabling interrupts ... ok.
bootdev: Mounting root fs (root_dev=256): OK
Starting /init

panic: killed init

I need to debug this further. I don't have to rebuild the library or user space after the latest changes? This takes ages on my aged machine. Did you also test with a clean filesystem as produced by the build-filesystem script?

EtchedPixels commented 9 years ago

No it was midnight so I didn't test beyond mounting root fs working again

EtchedPixels commented 9 years ago

All now working.

EtchedPixels / FUZIX

User space does not build (nc100 port) #158