Re: [cc65] OT: Where to get some help?

On Sun, Apr 25, 2010 at 2:30 AM, Ullrich von Bassewitz <uz@musoftware.de>wrote:

>
> On Fri, Apr 23, 2010 at 07:40:52PM -0500, Payton Byrd wrote:
> > Approach 1: Copy the entire screen to another page in memory and move the
> > start memory for the current screen to the copy, then draw the menu.
>  When
> > I'm done with the menu, set the screen pointer back to the original
> screen
> > and keep going.  What concerns me is the amount of time it would take to
> > copy the screen using C, so I'm thinking this might be a job for some
> inline
> > assembler, unless there's already a function out there to do this.
>
> memcpy is a standard C function.
>

I'm really leaning toward this method after some research and soul-searching
today.  For 80-column mode the VDC actually has a block-copy command in
hardware that will allow me to duplicate the contents of video memory with a
single assembler command.  For the 40-column screen I believe memcpy will do
the trick for me.


>
> > Approach 2: Copy the contents of the screen where the menu is to be
> > displayed into an array where the size of the array is height * width,
> then
> > write the contents of the array back to the screen one line at a time.  I
> > see two problems with this approach: first, the array might get quite big
> > and I don't know the maximum size of an array in CC65; second, how do I
> > obtain the contents of the screen?
>
> It is usuallay a memory area at a fixed address.
>
> > Should I use the screen codes from
> > memory and write the screen codes back to memory?  If I'm going to be
> > writing screens directly to memory then what's the point of using CONIO?
>
> These are problems no one can solve for you. It depends on the type and
> requirements of your application. There are cases where it does make sense
> to
> work around conio and others where this is not true.
>

I think by doing the screen duplication I'll be able to preserve CONIO for
my screen drawing.  I like CONIO for writing the screen since it keeps me
from having to deal with the messiness of two display systems 90% of the
time.


>
> > Approach 3: Simply invalidate the screen and force a full refresh.  This
> may
> > be the simplest, but it could be expensive as the screen may be very
> > complex.  Plus, if there's some text that was generated organically and
> > can't be repeated then such text would be lost.  I'm not fond of this
> > approach, but if all else fails....
>
> This is often the most memory saving solution.
>

And hopefully I'll be able to avoid it. :)


>
> > Maybe I'm going about this all wrong!  Does anyone know of a publicly
> > available windowing library for text mode on CBM machines?  A port of
> curses
> > for CC65 would rule the world, if there's enough resources on our
> machines
> > to handle such a library.
>
> There are a two window libraries I do currently remember: Fields by Joseph
> Rose and simplemenu by Magervalp. The first one is available from the
> contrib
> directory, the second one was available from paradroid.net, but the link
> on
> the page doesn't work, so you may have to contact Magervalp directly.
>
>
I looked at Fields after I got your email and he stopped at exactly the same
spot I'm at now as there's no code to preserve the screen underneath the
dialogs and menus.  I think I'm heading in the right direction now, but I'm
just getting bogged down in my lack of experience with both the C libraries
and assembler as it doesn't appear that there's a good way to avoid using
assembler when dealing with the VDC.


> Regards
>
>
>        Uz
>
>
Thanks for your time and patience!

-- 
Payton Byrd
<http://www.paytonbyrd.com>
<http://it.toolbox.com/blogs/paytonbyrd>

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.