The Builder of Stuff's Journal

6:14pm: Telegrams still work!
I was delighted to find that you can still send telegrams. How cool is that?

http://www.telemessage.co.uk/telemessage.asp?Cat=Message

Next project: TELEX.

2:35am: Practical uses for LED Technology
Well, I just couldn't resist getting a few of those new bright white LEDs to play with, so I bought myself three.

What for? Well, I have an age-old plan to build a wearable computer that had been on my back burner for many years due to a lack of resources, but lately it's occured to me that I do actually have enough tools now to at least start on it.

The kind of wearable computer I want isn't just a PDA that straps onto me with a head-up display - it's more of a cyborg exoskeleton.

So the first part I have built is the head mounted display. This is easier for me than it would be for many people; the vision in my left eye is very poor and lenses won't correct it. Bright light gives me a stabbing pain in that eye, and it can't focus. So I took a pair of comfy welding goggles, remove the left lens, and replaced it with a round PCB that mounted the three white LEDs on the front (plus current control resistors) and two columns of three dim red LEDs on the back (which I can see well enough to read Braille from). After drilling holes for the front LEDs through the sheet of clear plastic that protected the welding filter and placing that over the PCB to keep it dry and clean I mounted it in place of the filter, and began to experiment with it in practice. I've nothing to drive the 6-LED braille display yet, but the three white floodlight LEDs cast a bright enough glow to enable me to wander around in otherwise-unlit rooms and work easily!

I've brought the cable from the head unit down to an 8-pin DIN connector (ground, floodlight LED power, and power lines for each of the 6 display LEDs).

I've got a 6-volt sealed lead acid battery, which I've temporarily mounted a socket on such that it powers the floodlight LEDs. I've tried wearing the headset for a day with no ill effects, and in the bright sunlight it kept my left eye mercifully shielded, with only a faint glow penetrating the PCB.

I'd worried that the total left-eye blackout would cause my right eye to strain, but it was fine. In practice I wouldn't be wearing it much indoors anyway, so a whole day wearing it while using a computer was probably a worst-case test of its eyestrain inducing abilities.

The one downside was that the right hand side - even though I had removed the welding filter leaving just the clear plastic - did restrict my peripheral vision to an annoying extend thanks to the black plastic moulded surround. So I've bought a pair of polycarbonate safety glasses, which are entirely transparent, and am working on fixing the right hand side of them to the modified left eyepiece of the welding goggles to create something that does not restrict my field of view while still having structural solidity to support itself.

Plus it feels kind of nice to have a few millimetres of hardened plastic between the world and my only working eye!

To control the six braille LEDs, however, I am planning to finish off my Z80 project. This has been somewhat delayed by the annoyingly awkward design of the Eurocard matrix board I purchased, with holes so large I'm finding it hard to get good solder joints across them. So to get that moving again I've ordered an alternate board that Maplin sell. Wish me luck...

The I/O capability I am planning is:

1. RS232, so it can be a dumb terminal and for data transfer with my Unix systems


2. The six LEDs in my left-hand visual field


3. A wrist-mounted box containing an LCD dot matrix panel (the largest I can afford at the time), a six-button braille chord keypad for text entry, a tiny digital joystick or four-way arrow keypad and 'select' button, two high-brightness green LEDs I have handy, and two toggle switches that directly control the eye-mounted and wrist-mounted LEDs (I don't see any point in having them uP controlled). I'd also like "display message" and "repeat message" buttons for the head mounted display driver (see below)


4. IrDA. I think Bluetooth is overrated; being able to point at a device with my wrist-mounted transceiver is a very natural way to select from a number of devices. Particularly if I mount a small laser diode on the wrist unit for aiming, which will also be useful as a laser pointer.


5. A real time clock

The hardest part are the serial interfaces, IrDA and RS232; I'm still researching the best chipset to use. Presumably I can share a DUART between the two of them. But the others can all be handled via simple parallel buffers or latches wired to the data bus.

I need to obtain a smaller ROM, since I only want a very small 'basic executive' system in ROM and the rest in battery-backed RAM. The main loop in the ROM will start at the bootstrap address, so if the machine gets stuck in an erronious RAM-based routine, escaping will be a simple matter of hitting a reset button.

The software architecture I'm planning is thus:

• The ROM implements a basic LISP-ish system with mark/sweep garbage collection


• The LISP compiler would produce basic Z80 machine code; it wouldn't try to optimise. However, basic functions would be hand-coded in Z80 assembly.


• The main loop in ROM consists of polling the I/O devices and examining the real time clock to look for 'conditions' that need handling, then calling every handler listed for that condition in a RAM table. Key press and joystick activity conditions would be handled by the keyboard driver, for example, while alarm conditions from the real time clock (or presses of the 'repeat message' button) would be used by the display driver to flash Braille characters into my left eye in sequence from a message buffer.


• Garbage collection occurs if there are no conditions to perform on an iteration of the main loop.


• The head mounted display driver would have three modes: Idle, Message Waiting, and Working. In Idle mode, the LEDs do nothing other than offer direct feedback of the state of the chord keypad. In Message Waiting mode, a single LED illuminates to tell me a message is waiting in the buffer, in which case pressing the Display Message button will cause it to enter Working mode. In Working mode it displays each character of the first message in turn until the message is complete, whereupon the message is put into the single-message history buffer and removed from the pending message queue, in which case the driver either goes into Idle or Message Waiting mode, depending on the presence of further messages in the buffer. In either Idle or Message Waiting modes, pressing Repeat Message will cause the message in the history buffer to be pushed into the head of the message queue and Working Mode to be entered, while in Working mode, Repeat Message causes the system to start again from the beginning of the current message.


• The keyboard driver reads chord keypad press/release conditions, joystick press/release conditions, and joystick button press conditions. It passes on characters and control codes (joystick activity and the end-message chord) to the UI subsystem.


• The UI subsystem controls the LCD dot matrix display. It has three modes - Dialogue, Menu, and Editing. In Dialogue mode (the default) and Editing mode, it treats characters as insertions into a character buffer (made visible on the LCD) and joystick events as edit control - left and right moving the cursor, down deleting a character, and up doing nothing (for now). Sending an End Message character causes (in dialogue mode) the immediate interpretation of the edit buffer as Lisp source and the clearing of the buffer, while in edit mode it causes the system to be returned to Dialogue mode and the registered edit callback to be called, whereupon the application can retrieve the edit buffer's contents and process it. When the system enters Menu mode, however, the menu browser is invoked. The menu is a tree structure stored in RAM. Every node has a display name (displayed on the LCD), a type, and a parameter field. The type controls what happens if the node is chosen from its siblings. Callback nodes cause the system to return to dialogue mode and the parameter address to be called, while subtree node's parameters point to a list of nodes for the submenu; computed subtree nodes point to a function that returns a node list for the submenu. Edit nodes point to a single-element list, whose element is displayed in Edit mode, with a callback that replaces the list element pointer with the new value and returns the system to menu mode with the just-edited node selected.

Actual applications would exist as functions stored in the global namespace - which can be executed just by typing their name and arguments and hitting End Message - and/or as entries in the system menu - which can be executed by hitting the joystick button then navigating to them. The IrDA system would use a computed submenu node which, when invoked, would query for an IrDA device and then provide an appropriate submenu depending on the device type.

I'm not totally happy with the programming complexity of the event-driven system - I may decide to go for a system where the actual flow of control is entirely up to the application, with a root dispatcher providing function invocation and menu access to applications that then control the CPU until explicitly exited, but in that case I'll probably go for a task switching system where applications are "backgrounded" by a special button that suspends them and returns to the menu/dialog executive. That backgrounding would have to be done with the implicit consent of the application, since it could only happen when the app had passed control to the UI subsystem to request user input so the suspend button was being polled. The reset button would kill the application by returning directly to the menu without saving state, for exiting buggy apps.

I think I can get away without any interrupts, but if not, I'll use Z80PIOs and Z80SIOs so the interrupt logic is handled for me.

I am quite tempted to have the LISP code all interpreted (apart from hand-coded core functions) in order to enable the OS to keep regaining control to poll the buttons, to allow easy multithreading, debugging, and so on. But I'm not sure if the speed will be acceptable.

But anyway - the idea is that I'll be able to tap out basic commands by touch alone and see the responses as messages in the head-mounted display, only needing to consult the LCD for bulk s-expression entry and menu browsing (which would both be unpleasant with a single-character display). And event notifications (such as pre-scheduled alarms from a diary app) could interrupt me by flashing into my left eye, too.

Watch this space...

6:08pm: LED technology
Back when I was a kid, LEDs were dim red things; the green and yellow versions were even dimmer. If you hooked them up to a 20v power supply they'd be bright for about a tenth of a second, then the little chip inside (firmly in the grip of thermal runaway) would melt itself away from its electrical connections.

But over the past couple of years, not only have blue LEDs emerged - something I remember being told was 'impossible' due to the colours of LEDs being defined by the distances between energy levels in atoms, and there only being a fixed repertoire of energy levels available to us - but also the available brightness of LEDs has skyrocketed.

I saw this firsthand for the first time in a bar off of Brick Lane, London; they had a strange rectangular light, painfully bright, that cycled through all the colours of the rainbow. By staring at it I realised that, as I suspected, it was a grid of red, green, and blue LEDs of inredibly brightness, with the relative intensities shifting to alter its colour.

Since then, I have seen the rise of the LED torches, bringing forth brilliant light from a tiny point that, intuitively, looks as if it must be incredibly hot like a welding flame to produce that bluish brilliance but is actually cool to the touch.

And I have also seen something I've long predicted; LED arrays being used in traffic lights and for the light clusters on the backs of buses, more for their long lifetime rather than energy efficiency.

Are the days of filament and flourescent lights coming to a close? Will our homes soon be lit by white LED arrays behind translucent diffusers?

I hope so - they are very energy efficient. And they're high tech! :-)

However, I've yet to find any explanation of how blue LEDs work, nor how LEDs in general have become so much brighter lately. Anyone know?

11:55pm: RFC.net
RFC.net is back up on new hardware! Yay! This time it ought to stay up...

Visit it to get hold of nicely indexed and hyperlinked RFCs, STDs, BCPs, and FYIs!

11:41pm: Not building stuff!
Ok, ok, I've not built anything interesting in ages.

But no! I've not become boring. Instead of building stuff, my attention has been held by my software research lately... I was originally intending to keep this blog for hardware stuff only but if I'm going to go on software binges for months I guess I should relax that rule after all.

Lately I've been working on packet and protocol diagrams for an implementation of MERCURY - and in the process deciding I ought to define IRON first and just use that to handle the packet building, so my packet diagrams have ended up as IRON type definitions instead and a mental note to finish defining the details of IRON.

I've also been living it large on XML-DEV with my usual ranting about how XML sucks for data transfer! See their archives for details :-)

11:29pm: Mmmm, DSL...

...it's back! Ah....

9:57pm: Still alive!
I'm not dead, and I've not given up my LJ :-)

Just a bit snowed under with day-job-work, my-own-company-work, and failing hardware (not only has my server been down for 3.5 days this past month, the home DSL is dead too so I'm typing this on a SCUMMY DIALUP).

Day job work: With the moron boss gone, and now head of my own department, I am FREE! Free, that is, to spend lots of time discovering moronic things the moronic boss has left behind. The network was a minefield; while tidying that up I discovered a good five or six configuration 'mishaps' that weren't breaking anything but caused things to break when touched. Nice. But still - a month on, we're coming out of the shadow, and a couple of subprojects have now occurred which have gone from start to end without falling afoul of crapness hiding in the systems, and people from other departments are noticing improvements in throughput. Yay!

Own company work: Paperwork galore :-) Lots of bills, invoices, payments, annual return, corporation tax return, VAT returns...

Dying hardware: Oh, don't ask.

So the Z80 development board is currently peeking out from underneath a pile of paperwork, and the oscilloscope has yet to be used for anything more interesting than looking at my own voice waveforms...

11:10pm: Oscilloscope
Rock on!

I've got a 'scope.

Not a very high end one - 10MHz single channel analogue - but it was cheap and it'll do for taking a quick peek at the activity on Z80 system control lines - I've already been playing with wiring it up to an RS232 line today, too; I can use it to reverse engineer the strange synchronous RS232 my serial terminals talk...

10:59am: I've not had time to do much electronics these past couple of weeks - been busy with other bits of life.

But I've been reading; Babani do an interesting book on surface mount technology for hobbyists. Apparently, it's quite practical to make your own surface mount boards and mount devices on them, indeed this book claims that once you've got the hang it's easier than using pin-through-hole devices.

Downer is, there's no such thing as surface mount Veroboard, so you pretty much have to make your own PCBs. I'd rather avoid doing that for the time being.

ISBN 0-85934-411-8 for the interested.

Hopefully I'll be back onto the Z80 project in a week or two!

Oh, and about then I'm going to visit the technical side of my family and we're going to build a Van de Graff generator and make our hair stand on end. Tee hee!

11:02pm: PLD success!
Flatmate and I got the PLD programmer going today!

Turned out that, although the software had an option to upload the JEDEC file to the device, this was inexplicably turned off for the device the kit came with - but you could do it manually with another program.

We started with a sample circuit that was an AND of two input pins, taken through a D flip flop clocked from the system clock, to an output LED. It worked as expected!

So we fiddled with the schematic editor for a bit to get the hang of wiring things together, then added inverters to the circuit to make a lit LED signify one instead of zero and that kind of little luxury. Then we made the output the XOR of the AND gate and the clock, to make the LED flash (with the clock at 2Hz).

Then I got bold and wired up 6 T flip flops in a chain to produce a ripple counter, and sure enough it counted binary. Then we wired a button to enable or disable the counting, set the clock to 64Hz, and made a game of releasing the button as soon as it had counted to 111111 and lit all 6 LEDs :-)

Then we got bored and put it away. Now we know how to work it, it will wait until we need it for something serious.

Another toy in the box...

10:45am: Mmmm, PLD...
I've got a PLD starter kit. Based on the Lattice Semiconductor ispMACH series, which uses a standard JTAG programming/testing port to load the fusemap into the device.

I've waded through getting a licence file for the yukky strange Windows software, but I won't have the right power supply for the board until tonight.

It comes with a bewildering array of little programs that interoperate in confusing ways, involving about fifty different file formats all of which seem to say the same thing in different ways.

I hope to get them figured out tonight in order to start blowing my own logic into the thing, but in the end I want to figure out the format of the serial bit stream itself so I can make my Z80 system dynamically reprogram the device on demand, allowing me to write software with embedded hardware for the time critical parts, which strikes me as wicked cool.

But, I hear some of you ask, WTF is a JTAG PLD?

Well, a PLD is a Programmeable Logic Device.

The simplest kind of PLD - an sPLD - is a big matrix with input lines coming in from one side and internal 'product term' lines going out of another side. Each cell in the matrix is programmed to be enabled or disabled, and the cells are wired such that each product term line is the AND of all the input lines which have the switches enabled at the cell where the product term line crosses that input line.

All the product term lines then go into a similar matrix that comprises ORs instead of ANDs. The outputs of this are the outputs of the chip itself, although many designs have programmeable flip flops on the outputs that can be wired to latch them on a shared clock or to use another output as a clock signal, et cetera.

What this means is that you can take any logic expression and use mathematical techniques to normalise it into ORs of ANDs of inputs (and possible the inverses of inputs; I forgot to mention that each input is split into itself and its inverse before going into the AND matrix), which can be converted into a huge bitmap which is fed into the device to select which gates to enable.

A cPLD is a complex PLD. The one I have - a Mach 4 64/32 - has four sPLDs inside it connected by a 'switching matrix' that allows the inputs and outputs of the sPLDs and the pins of the chip iself to be wired up however suits you. Since the sPLDs have their own flip flops on the outputs, as well as seperate output flip flops on the logic pins, you can have entire state machines inside the chip using feedback loops through the switching matrix; it can do some pretty damn complex stuff, that you might consider using a PIC for normally. The software comes with examples such as an alarm clock, a dice game, and so on. There are 32 I/O pins and 64 internal flip flops; I also have a 32/32 with only 32 internal flip flops, for simpler logic circuits.

They make a 512/384, which you can use to implement things like PCI interfaces, DRAM controllers, and other such stuff normally from the domain of LSI.

At the top end of the cPLD space is the fabled FPGA, Field Programmable Gate Array. An FPGA is a truly vast array of cells, each connected to its neighbours and usually with a number of array-wide bus lines to play with too. Each cell tends to have 4 or more inputs and a similar number of outputs, and is either a tiny PLD or an EPROM which just gets programmed with the desired truth table.

They're more flexible than other PLDs, which tend to have a certain 'shape' of circuit hardwired into them, and they tend to manage much higher gate densities by having simpler interconnections, but they're loads more expensive.

Anyway, the last part of today's lesson in JTAG. JTAG is a four-wire interface originally designed for testing boards in mass production. The idea is that JTAG-compatible ICs are all wired onto this bus on the board, and a four-pin connector can be used to connect to the board and issue serial commands to put the ICs into test mode, whereupon all their inputs can be read out through the JTAG and their outputs overriden with test data. This is used to test the interconnections on the board, and to run test patterns through non-JTAG devices that are bordered by JTAGs.

However, IC manufacturers realised you could use the same interface to program devices such as EPROMs, PLDs, and PICs at the same time as testing them, thus saving manufacturing steps. Also, it would be possible to use the JTAG port to reprogram boards 'in the field'!

This has led to the exciting possibility (in my mind) of having a JTAG PLD and a CPU closely tied together and allowing the CPU to control the PLD through JTAG. When the OS loads a program, as well as loading the code into RAM it can load the hardware into the PLD. Now, each of the system's IO pins will go both to the PLD and to a Z80PIO, allowing IO between PLD and CPU, CPU and world, or world and PLD.

I've heard of a few groups playing around with genetic algorithms who have 'evolved' FPGA designs. These designs tend to evolve to use analog properties of the gates in feedback loops, and although they tend to be incredibly compact, they stop working as soon as the temperature changes :-)

11:12pm: Relay logic
Once upon a time, people used relays for digital logic.

This was actually pretty cool - apart from the fact that they're large, slow, power-hungry, and that they wear out after a paltry few million operations, they're ideal logic devices - multiplexers.

While it's well known that you can build any (combinatorial) logic circuit out of NAND gates, it's perhaps less known that you can do just the same with relays.

Relays are somehow easier to understand than NAND gates, to a human. Depending on the state of a signal, they connection one line to one of two other lines. You can visualise that.

Anyway, to the point - since I got about fifty telecoms signal relays for free from somebody I've been making little things like a D flip flop and a full adder out of them, just for kicks. But today I was visited by a friend who's good with scarey analog things like capacitors, and he used analog properties of the relay coils to reduce my edge triggered D flip flop design down to one and a half relays! That meaning, the relay that does the clock input can be shared with another flip flop with the same clock.

The trick is this. The clock relay is wired such that the common pin of one if its switches is wired to ground through a 220uF capacitor. When the relay is not energised, this capacitor is connected to the input line, so the capacitor charges or discharges to mirror the voltage of the input.

When it's clocked, the capacitor is connected to the coil of the state relay. The other end of the coil is grounded. One of the relay's switches is rigged so that when it's energised, its coil is connected to +5v so it stays energised.

Now, if the state relay is not energised and the capacitor is charged with a logic one when it's clocked, then the spurt of current as the capacitor discharges to earth through the coil is enough to energise the relay, thus connecting its own coil to the supply. There's a resistor in the feedback loop of the same resistance as the relay coil so the capacitor ends up with a charge of 2.5v on it in equilibrium.

If the input is now fed a zero, then the capacitor will be at 0v when it's switched into the feedback circuit. Since the feedback circuit is at 2.5v at that point, there is a surge of current into the capacitor rather than into the relay coil, meaning it is de-energised and the feedback loop is broken.

Voila! Two D flip flops in three relays!

We're laying out a bit of Veroboard with 12 relays on it to make an 8 bit barrel shift register. It will have 8 LEDs arranged in a circle to show the state of the state relays, and every time you press a button they will rotate one step clockwise. Two switches select between recirculation mode or insertion mode; in insertion mode the loop is broken and the input is fed from a switch so we can clock patterns into the thing then hook it up to a 1-5Hz signal and make it go round in circles (at more than about 5Hz there's not enough time for the capacitors to fully charge / discharge).

We rigged up a 2-bit version on breadboard and it worked a treat.

Fun fun fun!

2:11pm: Vindication!
Heheh - just found out that a 'serial complainer' about the software I write for a living was screwing it all up themselves.

I will not post the details, to protect the guilty.

Hehehe.

10:35am: Stupid surface tension!
Ok, I'm trying to solder together my Z80 design on a "nice" expensive board with power rails and tripads on it - rather than the plain individual-pads board I did the bus debugger on - and it's a right pain. The solder prefers to just flow along the power rails or tripads rather than bonding to the pins, because the holes in the board are too big and the pins sit in the middle of yawning chasms. There's also not a large enough lake of solder attached to the pins - if I'm lucky, a little bridge - to really soak around the prototyping wire and burn off the insulation, so it takes me a long time to get a joint to hold then half of them come undone again.

Nnnngh. Either I need to learn a magic trick for making this easier, or I need to try and desolder all my IC sockets and say goodbye to the wiring combs I glued in place and try again on an individual-pad board, which worked flawlessly and effortlessly for me before.

Nnnnnghghghg!

11:32pm: Something useful to show marketroids and other such nonbelievers
http://www.searls.com/jabberconf_jun02/source/slide01.html

11:34am: Railgun! Fun! Railfun!
Those crazy glubco guys have a homebuilt railgun project.

These guys have a homebuilt railgun project.

These guys have a railgun project and the wills of Gods.

I hope that one day I will have the tools and skills required to build a railgun too. One day.

11:04am: I've got a pair of military surplus field telephones off of eBay.

They will really come into their own next time we go camping - I can wire the tents together with an intercom system. But in the meantime I've wired them between my bedroom and the lounge so the flatmate can yell at me to get up without having to walk to the door and bang on it.

For my next trick, I will fold time and space to make a hyperdimensional balloon animal.

10:38am: I've just found that overdriving my desktop air conditioner at twice the recommended voltage produces a far superior cooling effect and a sound like a small jet aircraft trying to take off. Highly recommended.

12:09am: Eargh, stiff neck
I just spent several hours wiring up a rather convoluted data bus. Only eight bits, but going to and through several devices including an octal tristate buffer. I've built a bus debugging tool - eight debounced output switches, eight LEDs from input lines, and the tristate buffer wired from the switch outputs to the LED inputs so it can drive the bus at the flick of a switch (otherwise, the switch outputs are available on a seperate set of pins).

It's a fairly useful device for somebody planning on building a Z80 based computer. And it's an exercise in soldering lots of tiny little things.

It worked! First time! Despite being made from CMOS devices which I usually break by looking at!