Skip to content

Instantly share code, notes, and snippets.

View yupferris's full-sized avatar

Jake Taylor yupferris

View GitHub Profile
@yupferris
yupferris / snes-models.md
Last active October 25, 2023 06:41
SNES models that I own/test with

NTSC-J

Model Serial Board CPU PPU SMP DSP
SHVC-001 SM10938872 SNS-CPU-RGB-02 S-CPU B (5A22-02) S-PPU1 (5C77-01) / S-PPU2 C (5C78-03) S-SMP S-DSP A
SHVC-001 S18362950 SNS-CPU-GPM-01 S-CPU A (5A22-02) S-PPU1 (5C77-01) / S-PPU2 B (5C78-03) S-SMP S-DSP A

PAL

| Model | Serial | Board | CPU | PPU | SMP | DSP |

@yupferris
yupferris / video_stuffz.v
Created December 8, 2022 20:42
video stuffz
// video generation
// ~12,288,000 hz pixel clock
//
// we want our video mode of 320x240 @ 60hz, this results in 204800 clocks per frame
// we need to add hblank and vblank times to this, so there will be a nondisplay area.
// it can be thought of as a border around the visible area.
// to make numbers simple, we can have 400 total clocks per line, and 320 visible.
// dividing 204800 by 400 results in 512 total lines per frame, and 240 visible.
// this pixel clock is fairly high for the relatively low resolution, but that's fine.
// PLL output has a minimum output frequency anyway.
@yupferris
yupferris / slowverhead.md
Last active October 6, 2022 07:52
16 years later, I finally have an educated guess as to why Overhead was so slow on some machines.

In 2006, a (then-14-year-old) me wrote Overhead, a 256-byte intro (which was, ehm, "hEavilY InspiREd" by lander, among other intros). It was, for me, an early and highly rewarding experiment in x86 assembly, and huge thanks are owed to Baze/3SC (author of lander) not just for inspiration, but also including source with their intros (a common practice at the time, less common now unfortunately) and helpful responses to my emails asking how some basic things worked (eg. VGA setup and FPU stack).

In the pouët comments, many people reported that it ran quite a bit slower than intended. It was never blazingly fast (I recall 20-30FPS on my box at the time), but some people were reporting eg. 1-2FPS, which was pretty awful.

In a 2007 comment by Pirx, it was mentioned that writing memory at the beginning of the program segment was likely what was causing it to be so slo

@yupferris
yupferris / brief-2021-review.md
Last active August 10, 2022 11:49
brief 2021 review

The last few months have really been a grind, to the point where I'm feeling pretty demotivated/exhausted and I keep getting this idea that I didn't accomplish as much this year as I would have liked... however, this is pretty ridiculous considering the amount of things I objectively did accomplish this year, so I thought I'd write a (non-exhaustive) list to better align my thoughts with reality and give myself more room to take it easy lately without guilt.

In (mostly) no particular order...

  • Had a baby! first one too, man, what a ride!
  • Moved
  • Turned 30
  • Norwegian driver's license
  • Norwegian citizenship
  • Changed jobs
@yupferris
yupferris / wideboi.md
Last active September 18, 2021 23:25
Scalar stream (barrel) processor for TnL acceleration in xenowing

Goals

  • Input vertex attrib stream(s), output transformed vertex data stream(s)
    • Which stream(s) depend on required capabilities - eg. we don't always want/need lighting
  • Vertex transformation/deformation
    • Transform position vector into correct space, write out
    • Should support "spikeballs" somehow - eg. scale object space coords by sinusoid whose phase depends on vertex/thread index
  • Vertex lighting
    • Transform normal vector into correct space, dot product with light vector, scale rgba, write out
  • Relatively easy to program, probably via assembly (or similar)
note: j is used instead of i in these notes as it's much easier to differentiate from 1 in my editor's font :)
So, let's consider a 4-point (N=4) DFT of the following signal:
x = [0, 1, 0, 1]
for regular DFT, we have 4 basis vectors:
- k=0: [ 1, 1, 1, 1] (exp(-j(2pi/N)kn) for k=0 yields exp(0) or 1 for all n)
- k=1: [ 1, -j, -1, j] (exp(-j(2pi/N)kn) for k=1 yields exp(-j(pi/2)n))
@yupferris
yupferris / vcvarslol.bat
Created January 7, 2021 19:52
in `cmd`, `vcvarslol.bat >> vcvarslol`, then vs2019 tools can be pulled into msys2 with `. vcvarslol`
@ECHO OFF
set OLDPATH=%PATH%
call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvarsall.bat" x64 > NUL:
echo #!/bin/bash
echo export INCLUDE='%INCLUDE%'
echo export LIB='%LIB%'
diff --git a/rtl/src/color_thrust.rs b/rtl/src/color_thrust.rs
index 58b94d5..5fa8482 100644
--- a/rtl/src/color_thrust.rs
+++ b/rtl/src/color_thrust.rs
@@ -19,15 +19,25 @@ pub const REG_W1_DY_ADDR: u32 = 6;
pub const REG_W2_MIN_ADDR: u32 = 7;
pub const REG_W2_DX_ADDR: u32 = 8;
pub const REG_W2_DY_ADDR: u32 = 9;
-
-pub const REG_COLOR_ADDR: u32 = 10;
@yupferris
yupferris / livecoding-qna.md
Created April 20, 2020 11:16
What even was this?

How would you define livecoding in the demoscene? A sport? An art? Something else?

Definitely a mix of the two. There's a definitively competitive aspect that isn't necessarily present in other livecoding scenarios (eg. algorave) which makes it at least e-sports like, while still being an inherently artistic medium.

What are the reasons a shader wins over another one in a livecoding session and why, in your opinion?

It depends on the audience of course. It's the same with demos - people like what they like. For the demoscene, a cool 3D scene with lots of shiny things will often win. However, sometimes a very stylistic 2D shader will also win if it captures the audience (which is particularly common if it appeals to an "oldschool" palate, eg. by using a classic C64 color scheme/dithering style).

When did you first hear of livecoding in the demoscene?

@yupferris
yupferris / if_haxx.rs
Last active February 1, 2020 01:21
I feel dirty.
/// **UNSTABLE:** Provides a convenient way to write conditional combinational logic.
///
/// # Panics
///
/// Since this macro rewrites the referenced variable assignments using [`mux`], any panic conditions from that method apply to the generated code as well.
///
/// # Examples
///
/// ```
/// use kaze::*;