HP-41 Memory & Interfacing
#1

I had previously posted that message on late April, anyhow it was the last in the thread, and probably remains unseen (or -simply- no-one was willing to answer...:-(

Ok, just kidding...

<<Hi everybody,

It seems that the customized EPROM modules issue still have a lot of interest in this forum (easy to understand when looking at e-Bay prices :-)...

Let me see if I've understood the previous message...

- Are there EPROM chips (those UV erasable) that fit into a standar HP-41 module case??

- If the answer is YES, are there any clue about which modules could carry this (almost magic) chip?

- AFAIK, ROM modules are 10bit/word and RAM modules are 8bit/word... Anyhow, some modules share machine-code and user code programs in the same device, Does someone knows how they overcome the word lenght difference?

- Is it possible to place a small Lithium battery inside a, said, Quad-Ram module to turn it into a pseudo ROM?

... Well, I'm abusing I know, but those questions have been prowling into my head for long, since I'm a "harware guy" (those with the soldering iron and tweezers), sometimes messing my brain up, and you seem to be the only good answers source.

Thanks in advance and best whishes from the Canary Islands.

P.S. Please forgive my grammar "crimes".>>

Some MLDL related threads have born since I wrote this, and superb Meindert's work seems to flood some ligth inside my smoogy neurons, anyhow the question of the 10bit/word EPROM chips and M-code/U-code sharing remains somewhat obscure.

#2

ZEPROM modules are special EPROM modules, designed from Zengrange. This company also created the well known ZENROM, an advanced HP41 plug in module for synthetic and mcode programming.

First ZEPROMs used for military artillery applications, called GUNZEN or MONZEN and for military airoplane navigation. Later some more preacefully applications exist like surviving and custom made modules.

The internal size of an ZEPROM is 16KByte, furthermore a bank switching mode would be possible.

ZEPROM modules are powerfully plug in modules for HP41. Burning mcode or user code software is possible - also existing rom-image files.

Please contact me for more details or for burning support.

Best wishes - Christoph Klug

#3

U-code is stored in 56-bit registers (most internal CPU registers are 56 bits as are X, Y, Z, T, flags, etc). This is valid for all user memory and extended memory. This matches with the HP41 external interface, which uses a 56-bit cycle. This adds up to 7 bytes. An extra byte might have made a lot more sense, but I have no idea why this choice was made. User code instructions are 8 bits or multiples.

M-code is totally different. These are instructions that are executed by the CPU, and these just happen to be 10 bits long. The memory space of this is 64k of these 10-bit words. The only possibility to have user code in M-code space is to have it put in ROM (and indeed waste 2 bits). The translation is not very complicated and there are some M-code tools to do just that and put your user code in a ROM module. Again, I do not know why 10 bits was chosen.

M-code can never be run out of User space. A (quad) memory module is in User Space and will not work for M-code, battery or not. I have put small capacitors in extended function/memory modules to be able to swap programs with other users (gives you several minutes of storage), but only for user code and data, much like magnetic cards.

In MLDL or EPROM boxes the 10 bits need to be implemented. As typical available devices are 8 bits wide a trick is used with one EPROM containing the lower 8 bits (L8) and another one the upper two (U2). The U2 bits are packed with 4 of them in one byte. This requires some demultiplexing in an MLDL.

I have no idea how this is done in the ZEPROM, but I assume is is similar. In my MLDL the U2 bits are in the same chip, multiplexed in the same way but at a different location, requiring only one IC instead of two. The logic is more complicated, requiring two access cycles instead of only one.

Note that my MLDL will not fit in a module housing. The CPLD is a 144-pin SMD device, and that alone is too large to fit inside a module housing. Current goal is to put it in a card-reader housing. The only option to put it in a module is possibly chip-scale packaging (mini BGA) and limited functionality but this is not in my planning. If there are many interested I might investigate. I someone else is interested to do this, I will gladly offer my knowledge.

Hope this helps a bit

Meindert

#4

Hmm, not totally accurate, but anyhow...

User memory is a device in the HP-41. You access it with something similar to I/O instructions, and get 56 bit data.

Modules are always 10 bit wide, and are accessed in the normal addressable range of the CPU. This also applies to user code in modules. User code just have the high two bits always zero, and the low eight are as usual. The HP-41 can tell if it's user code, and calls the interpreter in that case to execute the code from normal memory.

The nitty gritty details have gone out of my mind, but I think it's documented in the ZENROM manual, which I have at home. I'll look it up, and write it here tonight.

So there really is only one kind of modules. 10-bit wide ROM. It can hold both user code and machine code.

#5

That's quite clearer now... Let me make a try to see how far have I got to understand:

HP-41 M-code is always 10 bit, and placed in a separated area. It's also the code that *really* controls the 41.

The 41, when instructed by this M-code, looks for U-code 8 bits *instructions* in the other area (somewhat I/O accessible, according to Johnny's comment, and retrieved in register -56bits- sized blocks) to interpret them accordingly (i.e. produce the M-code sequence needed to perform the specific task, -say SQRT for example-) and then go back for the next U-code and so on.

Do not hesitate to correct me if some of the above is mistaken ;-)

Regarding EPROM's chips I'm willing to get a Zenrom but prices are high above my budget (anyhow I didn't know they were made of EPROM's and had supposed they were mask ROM's)
Thanks for the info Christoph. Are any source of those chips -or related info- left nowadays?

I don't really want to stole your time for the much awaited (yes, me too) MLDL proyect, Meindert, but would like to ask you something regarding the Flash EEPROM area:
Is that inside the microcontroller or is it the addressable memory that microcontroller is able to handle with external memory devices?

Again thanks you all, and friendly greetings from the Canaries.

Diego.

#6

Diego,

Just to answer your question: I am not using a microcontroller, but a CPLD, which is a device with loads of configurable logic and flip-flops, a total of 256 macrocells in the device that I selected. For details check out www.xilinx.com and find the information for the XCR3256XL, this is the selected device of the XPLA3 family. The memory (flash and sram) are external devices controlled by the CPLD.

To confuse things, the CPLD is based on flash technology and can be reprogrammed for enhancements or bug fixes with a special programming cable (although the cable is not that special).

The rest of your observations are correct.

Meindert

#7

No no.

User code in a module is stored the same way as machine code.

User *memory* is accessed with I/O instructions.

A module can hold either 10-bit wide memory, accessible by the CPU, or 56-bit wide memory, accessible with I/O instructions. Consider all RAM memory as a device. There is no RAM in the normal memory area. In fact, the HP-41 CPU don't have a write instruction, only a read instruction.

When you look in CAT 2, you can see both user code and machine code functions. User code functions have a label starting with the superscript T. If such a function is called, the HP-41 will instead read the 10-bit memory words, and interpret them with the normal interpreter. When executing code from ROM, a system flag is set, to tell that the user PC is pointing into ROM, and not user memory.

User memory modules don't exist in the normal address space of the HP-41. They are just I/O devices. That's why you can combine them with ROM modules in the same slot.
User memory modules are the normal MEM and 4xMEM for the 41C, as well as the X-MEM modules. The X-FUNC is the only module I'm aware of that have both a ROM and User memory.

So, if you create a ROM, with 10-bit memory, you can place either machine code or user code in that memory. Really easy actually.

:-)

#8

Oh. I just realized, in a way you got it right.

The way you describe it is how normal programs you write yourself is stored and executed.

User code in a module is the special case, in that the user code is stored in the 10-bit wide words of the ROM module in that case.

#9

Glad to know I'm getting the rigth picture... little by little.

Regarding the EEPROM's in the MLDL, (and linking to the previous thread -count 7 downwards-), it will also be possible to burn a 2764, 128, 256... with the L8 (2732) U2 (2716) -old fashion MLDL EPROM's- merged to fit the new MLDL2000 addressing specs, for testing purposes... well, just a thought.

Enjoy your 41's!!

Diego.

#10

My final MLDL2000 will only support the built-in devices: FLASH and SRAM in TSOP package. These will be soldered, and no further sockets are provided. The FLASH is in-circuit reprogrammable. Note that EEPROM is a different technology than Flash Eprom. In a previous response I mistakenly mentioned that the CPLD device is Flash based, but it is actually EEPROM based

For prototyping I am currently using the 'old' type EPROMS, but that is not planned as a 'product'.

BTW, The pictures and working VHDL code of the prototype are now available at www.kuipers.to/hp41. One of the pictures has a close-up of the CPLD.

Meindert

#11

Told you nothing was in here!

#12

That's OK, I had seen the pictures with the EPROM's in your site, and that made me think of the burner story.

The Flash solution is, obviously, more apropriate for such a new design.

CU.

Diego.

#13

There was another module with ROM and User Memory. Almost all of the Extended Functions Module functions were provide for in the HEPAX Module to manage input/output of HEPAX Memory. The RAM is volatile -- if you remove the module from the HP-41 the RAM contents are lost. However Master Clear does not clear HEPAX Memory.

The HEPAX (HEwlett-PAckard 41 eXpansion) Module by VM Electronics ApS, Denmark, came in four versions:

HEPAX - ROM with 8K RAM

ADVANCED HEPAX - ROM with 16K RAM

HEPAX Memory Module - 8K RAM Only

HEPAX Double Memory Module - 16K RAM Only

From the owners manual ...

"The term HEPAX memory is used to describe the up to 31408 words of expanded memory that may be added to the HP-41 system by using HEPAX modules.

"The basic unit of HEPAX memory is a word .Of the 8192 words in the Standard HEPAX and HEPAX Memory modules, 340 words are used internally by the HP-41 itself and the HEPAX file system - leaving 7852 words available to the User. The Advanced HEPAX and HEPAX Double Memory modules contain twice as much memory.



Possibly Related Threads…
Thread Author Replies Views Last Post
  HP-41(CL): The easiest way to transfer FOCAL programs from a Linux PC to the HP-41 Geir Isene 13 5,555 12-05-2013, 02:40 AM
Last Post: Hans Brueggemann
  30b/34s interfacing? ross sponholtz 5 1,987 06-26-2013, 01:41 AM
Last Post: Walter B
  41 User Memory vs System Memory Gerry Schultz 6 2,376 07-01-2012, 12:02 AM
Last Post: Monte Dalrymple
  HP-41 Memory chips info (for those HW guys out there :-) Diego Diaz 3 1,578 03-24-2012, 08:06 PM
Last Post: Diego Diaz
  HP-41 strange Memory Module found. Diego Diaz 0 767 08-20-2011, 10:18 AM
Last Post: Diego Diaz
  HP 41 key assignment file and x memory Geoff Quickfall 13 2,889 08-15-2011, 01:00 PM
Last Post: M. Joury
  Op-Amp Gain and Offset Design for the HP-67 Stefan Vorkoetter 6 2,097 12-05-2008, 10:57 AM
Last Post: Tom Mathes
  ARRGGG HP 41 double x memory experts, help Geoff Quickfall 2 1,243 04-05-2008, 02:05 PM
Last Post: Geoff Quickfall
  AMP Rom for 71b PeterP 5 1,885 12-06-2007, 02:20 PM
Last Post: PeterP
  HP-35s I/O and Memory Gerry Schultz 20 4,291 07-19-2007, 09:02 PM
Last Post: karl Schneider

Forum Jump: