Stuffs to read before going to bed

[MooZ]

Ah TLDR; I also had this kind of remarks for some articles on my blog
There's a cool page to figure out acronyms : http://www.abbreviations.com/
Given the context I think ASP stands for Average Sales Price.

How to homebrew Sake. There's also an article about it in MAKE #33 and an article about growing one of the hotest pepper in the world.
And to stick to the topic, here's a video about the Galaksija, a Yugoslavian microcomputer halfway between a TRS-80 and a ZX 80 The Ulimate Galaksija Talk [29C3].

[MooZ]

Thanks to hackaday, I found a goldmine

• The 8085's register file reverse engineered
• Notes on the PLA on the 8085 chip
• The 6502 overflow flag explained mathematically

[MooZ]

As a benevolent dictator, I'm posting here a short article I wrote about translating CDRom games.

[MooZ]

It's Mars time!

• The software specification (v4.0) for the cameras of the Mars Exploration Rover (MER)
• The ICER Progressive Wavelet Image Compressor used to compress the images captured by the MER

[Tanuki]

A book on photography (WIP) by David Salomon:
Pho.pdf

from: David Salomon's Home Page

[MooZ]

• GameBoy programming manual

One day, we'll have all the Hu7 docs...

[MooZ]

It's Behind You: the making of a computer game
A book about the making of the ZX Spectrum version of R-Type.

[Charles MacDonald]

Here's the transcript of Michael Barr testifying about his analysis of the firmware in Toyota's engine control unit:

http://www.safetyresearch.net/Library/B ... DACTED.pdf

The gist of it is that too many tasks could be running at once, causing a stack overflow that would lead to system-critical variables getting overwritten, in turn causing unintended acceleration.

This was caused in general by poor programming practices; there were issues such as lack of comments, overuse of global variables, spaghetti code, trying to do too many things within single a task which isn't great for a RTOS, and adhering very loosely to coding standards designed for safety. It's sort of amazing the system worked at all and that there weren't more accidents.

It's lengthy and sort of a difficult read, but fascinating stuff nonetheless.

[MooZ]

Thx! I'll try to read it asap. This reminds me some of the bad stuffs I saw in my professional life
The weird things is that the code may have been "certified" at some point. Well... To be honest, from what I experienced this doesn't mean that your work is bulletproof.

[Charles MacDonald]

I thought I posted this a while ago but I guess I didn't:

10 Ways to Destroy an Arduino
http://ruggedcircuits.com/html/ancp01.html

It's about all the different ways a circuit can be destroyed (in this case an Arduino), and how protection measures can be added.

In terms of making a more robust/safe power supply, I've found that the Murata OKI-78SR is a really, really great little +5V regulator:

http://www.murata-ps.com/data/power/oki-78sr.pdf

It doesn't get hot, operates with 90% efficiency, it supports a wide range of input voltages (+36V), and most importantly it limits current output during a short-circuit condition to only 10mA. A regular 7805 limits the current to 250mA which is still more than enough to fry whatever is connected to it. We've all plugged in EPROMs backwards once or twice (or thrice..) and know how they can be damaged, at least this way they'll come out unscathed.

They aren't cheap, about $4 USD whereas a 7805 is $0.75 USD. But since I've started using these I'd never go back!