Having done a couple of FPGA video format conversions, I thought I'd contribute a few ideas. Unlike nctnico or BrianHG, I'm not going to give OP a solution, but rather a few points to consider:
1) Have you clearly defined the input and output of the design, and other constrains?
For the input, you would need to get to the bottom of it, measure the pixel clock frequency and all the timing parameters in the unit of pixel clock (horizontal total, active, sync width, front and rear porch, and the same for vertical).
For the output, you need to know your goal. Is it an analog, industrial-standard VGA-compliant output, or something acceptable by a PC monitor, or a digital video signal acceptable by an LCD panel? They are three quite different goals, although they overlap in certain areas.
In terms of other constrains, would you mind tapping into the pixel clock in the original video circuit, and perhaps the digital signals that generate the analog video via a video DAC or resistor network, or you are strictly limited to the signals available on the interface cable?
What about power and mechanical constrains, such as, do you plan to install an LCD panel in the original unit replacing the CRT? If so, the output format will be further limited by the resolution and size of available LCD panels.
2) The solution depends on what you have, and what you want to do.
For example, if you have access to the original pixel clock, things can be much easier. Do the math, and you'll find out if you can convert the original pixel clock into the new video format pixel clock using the PLL or DCM in an FPGA - they often have limited M, N and reference frequency range. If you maintain the exact frame rate, you can live without a frame buffer. How many line buffers you need depends on the vertical active-to-total ratio of the input vs output formats. Draw diagrams of input and output video format in 2D and compare them side by side, and you'll understand what I meant.
If you don't have access to the original pixel clock, you would need a PLL to recreate the pixel clock in order to sample the video signal properly. Not just any PLL, a PLL with KHz reference input and multiplication factor in the hundreds to the thousands. There are dedicated IC for that purpose, and fortunately Video ADCs often come with one built-in.
Do you really need a Video ADC, aside from the built-in PLL? You don't if you have access to the digital video signals in the original circuit, or if the original video has very few intensity levels (let's say 8 or less). By the way, using an ADC does not prevent you from doing grey scale to color mapping.
3) Don't let the recipe limit your creativity.
Both nctnico and BrianHG's solutions have their merits. You don't have to take one and drop the other. Instead, understand your requirement and take the parts from their solutions that meet your needs. For example, MAX10 seems nice, even if you don't use a Video ADC. On the other hand, there are plenty of open-source soft-core CPUs that you can integrate into an FPGA to do housekeeping things such as configuring a Video ADC via I2C.
Line doubling works. True. But does the line-doubled video exactly what you wanted from the beginning? How much off is it from the industrial-standard VGA? What will the picture look like on an LCD panel installed in the original chassis, if that's your goal? If you need more than the most basic image scaling, there are at least 20 different algorithms, and someone developed a program that allows you to compare them side-by-side.
My point is, a lot of planning can be done on the drawing board before you jump in and start writing RTL or drawing schematics.
Hope that helps your learning experience, and good luck