41CL - Warp Core Conflict with Card Reader?

[twoweims]

I have a 41CL with the latest ROM updates installed.

If I use the Warp Core XEQ+ function without the card reader installed it works normally. XEQ+ followed by [ALPHA] gives me the XEQ$ prompt.

If I plug in the card reader and execute XEQ+ followed by [ALPHA] the Warp Core ROM gets unplugged and the page that it was in gets locked.

Warp Core is not plugged into page E.

Has anyone experienced this?
If someone could try to reproduce this and report back I would appreciate it.

Thanks!

[Monte Dalrymple]

(03-22-2020 03:31 AM)twoweims Wrote:  I have a 41CL with the latest ROM updates installed.

If I use the Warp Core XEQ+ function without the card reader installed it works normally. XEQ+ followed by [ALPHA] gives me the XEQ$ prompt.

If I plug in the card reader and execute XEQ+ followed by [ALPHA] the Warp Core ROM gets unplugged and the page that it was in gets locked.

Warp Core is not plugged into page E.

Has anyone experienced this?
If someone could try to reproduce this and report back I would appreciate it.

Thanks!

What do you have plugged in to each page? I don't have a card reader any more, but there may be clues in your configuration.

[Ángel Martin]

Strange indeed, try plugging the WARP in another page - that will be useful to determine if there could possibly be some bank-switching issues when both the WARP and CRDRDR share the same port.

[twoweims]

My Current Setup:

4: -LIB#4 R50
5: -TIME 3A
6: -PRINTER-
7: -AMC"OS/X
8: -YFNX 4C
9: -PWREXT B3
A: -WARP CORE+
B: -HEPAX'4H
C: NO FAT
D: NO FAT
E: CARD RDR 1E (I leave this empty for the card reader)
F: NO ROM (The same failure occurs with Warp Core Plugged in here)

Everything works great until I plug in the card Reader.

Thanks for taking a look at this.

** Edit to add more information **

I took the CL to MEMORY LOST and started over loading modules from scratch... Same Result.
I replaced the Card reader 1E version with a 1G version and the problem disappears.

[Ángel Martin]

I don't have any Card Reader so can't try on the real CL, but on V41 there seems to work fine using the CRDR_RDR.MOD (which contains the "CRD RDR 1G" ROM)
I'm able to use the XEQ+ with any function, (type "7" at the prompt to get 7CLREG for instance), as well as XEQ$ to spell any function name. I have found no conflicts between WARP and CRDR ROM...

[twoweims]

(03-22-2020 03:52 PM)Ángel Martin Wrote:  I don't have any Card Reader so can't try on the real CL, but on V41 there seems to work fine using the CRDR_RDR.MOD (which contains the "CRD RDR 1G" ROM)
I'm able the XEQ+ any function, (type "7" at the prompt to get 7CLREG for instance), as well as XEQ$ to spell any function name. I have found no conflicts between WARP and CRDR ROM...

Yes. It seems to be a conflict with the 1E Card Reader ROM.
Everything works correctly with the 1G Card Reader plugged in.

[Massimo Gnerucci]

(03-22-2020 03:58 PM)twoweims Wrote:  

(03-22-2020 03:52 PM)Ángel Martin Wrote:  I don't have any Card Reader so can't try on the real CL, but on V41 there seems to work fine using the CRDR_RDR.MOD (which contains the "CRD RDR 1G" ROM)
I'm able the XEQ+ any function, (type "7" at the prompt to get 7CLREG for instance), as well as XEQ$ to spell any function name. I have found no conflicts between WARP and CRDR ROM...

Yes. It seems to be a conflict with the 1E Card Reader ROM.
Everything works correctly with the 1G Card Reader plugged in.

Maybe connected to this bug.

https://www.hpmuseum.org/cgi-sys/cgiwrap...ead=188546
https://www.hpmuseum.org/cgi-sys/cgiwrap...ead=190801

[twoweims]

I am aware of those two issues but this seems different.
Perhaps more bugs lurk beneath the surface of 1E?

I hope someone with a 1E card reader can duplicate this.

[hth]

It seems the same issue to me.

When you are filling in a prompt you are using the key sequence parser. This sets the calculator in state where the return address of the (next) key sequence handler is kept on the stack while the calculator goes to sleep waiting for the next key press.

During the process of going to sleep, the I/O poll vector is still called. At this point the poll routine is more limited (than usual) on how much it can put on stack (making subroutine calls), as the internal stack is only 4 levels deep and it is partly used in this state.

If some real action is needed, maybe a program card was inserted, the poll routine can decide to abort the key sequence parsing, getting all stack levels back (it terminates the function being entered).

The card reader 1E ROM violates this rule and then weird things happen as the calculator is put in a corrupted state.