Monthly Archives: February 2008

Furthering my Forth education

Forth [wikipedia] is a programing language that at first seems like a fairly simple language, no more high-level than C, but then as you look at some of the abstractions that arise in code produced by experienced forth programmers, you realize that you’re going to have to expand your mental model of the language to properly understand these (very useful) abstractions. It’s similar to looking at the Lisp written by experienced Lisp programmers.

I’ve been thinking about Forth a little more since reading parts of Stack Computers.

This comment on Lambda the Ultimate finally made some of this return-stack trickery more understandable to me.

Also, the tutorial pointed to is interesting:

I’ve been collecting Forth-related links for a while on my

Making the delete key work in screen (termcap capabilities)

I believe this is something I figured out long ago, and completely forgot since, so I had to figure it out again. I’m using a new virtualized Linux server from Slicehost, and as usual, I have some stuff running under Screen. Now, Screen is a crufty old program, but it’s immensely useful for leaving things running and detaching from them (and later reattaching), along with multiplexing several terminals into one.

But, I started having a problem I’d had before. Inside screen, my delete key wasn’t sending ^? (ascii 127), but it was sending ^[[3~ (the escape sequence for that key). Outside of screen, it was sending ^? as I’d expect. (I’m going to avoid the whole backspace [^H] versus delete [^?] argument here — OS X and Linux distributions seem to all come with it configured for delete out of the box these days, and that’s most of what I deal with.)

I poked around, and found some workarounds like this one, but I really want to fix it, rather than lying to it about my terminal type.

This did however remind me of what was wrong. My termcap (well, terminfo) was missing the proper capability for the delete key. So, I looked what the terminal type claimed by OS X’s was:

$ echo $TERM

I poked around some .screenrc examples and an old termcap file and composed this line to put in my .screenrc :

termcapinfo xterm-color kD=\E[3~

And it works! I didn’t even have to start a new screen session, I just detached and re-attached.

First FPGA project ideas

I decided recently that I want to really learn computer hardware design. Not just the theoretical “I know how the machine works” understanding, but actually having done it. So, the obvious thing was to get an FPGA and design stuff using it. fpga4fun was some of the inspiration for this. I ended up ordering one of their Cyclone II boards after deciding that I was going to play with the Altera stuff (Xilinx has comparable parts. For more sources of FPGA dev boards, see Sparkfun(only one), Digilent, and XESS.) The Altera software (Quartus II) seemed a little bit less obtuse. Otherwise I can’t say I found myself strongly in favor of one or the other. As for Verilog versus VHDL, I’m learning Verilog because it’s more readable, and more commercially popular (at least in the USA). Once I understand what I’m doing, I’m sure I can learn VHDL later.

Over the weekend, I’d been playing with the free version of Altera’s Quartus II software, writing a bit of Verilog and seeing what it compiles into. The Cyclone II EP2C5 is a reasonably capable part — 4608 “Logic Elements” (each is a 4-input lookup table — 4 bits in, 1 bit out, any truth table), carry chain logic, a register on the output, various stuff to connect it locally, across the chip, and to the clock distribution network), 119808 bits of ram in “block ram” scattered about the chip, 13 18×18 multipliers, and 2 PLLs for clock generation.

So, I got to thinking that a suitably hard project is a modern reimplementation of the 1980s home computer / game console. This would consist of a number of subprojects:

  • a CPU — probably early MIPS, R2000/R3000 or something. a subset of MIPS32. Not too hard to understand, I still have the Patterson and Hennessy textbook that gave a pretty nice introduction to it. Also, existing GCC support.
  • SDRAM controller — having looked at a datasheet, supporting a single 4Mx16 SDRAM chip shouldn’t be that hard.
  • Display controller. Low-color-depth VGA wouldn’t be too hard, but then I’d constantly have to hook a VGA monitor up, etc. A more interesting choice seems to be to support one these Sharp LCDs
  • SPI interface to an SD card. Have the first stage bootloader in the FPGA block ram load code from here into the SDRAM.
  • USB low-speed host controller, really only supporting keyboard/mouse/joystick. Another challenging piece, but not that bad
  • Serial port for debugging software.
  • Sound controller. Maybe an all-digital implementation of the SID in a C-64, or maybe the much simpler sound chip found in the TI 99/4a, IBM PC Jr., Sega Master System, etc.

So far, I’ve written Verilog for parts of a 3 voice + 1 noise sound chip (the simple one above), and I’ve implemented a register file and an ALU. Most importantly, I figured out how to use the right idioms to make the register file out of block ram, instead of consuming a quarter of all the logic elements on the chip.

But, wow, that’s a big first project. While I can design and test it piece by piece, I think it might be more fun to start out with something simple: A 16 bit stack-based CPU, interfaced to the on-board block ram (only about 13K bytes), with a serial console. I’ll have to cobble together some sort of assembler, but that’s not that hard. Especially when the instruction set is simple. I’ve been reading Stack Computers for inspiration.

Another possibility, instead of a stack CPU is some kind of stripped-down mips-like 16 bit architecture. You get into some compromises with 16 bit instructions if you want a reasonable number of instructions and the usual 3-operand instruction format, though.

(For more links, see my

Touch sensor tweaking

The one thing that wasn’t quite behaving right about the LED lamp was the touch sensor. I was having trouble both with it being far too sensitive (and sensitive to interference from other devices nearby — I’d plug in my laptop to an adjacent outlet and it would sense a “touch”), but also it was often not self-calibrating properly.

So, I reread Quantum Research Application Note AN-KD02, “Secrets of a Successful QTouch Design”, and I finally tried properly doing the procedure in section 3 for probing the sensor field. And I discovered one thing: the Rsns value I’d previously guessed at was far too small. I was using 1K, while I got the appropriate sort of risetime with about 18-25k. I decided that Cs was probably also far too high, so I tried reducing it from .044 uF to .022 uF.

It’s a little bit less sensitive now — you have to touch the area on the outside of the glass with at least a couple fingertips, but it’s far more reliable and less prone to interference.

Also, it seems to be recalibrating its threshold more quickly now.

I may try adjusting the value of Cs a little more (need to buy more values of 1206 surface-mount capacitors), but I think I’m almost “done” now.

On another note, I think there’s some FPGA design in my future. It’s got quite a learning curve, but it looks like fun.