From http://lists.tunes.org/archives/tunes-lll/1999-July/000121.html


On Fri, Jul 30, 1999 at 07:43:54PM -0400, Paul Dufresne wrote:
> My brother did found it funny that Retro is called like that.
> For him retro means going back (generally in time) so this does
> not looks like a name of a OS to come. So he'd like to know
> from where the name came.

Heheh, here's the story: When I started playing with OS stuff last year (not
seriously), I was reading about some old things like FORTH and ITS, dating
back to the 1960's and 70's.  The past few years in America, there's been a
revival of disco music (along with bell bottoms, platform shoes, and all
that crap) and they call it "retro".  Now, my OS was named by musicians.. I
was telling a fellow musician about my ideas, how it would be cool to have a
small OS that isn't bloated and unmanageable like Windows... go back to the
70's and resurrect a line of software that died out.  He goes "hmm.. sounds
kinda retro.."

I think it sounds kinda rebellious, which is a Good Thing now that everybody
hates the M$ empire. :) It seems like other people are as sick of the future
as I am.  Look at TUNES, the idea there isn't to make some great new
invention, just take some decades-old ideas and combine them in one OS.  The
first time I saw Knuth's "Art of Computer Programming" in the library I
thought "god that looks old.. 1973!!! nevermind.."  Now it's my programming
bible.  Find me something better published in the 90's.. if such a thing
exists, it'll be like a needle in a haystack.  "Newer" doesn't necessarily
mean "better".
	New cars = flimsier
	New farming methods = more devastating
	New version of Netscape = more bloat, more bullshit
One thing is better now: computer hardware.  Give me 70's software on 90's
and 00's hardware :)

btw, I'm also gonna mention this on my web page, under "Random Comments"..


> Also, I began to 'translate' my serial.asm to be callable by Forth.
> It work now for set-dtr and reset-dtr (comport -- ). But I may
> have some trouble with set-rx-handler and set-error-handler that
> should look like (comport execution-token -- ). I don't know yet,
> maybe it is easy to do, it is just not obvious to me yet.

You don't have to convert everything to forth conventions, only functions
you want to test interactively.  Also, serial I/O can be very demanding
(using my 56k modem on my 486-33, for example) so don't de-optimize any
critical routines.  Set-rx-handler, set-error-handler, find-port... it
wouldn't hurt to "translate" them.

If you want to write parts of your driver in forth, put them in bforth.fo. 
Later, when there's a filesystem, you can put it in serial.fo, and do this:
	INCLUDE "serial.fo"
from bforth.fo.  We'll also put the machine-code part in an XCOM module and
load that from serial.fo.  We could even include serial.fo in the XCOM
module.  That should be flexible enough.

-- 
Tom Novelli <tcn@tunes.org>
http://bespin.tunes.org/~tcn