From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-20 02:13:29
Hello Ullrich, Tuesday, November 19, 2002, 2:39:46 PM, you wrote: UvB> Hi! UvB> On Tue, Nov 19, 2002 at 02:46:12AM +0100, groepaz wrote: >> one point that made me headaches kinda was, what if you have more than >> one memory expansion? .. ie in a c64, there could be a >> REU,RAMLINK,SCPU etc... UvB> It is not a problem to load and handle more than one such module. There is UvB> some overhead, because the data concerning this module has to be stored into UvB> dynamically allocated memory instead of using global data, so access is UvB> slower. The question is, if it is really worth the trouble to handle more than UvB> one memory extension at a time, since usually each of them has a whole lot UvB> more memory than the C64, so just using the SCPU RAM or the REU RAM should be UvB> enough for any program. well i agree that having support for easy exclusive usage for a bunch of those modules is much more important than suport for using multiple of these modules at once... i was just always wondering if such a memory manager could be implemented in a halfway efficient way at all, even more i was wondering how some kind of swap-memory could work on a barebones c64 system (wouldnt necessarily require more than one physical memory extension, or support for it, though). however, for a start a decent interface that takes ONE of cartridge/reu/superam/whatever into account (and maybe leaves room to later add some kind of swap memory?!) is probably the way to anyway... once you are writing an application that could use the even more memory from a second memory expansion, you could still knock up an additional layer that loads one ore more of those modules and deals with them. -- Best regards, groepaz mailto:groepaz_at_gmx.net ---------------------------------------------------------------------- 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 02:13:43 CET