Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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 :)
    emard
    @emard
    https://github.com/hdl-util/hdmi I think this project is actively developed for audio islands
    @splinedrive does his own audio islands for ULX3S
    splinedrive
    @splinedrive
    You have showed me the links a few weeks ago. Is nice! But I really want to extend 1 bit audio with 2 channels in the moment I rebuild tmds with periods and guards and I had some timing issues. Next would be to understand how the error correction of island data packages are working with bch. I don't simulate, I use only my logicanalyzer and verify my streams on 4 different displays. :) I hope I will finalize this. I want more to play with basics like multipliers, divisors, digital filters designs etc. But to integrate island as much more as to implement tmds-dvi.
    emard
    @emard
    This is how it should be done for real :) I never simulated anything, directly to hardware always :)
    splinedrive
    @splinedrive
    With yosys and with your ftpecp5 it is possible :)
    emard
    @emard
    I had similar adventure with USB core, 4 different mouses, recompilation and storage scope. Only the scope was core in FPGA itself, hdl4fpga project :)
    emard
    @emard
    Most of the time only a small part of core has bugs so isolating only that will make compile process faster and this is greatly improves speed of development
    hhahhaa all sides plugged with somthing :))
    splinedrive
    @splinedrive
    Haha :)
    emard
    @emard
    To reduce no.of.LEDs for debugging, I use st7789 spi display with HEX decoder core, a little less parts to plug in but it adds to compilation time.
    splinedrive
    @splinedrive
    image.png
    And I fight in the moment with this issue here. It is the same picture on different display. Today evening I reworked the complete tmds for hdmi and solved some issues.
    emard
    @emard
    What is the issue - the white border lines or different display makes different picture?
    splinedrive
    @splinedrive
    Yes, because I introduced preamble video and video guard. I know howto fixed it, but is a workarround.
    emard
    @emard
    White borders could be something like off-by one or off-by-2^n at the counters, when something what shouldn't be included to video (and belongs to border or islands) is gated with blank signal and enters video area
    splinedrive
    @splinedrive
    ok
    I know howto to fix it, when I introduce the preamble and guard 2 cycles before HorizontalTotal but makes no sense for me. Must be something else!
    `endif
           /*
           preamble video data period
           */
          /*else*/ if ( (vga_hcnt >= (htotal - (8 + 2))) && (vga_hcnt < (htotal - (/*8*/ + 2)))) begin
             encoding_type = ENCODING_TYPE_CONTROL;
             /* video data period */
             //  control_data_channel_0 = {vga_vsync, vga_hsync};
             /* ctl1, ctl0  = 1 */
             control_data_channel_1 = {1'b0, 1'b1};
             /* ctl3, ctl2 */
             control_data_channel_2 = {1'b0, 1'b0};
          end
            /*
            video guard band
            */
          else if ( (vga_hcnt >= (htotal - 2)) && (vga_hcnt < (htotal - (/*2*/ + 0) ))) begin
              encoding_type = ENCODING_TYPE_VIDEO_GUARD;
          end
            /* remaining control signals hsync, vsync */
          else begin
              encoding_type = ENCODING_TYPE_CONTROL;
          end
    
        end else begin /* !vde */
          encoding_type = ENCODING_TYPE_VIDEO;
        end //  !vde
    I hope I will find it today :). It is good if you have different displays and fpgas :)
    emard
    @emard
    Aha I had similar non-sense situation with me too. I'm never satisfied until I make code that is logically understandable. I was testing it multiplatform, had alteras and xilinxes and when code is non-understandable, it behaves different on different platforms. When debugged properly, all platforms start to work same and correctly
    splinedrive
    @splinedrive
    My problem is I read the standard and some other sources and then you have to try your own implementation and then you can learn a lot.
    emard
    @emard
    With above code, I don't know about econding to comment, but general approach is to use some register for checking is counter within some range that is set and reset to different comparsion of "=" operation instead of ">" && "<" because those operators involve arithmetic units, complicate routing etc. OK if it works and fits fmax, don't fix just make some TODO later note
    splinedrive
    @splinedrive
    Thats why I have 85F :) I have no idea how good yosys is in optimizing such expressions