654 raybox-zero TTCAD25a edition
654 : raybox-zero TTCAD25a edition
- Author: algofoogle (Anton Maurovic)
- Description: TTCAD25a v1.7 resub of 'simple VGA ray caster game demo' from TT07
- GitHub repository
- Open in 3D viewer
- Open in VGA Playground
- Clock: 25175000 Hz
How it works
This is a sky130 resubmission of ttihp0p2-raybox-zero (an updated version of tt07-raybox-zero, from the raybox-zero project).
This resubmission of tt07-raybox-zero on TTIHP0p2 is a framebuffer-less VGA display generator (i.e. it is 'racing the beam') that produces a simple implementation of a "3D"-like ray casting game engine... just the graphics part of it. It is inspired by Wolfenstein 3D, using a map that is a grid of wall blocks, with basic texture mapping.
There is nothing yet but textured walls, and flat-coloured floor and ceiling. No doors or sprites, sorry. Maybe that will come in a future version.
The 'player' POV ("point of view") registers allow the player position, facing X/Y vector, and viewplane X/Y vector in one go, and (along with other visual effects registers) are controlled by a single SPI interface.
NOTE: To optimise the design and make it work without a framebuffer, this renders what is effectively a portrait view, rotated. A portrait monitor (i.e. one rotated 90 degrees anti-clockwise) will display this like the conventional first-person shooter view, but it could still be used in a conventional landscape orientation if you imagine it is for a game where you have a first-person perspective of a flat 2D platformer, endless runner, "Descent-style" game, whatever.
TBC. Please contact me if you want to know something in particular and I'll put it into the documentation!
How to test
TBC. Please contact me if you want to know something in particular and I'll put it into the documentation!
Supply a clock in the range of 21-31.5MHz; 25.175MHz is ideal because this is meant to be "standard" VGA [email protected].
Start with gen_texb set low, to use internally-generated textures. You can optionally attach an external QSPI memory (tex_...) for texture data instead, and then set gen_texb high to use it.
debug can be asserted to show current state of POV (point-of-view) registers, which might come in handy when trying to debug SPI writes.
If reg input is high, VGA outputs are registered. Otherwise, they are just as they come out of internal combo logic. I've done it this way so I can test the difference (if any).
inc_px and inc_py can be set high to continuously increment their respective player X/Y position register. Normally the registers should be updated via SPI, but this allows someone to at least see a demo in action without having to implement the SPI host controller. NOTE: Using either of these will suspend POV updates via SPI.
Unlike the TT07 version, this one combines the two separate SPI peripheral interfaces into one, allowing both the POV and other registers to be updated from the same interface.
External hardware
Tiny VGA PMOD on dedicated outputs (uo).
Optional SPI controllers to drive ui_in[2:0].
Optional external SPI ROM for textures.
TBC. Please contact me if you want to know something in particular and I'll put it into the documentation!
IO
| # | Input | Output | Bidirectional |
|---|---|---|---|
| 0 | spi_sck | red[1] | Out: digilent_tex_csb / Out: moser_tex_csb |
| 1 | spi_sdi | green[1] | I/O: digilent_tex_io0 / I/O: moser_tex_io0 |
| 2 | spi_csb | blue[1] | In: digilent_tex_io1 / In: moser_tex_io1 |
| 3 | debug | vsync_n | Out: digilent_tex_sclk / Out: moser_tex_sclk |
| 4 | inc_px | red[0] | In: SPARE / In: moser_tex_io2 |
| 5 | inc_py | green[0] | In: gen_texb / In: moser_tex_io3 |
| 6 | reg | blue[0] | In: digilent_tex_io2 / N/A: moser_CS1 |
| 7 | tex_pmod_type | hsync_n | In: digilent_tex_io3 / N/A: moser_CS2 |