Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Radu Stoichita
    @radu_stoichita_gitlab
    I have a little side project for which I need flexible firmware. Basically i went with SaxonSoc because I had many many questions with LiteX that i didn't find answers to. Like you said they evolve quite fast and honestly I have soend tens of hours only following the instructions and building the systems with not much understanding about the inner works of it. Basically, Linux is overkill for the application I try to build. I have successfully booted standalone firmware on Saxon after many many hours but when I consider going further into the understanding of these platforms, the learning curve is very tough for me. I only I had an ARM core with onboard FPGA and RAM controller for 3$ that would be great but there is no such device. Initially I soent some time evaluating Latticemico32 with diamond builder however they don't have native support for SDR only DDR
    @e2kgh right it's scary you need to follow very closely and not deviate. However I run everything on KDE 20.04 and didn't have much issues so far
    emard
    @emard
    We have onboard ESP32 and it can run micropython or plain C as microcontroller, access SD card wifi, bluetooth - maybe it can help somehow for your application
    Radu Stoichita
    @radu_stoichita_gitlab
    @emard exactly how I intend to use it for network connectivity, this is an awesome combo on this board! Just wondering what would be the speed for transferring 100MiB between FGBA and ESP32
    I need the memory ESP32 has not and on the other hand I need the speed for digital ADC application basically 😊
    emard
    @emard
    ESP32 is not very fast, it's about 100-200 KB/s (kilobytes per second) at wifi side. ESP32-FPGA can use SPI, probably slightly faster than wifi. OK currently ESP32 has not much memory. We plan new board design that will have ESP32-WROVER, it will have 2MB PSRAM internally, not big but more than now
    There is also f32c project, slightly unmaintained, this one is reduced MIPS core 100 MHz, SDRAM support, arduino/gcc programmable, very efficient but diamond-only (no ghdl/yosys)
    Radu Stoichita
    @radu_stoichita_gitlab
    @emard cool I will have a look at f32c thank you
    emard
    @emard
    It is in portable multivendor vhdl, compared to saxonsoc or nmigen it's relatively dirty soc'd but has gcc and arduino support. Not very fine support like esp32, but something is working. ulx3s selftest is done with f32c
    Radu Stoichita
    @radu_stoichita_gitlab
    👍👍👍
    Radu Stoichita
    @radu_stoichita_gitlab
    Nice Gadget but beware of potentially lethal voltage on the raw tube end and PSU. You could contact this guy?
    splinedrive
    @splinedrive
    I will order it I want to generate this old school analog signals!
    VGA signal generator takes 4 lines verilog but with this paper it becomes rocket scienes https://bit.ly/3r3LubY
    e2kgh
    @e2kgh
    @emard : so, are you planning on any updates to the F32C, ever? ;-)
    It was a nice piece & environment ...
    About tool chains ... So, how do you guys set up your system? There is the repository from KOST, there is LiteX, SaxonSOC, and they like specific versions of Java, GHDL, Verilator, etc. It is (at least for me) hard to understand, that if something went wrong, it was a problem with the tool chain, or mine, or somewhere in the PATH, I'm getting the wrong utility pulled in? Any writeups, how to set up a "clean" system, not having three/four versions of the same tools?
    Radu Stoichita
    @radu_stoichita_gitlab
    @e2kgh i installed so many versions and sources especially the toolchain that I filled my whole hard disk with them 😂
    Evertime trying a new repo I had to reinstall most of the tools however I started digging inside the helper scripts and writing my own to avoid repeating and deeply nested helper scripts
    emard
    @emard
    @e2kgh some f32c maintainance is planned in todo, but on hold as I'm currently doing some esp32-fpga spi interfacing. For yosys/nextpnr tools I currently use nightly builds https://github.com/emard/ulx3s/blob/master/doc/MANUAL.md#precompiled-opensource-tools-for-all-platforms
    emard
    @emard
    @splinedrive regarding small CRT, I haven't fiddled with this myself. It looks as spare part for older home video-door-phones. Usually it expects monochrome B&W composite signal with electrical properties that can be generated from 4-bit DAC at 3.5mm audio jack. I have also vhdl example on how to generate color burst composite signal, it's bigger than mono B&W but still not too complicated.
    emard
    @emard
    For example UK101/Orao core generates monochrome composite video example and 3.5mm jack mixing is in ulx2s toplevel https://github.com/emard/UK101onFPGA/blob/master/lattice/main_ulx2s_orao_composite.vhd and color example is here https://github.com/f32c/f32c/blob/master/rtl/soc/vgahdmi/tv.vhd
    splinedrive
    @splinedrive

    @emard I have a LCD display with Composite Input. And I tried something similiar

    assign vout = active && (xpos == 0 || xpos == 489 || ypos == 0 || ypos == 267);
    assign sync_ = active || !(hsync || vsync);

    I got the knowlege howto handle composite signales from that blog entry https://jeelabs.org/2016/11/composite-video-from-fpga/ and
    http://searle.x10host.com/Multicomp/index.html

    emard
    @emard
    Yes, exactly, that's the way to go and analog CRT usually accepts composite signal same to above example you mentioned. Some voltage levels must be respected between sync blank and video signal and 4-bit DAC at audio jack is 75 ohm impedance and designed to cover composite signal in our traditional proof-of-concept hackish style
    Lawrie Griffiths
    @lawrie
    I have started working on an Amstrad CPC retro computer for the Ulx3s - https://github.com/lawrie/ulx3s_amstrad_cpc
    It has a long way to go. The video output is not right, and I have not yet done the keyboard, audio or floppy disks. It is currently emulating a CPC664, which has 64KB of RAM and a floppy disk drive.
    It is based on my ulx3s_z80_template and the additions are mainly for the I/O ports and video modes.
    Lawrie Griffiths
    @lawrie
    I am always in two minds how to do the video circuit for these retro computers. The Mist/Mister versions emulate the original chips fairly closely. For the Amstrad CPC there is a custom gate array and a Motorola 6845 CRTC.
    Currently, I am following my normal procedure of bypassing all that and using dual-ported BRAM to directly generate a 640x480 video signal, which is then converted to HDMI. This usually gives good compatibility with monitors and TVs.
    The original chips usually generate a 15Khz signal for CRT monitors, which was often composite.
    The approach that Mister takes is to provide two options: HDMI or analog.
    Lawrie Griffiths
    @lawrie
    For HDMI they write the video data to a frame buffer in DDR3 memory and generate the HDMI signal from their Linux implementation. There are options on how to do this which have to balance lag with compatibility with monitors and TVs. Because they are converting a low resolution to a much higher one, they have lots of options for scaling, rotating and scan lines. We cannot do this on the Ulx3s.
    For analog output Mister uses an I/O board with a VGA connector, but not usually for VGA signals, as it is more commonly used for CRT display. So you need a cable to send the 15khz signal to the CRT, which can be VGA to RGB using a SCART connector, or VGA to composite, or (I think) VGA to composite. We could do this on the Ulx3s using a VGA Pmod.
    Lawrie Griffiths
    @lawrie
    Another problem with my way of generating video signals is that timimg can be wrong. The Amstrad CPU shares its RAM between the CPU and the video, and slows it down a bit to achieve this. So although it has a clock rate of 4MHz, it is effectively about 3.3v. I am using dual ported BRAM for the video ram. I am not sure the exact speed matters too much for home computers - it is more critical for games consoles.
    If we want to support options like screen rotation for arcade games on the Ulx3s, we would need a frame buffer. Although it is not usually feasible to use SDRAM for a frame buffer when it is used for other purposes by the retro computer, some sort of parameterized generic frame buffer in BRAM might be feasible.
    Lawrie Griffiths
    @lawrie
    I would appreciate any ideas on how best to do the video circuits for retro computers on the Ulx3s from @emard , @pnru_gitlab or anyone else who has ideas.
    Lawrie Griffiths
    @lawrie
    When Mist/Mister do use VGA monitors, they use a scan doubler to convert the 15khz signal to a 31khz VGA-compatible signal. This is one of the approaches we can take to convert the CRT-compatible signal from the original video chips to a VGA and then an HDMI signals. This is the approach that was taken for muy ZX80/ZX81 implementations and I think for @emard's recent C64 Mister port.
    For the NES port, @ironsteel used a frame buffer as without that the NES signal was not compatible with many monitors.
    This discussion overlaps a bit with the one about using composite CRTs.
    Lawrie Griffiths
    @lawrie
    (3.3v was a typo. The effective speed of the Amstrad CPC Z80 is about 3.3MHz).
    We do not currently have many Arcade game ports on the Ulx3s. The only one I know about is Phoenix. You need to rotate your monitor to ru that, and it is not always convenient. The code for the Pacman arcade cabinet used to work on the Ulx3s, but the last time I looked at that, it would not build.
    emard
    @emard
    @lawrie Your thinking of video covers the complete problematic and each approach can lead to some issues. For arcades, there is frogger scramble and amidar from papilio project but not too much than this. I think moon patrol, 1943, cat'n'mouse and looping are challenging to port and could be even interesting to play.
    emard
    @emard
    For video conversion, I'm fond of avoiding the lag-delay from video generation to visual appearance, this is one of rare things that justifies use of FPGA, it can offer something what PC and mame emulation can't. Scandoubler is good for complex video chips that are CPU clock sensitive like c64 vic2. BRAM is probably better for simple videos with just pixel framebuffer or tilebuffer, where clean room rewrite in verilog is more suitable for HDMI out than making composite video first and then converting that to HDMI. Buffering to SDRAM to 90° rotate or convert frame rate will make at least 1 frame delay, for slow response platforms it is acceptable and makes video flexible. Especially if SDRAM has no other use as CPU is better run from BRAM for example
    emard
    @emard
    If it is only for 90° rotation, I have pivot monitor that can be rotated by hand, so I'd vote to not put effort in 90° buffering for display as not only the work to write the code must be done, but also larger core will prevent fmax and would need us to choose should we have eg. USB joystick support or 90° rotation, as if both are enabled then nothing works. In C64 this happens with USB addition - if I add USB I get black screen and no boot :)
    Paul Ruiz
    @pnru_gitlab

    @lawrie I am still fairly swamped with work stuff. For retro-video my preference normally is to adjust the video circuit to a modern resolution and scan frequency. Often this means doubling the pixel size both horizontally and vertically by repeating a pixel twice in succession (i.e. running the shifter at half the modern pixel speed) and repeating a scan line twice (i.e. skipping the bottom bit of the line number).

    That approach does not always work: for example in the ZX80/81 the video signal is largely software generated and there is no actual hardware to tweak. The standard signal could be faked, but a lot of clever software did custom stuff and would hence not work with hardware that emulated the standard software signal. In these cases taking the (often only half-compliant) PAL signal and doing a special converter circuit (either line based or frame based) seems the only way to do it.

    emard
    @emard
    But maybe ULX3S is good for this, at one point we will saturate FPGA resource and this is "signal" we've explored enougho with this platform and should move to next one :)
    Paul Ruiz
    @pnru_gitlab
    I only lightly skimmed posts in the past weeks. Did I see correctly that somebody did a proper module for HDMI (i.e. with data islands & sound encoding)?
    emard
    @emard
    Yes, there is already a fresh independent project for other boards xilinx/altera that claims to do audio islands (I haven't yet tried) and here is a member of this group that does his own reimplementation of audio islands from scratch for ULX3S (work in progress)
    @pnru_gitlab I had some ti99/tms99xx porting questions for you that know this platform or @Speccery probably it was about "looping" arcade game if some approach could be applied. I think there's no FPGA port to this, mister doesn't have it. Other than a game, it's not too much "scientific" so It's kinda enginerhr-gobbler :)