Re: Apple II weather display

[BLuRry <brendan.robert@gmail.com>]

On Apr 18, 3:13 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
> BLuRry wrote:
> > On Apr 18, 2:22 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> >>BLuRry wrote:
>
> >>>On Apr 18, 8:29 am, Osgeld <osg...@cheesefactory.us> wrote:
>
> >>>>Another ghetto fab apple II graphics project my me. It downloads
> >>>>information from weather underground's mobile site and processes it
> >>>>for display on a II
>
> >>>>pt 1 of 3http://hackaday.com/2011/04/18/apple-ii-weather-display-part-1/
>
> >>>Awesome stuff!  You can probably get a higher baud rate though, just
> >>>not from Basic.  If you want to make a high-speed v2 of it, I don't
> >>>mind if you borrow the routines from AGS.  It has all the graphics
> >>>conversion, bootstrap, and high-speed (with compression) communication
> >>>writing for both the apple and PC/Mac side.  So all you'd have to do
> >>>is convert the web download part to Java. (but that's pretty
> >>>straightforward)
>
> >>I'm quite sure that communication speed is not the issue here.
>
> >>It's the BASIC used to do the graphics updates.
>
> >>The slow drawing of the block fonts is a dead giveaway.  Using shape
> >>tables for the characters and DRAW or XDRAW would speed the program
> >>up very significantly (as would using any block animation routines,
> >>but let's keep in in BASIC ;-).
>
> >>-michael
>
> >>NadaNet 3.1 for Apple II parallel computing!
> >>Home page:  http://home.comcast.net/~mjmahon/
>
> >>"The wastebasket is our most important design
> >>tool--and it's seriously underused."
>
> > Hmmm... looked like there was a beagle compiler copyright notice in
> > there.  Putting that aside, maybe using something more graphically-
> > oriented like Apex would be faster.  I remember that being pretty
> > decent for graphics rendering and also pretty easy to pick up.
>
> Applesoft shape tables are a very good approach to creating
> custom character sets, both large and small, for hi-res screens.
>
> They are implemented in assembly language (in the ROMs), so they
> perform quite well--particularly for drawing large block characters
> with lots of pixels.  They also make it trivial to erase previously
> drawn characters before re-drawing.
>
> They are compatible with Applesoft compilers.
>
> BTW, depending on the algorithm (seems like a line-scan type) used
> by the program, a compiler might do little to improve drawing if it
> is done a pixel at a time--that would just result very many fast calls
> to a relatively slow routine in ROM.
>
> As always, changes to the algorithm can make huge differences in
> execution speed, while compilation (such as it is for BASIC) can
> only improve speed by a small factor.  Put another way, doing something
> in a terrible way faster is not nearly as effective as doing it
> cleverly slower.
>
> -michael
>
> NadaNet 3.1 for Apple II parallel computing!
> Home page:  http://home.comcast.net/~mjmahon/
>
> "The wastebasket is our most important design
> tool--and it's seriously underused."

Well, Apex is really well optimized for writing text to the screen
using standard print statements.  Unlike using, say, a beagle bros
ampersand library to do something similar, Apex had the nice advantage
of letting you change your graphics mode and not have to go rewrite
your program, e.g. switching between color dhgr and hires was a
relatively painless affair and the drawing (and printing) commands
didn't change.  Plus it has pretty good sound, mouse and joystick
routines.  I had a blast with it in high-school.

-B