C51 7.0 supports dual DPTRs, at least in some major library routines. It also supports an extended DPTR. I'd like to be able to do both at once, to do block moves from far xdata to far xdata. It doesn't appear as though the Keil tools support dual far DPTRs, though. You can have two DPTRs, the first of which might be 24 bits wide instead of 16 and the second (if used) always 16. So, if I want a far-to-far memcpy, I'll be writing it myself. Is this conclusion correct?
The device in my case is an ASIC built around the Synopsys DW8051 core. So, we have some freedom to extend the DPTRs however we like. Of course, it makes sense to me to follow the method of some other device to make it easier for tools to support it. Since the DW8051 is already much like the Dallas 320, it makes sense to me to extend the DPTRs as does the 390. That is, a DPX as SFR 0x93 and a DPX1 as SFR 0x95, and use those bits to drive the extended address bus (depending on the current DPTR select bit). I'm a bit leery of telling uVision that I'm using a Dallas 390 instead of the DW8051 as the target, since none of the other 390 extensions would be implemented. Is it sufficient to select "dual data ptrs" and "far memory support" at the same time to generate 390-ish code affecting both DPX registers? Or would the use of the DW8051 target mean dual 16-bit DPTR support (as that's a standard DW8051 option) with single 24-bit DPTR, as customized with XBANKING.A51? I don't see a ROM compiler option in the manuals I have (C51 User Guide 9.2001, PK51 v7.01). There's only one reference to "huge", in the description for the FVAR macro, and "huge" isn't listed as an extended keyword along with "large", "compact,", etc, nor is it one of the memory models. The CLASSES(HDATA()) directive would tell the linker the extended physical range of memory, but I'd still expect to need some sort of code generation option for the compiler and library selection option for the linker. Perhaps the names of the directives have changed in v7.0? The discussion of supporting extending banking with XBANKING.A51 only talks about "an" extended DPTR using a single SFR for extending the (sole) DPTR. To support two 24-bit DPTRs, there'd need to be two EQUs to define, I would think. Also, there would need to be a library with specialized code for the dual 24-bit DPTRs for memcpy() and the like, as there is for dual 16-bit DPTRs. If I went that route, it would indeed seem to me as though I'd wind up with dual DPTRs with the restriction that they could only access the same page, since there'd be only one extension SFR being set by this code instead of two, and (presumably) no code to toggle DPTRs. I agree it'd make more sense and be more useful to have two independent 24-bit DPTRs. I just don't quite see how to get there. The MODDP2 compiler directive gets me dual DPTR support (for 16 bit DPTRs). VARBANKING gets me a single 24-bit DPTR using a register defined by ?C?XPAGE1SFR. There doesn't seem to be a ?C?XPAGE2SFR for me to define so that the compiler can find the second DPTR extension register.
The Dallas 390 Contigious Mode implementation does not use the XBANKING.A51 file. Instead the DPTR's are directly accessed. Please send your serial number to: support.intl@keil.com I will then send you the source code of the related routines.