Skip to content

Latest commit

 

History

History
38 lines (24 loc) · 2.44 KB

0134-2023-08-27.md

File metadata and controls

38 lines (24 loc) · 2.44 KB
Raw

27 Aug 2023

Previous journal: Next journal:
0133-2023-08-26.md 0135-2023-08-28.md

raybox-zero

SPI access to pov

The pov module provides Point-Of-View data, i.e. the 2D vectors for player, facing, and vplane directions.

With these mostly hard-coded until now, synth could've been doing lots of optimisations, giving us unrealistic expectations of actual ASIC area needs.

Ultimately, the POV needs to be controllable by an external device.

Possible approaches:

  1. Addressed access to internal registers, e.g. 5-bit CSR address bus selects up to 18x 8-byte registers that make up the 3 vectors, allowing direct write access to them.
  2. Since typically all registers will need to be updated at the same time, we could instead just expect 18x 8-byte writes in one go with just one control signal to indicate the start of the write and another to clock them in.
  3. Likewise, could do the same thing with SPI (as we did with the original Raybox).

Current implemention is option 3, and I've double-buffered in the input SPI bit stream to ensure the vectors will only be updated at the start of VBLANK for the last completed SPI write.

NOTE: Writing all 2x3x24 bits means 144 writes. However, in most cases only 80 bits might actually be required:

  • Q6.10 for each of playerX/Y: 32 bits
  • Q2.10 for facingX/Y and vplaneX/Y: 48bits
  • Total: 80 bits ...and so we could arrange it that only those bits are written first, but if the host continues to write, then it can flow into the remaining 64 bits.

Basic version for now will behave as Raybox does: Writing all 144 bits via SPI, and they only take effect at the start of VBLANK.

NOTE: Because we're double-buffering the input, that means 144x3 (432) registers, which is quite a lot.

NOTE: Buffering the input is not important if we find synchronisable times when we can write to the registers directly. With this in mind, there's a big advantage in providing IRQ-like signals for various states, and allowing byte-wide writes... 18 writes at 5 clocks per write is only 90 clocks, which is easily small enough to fit into HBLANK, for instance. This could enable us to change the view on specific scanlines, and effectively do split-screen.

Next steps

  • In sim, borrow this and use gOvers (with a better name) in update_spi_state