Skip to content

Latest commit

 

History

History
136 lines (125 loc) · 5.92 KB

0223-2024-11-12.md

File metadata and controls

136 lines (125 loc) · 5.92 KB
Raw

12 Nov 2024

Previous journal: Next journal:
0222-2024-11-11.md 0224-2024-12-05.md

Ideas for future raybox-zero versions

  • Maybe RGB333 or RGB444 output?
  • Dithered distance dimming?
  • Double-rez mode: For gen_tex only, since extra time is required for texture SPI reads otherwise, but there are probably ways around this including RGB222 6-bit packing (instead of 8-bit) and having blanking marigns during which there is extra time for SPI reads.
  • Dual LEAK (top and bottom), or high-precision LEAK/VOFFSET.
  • Byte-aligned SPI
  • Map SRAM (or regs) -- Map loading (with double-buffering or not?)
  • Registers to blank out a region, or fill a region, of the map
  • 3bit map instead of 2bit?
  • Optional QSPI mode; strap extra bits high to just use "classic" mode?

Standardizing TT/RBZ pinout and other raybox-zero pinout improvement ideas

These are some rough notes about changing the raybox-zero pinout, especially on Tiny Tapeout. It's motivated by: a change to merge the two SPI interfaces; universal support for the Digilent and Leo Moser QSPI PMODs; and trying to make room for other functions.

  • Pinout:
    • While SPI CSb is asserted, inc_px/py (and maybe others) could become extra SPI in channels (since they are not sampled until new frame start otherwise).
    • SPI slave: 3pins IN
      • CSb
      • SCLK
      • MOSI (if just single channel SPI)
    • RGB out: 8-11pins OUT
      • HSYNC
      • VSYNC
      • R
      • r
      • G
      • g
      • B
      • b
      • Optionally 3 more RGB bits, or just a 'bright' bit (or other side: LSB?)
      • ...need to match to what can be read in fast enough from texture ROM
    • Texture SPI master: 5 IN pins, 1 BIDIR
      • CSb
      • SCLK
      • io0 (bidir)
      • in1
      • in2
      • in3
    • Debug:
      • Single debug pin that makes a bunch of other pins turn into debugs?
      • GPout(s) (or equivalent; output pin overrides selectable by SPI)?
      • reg_outs_enb
      • gen_tex
    • Optional demo stuff:
      • inc_px/py
      • and/or: inc_vp_px/py
  • Pin totals:
    • 8 IN:
      • SPI CSb
      • SCLK
      • MOSI
      • gen_tex
      • inc_px
      • inc_py
      • reg_outs_enb
      • debug -- emergency fallback debug if SPI is not working (or inconvenient)
    • 8 OUT:
      • HSYNC
      • VSYNC
      • RGB222
    • Bidir:
      • io[3:0]
      • GPOUT
      • 3 spare?? Extra RGB bits for RGB333?
  • Per SPI spec, access texture ROM via bidir pins: 
    uio[0] - CSb
uio[1] - MOSI   io0
uio[2] - MISO   io1
uio[3] - SCK    
uio[4] - NC     SPARE
uio[5] - RST    Keep high, or use as an input when no PCB
uio[6] - WP     io2
uio[7] - HLD    io3
    WARNING: This is not compatible with Moser's QSPI Pmod. So, we could set up the bidir port as follows:
    • Make uio[5] an input:
      • If SPI Pmod is plugged in, it pulls this high.
      • We can then sense this as "use_texture_rom" (GEN_TEXb)
      • Also, this uio[5] input state means the chip will NOT reset (good).
      • If Pmod is NOT plugged in, manually pull it low via 10k (?) to assert GEN_TEXb -- in fact, we could ALWAYS pull it low on the demo PCB via 47k or something so that the Pmod pull-up (10k) can override it (3.3V CMOS or LVTTL Vih is 2.0V)
      • If using a Pmod that leaves this NC, then pull it up manually to enable texture ROM.
    • Reserve uio[4] for some other function (as it is normally expected to be N/C)
    • For compat with Moser's Pmod, could we make uio[7] an input, then strap it high externally:
      • With Moser's PMOD: we can sense this as GEN_TEXb. Moser's PMOD will see it as disabling one of the PSRAMs (?)
      • With Digilent PMOD: Make sure the ROM is programmed with this HIGH; then when floating it is pulled up by the PMOD anyway
      • HOWEVER: We would prefer it to behave as a "module type select" to change UIO pinouts to suit different PMODs... hmm...
pinout:
    # Inputs:
    ui[0]: spi_sck
    ui[1]: spi_sdi # aka MOSI
    ui[2]: spi_csb # aka ss_n
    ui[3]: debug # Show debug vectors on screen?
    ui[4]: inc_px # Increment px
    ui[5]: inc_py # Increment py
    ui[6]: reg
    ui[7]: texture_pmod_type
    #NOTE: For texture_pmod_type:
    #   0=Moser's QSPI PMOD; can have a weak pull-up on uio[5] (io3), and ensure io3 bits are 1 in ROM to avoid GEN_TEXb. NOTE: Looks like there are jumpers to enable/disable the chips...?
    #   1=Digilent SPI PMOD; hence expect uio[5] (RSTb) is weakly pulled up anyway, but can be pulled low for GEN_TEXb instead.

    # Outputs: Tiny VGA PMOD (https://tinytapeout.com/specs/pinouts/#vga-output)
    uo[0]: red[1]
    uo[1]: green[1]
    uo[2]: blue[1]
    uo[3]: vsync_n
    uo[4]: red[0]
    uo[5]: green[0]
    uo[6]: blue[0]
    uo[7]: hsync_n

    # Bidirectional pins
    #NOTE: The following are compatible with https://digilent.com/reference/pmod/pmodsf3/start
    ######## type=1           type=0
    uio[0]: 'Out: tex_csb   / Out: tex_csb'
    uio[1]: 'I/O: tex_io0   / I/O: tex_io0'
    uio[2]: 'In:  tex_io1   / In:  tex_io1'
    uio[3]: 'Out: tex_sclk  / Out: tex_sclk'
    uio[4]: 'In:  SPARE     / In:  tex_io2'
    uio[5]: 'In:  gen_texb  / In:  tex_io3'     # aka GEN_TEXb, aka use_texture_spi
    uio[6]: 'In:  tex_io2   / N/A: CS1'         # For RBZ with type==0 make it output 1 (disable RAM A)?
    uio[7]: 'In:  tex_io3   / N/A: CS2'         # For RBZ with type==0 make it output 1 (disable RAM B)? Otherwise unused for type==1, or MAYBE SPARE