Post Reply 
09-01-2019, 05:42 AM (This post was last modified: 09-01-2019 07:26 AM by Ángel Martin.)
Post: #68
Great insights indeed, thanks for sharing them.

(09-01-2019 02:41 AM)hth Wrote:  This might sound a bit alarming, but so far it has not posed any problems due to the way modules are written (similar to in the old days) and bank switching all address pages on the Clonix has not been a source of problems, as no low pages are bank switched (apart from IR printer and 41CX ROMs, but that works as they are handled outside Clonix).

In fact just the opposite: sometimes I've taken advantage of such arrangements, using calls to a second-bank in the paired page from the second-bank in the original one. Unorthodox yes,, but No risk no fun, uh? ;-)

(09-01-2019 02:41 AM)hth Wrote:  At least Clonix will have a problem if we ever start to bank switch page 4 and make it some library or system extension page. This will require some reprogramming of its firmware. It may also cause some issues with MLDL2000 and NEWT, but I have not investigated that. But there is no problem at the moment.

This is good to know, a Bank-switched Page-4 is still a possibility to achieve compatibility with the current implementations. It is available on the latest batch of CL's.

(09-01-2019 02:41 AM)hth Wrote:  It can also be worth looking at that 1LG9 only checks the ENROMx instruction if executed from within the chip. I think the other mentioned memories do the same. Old MLDLs however, read instructions on the bus and can react to the WROM (write to ROM) coming from other devices, i.e. a Zenrom. This way a Zenrom (or other module with write-to-ROM functions) can work together with a RAM only box. This can be studied in the original MLDL design in that old PPC journal. For a memory chip, it is probably a lot easier to just decode the instruction fetched internally rather than implement logics for reading instructions that appear on the bus (as on the MLDL).

You can always force the switching by calling to the ENROMx in that page from a different one. The final RTN will ensure a return to the original caller, which effectively "drives" all the BS from a common point. I used this in CPYBNK the Copy Bank function, and more extensively in the Auto-Complete XEQ+ to access sub-functions in *any* page from the same central place. This requires all the ENROM/RTN's pairs to be placed in the same addresses - as they always are by convention from 0xpFC3 to 0xpFCA

(09-01-2019 02:41 AM)hth Wrote:  
(08-24-2019 08:31 PM)Monte Dalrymple Wrote:  The IR printer also uses the special Peripheral instructions, which are also NOPs as far as the CPU is concerned. This operation is also well understood as far as the CPU is concerned, but I have never been able to find any documentation on how the IR module interprets them. I started looking at the code some time ago, but there are at least a dozen different "instructions" used and it's probably going to be impossible to figure out what they do from just looking at the code.

I think the best way forward here would be to try and track down some engineer that worked on the code or the IR module hardware. Peter Platzer had in his possession an MLDL that seemed to have been used for developing the firmware for that IR module. If he has some records where he got it, it might be possible to trace it backwards? Otherwise there may be people that are known to have worked on it or close to it at the time?

In my experience all the new memories switch "on the fly" with no need for any "warm-up" instruction. It is in the return to bank-1 where there are sometimes complications, and the implementations differ. The safest way is to always return by code, although the PWOFF opcode can be used as a safe to ensure the same.

Find all posts by this user
Quote this message in a reply
Post Reply 

Messages In This Thread
RE: (SOLVED) 41CL - DOUBLE HEPAX ACCESS and MMU CONFIG - Ángel Martin - 09-01-2019 05:42 AM

User(s) browsing this thread: 1 Guest(s)