From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-11-13 15:11:17
On Wed, Nov 13, 2002 at 02:26:58PM +0100, MagerValp wrote:
> Check out the preliminary source at
>
> http://www.cling.gu.se/~cl3polof/supercpu.c
>
> and let me know if you have any suggestions.
Good idea! Here are my suggestions: Having functions to detect and configure a
SuperCPU is great. However, the functions that access the SuperRAM would be
better integrated into a more general concept that allows to access
additional, non linear memory (like REUs, a GEOS RAM extension, banked RAM or
any other method). This would not be limited to the C64, since producers of
other machines have more or less used the same methods to increase the
available memory.
A possible solution could be similar to the graphics API: Have loadable
modules that implement a common interface. Loading one such module would make
one type of additional memory available. Maybe we can discuss a possible C
interface which is flexible enough to cover all memory extensions in use on
the different machines.
Please see also http://www.cc65.org/#PatchPolicy
> Also, CMD's docs are
> slightly buggy, so if someone here knows how the config registers
> actually work, please let me know if i did anything wrong.
I don't know about the config registers, but this code
switch ((unsigned char *)0xd0b0 & $c0) {
^^^^
does not seem to work for me. Maybe it's some secret optimization:-)
> PS: it seems like the cc65 runtime could benefit greatly from some of
> the 65816's capabilities (while still in 6502 emulation mode).
> Where would be the right place to add an 65816 target? Apart from
> adding the necessary code to runtime/*.s of course.
The 65816 would be more a sub-target than a standalone target. Unfortunately,
there is currently no concept for something like a sub-target. Support for the
65SC02 is done by .ifdef'ing the assembler code, so for 65SC02 support in the
runtime library, it has to be translated with the --cpu 65c02 option.
Another "problem" is, that the 65816 is many times faster than the 6502, even
when not in emulation mode. So most speed problems just vanish without any
further need to ressort to real 816 code. While this is not a real problem (so
I've put it in quotes), it makes developing real 816 code unnecessary in many
situations. This is similar to the MS-DOS world, where the 80286 machines were
used as fast 8086 and nothing more.
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-13 15:11:27 CET