Night Trap (classic FMV) on Kickstarter.

https://www.kickstarter.com/projects/1018579240/night-trap-revamped

The classic full motion video game, Night Trap, is coming back, if they get Kick Starter funding.

I played Night Trap on the Sega CD, though it was later ported to other systems. It was one of the first, if not the first, live action full motion video games. It starred Dana Plato (from Diff’rent Strokes) as the heroin in a campy B-movie style horror flick.

It is noteworthy because of the controversy that sprung up around it, led by Nintendo, which caused the industry to adopt video game ratings. That alone makes this quite the historic artifact.

The original developers are wanting to re-release it for modern systems, and have gone back to the original 35mm movie film and digitized it in full resolution letting us see, for the very first time, what the movie was meant to look like (and not the low resolution 64-color versions we saw on the Sega).

Very cool. Check it out.

Using Termcap – part 3

See also: Part 1 and Part 2.

The termcap file is a text file found in /etc/termcap on a Unix system. As it was ported to other operating systems, the default location would change accordingly. The contents of the termcap file is basically a series of entries for each terminal supported. Each entry contains various elements separated by colons. To make the file more readable, a backslash can be used at the end of a line to break it up.

See the Wikipedia page for a summary, or the GNU Software page for a more descriptive summary… Or see this for a vague summary:

For example:

2characterterminalname|longerterminalname|verboseterminalname:\
  :capability=characetersqeuence:\
  :capability=charactersequence:

The 2 character name is legacy and is no longer used, but remains for ancient backwards compatibility. For a DEC VT-52 terminal, it might look like this:

dw|vt52|DEC vt52:\
  :cr=^M:do=^J:nl=^J\bl=^G:\
  ...etc...

Each capability has a two character abbreviation. Above, we see that to generate a carriage return (cr) we send a control-M (enter key). A new line (nl) is ^J. The bell (bl) is a ^G (beep!). There are many other simple codes.

For moving the cursor position, a DEC VT52 terminal used the sequence: ESCAPE followed by [ (left bracket) followed by line followed by semicolon followed by column followed by H.

ESCAPE [ 10 ; 4 H

That would mean move the cursor to line 10, column 4. To represent sequences like this with variables inside of them (line, column, etc.), there are more complex termcap entries:

:cm=\E%i%d;%dH:

Above, \E represents ESCAPE (just like ^ represents CONTROL). %i is a special flag that means “increment the two values supplied” (base 1 numbering) then the two %ds are the variables similar to a C printf() call.

The %i is because termcap assumes base 0, so an 80 column screen would be 0-79. The VT terminal (and PC ANSI, I think) assume base 1, 1-80, so to make it universal, all termcap applications expect a screen that is base 0 (0-79) and the entry knows whether or not to output 0-79 or 1-80. Fun.

Termcap has pages of codes for all kinds of features, like cursor up, delete line, clear screen, clear to end of line, etc. If a terminal does not support a feature, the entry is not present. Applications that use termcap will query these capabilities then use what they can. In my situation, I needed “cm” for cursor movement — and if that feature was not there, I couldn’t work (or, better, I could default to a mode of just lines of text).

There are more advanced features where a termcap entry can reference another entry. For instance, there were series of terminals made and as new models came out, they added new features but maintained the earlier ones as well. The first version terminal would have an entry, then the “v2″ terminal would have an entry that described the new features, but by adding a capability of “tc=terminal-v1″ or whatever, it would get any other capabilities from the “terminal-v1″ entry.

This cuts down on redundant information but also means you can’t just look at one termcap entry and necessarily know everything the terminal does. If you were writing your own code to parse a termcap file, you would have to take this in to consideration.

In a C program that will be linking to the termcap library, to load the terminal type you want, you need a buffer for it to be loaded (2K is the defined max size):

char term_buffer[2048];

…and then you just use the termcap tgetent() function:

status = tgetent(term_buffer, "ANSI");

If the termcap file is found, and there is an entry called “ANSI”, it will be copied in to the term_buffer. By checking for errors (always a good idea), you will know if the entry was not found.

But hard coding is bad. What if this code ever runs on a non-ANSI terminal? Termcap programs typically read the TERM environment variable, then get whatever that is set to. In windows you might “set TERM=ansi” and on Linux you might “export TERM=vt100″. Then the C program would query that environment variable first:

char *termtype;
termtype = getenv("TERM");
if (termtype==NULL) { /* handle error if env var not set */ }

termtype will come back pointing to whatever the TERM environment variable is set to (“ANSI” in the windows example above, or “vt100″ in the Linux example above). Then the tgetent() is done using that response:

status = tgetend(term_buffer, termtype);

If both of those are successful, the individual capabilities can be loaded using the tgetstr() function. tgetstr() will parse capabilities in the loaded termcap entry and write them to a buffer that is processed to be the actual output (less any variables that get substituted when the actual sequence is used later). For instance, the termcap entry might say:

:bl=^G:

…but when you use tgetstr() to parse for the “bl” entry, it will write out the control-G (ASCII 7) character in the output buffer. Basically, it converts all the \E (escape) and ^X (control) ASCII characters to what they really represent. This saves work later when they are output to the screen.

A second buffer (that must remain around) needs to be allocated to store the resulting output. Most examples also do a 2K buffer:

char capbuff[2048]; // output sequences are stored here

Then, as each capability is obtained, a pointer is passed in to where the output should be written, and when the call returns, that pointer is advanced to the next place in the buffer where the next capability will go. As tgetstr() is called over and over, the pointer increments filling up the output buffer with entries, and returning the location where each one the user cares about is located within that buffer.

char *tempPtr = capbuff; // start out pointing to our output buffer

If you want to know the code that clears the screen, it would be:

char *cl; // clear screen sequence

cl = tgetstr("cl", &tempPtr);

If cl comes back non-NULL, you know have a pointer to the byte sequence that will clear the screen. tempPtr returns with a higher value, so when you get the next capability you use it again:

ce = tgetstr("ce", &tempPtr);

This is repeated over and over for every code you wish to send. You check for NULL to know which capabilities actually exist, so you could write functions like this:

void clearscreen()
{
  if (cl==NULL)
  {
    printf("Sorry, I cannot clear the screen...");
  } else {
  tputs(cl, 1, outchar);
  }
}

And now we see how these pointers get used. The tputs() function is a special output routine that handles padding (time delays for slower terminals) and other features (though it ends up writing the character out using a function you specify — such as outchar() in this example).

For the cursor movement (cm) capability, it uses a special tgoto() function that knows how to substitute the X and Y values:

void setcursor(int x, int y)
{
  tputs(tgoto(cm, x, y), 1, outchar);
}

tgoto() processes the cm output string and returns one that has everything set up with the x and y coordinate in it.

By now, you may see where I cam going with this… Read the termcap entry, parse the ones you care about, then create simple functions that output the screen code sequences:

void clearscreen();
void setcursor(int x, int y);
void underlineon();
void underlineoff();

…etc…

In the next installment, I will share with you my very basic and simple 1995 code that let me convert OS-9 L2 (and MM/1 K-Windows) text programs to run under Termcap on any supported type of terminal.

And then I will explain why I decided NOT to use termcap for my current project.

To be continued…

Using Termcap – part 2

Previously, I mentioned a bit about the ancient termcap system which is used to send display codes (clear, move cursor, underline, blink) to terminals of different kinds. In this modern GUI world, none of this is necessary … folks pretty much have to rewrite the whole program to work with native Mac, Windows, Linux, Java, etc. I suppose the modern equivalent to termcap would be a cross platform GUI (kind of like a graphical termcap?) which turns things like “create a pop up window” or “create a menu with the following options” in to whatever it takes to display them on the end operating system.

I suppose that’s truly what I should be learning right now — my program could make use of graphics on the Linux-based Raspberry Pi, Windows or Mac. However, since my program is not intended to be a windows-based program (no pull down menus, no mouse, etc.) and really had no use for graphics, I decided to write everything using text.

My original prototype was rather bland, spitting out 80 column descriptive text. This was perfect for debugging, but certainly not what we want the end-user to have to deal with:

Ticket system, 80 column window prototype.

Prototype running in a Mac Terminal window.

By writing the application as a strict ANSI-C program, and just using text, it would compile and run on a Windows PC as well, in a DOS-style COMMAND window (CMD.EXE):

Prototype running in a Windows CMD.EXE window.

Prototype running in a Windows CMD.EXE window.

The target system for this project would be Raspberry Pis, the $25-$35 micro-Linux computer designed for educational use. We would be using the $35 model, which has more RAM (512mb) and USB/ethernet. The Pis support HDMI and composite video output. Instead of using large (pricy) HDMI TV/monitors, I found tiny composite color monitors for under $20 (4.3″, about the size of a GPS unit or large smartphone screen).

By setting the resolution of the Pi to match the display’s 480×272 resolution (/boot/config.txt: framebuffer_width=480 and framebuffer_height=272), and by choosing the largest font available (setfont /usr/share/consolefonts/Uni3-Terminus32x16.psf.gz) I was able to get a large, easy to read (on the tiny screen) 30×8 display. It would look something like this:

+------------------------------+
|123456789012345678901234567890|
|2                             |
|3                             |
|4                             |
|5                             |
|6                             |
|7                             |
|8                             |
+------------------------------+

The actual screen ends up much wider than this text drawing, since the displays I am using are 16×9 widescreen.

Have you noticed the lack of mentioning Termcap so far? Let’s correct that now.

If I was going to be using this particular screen and run on just a Raspberry Pi, I could just hard-code everything to expect 30×8 characters, and whatever display codes were needed to clear the screen or change colors.

And that would be bad programming. Doing this “because this is all it is planned to ever run on” is like not having insurance because you never plan to get in an accident. It’s certainly fine to write anything for yourself any way you darn well please (I do that all the time, too), but I try to think ahead and write things to be as portable and as flexible as I can.

Fortunately, I wrote such portable code back around 1995. At the time, I had created a text-based user interface called EthaWin. It was written for OS-9 Level 2 on the Tandy Color Computer 3, and later ported to the OS-9/68000 MM/1 computer. The CoCo 3’s terminal window system supported all kinds of screen codes for basic things like color, blinking, move cursor, etc., much like ANSI graphics on a PC did. The MM/1 was meant to be a next generation replacement for the CoCo OS-9 users, so it’s K-Windows system replicated (and expanded upon) those same screen codes.

My EthaWin was not the “portable code” I am speaking of. It would only run on a CoCo or MM/1 under OS-9. When I began working for Microware, the company that had created OS-9, none of my stuff would run on the “headless” OS-9 computers in the building — most didn’t even have video displays. The way you accessed them was via an RS232 serial port and a hardware terminal (or software terminal program), or from telnetting in across the network.

OS-9, being created as a very Unix-like operating system, supported termcap, and text editors like vim, uMacs, etc. made use of this to give full screen editing. If I wanted EthaWin to work on these OS-9 machines, I was going to have to learn how termcap worked.

In the next installment, I will finally talk about termcap and show how very simple it is to do very simple things.

Until then…

Using Termcap – part 1

Before stand-alone computers became common, most computer time was spent in front of a dumb terminal — basically a keyboard and screen that would send whatever the user typed to a big computer somewhere, and display whatever it received back from the big computer:

http://en.wikipedia.org/wiki/Computer_terminal

As I mentioned in an earlier posting, my first interaction with a computer in the 1970s was via a printing terminal at my elementary school. The next time I used a computer, it was a TRS-80 at Radio Shack. I kind of missed the whole dumb terminal phase of computing, but I certainly spent endless time with my home computer acting as a dumb terminal as it dialed in across the phone lines to other computers running BBSes (bulletin board software).

In a way, this concept lives on via the Internet and cloud computing. Our computers are just far smarter “dumb terminals” when they display all the content generated from Facebook’s servers, or display virtual shopping catalogs that are indexed at Amazon.

I guess there really isn’t anything new.

While today, a modern smart “dumb terminal” may be running JavaScript or (can you believe it?) Flash, decades ago dumb terminals were doing similar rendering – though limited to simple things like moving a cursor around the screen, or turning on underlined text. Or blinking. Anyone remember when things blinked?

Frighteningly enough, you probably still see examples of this at some modern businesses. My car dealer still uses some text-based program in its service department, and it is not that uncommon to see the same in banks or other businesses.

Dedicated terminals were still alive and well in the mid-1990s when I took my first dream job and was teaching week-long OS-9 courses around America (and sometimes in Canada). I would arrive on Sunday night, and at the hotel would be a bunch of boxes that had been delivered. We would rent dumb terminals from local suppliers, and I would unbox and set up eight of them and wire them all up via RS232 serial cables up to the multi-user OS-9 computer I brought with me.

I would then go through the task of configuring the settings on each terminal (they were pretty smart for dumb terminals) to make sure all the settings matched what we would need for the class (like baud rate and serial port settings, as well as emulation mode).

Just like today, there were competing standards back then. A VT100 terminal might expect a particular series of bytes to indicate “clear the screen”, but a DEC terminal might use a different set. What a mess this must have been in the early years!

Fortunately, smart people came up with smart solutions to deal with all these different standards. One such solution was called Termcap – which stood for terminal capabilities.

http://en.wikipedia.org/wiki/Termcap

Created in 1978, termcap was a database of various terminal types with entries describing how each one did things like move the cursor or clear the screen. Programs could be written to use the termcap library and then, on startup, they would load the proper codes to match whatever terminal type the user was using — provided it was in the database.

This must have been a major breakthru for writing portable apps, much like Java was a breakthru to let the same app run on Mac, Unix and Windows… Today, HTML5 and JavaScript allow web content to run on desktops, tablets or phones.

I guess there really isn’t anything new.

During my OS-9 days, termcap was important since almost all connections were done via a terminal (or terminal/telnet program). Most industrial OS-9 machines did not have video screens. I found this surprising, since I had come from the hobbyist OS-9 world where all our systems (Radio Shack Color Computer, Delmar, Tomcat, MM/1, etc.) all had graphics and user interfaces. But in the embedded/industrial space, they were just a box of realtime computing, and if the user did need to interact with it, they hooked up a terminal.

But I digress.

Recently, I began working on a new ticket barcode project that would ultimately run on small Raspberry Pi computers. I was doing all the prototyping work on Windows, and also compiling the same for Mac. Since I do not know anything about writing GUI programs, let alone how I would write something that would work on Windows, Mac and ultimately Linux, I was writing everything as an old style text-mode program.

This was more than enough to test all the functions, even if ultimately we would be using small 7″ color displays at each system. (I sense that I will be writing some articles on Raspberry Pi video in the future.)

Because I am now at the stage where I want to do more than just scroll text, I decided to revisit the old Termcap system and see if I could at least write fancy text programs that could use color, and create fancier text screens, and actually work on all my development platforms. I actually looked in to termcap few months ago when I wanted to do something similar on Arduinos, but at the time I decided it was impossible due to limited memory. (Update: That may not actually be the case.)

My goals of the next few articles will be:

  1. Explain how termcap works.
  2. Explain how to get termcap running on a Windows system (as well as Mac, and Raspberry Pi).
  3. Create a simple library of common screen features (actually based on code I wrote in late 1995, to convert my EthaWin OS-9 user interface to run on the OS-9 machines at work via termcap).

…and after all this, I think I will have a version that works on Arduino as well.

More to come…

ANSI C and subtracting or adding time (hours, etc.) part 2

In my previous article, I rambled a bit about how I first learned to program in C in the late 1980s under the OS-9 operating system on a Radio Shack Color Computer 3. I mentioned this to point out that, even after 25 years, there were still things about C I had never used.

One of those things involves doing time math (adding or subtracting time). If you take a look at the various C related time functions (see time.h):

http://www.cplusplus.com/reference/ctime/

…you will see that the C library has two ways of representing time. One is a time_t value which is some value (but not defined by the standard as to what that value is), and a struct tm structure, which contains fields for things like hour, minute, second, day, month, year, etc. Some time functions work with time_t values, and some work with struct tm structures.

There are four main time functions. You can get the amount of processor time used by a program with clock(). You can get the current time using time() (as a time_t value of some sort). You can get the difference between two times using difftime(). And you can make a time using mktime().

The other time.h functions are conversion utilities: asctime() returns a string representing the current date/time (from a struct tm). ctime() returns a similar string but works on a time_t value. gmtime() converts a time_t value to a struct tm and adjusts the resulting to to be GMT (universal time zone, Greenwich Mean Time). localtime() is like gmtime but it returns a struct tm in local timezone. And lastly, strftime() is like a printf for time. It lets you create a custom string representation of date and time from a struct tm. This is useful if the asctime() and ctime() do not return the format you need.

The current project I am working on deals with event tickets, and the system needs to know when a ticket is valid. By default, a ticket is valid on the day it is activated and then it shuts off. The problem was that a ticket would stop working after midnight, so I needed to implement a grace period. I wanted to define a ticket good for “Today” (or “Friday” or “5/4/2015″) and have it know that even after midnight (when the day became Tomorrow, Saturday or 5/5/2015) it would still be accepted for a certain amount of time.

Almost all examples of handling time I could find relied on knowing something about what the time_t number was. If you *knew* that time_t was “number of seconds since January 1 1970″, all you would have to do is add or subtract a certain amount of seconds from that value and you would be done.

But, according to the ANSI C standard, time_t is implementation specific. If you really want to write portable ANSI C code, you can’t assume anything about time_t other than it being some number.

My program is currently being built for Windows, Mac and Raspberry Pi. All three of these systems seem to handle time_ t the same way, but what if my code gets ported later to some embedded operating system that did it some other way?

The good news is that it’s really not much work to do things the “proper” way, though I certainly understand the lazy programmer mentality of “if it works for me, ship it!”

Here is what I learned and what prompted me to write this article: you can create struct tm values with invalid values and the C time library functions can normalize them.

Here is an example… If you want to create a time of 2:30 a.m., the struct tm values would look like this:

tm_hour = 2;
tm_min = 30;
tm_min = 0;

If all the tm values are properly formatted, you can pass them in to functions like asctime() and they work.

BUT, you can also represent 2:30 a.m. as “150 seconds after midnight” like this:

tm_hour = 0;
tm_min = 0;
tm_sec = 150;

This tm structure appears to be invalid since minutes is listed as being 0-59 in the references I looked at. Because of this, it never dawned on me I might be able to pass in a value other than 0-59.

If you pass this invalid struct tm in to asctime(), it will fail. However, if you pass it in to mktime(), it will normalize the values (adjusting them to the proper hour, minute and second values) and return that as a time_t time. Interesting.

It seemed I might be able to add time simply by adding a number of seconds or hours. 2 hours in the future might be as simple as:

tm_hour = time_hour + 2;

…then I would use mktime() to get an adjust time_t that now represents the time 2 hours in the future.

A few quick tests showed that this did work. Unfortunately, the way I was approaching my ticket expiration task required me to look 2 hours in the past. It didn’t seem possible, since that would mean using negative numbers and surely that wouldn’t work.

Or would it?

I had noticed that the tm_xxx variables were “int” values rather than “unsigned int”. Why? If values are 0-59 (minutes) or 0-23 (hour) or 0-365 (days since January 1), why would it ever need to be a signed negative value? But since a value could clearly be greater than 59 for seconds, perhaps negative values worked as well and that’s why they were “ints”.

Indeed, this is the case. I had never known you could do something like this:

tm_hour = tm_hour - 2;

By doing that, then converting it using mktime() in to a time_t, you end up with a time_t representation of two hours in the past.

Simple, and portable, and “proper.” Even if it looks strange.

The only issue with doing it this way is you need a few more steps. In my case, I had a time_t value that represented when a ticket was activated. It began life as something like this:

time_t activationTime = time(NULL);

When I would be doing my time checks, I would need to know the current time:

time_t currentTime = time(NULL);

And since I was not concerned with the time of day of the activation, just the actual day (month/day/year), I would need to convert each of these in to tm structures so I could look at those values:

struct tm *activationTmPtr;
int activationMonth, activationDay activationYear;
activationTmPtr = localtime(&activationTime);
activationMonth = activationTmPtr->tm_mon;
activationDay = activationTmPtr->tm_mday;
activationYear = activationTmPtr->tm_year;

NOTE: I am copying the values in to my own local variables because localtime(), gmtime() and other calls return a pointer to static data contained inside those functions. If I were to do something like this:

struct tm *activationTmPtr, *currentTmPtr;
activationTmPtr = localtime(&activationTime);
currentTmPtr = localtime(&currentTime);

…that might look proper, but each time localtime() is called, it handles the conversion and returns a pointer to the static memory inside the function. Every call to localtime() is returning the same pointer, so each call to localtime() updates that static memory.

activationTmPtr and currentTmPtr would both be the same address, and would both point to whatever the last localtime() conversion was.

Easy mistake to make, and one of the reasons returning pointers to static data is problematic. The caller has to understand this, and make copies of any data it wishes to keep. (Yeah, this is something I learned the hard way.)

With this in mind, I could get the parts of the local time the same way:

struct tm *currentTmPtr;
int currentMonth, currentDay currentYear;
currentTmPtr = localtime(&currentTime);
currentMonth = currentTmPtr->tm_mon;
currentDay = currentTmPtr->tm_mday;
currentYear = currentTmPtr->tm_year;

Now to see if Activation Day was the same as Today, I could just compare:

if ((currentDay==activationDay) && (currentMonth==activationMonth) && (currentYear==activationYear))

Simple. Though in my application, the ticket could also specify a day-of-week, so there could be a weekend pass active only on “Saturday” and “Sunday”, or a pass good for only “Thursday”. I would do this the same way, but I would use the tm_wday variable (day of week, 0-6).

To deal with a grace period, my logic looked like this:

  • Check current day (either month/day/year or day of week) against target valid day (again, either a month/day/year value, or a specific day of week).
  • If invalid, try the comparison again, but this time have “current day” be X hours earlier. If X was 2 hours, then I could test at 1:30 a.m. and it would be comparing as if the time was still 11:30 p.m. the previous day, and it would pass.

Easy peasy.

To do this, I simply created a special graceTime and graceTmPtr like this:

// Start with current time again and convert to a struct tm we can do math on.
graceTmPtr = localtime(&currentTime);
// Adjust the values to be 2 hours earlier.
gracetTmPtr->tm_hour = graceTmPtr->tm_hour - 2;
// We need to normalize this so we can get the real Month/Year/Day.
graceTime = mktime(graceTmPtr);
// And now we need it back as a struct tm so we can get to those elements.
graceTmPtr = localtime(&graceTime);
// And now we can get to those values.
graceMonth = graceTmPtr->tm_mon;
graceDay = graceTmPtr->tm_mday;
graceYear = graceTmPtr->tm_year;

After this, I could do the same check:

if ((graceDay==activationDay) && (graceMonth==activationMonth) && (graceYear==activationYear))

Problem solved.

Maybe this will help someone else. I know I spent far too much time searching for how to do this before I stumbled on some old post somewhere that mentioned this.

Have fun!

ANSI C and subtracting or adding time (hours, etc.) part 1

I started learning C in the late 1980s on a Tandy/Radio Shack (TRS-80) Color Computer 3. At the time, my college was teaching Pascal and BASIC, so I was learning everything on my own with the help of a friend of mine.

My friend Mark was a great Commodore 64 assembly programmer and he had began programming in C on the Amiga. He helped me with my first real C program which was a user-designed text adventure system for a BBS.

Special thanks goes to another friend of mine, Tim, who was the inspiration of this project. Tim (aka COCO KID) had ran the ADVENTURE SYSTEM BBS in Lufkin, Texas on a CoCo 1. It was set up like a text adventure. If you did “GO WEST” and there was nothing there, it would prompt you to create a room and enter information about it. You could wander around and check mail by doing “LOOK MAILBOX” and stuff. It was great fun, and I decided I wanted something like this for my OS-9 BBS I was running at the time. (This was probably the OS-9 Level 2 BBS by Keith Alphonso of Alpha Software in Louisana. I type things like this in so they show up in Google in case anyone else ever remembers the OS9L2BBS package.)

For learning C, I used the manual from the Microware OS-9 C Compiler and a Pocket C Reference Guide (not sure of the exact name of it, but I still have it somewhere). This was original K&C C — I wouldn’t see an ANSI-C compiler until I started working for Microware years later and began using their Ultra-C compiler. It was quite an experience starting out as a self-taught hobbyist using a company’s products, and eventually actually working for that company. My entire technical career is all based on me sticking with that 8/16-bit CoCo computer and learning OS-9 and C. I look back and imagine what would have happened if I would have just given in and became a DOS or Windows 3 user. Would I have even kept coding?

The reason I share this story is to point out that I started using C a very long time ago — before ANSI C (C89) or C++. I was away from C for some years, and when I started working with it again many things had changed — like the C99 standard finally offering a way to get an integer of a specific size. (“int” is 16-bits on one of the systems I program on at work, and 32-bits on another. Things like this always made writing architecturally portable code challenging.)

Recently, I began working on a new project — a barcode ticket system for a Halloween haunted house project. Since I know C the best, I have been writing it in C and within a few evenings had a working prototype that handled almost all the desired features.

Lest night, I was trying to work around a problem where the system would start rejecting tickets after midnight when the day changed. Normally, tickets sold are fully used up by the guest, but if they had to leave early or just ran out of time to visit all the attractions, the park lets them return on a Thursday or Sunday to use up the rest of their ticket.

My system was now validating the ticket against the current day, with a ticket being valid on the day it was sold, and then also on Thursdays or Sundays. While I was thinking about this, I realized that if a ticket was sold on Friday, and the park stayed open late that night, at midnight the day changed to Saturday and now the ticket would not be valid (since it would only be good on the day it was activated, or a Thursday or Sunday). Fortunately, I thought about this before writing any code. I am pretty sure there would be a lynching if my system suddenly started refusing admission to a park full of guests on a busy Friday night in October!

I proposed several simple solutions to this. One was simply having the system require being activated each day of operation, and recording that state. Tickets sold that day would be active until the system was shut down, or until the system was started up on a different day. This was very simple, but would mean yet another bit of information to keep in sync on about 12 different computer systems running throughout the park. The more parts, the more chance of failure. And failure was not an option (see “lynching” above).

Instead, I decided to simply allow the tickets to have a grace period before they truly expire. If this was set to two hours, the ticket would be valid within two hours of the end of the activation day. Thus, a ticket sold on Friday would be valid until 2am on Saturday morning. As long as the grace period were long enough to cover the latest hour of operation, but short enough that it didn’t overlap with opening time the next day, this would solve the problem. (The overlap issue was also something I thought about before coding. If a ticket were sold at midnight, and the grace period were 12 hours, that means it would still be honored by the system until noon the next day. If the park opened at 11am the next day, it would be allowing tickets for that first hour that really shouldn’t be allowed at all on that day.)

Normally we wouldn’t worry about situations like this, especially in a (mostly) controlled environment running 2-5 days a week from 7pm to midnight (or 1am-ish). But, if this system were used elsewhere, say, for Go Karts and Mini Golf and other activities, there could indeed be times when “Summer Fun Late NIght” tickets might overlap with “Early Bird Special” tickets the next day. I wanted to make sure my system was as flexible as possible.

But I digress…

The purpose of this article (and the next one) is to discuss something in C I had never done: subtracting time.

If a ticket was activated (sold) on a Friday, then it gets scanned when the system thinks it is Saturday (minutes after midnight on Friday). it would be rejected. I wanted to make it check the grace period by taking “current time minus 2 hours” (or whatever it is configured to) and see if that time would have worked. The logic would look like this:

if ticket is not valid for current day,
check to see if ticket is valid for current day – offset hours.

Simple.

But how do you do that? In C, the standard time.h functions let you represent time as either a time_t value, or a struct tm structure. The tm structure contains entries for hour, minute, seconds, year, month, day, etc. The time_t value is … something. Most systems treat it like the number of seconds since some date (like January 1, 1970). If this is the case, then subtracting six hours is really easy:

time_t timeNow;
time_t timeEarlier;

timeNow = time(NULL); // Get current time.
timeEarlier = timeNow – (2*60*60); // Subtract 2 hours of seconds.

Problem solved. Moving on…

But wait… That assumption, which might be the case on a Unix-style system, might not be the case everywhere. The C standard says that time_t is an “arithmetic type capable of representing times” but it doesn’t specify what that value actually is. It could be in seconds, microseconds, or metric seconds. It also does not state what date that time would be based off of.

Any C program that makes the assumption that time_t is “seconds since 1970″ is not guaranteed to be portable to other C systems. Period.

Read that again and let it soak in.

I see C programs do math with time_t values all the time. If you are only writing for Windows, and Microsoft never changes this, you are fine. Ditto for folks who only write for Unix or Linux. But does QNX work this way? OS-9? OSE? PSOS? I really don’t know, and I don’t want to be lazy and write non-portable code when there is a “right way” to do this.

Unfortunately, I did not know the right way to do this. Even though I started programming in C in the late 1980s, and even though I had used C time functions before, I had never tried to subtract time from time.

Some Bing searches (Microsoft gives me Bing Rewards points which pay for my Hulu Plus subscription so I don’t have to – ask me if you want a referral link) led me to a number of discussions of people asking this very question, and many very bad answers to how to do it (like doing math on time_t values).

In the next part of this article, I will share with you some things about C’s time functions that I was not aware of, as well as provide example code on how it works.

Stay tuned…

Cheap bicycle wheel LED sign (POV)

Due to finances, about the only form of recreation I have these days is riding my bike. I like to take casual rides on the many trails here in Des Moines (Iowa is famous for it’s massive bike trail network).

A few years ago, I came across this neat LED display that attaches to a bike wheel and created images using persistence of image (i.e. lights flashing real fast as the wheel rotates, which the eye sees as a complete, though flickering, image):

http://www.ladyada.net/make/spokepov/

Go there and look at the pictures and watch the videos. It is able to display full color and even animate images (I love the Pac-Man and Ghost images they show). It works by having a row of LEDs that flicker on and off as the wheel spins. The wheel has to spin very fast to show an image, so they sell kits with multiple circuit boards of LEDs. The more on the wheel, the slower it has to turn to show an image.

It looked really cool, but it came in a kit, and I am not really that capable of an electronics person. Plus, the kit with three circuit boards was $113.

A found similar (much cheaper) devices on Amazon, though most of them just did preset patterns and didn’t let you load your own. You can find some simple LED wheel lights at Amazon for around $13 that can display short text messages:

http://www.amazon.com/Trademark-Games-Spoke-Message-Light-14/dp/B007VYZP6M/ref=sr_1_7?ie=UTF8&qid=1397281675&sr=8-7&keywords=spoke+led

Do some searching and you will find all kinds of cheap POV displays for bike wheels. I even found one for around $12 that was programmable via USB:

http://www.amazon.com/Docooler-Programmable-Colorful-Bicycle-32-pattern/dp/B00FOIZFNK/ref=sr_1_1?ie=UTF8&qid=1397281771&sr=8-1&keywords=spoke+led+programmable

None of these are anywhere near as cool as the Adafruit SPOKEPOV kit, but they might be pretty neat for the money.

Then, I came across this one on from an e-Bay store:

http://www.ebay.com/itm/PC-Programmable-Wireless-LED-Custom-Message-Bike-Wheel-Lights-/400354534043?pt=LH_DefaultDomain_0&hash=item5d36fd629b

It had two rows of LEDs and could attach to the hub of the bike and display messages or graphics. At the time I found it, there was a seller auctioning them off, and I picked one up for $6 (shipped from the US, even). Unfortunately, the device was not like the pictures show — it was not in color, just blue (the description says this, but all the listings, including Amazon, use pictures showing one with color).

Also, the device would not fit the hub of my bike (the bolts were too short), nor the sensor on the frame (the bracket was too small). I am not sure what tiny little bikes these were made for, but my old 1998 Trek wasn’t one of them.

However, with a bit of rigging, it was easy to attach the device to the spokes of my bike (rather than clamping it around the hub) using some tape, and then I could do some quick experiments.

If I get time, I would like to experiment with a very low-cost version of this, using an Arduino-style device and a strip of the high speed LPN8806 addressable LEDs. An Arduino in a plastic enclosure with batteries could easily power two segments of 32 LEDs (wider spacing than the commercial units, though) and do full color. The only other hardware would be a magnet and a sensor so the device can tell when the led strips circle around.

Sound fun? More to come… (I already have created JavaScript code that lets me load in an image in a web browser and convert it to the format that this device would need to display it.)

Porting from 32-bit systems: 16-bit constants

I recently ran in to an issue at my day job where I had to write some time functions for a project. My work system did not have <time.h> and related functions like gmtime(), which I needed.

Unfortunately, once I implemented my version of gmtime() routine (based on some code I found online), I found it did not work on my target system. Testing on a PC using GNU-C worked fine, so I expected it had something to do with the code not being written for systems with 16-bit “ints” — like the Arduino.

I narrowed down the problematic code, and used the Arduino to test it. Here is the sample:

#define SECS_DAY          (24*60*60)

void setup()
{
  long           time;
  unsigned long  dayclock;

  Serial.begin(9600);

  time =   1396342111;

  dayclock = (unsigned long)time % SECS_DAY;

  Serial.println(time);
  Serial.println(dayclock);
}

void loop()
{
}

On the PC, dayclock would print as 31711. On an Arduino, it would print as 18911. Initially I just tried to cast things to “unsigned long” but that did nothing. When I realized my mistake, I felt rather dumb since I learned this long ago.

Numeric constants, like that #define, are treated as “int” values meaning that on the PC (where int is 32-bits) they were different than on my target system (where int is 16-bit).

When dealing with long constants, you add “L” to the number like this:

#define THISISANINT 123456
#define THISISALONG 123456L

To fix my problem, all I did was throw in the Ls:

#define SECS_DAY          (24L*60L*60L)

The code I used as reference was written by someone who probably only considered it running on machines with 32-bit ints. Most desktop (PC/Mac/etc.) programmers tend to code this way.

Maybe this reminder will help someone else as they try to port code to an Arduino project.

Side note: Rather than use “int” and “long”, if you use a new enough compiler (C99 standard), include and use the actual type you want, such as uint8_t, uint16_t, or uint32_t. As you can see, “int” on the PC would be 32-bits, and “int” on Arduino (or MSP430, or…) would be 16-bits. It’s not portable code that way, and the C standard has finally solved this challenge.

Here’s another example for you to try… It should print out 86400 (24*60*60), which it does on a PC/32-bit system, but not on a system where ints are 16-bits. Have fun!

// This will fail (ints, 16-bit)
#define SECS_DAY  (24*60*60)

// This works (longs, 32-bit)
//#define SECS_DAY  (24L*60L*60L)

void setup()
{
  Serial.begin(9600);

  Serial.println(SECS_DAY);
}

void loop()
{
}

Virtual Reality … back again.

With the recent news that Facebook is buying a Virtual Reality headset company for 2 billion dollars, it seems I can’t get away from coverage on V.R. For some of us that are older than Facebook, and who experienced commercial V.R. over 20 years ago, I say: bring it on! Or rather, bring it back.

This is nothing new. But it should be improved: higher resolution graphics, and faster framerate.

My first experience with V.R. was a Virtuality “Dactyl Nightmare” arcade game in Dallas. My friend Larry took me on a road trip from East Texas to Dallas to check out a few places – including the defunct Incredible Universe store (look them up sometime for a mind blowing retail experience years ahead of its time). We also visited some placed called Dave and Busters which was, at the time, known as a place for V.R. type games.

Dactyl Nightmare was powered by Commodore Amigas, and thus was vastly more advanced than what any non-Amiga owner has seen. (Remember, it took the PC world YEARS to even remotely catch up to what the Amiga was doing in the 1980s.)

You stood on a small circular platform with a round railing around it, and put on a large headset (like a motorcycle helmet) and a belt. In your hand was a simple controller with a trigger switch button and a thumb button. In the game, you could see yourself inside of an Escher-like playfield with stairs and platforms. You would press the thumb button to walk forward in whatever direction you were facing, and use the trigger button to fire.

Above you flew a pterodactyl that you could shoot at. You could see a digital representation of your arm in front of you. You could hear yourself walking. It was a very intense few minutes inside this virtual world, and when the game was over, my heart was pounding and I had broken in to a sweat.

It was amazing.

A few years later, during a business trip to Canda, I encountered a later version of the Virtuality system running Missile Command V.R. It was an update to the classic Missile Command arcade game from the 80s, but you were seeing things from one of the missile launching stations and had to look up and all around to target incoming missiles and fire at them.

It also was amazing, but wasn’t as fun of a game (to me) as the original. The graphics were better.

Atari released a home version of Missile Command 3-D for their Jaguar system, though playing it on a TV wasn’t quite the same. Atari had plans to release a V.R. helmet, and even showed it off at a trade show, but it never made it to release.

Sega also was working on a V.R. project, and a friend of mine was one of the developers working on three launch titles. Google “Iron Hammer Sega” on YouTube and you will see footage of this old V.R. system.

Around 1994 or 1995, Disney’s Epcot was presenting an Imagineering exhibit on DisneyVision – their attempt to enter the V.R. world. They gave daily presentations where a few lucky audience members we brought up on stage and hooked up to the Aladdin’s Magic Carpet V.R. experience, while the rest of us watched the game play on overhead monitors.

A short time after this, that game was sitting at the Disneyland Tomorrowland arcade with a cast member. I believe it was $3 to play, which I did. The graphics were great and light years beyond Dactyl Nightmare. The goal was to fly on a magic carpet and collect gold pieces or jewels or something. I only played it once, but it was great. You sat down (on your magic carpet, though straddling it like a motorcycle), and you held the edges of the carpet (like motorcycle handlebars). Somehow I think they may have used a motorcycle game as a reference.

There were even home V.R. helmets. I bought a StuntMaster helmet for less than $100. It was a simple non-3-D LCD display in a helmet, and you would clip a rod to your shoulder sleeve. This rod was attached to the helmet, and as you looked left and right, it would rotate an analog input so the game would get LEFT and RIGHT motion. It was barely 3-D, but you could use it on a Sega Genesis or other home systems and turn your head left and right instead of pressing a joypad left or right.

There were many other higher end V.R. helmets being sold during those days, and games for them.

Nintendo even tried to get in to the home console action, like Sega and Atari were, and unlike those two, Nintendo actually shipped their product… As the VirtualBoy. Which sat on a table. And you looked in to the goggles, and couldn’t move them. Bascially, it was a 3-D Nintendo you had to stick your face in, and didn’t qualify as any kind of V.R. system (even the StuntMaster was better than that).

Google it if you haven’t heard about it.

Was V.R. ahead of its time back then? It was more than playable, and amazingly fun. Perhaps if the games were a quarter instead of $3 it would have stayed around longer… But even the .25 arcade games went away. Perhaps if the home helmets were $50 instead of $500 it would have stayed around longer… But larger and larger TVs came out and gaming when super sized…

Will it work this time? Have we lost 20 years of advances because of lack of development?

I can’t wait to find out.

It’s so retro, it might even be cooler this time around.