FRAM71B

[rprosperi]

(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

I think the issue could be where your 64KB block is located. Although you declare that 64KB FRAM F_Block near the end of your config string, the '71 initialize routine (in the OS) allocates larger memory blocks in lower addresses, regardless of which port they are physically (or in the case of FRAM logically) located.

Most likely, the init routine configured your RAM blocks in this order:

1. Main RAM (5.00)
2. 64KB Block (to hold the image, after converting to IRAM) (5.01)
3. Other 32KB blocks for holding other images. (5.02, 5.03, etc.)

The easiest way to check this is with the MEMBUF program and SHOW PORT commands. In fact for each new config you create, I suggest you run these 2 commands to see the actual memory map; it is not always what you expect it to be.

Run MEMBUF immediately after your initial start with the new config, then after you FREE the various PORTs, and it should be easy to track what is happening.

Also, re-read the article here for a detailed explanation of the memory configuration process.

[Erwin]

(11-01-2016 01:42 PM)rprosperi Wrote:  

(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

I think the issue could be where your 64KB block is located. Although you declare that 64KB FRAM F_Block near the end of your config string, the '71 initialize routine (in the OS) allocates larger memory blocks in lower addresses, regardless of which port they are physically (or in the case of FRAM logically) located.

Most likely, the init routine configured your RAM blocks in this order:

1. Main RAM (5.00)
2. 64KB Block (to hold the image, after converting to IRAM) (5.01)
3. Other 32KB blocks for holding other images. (5.02, 5.03, etc.)

The easiest way to check this is with the MEMBUF program and SHOW PORT commands. In fact for each new config you create, I suggest you run these 2 commands to see the actual memory map; it is not always what you expect it to be.

Run MEMBUF immediately after your initial start with the new config, then after you FREE the various PORTs, and it should be easy to track what is happening.

Also, re-read the article here for a detailed explanation of the memory configuration process.

Hi,

thank you, I see it in the end of the article so I have to take care to put the larger ROMs first. I understand that the smaller ROMs at the end are not a problem for the system, the 64KB is to big. I'll give this a try next weekend and change the whole configuration and give here feedback about this ...

Thanks Erwin

[Dave Frederickson]

(11-01-2016 10:48 AM)Erwin Wrote:  When I initialize the PORT 5.05 with 64KB (POKE "2C012"; "109100") ... my last module it is not configured as IRAM when i do the FREE PORT without an error. The SHOWPORT shows type "0" instead of "1", and I couldn't ROMCOPY (error: Device Not Found) So I configured it as ROM (POKE "2C012"; "50D100") and tried the ROMCOPY but with the "verify" error.

This was described in 3. in this post:
http://hpmuseum.org/forum/thread-6287-po...l#pid62269

Understand that ROM's and IRAM's get configured after RAM. When you FREEPORT a module it moves within the address space from RAM to a higher address with the other ROM's and IRAM's. In some max RAM configurations this will cause a configuration warning just like configuring more RAM than can be addressed.

Configuring the module as ROM will, by definition, prevent it from being written.

(11-01-2016 02:14 PM)Erwin Wrote:  ... I see it in the end of the article so I have to take care to put the larger ROMs first.

That's not necessary. The 71's configuration routine takes care of that.


That said, I had no issues configuring FRAM71B as above.

Code:

>PEEK$("2C000",32)
D3E4D5D69718191A9B50D10000000000
>RUN MEMBUF
Port Dev Seq  Size Addr  Type
  0   0   0     4  70000  0  BUILT-IN RAM
  0   1   0     4  72000  0  BUILT-IN RAM
  0   2   0     4  74000  0  BUILT-IN RAM
  0   3   0     4  76000  0  BUILT-IN RAM
  5   4   0   128  30000  0  MAIN RAM
  0   5   0    16  80000  2  HPILROM
  5   0   0    16  88000  2  FTH41 ROM
  5   1   0    32  D0000  2  MATHROM
  5   2   0    32  C0000  2  JPC ROM
  5   3   0    32  B0000  1  FRAM71 TK
  5   5   0    64  90000  2  DATACQ ROM
>

Dave

[physill]

I hope this is the right place to post this question. If not let me know. Thanks.

I am unable to get around an Invalid Arg error in line 120 of SERTOSYS as shown on page 23 of the FRAM71B manual. I am using a PilBox (with the PIL-Box Bridge, ILPer and Video Interface) to attempt to load the file HP-71B_OS2CDCC_ROM.BIN to the FRAM71B to allow use of the 2cdcc operating system. Communication between the HP-71B hardware and the virtual components is working.

10 ! SERTOSYS SERIAL TO SYS
20 DIM A$[64]
30 INPUT "SYSWRT ENABLED? Y/N";V$ @ IF V$="N" THEN GOTO 20
40 DISP "START *.DMP UPLOAD"
50 S$="00000"
60 E$="1FFFF"
70 S=HTD(S$)
80 E=HTD(E$)
90 FOR I=S TO E STEP 64
100 ENTER :2 ;A$ @ IF I=S+64 THEN DISP "WRITING..." !:2 = 82164A Note that I am using ENTER :4 for the HDRIVE1.DAT file on ILPER
110 I$=DTH$(I)
120 POKE I$,A$
130 ! PRINT I$;": ";A$
140 NEXT I
150 DISP "DONE" @ BEEP
160 END

HP-71B_OS2CDCC_ROM.BIN is a file from one of the many pages I have obtained HP71 info from, perhaps a post on MoHPC. It was part of a link or ZIP file that contains the .BIN files for most if not all of the ROMs for the HP71b.

SERTOSYS uses variables I$ and A$ to contain a counter and the data read from the 2CDCC hex dump file, respectively.

The values that are put into the variables I$ and A$ on the first pass through the loop appear to be valid. Using the program HexEdit to view the contents of HP-71B_OS2CDCC_ROM.BIN and comparing to the value placed into variable A$ appears to show that the correct data is in the variable.

Line 120 POKE I$, A$: The HP-71b reference manual (error 11) implies that the correct data type is being used but lies outside the domain of definition of that function (POKE) The HP-IL manual (error 255056) implies that the error message is due to either the argument being out of the allowable range or the argument has a Directory Entry or Length that is improper. I am not really sure what is going on.

I do not have much experience with file operations on the HP71b and have never actually used any HP-IL peripheral hardware which may have educated me on how files are actually manipulated on the hardware.

I would appreciate any help that can be offered. I have not had any issues with the SERTORAM program on page 17 of the FRAM71b manual. Using that program educated me on how the ENTER statement works and I have been able with trial and error get various ROM images loaded onto the FRAM71b.

Thank you for the info on bank switching and other involved topics that I have yet to get to. I find this forum to be most helpful.

[Dave Frederickson]

(11-22-2016 10:53 PM)physill Wrote:  I am unable to get around an Invalid Arg error in line 120 of SERTOSYS as shown on page 23 of the FRAM71B manual. I am using a PilBox (with the PIL-Box Bridge, ILPer and Video Interface) to attempt to load the file HP-71B_OS2CDCC_ROM.BIN to the FRAM71B to allow use of the 2cdcc operating system. Communication between the HP-71B hardware and the virtual components is working.

Hi Mark,

The issue here is that SER2SYS was written for use with the RS-232 interface and the hex dump needs to be in ASCII not binary. HP-71B_OS2CDCC_ROM.BIN, which came from Sylvain's HP-71B Compendium, is intended for use with the Emu71 emulators.

With help from Paul Berger and Bob Prosperi, the utilities in the FRAM71B manual were modified to work with the PIL-Box and hex dumps in the format described in the Emu71/Win manual. Those utilities along with Paul's excellent MEMBUF, can be found in the FRAM71 Tool Kit: http://www.hpmuseum.org/forum/thread-4844.html

The 71B Compendium, http://www.hpmuseum.org/forum/thread-5286.html, has the hex dump in the format to be used with the PIL-Box and Sylvain's loader or the Tool Kit utilities.

Code:

-> HP-71B_SYSTEM_ROM.LIF          ILPER: LIF Mass Storage File / FRAM71
   -> OS2CDCC    ASCII  135K      71B OS Version 2CDCC Memory Dump
   -> OS2CDCCL   BASIC   159      71B OS Version 2CDCC Memory Dump Loader

HTH, Dave

[physill]

Thank you Dave. Your advice was most helpful. Unfortunately, the FRAM71B is acting up since I had it in sysram writing mode when I was trying to configure memory blocks. Was in a hurry and did something dumb.

[Dave Frederickson]

(11-24-2016 05:55 PM)physill Wrote:  Was in a hurry and did something dumb.

Welcome to the FRAM71 Club!

[Erwin]

Hi,

now in the holidays I had time enough to play with the FRAM71B. I made a documentation about my configurations and put it on the DROPBOX for download. I want to give a little back for the great work of the community, especially – Sylvain Cote, Dave Frederickson, Bob Prosperi, Hans Brueggemann, Christoph Giesselink.

One thing I had not solved yet was the implantation of a 64KB ROM - but comes time, comes solution :-)

The document is my personal one to check each single step, maybe its helpful for others. I took care of the writing, but maybe there are some faults in the transcription - feedback is welcome.

Link: FRAM71B_Configuration_Docu

EDIT 2017-01-06

• first correction of typos
• unsolved 64KB DATACQ - workaround with physical ROM
  

EDIT 2017-03-08

• solved 64KB DATACQ installation, correct DOKU
  

best regards
Erwin

[rprosperi]

(12-30-2016 12:26 PM)Erwin Wrote:  Hi,

now in the holidays I had time enough to play with the FRAM71B. I made a documentation about my configurations and put it on the DROPBOX for download. I want to give a little back for the great work of the community, especially – Sylvain Cote, Dave Frederickson, Bob Prosperi, Hans Brueggemann, Christoph Giesselink.

One thing I had not solved yet was the implantation of a 64KB ROM - but comes time, comes solution :-)

The document is my personal one to check each single step, maybe its helpful for others. I took care of the writing, but maybe there are some faults in the transcription - feedback is welcome.

Link: FRAM71B_Configuration_Docu

best regards
Erwin

Quite an impressive document Erwin!

It will take some time to review in detail, but from a quick glance it appears to be very thorough. Your use of SHOWPORT and MEMBUF at each step makes it very clear to see what is happening, and will be very helpful for folks learning to use more advanced features of FRAM71.

Thanks for creating and sharing this beautiful and useful document!

Happy New Year!

[Dave Frederickson]

Very nice, Erwin.

I do see a slight mistake, however. What you describe in paragraphs 5.9 and 6.9 is "conventional" bank switching, not on-the-fly. On-the-fly bank switching:

• Is intended for backup purposes (not switching ROM's)
• By definition, does not require a power cycle
• Is invoked when only a Chip's address nibble is changed
• Requires the use of PEEK$/POKE commands as the file chain is broken
  

See Han's example: http://www.hpmuseum.org/forum/thread-251...l#pid30686

Technical Description: http://www.hpmuseum.org/forum/thread-251...l#pid30720

You should have no issues loading a 64k ROM image but you might need to add the ;ROMSIZE=65536 option to ROMCOPY.

Dave

[Sylvain Cote]

Hello Erwin,
I fully agree with Robert, impressive document!
Thank you for sharing it.
Sylvain

[Erwin]

(12-30-2016 06:57 PM)Dave Frederickson Wrote:  Very nice, Erwin.

I do see a slight mistake, however. What you describe in paragraphs 5.9 and 6.9 is "conventional" bank switching, not on-the-fly.
You should have no issues loading a 64k ROM image but you might need to add the ;ROMSIZE=65536 option to ROMCOPY.

Dave

Hi Dave,

you are right - it's not on the fly - I will correct this terms in the document. I tried the ROMSIZE option (described in the fact sheet to the ROMSIZE-LEX) in the past but it was not working of me - I have to do some more tests on this.

Erwin

[dayd]

I got it! My FRAM71B arrived and I played with it a bit 
I have no ROM modules so what an upgrade!
Here’s my initial setup:

Code:

HP71:1BBBB FTH41:1A EDT:A MATH:1A JPC:F04 HPIL:1B KBD:C SHWP:A ALARM:B Beep:A ULIB:c RCPY:E

FRAM71B 512k configuration string:    D3E4D5D69798991A1B9C9D0000000000

RAM    :   148k  (144045 + files 7321 = 151366)
IRAM   :    96k  Lex files, Backups + ROMs
F-ROM  :   112k  T41, Math, JPC
H-ROM  :    80k  (OS + HPIL)
OS RAM :    32k  (CR/FRAM + Devices + ... at 20000)
total  :   468k

512 KB space = 468 KB  +  12k main ram not filled at 7A000  +  32k at F0000

Mapped FRAM blocks: 11
Module HP 4k      :  1

Port Dev Seq  Size Addr  Type   Comment
               64  00000        OS
               32  20000        CR Port, FRAM config & others
  5   6   0    96  30000  0     Main RAM fram
  5   7   0    32  60000  0     Main RAM fram
  0   0   0     4  70000  0     Main RAM internal
  0   1   0     4  72000  0     Main RAM internal
  0   2   0     4  74000  0     Main RAM internal
  0   3   0     4  76000  0     Main RAM internal
  1   0   0     4  78000  0     Main RAM module
  0   5   0    16  80000  2     HPIL ROM
  5   0   0    16  88000  2     SC T41 ROM
  5   5   0    32  90000  1     IRAM testing
  5   4   0    32  A0000  1     IRAM testing
  5   3   0    32  B0000  1     IRAM Backup & Lex
  5   2   0    32  C0000  2     JPC ROM
  5   1   0    32  D0000  2     Math ROM
               32  E0000        HC T41 ROM
                   F0000        00000000000000000000000000000000


Code:
Chip_#  Addr.  Configuration  Description      of        LCIM  Type   Size  Port 
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_0  2C000  CONF     D
Chip_0  2C001  F-BLOCK  3     HC E0000 T41 ROM             1   ROM    32     n/a 
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_1  2C002  CONF     E                                                       
Chip_1  2C003  F-BLOCK  4     16KB SC T41 ROM              1   ROM    16    5.00
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_2  2C004  CONF     D                                                       
Chip_2  2C005  F-BLOCK  5     32KB Math ROM                1   ROM    32    5.01
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_3  2C006  CONF     D                                                       
Chip_3  2C007  F-BLOCK  6     32KB JPC ROM                 1   ROM    32    5.02
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_4  2C008  CONF     9                                                       
Chip_4  2C009  F-BLOCK  7     32KB IRAM Backup & Lex       1   IRAM   32    5.03
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_5  2C00A  CONF     9                                                       
Chip_5  2C00B  F-BLOCK  8     32KB Testing IRAM for rom    1   IRAM   32    5.04
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_6  2C00C  CONF     9
Chip_6  2C00D  F-BLOCK  9     32KB Testing IRAM for rom    1   IRAM   32    5.05
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_7  2C00E  CONF     1
Chip_7  2C00F  F-BLOCK  A     Main RAM 96KB 1 of 3         0   RAM    32    5.06
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_8  2C010  CONF     1
Chip_8  2C011  F-BLOCK  B     Main RAM      2 of 3         0   RAM    32    5.06
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_9  2C012  CONF     9
Chip_9  2C013  F-BLOCK  C     Main RAM      3 of 3         1   RAM    32    5.06
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_A  2C014  CONF     9
Chip_A  2C015  F-BLOCK  D     Main RAM 32KB                1   RAM    32    5.07
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_B  2C016  CONF     0
Chip_B  2C017  F-BLOCK  0     (future swappable rom)
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_C  2C018  CONF     0
Chip_C  2C019  F-BLOCK  0     (future swappable rom)
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_D  2C01A  CONF     0
Chip_D  2C01B  F-BLOCK  0     (future swappable rom or os)
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_E  2C01C  CONF     0
Chip_E  2C01D  F-BLOCK  0     (future swappable rom or os)
------  -----  -------------  -------------------------- ----  -----  ----  ----
Chip_F  2C01E  CONF     0
Chip_F  2C01F  F-BLOCK  0     1 F-block left for FRAM and OS config (at F_20000)
------  -----  -------------  -------------------------- ----  -----  ----  ----

I divided the main RAM, to be able to move things around more easily, without losing the content.
Backup is not intended to be switched but just to protect some files (memory lost or corruption).
What is the F0000 to FFFFF space reserved for? I did same testing with the samples configurations provided by Hans’ manual and when I add one more F block I get a warning.
It’s not that I want to, but I’m curious, here some others question that I have:
In Erwin’s pdf, sometimes, like in the beginning, IRAM identifiers are not erased by a poke, is there a reason?
And my big question; what is the work around to free the ports programmatically?

Thank you all for your involvement in the forum, it has been very helpful,
André

[rprosperi]

(01-17-2017 09:07 AM)dayd Wrote:  What is the F0000 to FFFFF space reserved for?

FFC00-FFFFF is reserved for OS configuration.

According to the Forth (and F41 I think) Manual, when any HC ROM is present at E0000 (Forth or F41) the F0000-FFC00 block is reserved for a Debugger, which was never released. Similar comments can also be found in the IDS listings, but when IDS was released it appears the debugger was not ready (and then later abandoned) so there are no details.

Note that this is NOT the same Debugger that was released later as a set of LEX files that could be loaded into normal RAM.

[J-F Garnier]

(01-17-2017 09:07 AM)dayd Wrote:  And my big question; what is the work around to free the ports programmatically?

(Warning: advanced information :-)

The JPC ROM has provision for executing non-programmable functions, with the EXECUTE command.
There is an additional difficulty: after executing CLAIM/FREE ports (that causes system reconfiguration), the current program is ended and the current program file is set to 'workfile'. But is is easy to manage it by adding a RUN command after the CLAIM/FREE to continue the program.
For instance, create the TEST program file:
10 ! TEST
20 DISP "Doing EXECUTE..."
30 EXECUTE "FREE PORT(5) @ RUN TEST,40"
40 DISP "Done."

J-F

[Hans Brueggemann]

(01-17-2017 03:01 PM)rprosperi Wrote:  Note that this is NOT the same Debugger that was released later as a set of LEX files that could be loaded into normal RAM.

ah, thanks! one more mystery solved!

[dayd]

(01-17-2017 03:01 PM)rprosperi Wrote:  According to the Forth (and F41 I think) Manual, when any HC ROM is present at E0000 (Forth or F41) the F0000-FFC00 block is reserved for a Debugger, which was never released. Similar comments can also be found in the IDS listings, but when IDS was released it appears the debugger was not ready (and then later abandoned) so there are no details.

Thanks Bob, it’s very nice to have some background history, also. That’s probably because the 71b didn’t sell as the 41. I wonder how much man hours work it took to make an OS as the 71b, may it would explain why they dropped the debugger.

(01-17-2017 05:07 PM)J-F Garnier Wrote:  (Warning: advanced information :-)

Indeed, powerful and reserved for extreme situations! It worked on my case, thank you. The ALARMLEX with SETALARM also execute commands from strings but that’s not as clean as your code. The JPC seems to be a ‘must have’ ROM (at least for me).

Sorry to take so long to respond, best regards,
André

[Erwin]

(01-17-2017 09:07 AM)dayd Wrote:  In Erwin’s pdf, sometimes, like in the beginning, IRAM identifiers are not erased by a poke, is there a reason?

Hi André,

there is no reason - it was my very first full try with an easy proposal from Sylvain and I did it only one time and it was running. But I'll do it a second one and see what's the difference :-)

regards
Erwin

[Erwin]

(11-01-2016 03:39 PM)Dave Frederickson Wrote:  Understand that ROM's and IRAM's get configured after RAM. When you FREEPORT a module it moves within the address space from RAM to a higher address with the other ROM's and IRAM's. In some max RAM configurations this will cause a configuration warning just like configuring more RAM than can be addressed.

Configuring the module as ROM will, by definition, prevent it from being written.

(11-01-2016 02:14 PM)Erwin Wrote:  ... I see it in the end of the article so I have to take care to put the larger ROMs first.

That's not necessary. The 71's configuration routine takes care of that.


That said, I had no issues configuring FRAM71B as above.

Code:

>PEEK$("2C000",32)
D3E4D5D69718191A9B50D10000000000
>RUN MEMBUF
Port Dev Seq  Size Addr  Type
  0   0   0     4  70000  0  BUILT-IN RAM
  0   1   0     4  72000  0  BUILT-IN RAM
  0   2   0     4  74000  0  BUILT-IN RAM
  0   3   0     4  76000  0  BUILT-IN RAM
  5   4   0   128  30000  0  MAIN RAM
  0   5   0    16  80000  2  HPILROM
  5   0   0    16  88000  2  FTH41 ROM
  5   1   0    32  D0000  2  MATHROM
  5   2   0    32  C0000  2  JPC ROM
  5   3   0    32  B0000  1  FRAM71 TK
  5   5   0    64  90000  2  DATACQ ROM
>

Dave

Hi Dave,

The way you did it is running for me in the same way. But to put the DATA-ACQ module in this space it must be configured as IRAM and that is not possible. When I FREEd this space it does it without an error but it resides as RAM. You can try this with POKE "2C012"; "109100" and then try to FREE it. So maybe its not possible for 64k on the "end" of the FRAM? In the address space it is after the MAIN RAM.

I'm confused at the moment about this. No other have such problems solved? I'll try it in another sequence ... next time.

regards Erwin

[Erwin]

(11-01-2016 09:26 AM)Erwin Wrote:  I found the basic program R64KCOPY (chu06) but it is to get the checksum from existing ROMs in a port and needs a LEX-File "TRIM$" from STRINGLX. But in the basic program there is another LEX-file not present (XFN113004) - line 100 till 103 for the checksum - so it ends in an error. Looks like it was saved in the past without the necessary LEX present in the HP71. When the prog could be run I could get the data out of my DATCQ module.

Now I found the solution - with the help of Joe Horn's great the O.L.D project to searcher the XFN number and get the function or command: OLD Project
It is the 'HTA$' command. So the correction of the program looks like:

Code:

10 ! THIS PROGRAM COMPUTES CHECKSUMS FOR ROMCOPY FOR 64K IRAM
20 INPUT "Port?","5";P
21 P$=":PORT("&STR$(P)&")"
30 DIM A$[96]
31 I=1
40 A$=CAT$(I,P$) @ IF A$="" THEN 100
50 F$=TRIM$(A$[1,8]) @ B$=ADDR$(F$&P$) @ PRINT A$[1,8];" ";B$;
51 O1=HTD(B$) @ IF I=1 THEN O=O1-8 @ PRINT ELSE PRINT USING "X,5D.D";(O1-O)/2
52 IF O1-O>32768 AND O2=0 THEN O2=O1-O
53 IF O1-O>32768*2 AND O3=0 THEN O3=O1-O
60 I=I+1 @ GOTO 40
100 PRINT USING '"csum 1: ",6d,x,8a';30;HTA$(PEEK$(DTH$(O+8),18))
101 PRINT USING '"csum 2: ",6d,x,8a';O2+22;HTA$(PEEK$(DTH$(O+O2),18))
102 PRINT USING '"csum 3: ",6d,x,8a';O3+22;HTA$(PEEK$(DTH$(O+O3),18))
103 PRINT USING '"csum 4: ",6d,x,8a';O1-O+22;HTA$(PEEK$(DTH$(O1),18))
200 POKE DTH$(O+30),"00"
201 POKE DTH$(O+O2+22),"00"
202 POKE DTH$(O+O3+22),"00"
203 POKE DTH$(O1+22),"00"

maybe some could use it too - regards Erwin