Problem with BankSwitching on V41 R9E

[Ángel Martin]

I guess nobody else has noticed it but I've seen a change in behavior on V41 R9E related to bank-switching.

It appears that the fail-safe return to bank-1 upon light sleep has been disabled. Yes I understand this is like the "real" machine works (so not strictly a problem on V41), but it really was a godsend to have it implemented all along previous revisions (we're talking about decades now ;-), so I'd like to request a reinstatement of that fail-safe feature if at all possible.

Looking forward to Christoph's comments here...

Cheers,
ÁM

[rprosperi]

Just curious... What's the advantage of that behavior?

[Christoph Giesselink]

(03-18-2021 03:25 PM)Ángel Martin Wrote:  I guess nobody else has noticed it but I've seen a change in behavior on V41 R9E related to bank-switching.

It appears that the fail-safe return to bank-1 upon light sleep has been disabled. Yes I understand this is like the "real" machine works (so not strictly a problem on V41), but it really was a godsend to have it implemented all along previous revisions (we're talking about decades now ;-), so I'd like to request a reinstatement of that fail-safe feature if at all possible.

Looking forward to Christoph's comments here...

Cheers,
ÁM

V41 R9E among other changes newly supports the W&W RAMBOX (with updated .MOD files, read section RAMBOX in Help.txt file please), so the bank switching unit has been expanded to the 64K W&W RAMBOX II bank switching scheme.

Therefore the bankswiching fallback to page 1 executing the POWOFF opcode changed. To prevent a bank switching of the RAMBOX module, only the HEPAX module pages are set to page 1 at the POWOFF opcode (this was marked in the source code as bugfix for the HEPAX module). So the "fail-safe return" to bank 1 for other modules is not implemented in R9E.

But it's only a minor change to restore the old behavior "fail-safe return" to bank 1 for all modules with the exception for the RAMBOX module in R9F. R9F with an XLarge background image will be published very soon. So the "fail-safe return" fix is a so called "last minute" change.

BTW, it's not decades, but <one decade> <ENTER> <some month> <+> ;-)

--------------------------------------
RELEASE 8C (5/27/2010)
--------------------------------------
- Fixed a problem with POWOFF reseting banks - caused problems with HEPAX

[Ángel Martin]

(03-22-2021 05:23 PM)Christoph Giesselink Wrote:  But it's only a minor change to restore the old behavior "fail-safe return" to bank 1 for all modules with the exception for the RAMBOX module in R9F. R9F with an XLarge background image will be published very soon. So the "fail-safe return" fix is a so called "last minute" change.

Yes please, that will ensure a smooth behavior across all other modules for cases when the return to bank-1 was not explicitly coded (I know, not a good practice but hey...)

BTW there is another case similar to the RAMBOX that perhaps should also be on the same "exclusion" list: the ZEPROMS do allow running of user code (FOCAL) in secondary banks. I think this is the same condition on PWOFF but you will know better. However it's perhaps not possible to tell the presence of ZEPROMS (how are they different on V41 from "regular" QRAM?

Best,
ÁM

[Christoph Giesselink]

(03-23-2021 08:42 AM)Ángel Martin Wrote:  BTW there is another case similar to the RAMBOX that perhaps should also be on the same "exclusion" list: the ZEPROMS do allow running of user code (FOCAL) in secondary banks. I think this is the same condition on PWOFF but you will know better. However it's perhaps not possible to tell the presence of ZEPROMS (how are they different on V41 from "regular" QRAM?

Best,
ÁM

There's no chance to detect ZEPROMS because there's no hardware code for a ZEPROM.

The QRAM for the RAMBOX is integrated inside the RAMBOX MOD files which have the hardware identifier HARDWARE_WWRAMBOX.

Same with the HEPAX module. The combination of ROM and 8K QRAM is also classified with the hardware identifier HARDWARE_HEPAX, also the optional HEPAX memory modules Hep-mem.mod and Hep-2mem.mod. Of course there's no special need for bank switch of the HEPAX RAM, because HEPAX RAM using only one bank per page.

The QRAM memory modules for MLDL Ram4k.mod, Ram8k.mod, Ram16k.mod and Ram32k.mod have no hardware identifier and are always located in bank 1. HEPROOM of the HEPAX module also find this QRAM memory.

[Ángel Martin]

Makes sense, never mind the ZEPROM question.
Thanks for changing back the default B1-return to what is was before (except the Rambox).

[MeindertKuipers]

Interesting thread. I have checked the behavior of MLDL2000, and it will reset to Bank #1 on whenever the PWO line goes low, and this is also in light-sleep mode. There is no way to distinguish between various RAM types. Maybe try ZEPROM in the MLDL2000, did anyone ever try this?

[Ángel Martin]

(03-24-2021 08:07 AM)MeindertKuipers Wrote:  Interesting thread. I have checked the behavior of MLDL2000, and it will reset to Bank #1 on whenever the PWO line goes low, and this is also in light-sleep mode. There is no way to distinguish between various RAM types. Maybe try ZEPROM in the MLDL2000, did anyone ever try this?

Yes I tried it - using my modules on the ML2K is totally compatible, so it works just grand.

The ZEPROMS are just eproms, so the code in them is the same as in any other H/W platform. Simulating their BS behavior is therefore not possible unless there's a dedicated switch or option that tells the host (ML2k, V41, CL, Clonix) that the "standard" fail-safe should not be applied.

To my knowledge they are the only hardware capable of running User Code in auxiliary banks; in fact they provide a nice set of Mcode functions to make that possible/

[MeindertKuipers]

(03-24-2021 02:24 PM)Ángel Martin Wrote:  

(03-24-2021 08:07 AM)MeindertKuipers Wrote:  Interesting thread. I have checked the behavior of MLDL2000, and it will reset to Bank #1 on whenever the PWO line goes low, and this is also in light-sleep mode. There is no way to distinguish between various RAM types. Maybe try ZEPROM in the MLDL2000, did anyone ever try this?

Yes I tried it - using my modules on the ML2K is totally compatible, so it works just grand.

The ZEPROMS are just eproms, so the code in them is the same as in any other H/W platform. Simulating their BS behavior is therefore not possible unless there's a dedicated switch or option that tells the host (ML2k, V41, CL, Clonix) that the "standard" fail-safe should not be applied.

To my knowledge they are the only hardware capable of running User Code in auxiliary banks; in fact they provide a nice set of Mcode functions to make that possible/

Actually there is a switch to make the BS status persistent in light-sleep mode, this is done by hardware using the jumper on the power PCB. It will keep the CPLD powered in standby, so current consumption is a bit higher. Would be an interesting experiment ...