[FRAM71] Pre-Production Batch

[Dave Frederickson]

(02-10-2015 05:44 PM)Hans Brueggemann Wrote:  c. FRAM71 does not use the internal FPGA-RAM for a simple reason: that RAM is volatile and hence would screw FRAM71's memory configuration as soon as your HP-71B loses power

According to the IGLOO nano data sheet, all versions of the FPGA contain 1kbit of FlashROM User Nonvolatile Memory. It should be possible to map the few registers in the 0x20000 segment into the FPGA. That would give us another 32k block.

Regarding the 0x00000-0x1FFFF reserved block. Presently, those nibbles in the configuration string are set to zero, but why couldn't they be configured the same way as the Chips? If the config nibbles are zero then the memory get treated as SYSRAM and if non-zero then it gets treated as Chips.

Edit: Okay, I see that the FlashROM is only programmable via JTAG.

Dave

[rprosperi]

(02-10-2015 05:44 PM)Hans Brueggemann Wrote:  what i hear though is a request of having the FRAM memory chips readied with ROM images "behind the curtains" and then pick an appropriate set by setting the respective bits in the configuration area. is that correct? would that feature justify to kick out UART- and REDEYE- support?

thanks for your great input, guys!
hans

Thanks for clarifying the FRAM structure and allocation process.

For me, yes, having additional ROM/IRAM images that can be mapped-in/out of currently accessible address space is of interest. Also, for me, these outweigh the UART and REDEYE support.

Thanks for asking and collecting input to improve FRAM71.

[Hans Brueggemann]

bob, that is what i had hoped for, because i need the extra bytes in the configuration area...
V430 is hiding now on my hard disk, REDEYE and UART abandoned, but having access to 15 out of 16 32kB blocks. no, it's not ready for release, though ;o)
instead of having one nibble per chip in the 2C000 area, each chip now has one configuration byte.
in V420,
having at 2C000 the 4 nibbles "9999" meant "4 Memory modules, 32k each, living at HP-71B's address range 30000-6FFFF", whereas at the same time the FRAM base addresses were fixed at 30000, 40000, 50000, 60000, respectively.
in V430 however,
you would instead program at 2C000 the value "9a9b9c9d", where a,b,c,d are constants in the range of "0".."F" (except "2", that is) that program the FRAM's base addresses in 32k steps. hence, programming "93949C9A" into 2C000 would still deliver 4 memory modules at the same address range in HP-71's world, but would actually use the internal FRAM-blocks at 30000, 40000, C0000, A0000. and by changing the constants only, you can now map different FRAM contents into the same HP-71B address range.
(big caveat: though the above example shows RAM modules, you would do this with ROMs only in order to keep the file chain intact.)

hans,
awaiting more votes on the "drop REDEYE, UART" case

[Dave Frederickson]

(02-11-2015 06:42 PM)Hans Brueggemann Wrote:  awaiting more votes on the "drop REDEYE, UART" case

I vote to drop REDEYE and UART support.

[Michael Fehlhammer]

I am fine with HP-IL for accomplishing all kind of I/O, so I second Bob and Dave:
Drop REDEYE/UART, in favor of having additional ROM pages.

[cruff]

(02-11-2015 09:58 PM)Michael Fehlhammer Wrote:  I am fine with HP-IL for accomplishing all kind of I/O, ...

I agree also. I'm looking forward to getting one!

[anetzer]

(02-11-2015 02:04 PM)rprosperi Wrote:  For me, yes, having additional ROM/IRAM images that can be mapped-in/out of currently accessible address space is of interest. Also, for me, these outweigh the UART and REDEYE support.

+1!

Though I do not see why UART is mandatory exclusive to pre-stored images...

Redeye can easily be dropped.

Thanks!

a.

[Dave Frederickson]

(02-12-2015 12:53 AM)anetzer Wrote:  Though I do not see why UART is mandatory exclusive to pre-stored images...

Bit 3 in register CTL_1 turns the oscillator on or off to reduce power consumption. That bit needs to be in non-volatile memory. It has nothing to do with pre-stored images. It's whether that memory is available for RAM/ROM or UART/REDEYE registers.

[Paul Berger (Canada)]

(02-11-2015 06:42 PM)Hans Brueggemann Wrote:  awaiting more votes on the "drop REDEYE, UART" case

I would also vote for dropping redeye and uart support since I never did get around to implementing it on my FRAM

Paul.

[Sylvain Cote]

Like everyone else, I agree to drop REDEYE and UART support.
Sylvain

[Marcus von Cube]

(02-12-2015 04:04 AM)Sylvain Cote Wrote:  Like everyone else, I agree to drop REDEYE and UART support.
Sylvain

Let's go for it. UART would only be useful as an alternative to HPIL. I guess most of the prospective FRAM owners do own an HPIL module.

In a future development the FRAM71 II might add a USB port that acts the same as a PIL box for a straight forward connection to a PC but that's just dreaming...

[Dave Frederickson]

(02-12-2015 04:59 PM)Marcus von Cube Wrote:  In a future development the FRAM71 II might add a USB port that acts the same as a PIL box for a straight forward connection to a PC but that's just dreaming...

Would that not limit the physical devices on the loop to just the 71B?

[Marcus von Cube]

(02-12-2015 05:10 PM)Dave Frederickson Wrote:  Would that not limit the physical devices on the loop to just the 71B?

Yes, but for a quick connection to the PC this is preferable.

[Dave Frederickson]

There appear to be a couple of issues with the v430 beta.

1. There's no error checking to prevent Base Address 0x20000 from being configured as RAM.
2. If memory is configured to the maximum of 384k, with HP-IL, and there are several devices and an attempt is made to FREEPORT a device then WRN:Configuration is displayed. Configuring memory to less than 384k circumvents the issue.
   

I'm still testing.

[Hans Brueggemann]

(02-16-2015 06:09 AM)Dave Frederickson Wrote:  There's no error checking to prevent Base Address 0x20000 from being configured as RAM.

confirmed, the FRAM range 0x20000 to 0x2FFFF is not protected against bankswitching use. unfortunately, FRAM71 can't do that, so user has to be aware of that when selecting FRAM ranges for bankswitching.

(02-16-2015 06:09 AM)Dave Frederickson Wrote:  If memory is configured to the maximum of 384k, with HP-IL, and there are several devices and an attempt is made to FREEPORT a device then WRN:Configuration is displayed. Configuring memory to less than 384k circumvents the issue.

can you give me the exact configuration string that you used for testing that? is it a 1BBB or a 2CDCC mainframe?

hans

[Dave Frederickson]

(02-16-2015 05:40 PM)Hans Brueggemann Wrote:  

(02-16-2015 06:09 AM)Dave Frederickson Wrote:  If memory is configured to the maximum of 384k, with HP-IL, and there are several devices and an attempt is made to FREEPORT a device then WRN:Configuration is displayed. Configuring memory to less than 384k circumvents the issue.

can you give me the exact configuration string that you used for testing that? is it a 1BBB or a 2CDCC mainframe?

It's a 2CDCC machine, HP-IL installed, and the config string is "93A4 9697 9819 1A1B 1C1D 1E9F 0000 0000". This issue exists in v420 as well.

Dave

[Hans Brueggemann]

here's what i get on a 1BBBB plus HP-IL:1A
with "93A4 9697 9819 1A1B 1C1D 1E9F 0000 0000" (=32+16+32+32+32+[7*32]+16=384k),
1) MEM after MEMORY LOST: 393738
2) after FREEPORT(5.05): 164347
3) after FREEPORT(5.04): 131561
4) after FREEPORT(5.03): 98778
5) after FREEPORT(5.02): 66010
6) after FREEPORT(5.01): WRN:Configuration, 49631
7) CLAIMPORT(5.01) : Device not found, 49618 (oops... if 5.01 isn't existing, who ate the 16k between steps 5 and 6?
8) CLAIMPORT(5.02) : WRN:Configuration, 82385 (again, we are 16k short of the expected 98778)
9) SHOWPORT : 5.05 229376 1
10) OFF/ON : WRN:Configuration, 82391

re-claiming all ports doesn't remedy the WRN: Configuration message. also, after a MEMORY LOST there are now 16k missing when doing MEM.
this is the case when the HP-71B fails to properly re-CLAIMPORT(x.xx), or when a hidden memory block that was formerly FREEPORTed, but never CLAIMPORTed, gets revived with a new configuration. using jumper CN2:2 in conjunction with an [ON]/[/],3 and then removing CN2:2 followed by [OFF], [ON] brings back formerly FREEPORTed memory blocks.
can't see a fault in FRAM71 handling the memory blocks, though.

hans

[Dave Frederickson]

(02-16-2015 08:06 PM)Hans Brueggemann Wrote:  here's what i get on a 1BBBB plus HP-IL:1A
with "93A4 9697 9819 1A1B 1C1D 1E9F 0000 0000" (=32+16+32+32+32+[7*32]+16=384k),
1) MEM after MEMORY LOST: 393738
2) after FREEPORT(5.05): 164347
3) after FREEPORT(5.04): 131561
4) after FREEPORT(5.03): 98778
5) after FREEPORT(5.02): 66010
6) after FREEPORT(5.01): WRN:Configuration, 49631
7) CLAIMPORT(5.01) : Device not found, 49618 (oops... if 5.01 isn't existing, who ate the 16k between steps 5 and 6?
8) CLAIMPORT(5.02) : WRN:Configuration, 82385 (again, we are 16k short of the expected 98778)
9) SHOWPORT : 5.05 229376 1
10) OFF/ON : WRN:Configuration, 82391

re-claiming all ports doesn't remedy the WRN: Configuration message. also, after a MEMORY LOST there are now 16k missing when doing MEM.
this is the case when the HP-71B fails to properly re-CLAIMPORT(x.xx), or when a hidden memory block that was formerly FREEPORTed, but never CLAIMPORTed, gets revived with a new configuration. using jumper CN2:2 in conjunction with an [ON]/[/],3 and then removing CN2:2 followed by [OFF], [ON] brings back formerly FREEPORTed memory blocks.
can't see a fault in FRAM71 handling the memory blocks, though.

I confirm 393738 bytes after Memory Lost. The Configuration Warning occurs even if port 5.01 is the first one FREEPORTed. This isn't the behavior I expected. Why can ports 5.02-5.04 be FREEPORTed without a warning, yet 5.01 always causes a warning? Is it an issue with Base Address 0x40000?

EDIT:
I tried to mix it up using config string "9314 1516 1718 191A AB9C 9D9E 0000 0000" after resetting
which yielded 384k, however, in this configuration:

Code:

>SHOWPORT
0.05  16384  2
0      4096  0
0.01   4096  0
0.02   4096  0
0.03   4096  0
5     32768  0
5.01 229376  0
5.01  16384  0
5.02  32768  0
5.03  32768  0
5.04  32768  0

Something doesn't look right with Port 5.01.

Dave

[Dave Frederickson]

According to EduCALC Technical Note #4 the HP-IL module often configures the system as 32k for HP-IL. We've been using 16k.

Can someone explain how this works?

I think the max memory with HP-IL might need to be revised to 368k.

Dave

[Hans Brueggemann]

the HP-IL module is a single, soft-configurable 16 kByte ROM. it is reported as 32 kNibble by the Diagnostic module, though. that's probably the reason for the confusion. as for the memory limit being lower on a machine that uses FREEPORTed memory, i can only speculate at the moment that the HP-71B's configuration routine screws something when trying to manage the FREEPORTed memory.

hans