heuser.marcus{at}freenet.de wrote:
> On Aug 22, 8:38 am, "Michael J. Mahon"  wrote:
>> heuser.mar...{at}freenet.de wrote:
>>
>> Fleshing out a design "on paper" is an excellent way of building
>> several generations of "virtual prototypes" so that less effort is
>> wasted going down major detailed blind alleys.
> 
> I once did several versions of a tile-mapping routine (like those
> found in the earlier Ultima games) because I was curious if I can
> do it with acceptable speed in hires graphics mode which of course
> uses much more memory than the charcter graphics modes of the Atari
> and C64 platforms.
> 
> It was a terrific experience as I only used graph paper (with 5 mm
> squares), a pencil, a 6502 mnemonics and cycle table and my trusty
> 25 year old calculator - while lying on my bed (I call it "testbed"
> since then and I don't make this up now!).
> 
> Granted, I took my time with it and the cycle count didn't always
> come down but in the end, when I was satisfied with the speed/space
> ratio (version 7, IIRC), I hacked it in and it worked from the get-go.
> 
> It really was a mixture of exercise and experiment and in the end
> it provided me with some 6502 training and showed me that it is very
> well possible to think a problem through, choose a good algorithm,
> implement it, debug it, improve it and have something working in the
> end. Immensely gratifying.
> 
>> The trick for me is sustaining enthusiasm for a long time without
>> actually coding anything.  I find that putting pencil to paper is
>> both focusing and stimulating, but I'm sure folks differ in that
>> respect.  (My real wastebasket does tend to fill up with paper.  ;-)
> 
> I hear you!
> 

This, in my opinion, is the most overlooked design process.  I have a 
bunch of notebooks (engineering computational pads) that have a bright 
grid on the back side, and the front side has the faint image of the 
back side showing through.  Jim Blinn once wrote a great article on the 
benefits of pencil and paper design - I think it is still available in 
his book "A Trip Down the Graphics Pipeline".  One of those must-have 
books.  Unlike Michael, I never throw stuff in the wastebasket.  I leave 
the ideas that don't work out in my notebook.  Either I will eventually 
find a purpose for the idea, or it will help remind me why it didn't 
work in the first place so I don't try it again!

Everyone talks about bottom-up and top-down design.  I find that you 
can't really do one without the other.  I have a system design in my 
head (or paper) and start coding the foundation.  Based on the top-level 
ideas, I decide which are the most crucial low-level routines and write 
them with a lot of test cases.  Making the low-level routines simple and 
robust ensures I won't be wasting valuable high-level programming time 
debugging the basic routines.  Kind of like Legos, only I get to create 
the bricks, too.  This also allows me to do coding while fleshing out 
the overall design.  Sometimes the low-level routines will influence the 
high-level design.

I also find low-level code just as challenging as higher level routines. 
  A really efficient memory manager or fast floating point divide 
routine can be projects in themselves.  So create some mini-projects out 
of your big project to keep enthusiasm up and progress moving.

> 
> bye
> Marcus

And don't worry about expectations.  This is a project for you, not 
anyone else.  Even if it doesn't come to fruition, the ideas and 
discussions have value in themselves.

Dave...
--- SBBSecho 2.12-Win32