HP-41CY emulation for NoV-64.



#2

Hi all...

First, beg your pardon because the title is not accurate enough.

There are some differences between both devices which are detailed below. But for many of you who (like me) have never had the opportunity to "play" with the real thing... and hardly will according to its price and rarity. :-(

What CY does and NoV-64 does not:

- Run in turbo mode.

[- Disable the RAM page when a ROM module is plugged on its same address. System modules are allowed of course (PRINTER, IR-PTR, HP-IL, TIMER, EXT-MEM)] This has been solved thanks to the hints by J-F and Winfried. The dowload link is updated.

What a NoV-64 does and CY does not:

- Preserves its OS, no matter how hard the crash, since it's stored in ROM.

- Preserves ist RAM contents without aditional power.

Of course, it handles the well known commands: PG<>, PG01 & PG10; as well as the intitialization/test via [MEMORY LOST ].

In short, this is more a toy than a tool.. but I've found it funny to build and hope you also enjoy playing with it.

The download link is here.

As usual, comments and suggestions are welcome... A copy of the original English manual will be *really* welcome. :-) and... decription of the process to detect which ROM's are plugged in will be enormously welcome!! ;-))

So far I've only got some clues (and could be completely wrong) about how 41CY gets acquainted of the ROM's. Seems like if it intercepts mainframe's "ROMCHECK" process, performing its own... then returning the control to 41 OS. At this point it behaves like a "peripheral" (H'010) and handles a couple of registers and NUT processor flags 10 & 12 (status register)... long way ahead.

Best wishes.

Diego.

Edited: 13 May 2010, 5:30 p.m. after one or more responses were posted


#3

Hola Diego,

I see you're deepening and widening the knowledge on almost everything related to the Coconut world ;)

Well, I'm of course not an expert on the 41CY - don't have one, nor do I think I want it either (I'm saving for my NoVo-64 :), besides, give me a HEPAX anytime...) but - I happen to have an english manual for the RAMBOX - will that help? It does not have any techy stuff, just the basic functioning of the system, but maybe ...

Let me know.

#4

Hi Diego,

I'm not be 100% sure, but I don't think the RAMBox OS does something special about pages already taken by ROM modules. I think the RAMBox just drives the ISA line in a weak way, so an external ROM can overdrive it.

The RAMBox OS uses the special ENROM1/ENROM2/ENROM3 opcodes to manage the page selection PG01, PG10 and PG<>. AFAIK, no other special opcodes and peripheral commands are used. I successfully emulated the RAMBox in Emu41 in this way.

It's great to have a hardware replacement for the RAMBox!

J-F


Edited: 13 May 2010, 12:17 p.m.


#5

Quote:
I'm not be 100% sure, but I don't think the RAMBox OS does something special about pages already taken by ROM modules. I think the RAMBox just drives the ISA line in a weak way, so an external ROM can overdrive it.

I don't know if this is correct, but it ist just the way I did it with the MBK-ProfiSet. There was a resistor in line with the ISA line and a switch (named "Priority Switch") paralell to the resistor. By this way you get a signal which ist weaker or stronger than the signal from the ROM module and you can switch between RAM and module.

The ProfiSET-OS simply reads the last word from each 4K page (the checksum), inverts the bits, writes this value and reads again. If the result changes it is a RAM page, if not it is a ROM page or a ROM page with a weaker RAM behind. It doesn't matter if the checksum is overwritten in RAM as it will not be valid most of the time and it can be calculated new if needed. The check was done with all pages each time the OS tried to access a page. By this way it was possible to give each RAM page a sequential number called "block".

Someone who has got a RAMBox should verify it. Put a ROM module in one port which has also RAM addressed to it and overwrite one word with a mcode WROM (do not use the RAMBox OS for this). After this remove the module and read the word. If it has changed like it was written, the RAMBox uses just the weak ISA signal.


#6

Hi Ángel, J-F, Winfried,

Thanks a lot for your responses, I've gone a SW "variation" (I cannot modify existing NoV-64 HW adding a serial resistor) of the propossed weak-ISA way, and it seems to work... ;-) (please consider this "extremely experimental" if your're about to test).

The new code is here for download. (Updated)

I'm certainly neither a CY expert... nor a fan of it. Fully agree with you about HEPAX, Ángel.

HEPAX puts 16K of "efficiency" into 4K of unused space, while CY "wastes" 8K of its own RAM space (it should more properly be called 56K RAM-Box) to allocate a "duplicated" block of a "memory pull-pusher" overvalued OS. No direct RAM access/editor, no dissasembler... in short, not enough revenue for the money.

However, its ability to put its RAM in the shadow if another module is plugged-in is of my main interest. Thats why I've come to that point in the end, not because a particular interest in the CY itself: I need/want "just" this feature for a future project... and was decided to "stole" it... :-)

Ángel, I've found both, 32K RAM-Box manual, as well as the German manual for the "41CY/64K RAM Box II" in TOS. If you have the English version of the later, I'd certainly appreciate your contribution.

J-F, the "weak ISA" is a feasible method, I find it "extremely" tricky though... Those guys at W&W were very serious and well founded in the 41 OS... However, as I've read not long ago in this very forum: "If you eliminate the impossible, whatever remains must be the truth"... (think I must trim the tip of my ears again).

Nonetheless, tricky use of pure HW interface (ISO level #1) is not uncommon. The "RS-232" PIC programmer is a very good example of it and as stated above, it solved the issue so far.

In the meantime, may some of you offer an (M-code) expert point of view on what CY does when it comes to I/O interrupt (polling point H'8FF8) pure couriousity by my side I must admit.

This is the code:

8FF8 330  GO 8FDE (-1A)
.
.
8FDE 130 LDI
8FDF 010 010
8FE0 270 SEL RAM (DESELECTS RAM 010)
8FE1 3F0 SEL PERF (SELECTS PERIPH 010)
8FE2 046 C=0 S&X
8FE3 3E8 WRIT 15(e) (There must be a REG(15), to be cleared(inside CY?)
8FE4 3F0 SEL PERF (DESELECTS PERIPH 000)
8FE5 270 SEL RAM (SELECTS RAM 000)
8FE6 0CC ?FS 10
8FE7 05B GONC FFF2 (EXITS POLLING THRU 27F3)
8FE8 34C ?FS 12
8FE9 04B GONC FFF2 (EXITS POLLING THRU 27F3)
8FEA 10E A=C (BOTH FLAGS 10 & 12 ARE SET, saves c in a)
8FEB 338 READ 12(}) (There must be a REG(12), to be READ)
8FEC 1BC RCR 11 (Places c[3] at c[6])
8FED 0AE A<>C (SWPAS A AND C)
8FEE 15C R=6 (POINTER = 6)
8FEF 362 ?A#C @R (COMPARES C[6] WITH C[3])
8FF0 017 GOC FFF2 (EXITS POLLING THRU 27F3 IF THEY'RE EQUAL)
8FF1 348 SSF 12 (OR SETS FLAG 12 AND THEN...)
8FF2 3CD GO 27F3 (...EXITS)
8FF3 09E

Best wishes.

Diego.


Edited: 13 May 2010, 8:13 p.m.


#7

Since no one answers I take a confused bite on this...

Peripheral 010 is the halfnut LCD extension peripheral. I have not much information of what it does, and I do not know what WRIT 15 means to it. Then it deselects peripherals and selects low ram.

The flags relelated to RPN program is checked to see if the RPN program pointer is in rom (flag 10), then the private flag (12). If both are set it tests if the RPN program pointer is in the same 4K module as the poll code. If it is, then it sets the private flag, which it already tested that it was set?? Makes not sense to me, I probably misunderstand something.

Quote:

In the meantime, may some of you offer an (M-code) expert point of view on what CY does when it comes to I/O interrupt (polling point H'8FF8) pure couriousity by my side I must admit.

This is the code:

8FF8 330  GO 8FDE (-1A)
.
.
8FDE 130 LDI
8FDF 010 010
8FE0 270 SEL RAM (DESELECTS RAM 010)
8FE1 3F0 SEL PERF (SELECTS PERIPH 010)
8FE2 046 C=0 S&X
8FE3 3E8 WRIT 15(e) (There must be a REG(15), to be cleared(inside CY?)
8FE4 3F0 SEL PERF (DESELECTS PERIPH 000)
8FE5 270 SEL RAM (SELECTS RAM 000)
8FE6 0CC ?FS 10
8FE7 05B GONC FFF2 (EXITS POLLING THRU 27F3)
8FE8 34C ?FS 12
8FE9 04B GONC FFF2 (EXITS POLLING THRU 27F3)
8FEA 10E A=C (BOTH FLAGS 10 & 12 ARE SET, saves c in a)
8FEB 338 READ 12(}) (There must be a REG(12), to be READ)
8FEC 1BC RCR 11 (Places c[3] at c[6])
8FED 0AE A<>C (SWPAS A AND C)
8FEE 15C R=6 (POINTER = 6)
8FEF 362 ?A#C @R (COMPARES C[6] WITH C[3])
8FF0 017 GOC FFF2 (EXITS POLLING THRU 27F3 IF THEY'RE EQUAL)
8FF1 348 SSF 12 (OR SETS FLAG 12 AND THEN...)
8FF2 3CD GO 27F3 (...EXITS)
8FF3 09E

Best wishes.

Diego.




#8

Hi Håkan,

And thanks for taking the "chalenge"... Same conclusion than mine then: I found not much sense on this either.

But you've pointed out one thing that I didn't know: "Peripheral 010 is the Halfnut LCD extension".

BTW, are there listings of "Peripheral addresses" and "Peripheral Interrupt flags"?

Seems that they're the most poorly documented and "obscure" aspects of the 41 system.

Best wishes.

Diego.


#9

"WRIT 15(e)" is the disassembler's (vain) attempt to decode the display writing instruction "SLSABC" - as per Ken Emery's book, see pages 109 and following.

In case it helps - probably not.

Cheers,
Ángel


#10

Hi Ángel,

Thanks for the tip, I've re-read "M-Code for Beginners", however, I think that the SLSABC... (and the rest of WRIT's and READ's for the display) are referred to the "standard display" peripheral H'0FD.

Peripheral H'010 (sort of halfnut extended display functions), acording to Emery's (p.116), allows six (WRIT's/READ's) instructions, two of'em for the contrast adjustment, the only mention to any of the remaining four is just for "WRIT (e)"

Quote:

"... will crash the display, simultaneously lighting all the segments... The only way to recover from this particular crash is to remove the batteries..."

Still can't understand the basics of M-code... but this routine really sounds strange to my ears... regardles the "language"... ;-)

Cheers.

Diego.

#11

I have looked into this a bit. I have checked the HEPAX code for changing the contrast of the display, and indeed it used peripheral 010 (works only for the halfnut display), see below (HEPAX bank 3):

            A105 043 054 052  .FNAME      "CTRAST"                   ; 043 054 052 041 053 0D4  
CTRAST A106 130 002 LDI 002
A108 106 A=C S&X
A109 0F8 READ ( 3)X
A10A 306 ?A<C S&X
A10B 033 JNC +06 LB_A111 A111
LB_A10C A10C 3B5 08C 3B7 GOSUB LB_AFB7 AFB7 ; ?NC XQ 23ED, address in 4th Quad
A10F 02D 028 ?NC XQ 0A0B
LB_A111 A111 10E A=C ALL
A112 3B5 08C 397 GOSUB LB_AF97 AF97 ; ?NC XQ 23ED, address in 4th Quad
A115 33C RCR 1
A116 2E6 ?C#0 S&X
A117 3AF JC -0B LB_A10C A10C
A118 130 010 LDI 010
A11A 270 RAMSLCT
A11B 3F0 PRPHSLCT
A11C 2FC RCR 13
A11D 168 WRIT ( 5)M
A11E 3B5 08C 3B7 GOSUB LB_AFB7 AFB7 ; ?NC XQ 23ED, address in 4th Quad


The I/O service routine is supposedly called when the HP41 enters standby mode, so it may be part of a key-entry routine.
The READ 12 is a eal read from status register b, and it tests for the nybble of the RPN PC indicating the position within a register, when in ROM it is the current ROM number. What I find a bit strange is that the routine tries to do something when a private RPN program executes from this ROM, but the RAMBOX ROM has no user code programs in its catalog.

My biggest question is now whan the instruction to the NUT special display does here ....

Meindert

#12

WRIT 15 writes to the control nibble of the internal timer in the halfnut display chip.

Except for the Hepax contrast function, I didn't know any ROM using this peripheral code 10! I was unable to find any use of this select code 10 in the CX ROM, not even in the CX service ROM (I set a breakpoint in Emu41 on read/write when SEL PERF = 10, and got nothing).

The registers related to the halfnut display PERIPH 10 are described in the CHHU V2N4 issue (July 85) p.10.

J-F


#13

Hi all,

And thanks again for your time. To keep on feeding my curiousity I'll go for the CHHU issue.

However, the point here is that I was wrong when assuming that the "I/O interrupt" call in RAMBOX 64 was related to the fact that 41CY's can sense physical modules... Which saved me a lot of time diving in the wrong direction.

Thanks a lot for that... :-))

Best wishes.

Diego.

#14

I am not aware of any complete in-depth compilation of all peripheral addresses and flag use. They are not too hard to find by looking at listings and fragments of information you can find in various places.

For the timer and HP-IL there are in depth documentation available. I have an old article about the card reader, but nothing that I can recall about the Wand and virtually nothing about the 010 halfnut lcd. The situation gets a little bit worse when it comes to how devices implement read and write instructions. That is at least the "mainstream" devices. Then there may be some non-HPIL special devices like the CMT multimeter, I do not know anything about these.

Then there are lots of other things to "worry" about, like XROM numbers, buffer numbers, file types (extended memory, mass storage, card reader, wand)...


But overall, we are actually very blessed with the wealth of information available.

#15

I would have expect that to work on earlier HPs, but I'm surprised that it works on the 41.

In all of the HPs, the CPU drives the bus lines (ISA and DATA, or equivalent) low during one of the clock phases, which is called precharge. In most of the HPs, the driver in the ROMs and peripherals can only drive the bus lines high, not low. This is known as an "open source driver". [1]

With that arrangement, if you had a ROM that was trying to output a zero (by doing nothing), and a secondary device with a deliberately weak driver trying to output a one, you would see the one. The ROM would not override the weak driver.

On the other hand, the high-side driver in the ROM is very weak already, so if you didn't want the secondary device driving a weak zero to override the ROM driving a one, the secondary device's low-side driver would have to be *extremely* weak. Probably best to omit it entirely, and have the secondary device use an open source driver also.

While the Nut processor still did bus precharge, based on what you're saying apparently the ROMs, RAMs, and peripheral chips used with it no longer used an open source driver.

Eric

[1] similar to the better known "open drain driver", with "source" referring to the source terminal of a FET, and having nothing to do with "open source software".


#16

Yes, the HP-41 ROMs have open source drivers.

This is the part of the circuit from the ProfiSET for driving the ISA line:

The CD4503 is a (hex) non-inverting 3-STATE buffer with high output current sink and source capability. It has 3-STATE outputs and a disable input.

In line with the output of the 4503 I used a 470 ohm resistor. Between ISA and GND there is a 100k resistor used as pull down inside the connector to the HP-41 port.

With the "Priority-Switch" turned on the signal is stronger than the signal from modules and it is weaker with the switch turned off and the 470 ohm resistor in line with ISA.

This works with ROM modules from HP, but will not work with all third party peripherals.

The MBK EPROM boxes had no switch and always the weak signal on ISA. I used a CD4066 instead of the CD4503. It worked with several hundreds of devices.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP-41 Clonix&NoV's SW Update. (For the non-Primer's guys out there... :-) Diego Diaz 21 755 11-13-2013, 09:00 AM
Last Post: Ángel Martin
  Last HP emulation, 32 & 01 Olivier De Smet 0 146 09-07-2013, 08:27 AM
Last Post: Olivier De Smet
  HP-41CL & NoV(-64): Race condition? Geir Isene 11 575 05-03-2013, 01:59 PM
Last Post: Diego Diaz
  HP 50G emulation for android Olivier De Smet 3 251 04-14-2013, 12:01 PM
Last Post: CompSystems
  Latest Clonix/NoV's SW update. Diego Diaz 5 284 02-15-2013, 12:12 PM
Last Post: Ángel Martin
  [Clonix/NOV] NoV-64 backwards compatibility Doug (NYC) 0 145 01-20-2013, 11:21 AM
Last Post: Doug (NYC)
  NOVRAM 64 / HEPAX bug? M. Joury 2 190 11-03-2012, 02:49 PM
Last Post: M. Joury
  Beta 41CL --> Best CL UTILs to burn in NoVRAM 64? Gene Wright 5 246 07-01-2012, 03:06 PM
Last Post: Matt Kernal
  NoVRAM 64 USB programmer Gene Wright 4 221 06-29-2012, 11:43 AM
Last Post: Diego Diaz.
  New HP71B emulation (go71b) Olivier De Smet 9 417 06-26-2012, 10:25 AM
Last Post: Jerry Raia

Forum Jump: