Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    splinedrive
    @splinedrive
    It would be nice if you have the feature to generate tmds to pmod.
    emard
    @emard
    @lawrie TRS80 tried, keyboard works, picture ok
    @splinedrive there are (expensive) PMODs with chips that accept parallel VGA input and convert to TMDS in the chip. For cheap PMODs with minimal hardware like transciever chip or just RC network, TMDS signal is generated by FPGA core, sources are short and are widely used (ulx3s uses this)
    splinedrive
    @splinedrive
    @emard I have done a dvi controller that works on ulx3s. I learned from the fpg4fun hdmi code. But how the tmds encoder works is not possible to understand from fpg4fun code (for me). I hacked the tmds encoder with dvi standard, Page 29. There is flow chart you can hack verilog down directly from that flow. I'm definitely not saying anything new. And I am little bit happy about that. To have a PMOD with RC network would be very nice. Do you know providers?
    splinedrive
    @splinedrive
    I ordered these modules https://de.aliexpress.com/item/32959577833.html?spm=a2g0s.9042311.0.0.4e1e4c4dJBW9MC maybe with soldering RCs this will work hopefully @emard ?!
    Lawrie Griffiths
    @lawrie
    splinedrive
    @splinedrive
    @lawrie exactly what I'm looking for.
    emard
    @emard
    @splinedrive you can also use this direct adapters without any RC but be careful to supply FPGA from monitor if monitor has USB supply or with USB supply that shares the same GND as monitor. Otherwise 50Hz AC may fry fpga when adapter has no RC
    splinedrive
    @splinedrive
    @emard thank you for the infos! I will try it when I get the stuff from Ali :)
    Lawrie Griffiths
    @lawrie
    @emard I thought I would look at my ZX80 implementation before trying to convert it to use my new template.
    It had two problems with the video: it was shaky and characters were corrupted.
    The shakiness seems to be because of the frequency of the video clock. I was using a 13MHz clock and a 125MHz HDMI clock. With the scan doubler, the VGA clock is effectively 26MHz.
    Lawrie Griffiths
    @lawrie
    I changed the clock to 12.5 MHz and that fixed the problem, but slows the CPU down a bit.
    I just tried changing the HDMI clock to 130HHz and putting the system clock back to 13MHz, and that seems to work too, so I will probably stick with that.
    Lawrie Griffiths
    @lawrie
    The character corruption seemed to be because the shit register used to shift out the pixels of a character was being reset a couple of pixels through the character. I don't know why. The logic is similar to the Mist version, but I am using clocks differently, so it is probably due to that. The ZX80 logic in this area is convoluted and I don't understand it well. But anyway, I put in a back to count pixels and avoid the early reset, and that seems to be working, so the screen now looks OK.
    One thing about the Mist code is that it frequently uses signals before their declaration. For example here - https://github.com/gyurco/ZX8X_MiST/blob/master/zx8x.sv#L430-L432
    You have complained that yosys allows this, but Mist and Mister are presumably being synthesized with the Quartus software.
    As far as I can seem, this is illegal in Verilog, so I am surprised it is allowed.
    Moving all the declarations to before their usage in my version of the ZX80 made no difference.
    Lawrie Griffiths
    @lawrie
    I only have the ZX80 mode working not the ZX81 mode. In ZX80 mode the video signal is not generated when you are typing. On the original ZX80 this caused a flicker. It does a lot more than a flicker on my monitor.
    I have not implemented tape loading with the ZX80.
    Lawrie Griffiths
    @lawrie
    My capture card doesn't like the video signal. My monitor reports it as 57Hz and display it fine.
    emard
    @emard
    @lawrie ZX81 shows some video for me but pixels shake/jitter in mostly Y direction and I'd say a bit in X direction too. It's useable, I can type and read letters but it's not stable. Upper parts of the screen shake less than lower parts, maybe some error accumulates. It could be Z80 implementation is not cycle exact as original if code is used for pic generation
    Lawrie Griffiths
    @lawrie
    It seems more stable with the pll set to 125 12.5 rather than 130 13, but that has a slightly slow cpu clock.
    Lawrie Griffiths
    @lawrie
    I have pushed a version with that and 16KB of ram
    emard
    @emard
    I will try to recompile this using ecp5pll. if it's only for 13:12.5 difference, I could not notice so small change
    Yes 125/12.5 seems fully stable. Also I added --compress option :)
    Lawrie Griffiths
    @lawrie
    The code in these projects is a bit out of date, which is why I was planning to update them using the template. But the ZX80/81 does not follow the pattern of the other implementations as the video needs to be generated the way the original machine did it. Unless I mirror the display list in dual-ported vram and write new VGA code to convert the display list. Not sure how feasible that is.
    emard
    @emard
    Just add ecp5pll and some notes like this
      localparam pixel_clock = 12500000; // 12.5 MHz slower than original, screen stable
      //localparam pixel_clock = 13000000; // 13 MHz original, screen jitters
    
      wire clkdvi;
      wire clk_sys; 
      wire [3:0] clocks;
      ecp5pll
      #(
       .in_hz  ( 25*1000000),
       .out0_hz(pixel_clock*10),
       .out1_hz(pixel_clock)
      )
      ecp5pll_inst
      (
        .clk_i(clk_25mhz),
        .clk_o(clocks)
      );
    Lawrie Griffiths
    @lawrie
    I will use that.
    Just tried it in ZX81 mode and that appears to work (zx81 = 1). That gets rid of the screen blanking. Last time I tried it, it didn't work.
    The keyboard doesn't seem to work correctly in ZX81 mode.
    emard
    @emard
    I'm compiling your latest pull to see if screen is stable. In default mode keyboard worked ok
    ok, latest version 12.5 MHz makes stable picture here
    Lawrie Griffiths
    @lawrie
    I am getting this when I use ecp5pll:
    Info:     promoting clock net vga2dvid.ddr0p.SCLK$const to global network
    make: *** [ulx3s.mk:16: bin/toplevel.config] Segmentation fault (core dumped)
    emard
    @emard
    Strange, for me it normally works. I think I pulled yesterdays tools from edbordin site
    Lawrie Griffiths
    @lawrie
    I just pulled the latest to check it wasn't that.
    emard
    @emard
      localparam pixel_clock = 12500000; // 12.5 MHz slower than original, screen stable
      //localparam pixel_clock = 13000000; // 13 MHz original, screen jitters
    
      wire clkdvi;
      wire clk_sys; 
      wire [3:0] clocks;
      ecp5pll
      #(
       .in_hz  ( 25*1000000),
       .out0_hz(pixel_clock*10),
       .out1_hz(pixel_clock)
      )
      ecp5pll_inst
      (
        .clk_i(clk_25mhz),
        .clk_o(clocks)
      );
      assign clkdvi = clocks[0];
      assign clk_sys = clocks[1];
      /*
      pll pll_i (
        .clkin(clk_25mhz),
        .clkout0(clkdvi), // 125 Mhz, DDR bit rate
        .clkout1(clk_sys),  //  13 Mhz system clock
      );
      */
    This is exactly what I have in toplevel as replacement for your code
    Lawrie Griffiths
    @lawrie
    I was missing the assigns.
    emard
    @emard
    it can be shorted as wire clkdvi = clocks[0] and delete wire declaration above...
    Lawrie Griffiths
    @lawrie
    It is working now.
    emard
    @emard
    ecppack --compress can also be added
    Lawrie Griffiths
    @lawrie
    Yes, I have done that and removed idcode.
    I have pushed it now. I will see if I can get zx81 mode working.
    emard
    @emard
    Im compiling current version
    it works great, picture stable