Emulation setup

[veremenko-y]

I have compiler kit and emulation kit building and running locally. Would you be able to point me up at some documentation/code for some emulator to run for testing you would recommend?

The only hardware I have is pico, and it's not really representative to general user of FUZIX.

[EtchedPixels]

A lot of the ports actually give you the emulatorkit commands to run them (because I otherwise keep forgetting).
In general though

• rcbus-z180 is a good generic 'Z80' style system with lots of RAM and fairly fast
• searle is as good as anything for a simple one process at a time system (make diskimage, searle -r scm.rom -i fuzix.ide -b -t)
• rcbus-6502 is often useful as the 6502 compiler and code sizes are usually the worst case scenario

For the bigger systems (where stuff like select might be useful) rcbus-68008 is a fairly typical 68K setup.

[veremenko-y]

Huh, did I do anything wrong?

make TARGET=rcbus-z180 diskimage
/opt/fcc//lib/z80/libz80.a: Unknown symbol '__mulde'.

[EtchedPixels]

__mulde should definitely be in libz80 from the compiler so that is a bit weird.

ar t /opt/fcc/lib/z80/libz80.a|grep mulde

shows what ?

[veremenko-y]

Something is funky with the Compiler Kit in general for me.

On clean repository compiler kit first fails on 6502

make[1]: *** No rule to make target '__divu.o', needed by 'lib6502.a'.  Stop.
make[1]: Leaving directory '/home/yaroslav/my-aur/tmp/Fuzix-Compiler-Kit/support6502'
make: *** [Makefile:206: support6502] Error 2

If I comment out support6502 out of Makefile it builds. Both functions report existing. Depending on makefile ordering it complains about divdeu or mulde.

$ ar t /opt/fcc/lib/z80/libz80.a | grep divdeu
__divdeu.o
$ ar t /opt/fcc/lib/z80/libz80.a | grep mulde 
__mulde.o
__muldec.o

[veremenko-y]

To make sure it's not my environment or distro, I created an empty Debian 12 docker and tried building there. I went further but still failed. I put all code here: https://github.com/veremenko-y/fuzix-docker

• installed libbsd-dev (-lbsd in CPP/makefile)
• byacc (updated alternatives).
• Custom sdcc280 cloned built and installed
• Bintools successfully built and installed
• /opt/fcc/bin added to path
• Compiler kit still fails onsupport6502 and mtms7000 (see patch)

fcc -mtms7000 -c __mul.s
__mul.s: 13: A: phase error.

Eventually fails here:

/build/FUZIX/Kernel/tools/bankld/sdldz80 -n -k /usr/share/sdcc/lib/z180 -f platform/platform-rcbus-z180/fuzix.lnk
?ASlink-Warning-Undefined Global '_ch375_probe' referenced by module 'discard''

[EtchedPixels]

6502 was me forgetting to commit some changes

For the divdeu/mulde stuff does it linkc orrectly if you link libz80 twice ? If so then something is messed up with the lorder/tsort bits putting the library in correct order

[veremenko-y]

Compiler kit still fails on.

fcc -mtms7000 -c __mul.s
__mul.s: 13: A: phase error.
make[1]: *** [Makefile:26: __mul.o] Error 1
make[1]: Leaving directory /src/fuzix-compiler-kit/supporttms7000'

But whatever you did in FUZIX repo made it build now.

[EtchedPixels]

I can't duplicate this __mul.s failure unfortunately.

[veremenko-y]

Would setting up docker file for you that runs debian be useful?

[EtchedPixels]

What is line 13 of that __mul.s on your system ?

I can if need be put a debian setup together, I need to at some point as the lorder/tsort problem appears to be a Debianism and the code in question is based on V7 and afaik has worked since V7 unix came out 8)

[veremenko-y]

What are you building on usually? Here's my mul.s

$ nl -b a supporttms7000/__mul.s 
    10	__mul:
    11		call @__pop10
    12		mpy r5,r11
    13		movd b,r3		; Save low result
    14	
    15		mpy r5,r10
    16		add b,r2

[EtchedPixels]

I build on Fedora but there's nothing that ought to matter between them and other folks build it on Mac etc - although you do need a` case dependent file system.

Ok the mul.s matches what it should be and there's functionally no way line 13 can generate a phase error as it has no symbol definitions. Very weird

[EtchedPixels]

__mul.s bug fixed. I built a Debian 12 to take a look and there's an uninitialized field that just happens to be zero with a later gcc. Will push the fix when I have better internet