CMT 64Kb RAM module for HP-71b question
|
10-11-2021, 03:24 PM
Post: #21
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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. |
|||
10-11-2021, 06:49 PM
(This post was last modified: 10-11-2021 06:53 PM by J-F Garnier.)
Post: #22
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(10-11-2021 12:44 PM)Sylvain Cote Wrote: I also did this test: 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 |
|||
10-11-2021, 07:33 PM
(This post was last modified: 10-11-2021 08:06 PM by Sylvain Cote.)
Post: #23
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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?Good thinking! MULTIMOD with one external 32KB RAM memory module Code: loop MULTIMOD with two external 32KB RAM memory module Code: loop MULTIMOD with three external 32KB RAM memory module Code: power off Code: loop MULTIMOD with four external 32KB RAM memory module Code: power off Retest: MULTIMOD with three external 32KB RAM memory module Code: power off Code: loop re-retest: three external 32KB RAM memory module, no MULTIMOD Code: power off reˆn test: MULTIMOD with three external 32KB RAM memory module but with POKE "2C000","1" Code: power off Code: 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" |
|||
10-11-2021, 08:03 PM
Post: #24
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(10-11-2021 07:33 PM)Sylvain Cote Wrote: MULTIMOD with three external 32KB RAM memory module 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 |
|||
10-11-2021, 09:26 PM
Post: #25
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(10-11-2021 08:03 PM)J-F Garnier Wrote: Ok, I may have the beginning of an explanation. 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 Remember kids, "In a democracy, you get the government you deserve." |
|||
10-11-2021, 10:41 PM
Post: #26
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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 ? 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.... --Bob Prosperi |
|||
10-11-2021, 11:18 PM
Post: #27
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(10-11-2021 10:41 PM)rprosperi Wrote:Agreed!(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. |
|||
10-12-2021, 08:00 AM
Post: #28
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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 |
|||
10-12-2021, 11:57 AM
Post: #29
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(10-12-2021 08:00 AM)J-F Garnier Wrote:Code updated.(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 :-) (10-12-2021 08:00 AM)J-F Garnier Wrote:Always something new to learn about the 71B!(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. (10-12-2021 08:00 AM)J-F Garnier Wrote:I'll make a note of that in the appropriate code block since that RAM possibility will eventually occur(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. 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 Remember kids, "In a democracy, you get the government you deserve." |
|||
10-12-2021, 03:52 PM
Post: #30
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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 :-) 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 Remember kids, "In a democracy, you get the government you deserve." |
|||
10-12-2021, 05:17 PM
(This post was last modified: 10-12-2021 05:23 PM by Sylvain Cote.)
Post: #31
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
MULTIMOD setup ...
Testing ...
|
|||
10-12-2021, 07:48 PM
Post: #32
|
|||
|
|||
RE: CMT 64Kb RAM module for HP-71b question
(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 Remember kids, "In a democracy, you get the government you deserve." |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: