4:22 PM 2/9/99
The folling file is encluded "as is", with out 
editing for clarity.
Read at thine own risk.

---
99-01-21- 8:31pm GMT-4

Syntax: @ row, column, string literal

Where the string literal is printed to the screen at such co-ordinated...
In theory...

For some reason not yet know to me, 
I get total and complete garbage on the screen.

I believe the problem concerns the
renderAt function;
which either:
1) is using invalid data from chrROM[]
2) is using data loaded form an invalid "CHAR.ROM"
3) is broken in strange and unusal ways

I will take a break to eat lunch.

I have written over 700 lines of code;
indeed, it's closer to 1000 as I've re-written a lot of it 
trying to get this to work.

But it does not.

So I will take a break.

---Kei

11:38pm

Found the error a few mins ago:

(2^x ) uses floating point math, so on ints or chars it fucks up
1<<x Is what u want. It's nicer, just like LSR on the C64.

I now love C.

May the coding continue...

---Kei

99-01-22-Fr

4 am

I seem to be misusing strtoul...
I checked cguide.doc...
and I know know what arg 2 is for...
but The colors still look off...

minor table...
I'll probally save the palette to a datafile for m2...
or something.

In any case, 
I've done more than enough coding and planing and recoding for one day...

Perhaps I'll send this to chip...
That's all for now.

Gonne look at it with a fresh head, call it m2, 
move the fuck on.

I'm proud and happy, btw.
Just restless and .. lacking sleep....
no, it's not sleep I lack. It's a break...
I'll go toss some weights around or soemthing...
Since today's a holiday, I might go and see what this beach thing is about...

---Kei.

Wait !!!

Let me say this:

Command Line Arguments!!!

t = enable test mode. 
Instead of parsing TESTIN.TXT; m1 do some internal test routines... 
and print the entire charset to the screen... hopefully...

d = enable debug mode.
Regarless of mode, 
SOMETHING is written to m1bug.log...
using this flag will include debugging info as well.

v = increase verbosity.
The more v's u use, the mor everbose the M1BUG.LOG file
will be. I won't go above 3 if I were u...
You've been warned.
In fact, there's little reason to use this... unles su wanna hack at the C src...

---]

Files in use:

input:

CHAR.ROM : ROM dump of C64 CHARSET.
TEXTIN.TXT : the semi-tokenized program file to parse.
format:
@column,row,literal
...

-

The @ indicates PrintAt, column = 0-39, row = 0-24 (numeric constant literals);
and literal is a quote-enclosed string, e.g.

@1,1,"HELLO WORLD!"

Note that the hyphen ('-') is the EOF character...
forget it, and suffer in unspeakable pain.

---]

Architecture (how it works)

I don't feel like talking about it... to me, this is like crawling... the only point is
to move, not move well. When I walk, I'll explain how I walk...
Or at least why I put a bop in my step...

A few notes, though:

CHAR.ROM is read, using fread, into RAM in one fell swoop.

TEXTIN.TXT is run thru an adhoc processor which ...
1) copies it to RAM
2) replaces \f and \l and such with 0
3) replaces the EOF with a sting of zeroes... supposedly 3, 
but it is broken so... 
more like 12.

--]

General Rambling

Like avid chess players, programmers are wont to go about randomly challenging
others to a game every once and a while... even if it's never spoken, or
even consciously recognized, everything that reaches the processor of a peer
is an implicit challenge... "I'm cool... beat that.." or even "I'd stuck...
but I bet u will be too". At least, this is my perception...

So, my m1 thingy isn't much, but m2 should be much more cleanly written...
and then, m3 will probally be able to contest with Chip's C64.exe...

I didn't put in sprites, border, or background cause i wanted the damn
thing to work... m(1++) (i.e. some later m) will add this in...

Btw, m is for militant, because I coded this with great agression.
Not recklessess, mind you, although the code is admittedly unpolished,
but with the philosophy that this will work...

I feel the Tao growing stronger within me,
Bu I am not a Master yet...

--- :)

My enitre life is a quest... of spiritual, mental, and physical proportions...
To me, seeking the Tao of Programming is a worthy pursuit...

My Thanks to Chip, for inspiring me to get off my ass( or, rather, sit up 
straight on my ass) and do some code; to Eric for the same reason (as well
as helping me with getting VCC to compile under Linux... and reminding me
or the importance of test harnesses), and to the Allegro crew...

Speaking of which, I compiled this with Allegro 3.0; but I have 3.1 sitting 
on my HD, waiting to be installed...

Always something to do...

//END RAMBLE

---Kei

4:35 am
(Just checked out chip's latest c64.exe... going good...)

Oh, and, one more thing:

The colors seem to be messed up...
i mentione that b4...
but, I'll fix it for m2...
Really, I will!

---Kei

Jumping: Gotos, Gosubs, Call Sub...:

I forsee using a linked list of sorts to keep track of line numbers...
The C64 used a one-driectional set of pointers to all reading quickly
thru the BASIC file; I want to outdo it and go both ways...
But not store anything in the file, calaculate at runtime, such that
various ad hoc compresison routines can be used...

I may reconsider this. I have to do more research, and also actually read
that chapeter in my C book about Linked Lists...
In the end, though, once it's fast, everyone will be happy...
cept it's a RAM hog.

--]

990122/13:15

added
setRam:

I personally don't see why you'd need more than a few hundered bytes, anyways...
but remember, I'm getting ready to move up to m2...

also, I cleaned up the source a little...

I'mm gonna take Eric's hint and split this stuff into files...
make some of it into a lib or something...

CBM BASIC 2.0 used UMA for DATA and PROGRAMS;

BOTTOM - > PROGRAM -> FREE <- DATA (VARIABLES) <- TOP

note that constants (string literals, numeric constants, DATA statements) were embedded
in PROGRAM space. 

[UMA: Unified Memory Architecture. used in some video cards today, 
especially ones built onto the motherboard... the marketing drones
would make u belive this was new to the PC, but the C64 has been doing
this in HW and SW (Hard and Soft Ware) for well over... 15+ years now...
And probally the calculators and PETs that came before it...]

I wish to make no direct references to PROGRAM constants, i.e. no pointers.
also, I want to make it easier to seperate DATA statements form the code...
and drop them in a .dat file or soemthing.

I'm not sure how I'll do Disk I/O yet. 
But I'm full of Ideas, inspired by the C64 Programmer's Reference Guide,
and others....

Hey, I can almost code FRE()!

I will make the paraments for all functions do something, though...
if u want it to be just readable, do it like ST, which is a reserved, 
read-only variable which changes value according to:
1) Disk errors
2) The action of u reading it

I call this a latch-read variable, but I think there's a better name,
the logic is: it "latches" itself in place until u read it.

TI is not latch-read, it's read-only.

Both are implicit system calls... 
in my c99 speak (which is scattered over pieces of paper) this
would involve the ?_* calls... like T_COLOR (cursor color).

(T_ stands for Page Three, which is where all the system variables were 
usually found... a fun place to be indeed)

Note also that CBM BASIC had automatic garbage collection eons before 
Java ever reared it's buzzword-heavy head... (and yes, I have a thing 
about Java... )

perhaps calling free with a non-zero value would force garbage collection...

Anyhow, time to upload this stuff.

---Kei.

P.S. Note that the line numbers are counted from 0, just like u could on a real 64...
do u remember that if you tried to LIST 0, the whole freaking program would LIST?!

---Kei.

Hmmm.. I need a seperate Thanks and Contacts file...
Oh, and some sort of OpenSource Liscence...

*shrugg*

In time.

---]
990123/02:20

I am miserable..yet not...

m1 has broken color.
It brakes on LINE20.
it doesn't matter what line 20 is.

It acts like Windows.

I think ggi may be in order...

---

m1 be damned.
I'm working on m2 exclusively from now...

---Kei.

19:54
    /*
       $RGBCOLOR0=101010
       $RGBCOLOR1=ffffff
       $RGBCOLOR2=e04040
       $RGBCOLOR3=60ffff
       $RGBCOLOR4=e060e0
       $RGBCOLOR5=40e040
       $RGBCOLOR6=4040e0
       $RGBCOLOR7=ffff40
       $RGBCOLOR8=e0a040
       $RGBCOLOR9=9c7448
       $RGBCOLOR10=ffa0a0
       $RGBCOLOR11=545454
       $RGBCOLOR12=888888
       $RGBCOLOR13=a0ffa0
       $RGBCOLOR14=a0a0ff
       $RGBCOLOR15=c0c0c0
        */

The RGB table from CCS...
note that black is actually grey...

Here's an Idea:
Rendering the scanlines as less bright color varients!
Whoo hoo!

---L8r

---]

11:48 PM 2/5/99

You know, 
notepad is probally the best 
part of Windows.
Or, rather, the only technically
good thing.
It starts up fast,
and has that cool
binding to F5 just for ppl like me.

m1r5 is the last great, best hope for m1.

m1 is now dead.
C99 lives on, however,
and I'm working on m2/m3 already.

I may have mentioned that m1 is slow.
that's not true, it's horribly designed,
and thus is horribly slow.
like, at least 1000 times as slow as it
needs to be.

will the new m's be faster?

heck and cucumber, yes!!

/* ----------------- What to expect to come after m1 -------------- */

m3 will make use of "advanced" techniques,
such as Tile Caching; Interrupt-driven
timers; and Modular Design!

what about m2?

I don't like even numbers,
but m2 will be better too. 
At least 1000 times faster.
it will use a plain Tile-based design,
with a Bitmapped Background,
and maybe other goodies.

Right now I'm writing the boring support libraries
for things such as ASCII to screencode conversion;

The exact specification of m2 are uncertain.
I do wish to include an IDE... i.e. emulate
the C64's fullscreen editor.

I may introduce a 640x400 mode.
well, I will eventually (the C65 could do this),
but I'm not sure when. I doubt before m3, though.

Multiple modes is a design issue, 
and I already have enough to deal with...

sprites (my favourite C64 thingies) will be back,
but I'm not sure when or how.

Sound will be in m2, albeit primative.
Loading and playing samples will be supported.

Loading? Yes, loading. File I/O will also be 
implemented.

For now it will be primitive, 
maybe for m3+ i will switch to .d64 and/or .x64
support, also Chip is working on a filesytem (and 
reverse engineering GEOS... in QBASIC... and I 
though -I- was ambitious!), so imaged filesystems
are my next "boring" topic to slay (no frontend =
boring by "flashbang" standards"). 

Also I chose to be unemployed
in order to focus on several personal issues.

the M series is not a direct personal issue,
but imporoving myself is, 
and program design and implementation helps
greatly in many aspects...

One other note:
In addition to C64-type sprites (MOBs);
I may add support for Genesis-type sprites;
albeit a bit more expanded (up to 16x16 cells?).

I played around with the genesis C compiler a bit,
I may upload my demo l8r,
once I comment the code and inform the author...
Tile-based graphics are quite cool. 
But Background Stamping of some for
is needed for text-based displays...
maybe the genesis has this facility too...

One commercial application of C99 would be to act as 
a development environment for Arcade Machines
of some sort...

Sort of like how the JDK acts as a development
environment for embedded applications... or
web browsers, in the case of applets.
 
If Realtime Java existed, I might not be doing C99 
at all.

To my mind, though, Realtime things are better
modled procedurally... button bar is pressed, 
foo happens. No fancy OO folly.

The backend that simulates and environment,
esp. in MUDlike games, is where OO benefits
are to be had...

//END RANT

So, Let me go upload this stuff... 
assuming I can get ont he net...

Oh, one more thing.

m3 will definately use Allegro 3.1,
I'll install it Real Soon Now...

m2 probally will too, but I'm not sure
at this point in time,
stay tuned.

Hmmm.. and Open Arcade machine.... 
There's an Idea.

---Kei.

NB:

/* ----------- Important messages ------------*/

All code, comments, etc.
are (C) 1999 Keinall H. Caddle.
some code / comments from Chip
and Nelish are also present.

However, you may redistribute everything as you
wish, under these conditions:

1) No fee may be charged, except a reasonable one
for the media, etc.
2) This copyright/disclaimer must appear, and 
any modification made to my original creation
must be clearly indicated before it is 
redistributed.
3) ABSOLUTELY NO WARRANTY is given, espressed
or implied, for this software. Use at your
own risk. I will not be held liable.
I do not even have faith in this code,
neighter should you!

/* ------------ contact info -----------------*/

granitor@geocites.com

"Home" Page:

http://www.geocities.com/SiliconValley/Lakes/2658

Project page:

http://www.geocities.com/SiliconValley/Lakes/2658/m1.htm

Thanks again
to Chip and Nelish of #kode, #jerk on FEFnet (irc.fef.net)
for their help in motivating me...
(and laughing with me at horrible attempt)

I will document KC Sometime In The Future(tm). heh. 
Until then, you can guess how to play... 

/* ------- The End.... Or is it? --------------*/


/* ------ NEW: Bugless Version released! ----- */

2:51 PM 2/9/99

with m1r6,
m1 now acts like a nice dos app,
and not like a M$ OS.

I am content in my ability to crawl.

Now i'm doing things like getting the docs together...
althouygh it's already uploaded...
Thank goodness for re-uploading.

make and -Wall are my friends.

Next up will be m2... which may use 3-part version numbers,
as in m2.0.0 ; etc.

Maybe. I'll ponder it.

The reason is that once I have a stable core, I'll
work on adding commands like they've
gone out of style...
so a number to indicate an addition of commands 
would help.

*shrugg*

/* -------- The end.... muhahahhahaha! ------------ */
