Time Capsule - Part I

Speaking with some friends of mine.. I was wondering what I should have put in
a Time Capsule, like the one used from people in the American High School....

It was 1989 when I received my first Computer, a Commodore 64.

I started playing games as every child of my age, but in few times I started
studying Basic and Assembler Manuals, Electric Schemes, everything
that could let me better understand what was inside the box.

No, at the age of 10 I could not understand Commodore Electric Schemes :-), but
I was really fascinated by them, and moved by a strange 'force' that still
today I'm unable to totally explain.

What should move a young boy to study programming instead of playing games?

'Hacking Spirit', I could try to answer today.

I started to work on some routines to speed up the bootloading
of some games on my 1541-II floppies and to explore al the
possible combinations of PEEK and POKE instructions to full
control my C=64.

I also wrote some starfields with something like a 'USS Enterprise' moving into them.

Yes, In that period Star Trek TOS was what I prefered on the TV instead of Cartoons,
but that's another story.. :-)

One day arrived the second object (after the C=64 of course) that I should have put
in my Time Capsule: a 1200 baud Modem :-)

I'll speak about it in the second part of my post...

Soft error

So you're in your Lab integrating your Software Module on a brand new System.

In Embedded Engineering sometimes SW can be useful to debug/validate new

hardware components and people from the hardware division knows it

very well :-)

Using your 'old and validated' protocol on a simple RS-232 it seems that

data coming from sensors are 'slow'.

Hardware division says... 'It's a Software Problem' :-) 

Ok, let's see it.

You connect the JTAG on the Micro, launch your debugger, put a break point

in your 'old and validated' protocol.. dump the buffer coming from

the RX channel and... hey wait...

Data coming from sensors should be 0xAFCED0... but periodically I see....

0xAECED0.... it seems there is a bit-flip and the CheckSum routine is 

throwing away data...  

I simply move the cable connector and... now data arriving at the right frequency..

'Software problem'... uh? :-)

Perhaps you mean 'Soft', not 'Software'...  http://en.wikipedia.org/wiki/Soft_error

Don't Trust Hardware :-)

Are you John Carmack? :-)

... if not (He is a genius) please use #define in your code. (*) :-)

Look at this:

AbsAcc = fabs(sqrt(AXB*AXB + AYB*AYB + AZB*AZB) - 0.04903325

What is '0.04903325'.... ? Perhaps some months ago you knew it but now.... its LOST... so something like:

#define DV_FOR_GRAVITY (0.04903325)

Could be a good choice... :-)

Please: 'for each unusual constant in your code, use define' (!).

(*)
http://stackoverflow.com/questions/1349542/john-carmacks-unusual-fast-inverse-square-root-quake-iii