CMT 64Kb RAM module for HP-71b question

[Sylvain Cote]

(10-11-2021 02:55 PM)Dave Frederickson Wrote:  That's just wrong. You MUST FREEPORT a RAM module before removing it.

Yes, I know, this is what I normally do.
There is a problem with the address configuration routine and with free in particular, I was trying all kind of tests to narrow the issue.
Since the memory does not contains anything, inserting and removing memory modules is normally harmless and the system do cope with it.
I have done this countless of times in my testings and never got a ML on an empty machine.
Anyway, the test result was negative, I tried all combination and I got no ML afterward.

[J-F Garnier]

(10-11-2021 12:44 PM)Sylvain Cote Wrote:  I also did this test:

1. no RAM memory modules
2. INIT 3, MEM → 16760
3. power off, insert 32K RAM into port 1, power on, MEM → 49517
4. power off, insert 32K RAM into port 2, power on, MEM → 82280
5. power off, insert 32K RAM into port 3, power on, MEM → 115043
6. power off, insert 32K RAM into port 4, power on, MEM → 98654 → What?
   

OK, how this is mapped ...

Code:

MEM → 98654
DELAY 0,0
DISPLAY IS :PRINTER
COPY MEMBUF:TAPE
RUN MEMBUF
Port Dev Seq  Size Addr  Type
  1   0   0    32  30000  0
  2   0   0    32  40000  0
  3   0   0    32  50000  0
  0   0   0     4  78000  1
  0   1   0     4  7A000  1
  0   2   0     4  7C000  1
  0   3   0     4  7E000  1
  0   5   0    16  60000  2
  4   0   0    32  D0000  1
  5   0   0    16  68000  2
  5   1   0    32  C0000  2
  5   2   0    32  B0000  2
  5   3   0    16  70000  2

Power cycle and show memory map again

Code:

MEM → 146306 , memory is now what was expected
RUN MEMBUF
Port Dev Seq  Size Addr  Type
  0   0   0     4  70000  0
  0   1   0     4  72000  0
  0   2   0     4  74000  0
  0   3   0     4  76000  0
  1   0   0    32  30000  0
  2   0   0    32  40000  0
  3   0   0    32  50000  0
  4   0   0    32  60000  0
  0   5   0    16  80000  2
  5   0   0    16  88000  2
  5   1   0    32  D0000  2
  5   2   0    32  C0000  2
  5   3   0    16  90000  2

Ok, and what happens if you then do more successive power cycles with this configuration?
Doesn't it swing again between the bad and good memory maps? Check MEM after each power cycle.

J-F

[Sylvain Cote]

(10-11-2021 06:49 PM)J-F Garnier Wrote:  Ok, and what happens if you then do more successive power cycles with this configuration?
Doesn't it swing again between the bad and good memory maps? Check MEM after each power cycle.

Good thinking!

MULTIMOD with one external 32KB RAM memory module

Code:

loop
  power on → normal
  MEM → 49523 (empty machine)
  power off
end-loop

MULTIMOD with two external 32KB RAM memory module

Code:

loop
  power on → normal
  MEM → 82286 (empty machine)
  power off
end-loop

MULTIMOD with three external 32KB RAM memory module

Code:

power off
insert third external 32KB RAM memory module
power on → normal
MEM → 113543   (with MEMBUF)
power off
power on → memory lost
MEM → 115049   (without MEMBUF)
power off

Code:

loop
  power on → normal
  MEM → 98665
  power off
  power on → normal
  MEM → 115049
  power off
end-loop

MULTIMOD with four external 32KB RAM memory module

Code:

power off
insert fourth external 32KB RAM memory module
loop
  power on → normal
  MEM → 147810
  power off
end-loop

Retest: MULTIMOD with three external 32KB RAM memory module

Code:

power off
removed all modules
power on → normal
INIT 3
power off
insert three modules

Code:

loop
  power on → normal
  MEM → 65897
  power off
  power on → normal
  MEM → 115049
  power off
end-loop

re-retest: three external 32KB RAM memory module, no MULTIMOD

Code:

power off
removed MULTIMOD
loop
  power on → normal
  MEM → 115189
  power off
end-loop

reˆn test: MULTIMOD with three external 32KB RAM memory module but with POKE "2C000","1"

Code:

power off
insert MULTIMOD (no battery, power jumper removed, insert module, add batteries, add jumper)
power on → normal
INIT 3
POKE "2C000","1"
power cycle
VER$ -> HP71:1BBBB FTH:1B EDT:A KBD:C STRU:A MATH:2B JPC:F05 HPIL:1B

Code:

loop
  power on → normal
  MEM → 115057
  power off
end-loop

edit 1: added the four modules test case, one modules test case and redid the three module test case. The three modules configuration seems to be problematic, the others configuration are stable.
edit 2: I have tried the modules in different physical ports and I get the same behavior.
edit 3: testing without MULTIMOD module.
edit 4: testing with MULTIMOD module but with POKE "2C000","1"

[J-F Garnier]

(10-11-2021 07:33 PM)Sylvain Cote Wrote:  MULTIMOD with three external 32KB RAM memory module

Code:

power off
insert third external 32KB RAM memory module
power on → normal
MEM → 113543   (with MEMBUF)
power off
power on → memory lost
MEM → 115049   (without MEMBUF)
power off

Code:

loop
  power on → normal
  MEM → 98665
  power off
  power on → normal
  MEM → 115049
  power off
end-loop

Ok, I may have the beginning of an explanation.
It seems to me that once the Multimod configures a 16K ROM at 80000, then this ROM is not correctly unconfigured at the next configuration, and interfere with the configuration that uses the absolute address 80000 for RAM/IRAM check..
After this incorrect configuration, the 16K ROM is no more at 80000 and next config will pass correctly (putting the 16K ROM again at 80000), the next one will fail again. And so forth.

A Multimod port becomes configured at 80000 if:
- it is a 16K ROM (32K ROM are configured from D0000 downward),
- addresses 3xxxx to 7xxxx are occupied by other MAIN RAM (or other 16K ROM).

Mark may confirm if there is a problem with port unconfiguration (RESET opcode).

J-F

[mfleming]

(10-11-2021 08:03 PM)J-F Garnier Wrote:  Ok, I may have the beginning of an explanation.
It seems to me that once the Multimod configures a 16K ROM at 80000, then this ROM is not correctly unconfigured at the next configuration, and interfere with the configuration that uses the absolute address 80000 for RAM/IRAM check..
After this incorrect configuration, the 16K ROM is no more at 80000 and next config will pass correctly (putting the 16K ROM again at 80000), the next one will fail again. And so forth.

A Multimod port becomes configured at 80000 if:
- it is a 16K ROM (32K ROM are configured from D0000 downward),
- addresses 3xxxx to 7xxxx are occupied by other MAIN RAM (or other 16K ROM).

Mark may confirm if there is a problem with port unconfiguration (RESET opcode).

J-F

Mapping of a 71B address to the PIC program flash memory occurs with the CONFIGURE bus command while Daisy-In is high. A mapping table is used, and a non-zero value in the table means the address is to a valid flash memory address. The table is cleared whenever the Daisy-In goes high so that no address is valid at the beginning of a configuration pass. However (wait for it) the table is not cleared by a RESETX command.

When does the RESETX command occur? If at the very beginning of the power on sequence, then MultiMod would map its ROMs to the address space last assigned to it until port 5 Daisy-In is raised. Since according to Dave Frederickson's link, RAM is configured before ROM, there would be a clash at power-up, but not during normal operation after MultiMod ROMs are assigned new addresses. Nice sleuthing work, even though I don't fully understand the failure mechanism. Is there another configuration pass following the FREE or CLAIM command?

Looks like a call to the initialize mapping table routine is needed for RESETX. Would it also be necessary to do the same with the UNCONFIG command? I've only seen that in the first configuration pass as some sort address decoding test.

~Mark

[rprosperi]

(10-11-2021 02:55 PM)Dave Frederickson Wrote:  

(10-11-2021 12:44 PM)Sylvain Cote Wrote:  mmm, ok, what happen when I remove module now ?

1. four RAM memory modules, all part of main RAM, MEM → 146303
2. power off, remove 32K RAM from port 4, power on, MEM → 113540
3. power off, remove 32K RAM from port 3, power on, Memory Lost , MEM → 82236
4. power off, remove 32K RAM from port 2, power on, MEM → 49523
5. power off, remove 32K RAM from port 1, power on, MEM → 16760
   

I have to go, but more test are needed on this last part.

Sylvain

You MUST FREEPORT a RAM module before removing it.

Not if there is nothing in the file chain stored in that memory block (e.g. memory that is 'higher' address than any used files) which is why removing Ports 4, 2 and 1 don't cause a crash.

This is pretty interesting but no time to experiment until the end of the week....

[Sylvain Cote]

(10-11-2021 10:41 PM)rprosperi Wrote:  

(10-11-2021 02:55 PM)Dave Frederickson Wrote:  You MUST FREEPORT a RAM module before removing it.

Not if there is nothing in the file chain stored in that memory block (e.g. memory that is 'higher' address than any used files) which is why removing Ports 4, 2 and 1 don't cause a crash.

Agreed!

[J-F Garnier]

(10-11-2021 09:26 PM)mfleming Wrote:  However (wait for it) the table is not cleared by a RESETX command.

Yeah, I was suspecting that :-)

Quote:Is there another configuration pass following the FREE or CLAIM command?

Each FREE/CLAIM command is followed by a configuration.

Quote:Looks like a call to the initialize mapping table routine is needed for RESETX. Would it also be necessary to do the same with the UNCONFIG command? I've only seen that in the first configuration pass as some sort address decoding test.

UNCONFIG is used for RAM, after checking the RAM/IRAM status, to move it from 80000 to 40000.
It is normally not used for ROM and can be ignored by ROM emulators. But if one day you do a RAM emulator, you will need to manage the UNCONFIG.
See also these comments.

J-F

[mfleming]

(10-12-2021 08:00 AM)J-F Garnier Wrote:  

(10-11-2021 09:26 PM)mfleming Wrote:  However (wait for it) the table is not cleared by a RESETX command.

Yeah, I was suspecting that :-)

Code updated.

(10-12-2021 08:00 AM)J-F Garnier Wrote:  

(10-11-2021 09:26 PM)mfleming Wrote:  Is there another configuration pass following the FREE or CLAIM command?

Each FREE/CLAIM command is followed by a configuration.

Always something new to learn about the 71B!

(10-12-2021 08:00 AM)J-F Garnier Wrote:  

(10-11-2021 09:26 PM)mfleming Wrote:  Looks like a call to the initialize mapping table routine is needed for RESETX. Would it also be necessary to do the same with the UNCONFIG command? I've only seen that in the first configuration pass as some sort address decoding test.

UNCONFIG is used for RAM, after checking the RAM/IRAM status, to move it from 80000 to 40000.
It is normally not used for ROM and can be ignored by ROM emulators. But if one day you do a RAM emulator, you will need to manage the UNCONFIG.
See also these comments.

J-F

I'll make a note of that in the appropriate code block since that RAM possibility will eventually occur

The github repository will be updated in a few days with source changes and hex files for programming. The bootloader client is Windows only, so I'll see if I can write a simple python script to erase and replace the application code.

~Mark

[mfleming]

(10-12-2021 08:00 AM)J-F Garnier Wrote:  

(10-11-2021 09:26 PM)mfleming Wrote:  However (wait for it) the table is not cleared by a RESETX command.

Yeah, I was suspecting that :-)

J-F

Oh my, I may have spoken too soon. Although the mapping table isn't cleared directly in the RESETX command handler, when finished control is transferred to the Initialize Device routine that does clear the mapping table. It also enters a spin-wait for Daisy-In to go high, so bus commands will be ignored until the MultiMod is configured. I'll confirm this behavior is valid or not with a logic analyzer on the bus.

I've nonetheless made the call to the clear mapping table routine in the RESETX handler. The change has been pushed to the repository and Hex files also updated.

A workaround for the moment is to not enumerate the second 16KB ROM (Ulib52) in the default MultiMod configuration. Do so by POKE "2C000","1" rather than using a "3" to enable all ROMs. That seemed to work for polbit. Sylvain, could you check if this is true for one of your Memory Lost scenarios?

~Mark

[Sylvain Cote]

MULTIMOD setup ...

• power on -> ok
• POKE "2C000","1"
• power cycle
• INIT 3
• OFF IO
• VER$ -> HP71:1BBBB FTH:1B EDT:A KBD:C STRU:A MATH:2B JPC:F05 HPIL:1B
• MEM -> 16770
• power off
  

Testing ...

• no front port memory modules
  • power on -> ok
  • MEM -> 16770
    
• +32KB -> 32KB RAM into port 1
  • power off
  • insert 32KB RAM into port 1
  • power on -> memory lost
  • OFF IO
  • power off
  • power on -> ok
  • MEM -> 49533
  • power off
  • remove 32KB RAM from port 1
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 1
  • power on -> ok
  • MEM -> 49533
    
• +32KB -> 32KB RAM into port 2
  • power off
  • remove 32KB RAM from port 1
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 2
  • power on -> ok
  • MEM -> 49533
    
• +32KB -> 32KB RAM into port 3
  • power off
  • remove 32KB RAM from port 2
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 3
  • power on -> ok
  • MEM -> 49533
    
• +32KB -> 32KB RAM into port 4
  • power off
  • remove 32KB RAM from port 3
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 4
  • power on -> ok
  • MEM -> 49533
    
• +64KB -> 32KB RAM into port 1 and 2
  • power off
  • remove 32KB RAM from port 3
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 1
  • insert 32KB RAM into port 2
  • power on -> ok
  • MEM -> 82296
    
• +64KB -> 32KB RAM into port 1 and 3
  • power off
  • remove 32KB RAM from port 2
  • power on -> ok
  • MEM -> 49533
  • power off
  • insert 32KB RAM into port 3
  • power on -> ok
  • MEM -> 82296
    
• +64KB -> 32KB RAM into port 1 and 4
  • power off
  • remove 32KB RAM from port 3
  • power on -> ok
  • MEM -> 49533
  • power off
  • insert 32KB RAM into port 4
  • power on -> ok
  • MEM -> 82296
    
• +64KB -> 32KB RAM into port 2 and 3
  • power off
  • remove 32KB RAM from port 4
  • power on -> ok
  • MEM -> 16770
  • power off
  • insert 32KB RAM into port 2
  • insert 32KB RAM into port 3
  • power on -> ok
  • MEM -> 82296
    
• +64KB -> 32KB RAM into port 2 and 4
  • power off
  • remove 32KB RAM from port 3
  • power on -> ok
  • MEM -> 49533
  • power off
  • insert 32KB RAM into port 4
  • power on -> ok
  • MEM -> 82296
    
• +64KB -> 32KB RAM into port 3 and 4
  • power off
  • remove 32KB RAM from port 2
  • power on -> ok
  • MEM -> 49533
  • power off
  • insert 32KB RAM into port 3
  • power on -> ok
  • MEM -> 82296
    
• +96KB -> 32KB RAM into port 1, 2 and 3
  • power off
  • remove 32KB RAM from port 4
  • insert 32KB RAM into port 1
  • insert 32KB RAM into port 2
  • power on -> ok
  • MEM -> 115059
    
• +96KB -> 32KB RAM into port 1, 2 and 4
  • power off
  • remove 32KB RAM from port 3
  • power on -> ok
  • MEM -> 82296
  • power off
  • insert 32KB RAM into port 4
  • power on -> ok
  • MEM -> 115059
    
• +96KB -> 32KB RAM into port 1, 3 and 4
  • power off
  • remove 32KB RAM from port 2
  • power on -> ok
  • MEM -> 82296
  • power off
  • insert 32KB RAM into port 3
  • power on -> ok
  • MEM -> 115059
    
• +96KB -> 32KB RAM into port 2, 3 and 4
  • power off
  • remove 32KB RAM from port 1
  • power on -> ok
  • MEM -> 82296
  • power off
  • insert 32KB RAM into port 2
  • power on -> ok
  • MEM -> 115059
    
• +128KB -> 32KB RAM into port 2, 3 and 4
  • power off
  • insert 32KB RAM into port 1
  • power on -> ok
  • MEM -> 147822
  • power off
    

Note: at each module insertion and removal, the cycle ON+MEM+OFF were done twice to see if memory was stable and with the memory lost exception who happened once, it was.

[mfleming]

(10-12-2021 05:17 PM)Sylvain Cote Wrote:  Note: at each module insertion and removal, the cycle ON+MEM+OFF were done twice to see if memory was stable and with the memory lost exception who happened once, it was.

Thanks for the test, I'll note this in some way for others who experience the same problem with stock configuration and application code.

Failure to remove the ROMs was the cause of the problem after all, just as J-F surmised. Turns out I failed to disable interrupts at the beginning of the RESETX handler. As a result, in the middle of RESETX processing, another command asserted on the bus caused control to be vectored to the command dispatch routine. And the band played on...

So by immediately disabling interrupts in the RESETX handler, RESETX code can finish. ROMs will be disabled and the MultiMod will go back to waiting for another configuration pass.

Timing is everything in this sort of control system!
~Mark