Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    kost
    @kost
    pnrhub
    @pnrhub
    Maybe I should get working on building Micropython 1.12 with IP forwarding enabled. It seems that 1.12 has support for bluetooth (1.11 does not). Maybe it offers a simple way to add a wireless keyboard and mouse.
    emard
    @emard
    https://www.youtube.com/watch?v=aK93u340A9I this should be possible but I haven't tried
    Ups this is wireless USB, must search better example
    emard
    @emard
    Yes, these bluetooth keyboard/mouse projects look promising! In meantime I was playing with e-ink displays and RTC from micropython. Also made i2c bidirectional bridge in FPGA (not trivial to make)
    Ghost
    @ghost~5dc3e397d73408ce4fd042cd
    Hello, I wanted to have a 90 degree shifted clock. I was trying out the ecp5pll from @emard. I get it running and the clock adjustment seems to work, but somehow it does not get shifted for me. Is this currently not working with yosys and so forth, is there anything I have to take care of, or might it just be a bug on my side? Tried to search this chat a bit and just searched a bit on the internet but the things I found about it were quite old and not necessarily about my problem. Any ideas? I am using the vhdl version btw
    emard
    @emard
    There's some order of signals and small delays between them for dynamic shifting to work. https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/top/top_memtest.v#L73 here is module to control phase shifts by pressing of BTN for testing of SDRAM with variable phase shift of the clock to chip
    Ghost
    @ghost~5dc3e397d73408ce4fd042cd
    alright, ill look at that. thanks
    Ghost
    @ghost~5dc3e397d73408ce4fd042cd
    Oh nice it works. My thinking was just a bit wrong and there was a little bug too. Thanks
    emard
    @emard
    ecp5pll has possibility for fine-precision phase adjustment but this simple BTN module doesn't generate proper phaseloadreg signal https://github.com/emard/ulx3s-misc/blob/master/examples/sdram/memtest_mister/hdl/btn_ecp5pll_phase.v#L51
    emard
    @emard
    I have done a low power shutdown and wake-on-RTC clock example https://github.com/emard/ulx3s-misc/tree/master/examples/rtc/micropython-mcp7940n with this e-ink display shows picture without power https://github.com/emard/ulx3s/blob/master/doc/MANUAL.md#e-inke-paper-display
    Lawrie Griffiths
    @lawrie
    I have taken some time off implementing computers from 1984 to look at GPUs, and any Verilog implementations that I could find. If I am ever to implement computers from the mid-nineties onwards, I need to understand 3D GPUs. I found this which is very interesting - https://github.com/jbush001/NyuziProcessor. It is a CPU that implements general-purpose GPU (GPGPU) single-instruction multiple-data (SIMD) code, and which can be used to implement rasterization, shading etc. in software. It comes with a C compiler and is a general-purpose language that has been used to implement a variant of Unix and Doom. I am not sure if it will fit on an 85f. It looks exactly what I was looking for in an open source GPU.
    The author (Jeff Bush) has a blog on it as well - https://jbush001.github.io/, which has more interesting stuff on GPUs including a full description of the the Raspberry Pi one, and a reference to another verilog GPU implementation.
    I also looked at Jeff Bush's other repositories and found that I had ported one previously to an ice40 board - his Lisp FPGA implementation.
    Lawrie Griffiths
    @lawrie
    I also found this interesting project, which I have ported to the ulx3s -https://github.com/lawrie/FPGAWhack. It is also a type of parallel processing GPU,. with a CPU and an assembler, but the source of data is effectively limited to the x, y co-ordinates of a pixel and a frame number. There is a compiler (in python) that lets you enter an expression involving x, y and f, which calculates the pixel color. It can be used to generate interesting graphical output. There is more detail here - https://github.com/jbush001/FPGAWhack/wiki
    emard
    @emard
    @lawrie HI lawrie, great GPU-vacation. 85F is large and rare project use it fully and compile time will rise significantly so a part of preparation could be getting a free login on some supercomputing cluster for yosys compilation. Here is DOOM for ULX3S and 1h compile time on normal PC https://twitter.com/sylefeb/status/1288053013748289538
    @daveshah1 can yosys actually split its processing on parallel cluster to get any speedup?
    David Shah
    @daveshah1
    No
    you could in theory process submodules separately but you would get a less optimal result that way
    emard
    @emard
    For a larger project like GPU that could be good option
    Konrad Beckmann
    @kbeckmann
    i guess that would be nice while developing so your iteration time goes down, and then when doing a release build you can build everything on a single machine. assuming it can still meet timing etc.
    e2kgh
    @e2kgh
    @lawrie Hi, I'm new to this group, but love GPUs ;-) Just in case you missed that one, it isn't easy to find:
    FlexGripPlus is also very interesting, but VHDL : https://github.com/Jerc007/Open-GPGPU-FlexGrip-
    Lawrie Griffiths
    @lawrie
    @e2kgh Thanks for those links. I will look at them.
    Paul Ruiz
    @pnru_gitlab
    @daveshah1 Recently I upgraded Yosys after a 6 month hiatus. My impression is that Yosys has slowed down a lot. The 6 mo's old Yosys took I think about 4 mins to compile a fx68K retro system, the current Yosys takes about 8. I can time exactly if that is helpful. Maybe some extra passes were added in the past 6 months? One of the attractions of Yosys (for me) is its fast turn-around as compared to the vendor tools. Would it make sense to have a "fast" mode for development of designs that do not need full optimization? I.e. a bit like compiling C without optimizations during development? Maybe I should direct this question to Clifford instead of you?
    Paul Ruiz
    @pnru_gitlab
    Maybe the analogy to C goes further. Back when C was developed, separate compilation of modules was one of its features, and the reason were the slow compilers (or the slow hardware if you like) of the time - standard Pascal at the time could only do whole program compilation. A related design point is the sqlite library. It has many source files, but for for ease of usage for distribution it is all combined into one big source file (the "amalgamation"). Somewhat to my surprise, compilers get more optimizations in the amalgamated source than in the separate source files. My point is: maybe a bit of inefficiency during development is acceptable for most designs and it accelerates the development cycle noticeably.
    David Shah
    @daveshah1
    No, that wouldn't help as the bigger design would probably just spend longer in nextpnr
    drr
    @danrr_au_twitter
    Sharing a small audio demo I made for ULX3S:
    https://github.com/dan-rodrigues/ics-adpcm/tree/master/demo
    It uses ULX3S to demo the ADPCM decoder / mixer core in the root of the repo. (thanks Emard for dacpwm.v)
    emard
    @emard
    https://www.ebay.com/itm/PCM5102-I2S-Interface-DAC-Decoder-GY-PCM5102-I2S-Player-Module-for-Raspberry-Pi/183853870696?hash=item2ace8b6e68:g:C-gAAOSwYbZdCvX1 thanx for this demo! Besides SPDIF and HDMI, this i2s module for 5$ can also produce very clear sound and is directly pluggable to ulx3s
    Erik Piehl
    @Speccery
    @emard I am trying to get back to TI-99/4A work with the ULX3S, i.e. looking to continue the SDRAM work sometime this week. Just checking if there's been some further work with SDRAM controllers to have a perhaps more recent starting point (I haven't read all the 100+ recent messages yet)
    drr
    @danrr_au_twitter

    Thanks @emard , I was thinking of soldering headers to the board at some point to try a few peripherals like that

    For HDMI audio I did see this repo, it is in SV but when I get a chance I'll try running it through sv2v and see if the output is workable with OSS toolchain:
    https://github.com/hdl-util/hdmi

    I would just try SPDIF but I don't think I have any equipment that accepts it

    emard
    @emard
    @Speccery I'd be glad to get 99/4A equipped with SDRAM for complete expandable space. @pnru_gitlab has made for QL https://github.com/lawrie/ulx3s_ql/blob/master/src/sdram.v the latest SDRAM controller. I suggest you try it first maybe it will just work or we can ask Paul for support :)
    headkaze
    @headkaze
    Thanks for sharing @drr I plan on doing some audio demos. Currently working in vhdl on ISE but want to port to fully open source ICE40 and Verilog (have an iCEBreaker and ULX3S on order). My demos will be streaming using a Python script running on the PC side using serial over USB communication with async.v on the FPGA (source from https://www.fpga4fun.com/SerialInterface.html). I really like the idea of using Icestudio to create my projects in a visual style. Do any of you guys use Icestudio?
    I should also be ordering a MIDI Pmod at some point. Just waiting for @goran-mahovlic to get back to me when he's finished testing
    Goran Mahovlic
    @goran-mahovlic
    @headkaze I did solder first MIDI PMOD, but now I need USB MIDI for testing - so I am waiting or it ...
    ULX3S boards are packed and ready, I am just waiting for some papers from CrowdSupply
    headkaze
    @headkaze
    @goran-mahovlic great news!
    emard
    @emard
    @danrr_au_twitter I think every home theatre receiver, like some yamaha 6.1 dolby surround offer great 24-bit spdif quality amost no noise even at maximum volume. Plugs directly to ulx3s 3.5mm jack with 3.5mm to cinch adapter
    headkaze
    @headkaze
    I was just checking out https://github.com/fpgawars/icestudio#supported-boards. Any chance of ULX3S support?
    emard
    @emard
    @headkaze I think @goran-mahovlic got this graphic tool running for ulx3s
    headkaze
    @headkaze
    Ahh yes I should have looked at the source. All ULX3S boards are supported (https://github.com/FPGAwars/icestudio/tree/develop/app/resources/boards)
    I'm pretty blown away by the team here. You guys seem to be adding support for everything under the sun. It's going to be an extremely versatile board with tonnes of tools and examples to play with
    Paul Ruiz
    @pnru_gitlab
    @emard, @speccery: I'm building a Verilog model for the mini Cortex and just completed an SDRAM controller that is matched to the 99000 and 9995 bus. It does one R/W plus one refresh cycle for each CLKOUT cycle (i.e. it is not free running like the 68K one). I'm happy that I spent so much time going into the details of SDRAM a few weeks ago: so far all my recent TI99 controllers have worked out of the box (but pride comes before the fall....). I will post my current 99K controller within the next few minutes.
    Paul Ruiz
    @pnru_gitlab
    The controller is here: https://gitlab.com/pnru/ti99/-/blob/master/sdram.v
    I am using this with a 25MHz CPU clock (i.e. 6.25MHz CLKOUT) and a 125MHz sdram clock.
    emard
    @emard
    @pnru_gitlab great!! Maybe I'd suggest this delay loop to be done with for/generate loop with compile-time parameter N steps.
    Paul Ruiz
    @pnru_gitlab
    @emard I'm building an IDE_SPI bridge from the CPU to the ESP32. The CPU thinks it is addressing an IDE controller, but the commands go to the ESP32 that gets the sectors from a file on the SD Card. Overall timing should still be faster than a 1984 WD1003 controller + disk. I'm modeling the SPI a bit on your OSD code. Is there any particular reason for the choice of sel/sclk/miso/mosi pins on the ESP32? Or just a choice just as good as any?