Ram Slot Soldering

Hi

I want to combine a MATH/STAT and a MACHINE module for the HP-41 in one module shell. Does someone has a diagram which pin has to be combined / crossed?

1 2 3 4 5 6 7 8 9 A B C Pins

o o o o o o o o o o o o Upper module (MACHINE for example)

o o o o o o o o o o o o Lower module (MATH/STAT)

Matthias

Hi, Mathias,If I understand well, you want to do a double rom module for a 41.I think you can have some usefull ints by looking at the article about how to do a double xmemory module in the museum.

Bye, Patrice

I don´t think that this is the same procedure. In case of the double ROM module the calculator only reads from the module. In case of the double XMEM, the claculator writes into the module, so that you have to address the memory. My speculation is, that I can solder the pins strait together (1-1, 2-2, 3-3, ...), cause the calc doen´t matter, from which circuit board the commands come.

Your speculation is good if the modules address does not depend on the port number, otherwise you will have to device something like for the double XMEM, to make the 41 feel like the 2 roms are in different ports and at dif addresses.

Hi,

AFAIK at least the Math/Stat is an 8K module,
so both upper and lower page of the port are used.
Considering this, you can't combine another ROM
with the Math/Stat ROM.

Raymond

Why not? There are also combinations with three modules..

Matthias

Yes,

but AFAIK these combinations consist of one or two memory modules,
and one or two 4K ROMs.The memory modules don't take ROM address space,
so that won't be a problem.
Combining three ROMs into one module would only work if
one of the ROMs is hard-configured, like the TIME module,
so it won't overlap one of the other two ROMs.

Raymond

And what about port replicators? They do not contain electronic. You can also plug in three applications that are plugged into the same port of the calculator

Port replicators are a different thing.
They have one general plug,
but coded (and numbered) slots for modules.
Some replicators also may have switches
to either activate or deactivate a specifiec slot,
or to shift a port assignment.

Maybe there would be a possibility to pack
three ROMs into one module, how would you define
their address assignment?

AFAIK you can designate a ROM to be either on
the lower or upper half of the current port,
or at a fixed address.

I don't know if there's an option to define a ROM
to be addressed at the current upper page + one.

If that would be possible, plugging the ROM pac
into port 4 would invalidate/deactivate a ROM
with a designation like above, or in the worst case,
it would be mapped to address page zero,
which would crash the calc.

So if you have the Math/Stat, I think you can
only add a memory module into the same housing.

However, maybe some other HP-41 specialist
could shed some more light on this topic;-)

Raymond

Hi all,

AFAIK, the wiring scheme is identical to the doubled X-Memory or the old 'dules' (2x82106A), namely B3 line must be connected to GND for one of the modules while kept to V+ for the other.

Indeed, DATA and FI lines don't need to be connected at all, as ROM Pacs don't make any use of'em. Connecting them will increase mechanical strength though.

Obviously the 41 will 'see' both modules as if they were plugged into adjacents ports, so you can only plug a 'System' module in the 'almost freed' port.

Best wishes to everybody :-)

Diego.

Careful, as others already pointed out, there is a difference between ROMs and memory modules, and there are also special ROM modules.

First of all: the lines B3 and B4 are hardwired chip select lines; a module can thus find out in which slot it is located. This is important for the old 41C memory modules, because their slot assignment determines which RAM address range they occupy. The 41C wants to see contiguous memory, so if you have single modules, you have to put them into contiguous port slots (you can't put the first one in port 1 and the second one in port 4 - the latter won't be visible to the CPU. With Quad memories and CVs and CXs, this is nowadays barely known. With X-Memory, the same effect happens: you mustn't put two XMEM modules 'vertically' in the slots, as they only use one of these B3/B4 lines; so then they would be addressed at the same time. If you want to create a double-X-Memory module, you have to wire them in a way as if they were located in the correct slots. You can combine without problems a memory module with an xmemory, a memory module with ANY ROM, and an xmemory module with ANY ROM.

There are two kinds of ROMs, ones which are internally hardwired, and occupy a fixed address range, and those that adapt to the port they are plugged into.Fixed ROMs are for instance: Printer (any kind), HP-IL, Time, Diagnostics, and surprisingly: the card reader (which has a fixed address of 0xe000-0xefff, the low range of port 4).Each port can physically address 8K, but this can be extended by bank switching. So, for example, if you'd like to add a ROM to the card reader case, it would have to be a ROM module that is either fixed, thus out of the way, or would have to be addressed to 0xf000-0xffff. Unfortunately, there are IIRC no natural 4K modules that use a high port range, because HP didn't expect people to assemble multiple 4K ROMs in a single case. This means, you can only combine a fixed module (e.g. Time) in the card reader, or you have to use an artificial ROM, like the NovRAM which you can wire to any address.

The diagnostics ROM is a special case, it is fixed to 0x4000 and will take over control of the whole calculator when plugged in (there is a check in base ROMs whether there is a ROM at 0x4000, and if so it is jumped to).

If you have an 8K (or more, via bank-switching) module: you can combine those only with fixed ROMs, like Time or HP-IL, or with memory/X-memory, because these use different methods of addressing (memory modules don't write to the ISA line, they just monitor it).

Some useful recommendations: make a 'double X-Memory' in slot 2/3, and combine it with a Time/Xfunctions in slot 1.Should be the base for each collection...

Or combine XIO/ILDEV with HPIL, or Printer with some 4/8K-module.

Ok, let´s talk about a combination of a HP-IL module with a 4k/8k module.. DOes this requires the same whire connections like the other possibilities (crossing B3-B5)

Matthias

Hi again,

82160A HP-IL Adapter doesn't care about B3/B4 lines. To merge any ROM Pac into an HP-IL enclosure just make a straight connection for every wire.

Cheers

HPIL (fixed) + a 4/8K (B3/B4-adapting) is exactly the situation I described as the example HPIL/Extended-I/O which I myself have built (quite a useful combination, one might argue that HPIL/IL-DEV might be even better, but that time I hadn't the latter).

As a combination of a fixed and an adapting ROM, you simply connect all wires one-by-one together. Don't think about any special wiring to move the adapting ROM to a specific slot, it would just result in subtle restrictions on where to plug in the module, or other modules when this pair is attached.

Holger thinks that there are 'no natural 4K modules that use a high port range, because HP didn't expect people to assemble multiple 4K ROMs in a single case', so no ordinary module can be doubled with the Card Reader. Ah, but Zengrange _did_ think exactly this, so the ZENROM is an upper 4k module precisely so that it can be doubled with an ordinary 4k ROM. This means that a ZENROM can also be doubled into a Card Reader - a useful hack but I have not heard of anyone who did it.

> Ah, but Zengrange _did_ think exactly this, so the ZENROM is > an upper 4k module precisely so that it can be doubled with> an ordinary 4k ROM. This means that a ZENROM can also be> doubled into a Card Reader - a useful hack but I have not> heard of anyone who did it.

Thanks for the correction. But did Zengrange actually have module tinkers in mind for that design? Or didn't they rather wanted to provide a development ROM which does not occupy the normal address space a later retail ROM would reside? You can hardwire RAM into the low range, and the resulting code won't need further changes even if it used absolute addresses (forcing the module into a specific port).

It's been a long time since I wrote HP41 code, but there is also a subtle difference between the low and the high range of a module port, namely the order of execution of the xFFx hooks. Don't remember whether 8ffx or 9ffx hooks would be called first in an 8K module, but there are interdependencies in which port you can put for instance CCD and other ROMs which both intercept the keyboard hook.

From my own fumbling and stumbling (which some people would call experience), I'd say that the order of polling-points execution is sequential, starting from the lowest addresses.

The classic example is combining the CCD and the ZenROM, but there are other cases where the order does matter as well (SandBox, AECROM, etc.)

Best,ÁM

>> Some useful recommendations:
>> make a 'double X-Memory' in slot 2/3,
>> and combine it with a Time/Xfunctions in slot 1.
>> Or combine XIO (...) with HPIL,

Exactly the configuration of my old 41CV, plus the Advantage ROM:

J-F

Why bother? With Clonix, NoVram and MLDL2000 you can plug almost any combination of ROMS in any port?

Only ROMS with specific hardware makes sense to combine, like XFUN and XMEM, and the ROMS that control I/O like IL, Wand etc ...

Meindert

Dear HP41 enthusiasts,

I correspond completely with Meindert. Today hardware ROM combinations are more of historical interest, because we are able to use ZEPROM, CLONIX, NoVRAM or MLDL2000. Only DOUBLE X-MEMORY Modules making much sense – in combination with the advanced plug in module solutions above.

For breaking the 32KByte address limit of the HP41 system we need more bank switched ROM solutions, therefore Raymond is working on the right way.

Up to now most HP41 enthusiasts neglect the creation of their own and individual user code ROM solutions, which are now possible with help of EMU41 plus ZEPROM, CLONIX, NoVRAM and MLDL2000. Own user code ROM solutions will extend the power of the HP41 system essential. May be there are some Mcode specialists like Angel or Raymond who are able to developing new ROM solutions, for example like SANDBOX.

With best regards - Christoph Klug

Christoph's summary is very sensible, and sure I wish I had more time to spend on the wonders and intricacies of MCODE programming - but unfortunately such isn't the case for the time being.

Maybe the MLDL_2000 triggers a new spur of activity! (it must be closer to release every day now, or so I hope).

Best, ÁM