MLDL2059 (again): completely built!



#34

Hi, all;

Forgive me bringing back the same subject, but at least, this is the last time I'm posting about my own MLDL2059 assembling procedures (59 is the serial#) .

I actually built the last connector and finished assembling it. Now it is safer to operate and download. Thanks to the additional USB 'holder', I can insert and remove the USB connector without worrying about the possibility of having it loose inside the card reader holder. I am particularly worried about this because I did not use Meindert's suggested USB-B connector (could not find one), so I found myself in the need to hold it in place accordingly.

The new pictures are available at the same old www.logeng.com.br/images/mldl_pics again, and the new ones are easily found (mldl2059_connector_xx.jpg). Hope you like them.

To give you a glimpse, the final image:
Click to enlargeYeap, Hepax 1D!

The MLDL2059 is working perfectly fine, and I personally consider that the product itself by far exceeds Meindert´s proposal. Once FLASH/SRAM programming and editing are understood and internal mapping with SR configuration is mastered (just a matter of RTFM), all is heaven!

It is worth the $$$... and also the extra labor to settle the boards accordingly. At least for now, I'll miss all of the fun preparing the case for this unit. Yeap, I said 'at least for now'...

Best regards.

Luiz (Brazil)


#35

Luiz,

Quote:
Yeap, Hepax 1D!

From the docs, Hepax wil *not* work because the bankswitching is special and not (yet) implemented in the MLDL firmware.

Did you try it?


#36

Hi, Marcus;

I tried to find bank swithching related documentation, but it seems that each hardware handles the swithching its own way. I tested a set of four HEPAX files, version 1D, named HEPAXH1.ROM to HEPAXH4.ROM in some different configurations, and in some of them I got nothing but garbage from CAT 2. In two of them I read all HEPAX 1D functions and I could program some of them. As I do not know how to use them yet, and some of them refer to HEPAX RAM, I thought it would not be a good idea to test them in run mode. I would like to know which of these files represent lower and upper port, and which sequence should I try. I also would like to know how to rediredt MLDL SRAM pages so the HEPAX functions could "see" them. If bank switching is used in HEPAX RAM pages as well, if it works in MLDL2000 the same and the correct mapping is found, I guess we can expect to use at least 4 MLDL SRAM pages, meaning 16K RAM space for each possible SR setting where HEPAX is configured.

In order to try the configurations I had in mind, I took as a reference the fact that ADVANTAGE ROM images work in MLDL2000 (and I tested it already) when a specific combination of ROM images is used in the four banks in ports 8 and 9:

Bank#    Port8    Port9
0 ADV L1 ADV U1
1 ADV L1 ADV U2
2 ADV L1 ADV U2
3 ADV L1 ADV L2
I tried some configurations, and the one that shows all HEPAX functions is:
Bank#    Port8    Port9
0 HEPAXH2 HEPAXH1
1 HEPAXH2 HEPAXH3
2 HEPAXH4 HEPAXH3
3 HEPAXH4 HEPAXH3
Maybe this configuration allows only the headers to be seen, because at least their XROM codes are correctly recorded. I'll read the HEPAX manuals and try some functions.

Thak you for your warnings!

Best regards.

Luiz (Brazil)


Edited: 21 Nov 2005, 5:11 a.m.


#37

HEPAX should really not be working on the MLDL2000, the special instructions are not implemented at all, certainly HEPAX RAM cannot be supported. I have experimented with HEPAX on an older version of V41, and the virtual HP41 would not start at all. The configuration also seems to be incorrect, but I have not even tested HEPAX myself yet. I am surprised that it shows up in the CAT 2 listing at all.

For the Advantage ROM: I guess Port 9 Bank 3 is a typing error?

However, if HEPAX does work then it would be great, but certainly not by design!

Meindert


#38

Hi, Meindert;

you´re correct, I wrongly typed the ADVANTAGE table, sorry! It was supposed to be ADV U2 instead of ADV L2 (no such ADV L2 image...). In time: CCD's CAT' 2 and HP41CX CAT 2 show an interesting user label between '-ADV MTRX' and '-ADV MATH' in the emulated ADVANTAGE ROM ('MATRIX', perhaps, I am not sure). Should it be because of the MLDL2000 particular bank-switching scheme?

About HEPAX configuration, I have no idea if the mapping I use is valid, mainly because I do not know if any of the rom images is low- or up-addressed, their names do not suggest it. I started with some configurations that did not work at all. The one I listed in the previous post produced a valid CAT 2 and program instructions, but I did not go any further, meaning I did not test any of the functions as I do not know how do they work. And as some of them remind the HP original X-Functions/Memory module, they are supposed to access specific RAM memory, and I neither have any idea of how can it be done through the MLDL2000 structure.

In the MLDL2000 User Manual, you actually mention that bank switching is not fully implemented, but based on the ADVANTAGE unique mapping, I supposed it was worth trying to make HEPAX to work as well. Maybe I can think of something later, when deving into MCODE...|B^>

Thanks and best regards.

Luiz (Brazil)

#39

Hi Meindert,

although the HEPAX uses a special sequence to let

the actual HEPAX hardware know how and where to switch to,

AFAIK it also uses the standard mechanics (ENBANKn at the usual locations),

so if the MLDL2K supports these (like in the ADV pac),

then it should work.

The main difference to most other bankswitched modules is

that HEPAX uses all four banks, and BS slots are from xFC3 to xFC9.

Regards

Raymond


#40

Raymond,

You are totally correct, the normal bankswitching should work without problems, except that I am not certain if HEPAX switches only in one page, and not in both (odd and even) pages. The big problem is that when HEPAX starts it tries to relocate itself to another page, and identifies its own RAM pages by using the special Write Protect instruction. This is not yet implemented with the MLDL2000, and will probably cause the HEPAX startup sequence to fail.
Both instructions that are special to HEPAX will actually be quite difficult to implement, since it requires modification of the Settings Registers by the MLDL2000 itself. If these are in FLASH it is certainly not possible, only if they are in SRAM. I have some ideas about this, and actually the easiest will be to modify HEPAX itself, so it will start with a fixed configuration, and will not try to relocate itself.

Meindert


#41

Hi all,

First my congrats to Luiz for his neat MLDL2K housing job: Great work Luiz!! :-))

Now, regarding the HEPAX issue, here is what I've been able to learn (based just on experimenting during NoVRAM development, as I'm not one of thoses fortunated *real* HEPAX owners... :-(

Hope this can help others:

- HEPAX certainly uses same *standard* BS scheme than Advantage does. Just extended to four banks as Raymond pointed out.

- HEPAX procedure on Power-ON is as follows:

1st - Allocates itself in the lower page of the port it is plugged in. In doing so, it also temporarily disables its own first RAM page (usually on page #8 assuming HEPAX is plugged in port 1)

2nd - Searches for non used pages starting from page #5 upwards (#6 if it's in a CX). If no page is available it will show [ILL CONFIG] on the display.

3rd - Once a suitable page has been found it relocates itself into such page by means of "ROM BLK" (H'030) instruction and recovers first RAM page (for instance, on page #8)

4th - After relocation is finished it begins idle RAM pages identification by a sequence of READ/WRITE commands.

5th - Once idle RAM pages are identified HEPAX writes its proprietary "FILE SYSTEM" chain in them. (Remember you can have ROM images recorded into RAM pages, these won't be altered by this process)

6th - Last it turns back control to the HP-41 mainframe OS.

From what's stated above, some conclusions can be drawn:

- HEPAX will not perform relocation (nor RAM FILE SYSTEM building) if it's forced to load into an odd page (say #7)

- You can build up the HEPAX FILE SYSTEM by hand (say in pages #8 to #B) so HEPAX will recognize it as its own FS.

- Obviously you won't be able to use RAMTG (page write protection) command so, one must just be disciplined when handling RAM pages.

Theoretically, such a config will work on an MLDL2K, I havent tested it yet, but I'll try to find the time during the week and will let you know of the results.

Cheers from the Canary Islands.

Diego.


#42

Hi, Diego; thank you for your kind (and encouraging) comments. I appreciate it!

Just a few (silly?) questions from someone that is getting into the inner HP41 secrets right now. Some background: I was able to download two sets of HEPAX ROM images, namely versions 1C and 1D, each with four files named HEPAX H1 to HEPAXH4. In both cases, HEPAXH1 and HEPAXH3 had XROM definition (03) and function counting, while both HEPAXH2 and HEPAXH4 had none. One of the sets (don't remember which one, 1C or 1D) also contained two ROM images equivalent to RAM pages, and they are simply two 4K files filled with zeroes (at least I have not seen anything else bute zeroes).

So... questions are: could/should these zero-filled images be loaded in SRAM to mimic HEPAX RAM, so the module (or ROM image) could identify it/them? What could we consider as for lower and upper files for HEPAXH1 to HEPAXH4? Maybe lower or upper image is not even applicable, but what valid mapping should be used to start loading HEPAX? As you have already studied the HEPAX startup, does the module save the startup information somehow, and where should it be?

Thanks for your support and forgive me if the wquestions are not applicable.

Cheers.

Luiz (Brazil)

(in time: Diego, did you receive my last e-mail with the configurations for the modules? Please, let me know)


Edited: 21 Nov 2005, 6:16 p.m.

#43

Diego,

This is really interesting. So it might work after all! I have not done any testing, but looking at the HEPAX code I assumed that HEPAX would identify its RAM pages by doing the write protect, so it would only use its own RAM pages for the HEPAX file system.

My idea was to load HEPAX in the lowest possible page anyway (5 or 6), so relocation should not be required.

If I have time I will also do some testing myself.

Meindert

BTW, I have now a list of ROMs supported by the MLDL2000 on my website. Let me know what ROMs you know to work, so I can add them to the list.


#44

Hi Meinder, Diego, guys;

After a bit of mind clearing with sacred MoHPC ritual (think RTFM...), I read the little .txt that comes with the HEPAX.MOD and it is explainded there that:

  1. HEPAXH1.ROM to HEPAXH4.ROM should occupy banks 0 to 3 (1 to 4 in the original text);

  2. it is also stated these ROM images should be in a page with an even # (8, B, D or E);

  3. each of the two RAM-image files that come with the HEPAX ROM images are designed to be in the first bank of an odd- or even-numbered page;

  4. the HEPAX manual explains that the HEPAX ROM uses one single page, and that each 16K RAM module occupies four pages, or two ports. (This is probably the reason that HEPAX relocates itself to a lower page, so all pages from 8 to F can be used to accomodate the 32K RAM, in 8 pages of 4K each, by using three modules)

So, I loaded all RAM files accordingly, in MLDL SRAM blocks, and set the SR as well (pages A, B, C and D); I also tried the suggested configuration by using page #8 and all of the banks filled accordingly, but I guess that a particular mapping with page #9 should be made, as it happens with Advantage mapping. All HEPAX functions I tried returned error messages, and the HP41 main memory was reduced from the original 319 registers to 273 registers (46 registers are relocated). After testing a few functions to see what messages they generated, the HP41 stuck and pages 8 and 9 became unavailable, even after a series of MEMORY LOST sequencies. I had to remove the MLDL and insert it in another HP41, then I had to insert a different module in port#1, place the MLDL back and then the pages became available again.

After that I tried the same procedure below, with the HEPAX ROM images mapped to page #6 and RAM mapping to pages 8, 9, A and B. Same behavior, no calculator stuck because I did not insist that much...

I think further studies should be made prior to settle HEPAX to work with the MLDL2000, but although the calculator stuck in a weird way, based on Diego's considerations and Meindert's agreements, I guess it is a matter of a final, working arrangement.

Any additional facts, thoughts, eventual corrections? Please, althought I've been dealing with the HP41 basic hardware and software since the 80's by doing smalll repairs, structure studies and user-code programming, I'm dealing with all of this HP41 internal arrangments for a month only, strictly available time, and I hope all former enthusiasts forgive me if I am like a kid with a new toy... or like a kid with an old toy that found some hidden features.

Cheers.

Luiz (Brazil)

Edited: 22 Nov 2005, 3:22 p.m.


#45

Hi all,

Not much time allowed for testing, but here is what I've found:

- Forcing HEPAX to page #7 (CX) or #5 (CV) allows 41 to power up and display the correct CAT 2...

- It's also possible to see RAM on pages #8 & #9 thru [HEXEDIT] and it can be read and written accordingly...

- However, some (most) HEPAX functions return error messages as Luiz has pointed out. Further more, those error messages are *not* consistent with the corresponding function... (?) (for example: [HEPAX 002] returned H:NO FILESYS) So far this is quite a mystery for me...

Now I'm preparing a somewhat weird config SR trying to fool the 41 reagrding HEPAX location in an attempt to gain access to the HEPAX code itself... let's see what we find out... ;-))

Best.

Diego

Edited: 22 Nov 2005, 4:21 p.m.


#46

Hi again,

As usual, things are much clearer when you dig down to the "bit" level... ;-))

First, the cause of the troubles comes from the (dis)order in the so-called *standard* Bank-switching scheme:

100 - Bank 1

180 - Bank 2

140 - Bank 3

1C0 - Bank 4

... as you can see, bits 6 & 7 determine which bank to point to, but banks 2 & 3 are, in some way, *swapped*.

By fooling the 41 (which allows HEPAX editing) I've found out that the BS scheme in the MLDL2000 does not keep the "standard" order, but the bits order instead.

Just place HEPAX images in the "correct" order (i. e. 1, 3, 2 & 4) into the corresponding banks: 1, 2, 3 & 4.

And the whole thing works as expected... well... remember you must write the HEPAX FILE SYTEM by hand... here it is how it looks for 16K on pages #8 to #B.

8000: 00B

8FE7: 000

8FE8: 009

9000: 00C

9FE7: 008

9FE8: 00A

A000: 00D

AFE7: 009

AFE8: 00B

B000: 00E

9FE7: 00A

9FE8: 000

X= Same contents in all four pages

XFED: 090

XFEF: 091

XFF1: 0E5

XFF2: 00F

XFF3: 200

Hope this helps, best wishes from the Canaries!!

Diego.


#47

Hi, Diego;

I am amlmost sure I do not speak only for myself when I say "Thanks!"

I'll try it later (now being sure of having a good result) and save the corresponding SRAM contents after modifying them so it will be easier to load them back when needed.

Best regards.

Luiz (Brazil)

(In time (again): did you receive my e-mail with the configuration for the NoVRAM and NoV32? Just let me know, so I can send it again if you didn´t get it)


#48

Hi Luiz, all,

Thanks, yes I do receive it, please check your mail, I've sent my reply a minuta ago... ;-)

Best wishes.

Diego.

#49

Hi, Diego;

the last post should be updated to contain:

BTW, shouldn't the three last lines be

B000: 00E
BFE7: 00A
BFE8: 000
instead of
B000: 00E
9FE7: 00A
9FE8: 000
Maybe you copied and pasted so the last ones were not updated... Also, in case of daring a 32K RAM, would the modifications be reflected the same way, I mean:
C000: 00B
CFE7: 000
CFE8: 009
D000: 00C
DFE7: 008
DFE8: 00A
E000: 00D
EFE7: 009
EFE8: 00B
F000: 00E
FFE7: 00A
FFE8: 000
or should their contents be different, I mean, do the 8, 9, A, B, C, D and E bytes refer to some address or are fixed data? The other set seems to follow the same pattern, right?

Best regards.

Luiz (Brazil)

Edited: 22 Nov 2005, 5:50 p.m.


#50

Hi Luiz,

You're right about the copy-paste error, regrettably it cannot be edited according to new forum's policy (you know for sure who's the one to "thank" about that..)

Regarding the HEPAX FILE SYSTEM, it's in fact a "chain" so:

X000: Holdl a *unique* fake XROM-ID starting with H'00B, this turns C000: H'00F, D000: H'010, and so on...

XFE7 and XFE8 holds the pointers to the preceding and following pages in the chain respectively, or H'000 for the upper or lower ends of such chain.

Whit this in mind the 32K FILE SYSTEM version will look like this:

B000: 00E
BFE7: 00A
BFE8: 00C
C000: 00F
CFE7: 00B
CFE8: 00D
D000: 010
DFE7: 00C
DFE8: 00E
E000: 011
EFE7: 00D
EFE8: 00F
F000: 012
FFE7: 00E
FFE8: 000

Hope you find this info useful.

Cheers.

Diego.


#51

...

#52

HI all;

I know Diego is helping the way he can and that Meindert himself had already told that bankswitching is available and has some known limitations in MLDL structure. As a matter of fact, the ADVANTAGE emulation runs perfectly fine, as many other MLDL users may have noticed. The only fact that still calls my attention is that W&W's [CAT'] 2 shows intermetiate labels or function names when the emulated ROM uses more than one page. I have not tested the 41CX's [CAT] 2 to see if it happens the same.

I have read that HEPAX has some tricky operation, and Diego was able to completely emulate it with his Clonix41 or with his NoVRAM/NoV32 running as Clonix41, so Diego has valuable experience studying HEPAX operation.

I prepared all data related to the HEPAX emulation in the MLDL2000 and it now performs all 'memory independant' operations successfuly, and some memory access operation. One of them, HEXEDIT, either reads or writes successfuly in MLDL's SRAM.

But when the HEPAX automatically accesses MLDL SRAM, it seems that there is something missing or wrong, I cannot say for sure. With all SRAM memory filled with zeroes and the corresponding bytes altered the way Diego sugested (double and trippled checkd, even with HEPAX HEXEDIT), it seems that HEPAX 'sees' some contentes that are not there. HEPDIR returns some entries, about ten, with names like

 C2   C3    C4    C5     MC    ??,S    PR,S 
and so. When the list finishes, the display shows:
[          8:]
and when HEPROOM is executed, the same
[          8:]
is shown again. If we activate ALPHA, a weird, right-justified (wait for a little or press any key to see) 2000000 is shown in the ALPHA register; is this what HEPAX sees as free memory? 2.000.000 registers? If so, no wonder why it is behaving like this. I am sure that the last SRAM block contains a 000 as the reference of the last block in the chain.

I am almost sure that I may be doing something wrong, maybe I keyed extra data in or missed some step. Has anyone else tried the HEPAX with MLDL2000 so far? I think that using an actual HEPAX module and emulating RAM with MLDL might also work, OR, Diego, emulating HEPAX with Clonix and SRAM with MLDL (that´s what I actually have in mind) might give us plenty of room to develop and study MCODE. Even if it is for pure fun...

Thanks all and regards.

Luiz (Brazil)


Edited: 23 Nov 2005, 8:47 a.m.


#53

Hi all,

Let me just remind you that Emu41 fully supports the Hepax module (among other things), and can be used as a reference for the (unlucky) ones who don't own the real module...

From my own experience in implementing Hepax operations, there is no need to initialize the RAM with special values.

Regards.

J-F

#54

Many thanks go to Diego and Luiz for making HEPAX work and finding two design errors in the MLDL2000:

bug 1: Banks 2 and 3 are swapped. This can be easily fixed, but requires the firmware updater to be finished first before the user can do the upgrade himself. I am working hard on this (complicated) piece of addition to the M2kM software.

bug 2: HEPAX works! This is not by design, but rather by fooling HEPAX and setting a special configuration. The only restriction is that it is not (yet) possible to control the Write Protection of SRAM from within HEPAX.

The only thing that need to be added to Luiz' configuration to run HEPAX in the MLDL2000 is that the RAM pages must be in all banks of a port. Why is not really clear to me yet, but with the settings below I have been able to save a program in an SRAM page, and HEPDIR and HEPROOM seems to give the correct results! I will investigate this further, there may be more secrets to bankswitching that still need to be uncovered.

Configuration for a CX:

Page $7, Bank 1: HEPAX1-1D

Bank 2: HEPAX2-1D (in SR this is Bank 3)

Bank 3: HEPAX3-1D (in SR this is Bank 4)

Bank 4: HEPAX4-1D


Page $8, Bank 1 to 4: SRAM Page 1 (identical in SR)

Page $9, Bank 1 to 4: SRAM Page 2 (identical in SR)

I have not tested any other configurations yet, but I think we have proven that HEPAX can work in MLDL2000 if the configuration is right!

To answer to another question with the CCD CAT 2: this is by design. AFAIK a FAT entry starting with a '-' will be seen as an extra header.

Meindert (who was very excited to see HEPAX work in his MLDL2000, I really feel like on old kid with a new toy)


#55

Hi Meindert, Diego, all;

Thanks for crediting, but I consider that Diego and others that actually know what was going on inside the HP41 'guts' and made good suggestions are the ones to be credited. I am lurking around and, occasionaly, getting into accquaintance with the so many new information. In any case, you all know I am sharing whatever I find out, because I may find something important and do not be (yet) aware of that. Thanks!

In time. Meindert, you wrote in other post:

Quote:
While testing I discovered another potential problem with a wrong HEPAX configuration: when connected to USB, the CPLD remains powered, and the contents of the Bank Switching Registers (which are in the CPLD) are kept alive. If the current active bank in a port is pointing to the wrong place, switching the HP41 OFF and then ON again, will not solve the problem if USB is still connected. I will investigate this and look for possibilities to reset the BS registers.
I was about to point this out, but with so many stuff being discussed here, I thought I should wait till HEPAX basic configuration was ready prior to go ahead with that. In fact, if this happens, [CAT] 2 lists some stuff but HEPAX functions, and I thought that it was related to bank switching. Anyway, closing all MLDL 2K manager windows and disconnecting the USB cable (HP41 OFF) proved to be enough to bring the HP41 back to normal operation. In only one case that I forgot it connected for too long, it took me a while and a lot of [ON][<-] to bring it back. The LCD was somehow dimm (it is a fullnut, i.e., no contrast available), but it became normal after about 10 to 15 minutes.

Just to add these facts.

Cheers.

Luiz (Brazil)

Edited: 24 Nov 2005, 12:42 p.m.


#56

Hi again all,

Undoubtly, the more people try to replycate the "suggested" HEPAX configuration the more feedback info we'll get... However, I think that it will be a good idea to *define* a unique "testing scenario" in order to make all comparative testing (and results) to be consistent.

This is just a proposal for such scenario, feel free to suggest others (or mods to this one):

HEPAX-1D loaded into MLDL FLASH pages 240, 241, 242 & 243 (you may think it's completelly irrelevant where an image is loaded, but it will be easier to share SR files... and, IMHO, *nothing* is completely irrelevant ;-) Point SR (FLASH SR #0 for the sake of precission) to page #5 and use a CV.

RAM pages #8 to #B (start testing just with 16K... I think its a good testing tradition to proceed one step at a time...) pre-programmed with "basic" FILESYSTEM structure (as described in previous posts. Remember BFE8 must be H'000) Loaded into MLDL SRAM pages 0 to 3. (at this point remember to fill all 4 banks of every page with the same descriptor.)

I must say I don't have a battery inside my MLDL, so I keep USB *and* HP-41 connected all the time...

Turn HP-41 ON.

With above described scenario, I've been unable to reproduce the errors Luiz have seen... (?)

After first HEPDIR, (or others FILESYSTEM related commands) HEPAX *actually* build ist FILESYSTEM, shows "H:DIR EMPTY" and (<-) 2.610,0000 (free registers in "X")

You can check at address X092: H'04E and X093: H'00F (X= 9 to B) to verify if FILESYSTEM has been correctly built. At B092 and following addresses you'll find something like this: 380, 251, 1CA... (on real HEPAX this contents are allocation dependant...)

If things goes as expected then remove the RAM mapping to BANKS 2 to 3 in SR, leave just BANK 1 for RAM pages... Otherwise please post your results as detailed as possible.

I've also tested this, without problems (remember I always have USB plugged in)

Turn 41 OFF.

Then, re-load *all* MLDL SRAM pages 0 to 7 with pre-programmed RAM images according to the *basic* FILESYSTEM for 32K RAM (now BFE8 should be H'00C)

This is required to avoid HEPAX finding a half-built FILESYSTEM (see HEPAX manual to get detailed info on how *strict* is HEPAX in handling its own FILESYSTEM... ;-)

Turn 41 ON, execute HEPDIR, you should get "H:DIR EMPTY" again and 5.222,000 afterwards (<-) in X register...

I know this could seem quite painstaking, but HEPAX is *really* sensitive when it comes to messing into its proprietary FILESYSTEM... and some of the things we've testing are not even cosidered possible those days, back it the good eigthies when this wonder was conceived... so keep in mind taht we're "playing in *other's* yard" ;-))


Once we can cope with HEPAX standalone functionality, will begin with other modules/devices (CCD, Advantage, printer... interoperability).

Your comments and test results are certainly welcome!!

Best wishes.

Diego.


#57

Hi Diego, all;

first of all, let me just add that in my previous post I missed some of my own words. I wrote:

Quote:
(...)I consider that Diego and others that actually know what was going on inside the HP41 'guts' and made good suggestions are the ones to be credited.
and I should have written:
Quote:
I consider that Diego, the one that actually made HEPAX work properly in MLDL, and others, that also know what was going on inside the HP41 'guts' and made good suggestions, are the ones to be credited.
That said, let's go ahead.

Diego, both the HEPAX ROM images I have, either 1C or 1D, show a checksum error (I did not notice before...). I reproduce the 1D-version report shown after MLDL's Open operation in MLDL ROM/SR Handler:

  XROM          : $007  007
# Functions : $037 055
Pause Entry : $000
Program Entry : $000
Sleep Entry : $000
OFF Entry : $243
Service Entry : $000
ON Entry : $213
MemLost Entry : $000
ROM Revision : H1-1D
Checksum : $106 CHECKSUM NOT GOOD, should be $100
Is it the same one you use?

This one is just for checking purposes, althought the answer is known. You did not mention the way HEPAX images should be ordered, so we assume it is the 1-3-2-4 bank sequence, right?

About the HEPAX memory modules. I know you mentioned you did not have any HEPAX actual memory modules, but it seems to me you have the actual HEPAX ROM module. If this is true, have you tried to use MLDL's SRAM with the actual HEPAX module? You know what is still teasing me? If the HEPAX memory modules are RAM modules without backup batteries, shouldn't they be empty (all bits = "0") when firstly inserted in an HP41? If so, HEPAX should build the system files from 'zeroes', and based on what I read, it would identify the existence and location of RAM modules after writing/reading operations. If we can call them this way, the few 10-bit words recorded on these RAM modules are like signalling words, as for the existence and RAM sequence (chain). Is that correct? If my assumptions are correct, would an actual HEPAX ROM module be able to build the HEPAX file system in empty ('zeroed') MLDL SRAM available blocks? If it is not daring too much, may I go somehow further and ask how does Clonix emulation of HEPAX (in NOVRAM programmed with clonix6) handle that?

I have already printed the tentire text and I'll go for your solution in a few minutes from now. I just would like to be confident of the HEPAX image I have here.

Thanks again, Diego (and Meindert, of course). It's been pure brainstorm these last weeks.

Cheers.

Luiz (Brazil)


#58

Hi, Diego, all;

I had not seen Diego's reply to Meindert's post where Diego mentions what he is using to perform tests. Anyway, I'll keep the suggestion to use MLDL2000 SRAM blocks with NoVRAM HEPAX emulation (something I want to do soon...)

Cheers.

Luiz (Brazil)

Edited: 25 Nov 2005, 11:36 a.m.


#59

Hi Luiz,

I'll try to make an abstract from the somewhat "disperse" info in my posts above:

- No, regrettably I haven't got any *real* HEPAX, neither the module nor the MEMORIES... :-(

- The Clonix module is not able to emulate HEPAX, this is achieved by NoVRAM and NoV-32. I build an HEPAX file for clonix just for the fun of playing with some of its functions but it cannot handle any FILE SYSTEM related funtionalities.

- HEPAX do in fact lost its memory contents when it's unplugged (one of the [few] things in which NoVRAM emulation surpass the *real* HEPAX specs)

- Consequently, you're right when supposing HEPAX builds its FILE SYSTEM from scratch (all zeroes). This is achieved in two steps:

1st HEPAX writes the "basic" FILE SYSTEM structure, on power up, *after* relocation... thus, due to the imposibility to perform relocation on the MLDL, this step will never be automatically performed. That's why I write it by hand. In fact, the real HEPAX does not write the "chain" (XFE7, XFE8) in this step, these remain zeroed until the 2nd step is performed. Also address XFF3 holds H'100 instead of H'200 at this very stage of the initialization process. However, I've got no difference during tests in doing this way.

2nd once that basic structure is written, you must execute HEPDIR to actually build the FILE SYSTEM structure. At this point HEPAX writes data at addresses X092 and following, writes the chain at XFE7 and XFE8, and toggles XFF3 from H'100 into H'200.

- NoVRAM could be used to handle MLDL SRAM in an HEPAX-like fashion, but in its current implementation NoVRAM holds 16K (#8 to #B) so MLDL RAM must be set to map at pages #C to #F.

Whichever the case, and prior to begin messing with different/mixed module-MLDL configs I'd like to have a consistent basis just with MLDL and standalone HEPAX emulation.

As I've told before I've got it running in my MLDL but want to make sure this is not a "casual" result... That's why I've posted a basic testing scenario.

Hope this helps others interested in the process.

Best regards.

Diego.

P.S. Regarding HEPAX image checksum... yes it's the same here, but I haven't paid much attention to this point. And the banks order is ok: 1, 3, 2 & 4.


Edited: 25 Nov 2005, 1:04 p.m.


#60

Hi Diego, Meindert, all that are following this MLDL adventure.

I followed all Diego's suggestions and actually changed some of my MLDL2000 `preferences`, so I could go ahead with the experiment exactly the same. In time: there is no problem at all rearranging ROM images in the FLASH memory, once you know what you are doing. I sent Diego a copy of what I have already stored in FLASH memory, and I agreeded with moving four images form where they were in order to locate the HEPAX 1D ROM images in the same address suggested. The four ROM images I had in 240, 241, 242 and 243 were moved to lower addresses. As a matter of easy arrangement, a fifth ROM image was also moved.

All set, 16KRAM available and `preprogrammed`, calculator OFF in all MLDL accesses and changes, after first HEPDIR I saw the same C2, C3, C4 and C5 entries again, and the 2,160.0000 at the end (free registers, O.K.). If HEPAX reports 2.610 free registers, the C2, C3... entries do not occupy space, so there is no trouble for me.

I checked all non-zero words (added/changed) and found:

Addr	Dta
8092 048
8093 0B0
8095 01C
809A 047
809B 00F
X092 04E (X= 9, A, B)
X093 00F (X= 9, A, B)
I repeated the entire process with a 41CV halfnut and got the same results.

Then I changed SR references and removed the SRAM references from banks 2 and 3 at pages 8, 9, A and B, so I executed HEPDIR again and I received a NONEXISTENT. Then I tried [CAT] 2 and none of the HEPAX 1D functions were there, HEPAX 1D identification neither.

One point: I am counting banks 0, 1, 2 and 3, as they appear in the MLDL2000 Manager windows. Is there a chance that you, Diego, is counting banks 1, 2, 3 and 4? In this case, should I leave intact the references to banks 0 and 1 in a 0, 1, 2 and 3 counting for each SRAM, or should I leave references to banks 1 and 4 in a 1, 2, 3 and 4 counting? Or any other arrangement? In my case, as I am counting as MLDL2000 Manager shows, I left banks 0 and 1 with the original reference SRAM. And as I was considering other possibilities, I decided to remove all but the first bank reference. So I had only bank 0 of each SR activated and tried again: no HEPAX showing up. I restored previous references to all four banks and tried again. No HEPAX. Then I closed MLDL2000 manager, disconnect the HP41 and tried: there he is, HEPAX functions back again after [CAT] 2.

HEPDIR gives C2, C3, C4 and C5 as the four unique entries yet, each with a right-justified space, and ends with correct 2.610 available registers. I decided to go ahead finished all steps to set 32KRAM the way it is shown here, and after HEPDIR I got:

C2
C3
C4
C5
MC
??,S
PR,S
DA,S
5,610.0000
These look like ‘ghost entries’, or something like references to the possible file types. You see, when HEPAX cannot identify a file type, it shows the file ID as ??, right? PR refers to Program file, and DA refers to Data, the S meaning Secure file. No Key assignment file references, however, neither ASCII (ALPHA string), nor Write All.. Except for these particular entries in HEPDIR, everything else seems fine. After saving three small programs as for testing purposes, the first `ghost` entry (C2) disappeared, and the reported remaining register was reduced to 5,203 (fair enough to hold the new data). One interesting fact: although these ‘ghost´ entries do not count as used bytes, HEPDIRX ‘sees’ each of them as they appeared: C2 when X=1, C3 when X=2, and so. After loading the three small programs, C3 became entry #1, C4 became entry #2, etc.

And yes, after [HSAVEP], each of the three programs appear in [CAT] 2, after [XFA]. I ordered a MEMORY LOST and recovered each of them back to main memory. Interesting: I saw [HSAVEP] and [HPURFL], but I did not see [HGETP]. After wondering about how to bring the programs back, I decided to see the functions repertoire in HEPAX to see which of them could be used. Then I saw the three labels showing up as the last entries, and I could understand that they were actually converted to internal XROM calls. I was not known about that... I wonder what else I missed all of these years... After that, [COPY] was enough to bring them back.

I´ll go further using HEPAX functionality to deal with as many possibilities as I can, and I'll report any additional fact.

In time: Meindert and Diego, as Diego mentioned his MLDL2000 is a BETA unit and being my own a regular unit, are there any chances that the CPLD program used in mine is an updated version? If so, that would (at least partially) explain the different behavior. I guess it would be related to WXP version or MLDL2000 manager; maybe the HEPAX version, but it seems to me that Diego is using the same.

I wish I knew more about the HP41 + HEPAX internals to be more technical and deeper when mentioning these facts, sorry.

Thanks again.

luiz (Brazil)

(should we start a new thread?)

#61

I guess this particular thread will be a reference for future users. I'll later compile all info posted here and try a final docuemnt. Waht do you think?

Cheers.

Luiz (Brazil)


#62

Please do! I intend to own an MLDL2K one day, and I have a Nov32 on order. Reading this thread has been educational and interesting!


#63

just a humble "You are guys are simply amazing" from a guy not really worthy reading your stuff. A happy owner of an MLDL as well and in love with the HEPAX I've been following your post here with great excitement. Now it will allow us mere mortals to play with a fantastic HP - MLDLD+CCD+Hepax+lots of memory (as I don't have any hepax-memory modules).
Thanks again, you guys (including the one genius who has made the whole thing possible in the first place, Meindert) are awesome! Thanks so much for sharing all this invaluable information, I'm sure I'm not the only bystander who has followed this post with held breath.

Cheers

Peter

#64

Hi again,

I've received an e-mail a minute ago from a user/friend, he pointed me out about one fact that I think requires clarification:

Some of my previous posts in this thread could be *misread* as if I had unveiled some errors or weak design points in the MLDL2000, not AT ALL!!

Please note that MLDL2000 achieves a smooth Bank-switching handling, it uses bits 6 & 7 in the "logical" order, and it's just a matter of ROM images loading organisation which does *not* represents any kind of incorrect function whatsoever.

Meindert, please excuse if any of my explanations could be misunderstood. Sincerely hope this clarifies my opinion about your superb device.

Best regards and enjoy your new toys.

Diego Díaz, honoured MLDL2003 betatester... ;-))


#65

Diego,

I am very glad to hear that there are bugs/mistakes/design issues in the MLDL2000. That is why I have made all the information public to make it better! Did you dive into the VHDL sources?

I have pinpointed the error and have already fixed it, but not tested it yet. For field upgrades this requires a bit of software that I am working on to be finished first to allow reprogramming of the CPLD firmware.

Bankswitching is for me still a bit of black magic. The actual code to implement it is only a few lines of VHDL code, and I have used the bits in the ENBANKx instructions to control the address bits for selecting the active bank, and that is where I went wrong. To implement is was actually very simple, but the mechanism has large consequences. I actually did the coding of BS without any simulation, and it worked the first time I tested it with the Advantage ROM.

While testing I discovered another potential problem with a wrong HEPAX configuration: when connected to USB, the CPLD remains powered, and the contents of the Bank Switching Registers (which are in the CPLD) are kept alive. If the current active bank in a port is pointing to the wrong place, switching the HP41 OFF and then ON again, will not solve the problem if USB is still connected. I will investigate this and look for possibilities to reset the BS registers.

I am still a bit worried about having HEPAX in Page 7 (CX configuration), and something else in Page 6 that also does bankswitching (Page is normally just for the Printer). Since the even and odd ports share the same BS registers they will influence each other. Also, what happens if IL (fixed at Page 7) is plugged in, where do we put HEPAX then?

Again, please report any unexpected or undesired features of the MLDL2000, it only helps to improve it!

Meindert


#66

Hi Meindert,

Thanks for your comments. It was more a question of luck than of knowledge, that I come accross with the swapped organization on banks 2 & 3... (I should'n call it a "bug"... :-)

Regrettably I haven't dig into CPLD code. I've got almost no experience with these devices, so I'm affraid I wouldn't be much of a help in this field... Always willing to learn though!!

In a previous post to Luiz comments I've described some of the test I've performed so far. First I also kept RAM pages in all four banks, but removing them from banks 2, 3 and 4 did not make any difference (at least on my unit) regardless the use of 16K or 32K RAM configurations...

I'm using my own NoVRAM (16K RAM) with HEPAX-1D emulation as a "reference", currently I have no NoV-32 unit due to some domestic trouble... I'm confident I'll have some units ready during this weekend to test 32K configurations (I must say that NoV-32 was not intended to use all 32K with HEPAX FILESYSTEM but this could be achieved though...) It would also be great if users with the *real* HEPAX (and even HEPAX MEM/HEPAX 2MEM) can verify the reported results... Any volunteer?? ;-))

Best wishes.

Diego.


Possibly Related Threads...
Thread Author Replies Views Last Post
  flood side-effects (not completely OT) Kiyoshi Akima 6 368 11-05-2013, 12:06 AM
Last Post: Kiyoshi Akima
  [hp 50g]Recall quickly a built-in function Pier Aiello 10 389 08-05-2013, 09:38 PM
Last Post: Robert Prosperi
  Solving with the built-in equations of the 35s Palmer O. Hanson, Jr. 4 221 10-17-2012, 03:17 PM
Last Post: Dieter
  [OT] Completely off-topic but couldn't resist Valentin Albillo 11 472 10-08-2012, 09:51 AM
Last Post: mike reed
  HP-48GX RAM Cards - Better with or without built-in battery? Timo 7 275 02-20-2011, 12:11 AM
Last Post: Steve Medina
  30b Built-In Functions Jeff 6 210 08-19-2010, 06:49 PM
Last Post: Allen
  number of calculators built of each model Jose Gonzalez Divasson 2 115 06-25-2010, 10:05 PM
Last Post: Eric Smith
  Pre-built Windows version of NutStudio tools for HP-41 available Håkan Thörngren 5 205 04-23-2010, 02:30 PM
Last Post: PeterP
  [Completely OT] Capeesh Antonio Maschio (Italy) 15 503 11-13-2009, 08:00 AM
Last Post: George Bailey (Bedford Falls)
  And now for something completely off topic: Geoff Quickfall 9 355 04-27-2009, 12:34 PM
Last Post: Kiyoshi Akima

Forum Jump: