Avian’s Blog

Now just to figure out why the characters are flipped...

I finished populating the motherboard with components. I'll start testing it (and burning stuff :) tomorrow.

After bridging around 200 vias with wire I now fully appreciate the invention of through-plated holes.

This is a photo of the board with all integrated circuits and the big extension connector (bottom right) missing.

I just got a finished PCB for Galaksija's motherboard from our Faculty's Laboratory for semiconductor electronics. Thanks!

Update: some more pictures

Today I found this while cleaning up a cabinet in the workshop. It's the first circuit I've put together with the help of my father. Unfortunately it doesn't have a date on it so I don't know when I made this. I also don't remember exactly what I wanted to use this thing for.

It's a simple 1-of-10 encoder made with signal diodes and some LEDs to show the result. It still works :)

First part of Galaksija hardware finished!

Not exactly a Model M, but I guess it will do fine.

Yesterday the last components for the first prototype of my Galaksija redesign arrived. Now I can finally start working on some real circuits instead of just pondering over schematics.

Interestingly the most difficult part to obtain was the Z80 CPU. I had no problem getting one a few months ago when I was repairing a ZX Spectrum, but now nobody seems to have it in stock anymore.

In previous parts, I explained how synchronization impulses are generated and how they get mixed with the video signal from the character generator. I also described how character generator works and told a little bit about what must happen on the CPU bus in order for characters to be drawn on the screen. I also mentioned that everything must be timed perfectly in order for this scheme to work: software must be exactly synchronized with the hardware. As I promised this time I'll go into some detail about how this is achieved.

Synchronization of software execution with asynchronous events is usually done with hardware interrupts. This is a mechanism built into most of the CPUs that enables the designer to run a specific part of the program whenever some signal line becomes active. This mechanism is accurate enough for most purposes, but it is not perfect. For example, the CPU must finish computing the last instruction before it can begin executing the interrupt routine. This means that in the best possible scenario the interrupt timing is only accurate to the order of magnitude of the duration of a single instruction.

If you look carefully at the timing requirements for Galaksija's video circuitry you can see that this is not nearly accurate enough. The timing must be accurate to within one pixel clock period (around 160ns) while the longest Z80 instruction takes 23 CPU clock cycles (which is around 7500ns or 46 pixel clock periods)

Fortunately, the Z80 CPU provides a mechanism that can be used to correct the accuracy of interrupts. But before we go into that, let's first see where the interrupt impulses come from.

This is part of the clock generation circuit. Among other things it generates the video interrupt signal and horizontal and vertical sync clocks:

As you can see, the interrupt line (2) goes high 4ms after the vertical video sync (3). This signals the processor that it should start the interrupt routine and start putting video data on the CPU bus. Why 4ms after the vertical sync? This delay accounts for unused blank lines in the PAL standard that are above the visible area of the television screen.

Now you can see why there is special synchronization circuitry required. Without it the time CPU would start drawing the screen would depend on the interrupt delay, which is not deterministic and the picture would be blurred by those 46 pixels I mentioned before.

To provide better synchronization the following circuit is used:

Here we see the interrupt line (2) coming from the clock generator. U19, U20 and U21 halt the execution of the CPU until a video interrupt sync (5) goes low. If you remember from one of the previous parts, the interrupt sync line comes from the video generator and is basically an inverted horizontal sync impulse.

Let's have a look at signal waveforms at the moment the video interrupt occurs:

When the interrupt occurs, the CPU is executing an unknown instruction. It continues to do so for an unknown number of clock cycles. After its completion it enters an interrupt acknowledge cycle. This is a special version of the M1 machine cycle that produces a specific waveform on the M1 (6) and IOREQ (7) lines. This waveform is detected with a simple logic circuit (U20 and U19) and triggers a flip-flop U21. This puts logical 0 on the WAIT input (8) of the CPU.

Z80 CPU samples the WAIT input in most machine cycles at the falling edge of the CPU clock. If it detects a logical 0, it will halt the execution and insert dummy machine cycles known as wait states until the WAIT line is released.

This is done by the video interrupt sync signal (5) that resets U21 at the exactly the same moment as the first horizontal video impulse after the video interrupt. This causes the CPU to start executing the video interrupt routine in sync with the beginning of the first line to be drawn.

If you look at the previous waveform diagram you can see that there is one half of the horizontal sync period between the video interrupt (2) and the first horizontal sync impulse (that is also the video interrupt sync impulse (5)). Which means that there is plenty of time (approximately 30ms) available for the CPU to finish executing the last instruction and do the interrupt acknowledge cycle.

The mechanism described gives the software in the CPU a very accurate reference point from which all other timing required for the video signal generation can be derived. As you probably guessed the software that does that and actually takes care of feeding the character generator with data is again quite complicated. So the next part of this series of articles will be a bit less about electronics and a bit more about the software that drives it.

Last time I talked about how Galaksija generates a composite video signal. I explained how the vertical and horizontal sync impulses are generated and how they are mixed together with the video signal. In this part I'll describe the part of the circuit that is responsible for generating that last part of the composite signal - the part that is actually carrying information about the picture that is drawn to the TV screen.

If you remember from my last post the video input into the composite video generator is at logic levels. Logical 1 (+5V) on that line means a black pixel and logical 0 (0V) means a white pixel. These levels must change in sync with the pixel clock - a clock signal that determines the length of one pixel on the screen.

Let's have a look at the first schematic:

On the right there is an 8-bit shift register (74HC166) and on the left is the character generator ROM. The ROM data outputs (8) are connected to the parallel inputs of the register. Low ROM address inputs (7) are connected to the Z80 data bus. High address inputs (9) are connected to the latch (more about that later). The pixel clock (1) is connected to the shift register's clock input. The "Shift out" output of the register is connected to the composite video generator (10).

So for every clock cycle the register will shift its contents one position to the right. On the first pixel clock cycle, the highest bit in the register will be on the video line, on the second cycle the second highest and so on until the 8th clock cycle. After that the register will be empty and has to be reloaded through its parallel input (8). For this to happen the "Load scan line" input (5) must be at logical 0 (the "Load enable" register input is active-low). During this time the first positive transition of the pixel clock will shift-in fresh 8 bits (representing the next 8 pixel to be drawn on screen) from the character ROM.

The character ROM obviously contains 8 bit slices of characters that will be displayed on the screen. Lower 7 address inputs determine the character to be displayed (so a maximum of 128 different characters can be displayed) while the upper 4 address inputs determine the scan line (row of pixels) that will be displayed on the current line.

Let's go through this again. The following things must happen for this scheme to work properly:

• Before every row gets drawn on the display the software has to set the proper scan line number on the latch and so set the upper 4 address inputs of the character ROM.
• Every 8 pixel clock cycles there must be a character code present on the processor's data bus.
• In sync with the character code the "Load scan line" input must go low for one pixel clock cycle.
• All this must be synchronized with the horizontal and vertical sync pulses that are added to the signal by the composite video generator.

We'll have a look at how the software does its part and the synchronization issues in one of the next parts. For now let's only have a look how the "Load scan line" gets generated.

Two 3-input NOR gates here form a simple logic circuit computes the "Load scan line" (5) signal from three control signals from the Z80 processor: the MREQ signal (3) goes low whenever the processor wants to access memory, RFSH (4) signal goes low whenever there is a memory refresh cycle and (2) is the CPU clock which is pixel clock divided by 2.

During the time that the picture is drawn on the screen, the Z80 CPU only performs a type of machine cycle that is called M1. Each M1 machine cycle takes 4 CPU clock cycles which is equal to 8 pixel clock cycles. During this time both MREQ and RFSH signals go low at a certain time, meaning that the "Load scan line" can go high for exactly one positive transition of the pixel clock, allowing 8 new pixels to be loaded in the shift register.

Again, here is a time diagram of all signals in this part of the circuit:

If you are familiar with the Z80 CPU you can probably already guess know how the software part of this system works. Next time I'll explain this time diagram in more detail and tell why exactly the correct character code appears on the CPU bus during this machine cycle.

Update: Only 7 data bus lines are connected to the character ROM, not 8. So only 128 different characters are possible.

This map shows locations of Galaksija hardware in Z80's 16 bit address space. The audio output is controlled by two bits of the latch and audio input is read from keys at row 1.

As promised, here is the first part of a detailed description of how Galaksija generates a video signal. This description is based on my modified circuit, so some details may differ from the original, but the basic principles are the same. I will try to point out the key differences later in the text.

This first part is about the lowest level of the video generation circuitry, the so-called composite video generator. The schematic diagram of this part of the Galaksija circuit is shown below.

Before I go into details I would like to point you to some on-line resources about composite video because I will assume you already know what a video signal looks like. The Wikipedia article gives a nice introduction into this subject. You can find a more detailed description, including the description of sync pulses, in an article about analog video. Note that the composite video signal format is the same as the analog video format that is broadcasted over radio and cable TV systems (without RF modulation).

Now let's take a look at the circuit. On the left two signals (2, 4) enter the circuit. They come from the clock generator circuit and are square waves with basic vertical (2) and horizontal (4) synchronization frequencies. Each of these two signals triggers its own monostable multivibrator (one half of the 74HC123 circuit). The monostable multivibrator will give a voltage pulse of a fixed length on its output when the trigger signal goes from logical 0 to logical 1 (positive transition). The 74HC123 circuit used here also gives an inverted pulse on a complementary output. The length of the pulse is set with the RC circuit (R19/C11 for horizontal sync and R16/C12 for vertical - the formula can be found in the 74HC123 datasheet).

So now we have a train of impulses on the outputs of both monostable multivibrators. There are 16000 horizontal impulses per second, each 0.8µs long (7) and 50 vertical impulses per second, each 1.2ms long. If you read the composite video specifications carefully, you should notice that the horizontal impulses are shorter than they should be (PAL standard says they should be 5µs long). The author of the original Galaksija says that that this gives a more stable picture. I haven't checked whether this is true or not, but it should be easy enough to fix if it turns out not to be (just change the values of R and/or C). The vertical sync signal duration is equal to roughly 20 line durations, which is close to 21 lines in the standard.

The sync pulses and their complements are then routed to an XOR gate (composed of 3 NAND gates in the 74HC00 chip). The result is an inverted synchronization signal that is obviously close enough to the PAL standard so that it works with TV receivers. Note that there are no equalizing pulses in the vertical sync interval since Galaksija doesn't use interlaced video.

The sync signal must now be mixed with the video signal (1) that comes from the character generator. Both signals have TTL logic levels (0V for logical 0 and 5V for logical 1) which also need to be adjusted to the standard 0V - 1V voltage levels for composite video. The mixing is done with transistors Q4 and Q5. When there is a logical 1 on the sync line (8), this transistor pulls the output to the ground, which is equal to the sync level of 0V. When there is no sync pulse present, Q4 controls the output. Depending on the state of the video line it can either pull the line down to approximately 1.6V which is 5x reference black level of 0.3V or leave it at 5V which 5x reference white level of 1.0V. These levels are then further divided by approximately 2.3 by the voltage divider R24 / R27. At the output of the divider we now have the video signal at adjusted voltage levels mixed with the 0V sync impulses.

The final stage is an output amplifier Q6 / Q8 which reduces the high output impedance of the voltage divider to 75 ohms as specified in the composite video specification. You may notice that the output voltage levels are still approximately two times what they should be (peak at 2V instead of 1V). This is corrected when you connect a TV receiver to the video output which has 75 ohms of input impedance. This input impedance forms a divide-by-2 voltage divider with the output impedance of the output amplifier.

Note: vertical sync pulse is not to scale on the diagram above.

Some notes on the original Galaksija design: the original uses a RF modulator so it doesn't need the output amplifier. Also the voltage levels of the composite video are adjusted to those needed by the modulator and not to those needed by the composite video input of the modern TV set. The original also lacks transistors because it uses the open-collector outputs provided by chips in the 74LS series.

That's it for today. Next time I'll describe the character generator that generates the video signal (1) that contains the information needed to draw a picture on the screen.

Recently I've been working on a redesign of Galaksija for Cyberpipe's computer museum. People from the museum would like to add this 80's-era computer to their collection and I offered to help them build one.

Galaksija was originally meant as a do-it-yourself project, so complete schematics and ROM contents are available on the net. At first it didn't look like it would be a complicated task to build one with modern components. Soon it turned out that the original author (Voja Antonić) had used a lot of dirty tricks in the computer's circuitry to keep the number of integrated circuits to a minimum. In the 80's he of course had a perfectly good reason for this: integrated circuits were expensive since the government restricted imports of western technology. However this also meant that the circuit relied on properties of certain chips that weren't documented and therefore weren't guaranteed to remain unchanged with new revisions. The result: the original circuit only works with 74LS series logic chips which are a bit hard to come by these days (they were mostly replaced with 74HC/74HCT series) and only works with some Z80 processors (or so I heard from people that built the original Galaksija).

There were some attempts to build Galaksija with more modern components. For example galaksija.org had a schematic of a Galaksija built with a GAL chip instead of discreet logic circuits (the link to schematics disappeared some days ago with the redesign of the page). However they said that this version also had many of the problems of the original (it also doesn't work with all Z80 processors).

So I set out to design a Galaksija compatible computer with the following goals:

• The computer must be completely software compatible with the original Galaksija.
• It should use modern 74HC-series chips instead of 74LS.
• Rely only on documented features of integrated circuits. Integrated circuits are cheap today, so the first priority is to make the circuit work reliably. The number of components comes second. This way the circuit should work with any series of logic chips and would probably only require minor modifications in the future.
• Skip the radio-frequency modulator that enabled the computer to be connected to an ordinary television and use a composite video output instead. All television sets today have a composite video input so including a RF modulator no longer make sense.

So far I spent something like 120 hours on this project and the circuit schematics itself is now more or less finished (you can find the current working draft of the motherboard here). The only thing that remains to be done at this point is to make the layout for the printed circuit board. Unfortunately I have some other things to attend to right now, so this will have to wait. In the mean time I'll try to post here some of the more interesting details of the original Galaksija's design.

Recently I've heard some quite interesting (and wrong) theories from people that are overclocking their CPUs. So I compiled this short list of overclocker's facts together with the underlying reasons on the level of transistor circuits. As far as I know, these simplified explanations are correct for static and dynamic CMOS circuits (which covers all consumer VLSI (CPUs, GPUs, etc.) circuits on the market today).

Heat output is proportional to clock frequency.

Reason: CMOS circuits consume power (and generate heat) only when they switch from one state to the other. Energy consumed by one gate for one state transition is approximately constant, because this is the energy stored in the input capacitance of the next gate in the circuit (static CMOS circuits also consume power for a very short time during state transition when a direct connection of supply and ground lines exists, but the principle is the same). So the power consumption of the whole circuit is proportional to the number of state transitions per second. In a complicated microprocessor a portion of all gates will switch each clock cycle. So more clock cycles per second means more gate switches means higher heat output.

A circuit can operate at higher frequencies when cooled to a lower temperature.

Reason: MOS transistors in a CMOS circuit act as switches. Unlike mechanical switches that have a constant resistance in "on" state, MOSFETs have a more complicated relationship between current and voltage. If a higher current can flow through the transistor at a given voltage, it will charge or discharge the input capacitance of the next gate faster, thus allowing the circuit to operate reliable at more state transitions per second (higher clock frequency). It turns out that the current/voltage relationship for a MOS transistor is proportional to mobility of electrons and holes (charge carriers) in silicon. Charge mobility (see this article) is higher at lower temperatures, so circuits will work faster when cooled.

Heat output is proportional to the square of supply voltage.

Reason: As I mentioned earlier, the power consumption of CMOS circuits comes from charge and discharge cycles of gate capacitances. The energy stored in a capacitor is proportional to the square of voltage on its terminals (W=(C U²)/2). Since capacitors in CMOS circuits are charged to supply voltage and discharged to 0V, each state transition consumes energy that is proportional to the square of supply voltage.

A circuit can operate at higher frequencies when connected to a higher supply voltage.

Reason: Normally when a capacitor is discharged through a resistor, time needed for the capacitor voltage to reach, let's say 25%, of its initial value, is independent of the initial voltage. MOS transistor switch however will let through more current when it has a higher control (gate) voltage. This is similar to the case where the resistor through which the capacitor is discharging has lower resistance. In CMOS circuits, the transistor gate voltage is equal to the supply voltage, so the gate capacitances will be charged or discharged faster with higher supply voltages and the circuit will work with higher clock frequencies.

Some time ago, I read about an interesting PCB etching method that uses ordinary laser printer toner as an etching mask. The mask is printed on a sheet of paper and then transferred from paper to PCB with an clothes iron. I decided to try this approach with a project I'm currently working on.

The author of the original article recommends using special InkJet papers to print the mask. I didn't like that idea because using paper that isn't meant to be used in lasers can have pretty bad effects on the xerographic unit in the printer, so I only tried it with ordinary office paper.

It turned out it still works remarkably well. I got the best results with the following recipe:

I printed the mask on a sheet of 80g office paper (with "toner saving" feature disabled). Then I positioned the artwork on the PCB laminate and taped it on with scotch tape. I heated the paper with iron on setting ●● then immediately firmly pressed down on the paper with an old rag so that all surface of the paper came into contact with laminate. I repeated the heating process a couple of times.

After the laminate cooled, I submerged it in water for 10 minutes or so until the paper became soft. Then I just scrubbed the paper off the laminate with a soft sponge.

The final results weren't good enough to use this technique for etching because for some reason small patches of toner always refused to stick to the laminate. Scrubbing with the sponge removed some more toner and I would have to spend a lot of time repairing the traces manually with a marker. On the other hand it worked great for the silk (text and symbols on the component side of the PCB that identifies components on the PCB).

I'll definitely do some more experiments with this.

My dad found this Intel 387DX coprocessor today. It was still in its original packaging, together with warranty, user's guide and a 3.5 inch floppy with some diagnostic software.

It's interesting how Intel's moto changed over the years. Back then it was obviously Intel. The Computer Inside. which is the opposite of their famous Intel Inside stickers.

Wow, this brings back some memories... Some 15 years ago I used to spend many hours playing that game.

I'm currently trying to repair two Sinclair ZX Spectrums from Cyberpipe's computer museum.

I was told this one was connected to a wrong type of a power supply. After a quick look inside I kind of agree with that. It looks like a small explosion happened in the voltage regulator.

Nothing else on the board appears to be obviously damaged. With some luck replacing the regulator will bring this machine back to life.

I'm currently experimenting with this CMOS image sensor array made by ST Microelectronics. Raw image data is read from it through a 10 bit parallel bus while various settings (like exposure time, etc.) can be adjusted through a standard I²C bus.

These chips are quite hard to come by in shops with electronic components, but are common in (very) cheap web cams and digital cameras (the chip on the picture is from Aiptek Pencam Trio).

The image quality isn't impressive. The sensor has 640x480 pixels and poor light sensitivity characteristic for CMOS sensors.

I've finally finished my keylogger project yesterday.

Actually I finished writing the firmware sometime in December, but it took me a month to find and fix all bugs. Still it doesn't work with all computers and keyboards out there. Old Compaqs are especially problematic and I haven't been able to figure out why they simply refuse to work when the keylogger is connected. Also some keyboards seem to use a different scan code set, since the keylogger will work fine with them in transparent mode but it won't recognize the access password (which is internally stored as a sequence of scan codes).

The final keylogger firmware consists of 1758 lines of C code and uses 4080 bytes of code memory (which leaves exactly 16 bytes of FlashROM free).

I've also made a screencast (Ogg Theora) of the keylogger in use.

Finished circuit board front:

and back:

I also found out that overtone 24MHz quartz crystals don't work here since they tend to oscillate at their fundamental frequency instead of their 3rd overtone. When I used an overtone quartz the keylogger stopped working because the microcontroller ran at 1/3 of the correct clock frequency.

Almost finished with PCB design. Here's a nice composite picture of my current draft.

Schematic editing and capture done with XCircuit, board design with PCB and pretty picture with GIMP.

Success!

The software part of the keylogger is now almost finished. The only part that is missing is the serial EEPROM driver for which I need to make a new prototype board that has the actual EEPROM chip on it. I can't add it to the current board because the EEPROM is in a SMD package that can't be soldered to the breadboard.

It took me two days to debug the software for the transparent logging mode, but now it is working without problems. As far as I can tell it isn't detectable from software. The Linux kernel will still report that an ordinary AT keyboard is attached to it and the LEDs on the keyboard work as usual.

A simple menu is accessible by entering a correct (configurable) sequence of 8 keystrokes. Alphanumeric keys and also modifier keys like ALT and CONTROL can be used in this password, because the key logger saves it as sequence of raw scan codes. Of course all sorts of weird things happen if you activate the menu when some application other than a simple text editor has the keyboard focus. Because the keylogger has no way of getting feedback from the computer it will blindly type the menu text for example in a Firefox window which will then interpret the keystrokes as keyboard shortcuts and you will end with a messed up browser.

The bad news is that all this fancy code takes around 1800 bytes of code memory. This leaves only 200 bytes for the EEPROM driver and playback code, which most likely won't be enough. I guess it's time to look for a bigger 8051 compatible microcontroller. AT89C4051 looks promising since it's pin and code compatible with AT89C2051 I'm using now. I just hope I can get it in Slovenia for a reasonable price.

I'm still experimenting with the prototype board I've made last week. Today I've attached two cables to the board: one for the computer and one for the keyboard. Since proper PS/2 connectors are hard to come by, I've simply bought a cheap keyboard extension cord and cut it in half. You can see the board connected to my computer on the picture below.

At the moment it looks like I've chosen the right software approach. I've been able to put code that reads scan codes from the keyboard to one buffer, code that sends scan codes from a second buffer to the computer and code the copies data between two buffers into 971 bytes of machine code (or 417 lines of C). That leaves more than a kilobyte of space for the code that sends data in the opposite direction and serial EEPROM driver code.

Even though the current prototype is only capable of moving data from the keyboard to the computer and not vice-versa it seems to work surprisingly well (I'm writing this post through the key logger). Regarding the complexity of the PS/2 protocol I didn't expect that the keyboard would be usable if it wasn't able to receive commands from the PC. Caps lock LED and other LEDs aren't working of course.

One interesting thing I noticed is that the keyboard will send a packet containing hex 0xAA to the PC as soon as it is turned on. If I let this packet through, the computer (running Linux) will ignore any key presses. I'm guessing it has sent some command to the keyboard (which won't currently reach the keyboard) and is waiting for an answer. The quick and dirty fix was that I simply added a filter to the key logger code that won't let a 0xAA through.

Unfortunately not :)

This is a simple prototype I've made for testing. It has two diagnostic LEDs that won't be there in the final version and it is currently missing connectors for the keyboard and computer.

I'm currently working on the second software approach. I've managed to pack a simple function that is capable of sending some data with proper timings into approx. 300 bytes of code. I think this leaves enough space for the serial EEPROM driver and the data receiving functions, but the fancy menus in the control mode are definitely out of the question. I also think that I have enough processing power available so that transmission delays shouldn't be noticeable.

I want my key logger to work in the same basic way as the KeyKatcher. This means that it must operate in two distinct modes: In the logging mode, it must only monitor the communication between the keyboard and the computer. In the ideal case it should not modify or affect the communication in any way. In the control mode, it should appear as a computer to the keyboard and as a keyboard to the computer. It receives commands from the keyboard interface and prints information (menu choices, stored data, etc.) to the computer interface.

The problem here is that PS/2 is a pretty complicated two-way two-wire protocol that is not very easy to emulate with a 801 microcontroller. The biggest problem that appeared so far is how to implement the transparent logging mode. I'm currently considering three approaches:

 <-- to keyboard          to computer -->
                 _______
 CLK  ---o------|       |------o---- CLK
         |      |switch |      |
 DATA ---+---o--|_______|--o---+---- DATA
         |   |      |      |   |
         |   |      |      |   |
         |   |   _______   |   |
         |   +--|       |--+   |
         |      | 8051  |      |
         +------|       |------+
                |_______|

This is the hardware approach. When the key logger is in logging mode, the electronic switch directly connects keyboard to the computer and the 8051 is only pasively monitoring the communication. In control mode, 8051 turns the switch off and communicates with keyboard and computer separately. Good sides: key logger is undetectable in logging mode. Low processing and code memory requirements for the 8051 in logging mode, since we are only monitoring the bus. Simple 8051 code (no hard real-time code required). Bad sides: requires an additional chip which means a bigger device.

 <-- to keyboard          to computer -->
                 _______
 CLK -----------|       |------------ CLK
                | 8051  |       
 DATA ----------|       |------------ DATA
                |_______|

This is the first software approach. When the key logger is in logging mode, the 8051 software mirrors signals from the keyboard to the computer side and signals from the computer to the keyboard side. Because the PS/2 bus heavily exploits the properties of the open-collector outputs (the bus line works as a wired-or), the coupling code needs to be pretty complicated (as far as I see, a state machine with 3 states) and must use polling instead of hardware interrupts. Good sides: Low code memory and RAM requirements for the 8051 in logging mode, since we do not need to decode the protocol and/or buffer data on the fly but are only mirroring the bus. Bad sides: Hard real-time code required. CPU intensive in logging mode (not sure if even feasible with 24 MHz CPU clock and 10kHz PS/2 bus clock). Detectable in logging mode since software bus coupling introduces delays and glitches.

The second software approach. The key logger always emulates the computer on the keyboard side and keyboard on the computer side. In logging mode it, for example, receives data from the keyboard, decodes it, puts it into buffer and (when possible) transmits the data on the computer side. The receiving and transmitting code can work from interrupt service routines. Good sides: Low processing requirements for the 8051 in logging mode, since we do not need polling of inputs and state machine emulation. Real-time code contained in interrupt service routines. Undetectable if the computer side fully implements the PS/2 protocol. Bad sides: Large RAM requirement because of buffering. Large code memory requirement because of all decoding and buffering logic.

Basically, the first software approach hits the processing limit of the 8051 and the second approach hits the code memory limit.

Board design in pcb:

Final result:

I've discovered two incredibly cool wireless-network-related things today:

First, I found out that my old Toshiba Satellite 1410 laptop has a mini-PCI port and integrated antennas that I can use with my dual-band wireless card. I bought this laptop years ago when wireless cards were still prohibitively expensive, so I chose a model without wireless capabilities. Now it turned out that this cheaper model also included everything the more expensive did, short of the actual wireless adapter card.

Second, somebody obviously succeeded in hacking the Nokia D211 binary-only driver to work with Linux 2.6 kernel. Nokia D211 is a multimode radio card that supports 802.11b, GSM, GPRS, and HSCSD. I've tried to use it under Linux several times, but unfortunately the source of the official Nokia driver isn't available and the binary only worked with some 2.4 kernels. Unfortunately, Toshiba Satellite 1410 (my only computer with a PCMCIA interface) is only usable with newer 2.6 kernels, so I've been forced to use Windows if I wanted to use D211. I'm definitely going to try this as soon as I'll find some time to install Debian again on this laptop.

After all complications with the payment (6 GBP got lost in the international money transfer, go figure) I've received the mini-PCI to PCI adapter I've ordered. Now I'll finally be able to have some fun with the Atheros-based wireless card I've got at What The Hack from the friendly Meshnode people.

This chipset includes a dual-band (2.4GHz and 5GHz) diversity transceiver, supports IEEE 802.11 a/b/g standards, can operate in AP, ad-hoc and monitor modes and, best of all, has free software drivers for Linux and FreeBSD available.

The only problem is that the antenna connectors are of the U.FL type and it is almost impossible to find a coax cable with that connector already attached. I've only bought one adapter from U.FL to RP-SMA at What The Hack because I didn't notice the second antenna connector for the diversity mode.

The sad thing is that I paid 5€ for it at WTH and if I would order it now from Farnell it would cost me some 25€ plus postage.

I think I'll wait until 22C3 and see if I can get another adapter there.

I'm seriously considering making me one of these. I've seen these displays at 21C3 and What The Hack and they look great.

Full circuit schematic is available and 144 LEDs really don't cost that much.