On January 4th, just a few days before HC16 started, Jibz (Joergen Ibsen)
posted this to the Hugi Compo mailing list:

> Hi Folks!
> 
> Since it has been a while since there has been any activity on this
> mailing-list, I thought we might kill some time till the next compo
> with a small task:
> 
> Write a program (following the normal base rules we have) which
> outputs the current date and time in the following format:
> 
> Weekday Month Dth year, HH:MM:SS
> 
> E.g.
> 
> Friday January 4th 2002, 10:26:30
> Monday December 24th 2001, 23:59:59
> Wednesday January 3rd 2001, 12:31:15
> 
> My initial code was 451 bytes long, and after about an hour it is
> down to 309 bytes.

Lawrence E. Boothby sent a 510-byte calendar program, which does
not do what Jibz said but is very nice so I include it; he wrote:

> The keys are all 4 arrow keys, pgup/dn, home, and esc. It has full
> range and not only leap year adjustment, but also skips leap year
> when that falls on a century. If I already sent it to you when we
> first started talking about apack, ignore this. I've learned things
> since competing in Hugi though.

Have fun reverse engineering it since he only sent the .COM :-)

For the pseudocompo itself, there were response from me, INT-E, Alexione
and Sniper.  Here are the programs, in the hope that you can learn something
from them.

Since this was not a real compo, but only a simple task to stay warm until
HC16 started, nobody attempted more complicated optimization strategies
such as compression of the printed strings (focusing on tactical optimization
instead) and all the entries are buggy in some respect. Here is the list:

Alexione	230 bytes	uses INT 29h (which is not redirectable),
				does not print st/nd/rd.
INT-E		233 bytes	does not strip leading zeros from the day;
				incorrectly prints 11st, 12nd, 13rd.  A fixed
				version (int-e_ok.{asm,com}) is 242 bytes.
Bonz		236 bytes	does not print the right century in 1980-1999

INT-E saw a pretty easy way to gain another byte but did not have
time to apply the technique.  Here's what he wrote me:

> > > The really nice thing about [the AAM/SAHF] trick is that
> > > the 80h isn't fixed and sometimes you can save some more space by
> > > choosing a different value for it, which sometimes allows one to
> > > embed the data in code and do other similarily nasty stuff with it.
> > 
> > And I guess that's why you encode all the bytes but the last
> > instead of encoding only the last which would be less painful
> > when typing...
> 
> Right.  Now that you mention it: one can save a byte by letting
> Y equal C3h-' ' and swapping the meaning of Y there/Y not there:
> 
> rest:   db      ' '+Y, 32h, 09h, ','+Y, ' '+Y
>         db      04h, ':'+Y, 02h, ':'+Y, 00h, 0Dh+Y, 0Ah+Y, '$'+Y
> 
> will start with a ret instruction then (And I guess you know what to
> do with that ;-).
> 
> There isn't much freedom for the choice of X though, it has to be
> at least 7Ah ('y'+1) and no bigger than 85h (FF-'y').

I hope you like these little gems!

Paolo aka Bonz
