Re: Apple II weather display

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

On Apr 19, 10:46 pm, Osgeld <osg...@cheesefactory.us> wrote:
> I might consider a fast V2 (or something along the same line) later in
> this year and so thanks for everyone's tips, unfortunately I didn't
> have any say in our family's computer setup until the early 90's when
> I went to high school. Therefore I wish I could chuckle about the days
> of reading a document as it downloads but the slowest modem (and my
> first) was 2400 baud, which is not quite the same!
>
> I do have a couple questions though mainly for my //c
>
> why cant I set baud rate from basic? I have read darn near a couple
> dozen citations on how to do it, but MY //c wont have anything to do
> with it, even with what I would consider every reasonable variation of
> spaces, colons and string phrases mixed and unmixed with integers
> (even in no dos, plain basic rom)
>
> does a rom 255 //c support hardware handshaking? I have seen no, yes
> but backwards, and putty wont have anything to do with communications
> unless xon and xoff is turned on.
>
> Thanks Again

Also, forgot to mention that if you work with anything above 9600 baud
(especially 115.2k baud) you must do your work in assembler for
transferring data.  What you can do is write a small routine that
sends a READY message to the PC and then (as a replacement for INPUT)
reads data to a known spot in memory.  Once that is done, send an
acknowledgement message back to the PC, RTS so that you can process
the data afterwards.  At 115k baud you only have 50-ish CPU cycles per
byte so you only really have time to read a byte and then store it
somewhere.  There are a couple of extra cycles to do a few things in
between, but each opcode takes 3-5 cycles (sometimes more) so you're
limited to simple schemes like packbits compression for example.
Likewise, it's overall faster to convert the video to apple format on
the PC side and transfer as raw data directly into the hires memory
than it is to transfer as an intermediate format and have the apple
interpret it and plot individual pixels.

Another optimization you could make though is to only send the
differences per frame and reduce drawing time between frames when
there are little or no changes.

Just throwing some fun ideas out there you can experiment with.  I had
a blast working on this stuff as it finally gave me a chance to learn
about compression/decompression of streaming data, how CRC is really
useful in catching corrupted data.

-B