From aa403b978860210fcbace7fcdf5830066f3e14e0 Mon Sep 17 00:00:00 2001 From: Jesse Luehrs Date: Sat, 13 Oct 2018 02:17:44 -0400 Subject: import site content --- content/_index.md | 13 ++ content/blog/hacker-school-day-1.md | 33 +++ content/blog/keyboard-mappings.md | 141 +++++++++++ .../writing-an-nes-game-inside-the-cartridge.md | 12 + content/blog/writing-an-nes-game-part-1.md | 184 +++++++++++++++ content/blog/writing-an-nes-game-part-2.md | 257 +++++++++++++++++++++ content/blog/writing-an-nes-game-part-3.md | 95 ++++++++ content/blog/writing-an-nes-game-part-4.md | 186 +++++++++++++++ content/contact.md | 7 + content/internet.md | 12 + content/projects.md | 106 +++++++++ content/resume.pdf | Bin 0 -> 81195 bytes content/resume.tex | 198 ++++++++++++++++ content/resume.txt | 110 +++++++++ content/talks.md | 15 ++ content/work.md | 8 + 16 files changed, 1377 insertions(+) create mode 100644 content/_index.md create mode 100644 content/blog/hacker-school-day-1.md create mode 100644 content/blog/keyboard-mappings.md create mode 100644 content/blog/writing-an-nes-game-inside-the-cartridge.md create mode 100644 content/blog/writing-an-nes-game-part-1.md create mode 100644 content/blog/writing-an-nes-game-part-2.md create mode 100644 content/blog/writing-an-nes-game-part-3.md create mode 100644 content/blog/writing-an-nes-game-part-4.md create mode 100644 content/contact.md create mode 100644 content/internet.md create mode 100644 content/projects.md create mode 100644 content/resume.pdf create mode 100644 content/resume.tex create mode 100644 content/resume.txt create mode 100644 content/talks.md create mode 100644 content/work.md (limited to 'content') diff --git a/content/_index.md b/content/_index.md new file mode 100644 index 0000000..7a689f0 --- /dev/null +++ b/content/_index.md @@ -0,0 +1,13 @@ +--- +title: "Jesse Luehrs" +--- + +I am a programmer, currently working for [Stripe](https://stripe.com/). + +I was a member of the Fall 1 2014 batch at the [Recurse Center](https://recurse.com/). + +I typically go by "doy" [on the internet](/internet/). + +I graduated from the [University of Illinois at Urbana-Champaign](https://uiuc.edu/) in 2008. + +I'm currently living in New York City. diff --git a/content/blog/hacker-school-day-1.md b/content/blog/hacker-school-day-1.md new file mode 100644 index 0000000..8ffe386 --- /dev/null +++ b/content/blog/hacker-school-day-1.md @@ -0,0 +1,33 @@ +--- +title: hacker school, day 1 +date: "2014-09-02T19:55:00" +tags: [hacker school] +--- + +So I'm finally starting [Hacker School](https://www.hackerschool.com/). Today +was partly an orientation day, and I spent a while meeting people and stuff, +but eventually settled down to work. + +For my first project, I decided to work on an IRC bouncer in +[Rust](http://rust-lang.org/). I've wanted a decent IRC bouncer for a while - +I'm currently using [ZNC](http://wiki.znc.in/ZNC), which is the only really +usable one I've found, but it doesn't really handle disconnection well. I'd +like to be able to just close my laptop and go, and actually get all of the +messages I missed when I open it back up. The problem is that if you don't +explicitly disconnect the IRC client, the bouncer has no way of knowing when +you stopped receiving messages, so messages in that timeout window tend to +just get dropped, which makes it quite difficult to keep up with +conversations. + +The solution I'm going to try is to split the bouncer into two parts, a client +and a server. The server still runs as usual, but you run a bouncer client +locally, and that is what you connect to with your IRC client. The bouncer +client then talks to the bouncer server using a different protocol which +allows you to sync unread messages reliably. + +The first problem that I ran into is that there doesn't appear to be a +fully-featured IRC library for Rust yet (in particular, one that can handle +being a server as well as a client), so... the first step is obviously to +write one! I've done this before [in Lua](https://github.com/doy/luairc), so I +don't think this should be an insurmountable obstacle. We'll see how accurate +that assessment is this week, I suppose. diff --git a/content/blog/keyboard-mappings.md b/content/blog/keyboard-mappings.md new file mode 100644 index 0000000..5109b87 --- /dev/null +++ b/content/blog/keyboard-mappings.md @@ -0,0 +1,141 @@ +--- +title: keyboard mappings +date: "2013-11-02T20:54:00" +tags: [configuration, keyboard] +--- + +So I was at the [Pittsburgh Perl Workshop](http://pghpw.org/ppw2013/), and +[John Anderson](https://twitter.com/genehack) gave a +[talk](http://pghpw.org/ppw2013/talk/5084) about his personal configuration +setup. It motivated me to spend quite a bit of time going over [my own +configuration](https://github.com/doy/conf), but in particular it reminded me +that I had been wanting to adjust my keyboard for a while now. My pinkies have +been getting tired more quickly lately, and I'm fairly sure this is in large +part because of how often I have to use the Shift and Control keys. I do all +of my work on laptops, so it would be pretty inconvenient to get an external +keyboard, so I decided to actually put some effort into looking at ways to +modify my existing keyboard to be easier to type on. + +## Control + +One of the first things I did was read up ways to avoid finger stress. As it +turns out, this is especially common in the Emacs community (since so many of +their keyboard shortcuts rely on weird modifier key combinations), and there's +even a [project](http://ergoemacs.org/) dedicated to making Emacs more +ergonomic. One of the things that they do mention is that contrary to popular +wisdom, [mapping Caps Lock to Control really isn't a very good +solution](http://ergoemacs.org/emacs/swap_CapsLock_Ctrl.html). They recommend +swapping Control and Alt instead, since Control is used far more often, and +you can press the Alt key with your thumb, which is a much stronger finger. + +To do this, I added this to my `.Xmodmap`: + + clear control + clear mod1 + keycode 37 Alt_L Meta_L + keycode 64 Control_L + keycode 105 Alt_R Meta_R + keycode 108 Control_R + add control = Control_L Control_R + add mod1 = Alt_L Alt_R Meta_L Meta_R + +## Shift + +The next thing I started thinking about was how to reduce the usage of the +Shift keys. I do a lot of programming, which uses punctuation characters quite +a bit, and so I started +[wondering](https://twitter.com/doyster/status/388138795557978112) if swapping +the shifted and unshifted number row would be a good idea. As it turns out, +[Brock Wilcox](https://twitter.com/awwaiid) did this [quite a while +ago](http://thelackthereof.org/Keyboard_Number-Symbol_Swap), and he liked it a +lot. Using that as a place to start, I came up with [this +script](https://github.com/doy/conf/blob/master/bin/toggle_numkeys): + + if xmodmap -pk | grep -q '(1).*(exclam).*(1).*(exclam)'; then + xmodmap -e 'keycode 10 = exclam 1' + xmodmap -e 'keycode 11 = at 2' + xmodmap -e 'keycode 12 = numbersign 3' + xmodmap -e 'keycode 13 = dollar 4' + xmodmap -e 'keycode 14 = percent 5' + xmodmap -e 'keycode 15 = asciicircum 6' + xmodmap -e 'keycode 16 = ampersand 7' + xmodmap -e 'keycode 17 = asterisk 8' + xmodmap -e 'keycode 18 = parenleft 9' + xmodmap -e 'keycode 19 = parenright 0' + xmodmap -e 'keycode 20 = underscore minus' + xmodmap -e 'keycode 34 = braceleft bracketleft' + xmodmap -e 'keycode 35 = braceright bracketright' + xmodmap -e 'keycode 49 = asciitilde grave' + xmodmap -e 'keycode 51 = bar backslash' + else + xmodmap -e 'keycode 10 = 1 exclam' + xmodmap -e 'keycode 11 = 2 at' + xmodmap -e 'keycode 12 = 3 numbersign' + xmodmap -e 'keycode 13 = 4 dollar' + xmodmap -e 'keycode 14 = 5 percent' + xmodmap -e 'keycode 15 = 6 asciicircum' + xmodmap -e 'keycode 16 = 7 ampersand' + xmodmap -e 'keycode 17 = 8 asterisk' + xmodmap -e 'keycode 18 = 9 parenleft' + xmodmap -e 'keycode 19 = 0 parenright' + xmodmap -e 'keycode 20 = minus underscore' + xmodmap -e 'keycode 34 = bracketleft braceleft' + xmodmap -e 'keycode 35 = bracketright braceright' + xmodmap -e 'keycode 49 = grave asciitilde' + xmodmap -e 'keycode 51 = backslash bar' + fi + +I bound the script to pressing both Shift keys at once as Brock recommended +(using xbindkeys): + + "toggle_numkeys" + Shift + Shift_R + + "toggle_numkeys" + Shift + Shift_L + +and also set it to run when I logged into X. Note that this also maps a few +other things - besides just the number row, it also makes tilde, underscore, +left and right brace, and pipe into the unshifted characters for their +respective keys. Underscore was the biggest win, I think - typing +`$variable_names_with_lots_of_words_in_them` was always a pretty big strain. + +Again as Brock pointed out, I had to remap the keys in some other applications +to make them stay usable. Strangely enough, both i3 and Firefox continued to +work (I have `Mod4+1`, etc mapped to switching desktops in i3, and Firefox +uses `Alt+1`, etc for tab switching). Not really sure what's going on there. I +did have to add some remappings for the hint mode in +[Pentadactyl](http://5digits.org/pentadactyl/) though: + + set hintkeys=")!@#$%^&*(" + +Zsh, readline, and vim also required remapping `)` to `0`, since I use the `0` +command a lot. Here's from vimrc: + + nmap ) 0 + +and zshrc: + + bindkey -M vicmd ')' vi-digit-or-beginning-of-line + +and inputrc: + + ")": beginning-of-line + +I couldn't figure out how to get the number keys in choose-window mode in tmux +to remap (if anyone has any clues, let me know), but I did rebind the +copy-mode command: + + bind { copy-mode + +So far, I've been using this setup for a little over two weeks, and I'm liking +it a lot. My fingers are noticeably less tired, and I feel like my typing +speed while programming is quite a bit faster. A lot of things feel more +natural too - for instance, `my ($foo_bar, $baz) = @_;` is now typed entirely +without pressing the Shift key, which feels much better. One thing that does +still bother me is that `(:` now requires one shifted and one non-shifted key, +which makes it harder to type, but I'm fairly sure that overall I use `;` more +than `:`, so I don't think switching that is worthwhile. + +In addition to these keyboard remappings, I also remapped a bunch of things in +vim to use fewer keystrokes, but I'll talk about that in a future post. diff --git a/content/blog/writing-an-nes-game-inside-the-cartridge.md b/content/blog/writing-an-nes-game-inside-the-cartridge.md new file mode 100644 index 0000000..14f8891 --- /dev/null +++ b/content/blog/writing-an-nes-game-inside-the-cartridge.md @@ -0,0 +1,12 @@ +--- +title: writing an nes game - inside the cartridge +date: "2014-10-14T12:00:00" +tags: [hacker school, nes] +--- + +As an aside, this is what the inside of an NES cartridge looks like: + +![cartridge image](/blog/cartridge.jpg) + +Note specifically the two physical ROM banks, one labeled PRG and the other +labeled CHR (and basically nothing else on the circuit board). diff --git a/content/blog/writing-an-nes-game-part-1.md b/content/blog/writing-an-nes-game-part-1.md new file mode 100644 index 0000000..b683980 --- /dev/null +++ b/content/blog/writing-an-nes-game-part-1.md @@ -0,0 +1,184 @@ +--- +title: writing an nes game, part 1 +date: "2014-10-13T16:00:00" +tags: [hacker school, nes] +--- + +For the past week or so at Hacker School, I've been learning how to write +games for the NES. This was intended to just be a brief debugging detour for a +different project I was working on, but as these things tend to go, it turned +into an entire project on its own. You can see the end result at +[https://github.com/doy/nes-snake](https://github.com/doy/nes-snake), but I +wanted to go over the code to give an overview about what programming for the +NES is like. + +The NES itself has three processors - a [6502 +CPU](https://en.wikipedia.org/wiki/MOS_Technology_6502), a custom graphics +chip called the PPU (picture processing unit), and a custom sound chip called +the APU (audio processing unit, which I didn't use for this project). Game +data is stored in [ROM](https://en.wikipedia.org/wiki/Read-only_memory) banks, +typically with code and sprite data separate - code is stored in PRG-ROM +(which consists of some number of 16KB banks) and sprite data is stored in +CHR-ROM (which consists of some number of 8KB banks). The only difference +between these two (other than the size) is that PRG-ROM is mapped to the +address space of the CPU and CHR-ROM is mapped to the address space of the PPU +(the different chips also have different address spaces). My game is simple +enough to only require a single PRG-ROM bank and a single CHR-ROM bank. + +The CPU in the NES has a single flat 16-bit address space, which contains +everything from system RAM (there is only 2KB of this), to [memory-mapped IO +ports](https://en.wikipedia.org/wiki/Memory-mapped_I/O) (so reading or writing +at specific memory locations doesn't actually access any memory, it instead +accesses some hardware pins), to battery-backed RAM on the cartridge itself +(if availble), to the actual program ROM. The PPU has its own entirely +separate 14-bit address space, which mostly holds raw sprite data, color +palettes, and information about which sprites should be drawn in which +locations on the screen (that last part is typically the only thing that needs +to be touched in a simple game). + +So this is what the basic skeleton of a small NES program (which uses a +single 16KB PRG-ROM bank and a single 8KB CHR-ROM bank) looks like: + +```asm +; .ROMBANKMAP describes the layout of the ROM banks that this assembly file +; will produce. They will end up laid out sequentially in the output file. In +; this case, we're writing a game that requires one 16KB PRG-ROM bank and one +; 8KB CHR-ROM bank, so we specify that there are two banks in total, and we +; then specify the sizes for each of those two banks. The output file, once +; linked, will be a 24KB file, where the first 16KB is the PRG-ROM data and +; the last 8KB is the CHR-ROM data. +.ROMBANKMAP +BANKSTOTAL 2 +BANKSIZE $4000 ; PRG-ROM is 16KB +BANKS 1 +BANKSIZE $2000 ; CHR-ROM is 8KB +BANKS 1 +.ENDRO + +; .MEMORYMAP describes how the ROM banks will be loaded into memory. On the +; NES, program ROM has $8000-$FFFF available to it in the address space (which +; corresponds to two banks of PRG-ROM data), but if you're only using a single +; bank, it is typically loaded at $C000 (since the interrupt vectors must be +; located at $FFFA/$FFFC/$FFFE). The CHR-ROM data isn't mapped into the main +; address space (it is instead mapped into the PPU's address space), so it +; doesn't actually matter what address we tell it to load into. +.MEMORYMAP +DEFAULTSLOT 0 +SLOTSIZE $4000 +SLOT 0 $C000 ; a single PRG-ROM bank should be mapped at $C000 +SLOTSIZE $2000 +SLOT 1 $0000 ; this location doesn't matter, CHR-ROM isn't in main memory +.ENDME + +; .ENUM just creates a mapping of names to values. Variables don't actually +; exist in assembly - all you have is memory locations, and so variables +; can be simulated by creating aliases to locations in memory. +; .ENUM is just a convenient shortcut for defining labels that point +; to data. On the NES, the internal system RAM is located at $0000-$0800 (2KB), +; and so we can just define labels that point into that section of memory and +; use them as variables. In addition, most 6502 opcodes are shorter and faster +; if they are accessing memory within $0000-$00FF (called the "zero page"), and +; so we should try to put most common variables within that portion of memory. +; In addition to putting variables in the zero page, NES programs typically use +; $0100-$01FF for the stack (used by the PHA/PLA instructions) and $0200-$02FF +; for holding sprite data until it can be copied to the PPU, so you should +; avoid using those sections of RAM for arbitrary game data. +.ENUM $00 +; global variable declarations go here +.ENDE + +; This defines the first ROM bank (bank 0), and indicates that it will be +; loaded into slot 0 as defined above. + .bank 0 slot 0 +; .org indicates the offset that the following assembly code will be created +; at, relative to the start of the current ROM bank. In this case, we're using +; an offset of $0000, so this code will be loaded into the NES address space +; starting at $C000. + .org $0000 + +; The RESET label is the code that will be jumped to at power on (see below) +RESET: + ; TODO: initialization code goes here +loop: + ; TODO: game code goes here + JMP loop + +; The NMI label is the code that will be jumped to at the start of each frame +; (see below) +NMI: + ; TODO: per-frame drawing code goes here + RTI + +; .orga defines the absolute address that the following assembly code will be +; created at. It must be a value within the current ROM bank. We're using .orga +; here because $FFFA is a special value to the NES, and so using it literally +; makes the code easier to understand. $FFFA is the start of three interrupt +; vectors that define which code to run when various things happen. The first +; one is the NMI handler, which runs on each frame. The second is the RESET +; handler, which runs at system startup. The third is the IRQ handler, which +; runs on external interrupts (usually from the APU or various external chips). +; We don't use the IRQ handler because we aren't doing any sound, and we aren't +; using any external chips, so it is just set to 0 (which disables it). + .orga $FFFA + .dw NMI ; $FFFA contains the address to jump to at the start of each frame + .dw RESET ; $FFFC contains the address to jump to at power-on + .dw 0 ; $FFFE contains the address to jump to on an external interrupt + +; This defines the second bank, which holds the CHR-ROM. + .bank 1 slot 1 + .org $0000 +; .incbin includes the contents of an external file literally into the output. +; Here, sprites.chr should contain the literal contents of the CHR-ROM. This is +; easier because the CHR-ROM doesn't contain any code, so defining it inline in +; the assembly code file would be quite a bit less convenient. I'll talk about +; ways to actually edit this file later. + .incbin "sprites.chr" ; sprites.chr should be 8192 bytes +``` + +This is using the syntax for the WLA DX assembler, which works well on Linux +(most of the existing tutorials I've seen use various Windows-only +assemblers). I'm using the +[`wla_dx`](https://aur.archlinux.org/packages/wla_dx/) AUR package on Arch +Linux, but similar packages should be available for most distros. To compile +this code, follow these steps: + +* Save the code as `test.s` +* Run `dd if=/dev/zero of=sprites.chr bs=8192 count=1` to create an empty CHR + data file (which will be included in the output) +* Run `wla-6502 -o test.s` to generate an object file called `test.o` +* Create a file named `linkfile` which is used by the linker, with the contents + +``` +[objects] +test.o +``` + +* Run `wlalink linkfile test.rom` to create the actual ROM + +This ROM is not yet in the format required to be run by most NES emulators. To +get it into this format, we need to add a 16-byte header which describes the +layout of the file. You can download the header I used from +[here](https://raw.githubusercontent.com/doy/nes-snake/master/header.bin) - it +specifies a layout containing one PRG-ROM bank and one CHR-ROM bank. If you're +interested in doing something different, you should read up on the [iNES ROM +format](http://wiki.nesdev.com/w/index.php/INES). + +Once you have a file containing the header, you can create a file that will +actually work in an NES emulator by running `cat header.bin test.rom > +test.nes`. To run the ROM, I highly recommend using an emulator that aims for +accuracy - a lot of emulators out there aim for compatibility, which typically +means hacks for specific known games, and which will quite possibly just +result in breaking games that they don't know about (including new games you +are writing). Nestopia is a good recommendation if you don't know much about +the subject. To execute the ROM you just created, run `nestopia test.nes`. You +should just see a blank screen, since we haven't included any code to make it +do anything differently, but it should successfully load and run. + +Next time I'll talk about the structure of the actual code in an NES game. For +further information about the topics in this post, here are some useful links: + +* [WLA DX assembler reference](http://www.villehelin.com/wla.txt) +* [NES Assembly Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf) +* [NES Architecture](http://fms.komkon.org/EMUL8/NES.html) +* [NES 101](http://hackipedia.org/Platform/Nintendo/NES/tutorial%2c%20NES%20programming%20101/NES101.html) +* [NES technical documentation](http://emu-docs.org/NES/nestech.txt) diff --git a/content/blog/writing-an-nes-game-part-2.md b/content/blog/writing-an-nes-game-part-2.md new file mode 100644 index 0000000..d2cd675 --- /dev/null +++ b/content/blog/writing-an-nes-game-part-2.md @@ -0,0 +1,257 @@ +--- +title: writing an nes game, part 2 +date: "2014-10-14T15:30:00" +tags: [hacker school, nes] +--- + +# code layout + +So before we get into the code itself, there are a couple more concepts that +will be important to understand, in order to understand why the code is laid +out the way it is. + +First, we need to understand how the PPU handles drawing. The NES was designed +to work on CRT screens, which work by drawing a horizontal line at a time from +the top of the screen to the bottom, at which point it starts again at the +top. This is done by a device called an [electron +gun](https://en.wikipedia.org/wiki/Electron_gun), which fires electrons at a +screen of pixels. The key point here is that drawing is done sequentially, one +pixel at a time, and the mechanism requires some amount of time to move from +one line to the next, and to move from the bottom of the screen back to the +top. The period of time when the electron gun is moving from the end of one +line to the beginning of the next is called the "HBlank" time, and the period +of time when the electron gun is moving from the bottom of the screen back to +the top is called the "VBlank" time. Except during HBlank and VBlank, the PPU +is busy controlling what actually needs to be drawn, and manipulating it at +all can cause all kinds of weird graphical glitches, so we need to make sure +we only communicate with the PPU during HBlank or VBlank. + +The way the NES handles this is to provide an interrupt (called NMI) which +fires at the beginning of every VBlank, which allows you to do all of your +drawing during a safe period of time. HBlank is harder to detect and not as +useful (since it occurs in the middle of drawing a frame), and so it is not +typically used except for some visual effects. NTSC television screens refresh +at 60 frames per second, and the CPU clock speed in the NES is approximately +1.79MHz, and so we get approximately 30,000 CPU cycles per frame, which +translates into roughly 5,000-10,000 opcodes. VBlank, though, only lasts +around 2273 cycles (roughly 400-800 opcodes), so drawing code needs to be +especially efficient. In particular, we don't want to do any game logic at all +during VBlank time, since that time is so limited. + +The other aspect that needs to be handled is system initialization. When the +CPU starts up, it's in an undefined state, so we need to set things up to +ensure that the game executes in a repeatable way. Emulators tend to be +consistent in how they initialize the system state at startup, but this isn't +true of the real hardware, so it's important to do this explicitly. Also, the +PPU requires initialization, but that is handled automatically. It does take a +bit over 30,000 CPU cycles though (a little over one frame), so we wait for +two frames before starting our main game code. Two frames is plenty of time to +do any initialization we might need to do. + +To illustrate these concepts, here is an example program which modifies the +background color every second. The details about how the background color is +set isn't particularly important (it's not really a feature you're likely to +use very often), but this should illustrate the basic structure of an NES +game. This isn't intended to be a lesson on 6502 assembly (there are plenty of +much better tutorials and references out there for that - see below), but just +to show how games for the NES specifically are structured. + +```asm +.ROMBANKMAP +BANKSTOTAL 2 +BANKSIZE $4000 +BANKS 1 +BANKSIZE $2000 +BANKS 1 +.ENDRO + +.MEMORYMAP +DEFAULTSLOT 0 +SLOTSIZE $4000 +SLOT 0 $C000 +SLOTSIZE $2000 +SLOT 1 $0000 +.ENDME + +.ENUM $00 +; declare the label 'sleeping' to refer to the byte at memory location $0000 +sleeping DB +; 'color' will then be at $0001 +color DB +; and 'frame_count' will be at $0002 +frame_count DB +.ENDE + + .bank 0 slot 0 + .org $0000 +RESET: + ; First, we disable pretty much everything while we try to get the system + ; into a consistent state. In particular, we really don't want any + ; interrupts to fire until the stack pointer is set up (because interrupt + ; calls use the stack), and we don't want any drawing to be done until the + ; PPU is initialized. + SEI ; disable all IRQs + CLD ; disable decimal mode + LDX #$FF + TXS ; Set up stack (grows down from $FF to $00, at $0100-$01FF) + INX ; now X = 0 + STX $2000.w ; disable NMI (we'll enable it later once the ppu is ready) + STX $2001.w ; disable rendering (we're not using it in this example) + STX $4010.w ; disable DMC IRQs + LDX #$40 + STX $4017.w ; disable APU frame IRQ + + ; First wait for vblank to make sure PPU is ready. The processor sets a + ; status bit when vblank ends, so we just loop until we notice it. +vblankwait1: + BIT $2002 ; bit 7 of $2002 is reset once vblank ends + BPL vblankwait1 ; and bit 7 is what is checked by BPL + + ; set everything in ram ($0000-$07FF) to $00, except for $0200-$02FF which + ; is conventionally used to hold sprite attribute data. we set that range + ; to $FE, since that value as a position moves the sprites offscreen, and + ; when the sprites are offscreen, it doesn't matter which sprites are + ; selected or what their attributes are +clrmem: + LDA #$00 + STA $0000, x + STA $0100, x + STA $0300, x + STA $0400, x + STA $0500, x + STA $0600, x + STA $0700, x + LDA #$FE + STA $0200, x + INX + BNE clrmem + + ; initialize variables in ram + LDA #%10000001 + STA color + ; no need to initialize frame_count or sleeping, since we just set them to + ; $00 in the clrmem loop + + ; Second wait for vblank, PPU is ready after this +vblankwait2: + BIT $2002 + BPL vblankwait2 + + LDA #%10000000 ; enable NMI interrupts now that the PPU is ready + STA $2000 + +loop: + ; sleep while vblank is happening. this serializes the code flow a bit + ; (the NMI interrupt will almost certainly occur while we are in this loop + ; unless we do a significant amount of processing in the main codepath, so + ; it won't interrupt anything important). it also ensures that our game + ; logic only executes once per frame. + INC sleeping +wait_for_vblank_end: + LDA sleeping + BNE wait_for_vblank_end + + ; change color every 60 frames + LDX frame_count + CPX #60 + BCS change_color + INX + STX frame_count + JMP loop_end + +change_color: + LDA #$00 + STA frame_count + LDX color + CPX #%10000001 + BEQ turn_green + CPX #%01000001 + BEQ turn_red + +turn_blue: + LDA #%10000001 + STA color + JMP loop_end +turn_green: + LDA #%01000001 + STA color + JMP loop_end +turn_red: + LDA #%00100001 + STA color + +loop_end: + JMP loop + +NMI: + ; save the contents of the registers on the stack, since the interrupt can + ; be called at any point in our main loop + PHA + TXA + PHA + TYA + PHA + + LDA color + STA $2001 + + ; indicate that we're done drawing for this frame + LDA #$00 + STA sleeping + ; and restore the register contents before returning + PLA + TAY + PLA + TAX + PLA + + RTI + + .orga $FFFA + .dw NMI + .dw RESET + .dw 0 + + .bank 1 slot 1 + .org $0000 + .incbin "sprites.chr" +``` + +The first thing we do when the system turns on is disable IRQ interrupts. +Calling and returning from interrupts uses the system stack, but the stack +pointer could be pointing anywhere at this point, and so interrupts would be +confuse things quite a bit. We never reenable IRQ interrupts here because we +don't use them at all (they would be reenabled by the `CLI` instruction). Next +we disable decimal mode (this shouldn't actually do anything, since the NES +doesn't have a BCD chip, but no real reason not to do this, to avoid +confusion) and set the stack pointer to `$FF`. The stack pointer is stored in +the register named S, and it is a one-byte offset from the RAM address +`$0100`. The stack grows downward, so the stack pointer should start out +pointing to `$01FF`, and then it will be decremented by `PHA` instructions and +incremented by `PLA` instructions as necessary. Finally, we disable a bunch of +other functionality on the PPU and APU, since we don't want them to be active +until we have finished initializing. + +We need to wait for a total of two frames to ensure that the PPU is entirely +initialized, so we next wait for the first frame to end, and then clear out +the entire RAM space, and then wait for the second frame to end. At this +point, the PPU is initialized, so we can enable NMI interrupts (by setting a +bit in the PPU control register at `$2000`) and begin our main loop. + +The main loop is where all of the logic goes. In this example, we just +increment the frame count every frame, and change the background color (via +some magic) every 60 frames. This allows the NMI interrupt to do nothing more +than write a single value to the PPU, without requiring any logic at all. This +illustrates the basic principle of using the main game loop to set up values +in memory, which the code in the NMI interrupt can just read and act on +directly, without requiring any calculations. + +Here are some more useful links discussing the topics in this post: + +* [NES ASM Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf) +* [The frame and NMIs](http://wiki.nesdev.com/w/index.php/The_frame_and_NMIs) +* [6502 instruction set + overview](http://www.dwheeler.com/6502/oneelkruns/asm1step.html) +* [6502 instruction set + reference](http://e-tradition.net/bytes/6502/6502_instruction_set.html) +* [NES technical documentation](http://emu-docs.org/NES/nestech.txt) diff --git a/content/blog/writing-an-nes-game-part-3.md b/content/blog/writing-an-nes-game-part-3.md new file mode 100644 index 0000000..749b76d --- /dev/null +++ b/content/blog/writing-an-nes-game-part-3.md @@ -0,0 +1,95 @@ +--- +title: writing an nes game, part 3 +date: "2014-10-15T15:30:00" +tags: [hacker school, nes] +--- + +# input handling + +Now that we have a general idea of how a program for the NES is structured, +it'd be useful to get a bit further into the specific capabilities of the NES. +One of the pretty basic (and pretty important) ones is reading input from the +controllers. + +The basic structure of an NES controller is a [shift +register](https://en.wikipedia.org/wiki/Shift_register). To read the +controller inputs, you send a signal to the latch pin, which stores the state +of the input buttons in the register, and then you send a sequence of signals +to the clock pin to put the state of each button on the output in sequentially +(A, B, Select, Start, Up, Down, Left, Right). As it turns out, the code you +have to write to read from the controller maps pretty exactly to these +operations. This is what it looks like: + +```asm +read_controller1: + ; memory address $4016 corresponds to the shift register inside the + ; controller plugged into the first controller port. writing to it sets the + ; state of the latch pin, and so we set the latch pin high and then low in + ; order to store the controller state in the shift register. + LDA #$01 + STA $4016 + LDA #$00 + STA $4016 + + ; reading from $4016 reads the output value of the data pin and also sends a + ; signal to the clock pin in order to put the next bit of data on the output + ; for the next read. the value that is read has the state of the button in + ; the low bit, and the upper bits contain various other pieces of + ; information (such as whether a controller is plugged in at all, etc), so + ; if we only care about the state of the button we have to mask out + ; everything else. +read_a: + LDA $4016 + AND #%00000001 + BEQ read_b + ; code for if the a button is pressed +read_b: + LDA $4016 + AND #%00000001 + BEQ read_select + ; code for if the b button is pressed +read_select: + LDA $4016 + AND #%00000001 + BEQ read_start + ; code for if the select button is pressed +read_start: + LDA $4016 + AND #%00000001 + BEQ read_up + ; code for if the start button is pressed +read_up: + LDA $4016 + AND #%00000001 + BEQ read_down + ; code for if the up button is pressed +read_down: + LDA $4016 + AND #%00000001 + BEQ read_left + ; code for if the down button is pressed +read_left: + LDA $4016 + AND #%00000001 + BEQ read_right + ; code for if the left button is pressed +read_right: + LDA $4016 + AND #%00000001 + BEQ end_read_controller1 + ; code for if the right button is pressed + +end_read_controller1: + RTS +``` + +Obviously this could be simplified by putting the reads in a loop (the [snake +game](https://github.com/doy/nes-snake) handles it by shifting and packing all +of the button states into a single byte which the code can query later on), +but that does require more CPU cycles, especially if not all of the buttons +are important. + +In the spirit of continuing with real working code, +[here](/blog/input.s) is a sample program which changes the +background color every time you press A, rather than every second like last +time. Tomorrow, we'll work on drawing sprites! diff --git a/content/blog/writing-an-nes-game-part-4.md b/content/blog/writing-an-nes-game-part-4.md new file mode 100644 index 0000000..87a4257 --- /dev/null +++ b/content/blog/writing-an-nes-game-part-4.md @@ -0,0 +1,186 @@ +--- +title: writing an nes game, part 4 +date: "2014-10-19T20:00:00" +tags: [hacker school, nes] +--- + +# graphics + +Now that we can handle input, it's time to learn how to draw things. All +drawing on the NES is handled by the PPU. The PPU does sprite-based drawing, +meaning that all drawing is two dimensional, and happens in 8x8 blocks. Colors +are determined by a 16-color palette, of which a given sprite can only use +four colors (transparency being one of the colors). There is a background +layer, containing 32x30 tiles, and a set of up to 64 sprites, which can each +be either in front of or behind the background. + +The PPU has its own memory space and mostly just runs on its own, handling the +redrawing automatically every frame. In order to tell it what to do, we have +to load various bits of data into its memory. As mentioned in an earlier post, +the PPU is only capable of doing one thing at a time, so this drawing must +happen at the beginning of the NMI interrupt, when we are guaranteed to be in +VBlank. + +There are four steps involved in drawing a sprite. First, we need the sprite +itself. The pixel data for sprites is stored in the *pattern table*, and is +typically (although not always) stored in CHR-ROM. It contains 16 bytes per +sprite, where each pixel contains two bits of data, so each sprite can contain +at most four colors (including transparent). Since CHR-ROM banks are 8KB +each, this provides enough room for two sets of 256 tiles - typically one set +is used for the background and the other set is used for foreground sprites, +although this is not required. The patterns are laid out in memory as two +chunks of 8 bytes each, where the first 8 bytes correspond to the high bit for +the pixel, and the second 8 bytes correspond to the low bit for the pixel +(each byte representing a row of pixels in the sprite). To help with +generating this sprite data, I have written a script called +[pnm2chr](https://metacpan.org/pod/distribution/Games-NES-SpriteMaker/bin/pnm2chr), +which can convert images in the .PBM/.PGM/.PPM formats (which most image +editors can produce) into CHR-ROM data, so that you can edit sprites in an +image editor instead of a hex editor. + +Once we have the pattern data, we then need the *palette table*, to determine +the actual colors that will be displayed for a given sprite. The way that +colors are determined is actually quite convoluted, going through several +layers of indirection. As a basis, the NES is capable of producing 52 distinct +colors (actually 51, since one of the colors ($0D) is outside of the NTSC +[gamut](https://en.wikipedia.org/wiki/Gamut), and can damage older TVs if +used). From those 52 colors, only 16 can be used at a time (although the 16 +colors can be distinct for the background layer and the sprite layer), and +this set of 16 colors is known as the palette. + +To determine which palette color to use for each pixel in a given background +tile, the two bits from the pattern table are combined with two additional +bits of data from the *attribute table* to create a four bit number (the +pattern bits being the low bits and the attribute bits being the high bits). +The attribute table is a 64-byte chunk of memory which stores two bits for +each 16x16 pixel area of the screen (so each sprite shares the same two-bit +palette with three other sprites in a 2x2 block). The attribute data itself is +packed into bytes such that each byte corresponds to a 4x4 block of sprites. +This is all pretty confusing, so here is a diagram (from the [NES Technical +Documentation](http://emu-docs.org/NES/nestech.txt)) which will hopefully make +things a bit clearer: + + +------------+------------+ + | Square 0 | Square 1 | #0-F represents an 8x8 tile + | #0 #1 | #4 #5 | + | #2 #3 | #6 #7 | Square [x] represents four (4) 8x8 tiles + +------------+------------+ (i.e. a 16x16 pixel grid) + | Square 2 | Square 3 | + | #8 #9 | #C #D | + | #A #B | #E #F | + +------------+------------+ + + Attribute Byte + (Square #) + ---------------- + 33221100 + ||||||+--- Upper two (2) colour bits for Square 0 (Tiles #0,1,2,3) + ||||+----- Upper two (2) colour bits for Square 1 (Tiles #4,5,6,7) + ||+------- Upper two (2) colour bits for Square 2 (Tiles #8,9,A,B) + +--------- Upper two (2) colour bits for Square 3 (Tiles #C,D,E,F) + +For sprites, the upper two bits of the palette index is specified when +requesting the sprite to be drawn. + +The data about which background tile to draw is then stored in the *name +table*. This is a sequence of bytes which correspond to offsets into the +pattern table. For instance, to draw the first pattern in the pattern table, +you would write a $00 to the corresponding location in the name table. The +name table data is the combined with the appropriate attribute table data to +get a palette index, which is then looked up in the palette table to determine +the actual colors to use when drawing the tile. + +The data about which sprites to draw is stored in an entirely separate area of +memory (not part of any address space at all), called the SPR-RAM (sprite +RAM). It is 256 bytes long, and holds four bytes for each of the 64 sprites +that the NES is capable of drawing at any given time. The first byte holds the +vertical offset for the sprite (where the top left of the screen is (0, 0)), +the second byte holds the index into the pattern table for the sprite to draw, +the third byte holds various attributes about the sprite, and the fourth byte +holds the horizontal offset for the sprite. The sprite attributes contain +these bits of data: + +* The low two bits (bits 0 and 1) contain the high bits of the palette index, + as described above. +* Bit 5 is set if the sprite should be drawn behind the background. +* Bit 6 is set if the sprite should be flipped horizontally. +* Bit 7 is set if the sprite should be flipped vertically. + +If you don't need all 64 sprites, you should just move the horizontal and +vertical coordinates such that the sprite is offscreen ($FE or so). + +Now that we have seen all of the different pieces of the PPU memory, here is +how it is all laid out in memory: + + $0000: Pattern Table 0 (typically in CHR-ROM) + $1000: Pattern Table 1 (typically in CHR-ROM) + $2000: Name Table 0 + $23C0: Attribute Table 0 + $2400: Name Table 1 + $27C0: Attribute Table 1 + $2800: (used for mirroring, which I won't discuss here) + $2BC0: (used for mirroring, which I won't discuss here) + $2C00: (used for mirroring, which I won't discuss here) + $2FC0: (used for mirroring, which I won't discuss here) + $3000: (used for mirroring, which I won't discuss here) + $3F00: Palette Table 0 (used for the background) + $3F10: Palette Table 1 (used for sprites) + $3F20: (used for mirroring, which I won't discuss here) + $4000: (used for mirroring, which I won't discuss here) + +So, to draw a background sprite at the top left of the screen, you would write +the sprite index to VRAM address $2000 (assuming default settings). + +The final piece of information necessary to be able to use the PPU is how to +transfer data from main memory into VRAM. This is done via certain +memory-mapped IO addresses. + +First, to copy data into SPR-RAM, you should write all of the sprite data to a +single page (a page is a 256-byte chunk of data whose addresses all start with +the same byte) in RAM, and then write the page number into address $4014 (the +$02 page ($0200-$02FF) is typically used for this purpose). The address to +start writing from can be set by writing a byte to address $2003, and so you +typically want to write $00 into $2003 before starting a full page transfer +with $4014. If you want to write to only certain parts of SPR-RAM, you can do +this via address $2004 - set the base address to write to via $2003 as above, +and then write a sequence of bytes to $2004 to store them into SPR-RAM. + +To copy data into the main VRAM address space, you use the addresses $2006 and +$2007 in the same way that $2003 and $2004 were used for SPR-RAM, except that +you need to write two bytes into $2006 before you start writing to $2007, +since the address space is larger. Since the order of the bytes matters here, +you can read from $2002 to ensure that the next byte written to $2006 will be +the high byte of the address. Note that $2006 is also used for scrolling +(which is based on the last address written to), and so you generally want to +write $2000 back into $2006 at the end of drawing. + +Finally, you need to initialize the PPU in a few ways in order to allow +drawing, which is done via $2000 and $2001. These addresses hold quite a few +different configuration bits, but the most important ones are: + +* Bit 7 of $2000 should be set to enable NMI interrupts (we did this last + time). +* Bit 4 of $2000 should be set to use pattern table 1 instead of 0 for + the background. +* Bit 3 of $2000 should be set to use pattern table 1 instead of 0 for + sprites. +* Bit 0 of $2000 should be set to use name table 1 instead of 0 (this is + actually more complicated due to mirroring, but we won't get into that). +* Bit 4 of $2001 should be set to enable the sprite layer. +* Bit 3 of $2001 should be set to enable the background layer. + +The default pattern and name tables will be fine for now, and so +initialization should set $2000 to $%10000000 and $2001 to $%00011000. + +[Here](/blog/sprites.s) is a sample program which draws a background +and a sprite, and allows you to move the sprite around the background with the +controller D-pad. It will require a CHR-ROM data file with actual patterns in +it, so you can download that from [here]({{urls.media}}/sprites.chr) + +Further reading: +* [NES ASM Tutorial](http://nixw0rm.altervista.org/files/nesasm.pdf) +* [NES technical documentation](http://emu-docs.org/NES/nestech.txt) +* [NES ROM Quickstart](http://sadistech.com/nesromtool/romdoc.html) +* [NES 101](http://hackipedia.org/Platform/Nintendo/NES/tutorial%2c%20NES%20programming%20101/NES101.html) +* [CHR ROM vs. CHR RAM](http://wiki.nesdev.com/w/index.php/CHR_ROM_vs._CHR_RAM) +* [CHR data layout for The Legend of Zelda](http://www.computerarcheology.com/wiki/wiki/NES/Zelda) (Note that unlike what is described above, Zelda stores its pattern data in RAM rather than ROM.) diff --git a/content/contact.md b/content/contact.md new file mode 100644 index 0000000..bba4997 --- /dev/null +++ b/content/contact.md @@ -0,0 +1,7 @@ +--- +title: "contact info" +--- + +* **Email**: doy at tozt dot net +* **Twitter**: @doyster +* **IRC**: doy (on irc.freenode.net) diff --git a/content/internet.md b/content/internet.md new file mode 100644 index 0000000..88005c2 --- /dev/null +++ b/content/internet.md @@ -0,0 +1,12 @@ +--- +title: "me elsewhere on the internet" +--- + +* [Twitter](https://twitter.com/doyster) +* [GitHub](https://github.com/doy) +* [CPAN](https://metacpan.org/author/DOY) +* [last.fm](https://www.last.fm/user/doyster) +* [Project Euler](https://projecteuler.net/index.php?section=profile&profile=doy) +* [Steam](https://steamcommunity.com/id/doyster/) +* [nethack.alt.org](https://alt.org/nethack/plr.php?player=doy) +* [crawl.akrasiac.org](http://crawl.akrasiac.org/scoring/players/doy.html) diff --git a/content/projects.md b/content/projects.md new file mode 100644 index 0000000..1ec7fe3 --- /dev/null +++ b/content/projects.md @@ -0,0 +1,106 @@ +--- +title: "projects i've worked on" +--- + +### conf + +* [Source](https://github.com/doy/conf) + +My (extensive) collection of configuration files. + +### runes + +* [Source](https://github.com/doy/runes) + +Runes is a VT100 terminal emulator for Linux written in C. + +### reply + +* [CPAN](https://metacpan.org/release/Reply) +* [Source](https://github.com/doy/reply) + +Reply is a customizable and lightweight REPL for Perl. It provides features +like pluggable tab completion, automatic class loading and refreshing, history +support, and (through the Carp::Reply module) automatically launching a REPL +when an exception is thrown. It can be easily extended through a powerful +plugin system. + +### Spreadsheet::ParseXLSX + +* [CPAN](https://metacpan.org/release/Spreadsheet-ParseXLSX) +* [Source](https://github.com/doy/spreadsheet-parsexlsx) + +Spreadsheet::ParseXLSX is a Perl module which can read .xlsx files (as +generated by new versions of Microsoft Excel). It handles reading both the data +and formatting from these files. + +### Dungeon Crawl Stone Soup + +* [Website](https://crawl.develz.org/) +* [Source](https://github.com/crawl/crawl) + +I was a member of the development team for Dungeon Crawl Stone Soup, a +roguelike game written in C++ and Lua. I contributed several features +throughout the game, and I was also the release manager for the 0.6 release. + +### Moose + +* [CPAN](https://metacpan.org/release/Moose) +* [Source](https://github.com/moose/Moose) + +I was a member of the development team for Moose, a module which provides +advanced object orientation capabilities for Perl. I was also the release +manager from 2011 – 2012. I am also the maintainer of several widely used Moose +extensions, such as MooseX::NonMoose and MooseX::Aliases. + +### Text::Handlebars + +* [CPAN](https://metacpan.org/release/Text-Handlebars) +* [Source](https://github.com/doy/text-handlebars) + +Text::Handlebars is a port of the Handlebars.js templating language to Perl. It +uses a custom parser on top of the Xslate template engine framework. It +supports nearly the entire feature set of the JavaScript implementation, and we +used it at Infinity Interactive to ease the transition of one of our large web +applications from client side templates to server side templates. + +### OX + +* [CPAN](https://metacpan.org/release/OX) +* [Source](https://github.com/iinteractive/ox) + +OX is a web framework for Perl based on the PSGI specification, which uses the +Bread::Board dependency injection system to manage application components. We +used it internally at Infinity Interactive for many client projects. + +### Plack + +* [Website](https://plackperl.org/) +* [CPAN](https://metacpan.org/release/Plack) +* [Source](https://github.com/plack/Plack) + +I was a member of the core development team for Plack, the reference +implementation of the PSGI specification for Perl web server/application +interaction (similar to Python's WSGI and Ruby's Rack). I have also contributed +to the design of PSGI. + +### Perl + +* [Website](https://perl.org/) +* [Source](https://perl5.git.perl.org/perl.git) + +I was the release manager for the 5.17.1 development release of Perl, and I +have also contributed many bug fixes to the Perl core. In addition, I have +contributed to the initial implementations of the p5-mop project, a prototype +of a new object system for Perl, including features like a meta-object +protocol. + +### TAEB + +* [Website](https://taeb.github.io/) +* [Source](https://github.com/TAEB/TAEB) +* ["Behavioral" AI Source](https://github.com/TAEB/TAEB-AI-Behavioral) + +I was one of the lead framework developers for TAEB, a Perl framework for +programmatic interaction with NetHack. I was also the primary developer for the +leading AI written for TAEB. diff --git a/content/resume.pdf b/content/resume.pdf new file mode 100644 index 0000000..01fc5d5 Binary files /dev/null and b/content/resume.pdf differ diff --git a/content/resume.tex b/content/resume.tex new file mode 100644 index 0000000..4edab96 --- /dev/null +++ b/content/resume.tex @@ -0,0 +1,198 @@ +% vim:foldmethod=marker commentstring=%%%s +% license {{{ +% This work is licensed under the Creative Commons +% Attribution-NonCommercial-ShareAlike License. To view a copy of this license, +% visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to +% Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. +% This file is adapted from Todd Courtesan's resume, at +% http://www.courtesan.com/todd/resume.html +% }}} +% preamble {{{ +\documentclass[letterpaper]{article} +\usepackage{jesse_resume} +\hypersetup{hidelinks} +\setlength{\oddsidemargin}{-0.75in} +\setlength{\evensidemargin}{-0.75in} +\setlength{\textwidth}{8in} +\setlength{\topmargin}{-0.75in} +\setlength{\textheight}{10.5in} +% }}} +\begin{document} +% Header {{{ +\resheader{Jesse Luehrs} + {http://tozt.net/} + {doy@tozt.net\hspace{0.5in}} + {(618) 616-6287} + {70 America St. \#1R} + {Providence, RI 02903} +% }}} +% Education {{{ +\resheading{Education} +\begin{itemize} + % Hacker School {{{ + \item \ressubheading{Hacker School}{New York, NY} + {Student}{September 2014--November 2014} + % }}} + % UIUC {{{ + \item \ressubheading{University of Illinois at Urbana-Champaign, College of Engineering}{Urbana, IL} + {Bachelor of Science in Computer Science with Minor in Mathematics}{August 2004--May 2008} + \begin{minipage}[t]{\textwidth/2-0.2in} + \begin{itemize} + \resitem{Overall GPA: 3.61, Technical GPA: 3.81}\vspace{-7pt} + \resitem{James Scholar in Engineering (2004--2005)}\vspace{4pt} + \end{itemize} + \end{minipage} + \begin{minipage}[t]{\textwidth/2-0.2in} + \begin{itemize} + \resitem{Dean's List (Fall 2004--Fall 2006)}\vspace{-7pt} + \resitem{Graduated with Honors}\vspace{4pt} + \end{itemize} + \end{minipage} + % }}} +\end{itemize} +% }}} +% Work Experience {{{ +\resheading{Work Experience} +\begin{itemize} + % Infinity Interactive {{{ + \item \ressubheading{Infinity Interactive (\url{http://iinteractive.com/})}{Manhasset, NY (telecommuting)} + {Senior Programmer}{February 2010--August 2014} \vspace{6pt} \linebreak + \small{I was in charge of a large, legacy codebase which handles employee + engagement survey registration and reporting, and I have also written + and deployed many smaller sites myself, mostly using Perl. Since we + relied heavily on open source software, a large portion of my time was + also devoted to maintaining various open source projects, as well as + developing new open source software that could be useful in the + future.}\normalsize + % }}} + % UIUC Hydrogeology Lab {{{ + \item \ressubheading{UIUC Hydrogeology Lab (\url{http://www.gwb.com/})}{Urbana, IL} + {Visiting Research Programmer}{February 2006--February 2010} \vspace{6pt} \linebreak + \small{I worked on the Geochemists' Workbench, a geochemistry software suite + written in C++ and Tcl/Tk. I added support for several new image output + formats as well as adding font embedding support to the existing + PostScript format. I also helped add parallel processing support to + several scientific calculations, using OpenMP. I ported our calculation + applications from Windows to Linux, to allow them to be run on large + clusters. Finally, I implemented a testing framework for our calculation + applications using Perl's Test::More.}\normalsize + % }}} +\end{itemize} +% }}} +% Projects {{{ +\resheading{Projects} + +\small{A more complete list of my projects is on my website +(\url{https://tozt.net/projects.html}). All of my personal open source work is +also available on GitHub (\url{https://github.com/doy}), and my Perl open +source work is also available on the CPAN +(\url{https://metacpan.org/author/DOY}).}\normalsize\vspace{-3pt} + +\begin{itemize} + % termcast {{{ + \item \resshortsubheading{Termcast (\url{https://github.com/doy/python-termcast-server})}{2014--present} \vspace{6pt} \linebreak + \small{I wrote a server and client to allow users to stream their terminal + sessions over the network for other people to watch.}\normalsize + % }}} + % libvt100 {{{ + % \item \resshortsubheading{libvt100 (\url{https://github.com/doy/libvt100})}{2014--present} \vspace{6pt} \linebreak + % I am the author of libvt100, a terminal parsing library written in C + % and Lex. I am currently using it in the Termcast server and in Runes, a + % terminal emulator. + % }}} + % Text::Handlebars {{{ + % \item \resshortsubheading{Text::Handlebars (\url{https://github.com/doy/text-handlebars})}{2013--present} \vspace{6pt} \linebreak + % I am the author of Text::Handlebars, a port of the Handlebars.js + % templating language to Perl. It uses a custom parser on top of the + % Xslate template engine framework. It supports nearly the entire feature + % set of the JavaScript implementation, and we used it at Infinity + % Interactive to ease the transition of one of our large web applications + % from client side templates to server side templates. + % }}} + % Reply {{{ + % \item \resshortsubheading{Reply (\url{https://github.com/doy/reply})}{2013--present} \vspace{6pt} \linebreak + % \small{I wrote Reply, a lightweight and extensible REPL for Perl. It includes + % many useful features such as tab completion and history support.}\normalsize + % }}} + % Dungeon Crawl Stone Soup {{{ + \item \resshortsubheading{Dungeon Crawl Stone Soup (\url{http://crawl.develz.org/})}{2009--present} \vspace{6pt} \linebreak + \small{I am a member of the development team for Dungeon Crawl Stone Soup, a + roguelike game written in C++ and Lua. I contributed several features + to the game and was also the release manager for the 0.6 release.}\normalsize + % }}} + % Plack {{{ + % \item \resshortsubheading{Plack (\url{http://plackperl.org/})}{2012--2013} \vspace{6pt} \linebreak + % I am a member of the core development team for PSGI and Plack, the + % specification for Perl web server/application interaction (similar to + % Python's WSGI and Ruby's Rack). + % }}} + % Perl {{{ + \item \resshortsubheading{Perl (\url{http://www.perl.org/})}{2011--2013} \vspace{6pt} \linebreak + \small{I was the release manager for the 5.17.1 development release of Perl, + and I have also contributed many bug fixes. I have also been a lead + developer on the p5-mop project, a prototype of a new object system for + Perl.}\normalsize + % }}} + % OX {{{ + % \item \resshortsubheading{OX (\url{https://github.com/iinteractive/OX})}{2011--present} \vspace{6pt} \linebreak + % I am the lead author of OX, a web framework for Perl based on the PSGI + % specification, which uses the Bread::Board dependency injection system + % to manage application components. We have used it internally at + % Infinity Interactive for many client projects. In addition to writing + % most of the framework itself, I also wrote a series of advent calendar + % posts documenting it, which can be seen at + % \url{http://ox.iinteractive.com/advent/}. + % }}} + % Moose {{{ + \item \resshortsubheading{Moose (\url{http://moose.perl.org/})}{2009--2013} \vspace{6pt} \linebreak + \small{I am a member of the development team for Moose, which provides + advanced object orientation capabilities to Perl. I was also the + release manager from 2011--2012.}\normalsize + % }}} + % TAEB {{{ + \item \resshortsubheading{TAEB (\url{http://taeb.github.io/})}{2008--2011} \vspace{6pt} \linebreak + \small{I was one of the lead framework developers for TAEB, a Perl framework + for programmatic interaction with NetHack. I was also the primary + developer for the leading AI written for TAEB.}\normalsize + % }}} + % Volition {{{ + % \item \resshortsubheading{System for Defining, Documenting and Recording Game Events (\url{http://volition-inc.com/})}{2007--2008} \vspace{6pt} \linebreak + % This is a library written in C which can be added to games in order to + % track arbitrary events and report them to a remote server, for use in + % gameplay testing. This project was completed for Volition as my senior + % project, and was used as part of their testing process for Saints Row + % 2. + % }}} +\end{itemize} +% }}} +% Talks {{{ +\resheading{Talks} + +\small{Slides and videos (where available) for these talks can be found at +\url{http://tozt.net/talks.html}.}\normalsize\vspace{-3pt} + +\begin{itemize} + \item \resshortsubheading{Introduction to Rust (50 min)}{YAPC::NA 2014} \vspace{6pt}\linebreak + \small{This talk describes the Rust programming language, touching on + its major features and design philosophies that make it + interesting.}\normalsize + \item \resshortsubheading{Dependency Injection with Bread::Board (50 min)}{YAPC::NA 2012, YAPC::EU 2012} \vspace{6pt}\linebreak + \small{This talk provides an overview of dependency injection, and + gives concrete examples of it using the Bread::Board module for Perl.}\normalsize + \item \resshortsubheading{OX - the hardest working two letters in Perl (50 min)}{YAPC::NA 2011} \vspace{6pt}\linebreak + \small{This talk describes the OX web framework for Perl, including a + conceptual overview and usage examples.}\normalsize + \item \resshortsubheading{Extending Moose (50 min)}{YAPC::NA 2010} \vspace{6pt}\linebreak + \small{This talk goes into detail describing Moose's meta object + protocol, including what it is, how it works, and how you can extend + it.}\normalsize +\end{itemize} +% }}} +% Skills {{{ +\resheading{Skills} +\begin{description} + \item[Languages:] \small{I am fluent in C, C++, Perl, Lua, and shell, and I am also proficient in Python, JavaScript, HTML/CSS, Scala, Rust, and LaTeX.}\normalsize\vspace{-6pt} + \item[Tools:] \small{Make, vim, git, Firefox}\normalsize +\end{description} +% }}} +\end{document} diff --git a/content/resume.txt b/content/resume.txt new file mode 100644 index 0000000..4c492eb --- /dev/null +++ b/content/resume.txt @@ -0,0 +1,110 @@ +Jesse P Luehrs +============== +Address: 702 W. Green St., Apt #2 + Urbana, IL 61801 +Phone: (618) 616-6287 +Email: doy@tozt.net +Website: http://tozt.net/ + +========= +Education +========= +University of Illinois at Urbana-Champaign, College of Engineering +Urbana, IL +Bachelor of Science in Computer Science +Aug. 2004 - May 2008 +- Overall GPA: 3.61, Technical GPA: 3.81 +- James Scholar in Engineering (2004 - 2005) +- Dean's List (Fall 2004 - Fall 2006) +- Graduated with Honors + +=============== +Work Experience +=============== +UIUC Hydrogeology Lab +Urbana, IL +Visiting Research Programmer +February 2006 - present +- Worked on the Geochemists' Workbench, a geochemistry software suite + written in C++ and Tcl/Tk. +- Added or enhanced support for several different image output formats + including PDF, SVG, and PostScript, including adding TrueType font + embedding to PDF and PostScript files. +- Helped add parallel processing support to several scientific + calculations, using OpenMP. +- Designed a new XML-based configuration file format for our + applications. +- Ported our calculation applications to Linux, to allow them to be run + on large clusters. +- Implemented a testing framework for our calculation applications in + Perl, using Test::More. + +Smile-A-While Amusements +Traveling, Illinois/Indiana/Missouri +Concessions manager +Summer 2004 and 2005 +- Managed several amusement games on the Luehrs' Ideal Rides carnival. + +======== +Projects +======== +Moose (http://moose.perl.org/): 2009 - Present +- Member of the Moose Cabal, the lead development team for Moose. +- Wrote several extensions for Moose, including MooseX::NonMoose, which + allows classes built with Moose to easily interoperate with other + types of classes, and MooseX::Aliases, which allows Moose attributes + to be referred to by different names. + +Bot::Games (http://github.com/doy/bot-games): 2009 - Present +- Bot::Games is an IRC bot framework written in Perl, designed for + multiplayer game moderation. +- Uses Moose extensively to provide a clean and extensible plugin system + for adding games. + +TAEB (http://taeb.sartak.org/): 2008 - Present +- TAEB is a Perl framework (using Moose) for programmatic interaction + with NetHack (http://nethack.org/). +- Primary developer for the leading AI written for TAEB. +- Developed several standalone Perl modules in the course of + development, including Graph::Implicit, which implements several + useful graph algorithms, and IO::Pty::Easy, which provides a simple + read/write interface for interacting with pseudo-terminals. + +Smithy (http://sourceforge.net/projects/smithy/): 2008 +- Smithy is a cross-platform map editor for the Aleph One engine + (http://marathon.sourceforge.net/), written in OCaml. +- Contributed several GUI improvements, including writing custom widgets + using LablGTK. + +System for Defining, Documenting and Recording Game Events + (http://volition-inc.com/): 2007 - 2008 +- This is a library written in C which can be added to games in order to + track arbitrary events and report them to a remote server, for use in + gameplay testing. + +LuaIRC (http://luaforge.net/projects/luairc/): 2006 - 2008 +- LuaIRC is a fully-featured IRC framework written in Lua. +- Supports all standard IRC functionality, including CTCP and DCC. + +====== +Skills +====== +Languages: +- Proficient in C, C++, Perl (CPAN id: DOY), Lua, Bash, OCaml +- Working knowledge of Ruby, Tcl/Tk, JavaScript, LaTeX, HTML/CSS, + PostScript, sed +Operating Systems: +- Linux (Arch, Debian, Gentoo) +- Windows (2000, XP) +Tools: +- Make, Vim, Microsoft Visual Studio, Cygwin, Darcs, Subversion, Git + +========== +Activities +========== +Inline Insomniacs: +- I was the webmaster for the Inline Insomniacs rollerblading club from + 2005 until 2007. +Falling Illini: +- I was a member of the Falling Illini skydiving club from 2007 until + 2008. diff --git a/content/talks.md b/content/talks.md new file mode 100644 index 0000000..3759321 --- /dev/null +++ b/content/talks.md @@ -0,0 +1,15 @@ +--- +title: "talks i've given" +resources: + - name: slides + src: "talks/extending_moose_yapc_na_2010/001.html" +--- + +* YAPC::NA 2014 - [Introduction to Rust](http://www.yapcna.org/yn2014/talk/5360) ([video](http://youtu.be/5EFCMaEbgX4), [transcript](https://github.com/doy/intro-to-rust-yapc-na-2014/blob/master/talk.md), [slides/examples](https://github.com/doy/intro-to-rust-yapc-na-2014/tree/master/examples)) +* YAPC::EU 2012 - [Dependency Injection with Bread::Board](http://act.yapc.eu/ye2012/talk/4181) ([video](http://youtu.be/Xpk7AV90gd8), [slides](/talks/bread_board_yapc_eu_2012.pdf), [source](/talks/bread_board_yapc_eu_2012.key)) +* YAPC::EU 2012 - [TIMTOWTDI in 2012](http://act.yapc.eu/ye2012/talk/4182) +* YAPC::NA 2012 - Dependency Injection with Bread::Board ([video](http://youtu.be/DhhaOQWoOpw), [slides](/talks/bread_board_yapc_na_2012/), [source](/talks/bread_board_yapc_na_2012/slides.vroom)) +* YAPC::NA 2011 - [OX - the hardest working two letters in Perl](https://web.archive.org/web/20110709062708/http://yapc2011.us/yn2011/talk/3251) ([slides](/talks/ox_yapc_na_2011/), [source](/talks/ox_yapc_na_2011/slides.vroom)) +* YAPC::NA 2010 - Extending Moose ([slides](/talks/extending_moose_yapc_na_2010/), [source](/talks/extending_moose_yapc_na_2010/slides.vroom)) +* YAPC::NA 2010 - App::Termcast - share your terminals! (lightning talk) +* YAPC::NA 2009 - [Botting NetHack with TAEB (lightning talk)](https://web.archive.org/web/20120323005415/http://yapc10.org/yn2009/talk/2148) diff --git a/content/work.md b/content/work.md new file mode 100644 index 0000000..20bce0e --- /dev/null +++ b/content/work.md @@ -0,0 +1,8 @@ +--- +title: "work" +--- + +I currently work for Stripe and am not actively seeking employment. My (not +particularly up to date) resume can be found here: + +[My resume](/resume.pdf) ([LaTeX source](/resume.tex), [plaintext](/resume.txt)) -- cgit v1.2.3-54-g00ecf