Skip to content

Latest commit

 

History

History
17 lines (13 loc) · 4.17 KB

0042-2020-07-14.md

File metadata and controls

17 lines (13 loc) · 4.17 KB

14 Jul 2020

Commits on t08f aim to show progression from a primitive VGA generator, to game logic, to optimisation.

Commits so far are:

  • 2020c1c: "Green fill generator". Fills the screen with green, using VGA timing pretty close to what it should be for 640x480, from a 50MHz clock.
  • aee5565: "Now using parameters; output core is the same". Does the same as above, but with magic numbers converted to useful parameters. Produces exactly the same .xsvf file.
  • e365df3: "Added T, R, B walls". Instead of solid green fill, draws solid "walls" at top, right, and bottom. Not left, because that's where we'll put the paddle.
  • 14c3f1f: "Basic paddle motion". Now we render the paddle on the left, and it can be moved up and down with pushbuttons. Motion is slow (i.e. too fine), and paddle is half the width of what I had planned (because I forgot I'm using a 50MHz pixel clock instead of 25MHz).
  • 15f06ea: "Fix paddle width, double its speed, and give it an initial value". Paddle is now 32 pixels wide (same as walls), moves twice as fast in response to buttons, and we're using an initial block to set an initial value for the paddle position (i.e. setting it to 32, so it doesn't start embedded in the wall). The initial block can be synthesized for this particular CPLD.
  • 386b79d: "Added a ball, but it doesn't move yet". Ball (with initial position X=35, Y=50) is 16x16 pixels.
  • d4b5076: "Trying to add ball motion but design doesn't fit now". Simple increment of ballX and ballY at the end of each frame, trying to make it move, but the design doesn't fit. Even if it did, I forgot that ballX needs to be incremented by 2 each frame, instead of 1, due to 50MHz clock. I changed multiple parameters for the synthesis and fitter, and kept these in the project, but to no avail.
  • b1a1dd7: "Speed up the ball and hence use less-precise tests to get a fit". Some simple optimisation: each frame, the ball moves by 2px on both X and Y, so we can get away with counters with 1 bit fewer, which in turn means comparators can be shorter, hence allowing the design to fit. Since everything is being compared now with effectively double-sized pixels, the ball width and height are adjusted to 8, which still equates to 16x16 pixels. The ball moves, but drifts off screen, wraps around, creates some artefacts...
  • 01fe8e2: "Ball now bounces around. Doesn't yet interact with paddle". Ball X and Y direction flags now define whether each axis increments or decrements per frame, and those flags update when the ball has intersected with any of the walls. At the moment, the paddle is ignored: The left-hand edge of the screen is treated as a full wall.

I made a script, f.sh, which can be used to try a "breadth first" search for a fitting solution. By default, it will try using 54 inputs for each of the 90..1 pterms combinations with cpldfit. If it finds a fit, it will build the .jed file.