Amiga VSC

Amiga Video Scan Converter

This project is one that I’ve wanted to do for some time.  The Commodore Amiga 500 has a few different graphic video modes, but the first one I want to deal with is the 320×200 mode. The output has a horizontal refresh frequency of 15.7khz.  These are the two problems that need to be solved, modern LCDs don’t like such a low resolution, and they won’t sync below around 30khz.

If you use simply the output from the DB23 video connector on the back of the amiga, the data is an analog output.  It has 0v-0.7v peak to peak on three different colors Red, Green, and Blue.  The pixel clock is based on the 7.14mhz clock for 320 horizontal resolutions, and twice that for 640x rez.  Now if you want to scan convert this, you’ve got to use an A->D converter which is reasonably fast, and has reasonable resolution because the original data is 4-bits per color.

But finding a hobbyist friendly(in a reasonable package, not many external components required, no programming/registers to setup, supports the freq and resolution required) ADC that can handle this is tough. I couldn’t find any that fit the bill without a gotcha.

Denise, the amiga video chip, has digital video connections that are easily tapped into, and will give me the clearest possible video.  There is no loss with a digital output in comparison to the analog which occurs from the amiga’s D->A and subsequent the A->D.

So I’m going to run from Denise, into a logic level board (to convert 5v TTL to 3.3V for the FPGA), into the Altera DE0 board, and then the VGA cable will connect directly to the monitor.

There are basically three steps that need done:

  1. Capture the amiga video signals.
  2. Resize/convert the video frame.
  3. Redisplay the frame at a new resolution and horiz frequency.

I have to convert the 320×200 in 640×400, and I want to keep it as simple as possible — but don’t want quality to completely go out of the window.  I can simply double each pixel horizontally, and double each line vertically, but I don’t think this is the best way.

There are some better techniques, like nearest neighbor, bicubic, and so on —- but these all sound pretty intimidating with someone who isn’t so great with math — and haven’t seen these things in the “wild” before.

What do you think? Do you have experience with this type of stuff?

Blog posts, including pictures and video on this project available by clicking here!

Current Status 1/17/2012: All hardware including cables/connectors, and the protoboard for voltage conversion from Amiga 5v to FPGA 3.3v is finished. The amiga is connected to the hardware and I have some video conversion happening. There’s no more vertical scrolling happening, no more black bars, image is stable and looks pretty good, but there are still video artifacts.  See pictures in the blog posts accessible by the link above this paragraph.

Next steps:  Got to find out where the video artifacts are coming from. See the blog posts for a better description and video of the problem.



Leave a comment
  • Cool project!

    If your source image is 320×200, then a simple pixel doubling to 640×400 will be most faithful to the original. The filtering methods you mentioned are more appropriate for non-power-of-2 scaling or down scaling.

  • Thanks for the message, Steve!

    I was going to do some playing around in photoshop and try the different scaling methods, and see which yielded the best result.

    Hopefully, I would have come to same conclusion.

    I’m glad to hear that simple pixel doubling will do the best job. When I inspected nearest neighbor, you need to be able to access the entire framebuffer pixel for pixel(access the previous lines contents, for instance) — which I can’t given my current design.

    (btw, a friend who generally knows this stuff had said SPD would result in crappy video, which sent me down this path)

    I start at a memory address, and then load one horizontal line of color data from the DRAM into a line buffer, which is in essence a 2-port altsyncram. It’s very nice in that I can write into the memory at one speed(100mhz, main design clock), and read at different speed (25mhz pixel clock)

    BMOW is awesome, I’m adding a link to you now!


  • Hmmm.
    I’m remembering of the Scale2x algorithm used in MAME for resolution doubling, employing only an intelligent way to choose the colors for the added pixels. It just uses 5 pixels to generate 4 news, and so far it works quite well. Of course the image is cosmetically good, but different than the original… But maybe it’s good for your application, and it doesn’t require any FIR filtering, multipliers, etc.

  • Thanks for the comment.

    Did you happen to see my post here?

    I found Scale2x and it definitely looks interesting.

    For phase I, I’m going to go straight pixel doubling because there are a lot of other issues to deal with. I’ll go to something like scale2x as an option in the next phase…..


  • Steve said it best, scan doubling is the best solution for increasing the resolution faithfully.
    This has as technical drawback that your required to hold the line in memory this is what the Amiga 3000 did.
    And you could use the flanks of the clock to doule the frequency, BTW some FPGA’s don’t like a low operating frequency nowadays…

    • Hey man!

      I got this project mostly working, and it was relatively error free. It wasn’t perfect but as I got closer to finishing, I lost interest. IIRC, someone pointed out at that I needed to use the strobe happening over the bus to properly synchronize it, but this was very different from what I was doing, and so I lost interest.

      Maybe I’ll revisit it sometime, if I can find the time!

      I’ll definitely check out your version. Your HD project is really very cool, so I have high hopes for this too!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>