Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Kid CUDA
    @KidCUDA_gitlab
    from the schematic it doesn't look 5V tolerant but I'm not sure how else it would work with just a pure PS2 adapter as suggested in the docs
    emard
    @emard
    @KidCUDA_gitlab US2 pins are 5V tolerant, limited by R and Zener diodes. Still some PS/2 keyboards don't accept 3.3V levels. Best is to obtain combo PS/2+USB they usually work in both modes for ULX3S
    PS/2 is normally used over OTG connector for most of our retro-computing cores, apple1-2, ti99, zx, vic20, QL just to name a few
    Lawrie Griffiths
    @lawrie
    SaxonSoc 2-CPU version on Ulx3s 85F:
    root@buildroot:~# cat /proc/cpuinfo
    processor       : 0
    hart            : 1
    isa             : rv32im
    mmu             : sv32
    
    processor       : 1
    hart            : 0
    isa             : rv32im
    mmu             : sv32
    Lawrie Griffiths
    @lawrie
    A 3-CPU version also runs, but a 4-CPU version did not, probably due to failing the timing by too much.
    e2kgh
    @e2kgh
    @lawrie " how much of the 85F does the 2-Core version use?
    Lawrie Griffiths
    @lawrie
    From memory it was 36%
    But apparently it takes a lot less if built with Lattice Diamond rather than the open source tools.
    Lawrie Griffiths
    @lawrie
    Info: Device utilisation:
    Info:            TRELLIS_SLICE: 15356/41820    36%
    Info:               TRELLIS_IO:    83/  365    22%
    Info:                     DCCA:     3/   56     5%
    Info:                   DP16KD:    48/  208    23%
    Info:               MULT18X18D:     8/  156     5%
    Info:                   ALU54B:     0/   78     0%
    Info:                  EHXPLLL:     1/    4    25%
    Info:                  EXTREFB:     0/    2     0%
    Info:                     DCUA:     0/    2     0%
    Info:                PCSCLKDIV:     0/    2     0%
    Info:                  IOLOGIC:    39/  224    17%
    Info:                 SIOLOGIC:     0/  141     0%
    Info:                      GSR:     0/    1     0%
    Info:                    JTAGG:     0/    1     0%
    Info:                     OSCG:     0/    1     0%
    Info:                    SEDGA:     0/    1     0%
    Info:                      DTR:     0/    1     0%
    Info:                  USRMCLK:     1/    1   100%
    Info:                  CLKDIVF:     0/    4     0%
    Info:                ECLKSYNCB:     0/   10     0%
    Info:                  DLLDELD:     0/    8     0%
    Info:                   DDRDLL:     0/    4     0%
    Info:                  DQSBUFM:     0/   14     0%
    Info:          TRELLIS_ECLKBUF:     0/    8     0%
    Info:             ECLKBRIDGECS:     0/    2     0%
    e2kgh
    @e2kgh
    Does the 4-Core fail on Diamond too?
    Lawrie Griffiths
    @lawrie
    I don't have Diamond installed to test it at the moment.
    Lawrie Griffiths
    @lawrie
    @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 compile-time utilities so need to be natively compiled. Then I had some problems with the run time library. There were problems with getcwd not being found. I commented out the code that used that, as it did not look critical, Then there was a problem with getopt being duplicated, so I omitted the getopt.c source. I could then compile some of the directories.
    The way the build happens seems to be that a binary called rcc is compiled using gcc, and then that is used to recompile the source, producing the lcc binary. I could compile rcc, but not lcc as the latter had some missing library routines, such as access.
    emard
    @emard
    Hmmmmm but very interesting, good part can be compiled
    I will download current multicore binaries, it would be my first multi-core linux booting at ulx3s board :)).
    Lawrie Griffiths
    @lawrie
    When I first built rcc and ran it on SaxonSoc Linux, it produced a lot of garbage files and corrupted the SD card. When I used the correct architecure and abi options, it worked better. However, it does not seem to be able to read or write named files (cannot read hello.c), but it worked with stdin and stdout. So all I can currently do is compile a single C file to an assembler output file.
    I haven't tried to build the binutils yet, and I haven't looked into the a.out issue next. So I cannot convert the assember output to an executable file yet.
    So I have made some progress, but a long way to go.
    emard
    @emard
    I remember on big datacenters there are administrators doing crazy jobs of compiling gnu stuff for aix vms vm/esa and of course errors occured. They told me they are just block-deleting with editor big parts of code they don't understand until compile succeeded :). Often such software was still useable, most of the code almost never gets executed
    Lawrie Griffiths
    @lawrie
    @emard I currently only have the 12F 1-CPU version in saxonsoc-ulx3s-bin. I will put the 3-CPU 85F version in that repository tomorrow.
    Lawrie Griffiths
    @lawrie
    I have updated this with the 85F 3-CPU version now - https://github.com/lawrie/saxonsoc-ulx3s-bin/tree/master/Smp
    There is currently no SD card image. You need a sdcard with partition 1 fat32 and partition 2 ext2.
    You need dts, uImage and rootfs.cpio.uboot in the fat32 partition and you need to extract rootfs.tar to the ext partition.
    Lawrie Griffiths
    @lawrie
    There are two images that need to be written to flash. I have updated the u-boot one to include 3 CPUs. That works for both the 12F and the 85F version.
    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.
    Lawrie Griffiths
    @lawrie
    My PS/2 and USB consoles or also not supported. The best solution there would be full USB support.
    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.