RAM in the 400-FFF range possible?

The Beta programme is where a device becomes fully formed. If you have any suggestions for features to integrate into the DM41X then feel free to make them here. We can't guarantee that they'll all end up in the final product but we'll certainly consider all sensible proposals.
hth313
Posts: 36
Joined: Thu Jun 15, 2017 8:00 pm

RAM in the 400-FFF range possible?

Post by hth313 »

Is it possible to configure the DM41X to have RAM registers above the extended memory, at address 400 to FFF hex?
rprosperi
Posts: 1070
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: RAM in the 400-FFF range possible?

Post by rprosperi »

hth313 wrote:
Mon Oct 19, 2020 7:31 am
Is it possible to configure the DM41X to have RAM registers above the extended memory, at address 400 to FFF hex?
No, that's not possible, memory is laid out and accessible per the original OS behavior.

But I'm curious, why would you want to do that? Isn't upper RAM in pages 8-F sufficient?
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
hth313
Posts: 36
Joined: Thu Jun 15, 2017 8:00 pm

Re: RAM in the 400-FFF range possible?

Post by hth313 »

I am thinking of the RAM area that holds user programs, data registers, status registers, extended memory, not the plug-in ROM area. The ROM pages are addressed 0000-FFFF. RAM is normally 000-3FF (with some gaps). The RAM addressing can be done beyond, typically up to FFF by using all bits in the 12 bits address (3 nibbles).

What I am looking for is RAM above the extended memory, that is, 400-FFF. This range is available on the HP-41CL and I used it with a modified mainframe firmware to give over 3000 registers of extended memory. I wonder if it is also possible to do this on the DM-41X?

Preferably without any gaps like in RAM page 2 & 3, just a continuous linear space of RAM registers.
User avatar
pcscote
Posts: 142
Joined: Tue May 02, 2017 12:12 pm
Location: Near Montréal, Québec, Canada

Re: RAM in the 400-FFF range possible?

Post by pcscote »

rprosperi wrote:
Mon Oct 19, 2020 3:08 pm
hth313 wrote:
Mon Oct 19, 2020 7:31 am
Is it possible to configure the DM41X to have RAM registers above the extended memory, at address 400 to FFF hex?
No, that's not possible, memory is laid out and accessible per the original OS behavior.
But I'm curious, why would you want to do that? Isn't upper RAM in pages 8-F sufficient?
Robert,
ROM, QROM & HEPAX RAM are 10 bits cells with a 16 bits addressing space (64K or 16 pages of 4K) and is considered as main memory by the CPU.
RAM are 56 bits cells (7 bytes or register) grouped in 16 registers (448 bytes) and is considered as peripheral RAM by the CPU.
RAM registers is what main memory and extended memory is using.
NUT CPU is able to address 4096 registers (000 to FFF or 28KB) but the standard 41OS is only able to address 1024 registers (000 to 3FF or 7KB)
Håkan has modified the 41OS to support the full RAM registers addressing (4096) and made it available in the 41CL.
His question was mainly to see the possibility to do the same with the DM41X.
Sylvain

RAM registers memory map for the HP-41

Code: Select all

+-------------------------+-----------+------+--------------+--------------+
| Description             | Registers | Type | From Address |   To Address |
+-------------------------+-----+-----+------+--------------+--------------+
| 41C/CV/CX status registers    |  16 | main |    0 (0x000) |   15 (0x00F) |
+-------------------------------+-----+------+--------------+--------------+

Code: Select all

+-------------------------------+-----+------+--------------+--------------+
| 41C  build-in memory          |  64 | main |  192 (0x0C0) |  255 (0x0FF) |
| 41C  +1 x 82106A memory       | 128 | main |  192 (0x0C0) |  319 (0x139) |
| 41C  +2 x 82106A memory       | 192 | main |  192 (0x0C0) |  383 (0x17F) |
| 41C  +3 x 82106A memory       | 256 | main |  192 (0x0C0) |  447 (0x1BF) |
| 41C  +4 x 82106A memory       | 320 | main |  192 (0x0C0) |  511 (0x1FF) |
+-------------------------------+-----+------+--------------+--------------+
| 41C  +1 x 82170A quad memory  | 320 | main |  192 (0x0C0) |  511 (0x1FF) | replace 4x 82106A memory module, hence the name quad
+-------------------------------+-----+------+--------------+--------------+

Code: Select all

+-------------------------------+-----+------+--------------+--------------+
| 41CV build-in memory          | 320 | main |  192 (0x0C0) |  511 (0x1FF) |
+-------------------------------+-----+------+--------------+--------------+
| 41CX build-in memory          | 320 | main |  192 (0x0C0) |  511 (0x1FF) |
| 41CX build-in extended-memory | 128 | ext. |   64 (0x040) |  191 (0x0BF) |
+-------------------------------+-----+------+--------------+--------------+

Code: Select all

+-------------------------------+-----+------+--------------+--------------+
| 82180A x-fncs/memory module   | 128 | ext. |   64 (0x040) |  191 (0x0BF) | for the HP-41C/CV only, built-in in the CX
| 82181A x-memory first module  | 239 | ext. |  513 (0x201) |  751 (0x2EF) |
| 82181A x-memory second module | 239 | ext. |  769 (0x301) | 1007 (0x3EF) |
+-------------------------------+-----+------+--------------+--------------+

Code: Select all

+-------------------------------+-----+------+--------------+--------------+
| Empty Space                   |  48 | none |   16 (0x010) |   63 (0x03F) |
| Empty Space                   |   1 | none |  512 (0x200) |  512 (0x200) |
| Empty Space                   |  17 | none |  752 (0x2F0) |  768 (0x300) |
| Empty Space                   |  16 | none | 1008 (0x3F0) | 1023 (0x3FF) |
+-------------------------------+-----+------+--------------+--------------+
[DM1x/DM1xL/DM41/DM41L/DM41X/DM42]
rprosperi
Posts: 1070
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: RAM in the 400-FFF range possible?

Post by rprosperi »

I understand the difference completely, but thank you for the nice documentation, clear and helpful as always.

I understand also about Håkan's modified OS, I followed that as well. While a significant technical accomplishment, what is the real-world demand for needing that much Extended Memory on a 41?

In short, the 41X does not currently support RAM in that address range, but more importantly, there is currently no provision to install an alternate OS version which could access it even if the RAM were there.

Since "it's only software" all of these kinds of things are theoretically possible, but there needs to be some kind of demand before any serious consideration should be given to undertaking such development. How many people are currently using this capability on the 41CL and can anyone explain what it's needed for and why a 41X version is also needed?
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
hth313
Posts: 36
Joined: Thu Jun 15, 2017 8:00 pm

Re: RAM in the 400-FFF range possible?

Post by hth313 »

The main use-case would be to allow more data registers than is possible today. Data files in Extended memory can be used as direct addressed registers using XRCL/XSTO in the Boost module.

Sure, back in the days I only had 124 registers of extended memory and I could survive with it even though I had to compromise a lot.

Later I got some extended memory modules, but in reality I have never really used them. My needs had changed. I could store my programs in ROM modules and I no longer worked with large arrays or large data sets.

Angel added some Y memory functions, which also access this RAM area in non-standard ways. I suppose having larger Extended memory is as useful (probably more so) than those functions.

Having the full range 400-FFF is not required, each page starting from 4 and up gives 256 more registers of extended memory. You can stop at any point.

I left the Fxx page free on the 41CL, thinking it was already enough and having a fixed addressable page could be useful for future modules. It is like having 16 fixed areas of 16 registers (like the low 16 status registers), but that only works on the 41CL at the moment.

One benefit of having this memory available (if there is enough RAM), is that it makes the DM-41X more similar to the 41CL. Some special software that only works on the 41CL would also work on the DM-41X.

That I cannot load my own 41OS on the DM-41X is a turnoff for me. I hope this is allowed at some point.
hth313
Posts: 36
Joined: Thu Jun 15, 2017 8:00 pm

Re: RAM in the 400-FFF range possible?

Post by hth313 »

Put another way, having a larger extended memory is like having a small HP-IL mass storage built-in. You can store your files in it, just like you did on your cassette drive, but instead it would be built into the calculator. Yes, it will only be about 20K, not 130K, but it is still a decent amount of semi-off-line storage?
toml_12953
Posts: 700
Joined: Wed May 03, 2017 7:46 pm
Location: Malone, NY USA

Re: RAM in the 400-FFF range possible?

Post by toml_12953 »

rprosperi wrote:
Mon Oct 19, 2020 8:27 pm
I understand also about Håkan's modified OS, I followed that as well. While a significant technical accomplishment, what is the real-world demand for needing that much Extended Memory on a 41?
Maybe there's not much demand now but I'm pretty sure that if the capability were made available, people would find uses for the extra addressability. Programs are like a gas - they expand to fill all available space. As long as the change won't break current functionality, why not do it? You don't have to make it a priority or project that consumes inordinate resources. DM could work on it in their spare time or at their leisure. Are we at a scenario where it's not there because people don't use it and people don't use it because it's not there?
Last of all, why do we want to use all that memory? Because it's there! Just my 2¢. YMMV.
Tom L

If I buy someone a drink to congratulate them, is it a Mazel Tov cocktail?

DM10L SN: 059/100
DM41X SN: 00023 (Beta)
DM41X SN: 00506 (Shipping)
DM42 SN: 00025 (Beta)
DM42 SN: 00221 (Shipping)
rprosperi
Posts: 1070
Joined: Mon Apr 24, 2017 7:48 pm
Location: New York

Re: RAM in the 400-FFF range possible?

Post by rprosperi »

All of the things discussed here, extending user RAM area, allowing alternate OS to be installed, etc. are things that have been discussed, all would be interesting to build and most are feasible (though I'm fairly sure there is not enough RAM to do what Håkan suggests at the moment) however major undertakings such as these are not light decisions and developed just to find out if anyone might find a way to use it. Would you pay someone to build it just in case someone may want it?

For offline storage of programs, the FAT drive offers 6MB, which is more than enough for any scenario, however using the high RAM address space for huge data files would be unprecedented and not otherwise possible.

So, I keep asking, what is this for, who wants to use it, why, etc.? With strong user support, it could and should be considered for inclusion, and prioritized for release at some later date, etc. But until a case can be made, there are other things already in the pipeline, and no 'spare time' even visible on the horizon for quite some time to come.

I hope that clarifies the thinking about this and motivates further discussion; nothing would be better than to find some good justification to extend the 41X platform further...
--bob p

DM42: β00071 & 00282, DM41X: β00071 & 00656, DM10L: 071/100
hth313
Posts: 36
Joined: Thu Jun 15, 2017 8:00 pm

Re: RAM in the 400-FFF range possible?

Post by hth313 »

Adding RAM is hardly a major undertaking. I did it in my simulator and it did not take long as it was just a minor adjustment to the RAM allocation rules. In total the cost for me a couple of hours, but that is because I tested it, made it configurable and documented it. I used it to test the changes I made to my updated OS image before tried to run it on the real 41CL hardware.

Investigating the feasibility is even easier. Is there enough RAM for this, to have one or more additional 256 register pages?

Preventing people from loading alternative OS images means there will be no such endeavours.

These were both made possible on the 41CL and both happened. The extra RAM has at least two different implementations that make use of it.

I made an alternative OS and fixed several bugs in the existing one, as well as made the extra RAM available to everyone that updates the OS image.

Saying no, we will not do this, is perfectly fine. You have the right to prevent people from helping with improving your products.

Getting a more clear answer is all I want for now. It will help me decide on how to proceed, otherwise I will assume the answer is "no".
Post Reply