Friday, November 21, 2014

Working on the anti-aliaser

I finally got around to plumbing the alpha-blender together to begin testing it for use with anti-aliasing text.

Not surprisingly, there are some things that aren't quite right. Primarily, Xilinx's reference implementation of an alpha blender doesn't quite seem up to the 192MHz pixel clock.  In particular, the blue channel is failing to meet timing closure, and seems to be delayed by a few pixels, as can be seen in the screen shots here:  


The displacement is a fixed number of physical pixels, as can be seen if I change the horizontal scaling of the text generator:



The timing failure isn't too surprising, given that the alpha blender uses a double-clock rate to multiplex the DSP operations to save a bit of silicon.  However, it means that the blender is effectively running at 192MHz x 2 = 384MHz. 

I think I will have to modify the blender so that it doesn't need to multiplex DSP blocks, and can hopefully then meet timing, and avoid the colour planes separating like this.

6 comments:

  1. Paul,
    Maybe I misunderstood... This is the VIC-IV, right? So, ultimately the VIC-IV and the C65 will run C64 programs rather than having to put the system in "C64 mode" (unlike the C128 that wasn't really compatible with the C64, having only a separate mode, presumably a complete C64 built in?)

    Thanks.

    Kevin

    ReplyDelete
    Replies
    1. Yes, this is the VIC-IV. The C65 (and my C65GS) make all hardware improvements available from C64 mode, which as you note is in contrast to the C128 that tried to hide everything from C64 mode, and didn't offer access to any combined mode. Of course, for C64 compatibility, the C65 disables a number of things from the C64 memory map, but there is a register-knock that turns them all back on (search for $D02F and C65 for details). I use the same register to allow selection between C64-only, C64+C65 or C64+C65+C65GS features being visible in the memory map. It will also be possible for the hypervisor to restrict/modify this behaviour.

      Delete
  2. Paul,

    It seems strange that you are having problems with the timing at approx. 384MHz when the tech. specs. for the Nexys4 say that it should operate at speeds "exceeding 450MHz". Are there other issues like delays in setting up the DSPs?


    Daniel.

    ReplyDelete
    Replies
    1. "exceeding 450MHz" is marketing speak for the clock speed you can obtain when implementing a NOT gate that feeds into itself, or other similar trivial circuits. In reality, the routing delays often dwarf the processing time, and so getting close to their 450MHz with a design occupying a reasonable fraction of the FPGA is very hard.

      Paul.

      Delete
  3. Alan Cox has just released a UNIX-like kernel for 8 bits, maybe you were already aware of it?

    https://plus.google.com/+AlanCoxLinux/posts/a2jAP7Pz1gj

    Lots of noise about the Z80 being better than the 6502 for this kernel, but I imagine you could address all these critiques with your system.

    ReplyDelete
    Replies
    1. Thanks -- I'll take a look. Any 65CE02 would be much better than a 6502 for this kind of thing I suspect.

      Paul.

      Delete