Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    For the 12F version you need to rename dtb.12f to dtb in the (root of the) fat32 partition.
    Only uart works. @Dolu1990 is currently getting a proper Linux VGA console working, so my hdmi text console which was driven from the bios is not supported. When the VGA console works, we should be able to add an VGA to HDMI verilog module as a SpinalHDL BlackBox.
    My PS/2 and USB consoles or also not supported. The best solution there would be full USB support.
    Lawrie Griffiths
    @lawrie
    The 85F version assumes 64MB of memory and the 12F version, 32MB.
    Paul Ruiz
    @pnru_gitlab

    @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.

    Lawrie Griffiths
    @lawrie
    I suspect that I will need help with that from you and @emard.
    Paul Ruiz
    @pnru_gitlab

    @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.

    Dolu1990
    @Dolu1990
    So basicaly, got X11 running, but no proper inputs to play with it XD
    directFB work too
    emard
    @emard
    For writing microdrive I'm always to help. ESP32 side is easy, cortex is already example which has it working. Only some part at QL side and sync to the tape could be challenging to reversengineer
    @Dolu1990 WOW X11 running!!!! xeyes/xclock I think can work without input :)
    Dolu1990
    @Dolu1990
    so, xeyes and xcalc are ok
    also, ussing ssh -X from my x86 computer, i can interract with them properly
    xclock currently open nothing XD
    don't know why
    emard
    @emard
    If this linux can compile uinput stuff, some user-space workaround over SPI can be done to interface with our usb-core mouse or PS/2 core mouse
    Lawrie Griffiths
    @lawrie
    @emard One issue with the QL microdrives is that you probably need to support two of them. One (say) to run Quill from and one to save your documents to.
    emard
    @emard
    I have some gui ideas how to make it. For example 2 files can be selected with different char marks indicating 1st and 2nd drive. We have F1 and F2 BTN to help selecting 1st or 2nd drive. That should be easy.
    I think micropython can have several files open simultaneously I haven't tried but expect this to work
    I also expect QL driver chip can't simultaneously access both drives but either services 1st or 2nd.
    Paul Ruiz
    @pnru_gitlab

    @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 Yes, you are correct. The QL micro drives are on a shared bus and only one can be active at a time.
    Lawrie Griffiths
    @lawrie
    Yes, it built out of the box for me with native Linux gcc, and enough of it it built with the gcc risc-v cross-compiler to get something running on SaxonSoc Linux. I will spend some more time looking at it and might contact the author as you suggest.
    I understand the relationship between lcc and rcc better now. rcc is the raw compiler and lcc is a front-end that builds an rcc command line and executes it.
    emard
    @emard
    small C saxonsoc compiler would be great! QL then at least from ESP32 side should be easy, both images will be open and there won't be timing issues as both 1st and 2nd drive will never be transferring data at the same time this will not add more latency when SD must stream 2 files simultaneously.
    Paul Ruiz
    @pnru_gitlab

    @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.

    emard
    @emard
    @pnru_gitlab 0.3-1MB is small for 30MB RAM free. I also agree the best option is to ask original author for help about lcc on saxonsoc
    Lawrie Griffiths
    @lawrie
    I made a bit of progress on lcc. I can now run this on SaxonSoc Linux: lcc -Wo-lccdir=/lccbin -S -target=riscv32 hello.c -o hello.s and it produces the risc-v assembly file.
    The buildroot cross-compiler used to build Linux worked better than the others I tried. I can now build lcc by make lburg then make CC=cross-compiler all.
    Paul Ruiz
    @pnru_gitlab
    Great. Assembling that file to a .o object file should work as well.
    Lawrie Griffiths
    @lawrie
    If you do -o hello.o, you just get the sasembler in hello.o.
    I don't think lcc produces anything other than assembler output.
    I thought the assembler and loader from binutils was needed for that.
    Paul Ruiz
    @pnru_gitlab
    Yes, correct. Use -c instead of -s to get an object file. That will try to inboke the assembler at location ../../binutils/bin/as telative to the location of lcc itself.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/lccbin -target=riscv32 hello.c -o hello.o
    lcc: /lccbin/../../binutils/bin/as: No such file or directory
    Paul Ruiz
    @pnru_gitlab
    That binary can be compiled from the binutils/as dir in the repo
    Paul Ruiz
    @pnru_gitlab
    You may want to edit https://github.com/michg/riscv32_lcc/blob/master/lcc/etc/linux.c when building lcc to get a bit more sanity in the paths.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 hello.c -o
     hello.o
    Assembling module '/tmp/lcc1711.s'...
    lcc: /riscv32_lcc/lcc/bin/../../binutils/bin/ld: No such file or directory
    Paul Ruiz
    @pnru_gitlab
    Great! Add -c to your lcc command line and you will end up with a hello.o object file.
    No need for the -o option, that is automatic.
    Lawrie Griffiths
    @lawrie
    root@buildroot:~# lcc -Wo-lccdir=/riscv32_lcc/lcc/bin -target=riscv32 -c hello.c
    Assembling module '/tmp/lcc1121.s'...
    root@buildroot:~# cat hello.o
    2��000#&�#,�� �$�g�Hello world!
    Paul Ruiz
    @pnru_gitlab
    That looks correct: an object file with the string constants at the end. If you also add the bof utility from binutils you can get a pretty print of the obj file contents.
    Lawrie Griffiths
    @lawrie
    I have built ld now. If I omit the -c, I get@
    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
    Paul Ruiz
    @pnru_gitlab
    Yes, I can help with that. Need to step away for 10 mins. If you compile ar and ranlib as well in the meantime I'll post my ld notres next.
    Lawrie Griffiths
    @lawrie
    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
    Paul Ruiz
    @pnru_gitlab
    That is what I get. There seems to be a bug for printing the relocation table(s). Use option -s to at least get an overview of the symbols that are defined/referenced by the object file.
    Lawrie Griffiths
    @lawrie
    If I compile a program (life.c) that just returns 42, I can link it with ld life.o, but the a.out is not executable.
    Paul Ruiz
    @pnru_gitlab

    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

    The c.lib file (the combination of all the separate libs in the default build) is here:
    https://gitlab.com/pnru/ulx3s-misc/-/blob/master/tmp/c.lib