## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Lawrie Griffiths
@lawrie
The idea now is to recreate my Z80 retro computers using this template and to add some new ones.
I will probably start with recreating the TRS-80 Model 1 as that is about the simplest of the Z80 retro computers.
emard
@emard
Ahaaa so our trs80 will be done again, I remember video chars had some spacing between columns what I think should not be spaced as looking at videos of green terminals, but maybe I could be wrong
Lawrie Griffiths
@lawrie
I plan to redo all the Z80 ones and perhaps get the ZX80 and ZX81 working as they never worked correctly.
Lawrie Griffiths
@lawrie
The redone trs80 is really working - https://github.com/lawrie/ulx3s_z80_trs80
There are some problems with the keyboard
@emard With the old version I got ecppll to generate a 25MHz clock for the VGA (plus 125MHz for HDMI) and a 28MHz clock, which I then divide to produce the CPU clock. Your ecp5pll gives an error when I try to generate the 28MHz clock, so I am currently using the 25MHz clock divided by 8 for the CPU. I don't know if that is causing the keyboard problem.
Lawrie Griffiths
@lawrie
The keyboard problem is that backspace and shift are not working consistently.
emard
@emard
@lawrie If you need 28MHz, you can generater near-28MHz with single PLL. Maybe exact 28 with 2-stage PLL. First set 28 and Extend tolerance it will generate something nearest. Then use nearest to 28.something and 28.something*5 exactly with tolerance 0 or few Hz to fit rounding error.
With 2-stage PLL, you need to create some 28-multplider-divider frequency first and then in second stage take that as input and get 28 exactly. For this you need some try and error, experiment with 2nd stage first to find out which input frequency will provide 28 as output. besides 28 maybe 282, 283/2 and similar inputs will. For example to create 32.0 MHz at 2nd stage I need 40MHz input which can be exactly generated by 1st stage from 25MHz input
Lawrie Griffiths
@lawrie
The 28.409MHz clock is now working, the same as the other version. My problem was the same as you had on the C64. ps2_key[9] inverted.
splinedrive
@splinedrive
Hi, Do you know a pmod for hdmi/dvi (no vga to hdmi)? I found only an article https://hackaday.io/page/5702-dvi-hdmi-pmod-for-an-ice40-fpga. I want to arm my ice40s with hdmi or arm my ecpix-5 with it. The ecpix has a hdmi controller on board :(. Maybe a pmod with and without levelshifters. Or it would be also cool to have more hdmi ports on our ulx3s.
Lawrie Griffiths
@lawrie
There is this - https://1bitsquared.com/products/pmod-digital-video-interface, which I have used on the icebreaker.
The Pmod by Dan O'Shea in that Hackaday article was never sold as far as I know. I am one of the few people to have one as I asked Dan for one. I used in briefly on a Blackice board. You needed to use a short HDMI cable with it.
splinedrive
@splinedrive
@lawrie I have it :), but I like to run tmds generated by the fpga. Today I got a ecpix-5 and it uses a hdmi controler and you have not to generate yourself tmds.
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.
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