SoylentNews

This is part three of a four part proposal for a trustworthy computer consisting of ALU, registers, memory interface, network cards and compiler. Part three covers networking.

I propose a fairly minimal trustworthy computer implementation which consists of a micro-coded mini-computer using one 8 bit ROM. It has performance which makes a Commodore 64 look racy. However, the redeeming feature is that it meshes well with a card bus bus system which scales from stripboard and DIP chips to PCI-X performance.

It would be extremely useful and practical if such a computer system could have a trustworthy network interface. Unfortunately, I'm not sure this is possible. Implementing a trustworthy UART with logic chips is easy if data integrity is secondary. Implementing a good, trustworthy UART is difficult. Implementing a cell network link layer is infeasible and implementing Ethernet requires VLSI and/or a dedicated processor. Unfortunately, VLSI and dedicated processors are not trustworthy.

Fortunately, it is possible to side-step this problem in a manner which is similar to trusting compilers. In the case of networking, data may be split and sent over two or more separate wired networks. This prevents untrusted network interfaces from ever obtaining sufficient information for a MITM attack. Untrusted network interfaces may maliciously drop packets or delay packets but they cannot inject information into communication. In the trivial case, this covers link layer security over a LAN. This can be extended to higher layers of communication and/or WAN communication.

How do we implement this? We borrow an idea from the counterfeit FTDI serial communication chips. Yes, we use one abuse of trust to counter another abuse of trust. The counterfeit serial chips use a more advanced scale of integration and use a micro-controller to simulate a bank of hardware registers. This is fairly trivial to implement if the parallel or serial bus timings are sufficiently generous. I give a worked example using commonly available hardware. In the untrusted (legacy computer) domain, we may program an 84MHz Arduino Due to use its dormant and relatively undocumented 100Mb/s Ethernet interface and work as a bank of registers within a 10MHz card bus system. The network card may specify 256 × 8 bit registers in which the bottom 64 registers may be a page-banked view of one filtered Ethernet packet in a queue of multiple packets. The card bus parameters are defined such that a wait state must be asserted within 100ns and timeout occurs before 2000ns. Device registers may be simulated with perfect fidelity if the firmware always keeps a 256 byte array in a consistent state. Specifically, the 84MHz micro-controller is able to respond to line level changes and assert a wait signal within 12 cycles. Page-banking is a little more difficult. However, with the reasonable assumption that packet data is always aligned on four byte boundaries and data is moved in multiples of four, a fixed length unrolled loop allows 64 bytes to be copied into the "registers" within 40 cycles (476ns). If line level interrupts for the card bus interface have interrupt priority which is higher than the Ethernet interface then it is possible for an 84MHz micro-controller to work correctly on a 10MHz, asynchronous, parallel bus interface with either:-

• A suitably generous number of bus cycles prior to timeout.
• A suitably constrained register interface.

In general:-

• Any micro-controller may be intercepted before delivery and contain hidden radio links and any amount of malicious code.
• Any micro-controller development environment may have malicious functionality.
• Regardless, an untrusted computer may be used to program an untrusted network interface.
• An untrusted micro-controller of 80MHz or so may operate on a card bus of 10MHz or so and maintain one or more Ethernet interfaces or any speed.
• Multiple micro-controllers connected to separate switches should not be able to collude.
• This requires screened cards, signal isolation along cables, separate power distribution and a split back-plane in which trusted cards are separated from untrusted cards - and each other. Untrusted cards do not belong in the same trust domain. Each untrusted card must have its own trust domain.
• If suitable conditions are met, trustworthy computers may establish link layer security without prior trust. Current systems do not meet these conditions.
• With suitable key management, trustworthy computers may extend trust to the application layer.
• If trustworthy computers provide WAN routing and tunneling, it is possible to extend trusted networking over single runs of cable without distance restriction.

What is lacking in contemporary systems? Parallel buses have an unacceptable level of trust where any dubious card may perform bus mastering and/or specify a vector interrupt address. Serial buses offer some improvement but some provide downward compatibility to parallel bus systems and none prevent covert communication over common wires. The next problem is key management. It would be preferable if trustworthy computers had access to a trustworthy filing system. This requires pieces of keys to be stored across multiple magnetic disks or multiple flash storage units which, again have to placed on separate storage buses and electrically isolated from each other. We're not even considering the case of a trustworthy network filing system. How would you retrieve the keys to access the network without being subject to MITM attack?

We know that almost every magnetic harddisk made over the last 10 years has sector DRM. That's the unwanted functionality which is advertised. What other functionality was included by the manufacturer? What other functionality was added by parties, such as the Equation Group, who are able to re-flash harddisks of all major manufacturers? Solid state storage is worse. As an example, it is fairly trivial to re-flash a Micro SD card to work as an SPI host rather than an SPI client. Samsung "smartphone" firmware fixes provide alarming insight into the internals of ARM micro-controller firmware used in Samsung flash storage. From this, it is fairly trivial to set Samsung flash storage into debug mode, extract firmware, decode bad block maps, extract dormant data and then re-flash the micro-controller so that it may keep aside information of interest. However, that's tame compared to information learned from my local makerspace. Some Micro SD cards are publicly declared to have a wi-fi interface. (Others may have a dormant wi-fi interface.) A wi-fi interface allows a card to work in an infinite storage mode when placed in a camera. However, in other scenarios, malicious firmware may snoop keywords or copy documents into a hidden pool and then crack a wi-fi connection so that documents can be uploaded to interested parties. How do you know that you're not a victim already? If you use strong encryption for every file on every storage card then you are only safe from data egress. A scenario of "How did that get there?" combined with wi-fi and horse-porn becomes increasingly likely without a user feigning ignorance.

Magnetic storage security is screwed. Flash storage security is screwed. What about booting and key management on ROM? Well, that's screwed too. a 250ns "ROM" implemented as a 100MHz micro-controller has 25 clock cycles to respond to any signal level changes. Nowadays, this can be achieved without writing assembly. However, the expected response time provides less opportunity for malicious activity. For the truly paranoid, it is possible to stripe data across ROMs (in the range of bits or bytes) and implement parity checks. Although this is far from ideal, it provides options which are not available with magnetic storage or flash storage.

This is part two of a four part proposal for a trustworthy computer consisting of ALU, registers, memory interface, network cards and compiler. Part two covers the memory interface.

The previous section describes the outline of a discrete hardware implementation of processor where the virtual machine is 32 bits or more and the native machine has:-

• 16 bit program counter for 8 bit micro-code.
• 8 bit internal accumulator.
• 128 byte internal register bus where values can be read into the accumulator.
• 128 byte internal register bus where values can be written from the accumulator.
• Locations on the internal buses where it is possible to read or write to the ALU, virtual processor registers and main memory.

Understandably, this requires a large number of clock cycles to do anything and clock cycles are likely to be less than 1MHz. However, this design works astoundingly well when used with a multiplexed card bus system. This covers multiple use cases:-

• Micro-controller uses card bus system to interface with one more other micro-controllers on same circuit board.
• FPGA uses card bus system as main memory interface.
• Micro-coded mini-computer uses card bus system as main memory.
• Legacy host computer accesses card bus system via parallel port. Access may be directed from native applications or software running in a virtual machine.

Where:-

• One or two peripherals do not use an edge connector.
• A desktop card frame provides 16 slots or less.
• A card frame provides 40 slots or so in a 19 inch rack. Using a trick popularized by the Sun Microsystems E10000 Server, it is possible to have an equal number of slots on the reverse of a back-plane without increasing the wave-length of the back-plane.

Where a card may be:-

• Homebrew cards made from strip-board and DIP chips.
• Etched, single sided circuit board.
• Double sided circuit board.
• Multile layer circuit board.

Where each card may:-

• Operate at 1MHz or less.
• Have the throughput of PCI-X.
• Also provide a PCI, PCI-X or PCI Express connector.

It may also be possible to implement generic bridges to and from PCI variants. However, the design is most likely to be used as an 8 bit interface running at less than 1MHz.

The card bus system was originally envisioned to be retro-fitted to 8 bit and 16 bit computers but I quickly realised that portable software would be required to cover multiple use cases. This led to the development of the virtual machine which compliments this card bus system. Therefore, the card bus may be driven via library code running on a computer which has its own address-space. Or it may be the only (visible) address-space of a hard-wired or trustworthy micro-coded mini-computer. During my absense, I began reading about legacy bus implementations from VAX, Apple 2, PCI and many others. This has led to making the design significantly more lax about power and signal tolerances.

Firstly, borrowing from the Apple 2 and elsewhere, supply Voltage should be unregulated. It is nominally 5 Volts but may be anything over the automotive range. This may exceed 15 Volts and may include transient spikes above 60 Volts. It is expected that each card performs Buck transformer regulation to 3.3V or similar but that all common signals are at 5V only.

Secondly, one open drain interrupt line may be common to all cards. Alternatively, the interrupt of each card may be fed into a priority encoder and/or switch fabric for delivery to multiple processor cores. If the host is a micro-controller then interrupts (which may be detected as edge triggered or level triggered) may or may not produce unique interrupt vectors. Similarly, for a trustworthy micro-coded mini-computer, unique interrupts may or may not be available.

Thirdly, signal lines are intended to allow a fairly minimal implementation of 3 × 74244 8 bit mono-directional buffer chips, 3 × 74245 8 bit bi-directional buffer chips, 2 × 74138 de-multiplex chips, two or more latches and XOR parity. Each card consumes a maximum of one TTL load on each signal line.

Fourthly, there are nominally 256 cards in a 64 bit address-space. Each card nominally implements a 56 bit address space. In the baseline specification, cards do not perform bus mastering or dynamic address allocation. Borrowing from PCI, cards may perform multiple, unrelated functions and therefore the address space on each card is divided into four equal sections. Each section is divided into four equal segments: ROM, I/O Segment, Manufacturer ID and Device ID. These segments can be decoded uniquely with 1 × 74138. In the absense of ROM, Manufacturer ID and Device ID may be hard-wired via buffer chips. A ROM format will be devised in which card capabilities will be defined. These will include wide data-paths, bus mastering, timings, Voltage ranges, current draw, larger numerical ranges for Manufacturer ID and Device ID, byte-code device drivers and native device driver implementations.

Fifthly, borrowing from QBus, if a card cannot accept or respond to a request within 100ns, it must assert a wait signal. A trivial host implementation may wait indefinitely. However, a host is expected to receive a bus error within 2000ns.

Sixthly, cards nominally have a 28 pin or so, single sided edge connector at 0.1 inch pitch where signals are: ground, power, ground, control signals, ground, interrupt, wait, ground, least significant four bits, ground, four bit even parity, ground, next four significant bits, ground, four bit even parity, ground, power, ground. A single height card is 8 inch. A single length card is 6 inch. Single height, quad length cards should fit within a 5U frame (8.75 inch) and should therefore be 8 inch high and 24 inch deep. Double height cards should fit within a 10U (17.5 inch) frame. It must be possible to fit three, half height, half length cards plus back-plane into 2 inch × 4 inch × 4 inch.

The memory of the card bus system is arranged so that a card in slot zero may be a mini-computer boot ROM. Furthermore, the bit patterns on the boot ROM may be compatible with multiple processor architectures. For example, for Z80, the first two memory locations are a vector for the start address. For x86, the first four memory locations are a vector for start address in 8086 segment format. For 680x0, the first four memory locations are a 32 bit start address in big endian order. Therefore, it is possible to choose representations which are distinct for all three architectures. For the virtual processor implemented by the mini-computer, address zero is the execution address. Fortunately, representations can be chosen for vectors which are also harmless, unprivileged instructions for the virtual processor. Specifically, it is possible to choose Z80 vectors, x86 vectors and 680x0 vectors which all lead to distinct addresses while also being a NOP sledge for the virtual processor. In the general case, architectures may be similar to the point that differences during boot are immaterial. More commonly, architectures differ to the extent that a dummy MOV in one instruction set is a jump in another instruction set. This allows bit patterns to be chosen such that execution for each architecture branches in one or two steps. The major consideration is that any card configuration held in ROM should be offset by 1KB or so. This avoids needlessly surmountable complications of card configuration clashing with boot vectors.

In practice, connecting the multiplexed card bus as the main memory of Z80, x86, 680x0 or similar would be troublesome. Connecting a virtual ARM processor in an FPGA would be easier. In general, it is good to keep options open when a broad solution is relatively easy to achieve. More specifically, choose any two or more architectures to provide cross-architecture support. For example: MIPS64, ARMv8, Xtensa, OpenRISC, RISC-V and my virtual processor.

Consideration of card access patterns is useful. In the trivial case where a card has not indicated a wider data-path, a 64 bit address would be specified in eight pieces. Each card latches chunks of interest. For I/O expanders without ROM, this may be the bottom 8 bit of the address-space (or less). Latches may be set in ascending order or descending order. However, descending order has the advantage of setting card select on the first cycle. It is also the most logical order when sequential addresses are accessed. This works very much like DRAM static column paging and is intended to facilitate such usage when used in conjunction with low density DRAM. This is not applicable when using high density DRAM but the option remains. Indeed, given typical bus bandwidth, use of high density DRAM may be impractical.

Borrowing from SCSI and Micro SD, host and card may be capable of wider transfers. For a trustworthy micro-coded mini-computer implementation, this requires moving the top 8 bits of a candidate address to an internal register then jumping to the micro-coded bus mastering routine for each case. In the trivial case, the extra check slows access to main memory. However, where a wider bus is common, latch operations and transfer operations may be reduced. Although the trivial case of a nine-way multiplexed bus seems slow, sequential 8 bit read/write operations approach 50% of 8 bit bus cycle throughput. In the frequent case of sequential, variable length instruction read, retrieval of longer instructions is considerably amortized. For wider buses, sequential 16 bit read/write operations closely approach 100% of 8 bit bus cycle throughput, 32 bit read/write operations are effectively 200% of 8 bit bus cycle throughput, 64 bit read/write operations are exactly 400% of 8 bit bus cycle throughput. Larger bus widths also perform better on random access. Specifically, 8 bit bus obtains 11% throughput, 16 bit bus obtains 20% throughput, 32 bit bus obtains 33% throughput and 64 bit bus obtains 50% throughput. However, for trivial cases, figures can also be considerably improved if partial address decode is used and bus cycles are correspondingly omitted. Given the bandwidth of the bus, this may be a practical default.

Unfortunately, the next section demonstrates that the desirable and trivial case of a passive back-plane is not sufficiently robust against malicious parties.

This is part one of a four part proposal for a trustworthy computer consisting of ALU, registers, memory interface, network cards and compiler. Part one concerns ALU and registers.

It is possible to prototype processors using FPGA [Field Programmable Gate Array] development boards. They have numerous advantages and dis-advantages. They are small, relatively cheap, relatively fast and can be re-purposed for other projects but they typically incorporate DRM and require the use of untrusted software. If the purpose of the project is to create a trustworthy computer, an untrusted FPGA would not be the final solution. Therefore, we have to "keep it real" and devise a solution which can be implemented without an FPGA. It may be common for the solution to be deployed on an FPGA but a solution which does not specifically require an FPGA has numerous advantages. For example, any solution which vastly under-utilizes an FPGA may be implemented as a multi-core processor. Whereas, any solution which is crammed into an FPGA may be expensive or impractical to implement in other forms. So, the intended scale of integration is DIP chips in sockets which can be hand soldered. However, trade-offs of other implementations are acknowledged.

There are numerous techniques to make minimal processors. It is possible to apply the design principles of the Apollo Guidance Computer to make something which can be programmed like a 6502 or similar. Unfortunately, it will be significantly slower than a 6502 because it will use 64KB EPROM or similar with 350ns access time. Further circuitry, such as counter chips, may require a system to run below 1MHz. A lack of instruction pipe-lining and 64 bit registers will also require significantly more clock cycles per instruction. It would be unrealistic to assume 10% performance of a Commodore 64. Regardless, in the same manner that it is possible to get a 6502 to add 64 bit numbers, a smaller data bus and ALU does not prevent 64 bit data from being processed on minimal hardware. Likewise, memory bank switching allows a very large amount of memory to be addressed by a processor. It would be faster and more efficient to not use multiplexing of an ALU, data bus or address bus. However, the minimal implementation is cheaper, more tractable and may be replaced with more substantial implementations.

The system will be based around one 8 bit ROM. One output from the ROM determines read or write. The other seven outputs determine which internal register to read or write into an internal accumulator. This has the obvious defficiency, described in NAND2Tetris, in which instructions will typically be a series of read then write operations. This can obviously be improved with the use of two ROMs and no intermediate accumulator. However, this incurs Amdahl's law because there are also cases where efficiency does not double.

The native machine has 128 × 8 bit read-only registers and 128 × 8 bit write-only registers. Of these, half of the read-only registers provide immediate constants. Therefore, any value from zero to 63 can be loaded into the accumulator. From this, it is possible to:-

• Short jump within a 64 instruction page.
• Medium jump within a 4096 instruction block.
• Long jump across the whole ROM.

Some of the registers provide access to ALU functionality. In particular, it is possible set or clear a carry flag by writing to specific locations. Within the native machine, the window to main memory may be eight bytes or less. However, the virtual machine is not aware of this restriction. Anyhow, a minimal system proposal requires:-

• 5 × 4 bit binary counter chips for the native program counter. This is arranged into six bits, six bits and four bits to allow page, block and global jumps.
• 2 × 8 bit latch chips so that the parts of a medium jump or long jump can be applied synchonously. These are not essential but they avoid a large number of trampolines in the micro-code.
• One 64KB EPROM or similar.
• One 8 bit latch for the internal accumulator.
• Numerous latches for all of the general purpose registers.
• Latches for general register selection.
• Latches for temporary registers.
• Latches and counters for the virtual program counter.
• Logic chips for the ALU. This includes internal flags which are not available via the virtual machine.
• Logic chips for register decode.
• Logic chips for virtual instruction decode.

Within the 128 × 8 bit write-only registers:-

• Three addresses allow the native program counter to be set.
• A range of addresses allow ALU flags to be cleared or set.
• A range of addresses allow ALU operands to be written.
• Three addresses allow register operands to be selected.
• Eight addresses allow writes to a general purpose register.
• Four or more addresses allow main memory address to be specified.
• One or more addresses allow writes to main memory.
• Four or more addresses allow the virtual program counter to be set.
• One address allows the virtual program counter to be incremented.
• Four or more addresses allow virtual stack pointer to be set.
• Virtual instructions may be written into specific addresses for the purpose of splitting byte-code fields. This functionality is copied directly from the design of the Apollo Guidance Computer.

Within the 128 × 8 bit read-only registers:-

• The first half of the address-space allows constants from zero to 63 to be loaded into the internal accumulator.
• A range of addresses allow ALU operations to be queried.
• 24 addresses allow reads from general purpose registers.
• One or more addresses allow reads from main memory.
• Four or more addresses allow the virtual program counter to be queried.
• Four or more addresses allow virtual stack pointer to be queried.
• A range of addresses conditionally provide a subset of known values. This allows bit-field decode, conditional execution and jump tables to be implemented within the native machine.

The native machine does not have subroutines or conditional instructions. It is not a general purpose 8 bit micro-processor. It is micro-code for the purpose of implementing one specific computer architecture. Conditional sequences, such as loading variable length instructions into a bit-field decoder, require a terminating jump at the end of the sequence and multiple jump tables for opcode and addressing mode. These conditional addresses can be obtained from dedicated register locations.

It is also possible to return to the beginning of the fetch-execute cycle via the use of a dedicated register. This allows an interrupt to be handled without incurring additional clock cycles to test an interrupt flag. Given that there are no conditional instructions, this is the most logical implementation. The read of the interrupt vector also allows atomic sampling of an interrpt signal and therefore it avoids the obscure corner case where a transitioning interrupt signal level causes indeterminate behavior across the hardware.

It is not strictly neccesary to implement the virtual machine's program counter with dedicated counter chips. However, omission would require a significant number of clock cycles to perform an increment operation via an ALU. This differs from the Apollo Guidance Computer in which all hardware counter increments stole bus cycles to perform increment via the ALU. However, in the case of the Apollo Guidance Computer, all counters were the width of the ALU. In the proposed design, all counters are significantly wider than the ALU and therefore increment operations require dedicated hardware or micro-code. While increment of the virtual machine program counter is an optional quick win, bi-directional increment/decrement of stack occurs far less frequently and is more difficult to implement as a dedicated unit. In both cases, the virtual machine's architecture constrains read and write operations within one instruction cache line and data cache line. Within a micro-coded implementation, this allows the bottom byte of the address to be incremented without concern for ripple carry into other bytes of the address. To achieve this, unaligned read and write operations are split into multiple virtual machine instructions. You'll see why this is important in the next section.

Many native instruction sequences will be read, write, read, write and the occasional poke to clear a flag or suchlike. This could be implemented with a pair of micro-coded EPROMs and no intermediate accumulator. However, this increases cost, slows development and doesn't double performance. Regardless, it is a trivial option to increase performance after initial development.

In response to CID634544 from UID791:-

I have no interest in price/performance anymore. Whatever it is, it is. I'm extremely interested in price/security/openness. How open is the architecture? Are there any blobs anywhere? Is there a security chip like the Intel ME? If so, do I have access to the source code? Can I compile my own security engine to run on this dedicated security processor?

Those are the questions I have now. I would build a system today with far less power than the bleeding edge processors out there, but all the security we want and need. I firmly believe now that security can ONLY be obtained with full and absolute transparency. No security is obtained through obscurity of the methods and processes.

Intel and AMD can both do whatever the hell they want, but the first company to deliver the security we truly need will start getting a lot of orders. Even if they're lower on the performance/feature totem pole.

I have been working on a paractical solution to your problem. It would have been preferable to have a solution prior to Dec 2017, when Spectre and Meltdown became widely known. However, a solution remains urgent. I have an outline design in which all components are open to inspection. This will be described in several parts.

The first part is a minimal, micro-coded system which implements a processor with 64 bit registers but, to reduce costs, not a correspondingly dimensioned ALU. You said that you would accept this solution irrespective of its speed. I am concerned that you may wish to place further constraints on your specification because my proposal is likely to be significantly slower than a Commodore 64 or Apple 2. Obviously, if computers with a 16 bit address bus were suitable, you'd be using them already. However, if you compare, for example, the market viability of Tandem's high-availability, 16 bit, stack processors against my concerns about transistor switching speed and ALU latency and system integrity, you'll see that a native, flat, 32 bit address-space is a beguiling false economy from which I have freshly emerged.

The second part is the memory interface and card bus system. this also covers physical considerations, such as enclosures.

The third part covers contemporary expectations about network interfaces. Unfortunately, this may require a workaround involving bit-banging with an Arduino or similar. Allowing such an untrusted unit into a system requires all data to be distributed across multiple network interfaces. In the trivial case, this only provides link layer security across redundantly wired LANs. In restricted cases, this may also work across WANs.

The fourth part concerns writing a compiler for such a system. I have a viable proposal which allows a complete bootstrap from an insecure environment. However, all of the work on trustworthy hardware is moot if trustworthy software cannot be maintained.

(The tools and materials lists look like a Dave Barry homage but this is not a spoof.)

Tools: bandsaw and all associated safety equipment, tape measure, coarse file, sandpaper.

Materials: two or more ball pit balls, drain-pipe, sheets of wood or plastic, glue, (optional) piano hinge, (optional) suitcase latches, (optional) aluminium strips, (optional) Mecanno pitch 5/32 inch nuts and bolts, (optional) yoga mat or child safety mat, (not required) 60000 feet of tram cable.

In the 1970s, rounded corners were a statement of finesse and sophistication. In the television series, UFO, Colonel Edward Straker's office has a lava-lamp style mood screen and is white with rounded corners with one of the rounded corners being a mini-bar. Totally shagadelic. It also helped that they dressed like Sgt. Pepper's Lonely Hearts Club Band. The white, rounded corners are copied in UFO's submarine cabins. When the third season of UFO was cancelled and work started on the inferior Space 1999, Commander John Koenig's office had more than a passing ressemblance to Ed Straker's office. These design elements and others are often mis-attributed to a Steve Jobs wet dream but since the 1970s, audio and computer equipment has cycled around box colors of white, biege, brown, gray, silver or black. Everything except white, silver and black has been dropped from this rotation but rounded corners on physical products remain a neccesity when consumers are a danger to themselves. For example, consumers are barely able to operate a micro-wave oven safely. It is from this situation that website styling follows physical products. If all of your products have rounded corner then, for consistency, web site style may be similar.

For a very long time, I've wanted to make boxes of arbitrary size with rounded corners and I feel like a dumb-ass for arriving at a solution after so long. The answer came about two months ago and, since then, I've been loudly telling people about it. The answer is to use ball pit balls for corners, drain-pipe for the edges and arbitrary sheets for flat sections. If a ball has radius (or diameter) which is the same or larger than the drain-pipe then the ball can be trimmed to size. I was able to find ball pit balls and drain-pipe with 68mm diameter. Unfortunately, the palettes are horribly mis-matched. Drain-pipe is typically available in white, gray, brown, black and (rarely) green. Unfortunately, gray and brown tend to be large diameter sewage pipes. My local supplier only had 50mm and 68mm pipe in black. To contrast with edge color, ball pit balls are only available in garish kid colors, such as bright purple, lurid pink and lime green. So, edges and corners are likely to be in clashing colors. Regardless, it is relatively trivial to manufacture boxes of arbitrary size.

I assumed that ball pit balls are ridiculously cheap because they are required in such large quantities. With a two inch diameter or similar, a hypothetical 10×10×10 block of balls is quite small and 10000 balls would barely fill a closet shower. A typical ball pool must have hundreds of thousands of balls and therefore they must be cheap in volume. Indeed, they are. 200 are less than US$20 and volume pricing becomes increasingly favorable. I was also able to get 10 for £0.99 but many retailers don't stock them during winter. The plastic is presumably ABS, BPA or similar plastic commonly used for food containers.

Unfortunately, the balls are sold by diameter and not thickness. They are incredibly thin to the extent that two or more layers should be glued together. Given that they are incredibly thin and flexible, any two sections of ball effectively have the same radius. Therefore, two or more layers can be easily glued together. The balls are presumably manufactured with injection molding. The balls have two smoothed injection points at the "poles" and a seam at the "equator". This facilitates cutting one ball into eight demi-semi-hemi-spheres when only using blunt scissors. With a little practice, this can be achieved with tolerance of 3mm (1/8 inch) or better. However, the balls are manufactured very cheaply and the molds are not spun before the plastic sets. Therefore, one hemi-sphere may have notably thicker plastic. To compensate, place the four heavier pieces in one pile and the four lighter pieces in another pile. Then match a piece from each pile when gluing layers together. This achieves the most consistent thickness after gluing. If cutting tolerances are bad and a piece from the top of one pile doesn't match a piece from the top of another pile then rotate one pile around with the intention of improving tolerances. There is a permutation explosion of possible matches but rotating one pile should obtain fairly optimal matches.

I tried three types of glue and there is no particular preference. I tried unbranded crazy glue which is presumably an aroma compound because it smells of acrid mint. I also tried water-proof silicone sealant and kiddie PVA glue. All work well. However, all leak from the sides, all glue corners badly and all take a long time to set. Presumably, this is due to ingress of air mostly occurring between the thin seam between the layers of plastic and the liquid glue being quite deep behind this seam. Predictably, crazy glue makes the most mess. Silicone takes more than one week to set. PVA gives the brightest finish. I am concerned that layers may flake due to ingress of water. In which case, silicone may be preferable.

My efforts with a hand saw have been completely laughable. The cheapest saw was completely impractical. However, a really good hand saw makes an unbearable resonance when sawing a plastic tube. This is completely impractical in my apartment at any time of day. Unfortunately, I discovered this after purchasing a 2m drain-pipe. I didn't want to take the full length of drain-pipe to my local makerspace. This led to the humorous situation of me, wearing a Hello Kitty tshirt, in a quiet street, sawing drain-pipe. This allowed me to take six small sections to my local makerspace. This was enough to make two boxes or one disaster. Unfortunately, the bandsaw was unavailable and a wooden bench vice was unsuitable without use of rags to hold pipe in one place.

Anyhow, the plan is to cut pipe lengthways in to 1/4 sections. This provides four edges with a 90° curve. Admittedly, this requires very accurate sawing. In volume, a jig to hold the pipe would aid such accuracy. The best part is that it is possible to cut all of the pipes without measurement because sections of the same length are always used in multiples of four. Sections of a particular length are always parallel to each other. If it aids visualization, each dimension (length, width, height) may be regarded as one section of pipe exploded into four complimentary curves of the same length. From this, it is possible (or even desirable) to mix pipe colors to aid identification and assembly of pieces. It is only after cutting edges that accurate measurements are required. This is to make the flat sections of the box to the correct sizes. These may be a mix of wood or plastic of any any color and of varying thickness.

So far, I have only described the outer surface of the box. An unseen layer is required to hold the outer layer together. For this, I considered purchasing a US$50 flight case and diassembling it. However, a thought experiment of case asembly is sufficient. A flight case typically has eight molded plastic corners. Each of these corners has three tongues. Cut aluminium can be slotted over each tongue. The extruded aluminium also has flat edges which allows the visible external panels to be glued. The tongues and edges are all missing from my design. I've only described the external shell but it can be held together with a second layer of flat (or curved) pieces. This may be aided with foam. A thick and solid type of foam may be sourced from yoga mats or child play mats. The thickest, dense foam is intended to be used a gymnasium flooring or play area flooring. [Insert Mark Twain "but I repeat myself" joke.] This thick foam is available in continuous rolls or inter-locking sections.

A box can be made with two sections which are hinged together. This may be achieved with piano hinge which is, conveniently, available in piano length sections. It may also be cut to length without the hinge falling apart. (Indeed, it is possible to make unrounded boxes through the use use of piano hinge. A friend made transparent cuboid computer cases where all 12 edges used piano hinge bolted to plastic sheets. Where all eight corners are formed from freely hinged edges, none of the edges have any freedom of movement and the box is relatively rigid. On this basis, you may want to order surplus piano hinge.)

Alternatively, strips of aluminium can be used to make a card frame system. I originally envisioned a system which is a multiple of 2 inch × 4 inch × 4 inch (5cm×10cm×10cm) in a flat orientation with one inch or so of padding and rounding on all sides (left, right, front, back, top, bottom). Within one unit, it is possible to fit three or more separate circuit boards. This would be a minimum of 12 square inch (300cm²) of circuit board. Nowadays, across two units, is it possible to fit nine credit card computers. Some of those credit card computers are quad-core and 64 bit, 16 core processors are foreseeable. That would be 144 cores in 2 inch × 4 inch × 8 inch (5cm×10cm×20cm). It is also possible to make units where the external dimensions approximate 19 inch rack boxes. For example, 4 inch × 16 inch × 16 inch (plus 68mm diameter tubing) easily fits within 4U. (Note that this is entirely compatible with the car dash-board design and allows equipment to be used during journeys and then removed without drawing blood.)

I considered making a rounded box, stereo audio amplifier for a partially-sighted friend. We previously bought speakers to watch Breaking Bad. However, these speakers used impressively hair-thin wires and speakers which required the molded box to hold the magnet against the coil and cone. Cable strain relief was a knot in the wire. This only cost £1 (approximately US$1.50) and had no amplifier but I was unaware of the construction until I tried repairing a strained wire at my local makerspace. The response to my laughter was akin to "What are you laughing at? Have you not seen inside recent Chinese exports?" I was unable to repair the cable strain and my friend's attempt to fix it. So, we watched the end of Season 4 and all of Season 5 audibly squinting in monophonic. Now I can make a small box with a headphone jack, two speakers, one of 10 PAM8403 stereo audio amplifier purchased for robotics and a 5 Volt USB charger. Unfortunately, I've only got black drain-pipe which isn't particularly good. My partially-sighted friend who regularly loses his black, Casio F-91W terrorist watch and his black, Dell mouse. Regardless, it is possible to make four of the corners red [port, left audio channel] and four of the corners green [starboard, right audio channel]. Actually, I wonder why stereo phono leads don't follow international shipping standards.

I can also make a box for the alarm clock project. A friend kindly ordered 15 large, red, seven segment digits. That's two sets of six for HH:MM:SS (or YY/MM/DD) plus spares. However, this is a case where I received significantly more than I expected. The description said one inch *segments* but I assumed that the entire seven segment module would be a metric inch tall. Oh, no. The segments really are one inch and therefore the digits are more than two inches tall. That should definitely be readable when I'm drowsy and bleary. However, digits this size don't fit into the hummus tubs which I use for credit card computers and prototyping. I now require corresponding lengths of drain-pipe to be cut without incurring serious injury.

My attempts at hardware hacking may be slow and abysmal but, to one of my friends, I look like a fricking wizard; especially after a friend stepped on a Casio F-91W watch and I repaired the catch with a blue paper-clip (to match the watch's blue trim).

Tools: scissors, (optional) drill.

Materials: six bamboo sticks, string, (optional) washers, (optional) nuts and (optional) bolt.

A friend suggested making a camera tripod from bamboo and the result was surprisingly good to both of us. I only wanted three bamboo sticks for testing and maybe a few spares. After some comedy at my local hydroponic shop, I purchased one pack of 25 bamboo sticks rather than three packs of 25 sticks. Optimistically, this was enough to make two or more tripods with plenty of opportunity to make repairs.

Bamboo sticks taper and therefore sticks can be used in pairs such that the cross-sectional area of the bamboo remains fairly constant along the length of each tripod leg. At the splayed end of the tripod legs, string should be knotted around each pair of sticks and the knots should be spaced so that sticks lean by about 15°. At the center, all sticks should be closely knotted in pairs and then knotted together and/or held together with elastic bands.

The platform for a camera can be made from an off-cut of wood. Cut three tapered ridges which take into account the off-centeredness of the stick pairs. With sticks wedged into the wood block, this platform is sufficiently stable to rest a camcorder. Although the picture may not be level, it is more than sufficient for motion capture. A level picture can be obtained with the use of a Gorilla Grip or similar. Alternatively, it is possible to add a standard camera clamp by drilling a hole and adding one bolt, one or two washers and a nut. Apparently, there is one standard bolt size for still cameras and one standard bolt size for motion cameras. The extra sturdiness was required for the weight of film cannisters. However, as digital cameras are decreasing in size, the small bolt size is becoming increasingly common for still cameras and motion cameras.

Our thoughts and prayers are with the victims of the horrible attack in Antioch, Tennesee last night, and we grieve the nation’s loss. We also condemn the violent actions of the attacker and anyone who would provide him support. Great work by the very brave customer. Believe me, I would have done the same thing. Thank you to all of our wonderful First Responders from @MNPDNashville who are on the scene. Travis, if you're listening, turn yourself in before it's too late. We are currently monitoring here at the Southern White House.

My budget already has separate line items for each of Hookers and Blow.

But seriously folks... I really do want to hear your kind suggestions as to what my business should purchase.

I was even contemplating a USB Protocol Analyzer. Used LeCroy's go for $3k to $6k. I'm going to get a USB 3.0 sniffer. USB 3.1 is very similar to 3.0; I could still use the sniffer for USB 3.1 work just for debugging by temporarily entering different values in certain variables, then restoring the variables' original values after I've fixed a bug.

In the end I decided that it would serve my business better to buy a used car. This so I don't have to take a taxi to interview with potential clients who are located in places that public transit does not serve.

There's a substantial chance that I'll have to buy some plane tickets to attend the interviews that are in far-away lands.

Here's what's in my business budget to far:

- 4K monitor
- Bitmain Antminer L3++ LiteCoin Mining Rig (1,000 Watts, 504 MH/s)
- Bitmain APW++ PCIe power supply
- Shipping the above two via DHL from China ($$$)
- Quarter 1 2018 IRS Estimated Tax payment
- Used MacBook Pro
- Technical books
- Transit Passes - yes I can deduct the bus and light rail!

- What else do you suggest?

It has never worked for me to save money; it always finds a way to slip through my fingers. What works far better is to buy quality products that I can really use and are of lasting value such as my Mac mini.

I'm specifically seeking business equipment and software that would enable me either to earn more money, or to earn money faster. Were I to actually buy that USB sniffer I could complete on USB contracts easily twice as fast as I presently do.

I've still got more than four grand unallocated out of just my next paycheck - and I've already signed my next client! W00T!

I spend quite a lot of ducats on technical books. I don't want to be driven out from the pack because I - really do - know FORTRAN. The main reason my consultancy is focussed on embedded and drivers is that my being olde and greyye is regarded by potential clients as a good reason to hire me.

Among my reasons for so many years of homelessness and unemployment is that I spent six years trying to get a job writing mobile apps. I got lots of interviews but the very instant they saw my grey hair they started coming up with plausible-sounding reasons not to hire me.

I'm using a LibreOffice spreadsheet to work out a detailed budget. Bonita and I worked together to develop a 707411y K3w1 budget template. (I will eventually lift a finger to post an article about it somewhere around here.)

My spreadsheet enables me to budget both personal and business expenses on the same sheet. I use one sheet per calendar quarter.

A fifth sheet uses my previous year's IRS Form 1040, 1040 Schedule C Profit And Loss From Business Income and 1040 Schedule SE Self-Employment Tax to estimate my income tax and self-employment tax rates.

Each paycheck's budget predicts my Quarterly Estimated Tax by referencing the above two tax rates.

For 2017 I just took a wild guess. Having been unemployed for five solid years deprived me of a 2016 return to estimate my quarterlies with.

I was so accustomed to earning nothing more than a few dollars of singing on the street tips that it was difficult to wrap my brain around quite suddenly and completely out of nowhere these huge wire transfers hit my business checking account, thereby burning holes in my pockets, through my shoes, through my feet and through the Earth all the way to the People's Republic Of China.

I'll be far more careful this year, I Swear On A Stack Of Bibles.

Really I am: there's an entry in my personal budget for "Walking Around Money" that mostly goes for coffee at Peet's and Starbucks.

I place a very high priority on hanging out in trendy cafes: after being in my tax-subsidized apartment for a few months, I realized that just being in the presence of other people was quite effective in relieving the symptoms of my mental illness.

Soylent news has no support for smart phones. That often leads me to tap the wrong link because all the links default to very small

A one line fix could make quite a lot of difference:

Set the viewport

A message from Kim Jong Un: “North Korea will stop nuclear tests and launches of intercontinental ballistic missiles.” Also will “Shut down a nuclear test site in the country’s Northern Side to prove the vow to suspend nuclear tests.” Progress being made for all! This is very good news for North Korea and the World -- big progress! Look forward to our Summit. Mongolia?