Skip to content

Latest commit

 

History

History
131 lines (113 loc) · 6.28 KB

0121-2023-07-26.md

File metadata and controls

131 lines (113 loc) · 6.28 KB

26 Jul 2023

Previous journal: Next journal:
0120-2023-07-24.md 0122-2023-07-27.md

Setting up tt04-solo-squash to use solo_squash submodule

  • Created submodule branch: git checkout -b submodule
  • Add submodule: git submodule add [email protected]:algofoogle/solo_squash src/solo_squash
  • Should top.v be part of solo_squash or remain in tt04-solo-squash? Probably keep in tt04-solo-squash because it is specific to that project/repo's needs.
  • Load top.v first, so it can set any `defines that it wants to.
  • Matched reset polarity.
  • Pushed solo_squash repo changes.
  • After tiny corrections, the GHAs work now with the solo_squash submodule. GDS builds fine.

Windows sync speed estimation

Verilator clock estimation was wrong on Windows:

Starting simulation in 3... 2... 1... Cold start...
Main loop...
[H,V,F= 751,  33, 3] Horizontal auto-adjust to 48 after HSYNC
[H,V,F= 751,  33, 3] Vertical frame auto-shift to 33 after VSYNC
Current FPS: 47.90 - Total average FPS: 47.90 - m_tickcount=  0,019,713,600 (  0,002,528,673 Hz;  10% of target)
Current FPS: 50.65 - Total average FPS: 49.20 - m_tickcount=  0,041,133,600 (  0,004,210,656 Hz;  16% of target)
...
Current FPS: 50.80 - Total average FPS: 49.74 - m_tickcount=  0,188,973,600 (  0,004,223,237 Hz;  16% of target)
Current FPS: 51.03 - Total average FPS: 49.86 - m_tickcount=  0,210,813,600 (  0,000,358,354 Hz;   1% of target)
Current FPS: 49.26 - Total average FPS: 49.80 - m_tickcount=  0,231,813,600 (  0,003,763,675 Hz;  15% of target)
Done at 322953600 ticks.

50fps is much better than 15% of target performance, and that 1% figure is way off.

It turned out to be a weird error that I had to work around where somewhere along the line what should've been a 64-bit long was being truncated to 32 bits, but only when compiled for Windows. Maybe a bug related to MinGW?

Next steps

  • Update READMEs
  • Need instructions on how to:
    • Clone/pull submodule, inc. updates to it
    • Update submodule commit/tag reference
  • TOP module simulation: Need to implement a way to simulate the tt04-solo-squash top module (say, with Verilator), so that we can make sure its behaviours seems right with the extra metastability avoidance stuff we've got in there (i.e. input_sync) and the wiring of other debug signals.
  • Do gate-level simulation.
  • Implement different output modes with a way to select:
    • RGB111: It does this currently.
    • RGB222 with temporal ordered dither (to use just 3 outputs).
    • RGB222 without speaker (to use 6 outputs).

Overall design plan for tt04-solo-squash submission

Here's my spec for tt04-solo-squash:

  • Remove LZC.
  • Ideally the game should support free-running so long as it gets reset. This means still supporting up/down keys by default.
  • Control via SPI (3 inputs needed, unless we can work without SS).
    • Buffered until a frame is ready to load the data.
    • Can set the paddle position directly.
    • Optionally could set paddle size, ball size, and ball motion.
    • Optionally can set/reset pause mode?
    • Optionally could select between registered and direct outputs?
  • Other inputs:
    • Pause.
    • New Game.
    • Down/Up will still increment/decrement paddle position once per frame, even if set via SPI.
  • Outputs:
    • HSYNC
    • VSYNC
    • R, G, B
    • Speaker
  • Debug ports?
  • READING some info via SPI MISO?
  • VBLANK IRQ?
  • Should we try having a mode that can read from an external memory and display it on screen, with a configurable divider for different pixel widths? As an experiment, we could make this one of:
    • A "sprite" for the ball.
    • A repeating pattern for the background, either 1-bit or RGB222? For example, we could use 6 ROM bits to provide RGB222 colours, with 4 of those bits via dedicated inputs, and the other 2 via bidirs, then use the remaining 6 bidirs as ROM address (64 pixels, which could be arranged, say, as 8x8 pixels). WAIT: NO GOOD. If we do this, we have no inputs left for SPI.
    • A pattern for the walls?
    • Some other overlay/logo/text or whatever.
  • Other ideas:
    • Is there a way to give this a score? Based on time between misses, or maybe counting bounces?
    • Multiple designs in one, selectable via SPI.
    • Ability to configure patterns via registers that turn on/off certain bitwise logic combos.
    • Controlling VGA timing via SPI?

Notes

  • config.tcl from tt04-submission-template has some interesting stuff in it.
  • It sets the target clock speed to 50MHz (20ns period). For me, this could be an issue if I only need a 25MHz clock for VGA, and my design is sophisticated enough that it can't get above this due to propagation delays on all my heavy combo logic.
  • Other TT04 ideas:
    • General VGA device:
      • Optional SPI control.
      • Configurable timing.
      • Experiments in un/registered outputs.
      • Experiments in reading external memory.
      • Route inputs to various VGA outputs, while blanking them via visible gate.
      • Trying out minimal "framebuffer" using a small number of DFFs or DFFRAM?
      • Modes to try out other VGA "games" and tests.
      • Delta-based bit packing of raycaster column heights, e.g. we could assume most inter-column height deltas will fit within 4 bits (+/- 8 height steps), and a counter could be used to specify how many "regular" columns there are before a break that exceeds this 4-bit range. We could assume that there won't ever be more than 32 "extreme" columns, so: 32x4bits for counters + 32x6bits for extreme (reset) values + 128x4bits for steps. This is 832 bits for 160x120 (not inc. 'side') which would normally take 160x6 (960 bits), but I'm sure we could do better.
      • How efficient would it be to RLE column heights, even?? Hmm, a single 45-degree wall angle would be enough to bust it.