Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    emard
    @emard
    Now game speed advances and double-chars drawn for better view with 8x16 chars. CPU usage very small mostly around 1%
    emard
    @emard
    TETRIS now works in VT100 mode https://github.com/emard/tetris4terminals so saxonsoc framebuffer can be used like this: 
    ./tetris > /dev/tty1
    Lawrie Griffiths
    @lawrie
    Or even ./tetris >/dev/tty0 to get it on the HDMI monitor.
    I see, both of those go to the HDMI monitor.
    emard
    @emard
    I have added sound (beep ctrl-g :)
    tty0 is currently viewed, ttyN is specific one maybe
    Lawrie Griffiths
    @lawrie
    With vt100 control codes, you could probably make the blocks coloured.
    Not sure, it is ever going to be the world's best Tetris, though :)
    emard
    @emard
    Yes but there's no gamefield color support as they packed everyting to each bit to save memory (code for pic mcu). I think piece rotation is a bit wrong and rotation origin a bit excentric but ok for now :)
    It should be distribued along with "sl" command :).
    e2kgh
    @e2kgh
    @lawrie : edititng the DTS as you recommended, I got my green 85F up to 4 cores, and completely compiled & placed locally. THANKS!
    Lawrie Griffiths
    @lawrie
    @e2kgh Excellent news. Maybe I should add some instructions on editing the dts, but I think the long term aim is to get it generated from the scala source.
    Building the 4-core version takes a long time.
    e2kgh
    @e2kgh
    @lawrie : DTS: probably just some comments in the file what to edit for 1/2/4 cores, and what constants the Memory sizes need (32/64MByte)
    When I have time again in the next days, I will set up a new system, and check our documents again. I think, for new people coming to the ulx3s, there is documentation out there, but sometimes old and contradicting :(
    And gitter is cool, but very hard to find answers browsing, so people ask the same questions all over ...
    Lawrie Griffiths
    @lawrie
    A forum is better for finding answers, but gitter and similar chat servers are better for collaboration and general chat.
    e2kgh
    @e2kgh
    Yes, I agree, the speed here is impressive. I understand, that documentation can't keep up with that ;-)
    OPENOCD: I never followed up on this, but do we have to compile it specially for SaxonSoc & ULX3S, or is the " normal" Ubnuntu/Debian package sufficient? I tried i t once, and it didn't work to compile it on my Ubuntu20.04LTS ...
    emard
    @emard
    I know I can't write everything so I mostly stick to MANUAL.md when someone asks a question that relates to manual, I edit it and I noticed this question is not longer asked by those who got in touch with manual :)
    Lawrie Griffiths
    @lawrie
    @e2kgh You need the Spinal HDL version of openocd, which is compiled as part of the instructions for building SaxonSoc from source.
    Dolu1990
    @Dolu1990
    @e2kgh I recently merged openocd upstream into my fork, so now it might be fine on ubunuto 20.04
    emard
    @emard
    openocd community is very conservative in accepting patches. I have 6 months of messaging to get ft231x support accepted by their mainstream. And still I'm not sure that debian binary got compiled that in binary release
    Lawrie Griffiths
    @lawrie
    You then need a usb JTAG device, preferably an FT2232 one, and you connect the pins to gn0 - gn3. I have not used openocd with SaxonSoc for a while, but @Dolu1990 uses it all the time.
    Dolu1990
    @Dolu1990
    for what do you want to use openocd ?
    Lawrie Griffiths
    @lawrie
    @emard I don't think @Dolu1990 is implying that the upstream version has his changes, just that he has merged the latest upstream into his version, so that it builds on recent Linux systems, like Ubuntu 20.04.
    e2kgh
    @e2kgh
    @Dolu1990 : "opencod", on my boards, which I hope to try in the near future, I have an FT4232 to program the FPGA & SPI Flash ...
    Lawrie Griffiths
    @lawrie
    @emard Have you looked at driving the OLED/LCD displays from SaxonSoc yet? It needs an ST7789 driver.
    emard
    @emard
    @lawrie yes I know, he pulled the openocd and applied required changes for softcore CPU. I currently have ST7789 plugged, are examples for this also besides ssd1331 (I haved it too but boxed around)
    How about some challinging stuff like getting USB linux host to accept a small USB1.1 hub at US2 port so kbd, mouse and something else to be plugged :)?
    Lawrie Griffiths
    @lawrie
    I think you might find that @Dolu1990 is working on that :)
    I did not attempt ST7789. I just wanted to show that the /dev/spidev stuff worked and the ssd1331 display seemed a simpler one to start with.
    emard
    @emard
    ahaaaaaa great! I have simple and reliable US2 PHY clock recovery core that runs well at 48MHz for USB1.1, its stuff for usbmouse and usbkbd in ulx3s-misc. OK I should unpack some SSD1331 and try this
    Dolu1990
    @Dolu1990
    So basicaly, i'm working on implement an USB OHCI controller, but that's quite some work
    Lawrie Griffiths
    @lawrie
    I am not sure what the best way to distribute optional software for SaxonSoc Linux is. We probably don't want to add it to the buildroot stuff as it isn't in buildroot packages.
    Dolu1990
    @Dolu1990
    i don't realy know, maybe some kind of out of tree packages ?
    emard
    @emard
    Yes something like risc32 tar extraction :)
    Lawrie Griffiths
    @lawrie
    The current software that we have is the riscv32_lcc compiler and library, @emard's mcpclock utility, @emard's tetris and my saxonsoc-lib, which currently has libraries for gpio, spidev and ssd1331. There was also some stuff that @kost built for the previous version.
    Lawrie Griffiths
    @lawrie
    We don't have a script for building the sd card image for this (Smp) version The one for the previous version used /dev/loop devices and I am bit dubious about that as which such devices are currently in use is system-dependent. That script added /etc/network/interfaces, create_keys.sh etc., as well.
    Dolu1990
    @Dolu1990
    right that's missing
    emard
    @emard
    @lawrie tetris early color support :) gamefield is bitarray so its scroll will currently reset colors
    Lawrie Griffiths
    @lawrie
    Looks much more like the real thing, in colour :)
    emard
    @emard
    :))) seems better, still I'm trying to use only basic vt100 sequences that most should support
    Paul Ruiz
    @pnru_gitlab

    There are now lots of system calls implemented, but they don't currently all have the wrappers that they need. For example, there is pselect6 and ppoll, but not select and poll wrappers.

    @lawrie the wrapper for select() seems to be fairly straightforward:
    https://github.com/brgl/uclibc-ng/blob/master/libc/sysdeps/linux/common/select.c
    It is a matter of normalising the timeout & adding a zero at the end of the parameter list.

    emard
    @emard
    TETRIS full color support (with vt100 scroll contols)... I hope it doesn't have bugs
    Lawrie Griffiths
    @lawrie
    A platform isn't complete until Tetris is running on it.
    emard
    @emard
    To support full color it's scrolling at the screen and bitmap is only internall kept for game logic.It had bugs at scrolling (looks like empty line where blocks should "fall" from above when lines are complete). I fixed and played 1 game and see no bugs, but more testing is needed :)
    I tried, bug is still there :(
    Screen first scrolls content down when lines fall, but accidentaly scrolls up and spoils the content... I don't know why. It's the same on PC linux, not just saxonsoc related