From: David Holz (davidh_at_otterspace.com)
Date: 2002-11-13 20:49:31
From: "MagerValp" <MagerValp_at_cling.gu.se> > Yep, that'd be nice. The idea here is to be low level though. A ram > expansion API could be implemented on top of these functions, and > include a decent way of allocating memory. Here I just opted for a > clean way of changing the start of free ram pointer, and left the > specifics to the user. I'll be using this for a game project, that'll > manage SuperRAM on its own. For some ideas, look at http://www.geocities.com/white-flame/scratch/softmmu.html I wrote this stuff up a long time ago (and really haven't touched it since) to define a memory expansion API for multitasking C= OS's. Its paradigm is compatibile with all memory expansions that I could think of, because it gives you access to 256 bytes at a time, which would be slower than random-length chunk copying under certain situations, but far more accomodating to different types of expansions. For instance, if you have a banked system like GeoRAM, you'd never have to do any copying. It also supports segfaults, which is nice. :) -- White Flame (aka David Holz) http://www.white-flame.com/ (spamblock in effect) ---------------------------------------------------------------------- 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-13 20:49:39 CET