From: MagerValp (MagerValp_at_cling.gu.se)
Date: 2002-11-13 16:15:00
>>>>> "UvB" == Ullrich von Bassewitz <uz_at_musoftware.de> writes:
UvB> Good idea! Here are my suggestions: Having functions to detect
UvB> and configure a SuperCPU is great. However, the functions that
UvB> access the SuperRAM would be better integrated into a more
UvB> general concept that allows to access additional, non linear
UvB> memory (like REUs, a GEOS RAM extension, banked RAM or any other
UvB> method). This would not be limited to the C64, since producers of
UvB> other machines have more or less used the same methods to
UvB> increase the available memory.
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.
UvB> Please see also http://www.cc65.org/#PatchPolicy
, no problem for me.
UvB> I don't know about the config registers, but this code
UvB> switch ((unsigned char *)0xd0b0 & $c0) {
UvB> ^^^^
UvB> does not seem to work for me. Maybe it's some secret optimization:-)
Whoops, typo. Should be 0xd0b9, or possibly 0xd0bc -- the CMD docs say
53433 decimal but d0bc hex...
I'll dig out my SuperCPU setup in a few days and try to straighten it
out.
UvB> The 65816 would be more a sub-target than a standalone target.
UvB> Unfortunately, there is currently no concept for something like a
UvB> sub-target. Support for the 65SC02 is done by .ifdef'ing the
UvB> assembler code, so for 65SC02 support in the runtime library, it
UvB> has to be translated with the --cpu 65c02 option.
Oh, ok, well this is probably what I want, A --cpu 65c816 switch.
UvB> Another "problem" is, that the 65816 is many times faster than
UvB> the 6502, even when not in emulation mode. So most speed problems
UvB> just vanish without any further need to ressort to real 816 code.
UvB> While this is not a real problem (so I've put it in quotes), it
UvB> makes developing real 816 code unnecessary in many situations.
Of course, but sooner or later you'll run into a situation where you
need those last few cycles.
----------------------------------------------------------------------
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 16:15:45 CET