Threaded Mode | Linear Mode

Dave Frederickson · (This post was last modified: 05-07-2015 06:59 PM by Dave Frederickson.)

(05-07-2015 03:45 PM)Paul Berger (Canada) Wrote: The .MEM files as distributed are DOS text files ie the records are terminated with a CRLF sequence which is not compatible with the 71B's idea of a text file ...

The .MEM files are identical in format to the files produced by J-F Garnier's ROM dump program which can be found in the Emu71/Win manual and J-F's Emu71/DOS manual. These files conform to the TEXT Data File format described on p.247 of the 71 Owner's Manual which is why the READ command can be used.

To convert binary ROM images to the MEM format the ROM2DMP program in Christoph's FILETOOL package can be used which is how I converted the Diag ROM image. The line numbers will need to be stripped off.

Given that, the easiest way to load ROM's into the 71B is to ROMCOPY the binary images from a LIF disc or image. The HC ROM's will need to be loaded by Paul's program. Speed is also a factor. To load an ASCII image takes about 17 minutes for a 32k ROM or about 45 seconds to load the binary image using ROMCOPY.

Thanks to Paul for these excellent programs. The one for listing the memory buffers is especially useful.

Dave

Paul Berger (Canada) · 05-07-2015, 08:01 PM

(05-07-2015 06:32 PM)Dave Frederickson Wrote:
(05-07-2015 03:45 PM)Paul Berger (Canada) Wrote: The .MEM files as distributed are DOS text files ie the records are terminated with a CRLF sequence which is not compatible with the 71B's idea of a text file ...

The .MEM files are identical in format to the files produced by J-F Garnier's ROM dump program which can be found in the [url=http://hp.giesselink.com/Emu71

Dave

When I look at the MEM files, that came with the package of ROM images made available here recently, with a HEX editor on my PC I see that they are strings of 64 ASCII characters followed by 0x0d (CR) 0x0A (LF), when I create a TEXT file on a 71B, such as using transform to convert a BASIC program to TEXT the file it creates has variable length records each one starting with a byte of 00 followed by a 1 byte length and no CR LF at the end of a record. If you take the DOS text format file and copy it over without transforming it to LIF1 format, even if you get the correct file type set in the LIF directory, the READ command on the 71B is going to have a hard time understanding the file.

Code:

HEX Dump of of file in HP BASIC LIF1 text file format.

000000: 00 40 38 44 37 32 30 30 30 38 43 45 31 30 30 33  .@8D720008CE1003

000010: 43 34 45 30 38 36 46 30 31 38 34 46 30 46 33 38  C4E086F0184F0F38

000020: 38 37 46 36 46 30 32 30 33 32 30 38 34 38 38 34  87F6F02032084884

000030: 43 38 34 44 38 34 45 31 42 33 46 46 46 32 41 46  C84D84E1B3FFF2AF

000040: 32 33 00 40 30 41 31 35 43 44 38 30 38 46 30 34  23.@0A15CD808F04

000050: 32 30 33 46 38 30 30 31 34 30 30 32 32 30 30 34  203F800140022004

000060: 31 30 30 38 31 42 30 35 33 45 32 31 35 34 37 33  10081B053E215473

000070: 37 30 30 30 30 30 30 36 38 31 42 38 46 33 45 32  7000000681B8F3E2

000080: 31 35 43 37 00 40 41 46 32 31 35 45 35 39 37 41  15C7.@AF215E597A

000090: 39 30 41 46 32 31 35 43 35 33 32 30 30 31 41 46  90AF215C532001AF

0000a0: 35 33 32 30 30 38 38 30 31 39 46 31 36 34 41 46  5320088019F164AF

0000b0: 32 39 46 35 45 33 41 46 32 41 46 32 41 46 32 41  29F5E3AF2AF2AF2A

0000c0: 46 32 41 46 32 41 00 40 46 32 41 46 32 38 30 31  F2AF2A.@F2AF2801

0000d0: 41 37 45 35 30 32 41 46 32 41 46 32 41 46 32 41  A7E502AF2AF2AF2A

0000e0: 46 32 41 46 32 41 46 32 41 46 32 41 46 32 41 37  F2AF2AF2AF2AF2A7

0000f0: 44 35 31 42 41 46 32 38 30 31 41 37 36 36 33 32  D51BAF2801A76632

HEX Dump of of file in DOS text format. 

000000: 38 44 37 32 30 30 30 38 43 45 31 30 30 33 43 34 8D720008CE1003C4

000010: 45 30 38 36 46 30 31 38 34 46 30 46 33 38 38 37 E086F0184F0F3887

000020: 46 36 46 30 32 30 33 32 30 38 34 38 38 34 43 38 F6F02032084884C8

000030: 34 44 38 34 45 31 42 33 46 46 46 32 41 46 32 33 4D84E1B3FFF2AF23

000040: 0d 0a 30 41 31 35 43 44 38 30 38 46 30 34 32 30 ..0A15CD808F0420

000050: 33 46 38 30 30 31 34 30 30 32 32 30 30 34 31 30 3F80014002200410

000060: 30 38 31 42 30 35 33 45 32 31 35 34 37 33 37 30 081B053E21547370

000070: 30 30 30 30 30 36 38 31 42 38 46 33 45 32 31 35 00000681B8F3E215

000080: 43 37 0d 0a 41 46 32 31 35 45 35 39 37 41 39 30 C7..AF215E597A90

000090: 41 46 32 31 35 43 35 33 32 30 30 31 41 46 35 33 AF215C532001AF53

0000a0: 32 30 30 38 38 30 31 39 46 31 36 34 41 46 32 39 20088019F164AF29

0000b0: 46 35 45 33 41 46 32 41 46 32 41 46 32 41 46 32 F5E3AF2AF2AF2AF2

0000c0: 41 46 32 41 0d 0a 46 32 41 46 32 38 30 31 41 37 AF2A..F2AF2801A7

0000d0: 45 35 30 32 41 46 32 41 46 32 41 46 32 41 46 32 E502AF2AF2AF2AF2

0000e0: 41 46 32 41 46 32 41 46 32 41 46 32 41 37 44 35 AF2AF2AF2AF2A7D5

0000f0: 31 42 41 46 32 38 30 31 41 37 36 36 33 32 31 32 1BAF2801A7663212

Dave Frederickson · (This post was last modified: 05-07-2015 11:31 PM by Dave Frederickson.)

(05-07-2015 08:01 PM)Paul Berger (Canada) Wrote: When I look at the MEM files, that came with the package of ROM images made available here recently, with a HEX editor on my PC I see that they are strings of 64 ASCII characters followed by 0x0d (CR) 0x0A (LF), when I create a TEXT file on a 71B, such as using transform to convert a BASIC program to TEXT the file it creates has variable length records each one starting with a byte of 00 followed by a 1 byte length and no CR LF at the end of a record.

Per the previously referenced page in the 71 Owner's Manual, TEXT files "are formatted to be read by other Hewlett-Packard computers, such as the HP-75", which would imply they are LIF1.

(05-07-2015 08:01 PM)Paul Berger (Canada) Wrote: If you take the DOS text format file and copy it over without transforming it to LIF1 format, even if you get the correct file type set in the LIF directory, the READ command on the 71B is going to have a hard time understanding the file.

So don't do that. I use HPDir to copy DOS text files to/from LIF images with the -c option to perform the conversion. I also use HPDir to copy binary files to/from LIF images (see Post #2). You can experiment with this technique without a PIL-Box by using Emu71 and ILPer.

Dave

Paul Berger (Canada) · 05-07-2015, 09:55 PM

(05-07-2015 08:57 PM)Dave Frederickson Wrote: So don't do that. I use HPDir to copy DOS text files to/from LIF images with the -c option to perform the conversion. I also use HPDir to copy binary files to/from LIF images (see Post #2). You can experiment with this technique without a PIL-Box by using Emu71 and ILPer.

Dave

..and I don't as I mentioned in post #100 I use HP lifutil to convert the files from DOS text format to LIF1 and write them onto LIF format diskettes which suits me fine. In you post #101 you implied that the MEM / DMP files as distributed, conform to TEXT files as documented in the 71B manuals however the manual reference you quoted only mentions the existence of TEXT files and does not go into details about the layout of records in the file, but I know from my experience DOS text files are not the same 71B TEXT files and conversion is required. I determined what the difference is by my own investigation, largely by examining hex dumps of both file formats.

My point in stating " The .MEM files as distributed are DOS text files ie the records are terminated with a CRLF sequence which is not compatible with the 71B's idea of a text file ." is the MEM files that are in the ROM image package that I downloaded are all DOS format text files and there needs to be conversion done to make the files usable on a 71B.

Dave Frederickson · (This post was last modified: 05-07-2015 11:38 PM by Dave Frederickson.)

(05-07-2015 09:55 PM)Paul Berger (Canada) Wrote: ..and I don't as I mentioned in post #100 I use HP lifutil to convert the files from DOS text format to LIF1 and write them onto LIF format diskettes which suits me fine. In you post #101 you implied that the MEM / DMP files as distributed, conform to TEXT files as documented in the 71B manuals however the manual reference you quoted only mentions the existence of TEXT files and does not go into details about the layout of records in the file, but I know from my experience DOS text files are not the same 71B TEXT files and conversion is required.

Yeah, I misspoke. I think we agree that the MEM format files need to be converted to HP71 TEXT (LIF1) when they're copied to LIF media. If you think the files should be distributed in a different format, then I'd be interested in your suggestions.

Dave

Christoph Giesselink · 05-08-2015, 12:03 AM

(05-07-2015 11:30 PM)Dave Frederickson Wrote: I think we agree that the MEM format files need to be converted to HP71 TEXT (LIF1) when they're copied to LIF media.

I personally use a modified version of JFG's alifhdr to convert a DOS or UNIX style text file into a LIF1 text file with a 32byte LIF text file header ("alifhdr input_file LIF_file /T").

The resulting LIF_file then can be directly transferred with the ILDoslink device to a HP71 ("COPY :DOSLINK").

Dave Frederickson · (This post was last modified: 05-08-2015 02:23 AM by Dave Frederickson.)

(05-08-2015 12:03 AM)Christoph Giesselink Wrote:
(05-07-2015 11:30 PM)Dave Frederickson Wrote: I think we agree that the MEM format files need to be converted to HP71 TEXT (LIF1) when they're copied to LIF media.

I personally use a modified version of JFG's alifhdr to convert a DOS or UNIX style text file into a LIF1 text file with a 32byte LIF text file header ("alifhdr input_file LIF_file /T").

The resulting LIF_file then can be directly transferred with the ILDoslink device to a HP71 ("COPY :DOSLINK").

I prefer to not deal with files one at a time so I've updated the batch file from Post #2. It works as follows:

Binary ROM and EPROM images have the extension .bin. These files can be ROMCOPY'd from a LIF image into a 71 or mounted in Emu71.
Binary HC ROM files have the extension .rom. These may be mounted in Emu71 with their accompanying SC .bin file, but they will not be copied to the LIF image.
ASCII HC ROM files which need to be converted to LIF1 have the extension .mem
An empty 16Mb LIF image needs to be created. In this case it's named 16mb.lif
Put everything in an empty directory and execute the batch file. It requires a single arguement which is the name of the LIF image, i.e., HP71ROMS.lif.

Code:

@echo off

copy 16mb.lif %1 > nul

if exist *.bin copy *.bin *.#E21C > nul

echo.

FOR %%f IN (*.#E21C) DO (

    echo %%~nf :

    HPDir -add %1 %%f

    echo.

    IF %%~zf == 16384 HPDir -attrib -aux 800100800000 %1 %%~nf

    IF %%~zf == 32768 HPDir -attrib -aux 800100000100 %1 %%~nf

    IF %%~zf == 49152 HPDir -attrib -aux 800100800100 %1 %%~nf

    IF %%~zf == 65536 HPDir -attrib -aux 800100000200 %1 %%~nf

)

DEL *.#E21C

FOR %%f IN (*.mem) DO (

    echo %%~nf :

    copy %%f %%~nf.txt> nul

    HPDir -add -c %1 %%~nf.txt

    del %%~nf.txt

)

This creates a LIF image with all the binary ROM images, which can be loaded with ROMCOPY, and all the HC ROM images in 71B TEXT format.

Then all that's needed is to mount the one LIF image in ILPer. Like this: HP71ROMS.lif Here's the contents:

Code:

>CAT :2

   NAME    S TYPE   LEN    DATE    TIME 

JPCF01       ROM   32768 01/00/00 00:00 

SFTFORTH     ROM   65536 01/00/00 00:00 

JPCE01       ROM   49152 01/00/00 00:00 

JPCF03       ROM   32768 01/00/00 00:00 

JPCX         ROM   32768 01/00/00 00:00 

JPCD         ROM   32768 01/00/00 00:00 

JPCE1        ROM   32768 01/00/00 00:00 

FORTHROM     ROM   16384 01/00/00 00:00 

TRANS41      ROM   16384 01/00/00 00:00 

MATHROM      ROM   32768 01/00/00 00:00 

AMP04        ROM   65536 01/00/00 00:00 

AMP01        ROM   32768 01/00/00 00:00 

AMP02        ROM   65536 01/00/00 00:00 

AMP02A       ROM   65536 01/00/00 00:00 

AMP03        ROM   65536 01/00/00 00:00 

FIREB        ROM   49152 01/00/00 00:00 

CMT32KE      ROM   32768 01/00/00 00:00 

SUPRSURV     ROM   65536 01/00/00 00:00 

DATACOMM     ROM   16384 01/00/00 00:00 

SURVEY       ROM   16384 01/00/00 00:00 

DATAMGMT     ROM   32768 01/00/00 00:00 

HP71DEMO     ROM   16384 01/00/00 00:00 

ZENWAND      ROM   16384 01/00/00 00:00 

WB71         ROM   32768 01/00/00 00:00 

AMPISTAT     ROM   32768 01/00/00 00:00 

DATACQ       ROM   65536 01/00/00 00:00 

HPIL1B       ROM   16384 01/00/00 00:00 

CURVEFIT     ROM   32768 01/00/00 00:00 

TEXTEDIT     ROM   16384 01/00/00 00:00 

FINANCE      ROM   16384 01/00/00 00:00 

CIRCUIT      ROM   16384 01/00/00 00:00 

HPIL1A       ROM   16384 01/00/00 00:00 

HRDFTH41     TEXT  67840 01/00/00 00:00 

HRDFORTH     TEXT  67840 01/00/00 00:00 

SYS1BBBB     TEXT   135K 01/00/00 00:00 

DIAG71       TEXT   135K 01/00/00 00:00 

SYS2CDCC     TEXT   135K 01/00/00 00:00

Here are the file descriptions:

[Image: ROM%2BDescriptions%2B.jpg]

Thanks go to Sylvain and Bob for the ROM images. Special thanks to J-F Garnier for the Diag ROM image and many of the EPROM images.

Dave

charger73 · 05-08-2015, 05:55 AM

Dave, thank you for your effort in this and Hans, thank you this great product FRAM71.
And thanks all for this beautiful ROM's!!

Yesterday I was able to load the "HP41 Translator ROM" in my real HP71 with FRAM71. (To fill up
the $E0000 area is a little bit tricky..)

But, so much fun!!!

With my Arduino IL drive, it needs only 18 seconds to load a 32k ROM(!)
(with romcopy)

Best regards
Tobie

Dave Frederickson · 05-13-2015, 02:50 AM

I've updated Paul's MEMBUF program to display the memory type, like SHOW PORT.

Code:

10 REAL S1(15) @ S2=15 @ FOR S3=1 TO 15 @ S1(S3)=2^S2/4 @ S2=S2-1 @ NEXT S3 @ S1(15)=.5

15 DIM T$[255]

20 B1=HTD("2F9E6")

25 DISP "Port Dev Seq  Size Addr  Type"

30 B2=B1 @ B3=B1+5 @ I=0 @ K$="FF"

40 GOSUB 300

60 B2=B1+5+L @ B3=B2+5 @ I=1 @ K$="EF"

70 GOSUB 300

100 END 

300 IF PEEK$(DTH$(B2),2)<>K$ THEN 500

320 L$="" @ L$=PEEK$(DTH$(B3-1),1)&PEEK$(DTH$(B3-2),1)&PEEK$(DTH$(B3-3),1) @ L=HTD(L$)

330 T$=PEEK$(DTH$(B3),L)

340 FOR X=1 TO L/10

350 Z=(X-1)*10 @ Z2=Z+1 @ S$=T$[Z2,Z2] @ Z2=Z2+1 @ D$=T$[Z2,Z2] @ Z2=Z2+1 @ P$=T$[Z2,Z2]

360 Z2=Z2+1 @ S=S1(HTD(T$[Z2,Z2]))*(HTD(T$[Z+9,Z+9])+1)

370 A$=T$[Z+7,Z+7]&T$[Z+6,Z+6]&T$[Z+5,Z+5]&"00"

375 T=VAL(T$[Z+8,Z+8])+I

380 DISP USING "AA,aaAA,aaaa,aaAA,3D,aa,7A,D";" ",P$,D$,S$,S,"  ",A$,T

390 NEXT X

400 RETURN 

499 END 

500 DISP "Problem with memory config buffer"

510 END

Port Dev Seq  Size Addr  Type

  0   0   0     4  30000  0

  0   1   0     4  32000  0

  0   2   0     4  34000  0

  0   3   0     4  36000  0

  0   5   0    16  F0000  2

  1   0   0    32  E0000  1

  2   0   0    32  D0000  1

Dave

Hans Brueggemann · 05-16-2015, 04:02 PM

All,
find the newest firmware V502 and the updated FRAM71 User's Manual in post #1 of this thread.

Hans

Dave Frederickson · (This post was last modified: 05-16-2015 05:22 PM by Dave Frederickson.)

(05-16-2015 04:02 PM)Hans Brueggemann Wrote: All,
find the newest firmware V502 and the updated FRAM71 User's Manual in post #1 of this thread.

Hans

Thanks, Hans.

In an email you stated, "There is no longer the restriction to have Chip_0 assigned to F_Block3 when configuring it to E0000. Chip_0 may now be configured to any F_Block0…F." The manual still poses a restriction.

Could you give us a brief update on the project's status?

Number of units in the field
Plans for another production run
Future firmware/hardware updates
When will the design files be released? Some of us are interested in 3D-printing custom bezels.

Dave

Hans Brueggemann · (This post was last modified: 05-16-2015 07:54 PM by Hans Brueggemann.)

ow. good catch. manual changed accordingly by yours truly, see post #1.

it requires at least 30 or more seriously(!) interested pre-orders to economically justify another production run. so, there are no plans to do that until there are enough people banging at my door.

one more firmware spin is in planning to add a feature that i personally would really like to have on my FRAM71. however, i want to analyze the feasibility first before i disclose anything about that V600.

i'm not planning to do a hardware re-spin, as this would imply a somehow evolutionary step in terms of new features and consequently require specialized driver-support on the HP-71B side of things. take as an example the (still) experimental UART in FRAM71, where the response to my support request for writing a suitable driver in assembly was zilch- so, my understanding from that response (or the lack thereof) is that the assembly language legacy for a vintage platform like the HP-71B is practically no longer existent and hence renders such project ideas basically stillborn, imho.

as for the design files, let me meditate a little longer about this. i have a bit of a hard time (call me sentimental, if you wish) to "simply let go" the fruits of 5 years effort that brought quite an amount of b,s&t besides the obvious(!) fun.
so, bear with me for now.

hans

Dave Frederickson · 05-16-2015, 09:08 PM

(05-16-2015 07:23 PM)Hans Brueggemann Wrote: as for the design files, let me meditate a little longer about this. i have a bit of a hard time (call me sentimental, if you wish) to "simply let go" the fruits of 5 years effort that brought quite an amount of b,s&t besides the obvious(!) fun.
so, bear with me for now.

I can appreciate that. I'm really only interested in the STL file for the bezel.

Thanks,
Dave

Guenter Schink · 05-16-2015, 09:16 PM

(05-16-2015 07:23 PM)Hans Brueggemann Wrote: it requires at least 30 or more seriously(!) interested pre-orders to economically justify another production run. so, there are no plans to do that until there are enough people banging at my door.
hans

I'm seriously interested, and I hope enough people will join the queue. What's necessary to make you feel confident?

Günter

Mark Hardman · 05-16-2015, 10:00 PM

(05-16-2015 07:23 PM)Hans Brueggemann Wrote: it requires at least 30 or more seriously(!) interested pre-orders to economically justify another production run. so, there are no plans to do that until there are enough people banging at my door.
hans

Me too!

Seriously interested email sent.

Oulan · (This post was last modified: 06-03-2015 03:22 PM by Oulan.)

I just installed my FRAM71 module, seems to works great (at least I can use MATHROM, JPC ... I had a bare memory HP71 but with HPIL)

I just have some problem with it

I romcopied MATHROM, JPCF03 and CURVEFIT in F-blocks D, E and F.

I configured FRAM71 with
POKE "2C000", "131415961718199AABDFDEDD00000000"

So I could do FREE PORT(5) to have an IRAM of 128K (it is shown in SHOW PORT), MEM(5) gives 131067

But when I try COPY PROG TO PROG:PORT(5) it result with
ERR: Insufficient memory even with a 200 bytes program.

(if I configure the IRAM at 96K it is the same, if I freed 5.01 it is the same also)

I have a 1BBBB ver system, FRAM is with 502 firmware

I can not manage to diagnose if it is an F-RAM problem or something else ... (perhaps a misunderstanding of the manual)

No freed ports :

Code:

>RUN FDIR

System RAM

Port Dev Seq Size Addr

  0   0   0     4  B8000

  0   1   0     4  BA000

  0   2   0     4  BC000

  0   3   0     4  BE000

  5   0   0   128  30000

  5   1   0   128  70000

  5   2   0    16  B0000

Misc Memory

Port Dev Seq Size Addr

  0   5   0    16  F0000

  5   3   0    32  E0000

  5   4   0    32  D0000

  5   5   0    32  C0000

>SHOWPORT

0.05  16384  2

5.03  32768  2

5.04  32768  2

5.05  32768  2

>MEM

 293588.0000

With FREE PORT(5)

Code:

>RUN FDIR

System RAM

Port Dev Seq Size Addr

  0   0   0     4  78000

  0   1   0     4  7A000

  0   2   0     4  7C000

  0   3   0     4  7E000

  5   1   0   128  30000

  5   2   0    16  70000

Misc Memory

Port Dev Seq Size Addr

  0   5   0    16  80000

  5   0   0   128  C0000

  5   3   0    32  B0000

  5   4   0    32  A0000

  5   5   0    32  90000

>SHOWPORT

0.05  16384  2

5    131072  1

5.03  32768  2

5.04  32768  2

5.05  32768  2

>MEM

 162510.0000 

>MEM(5)

 131067.0000 

>COPY FDIR TO FDIR:PORT(5)

ERR:Insufficient Memory

All seem correct :

5.00 is a 4x32KB ram module (F-blocks 3, 4, 5, 6 : 13141596 )

5.01 is a 4x32KB ram module (F-blocks 7, 8, 9, A : 1718199A)

5.02 is a 1x16KB ram module (F-block B : AB)

5.03 is a 1x32KB rom module (F-block F : DF MATHROM)

5.04 is a 1x32KB rom module (F-block E : DE JPCF03)

5.05 is a 1x32KB rom module (F-block D : DD CURVFIT)

0.05 is the HPIL module rom

0.00 to 0.03 is the internal RAM

>DCATALL

workfile   BASIC     0 01/01/00 00:00

FDIR       BASIC   598 01/01/00 00:00

HPILROM    LEX   16361 09/12/83 12:00 0.05

MATHROM  E LEX   32745 11/01/83 12:00 5.03

JPCF03     LEX   25972 12/27/14 18:31 5.04

ML         BASIC    55 12/27/14 18:31 5.04

CurveFit   LEX      41 01/12/84 12:00 5.05

CFIT       BASIC 14219 01/12/84 12:00 5.05

OPTIMIZE   BASIC  5068 01/12/84 12:00 5.05

MODELS     BASIC  5789 01/12/84 12:00 5.05

PCENTCHI   BASIC   727 01/12/84 12:00 5.05

FITLEX     LEX     415 01/12/84 12:00 5.05

FITLIB     BIN    5545 01/12/84 12:00 5.05

CFKEYZ     KEY      83 01/12/84 12:00 5.05

I used the program from Paul.

Oulan · (This post was last modified: 06-03-2015 05:22 PM by Oulan.)

By using

Code:

>POKE"2C000","DFDEDD131415961718199AAB00000000"

>

>RUNFDIR

System RAM

Port Dev Seq Size Addr

  0   0   0     4  78000

  0   1   0     4  7A000

  0   2   0     4  7C000

  0   3   0     4  7E000

  5   4   0   128  30000

  5   5   0    16  70000

Misc Memory

Port Dev Seq Size Addr

  0   5   0    16  F0000

  5   0   0    32  E0000

  5   1   0    32  D0000

  5   2   0    32  C0000

  5   3   0   128  80000

>MEM

 162838 

>MEM(5)

 0 

>MEM(5.03)

 131067 

>COPY FDIR TO FDIR:PORT(5.03)

>CAT:PORT(5.03)

  NAME   S TYPE   LEN    DATE    TIME PORT

FDIR       BASIC   598 01/01/00 00:01 5.03

It works !!! I just changed the order of the iram vs roms
for port 5.00 to port 5.03 and now it works

The base address of the iram also changed from C0000 to 80000 so it avoid the E0000-FFFFF part which can be peculiar

Quite strange ...

I wanted to have an iram called PORT(5), better than PORT(5.03) but it seems impossible.

After more test I only succeed with : DFDEDD131495161718199AAB000000 this one use the full address space (hpil at 0xF0000)

Code:

System RAM

Port Dev Seq Size Addr

  0   0   0     4  88000

  0   1   0     4  8A000

  0   2   0     4  8C000

  0   3   0     4  8E000

  5   4   0   160  30000

  5   5   0    16  80000

Misc Memory

Port Dev Seq Size Addr

  0   5   0    16  F0000

  5   0   0    32  E0000

  5   1   0    32  D0000

  5   2   0    32  C0000

  5   3   0    96  90000

>PEEK$("2C000",32)

DFDEDD131495161718199AAB00000000

Hans Brueggemann · (This post was last modified: 06-04-2015 03:07 PM by Hans Brueggemann.)

congrats, olivier!
seems that after some extensive tinkering with the configuration options you finally managed to generate what i would call an "IRAM zombie": neither CLAIM PORT nor CN2:2 and MEMORY LOST brings back the FREED memory, nor is it possible to COPY anything to the affected PORT.
good news is that i could replicate the symptoms on my test rig and probably have already found the root cause. need some more time for testing before i'll be posting a V510 update.
(note that this bug only affects V5.0x firmware versions)

hans

Dave Frederickson · 06-04-2015, 03:40 PM

(06-04-2015 03:05 PM)Hans Brueggemann Wrote: (note that this bug only affects V5.0x firmware versions)

So it would be possible to recover the FREED memory by installing V430 firmware?

Hans Brueggemann · (This post was last modified: 06-04-2015 04:23 PM by Hans Brueggemann.)

on V430, with olivier's example:

(06-03-2015 02:10 PM)Oulan Wrote: I configured FRAM71 with
POKE "2C000", "131415961718199AABDFDEDD00000000"
So I could do FREE PORT(5) to have an IRAM of 128K (it is shown in SHOW PORT), MEM(5) gives 131067

gives the same memory value for PORT(5), and COPY PROGRAM TO :PORT(5) works as expected.

note that V430 has internally the same bug as V50x. it is due to a different handling of ID-responses and latching the address masks, that the bug will not show directly on V430. i suggest to wait for the V510 update, rather than going back to V430.

hans