Re: RFC : SOME IDEAS FOR THE APPLE II FPGA'ers

["Michael J. Mahon" <mjmahon@aol.com>]

Mark McDougall wrote:
> mdj wrote:
>
> > > Yes, I regularly assemble a few thousand lines with Merlin 8 Pro,
> > > and with the screen listing turned off, it does it in seconds, not
> > > minutes (with an 8MHz Zip Chip).  That's fast enough that I don't
> > > get out of my chair.  ;-)
>
>
> Interesting that you choose not to do development on a PC (under an 
> emulator)...

I really like the smell of steam and oil...   ;-)

More literally, I love the actual experience of the Apple II, and that
even extends to using it's somewhat limited (but not too limiting)
toolset.

> A few years back I did some development on the TRS-80 which involved a 
> relatively small amount of Z80 assembler (in the vicinity of a few 
> hundred lines). I was using an emulator mainly so I could edit the 
> source using my favourite PC text editor, 1280x1024 LCD display, etc 
> etc, and then task-switch to the emulator and run a native TRS-80 DOS 
> batch file which re-imported the text file into the virtual disk image 
> and then ran the assembler.
>
> Originally I had the emulation running at 'natural speed' (disk drives 
> and CPU) and I was incredulous at how long it took to assemble my code - 
> MINUTES!!! The software was split across 2 virtual floppy drives and 
> from what I could tell, quite I/O bound. I just don't seem to recall it 
> ever taking that long - I guess I've become more impatient as computers 
> have gotten faster!?!
>
> By un-throttling the emulator it reduced the time to build to a handful 
> of seconds! Ultimately I could edit the assembler source and have it 
> actually *running* less than 10 seconds after hitting <F2> in my editor.
>
> A far cry from the days when I was attempting a pixel_perfect port of 
> Lode Runner to the TRS-80! ;)

Yes, and we have become more than a little addicted to that speed.

For example, we recompile after changing a comment!

And we don't pore over a post-mortem or a memory image for an hour
doing reasonableness checking of all the variables--which usually
finds several bugs that haven't fully manifested themselves yet.
Instead, we find "the" bug, fix it in seconds, and recompile and re-run.

As a result, many programmers do not really understand the behavior of
their programs, except from the display, and many bugs and design errors
lurk undiscovered until some corner case or workload exercises them,
usually in the field.

We used to say that the worst thing that can happen to a new
programmer is for his first code to run correctly.  That sets his
expectations, and his evaluation of his abilities, *exactly wrong*
for a long time!

Speedy development cycles--twice a minute instead of twice a day--can
have a corrosive effect on a programmer's discipline, and his grasp of
the program.  Having to wait allows time to think, and re-think, until
a clearer understanding emerges.

Now, in the interest of equal time, here's the downside of longer
cycles:  If you have an hour to turn your code around, that's enough
time to lose focus and thrash your mental cache, so when you finally
see the next run's results, you take half an hour just to re-establish
your mental context and begin to make progress...

So I propose that the human mind needs 1) time to observe and think,
and 2) discipline to keep its focus.  Programming is a bear, and I
love it!  ;-)

-michael

Music synthesis for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."