Friday 24 January 2014

Some screen shots

This is a hastily prepared post with a few screen shots of the C65GS display just to give you an idea of what I am working on.

The C65GS drives 1920x1200 @ 60Hz natively, with 1248 physical rasters for PAL compatibility.

By default hardware scaling of the character generator is set at 5x to render a normal 320x200 display within the borders ($D042 = $04, $D043 = $04).  Of course, the rasters are still physical, so an INC $D020, JMP *-3 loop produces very fine rasters, as you can see in the following image.

Sorry for the blur, my phone camera is not the best for this sort of thing, and I don't have a better way to capture the display yet.

You can also see that I still have at least one CPU bug that prevents 38911 from being printed correctly.  Looking into that.

The next image shows the detail near the ready prompt to give an idea of just how fine the rasters are.  You can also see that $D020 can be incremented quite fast in relation to the pixel clock, each colour band being only about 3 characters wide.  The pixel to CPU clock ratio is currently 2:1, instead of 8:1 on the C64.  In fact, it is possible to make them even narrower in future when I improve the IPC of the CPU (removing dead cycles from INC etc when not writing to locations that really matter, like $D019, and using the 64bit wide chipram bus to fetch entire instructions in a single cycle.

The next two images show the character generator set to physical resolution ($D042 = $00, $D043 = $00). There is a bug that is apparent in these images, where the character generator draws the characters at physical resolution, but doesn't fetch the character number from screen ram properly, resulting the same character being repeated three times each.  This is fairly high on my list of things to fix.

Also in this mode you can see that the character generator doesn't naively increment the pointer to screen memory when moving to the next line.  Instead there is a virtual screen width register that decides how much to increment each line.  In this example it is still set to 40 for 40-column mode, hence the repeating.

In the lower part of the screen you can see some odd things, like underlined characters.  These are characters with C65-compatibility VIC-III extended attributes of underline, reverse, bold and blink.

Again, a zoomed in view of the cornerwhere you get an idea of how teeny tiny these characters are.  Even at this physical resolution the rasters aren't too wide.

Anyway, that's it for this sneak peak.  I'll explain more about the machine in a future post.


  1. Paul, this is amazing looking forward to seeing where this goes. Maybe you'll even bring it to a local demoscene event?

    1. I am sure it will turn up at a demoscene event somewhere when it is a bit more complete.

  2. Would it be run-able on something like Turbo Chameleon? Gives me an excuse to get one when they're available again.

    1. Unlikely. I purposely selected a board with a very large and fast FPGA. The Artix7, for example, has 512KB of internal block RAM, which is what the CPU and VIC-IV use (some of) as main memory. The Turbo Chameleon is nice, though.