Skip to content

Latest commit

 

History

History
114 lines (92 loc) · 6.7 KB

0201-2024-05-11.md

File metadata and controls

114 lines (92 loc) · 6.7 KB
Raw

11 May 2024

Previous journal: Next journal:
0200-2024-05-01.md 0202-2024-05-15.md

Warming up for TT07 (tt-vga-fun)

Creating a new fork of my own tt06-grab-bag

For TT07 and beyond, I want this project to be mainly a VGA experiment/demo, and not specific to any TT version, so I'll leave the tt06-grab-bag repo mostly as-is and create a new repo from it called tt-vga-fun.

  1. Create new repo: https://github.com/algofoogle/tt-vga-fun
  2. Clone it, go into its dir.
  3. git remote add upstream [email protected]:algofoogle/tt06-grab-bag.git
  4. Create the main branch: git branch -M main
  5. Pull the upstream, but from the tt07-r2r branch (which is where I want to start): git pull upstream tt07-r2r
  6. Push to GitHub: git push -u origin main
  7. Remove the old upstream: git remote remove upstream
  8. Tag the version used for final TT06 submission: 
    git checkout ef59589
git tag -a tt06 -m "Version submitted to TT06 (from tt06-grab-bag repo)"
git push --tags
git checkout main
    (And I did the same for tt06-grab-bag too)

Ideas for tt-vga-fun

  • Fix reset logic.
  • Do a "fancy" version of solo_squash, or at least put a bouncing box option over the pretty 'mode' (e.g. XOR) pattern.
  • Support SPI during reset. The falling edge of /CS is kind of like its own local reset anyway.
  • Display hi-color image direct from SPI memories:
    • QSPI from a single chip should easily (?) enable 4-bit reads at 25MHz
    • 1 bidir pin is needed per chip for io0
    • Thus, we could do 12-bit colour images from 3 SPI memories (one for each of RGB):
      • 3 bidir pins needed
      • 9 other inputs; I'd want to maybe reserve 3 for control, e.g. an SPI slave, so 5 standard inputs, 4 bidir inputs.
      • 2 outputs needed (/CS and SCLK going to all 3 memories)
    • If I could forego the 3 reserved inputs, I could go up to 15-bit colour:
      • 4 bidir pins needed, for 4 SPI memories
      • 11 other inputs needed, say: 7 dedicated ui_ins, 4 more bidirs. Leaves 1 control pin.
      • This leaves 1 bit used out of 1 of the memories.
    • We could push up to 16-bit colour by using all ui_ins and bidirs.
      • Either do RGB565, or RGB555 with the extra bit controlling luminosity (e.g. MSB of all channels at once).
    • In terms of generating images:
      • Simple bit depths are easy in code.
      • Complex arrangements like 'dimming' might best be done with a nearest-match lookup palette that's the size of the target bit depth.
    • Note when reading in each line:
      • We have some time during blanking to read extra data that could be used to control our chip, for example to provide animation timing or other fun outputs (to be used by other spare output pins, e.g. for audio).
    • If we go for 15-bit colour (4 SPI ROMs), then how much animation can we fit in 16MByte packages?
      • Each frame is 640x480x15, but more like 640x480x4 when divided across 4 SPI ROMs.
      • Thus, one frame is 153,600 bytes.
      • 16,777,216 ÷ 153,600 ≈ 109 frames, and at 60fps this is about 1.8 seconds.
      • However, we have spare outputs, which could be used for extra /CS lines.
        • If we simply used 3 extra outputs as /CS lines, we can access 4x the memory (extra chips: 16 total? Are you crazy??) and get about 7.3 seconds of 60fps video.
    • Maybe it's time I learned the SDCARD (SDIO?) interface and whether it can be accessed serially at 25MHz (at least at 4 bits per clock). See: https://en.wikipedia.org/wiki/SD_card#Transfer_modes
  • Use EFSRAM?

Creating git and SSH key config that can switch between accounts based on directory

In order to use the same development environment for both work and personal projects, I need a git/SSH setup that allows for conveniently switching between GitHub accounts, and the best way I've found is to do this based on .gitconfig that uses the current directory.

Note that this is not necessarily required if your personal account can also be added to your work's GitHub organisation (and later removed if you leave). In that case, you might just want to add your work email address as one of many email addresses associated with your personal account.

In my case, I needed to do this though for a separate work GitHub account that I use for demo purposes:

  1. Assume there's a personal SSH key already.
  2. Create an extra SSH key for work, and add it to your work GitHub account.
  3. Create a file called ~/.gitconfig (or add to an existing one): 
    # Default (personal) config:
[user]
    email = [email protected]
    name = Anton Maurovic

# Uses an alternate git config if we're in a subdirectory of ~/WORK:
[includeIf "gitdir:/home/anton/WORK/**"]
    path = "/home/anton/amm-workplace.gitconfig"
  4. Now create ~/amm-workplace.gitconfig: 
    [core]
    sshCommand = "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_work_key -F /dev/null"

[user]
    name = Anton Maurovic
    email = [email protected]
    Notice how this config overrides the [user] details (namely user.email).

Note that this should have the following effects:

  • If you run git config user.email normally, it should be [email protected] (or whatever).
  • If you go into ~/WORK and do a git clone [email protected]:... of a private repo belonging to your work user or your work organisation (that you've been granted access to), then the new id_work_key should take effect.
  • As a result, if you then go into that repo you just cloned and run git config user.email now it should say [email protected]
  • If you go into any other dir that is not a subdir of ~/WORK then it will just use your personal GitHub SSH key.

What might work a little differently from what you expect:

  • If you go into ~/WORK (or a subdir of it) and you are not in a git repo, running git config user.email will still display your personal email address. This is normal. Don't worry: it will still use your work key when you clone a repo.
  • Don't expect ssh -T [email protected] to pick up your work key anytime. This method just affects Git.

TODO

  • Complete the doco for [tt06-grab-bag]
  • Prep TT07 submission
  • Full sim of extracted tt06-grab-bag layout
  • Install gnuplot and learn to use it in ngspice, e.g. see near here
  • Find out how to determine max current that can be supported and realistically delivered by sky130 devices internally (e.g. NFETs).
  • Try voltage buffers on R2R DAC output -- bias it: DAC currently gives [0, 1.8V], but ideally we want [0, 0.7V].