Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Lawrie Griffiths
    @lawrie
    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.
    (3.3v was a typo. The effective speed of the Amstrad CPC Z80 is about 3.3MHz).
    Lawrie Griffiths
    @lawrie
    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
    image.png
    I got the ranges from here
    emard
    @emard
    compilers won't optimize this, a man is required to reformulate algorithm to avoid ">" things when not needed. If counter is monotonicaly incrementing, then register set "=start" and reset "=stop" will replace ">" arithmetic
    reg in_range
    always @(posedge clk)
    begin
      if(counter == start)
        in_range <= 1;
      else
        if(counter == stop)
           in_range <= 0;
    end
    splinedrive
    @splinedrive
    Ok give me an example for:
    else if ( (vga_hcnt >= (htotal - 2)) && (vga_hcnt < (htotal - (/*2*/ + 0) ))) begin
    emard
    @emard
    always @(posedge clk)
      in_range <= counter == start ? 1 : counter == stop ? 0 : in_range; // save lines :)
    ...
      if(in_range)
    splinedrive
    @splinedrive
    Is unreadable!
    emard
    @emard
    :) but that's expresson to what really hardware "likes" to be made of when optimized
    splinedrive
    @splinedrive
    Ok! I have no idea! but htotal is known during compiletime.
    If something works I have to compare the RTLViews
    emard
    @emard
    start and stop condition may be also registers and not necessary constants known at compile time. Just note that in_range will be 1 clock delayed, so adjust -1 to start/stop ranges to make if(in_range) trigger correctly
    splinedrive
    @splinedrive
    Donald Knuth said: “Premature optimization is the root of all evil” :)
    emard
    @emard
    Yes, he gave tram station example: Q: help me at what station should I get off for traffalgar square? A: you should get off one station before I get off :)
    splinedrive
    @splinedrive
    :)
    Lawrie Griffiths
    @lawrie
    My Amstrad CPC is starting to work. The video seems OK now and the keyboard works if you type slowly. Keyboard losing keys is probably due to interrupts or clock speed, which I haven't looked at yet. I need to add audio and floppy disk - https://github.com/lawrie/ulx3s_amstrad_cpc