[cc65] Extended memory

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-20 17:30:05


On Wed, Nov 20, 2002 at 07:41:40AM -0800, David Holz wrote:
> I don't see where double-direction comes into play (pointer to a pointer).
> The window pointer is in the same location in zp.  When I said "move the
> window", I mean the pointer points to a different page.

This is in fact "double indirection", since the application will use a pointer
(the address) to the zero page location, which is itself a pointer.

> Since you're
> talking about having 1 window per application, make it have a fixed location
> in zp that the compiler knows about, instead of a normal pointer variable.

I don't think it's a good idea to special case these things. First, this would
need special code in the compiler. Second, on some platforms there are not
many free zero page locations left. Third, if I allow one library allocating
space in the zero page, I will have to allow it also for other libraries.

> As far as I can see, it will work with everything.  If you remember back to
> the DOS days, this type of API is very similar to EMS (bank in memory).  If
> you have to copy data around anyway, like with the REU or SCPU, then a XMS
> type of API (copy data between external & main RAM) would be faster, but
> you'd lose all the speed of banking on systems that support it (GeoRAM,
> linear access, and the cache idea).

If there is just one window, and the driver returns the pointer to this
window, memory extensions like GEO RAM don't need copying.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2002-11-20 17:30:13 CET