From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-20 15:55:53
On Wed, Nov 20, 2002 at 06:21:52AM -0800, David Holz wrote:
> gee, that sounds familiar. :)
Yes, I've seen your page, and the fact that you did it this way, increased my
confidence that this is the right approach.
> For expansion memory that is accessed linearly, you just move the window, so
> that's speedy, too. If you need to copy data in & out, you can do that on a
> page-by-page basis, keeping recently used pages cached in main memory (so
> you can point the window to it) if you've got the room.
The problem when moving the window pointer is, that the application cannot
remember it anywhere, so you will have to use double indirection - and cc65 is
not very good when doing this. The code does also get more complex. I would
like to have a very simple approach with a small memory overhead and accept
that the solution is not as fast as it could be. The module loader itself
needs 500-600 bytes (and no, it cannot be loaded as a module:-), add to that
the 256 byte window, the C API wrapper and the actual driver code. It should
be possible to limit the size to less than 1.5K.
So this is what I have currently in mind: The driver just supplies one 256
byte window and returns a pointer to this window to the application. The
application can then map different areas of the extended memory into this
window. I would also impose the restriction that mapped 256 byte pages must
reside on a 256 byte boundary in extended memory. Allowing a 24 bit address
space (16MB), we will get 16 bit page numbers which can be handled effectively
by the compiler.
1. Unexpanded C64
As long as the graphics module is not used, the memory below the kernal
may be used as extended memory. Copying is needed because the memory
cannot be accessed directly.
2. Unexpanded C128
The second memory bank and the memory below the ROM may be used, both
need copying. Copying may be accelerated by mapping the page to the
stack.
3. Unexpanded Plus4
Use memory below the kernal and basic ROMs - see above.
4. CBM-II systems
Use memory from bank 2. Needs copying.
5. GEO-RAM cartridge
The GEO-RAM cartridge maps a 256 byte window into the $D000 range, so
this maps nicely into the software API described above.
6. REU
The REU uses fast DMA transfers (1 cycle per byte). It needs copying, but
because of the REU speed, the solution would still be rather fast.
7. SuperCPU or any other 65816 solution
May use the memory above 64K. Needs copying, but should be ok, since the
CPU is fast and utilize the 65816 block move instruction.
Are there any other known memory expansions out there, that do not map into
this scheme?
If anything else fails, it would even be possible to use disk swapping,
because the 256 byte window maps nicely to the commonly used sector sizes (128
and 256 bytes).
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.
This archive was generated by hypermail 2.1.3 : 2002-11-20 15:56:01 CET