[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Apple II weather display

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."