@pnru_gitlab @emard I finished the QL sound with an attempt at everything (increments, wrap, random, fuzz), but I don't know how close to the original it is.
@lawrie That is cool! I think @Speccery has a working QL, maybe he can tell if the sound is anything like that of the original hardware. If we add write capability to the microdrive emulation it will be the best QL implementation on FPGA that I know of. Later in October I will have time to help with that.
@pnru_gitlab @emard I have started looking at riscv_lcc. It is not straightforward to cross-compile. Some parts (such as lburg) seem to be ...
@lawrie Here, too, I hope to have time in October to help on getting a tool chain in place that works for Risc-V systems. I would find it cool to see an ancient Unix running on a Risc-V CPU/system.
I can see that you would first build a cross-compiler with gcc and then a native one using the cross-compiler. The native build requires a matching C library. This may require some hand work to get right. I would expect that this C library does not need to be very big. If you get stuck with this, let me know and I'll see if I can figure it out.
@lawrie Had a quick try with lcc-riscv. It compiled for me on OSX, almost out of the box. The source has its own implementation of 'memmove' and this is a macro on today's OSX. So I needed to undef the macro just before the redefinition. Then it builds the cross compiler & tools.
Using the cross compiler is another matter. The core compiler and the assembler seem fine, but the linker/loader is troublesome - I think it is a work in progress. There are source files for the C library, but these build as a set of smaller libraries ("stdio.lib", "stdlib.lib", etc.) and are not combined into one big "libc.lib").
From the test code it seems that the work routine is to custom link files into a bare binary image and to put this binary image into the memory of a small nano-riscv system (verilog included in the test cases).
Probably the quickest way to proceed is to reach out to the author of that Git repo and see if he is interested in getting this stuff to work on SaxonSoc. In the alternative, rounding out the linker/loader does seem a doable amount of work.
@emard 'small' is relative. The cross compiler has >0.5MB of executable; that includes 4 backends (spare, mips, x86 and riscv32) but it will be >0.3MB for sure. Runtime memory use may be double that.
@lawrie @emard I did look a bit more at the toolchain. Compiler, assembler, archiver all appear to work fine. The utils appear to have roots in the ECO32 project: https://github.com/hgeisse/eco32
The riscv32 linker/loader seems to be a custom job. I managed to build a full libc.lib and could link a "hello world" program to an a.out file. That file is ~30KB, as it drags in much of stdio and of the floating point library routines.
As there is no OS, the C library just has stubs for some of the sys calls (https://github.com/michg/riscv32_lcc/blob/master/lcc/bin/libs/stdlib/syscall.c), with I/O hardcoded to a UART.
All in all, the compiler seems fine, but getting it to run on SaxonSoc is not a slam dunk.
make CC=cross-compiler all.
root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 hello.c Assembling module '/tmp/lcc1441.s'... Reading module '/tmp/lcc1442.o'... Usage: /riscv32_lcc/lcc/bin/../../binutils/bin/ld [-h] do not write object header [-o objfile] set output file name [-m mapfile] produce map file [-rc addr] relocate code segment [-rd addr] relocate data segment [-rb addr] relocate bss segment file object file name [files...] additional object files
root@buildroot:~# dof -a hello.o Header size of code : 48 bytes size of data : 16 bytes size of bss : 0 bytes size of code relocs : 48 bytes size of data relocs : 0 bytes size of symbol table : 48 bytes size of string space : 12 bytes Code Segment 00000000: 13 01 01 FD 23 26 81 02 13 04 01 02 23 2C 11 00 ....#&......#,.. 00000010: 17 06 00 00 13 06 06 00 EF 00 00 00 13 05 00 00 ................ 00000020: 83 20 81 01 03 24 C1 02 13 01 01 03 67 80 00 00 . ...$......g... Data Segment 00000000: 48 65 6C 6C 6F 20 77 6F 72 6C 64 21 0A 00 00 00 Hello world!.... Code Relocation Records 0: offset = 0x00000018 Error: illegal relocation method
Ok. The linker/loader was not integrated with the lcc front end. I've posted a revised unix.c file here: https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/linux.c
This has the default path set to /riscv32_lcc/lcc/bin and adds some forgotten / separators.
It also adapts the options given to ld to something it actually understands. It now tells the linker to look for the library c.lib in the directory "/riscv32_lcc/lcc/bin/../../lib". I.e. that lib needs to be here: /riscv32_lcc/lib/c.lib