From: groepaz (groepaz_at_gmx.net)
Date: 2002-11-19 02:46:12
Hello Ullrich, UvB> Good idea! Here are my suggestions: Having functions to detect and configure a UvB> SuperCPU is great. However, the functions that access the SuperRAM would be UvB> better integrated into a more general concept that allows to access UvB> additional, non linear memory (like REUs, a GEOS RAM extension, banked RAM or UvB> any other method). This would not be limited to the C64, since producers of UvB> other machines have more or less used the same methods to increase the UvB> available memory. UvB> A possible solution could be similar to the graphics API: Have loadable UvB> modules that implement a common interface. Loading one such module would make UvB> one type of additional memory available. Maybe we can discuss a possible C UvB> interface which is flexible enough to cover all memory extensions in use on UvB> the different machines. i thought about sth like this aswell.... for once i would like the memory of the retroreplay (or action replay for that matter) in my programs.... and i would also be interisted in implementing sth like "swap memory" (i know it'd be dog slow and all but hey... ;=P) once the filesystem works somewhat more stable (ie, it can deal with more than one file so it could actually handle the swapfile ;=)) .... 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... -- 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-19 02:46:18 CET