Retro Console Project

[Rob Holmes]

Hi All,

Just wanted to share here what i am working on. As i'm probably going to be a pain with questions in the future it makes sense for a little bit of context.

Goal:

Read and process the RBG signals out of the sega game gear and display on both a VGA monitor and and LCD panel, both of which run at different resolutions and frequency to the original hardware.

The Setup:

Game gear of course.
ICE40LP1k programmed with the Lattice HW-USBN-2B
640x480 VGA Monitor
320x240 LCD Panel
Big Nest of wires.



FPGA Board:

in addition to the ICE40lp1k, i have an IS61WV25616BLL-10BLI ISSI SRAM chip.

Progress:

Due to the mess i left the project in over a year ago, ive gone back to the start and stripped out all previous bad decisions :) So im back at square one.


You cant tell its been a while due to the literal dust accumulation.


Good bits:

• I'm currently reading data from the gamegear, its a start right? Located hysnc and vsync and am clocking out RGB data in the sequential format the sega chips give me.
• It looks like sonic the hedgehog.

Bad Bits:

• Colors are wrong.
• Timing is off as the image scrolls up the screen.
• Not scaled to fit the screen.

Todo:

Everything!

• Read data into an an Async Fifo.
• Write data to SRAM
• Scale the data (find a suitable algorithm as original screen and target screen and not proportional to each other)
• Read from Sram into outgoing FIFO
• Read from outgoing fifo into vga stream (and LCD stream)
• Time it all so everything does its bit at the right time, i.e. cant read and write to sram at the same time, 

So there we have it.... if nothing else im always just  pleased it displays the running game at all :)

Ill post updates as it improves... hopefully.

Thanks to everyone who has helped me in the past getting icestudio setup again.

[Jo mo]

Hello Rob,

Nice project, do not hesitate hesitate to share with us your icestudio file .ice ! To allow us to see what you are doing inside your fpga !

But if i understand well, what you are trying to do is this !?

I supposed that you started by:

- connecting wire as explained in the  "Installation diagram"

- using the verilog code available in that web page ( in " Logic Equations " ) ?

Have a nice  day!

[Jo mo]

Oups, 

It is not verilog code but Ahdl (for altera cplds) !

the conversion to verilog should be easy! 

This is a task for our new friend "Deepseek" ;-)  see joined file

Remains maybe some debugging ;-)

[charli va]

Hi Rob! An interesting project, I really like things related to retro computers and old consoles, you learn a lot.

I started a project a long time ago with another objective but motivated to build a small gameboy-type console with an fpga, but it was stopped due to lack of time. If you comment on your progress I will help you in any way I can and I'm sure we will all give each other feedback.

Good luck and encouragement!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/78a3f12e-4754-47c4-b5f5-2105bd0f4ed3n%40googlegroups.com.

[Rob Holmes]

Thanks all,

Yay, fixed the colors at least :) Simple error, i had them mapped the wrong way around.... 0-11 instead of 11-0


Once i stabilize the image, then i cant ignore the fact i need a VGA buffer any longer as i cant scale the image in realtime.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCa7s1eZTo9u3Tx9i23XqWK46RrxkRYwe4828iqghqbsyQ%40mail.gmail.com.

[charli va]

Wow!!! great job Rob!!! this become interesting!

If could be useful for you and you don't know it, this is a project similar like you but for analogue pocket, maybe could be inspirational for you:

https://github.com/RndMnkIII/Analogizer

Have a nice day!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0iPhL_aziCsrx-ij4VEk_PHLTsHAhrfHRa1gc9zsh3Rsw%40mail.gmail.com.

[Rob Holmes]

Ok ive hit a problem which highlights my inexperience with verilog.

I am adding a scaling algorithm to the line buffer, and i need it to be fast, hopefully fast enough to complete within the VGA hblank period.

I want to write the data in using one clock speed and process the data at another much much higher clock speed. 

However as this is inferred BRAM i dont think i can wire two different clocks to the same side at the same time.

When i change sys_clk input to have a different clock then i get an error which im assuming is because ive violated the BRAM.



While the clocks are the same it works (kinda) but is no where near running fast enough to complete before the next line comes in.




So my question is should i use the higher clock speed for both always blocks  and think about changing the first always block to write the pixel data in some kind of clock domain crossing fashion if thats possible even.....

Hopefully that made sense....

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZx5higkb28Xn8BeUPNrb9FoejNXwEcgY7MFBxiQFzr%3DQ%40mail.gmail.com.

[charli va]

Hi Rob! this message suggest you that your FPGA has no more space for your design! could be for a lot of things (design large enough or some bad implementation that generate a full of cells).

If you want go to ice-build directory and send us the .asc file if exists, in other way try to remove all unnecessary block in your design.

¿How are you generating the fast clock?

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hrxenYVLq-399G_iTd5DFSJjwdTLWQstEStC%2Be4FLo7g%40mail.gmail.com.

[Jo mo]

i am not sure that in understood well,

it is a bit special, but maybe you can try multiplexing the 2 clocks.

Something like this.

But if your clk_write to memory is at a Vga pixel rate (around 25mhz for 640x480), and you want to process at the end of each line during the blanking period (around 100pixel),

It means that you will need to process (including the memory read) at a rate which 25mhz x 640/100   (~150 mhz ) . 

If that frequency stays in the fpga, it should be ok (in terms of EMC)!

But in my projects i never worked at thaht speed :-) . So I have no idea if this can bring problem.

If not, maybe you can do the process after every pixel ! A kind of pipelined process . So everything will run at the pixel frequency ?!

[Rob Holmes]

Hi Jo,

thankyou for the feedback.

"It means that you will need to process (including the memory read) at a rate which 25mhz x 640/100   (~150 mhz ) . "

Yes this is exactly what 'im aiming for, trying to solve  using raw speed.

I'm going to try and process on the fly, i think it might be possible and certainly more desirable. (this would be a lot easier if the consoles original resolution evenly divides into 640!)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/56bf3567-7f8b-438a-9a9e-c62df0a72093n%40googlegroups.com.

[charli va]

Hi Rob! goes to 150Mhz could be very complex in this small fpga. You need to show the Fmax(Max freq) speed for your circuit, activate the FPGA resources view, and when you build your design, you could view in the bottom the space occupied in the fpga and the maximum speed, as well as other data such as the bram used, etc.

Think that is not only enough to put a 150Mhz clock feeding your circuit, your circuit should be capable to run at this freq.

Although the pll of this fpga can reach 250Mhz, I don't know if it is realistic to consider being able to process at that speed with this fpga, in fact I don't have the technical sheet at hand but from memory I would swear that, for example, the maximum frequency for the brams of this model is 100Mhz (I know that you have said that your idea is to route it directly in real time but just so you keep in mind that if you want to exceed 100Mhz you will not be able to count on fifos based on bram or nothing similar). 

I'm telling you this so that you can think about other strategies and not get upset if you start having problems.

And if you have EMC problems you already know...  ;)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gsj%3DP6ecQnSsM9zdOZHLz8j9%3DeLRE4SzJoQ%2Bw%2Bq3zjKQ%40mail.gmail.com.

[charli va]

After writing to you I kept thinking... I would recommend you start with a simpler technique and thus also gain mastery with pixel manipulation, verilog..... I would recommend you start with a pixel doubling that seems to me to be the simplest technique to start with, the idea is to generate from each pixel of the game gear (320x240) a pixel of 2x2  to obtain a 640x480 image.

To do this you will use the input pixel clock at 25 Mhz and the output clock at double (50 Mhz), which is quite reasonable.

Another option smaller at the resource level is to implement line doubling + pixel doubling. Basically it is sending each line 2 times to double the height and each pixel 2 times to double the width, you can achieve this with a few flip-flops and zero brams.

It's just an idea, if could be useful.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gsj%3DP6ecQnSsM9zdOZHLz8j9%3DeLRE4SzJoQ%2Bw%2Bq3zjKQ%40mail.gmail.com.

[Jesus Arias]

Hi,

I got some ideas too ;)

The video timing is NTSC/PAL, right? Thus, a line last 64us, it has 256 visible pixels, and the pixel clock should be around 10MHz.  The VGA line last 32us, half the time, but lines also have to be duplicated in order to fill the screen. Therefore the main idea is to use a double buffer with 2x256 pixels (2 BRAMS). One buffer gets written with the incoming PAL pixels during 64us while the other is read to the VGA two times. Then, the two buffers are interchanged. BRAMs have separate read and write ports, making this arrangement quite feasible.

The VGA clock would be 12.5MHz instead of 25MHz, meaning the pixels are twice as long, and because the lines are also duplicated this results in the console pixels being translated into 2x2 VGA pixels on the screen. The input pixel clock is asynchronous to the main clock of the FPGA and this could be a problem. Maybe a PLL could be used to derive the VGA clock from the pixel clock, this would be ideal..

Anyway, I was just thinking. Good luck with the project

[Rob Holmes]

Thanks everyone for the help and useful tips, it means a lot :)

So... I managed to get the simple case of pixel doubling and line doubling done fairly "easily". However.....

The game gear has a pixel clock of 32mhz and my output is 60mhz, im largely ignoring the sync for the time being as that is future Robs problem.

The console outputs two different resolutions in one mode it is  160 x 144 and another mode it is 256x192....
So i need to be able to scale up to 640x 480 in both scenarios, which ultimately means its a pain in the butt.

Progress Report:

I found an image scaling algorithm published in "Dr. Dobb's Journal May 2002" written in C and i emailed the author of the paper, and he very kindly sent me the source code which was incredibly kind.

Converting his C code into a state machine i ended up with this



After about 12 hours of fiddling i think i have at least HORIZONTAL scaling somewhat functioning.

Allowing me to scale from any src width to any target width

So here is a screenshot scaled from 160 to 640 (would have been trivial if that was the only version of scaling needed, and could have skipped the algorithm)


And here is a screenshot of it scaling from 160px to an arbitrary value of 467px



Im going to put the in the WIN column. 

Next..... vertical scaling...... 

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/11d335dc-75b7-484d-be01-c1716065d690n%40googlegroups.com.

[Rob Holmes]

Misated above

The game gear has a pixel clock of 32Mhz, i am outputting at 25Mhz and both have a frame rate of 60hz,so maybe syncing these up wont be so bad.... 

[charli va]

Huge progress Rob! Thank you for sharing your journey with us. If at some point you publish your work, ask the author of the algorithm for permission to publish it, it will surely be very interesting, there are many lost gems in magazines from the 90s.

I imagine it is some type of interpolator, there is no doubt that a lot can be optimized in the FPGA when going from a sequential code to something that can be parallelized, you will tell us.

Anyway congratulations on the progress!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0iaq9sMMgSEhD31MjK5Bstp1RZotm3G-6xQ-w0O7rw-HQ%40mail.gmail.com.

[Jesus Arias]

Hi,

I think you can use a PLL like this to sync the clocks:

$ icepll -i 32.2159 -o 25.175 -m

/**
 * PLL configuration
 *
 * This Verilog module was generated automatically
 * using the icepll tool from the IceStorm project.
 * Use at your own risk.
 *
 * Given input frequency:        32.216 MHz
 * Requested output frequency:   25.175 MHz
 * Achieved output frequency:    25.169 MHz
 */

module pll(
        input  clock_in,
        output clock_out,
        output locked
        );

SB_PLL40_CORE #(
                .FEEDBACK_PATH("SIMPLE"),
                .DIVR(4'b0000),         // DIVR =  0
                .DIVF(7'b0011000),      // DIVF = 24
                .DIVQ(3'b101),          // DIVQ =  5
                .FILTER_RANGE(3'b011)   // FILTER_RANGE = 3
        ) uut (
                .LOCK(locked),
                .RESETB(1'b1),
                .BYPASS(1'b0),
                .REFERENCECLK(clock_in),
                .PLLOUTCORE(clock_out)
                );

endmodule

[Jo mo]

Hi guys,

@ Jesus, I don't understand well the idea of syncing two different clocks speeds !? Maybe if their are quite close one to each other?  

As combining two different clock speeds can bring metastability problems, i think, in this case, it may be easier to just use in the fpga circuit the same 32mhz as in the gamegear (so wiring it if possible, without using an fpga pll ).

and use this vga timing settings . No ?

Big hug and have a great week guys !

[Rob Holmes]

Hi all, i think the biggest problem i will have is matching the overall screen refresh speeds with each other...

I am reading in one frame of data, and outputting the same frame after processing to either VGA or an IPS 3.5" panel.

As this incoming refresh rate is 60hz and i cant change that, both outputs will have to be at 60hz otherwise i will slowly drift out of sync.

In my current test, i am starting the VGA output at the end of the first line of the incoming frame, so that the output is running exactly 1 line behind the source, hopefully giving me enough time to process a line during HBLANK for horizontal scaling.

But as both are at 60hz refresh rate they "should" stay in sync with each other, i think deriving the 25mhz clock from the incoming clock might stop any drift over time if the incoming clock is not as slow or fast at the specification says it should be. I.e if the gamegear clock is a little slow, then it will slow down the pll clock proportionally and hopefully not enough to be so far out that it doesnt work...

As always, im testing everything..... refactoring and trying again..... repeatedly.... for what seems like forever :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b6426ad0-e934-41f6-8c90-f5f619c84f41n%40googlegroups.com.

[charli va]

Hi Rob! I don't know the game gear very well, although it was a console that I always wanted to have when I was little.  To try to help you and also learn that it is something that interests me, what you are trying now is to go from 160x144 to 640x480, going 160x144 at 60Hz and 32Mhz and we want to go to 640x480 at 25...Mhz at 60Hz, is that right? to confirm that I am in the correct hypothesis.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gHnxp-PG39rc_BVYOgUmHL%3DgOdWWwbi-%3DehMV2UeLjYA%40mail.gmail.com.

[Jesus Arias]

Hi Joaquim,

The idea is to generate the 25MHz from the incoming 32MHz of the Game Gear instead of using another clock source (maybe a 12MHz) for the FPGA. As Rob said, this will eliminate any phase drift between clocks. The 32MHz can thus be used for sampling the incoming pixels and the 25MHz for generating the VGA output (BRAMs can have different clocks for read and write)

And I think  32MHz is actually 3 times the pixel clock (pixclk = 10.7386MHz * 48us = 515 pixels) It looks a bit too much horizontal resolution for video, but I also think the console displays wide horizontal borders, ¿am I right?

Nice day!

[charli va]

I like a lot the pll idea of Jesús , In fact he was making a possible scheme with his idea (with the pll we save the need for a fifo, it's simply great).

In calculating the height, there would be two options, one is to center the resolution, simply tripling each line (and the remaining ones are left black below, above or distributed by centering the image). Or if we want to be faithful to the aspect ratio, since each line would have to be repeated 3.33 times vertically (144 → 480 => 480/144=3,33), we can do an interpolation, every three lines making the fourth the average of the previous ones.

Here a flow if could be useful:

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/dc685c70-8e3d-44d8-89f5-422e637bf9een%40googlegroups.com.

[Iceflow]

This project looks like it want to aim something like this: https://es.aliexpress.com/item/1005007344974985.html isnt it?

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZuuKYpqDKZt%3DABLFSQp2pmvAiHtPP1rLM8T_ic-%3DTNGA%40mail.gmail.com.

[charli va]

This aliexpress product is a lcd replacement to improve the original screen with an ips screen (more resolution in the same size than original), in part is very similar but Rob try plus of replace for an ips screen connect to an vga output (and maybe could be easy port to hdmi).

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBj0o-W-YXADL_JCS7%2BhY_ZizjJixCAGceRvTgxpyg-b4w%40mail.gmail.com.

[Rob Holmes]

Again thankyou all for your feedback, its been super helpful...

I have finally got everything synced up, ive attached a video below showing a stable image..... the video only shows about 10 lines of the image because that is the maximum i can fit into BRAM for my reduced test case.

Ive stripped out all the code (again) back to basics to ensure that i have a solid sync before i can start adding frame buffers and the like back in.

Note: if only i had enough BRAM to fit 640x480 image in, this would be the easiest project in the world from here :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYGFVc4X-RVKWTU1icr48A%2BoM_KmvKR4ju8-a4jDE%2BfKw%40mail.gmail.com.

[charli va]

Hi Rob! It looks amazing! It moves very smoothly!

There is no easy project, even the seemingly simplest thing has infinite details if you look in depth.

If you try the pll sync proposed by Jesus you need a very small framebuffer (only for 1 line and some register for prior pixel or something like this)

Give it a thought

Have a nice night!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jx3CU_-iWKNNnkHtASjB2s7SFtppB%2B8%3D0mEcq12vOG9g%40mail.gmail.com.

[Iceflow]

Aliexpress replacement screens allows for vga output also, so its clearly very similar to what he want to do...

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYGFVc4X-RVKWTU1icr48A%2BoM_KmvKR4ju8-a4jDE%2BfKw%40mail.gmail.com.

[Jo mo]

Hi aisflou,

it terms of functionality, it seam you are right.

But the problem is that:

- This small fpga (lattice lcmx02 i think ) is not supported by icestudio (or other opensource tools).

-  I do not see some documentation to know at least were we should make the Jtag connection to program the fpga.

 

This board look preprogrammed, so the customer can just solder it in his game gear and use it as it is!

So difficult to tweak the code for doing those " 5 legged sheeps " that we DIY people like ;-)

Have a good day!

[Iceflow]

Totally agree with that, tinkering is what it has hehehehe

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/3a90fd4b-da61-4372-a6ec-e62a54b7addbn%40googlegroups.com.

[charli va]

Hi IceFlow, in this forum we make many things that exists commercially but the idea is  learn, discover how all these devices work and above all share knowledge and learn from each other. What's cooler than Rob taking the video signal from his Game Gear into a vga and doing it himself? and along the way we have already discussed and learned about clock synchronization, pixel doubling, etc.

I hope you enjoy these conversations!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBhj7YTB69jCFhqYfr_pDwoi-BTnXFoPgZUCUkPgrpaxtw%40mail.gmail.com.

[Iceflow]

Totally true! :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCa698h0dYM9btSZszy8BegL4Ts%2BL0xgkcJzF%2BkciVkeGQ%40mail.gmail.com.

[charli va]

🥳🚀😉

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBjaDs8DrYLOQJD78KJRogYptT-5Sr4TzMkHxGQfP_d93w%40mail.gmail.com.

[Rob Holmes]

Thought id share, what looks like a horror show but in reality im calling it progress ;)

CONSOLE => INCOMING BRAM "FIFO" => SRAM => OUTGOING BRAM "FIFO" => VGA

The fact that anything at all comes out the other end is an absolute win :)

Had to share, as its so wrong its funny!!!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCbUNFwdNPEGrmFhKhQJLhOqvWuo%3Dz6iU9ZTMzb1a5OYeQ%40mail.gmail.com.

[charli va]

This is a great Victory Rob!!! go ahead!!!

i need more shit like this! 😉

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0g6%3DrE%2BFY19peHexCFAt%3DcEkBAp4WeqFZnjm7MAC-ZdNA%40mail.gmail.com.

[Rob Holmes]

Ok i have a question about if the following is possible.

I am trying to create a re-usuable module that is a dual port BRAM instance, i want to be able to pass in the data width and the address width as parameters.

However i think i'm probably misunderstanding how something works (sorry in advance). 

Will icestudio let me use a parameter as part of an input definition?

I am unable to get the module to verify as seen below..

I fully expect to be informed i'm doing something complete wrong here :)

[charli va]

Hi Rob! Just this os a new feature in icestudio give me Two or three days to finish it. I’M telling you soon  about it

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f95874a5-e945-4a3f-82ae-1e24f5d42f58n%40googlegroups.com.

[Rob Holmes]

Its been a few days, so here is an update.... as there is something to update :)

I've switched over from a VGA monitor to a 3.5in IPS panel, which is what i ultimately want anyways, vga was "supposed" to be easier to start.

I've finally solved ALL the sync issues by doing the following..

• I have tied the IPS screens VSYNC directly to the game gears vsync, and tied the pixel clock of the IPS panel directly to the pixel clock of the Gamegear.
• So when the gamegear issues a vsync i use that as my starting point and generate my hsync and pixel counts from there.
• Using a clock enable module to divide the gamegear 32Mhz down to 8Mhz and using that as the pixel clock for the IPS panel.

Ive managed to get the timing of reading, saving to fifo, saving to sram, reading from sram etc to all run off the 32Mhz clock, and because the IPS screen now runs on a divided clock via a clock enable EVERYTHING is now in the same clock domain and life is oh so much sweeter :)

The attached video is without scaling, so next weeks job is to start adding the scaling back in.

[charli va]

Wow Rob! sounds goog all of you tell, congratulations! the video is very smooth and clear.

Waiting for your advances!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/fc9788af-2a0b-4691-8797-0f341d80a974n%40googlegroups.com.

[Jo mo]

Congratulation Rob, Great result!

For the scaling, it seams you have to multiply by around 1.81 in X axis and by 1.70 in Y axis.

To start, a simple think you can do is:

- in X axis : double 4 pixels and for the 5th pixel, you let it Undoubled, and repeat this for the rest of the line,..  because  ( 2* 4 + 1) / ( 4 +1 ) = 1.80

- in Y axis : double 2 pixels and for the 3rd  pixel, you let it Undoubled, and repeat this for the rest of the rows,..  because  ( 2* 2 + 1) / ( 2 +1 ) = 1.67

At least It will be interesting to see how much that "stepping scaling"  is ugly/perceptible or not.

Playing with images is really fun (at least to me)! i am almost ready to update my XGA post too ;-)

Have a great weekend guys !

[Rob Holmes]

Thanks for the reply..... could have done with that last night ;)

You are exactly right. Originally i had my code running a bresnham scaling algorithm which tracked the error accumulator and doubled a pixle when the accumulator got over a certain value.... however i stayed up all last night and realised that in the case where i am Upscaling only, the entire formula/state machine can be reduced down to a simple conditional pretty much exactly what you have above.

As a 3.5in LCD cant quite fit all of its pixels in the console, i have to scale slighty off the maximum of the screen, not quite sure what my exact target will be as i havent tried it in the case yet but.....

scaling the source height from 144 lines to 236 lines (4 lines less than the scree has,  as the case obscures them)

Gives the following formula for the amount of times a pixel needs to be duplicated.

count(i)=⌊(i+1)×3659​⌋−⌊i×3659​⌋.

which reduces down to

(23 × i) mod 36 < 13.


so that ended up with

  if (((23 * i) % 36) < 13) begin
       // pixel i is output only once
 end else begin
      // Otherwise, it is output twice
end  

so about 400 lines of code less than before



Ive attached a video of it running, ive fixed the colors which i had inverted as well...


Next Steps:

• Black out the top/bottom/left/right borders where they wont be seen and currently display whatever happens to be in that SRAM location, (if i didnt have old data in there would be random fuzz)
• Slight issue with SRAM latency as im one read behind where i think it should be and ive probably violated the address setup times somewhere along the way.
• Support Sega Master System games, these have a different source resolution of  256x192, this shouldnt be too hard the process is the same and a few conditionals here and there should solve it.... really hoping i still have enough time in the 32mhz clock domain to do the processing.. fingers crossed.
• screen is slightly offset to the right, but i think that is down to the SRAM latency knocking my reads off slightly.
• Cleanup the icestudio project, as its been used and abused
  
  
  
• Remake the PCB so that it fits behind an LCD Panel
• Make the board more generic, so that its useful to anyone who wants an IPS screen and an FPGA paired together.... so increase the color depth from 12Bit to 24bit by wiring the rest of the LCD pins to the FPGA.
  
  
  
• Increase the SRAM size.... maybe.... to support larger screens e.g. 640x480 , 256k is only enough for 320x240, 512k would be need for 640x480..... although the price shoots up quite a bit..

[charli va]

Thank you very much Rob! for sharing your progress with us, it's amazing!

What ips display are you using? The PCB looks good.

I seem to understand that the PCB includes the fpga chip, sdram, spi flash and some level shifters. Could it be an interesting fpga board, aimed at graphics work, not just retrogramming, or is it a very closed design intended as a replacement for the gamegear?

Thanks again Rob and go ahead!🙌👏👏👏👏👏

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/283b67c8-8911-420f-a3b2-83ca7cc289f8n%40googlegroups.com.

[charli va]

Go Jomo, Go! 😉 graphics are awesome stuff!!!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/b1c921e1-d3ba-4099-943d-15f597bf3249n%40googlegroups.com.

[Rob Holmes]

Hi Charli,

Ive got quite a lot of samples ive ordered from china, but i think its this one 
https://www.alibaba.com/product-detail/3-5-high-resolution-640-480_1600458439669.html


Ive been working a new version of the PCB today, (working copy so there is no guarantee ive wired everything up correctly on this version. )

I would like to make it generic and useful for other projects.. as such i'm thinking of dropping all the VGA stuff, i dont need it anymore and would free up a bunch of IO so that i can up the LCD color depth to 16bit, will also free up some pins so i can reconnect the SRAM pins ive tied to ground.

The level shifters probably are not that much use to everyone though, but i need them so they obv have to stay.

There is no power supply on the board though....

So not sure how usefull/generic i can make it.

Ill be publishing everything at some point, code and PCB when im happy everything is passable.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCakphJMBcKMeERrYkwoNb2GxApNCFQ_A6%3DFW-Dwvp4k3Q%40mail.gmail.com.

[Iceflow]

Amazing work indeed! :D when you release the project i will do a couple of my gamegears with your pcb! opensource for the win! and maybe if it could be adapted, other consoles too!! yeah!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hZ5tzENaJ9sDOMLVMaWWyiZM93RBmMixdhKVttr%3DObEA%40mail.gmail.com.

[charli va]

Rob, take your time to publish, I understand you very well, I like to publish things when they reach the minimum quality I want, if not, I don't feel comfortable with it. Zero pressure, I only asked you out of curiosity and to find points of synergy with the projects I am doing in case we can "take advantage" of each other.

Just sharing your journey is amazing, thanks again.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBhZmE9xpkW9YuFGPaRmNkb1Xiw9m-wXDPAXxJOT%3Dw12-g%40mail.gmail.com.

[Jesus Arias]

Hi Rob, & congratulations

This schematic has many things in common with our "SIMRETRO" design ( if you want to take a look: http://www.ele.uva.es/~jesus/SIMRETRO/index.html)

There I'm using an R-2R DAC for the color components of the VGA video instead of weighted resistors, but the idea is basically the same. (The FPGA pins have about 25 ohms of series resistance if you want to fine tune the weights)

And with respect to the LCD panel I would recommend to connect the lower bits of the color components to the higher bits instead of GND:

R7_fpga to R7_lcd and R3_lcd,

R6_fpga to R6_lcd and R2_lcd,

R5_fpga to R5_lcd and R1_lcd,

R4_fpga to R4_lcd and R0_lcd

... and the same for Green and blue...

This will make use of the full signal range of the color components (6.6% more brightness)

Also, I think these panels also have a Data_Enable / Display_Enable (DE) signal that should be connected (It defines the visible segments of lines, HSYNC isn't enough)

And finally, I think it is a good idea to allow for the mounting of a ICE40HX4K FPGA, it has 7680 Logic cells (truly, not the ~3500 LCs Lattice says) and its pinout is "almost" the same as the ICE40HX1K, but not identical (different PLLs and a few other pins). In fact, the PCB could accommodate both types if some components are placed at the proper pins depending on the actual FPGA model mounted. (With that FPGA the whole Game Gear could be replicated  inside. A Z80 core takes about 2200 LCs  see some SIMRETRO examples at: http://www.ele.uva.es/~jesus ;)

Regards

[Jo mo]

Hola Jesus,

Thanks for the link to your projects main page!

it is full of incredible gems !  

And so well documented, ... Crazy stuff !!!

A special mention/award for what should be the most well written "technically/scientifically speaking" recipe of Tortilla! :-)

it is funny, because Carlos yesterday, by MP,  wrote a sentence suggesting that he could possibly supply me the recipe for a potato omelette :-))

Have a great day !

[charli va]

Jajaja I think that in Spain, potato omelette and patatas bravas arouse passions, and the most interesting (and delicious) thing is that no two are alike. At my grandmother's house, every Sunday without exception, they had potato omelette for dinner XD

On the other hand, emphasize that Jesus' projects are pure gold. It is wonderful to be able to count on Jesus in this forum. Thank you very much for sharing your time and knowledge with us ;)

With this project from Rob, I have taken out of the drawer a project that was abandoned there, it needs a little work but in the next few weeks I hope to be able to share it with you.

In fact JEsús, thank you very much for the screen trick, because with the LCD that I have running the colors look very poor and from what I have sensed from what you say, the problem may be due to the configuration of the pins, which is much more similar to Rob's than what you mentioned (and that is why I asked Rob about his screen, because I thought it looked relatively good), it may also be that the screen is really bad XD I'll tell you.

Nice day my friends!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/af83920c-e372-4551-b5d1-c4a16858a5e1n%40googlegroups.com.

[Rob Holmes]

Thankyou so much for the feedback Jesus, and the resources also :)

Its really helpful, and given me lots to amend / do this week...

Right now ive hit a bit of a "problem", i'm trying to create an "on screen display" for a menu system to control some settings., here is a screenshot of my test, which works but.....

Its consuming around 400 Luts, to the point i have no more to spare :(

Im obviously making bad choice about how to go about this, so was wondering if anyone has any experience with text display and have any tips?

What im doing now...

Ive defined some letters 8x16 pixels.

localparam char_p = 128'b00000000000000001111110001100110011001100110011001111100011000000110000001100000011000001111000000000000000000000000000000000000;
localparam char_i = 128'b00000000000000000011110000011000000110000001100000011000000110000001100000011000000110000011110000000000000000000000000000000000;
//localparam char_x = 128'b00000000000000001100001111000011011001100011110000011000000110000011110001100110110000111100001100000000000000000000000000000000;
localparam char_e = 128'b00000000000000001111111001100110011000100110100001111000011010000110000001100010011001101111111000000000000000000000000000000000;
localparam char_l = 128'b00000000000000001111000001100000011000000110000001100000011000000110000001100010011001101111111000000000000000000000000000000000;

localparam char_r = 128'b00000000000000001111110001100110011001100110011001111100011011000110011001100110011001101110011000000000000000000000000000000000;

localparam char_d = 128'b00000000000000001111100001101100011001100110011001100110011001100110011001100110011011001111100000000000000000000000000000000000;
localparam char_c = 128'b00000000000000000011110001100110110000101100000011000000110000001100000011000010011001100011110000000000000000000000000000000000;

localparam char_s = 128'b00000000000000000111110011000110110001100110000000111000000011000000011011000110110001100111110000000000000000000000000000000000;
localparam char_y = 128'b00000000000000001100001111000011110000110110011000111100000110000001100000011000000110000011110000000000000000000000000000000000;

localparam char_m = 128'b00000000000000001100001111100111111111111111111111011011110000111100001111000011110000111100001100000000000000000000000000000000;
localparam char_o = 128'b00000000000000000111110011000110110001101100011011000110110001101100011011000110110001100111110000000000000000000000000000000000;

I have a function which tests if the current x/y co-ordinate falls inside the letter

  function integer character;
    input [128:0] char;
    input [10:0] X;
    input [10:0] Y;
    input [10:0] XC;
    input [10:0] YC;
  //If current pixel is in the horizontal range of text
    if (
        (XC >= X) &&
        (XC < (X + 8)) &&
        (YC >= Y) &&
        (YC < (Y + 16))
   
    ) begin
      character = char[127-((XC-X) + ((YC - Y )*8))];
    end else begin
      character = 0;
    end
  endfunction

and for each X and Y co-ordinate as the screen runs im testing against that function and displaying white, or leaving it the original pixel otherwise..
       if (
                            character(char_d, 100,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_i, 108,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_s, 116,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_p, 124,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_l, 132,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_a, 140,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_y, 148,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_m, 166,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_o, 174,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_d, 182,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC]) ||
                            character(char_e, 190,180,ips_rgb_str_in[`XC],ips_rgb_str_in[`YC])
                           
                         ) begin
                          ips_rgb_str_out_reg[`RGB] <= 12'b111111111111;
                        end

I feel ive just created a terrible way of achieving my goal :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZBXAJoTGbykoNxC0Uoi%3D57pFiohPnWaxGLTdS%3DNJEqXQ%40mail.gmail.com.

[charli va]

Talking about Jesús projects, he share with us in this thread a vga text terminal:

https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/jSIN7BeOjWs/m/wRqrbjq2CAAJ

I implemented it in icestudio (bassically import Jesus code and little logic to could test). I don't have the .ice here because this week i'm out of home, but with the Jesús sources i think is enough if you want to use it, if you need it , the next weekend i could post it.

I'm attaching a video with this in action.

I think you should change the approach, that's my opinion, if I understand correctly how you are proposing it, it is too "hardcoded" and it will not scale well if you want to add a lot of texts or change them over time.

If you have closed options, i think the most optimal way could be literally have the menu drawn on the spi, if the menu is activated, you alternate the video source to the spi and do a "stream" during those memory addresses. You would simply need a memory address translator from the physical ones of the screen to those of the spi, this method can be very optimal because at the logic level it would involve very few fpga resources.

In other hand, if you need something more flexible, You would create an alphabet with the letters that you are going to use and that you can index (if you do not include all the ascii code to optimize space, you should create a lookuptable or something similar to correspond characters with memory areas where each character begins and if it fits in bram or spi, include all the ascii and so you can index by its own numerical code), since you are right now working with a very small fpga, the option of saving it in spi I think would be an option to explore.

In the example of JEsús you have a complete source if you want to use it.

Look at the code because there are very good tricks on how to index and paint the characters.

Depending on what you want to do, you might be interested in incorporating a small processor (which can be between 200-300 luts) very tailored for text, and that allows you to have flexibility in creating different menus, options... because it depends on the complexity of the menu, doing it in hardware will require quite a few resources that I don't know if you have! In this thread that Democrito started, we were discussing a possible architecture and you can get ideas, if you went this route.

https://groups.google.com/g/fpga-wars-explorando-el-lado-libre/c/BpvDRmLioS4

I hope some of this can be useful to you.

Good afternoon!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0itq_QG272tPj-Ef41s6s17%2B7w-08bXchhgL9X0-KiadQ%40mail.gmail.com.

[Jesus Arias]

Thanks for all the nice comments,

And, about the OSD I think it should be better to store the pixels on BRAMs (if you have some free) instead of logic cells. The main idea is to do the logic as if we where dealing with "TTL" chips and the like, so we will need:

- A memory for text storage (a DDRAM in the alphanumeric LCD jargon): 32 characters * 4 lines = 128 bytes (1 BRAM = 512 bytes)

- Another memory for the character pixels (a CGROM): 16 bytes/character * 96 codes (ASCII range: 32 to 127) = 1536 bytes (3 BRAMS)

- Some logic for DDRAM addressing (the XC and YC counters are already at hand) and pixel shifting, not too much.

I already have designed some of these OSD controllers, all of them with some sort of CPU (Z80, GUS16...) I think these PDFs could be interesting to you:

https://www.ele.uva.es/~jesus/SIMRETRO/ZX.pdf , section 5 Cassette tapes again, 5.2 Text mode video

https://www.ele.uva.es/~jesus/a2.pdf , section 6 A worm in the apple

And think about using a bigger FPGA... (Obijuan gave me the HX4K tip some time ago and it was a very good one, indeed ;)

Nice day

[Jesus Arias]

Hi,

Let me attach an example of OSD display. It fits in 2KB of RAM (4 BRAMS) and 107 Logic Cells

Here I'm using the memory to store both the ASCII codes to display (first 512 bytes) and the pixels for character generation.

The interfacing is just a write-only memory plus

- viden: OSD video enable. When active the video output of the OSD module has to be routed to the screen. Characters with ASCII codes under 32 deassert viden.

- video: The actual video signal, only 1 bit/pixel

- remark: The MSB of the character codes. It can be used for different video display (invert,...)

Regards

[Iceflow]

Nice improvement! :D great work!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/f1e1eb73-6504-463e-8d30-d4c9bca5cc37n%40googlegroups.com.

[charli va]

Thanks Jesús! it should very useful for this and other projects, i'm sure!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBiDONXgpPcs01mGNMWC2w_sVrR7u1xXPqg7Zf2OOEpv2A%40mail.gmail.com.

[Jesus Arias]

Hi again,

Let me attach another revision with little improvements and a video

[Jo mo]

Beautiful Jesus,

I will soon re-use your code to make an icestudio text block for my XGA experiments ;-)

Gracias and have a nice evening !

[Rob Holmes]

Hi all,

Work has been busy so haven't had much of a chance to work on this for the last couple of months :(

So i just started to get into it again and realized i "need" (or maybe just wanted) a logic analyzer, to get a better grasp of the signals i am working with instead of being fairly sure i know what i'm expecting.

A few weeks ago i was about to pull the trigger and buy a "Saleae Logic Pro 16", however just before i did i stumbled across this.....

https://github.com/gusmanb/logicanalyzer

 (which its highly probably everyone already knew about)

So, for $9.88 i orderd 5 boards from pcbway.
another $6 in parts
and another $6 for a rasberry pi pico 2

so for about $22 in total and after some good practice in hand soldering 0402 components.. ive ended up with this




giving me everything i needed and wanted :)




Open source has come to the rescue and saved me at least $1000 .

Anyhow, i'm so pleased i thought i would share!

[Democrito]

Everything looks great, and so does that analyzer. It was a nice touch to add the video to better understand the process.

Thanks so much for sharing all this!

[charli va]

Hi Rob! I'm so happy to continue seeing your progress. I'm sure this thread will inspire a lot of things based on everything you're teaching us.

Mr. Gusman's analyzer is amazing. I have one, and I can say it beats any analyzer of a similar price.

Plus, Mr. Gusman is not only a great technician, but also a great person. Any support or use of his software and hardware will surely continue to push him to create amazing things and share them with all of us.

Keep up the good work, Rob. Your project still sounds incredible.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/eb04c85e-9081-451c-bfc0-2f3a15c458acn%40googlegroups.com.

[Rob Holmes]

Hi All,

Been working on a new version of my board, incorporating some of  Jesus Arias' suggestions..

Main change is i've made it compatible with the HX1k and HX4k variants which was a great suggestion, however i have a question if anyone has experience of such things..

On my schematic the pins are noted as  HX1K (HX4K). i.e the HX4K pin name is in the brackets.

In the lattice chips, is NC really no connect, or is it a DO NOT CONNECT, vaguely remember being caught out in the past with another IC.

Points in question: 

1. VCC pin swaps, as the bank 2 VCC pins are in different locations between the two chip sizes, is there any problem with having VCC attached to an NC pin, which will occur regardless of ship size used?
Im trying to avoid having to add a zero ohm resistor footprint for each of them, but if im going to cause issues with the NC pins then ill have no choice.




2.  This scenario is probably not an issue as the 100 Ohm resistor can be removed from the unused chip version which isolates it.





3. This one worries me a little more as im running a "clock"ish signal into a NC, assuming it fine and doesnt introduce noise into the system .

in the HX1K it goes into the buffer as desired and I just ignore the fact its also on IOB_34, for the HX4K it goes into the buffer and the NC.



If anyone has any suggestions regarding the above, or can see if ive done anything really dumb in the attached schematic id love to hear it :) Its still a work in progress but getting closer to "done"

For once id like to get a board back that just works first time, instead of realizing the dumb thing i did the day after its been sent for production!!!!

Thanks as always, your feedback and support and encouragement is appreciated always.


oh and here is the pretty picture of the board, currently routed on 4 layers, SIGNAL/3V3/GND/SIGNAL but am considering dropping it to 2 layers if i can not breakup the ground planes too much in doing so.

[Rob Holmes]

Ok i think ive managed to answer my own question here...

Looking at the simretro board from Jesus a little closer i see he has the same for the PLLs


(although im curious about the PLL ground tied to the board ground, as the datasheet says " PLL GND – Ground. Dedicated pins. The sysCLOCK PLL has the DC ground connection made on the FPGA, so the external PLL ground connection (GNDPLL) must NOT be connected to the board’s ground.")


and the same for the differing power pins so thats cool.




Thanks Jesus, i should have looked at your example before asking :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/06b712fa-885b-4f07-8229-36fb8e354a4fn%40googlegroups.com.

[charli va]

Hi Rob!!! sorry for the delay i'm not view your message before.

I was going to recommend you look at Jesus sources that might be similar, I see you've already done that XD

Thanks so much for sharing your progress, Rob, it all sounds very promising.

Best of luck!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0j6PUpkPzbiQzaLN1E4LHd%2Bywxcc2O9%3DX8VXhGxf42YFg%40mail.gmail.com.

[Jesus Arias]

Hi, Rob

I'm affraid I'm a bit too late to answer, but anyway, looking at your schematic I found some details to remark:

- The 100ohm resistors in the PLL supplies are placed on the wrong side. The supply pins have to be directly connected to the capacitors.

- The HX4K has two PLLs. The supply of the second PLL must be also connected in order to use it: pins 126, 127

- Do not connect pin 50. It is a n.c. in the HX4K and it is also routed to pin 52 anyway. (Same for pin 58, n.c. in your schematic ;)

And with respect to the ground pins, all of them have to be connected together and I just routed them to a big ground plane on the bottom side of the board. It should be better to group the pins into domains (GND_io, GND_pll,...) and then connect all of them to a single point in an star-like topology. This would minimize the noise in the PLLs. (but the card with the simpler ground plane also have its PLLs running fine)

Have a nice day

[Rob Holmes]

  Hi Jesus, thankyou so much for your feedback, it is so appreciated you took the time to look for me :)

"The 100ohm resistors in the PLL supplies are placed on the wrong side. The supply pins have to be directly connected to the capacitors."

Ah yes! Well spotted, thankyou :)

"The HX4K has two PLLs. The supply of the second PLL must be also connected in order to use it: pins 126, 127"

Yeah i intentionally left that one out, as the HX1K didnt support 2  PLLs, but youre right i may as well have it available.

"Do not connect pin 50. It is a n.c. in the HX4K and it is also routed to pin 52 anyway."

I wanted this signal to be a buffer in both the HX1K and HX4K, but 52 is only a buffer in the hx4k version. SO if its connected to both pins its always on a buffer regardless of chip used.


Ive "borrowed" your method of bring in power via the corner from the corner of the chip and branching off from there, ive managed to get the board on 2 layers now with a largely uninterrupted ground place on the bottom layer. Its not quite as pretty layout wise as the SimRetro board as i didnt have room for a 45 degree chip :(




Again thanks for the review and assistance :)

Ive attached the latest version, everytime i come back to it i'm finding something ive missed or not thought about properly.. but im a software engineer so what do i know about hardware!!! So there is always the high possiblity ive done something collosally silly somewhere.  

At some point i just need to pull the trigger and fabricate it and see what happens.

[charli va]

Hi Rob!! thanks again for sharing your amazing work.

Looking at the design, I'm telling you things just in case they're useful to you or you think the review might be interesting. They're based on things I've done and problems I've encountered in my experience.

In a similar design I made, I had problems with the SRAM due to skew issues. More or less everything worked, but as soon as I increased the clock frequency a little or used PLLs, the data was inconsistent. This happened to me because the track lengths between the SRAM and the FPGA were noticeably different, a bit like what happens in your design, where some tracks are very short and others are longer. I solved it by rotating the FPGA 45º XD

I don't know if this is the case with the rotation of the simretro. I'm sure Jesús will tell us if it was a cosmetic issue, although I don't think so...

The tracks on the right seem too different in length compared to the ones on the left. This will cause you more or less problems depending on the speed, but I think if you gave it a try, you'd save yourself some headaches in the short term. As I said, it's a suggestion, your design may meet the limits of the memory datasheet and you won't need to rethink it. For low frequencies, the impact may be minimal, but from 25-30 MHz onwards, there could be desynchronizations. Even so, it's good practice to match the lengths to avoid future problems.

If you can't rotate the chip to find symmetry, you could try a trick that is to use "serpentine" or "zigzag" patterns to lengthen the shorter tracks and make them as long as the longer ones.

A rule I follow regarding lengths in this type of parallel bus interconnections between chips is that the difference between the longest and shortest traces should be at most 5-10%.

On the other hand, I also see these traces very close together, in dense areas. I don't know if you measured it or if it was just a guess based on how they fit. This may be excessive for this board, but it's somewhat the same depending on the speed. Crosstalk could occur if they were very close together and the impedance wasn't calculated correctly (due to the width of the trace).

I'm telling you all this about SRAM because it's a critical point, and when there are asynchronisms, debugging is a real challenge.

The same thing happens with the display. The RGB connector pins (R0-R5, G0-G5, B0-B5, etc.) also seem to have unequal lengths. This can cause timing issues on the display, such as misaligned colors or flickering.

Try to keep the difference between the trace lengths to less than 5 mm (at 25 MHz, the propagation speed on a PCB is approximately 150 mm/ns, so 5 mm equals ~33 ps of phase shift, which is usually acceptable).

I was involved in the design of a kind of micro console with an FPGA, and this error, along with the very long video clk track, caused a lot of jitter.

And talking about  the CLK connection point of the screen, it is very close to the SMS line, I would try to separate it and it seems that you have space, this is already a personal issue, the clock line for the screen should be as clean and short as possible to avoid jitter and flickering.

And then the display's CLK connection point. It's very close to the hsync line. I'd try separating it, and it seems you have room. This is a personal OCD issue. The clock line for the display should be as clean and short as possible to avoid jitter.

Regarding this, I'd try to connect the GND between 5V and CLK. It might be excessive, and I see you've inserted a small GND island as a shield between the 5V and the display's CLK. But if you can swap that pin to move it a little further away, I think it might be a good idea.

As I said, these are tips based on problems I've had, but each project is unique. I've seen designs for Chinese consoles that make you think, "How can this work?" But it does. XD (your design is much better!)

Depending on the maximum frequency, possibly up to 20-25 MHz , you may not have problems, but beyond that, if you don't balance the trace lengths of the parallel interfaces, I think you could have problems.

In any case, it's a great job Rob and you can always pull the trigger, get the pcbs delivered and try the first version ;)... It's always an exciting moment!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/dd27ac64-d834-48a3-ae9a-75c86ab1281dn%40googlegroups.com.

[Rob Holmes]

Hi Charli, i really appreciate this more than i can say.

Im currently running the SRAM at 32Mhz, but im not willing to risk it, as ive got enough issues debugging my verilog lol

I will take everything on board and go for a redesign.... ive got around 7 hours left of today... see what i can get done :)

Ive just taken a look at the modified olimex iCE40HX1K-EVB board ive been using up until now and it looks like they have length matched the SRAM traces, i was so happy to get it all to fit on 2 layers that i was blind to everything else.

Thanks again

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCYeRRZ5cqfjORH0MpadWN1F_uECaFvoVfUcSFnPOQ7EuQ%40mail.gmail.com.

[charli va]

Take it easy! As I mentioned, these are suggestions, maybe the 32MHz design will work fine and you don't have to worry about anything else. What I suggested is more, if the board looks interesting and could have more projection, and in the end, you can implement faster designs at a given time, so you can avoid headaches XD

I do find it very interesting that you try to fine-tune the display bus part,almos. Often, the same design with the same display looks much better than another simply because these silly things are tied up properly.

Keep up your spirits and keep us updated.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hnqpRwRytrMfqWS-VOg20rn2vD0Xr-%3Dzfmkv%2BN4-CQTw%40mail.gmail.com.

[Rob Holmes]

  Hi Charli,

Before i consider a redesign, ive been keeping all the address lines on the same IO bank as each other and all the data pins together on another IO bank. Ironically to avoid any latency between them, but is this actually a concern? or could (if i was so inclined) split the address pins across two IO banks without causing any issues. 

" I do find it very interesting that you try to fine-tune the display bus part,almos. Often, the same design with the same display looks much better than another simply because these silly things are tied up properly."

I think you are giving me undue credit here, i have just left them in a mess so it looks like i tried to tune it :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCacKERCCcAV%2BiMxnLEq5tHogPsBfWDMm-xV%3Db2kTUP9Fg%40mail.gmail.com.

[charli va]

Hi Rob! Sorry for getting you into this mess XD

Consider whether, with the design you already have without touching anything, you can "tune" the track lengths by making them snake. It might be the most straightforward option.

For both the SRAM and the display, I advise keeping the buses on the same bank as much as possible. Separating them wouldn't be critical, but it's not ideal.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0gcmrRr9i81bJKSTGfUV8U4ttn-wD%3Dcz6z0zE2zc3atMg%40mail.gmail.com.

[Rob Holmes]

No mess at all, my project is about me learning to do something ive never done before.

Ive deleted the verilog code many times over and started again as ive learnt new things and new approaches and more importantly understood more.

Ultimately as well as something that works i want something im proud of, that said I might fabricate the current board, and while i wait work on a new version :)

Regards,
Rob.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCaBfasZixd36zrL2Zj7a%2BjgrAeTzw_3LKq7%3Dydz%3Da2ELQ%40mail.gmail.com.

[Jesus Arias]

Hi

About the trace length mismatch, the speed of signals is roughly half the speed of light. That means 1 nanosecond equals 15cm of trace length.

And for a 33MHz clock a bit last 30ns, so, a 15cm length mismatch is a signal skew of just 1/30 of a bit time.

Of course, it is a good idea to keep the traces short and lengths more or less equal, but I don't think there is any problem for these frequencies.

Good night

[charli va]

Take Jesus' advice, and if the board is going to be dedicated to this task and the maximum speeds are going to be around 30MHz, don't worry about it. You've already done a great job.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/6d296971-beda-4a03-a5f3-24a084dc33dfn%40googlegroups.com.

[Rob Holmes]

Hi all,

Thankyou all again for the advice... I actually length matched all the traces to SRAM in the end, couldnt hurt.

Also switched to a 4 layer board, made me happier having a dedicated ground and power planes and to be fair the cost really isnt much different.

Board and stencil arrived TODAY :) Still waiting on a few parts from LCSC though.

However, its at this point i start to regret the 0402 packages :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCbVxpSKomfK480zGaxz%2ByKTo9chvye-MR6YCaHkLMZDHA%40mail.gmail.com.

[charli va]

Hi rob!! Looks  so cute!! Congratulations for this first big step!!

[Iceflow]

The board looks amazing! :D waiting to see if all goes well! great work!

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZGSD_PyEWGkBLadb4H2yqU%2BWrmaNqEObwn7V%2BGMV96nQ%40mail.gmail.com.

[Rob Holmes]

Parts arrived today..... took forever to solder this up... 0402s kill me. Looks pretty good as long as you dont zoom in too much!!! 

No idea if its working but at least i have 5v, 3.3v and 1.2v present and no magic smoke which is a good start :)

Fingers crossed for tomorrow!
 

[Alexander Lang]

Well done Rob,

Surface mount soldering without a reflow oven or hot plate is very difficult.

If you have correct voltage and no smoke you are half way there 😁

Alex

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hcPb8cu2SmV9CX3N9JnuyXYaLm9UuQeEj6pnZztxSGAA%40mail.gmail.com.

[charli va]

Looks amazing, Rob! I can't wait for your first tests. Tell us about the process; these kinds of experiences are always very enriching.

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hcPb8cu2SmV9CX3N9JnuyXYaLm9UuQeEj6pnZztxSGAA%40mail.gmail.com.

[Iceflow]

Looks good! :D

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0hcPb8cu2SmV9CX3N9JnuyXYaLm9UuQeEj6pnZztxSGAA%40mail.gmail.com.

[charli va]

Hi Rob! Purely by chance, while cleaning out the attic of one of my cousins' houses in the village, I found this Game Gear from when he was little.

It's completely broken. I think it broke. After searching online, he tried replacing the capacitors, but I actually think it made the situation worse. The casing is broken and has no screws, and the inside is pretty bad (burned traces, missing components, etc.).

But I'm going to try to fix it. It all depends on whether there are any fried key ICs.

For me, it's an important memory to preserve, and if I manage to get it working, I'll be able to try your work, which I find very interesting.

This is something I'll do occasionally. It will take time, but I was excited to have found it, given your project is underway.

Good afternoon!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBhJovjhf6dSYf%2B%3D%3DaH1A8zmdA5iVrZ5_UzdnUKnD0OvAw%40mail.gmail.com.

[Rob Holmes]

Thats awesome, 

Ive actually just finished reverse engineering the VA1 version (there are 3).

Ill push this up to github in the next few days, once ive done a bit of cleanup, might help fix any broken traces if you have any.
On the VA1 version, the one with the single ASIC chip, thats the only proprietary chip on there. The other common version has 2 Asics and a Z80 CPU, which i have almost finished as well....







Ive spent more time than id like to admit making the 3d Models of the components lol

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCZDRFo9YMnEZA2gU%2BjEp1XauFC%2BE1KX0BsZDMix5%3De9zA%40mail.gmail.com.

[charli va]

Woo Rob!! that's awesome!! 👏👏👏👏👏👏👏👏👏

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jJZy6p%2Bbj%2BC_2yiYULF4j4YrZ_Bnf_fxTH2oy2r6U2pg%40mail.gmail.com.

[Iceflow]

Amazing work! there were other reverse engineering projects but none of them were open in the end :( this would help a lot in repairing this old consoles! :D

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0jJZy6p%2Bbj%2BC_2yiYULF4j4YrZ_Bnf_fxTH2oy2r6U2pg%40mail.gmail.com.

[Rob Holmes]

Hi All,

Been crazy busy at work and havent had any time at all for months, so hadnt even tested the board..

As well as time, ill openly admit ive been putting it off as if it didnt work id have to start over which would be depressing...

However i can present to you the least impressive FPGA board demo ever.

The LED light

  assign LED = 1;



While not impressive, cant tell you how over the moon i am that it actually programmed.

Now i can on with  porting the code to my fancy dedicated board :) WHich for at least some part works :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAHN3uBivgT8xx%2BW35zRHEz2_VN1SqcOAnyaRYm%2BqYePNUDYOow%40mail.gmail.com.

[charli va]

Congratulations!! Where there are LEDs, there's joy! :)

I'll soon publish a project that includes several on-the-fly filters with the FPGA (upscalers, downscalers, smoothing). They might be useful.

Looking forward to seeing your progress :)

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAGYOE0h6mb9SiLZpq8EcDexP%2B6JUavy-ipAybj1GtrnnxtGoxQ%40mail.gmail.com.

[Rob Holmes]

August Update:

The board Works (against all odds) lol


I learnt something important though (which everyone else probably knew but me).... not all LCD screen drivers are plug an play.

320x240 LCDs using the  ST7272A driver IC you can just throw hsync and vsync at them along with RGB data and you are good to go.....

However after struggling to get a 640x480 LCD running with no joy, it turns out that a series of setup commands are 100% required prior to usage otherwise you get a black screen. This is a problem because well.... 


i didnt connect the SPI lines.

Im not 100% sure how to connect these, my first instinct is to put footprints for a inline (100ohm)? resistor for SPDA, SPCK and SEKB, and a 10k pullup on the reset line (which is active low according to the datasheet which is sparse on details)

Either way i need a new board revision if i want 640x480 which i do as i think scaling artifacts (line doubling) will less noticeable with denser pixels.

Next steps:

Get a new board fabricated
Split code out into smaller modules and write some testbenches as currently im running on hopes and dreams :)
Publish to github

On Thursday, 7 August 2025 at 09:25:48 UTC+1 Rob Holmes wrote:

August Update:

The board Works (against all odds) lol



I learnt something important though (which everyone else probably knew but me).... not all LCD screen drivers are plug an play.

320x240 LCDs using the  ST7272A driver IC you can just throw hsync and vsync at them along with RGB data and you are good to go.....

However after struggling to get a 640x480 LCD running with no joy, it turns out that a series of setup commands are 100% required prior to usage otherwise you get a black screen. This is a problem because well.... 


i didnt connect the SPI lines.

Im not 100% sure how to connect these, my first instinct is to put footprints for a inline (100ohm)? resistor for SPDA, SPCK and SEKB, and a 10k pullup on the reset line (which is active low according to the datasheet which is sparse on details)

Either way i need a new board revision if i want 640x480 which i do as i think scaling artifacts (line doubling) will less noticeable with denser pixels.

Next steps:

Get a new board fabricated
Split code out into smaller modules and write some testbenches as currently im running on hopes and dreams :)
Publish to github