(71B) FORTH questions

[Sylvain Cote]

From your link:

Quote:Standard Forth defines no words for character-aligning addresses; in Forth-2012 all addresses are character-aligned.

71B Forth follow as much as possible the FORTH-83 standard, so cell words are not implemented here.
Also, I am not a Saturn specialist here, but to my knowledge, word, ahum, nibble alignment is not an issue with the 71B processor.

edit: changed standard version from 1979 to 1983

[floppy]

(07-25-2023 03:02 PM)Sylvain Cote Wrote:  From your link:

Quote:Standard Forth defines no words for character-aligning addresses; in Forth-2012 all addresses are character-aligned.

71B Forth follow as much as possible the 1979 standard, so cell words are not implemented here.
Also, I am not a Saturn specialist here, but to my knowledge, word, ahum, nibble alignment is not an issue with the 71B processor.

Fine. But.
I have a program in gforth and want to translate in Forth71B. It means I should define the equivalent of CELLS.

Example my Forth71B wording for the gforth D= is
: D= 2OVER 2OVER D< IF 2DROP 2DROP FALSE ELSE 2SWAP D< IF FALSE ELSE TRUE THEN THEN ;
: D= ( d d -- ?) ROT = ROT ROT = AND ;

or another one..
: >= 2DUP = IF = ELSE SWAP < THEN ;

or another one.. (more to come the next weeks/months)
: CHAR ASC ;

[David Hayden]

(06-16-2023 05:39 PM)Giuseppe Donnini Wrote:  I can, therefore, confirm that the bug was indeed fixed in ROM revision 2CDCC. Here is my own disassembly of GETTIM for both the 1BBBB and the 2CDCC revisions.
...
2CDCC

Code:


1254A 04         GETTIM SETHEX
1254C 1B8F2E2           D0=(5)  =TIMER2        Point to timer in disp driv.
12553 AF0               A=0     W
12556 15A5              A=DAT0  6              Read timer
1255A 25                P=      5              [GD: Set value of P *before* using...]
1255C A98               B=A     WP             [    ...WP for the first time!]
1255F 15A5              A=DAT0  6              Read again.
12563 910               ?A=B    WP             Kerchunk anywhere?
12566 60                GOYES   GETTM2         No.  Reads are good.
12568 15A5              A=DAT0  6              Yes.  One more read.
1256C A88        GETTM2 B=A     P
1256F A05               B=B+B   P              Negative?
12572 500               RTNNC                  No
12575 B98               A=-A    WP             Yes.  perform sign-extend
12578 BF8               A=-A    W
1257B 02                RTNSC

I'm late to the party, so I may just misunderstand the issue, but even this fixed code looks wrong to me because it assumes that when value1 != value2, value 2 is the correct one. Shouldn't it basically loop until it reads two consecutive values that are the same?

[J-F Garnier]

(07-25-2023 06:05 PM)David Hayden Wrote:  

(06-16-2023 05:39 PM)Giuseppe Donnini Wrote:  I can, therefore, confirm that the bug was indeed fixed in ROM revision 2CDCC. Here is my own disassembly of GETTIM for both the 1BBBB and the 2CDCC revisions.
...
2CDCC

Code:


1254A 04         GETTIM SETHEX
1254C 1B8F2E2           D0=(5)  =TIMER2        Point to timer in disp driv.
12553 AF0               A=0     W
12556 15A5              A=DAT0  6              Read timer
1255A 25                P=      5              [GD: Set value of P *before* using...]
1255C A98               B=A     WP             [    ...WP for the first time!]
1255F 15A5              A=DAT0  6              Read again.
12563 910               ?A=B    WP             Kerchunk anywhere?
12566 60                GOYES   GETTM2         No.  Reads are good.
12568 15A5              A=DAT0  6              Yes.  One more read.
1256C A88        GETTM2 B=A     P
1256F A05               B=B+B   P              Negative?
12572 500               RTNNC                  No
12575 B98               A=-A    WP             Yes.  perform sign-extend
12578 BF8               A=-A    W
1257B 02                RTNSC

I'm late to the party, so I may just misunderstand the issue, but even this fixed code looks wrong to me because it assumes that when value1 != value2, value 2 is the correct one. Shouldn't it basically loop until it reads two consecutive values that are the same?

No, what the code does is:
read the timer 2 times,
if both values agree that's ok,
else immediately read the timer a third time, that value will be ok because the timer changes only every 1/512s.

J-F

[floppy]

AGAIN the topic TIME..
I want to use an application where the milliseconds, for time delay, are used.
Is there any way to get a HH.MMSSsss output in the code submitted previously?
else my idea would have to count between TIME1 and TIME1+5s in a loop, see how many it was as incrementals of a counter (let say 3000), then use the number of incrementals later to identity the value of a millisecond (in the case above, it would be 3000/5 = 600 increments for 1 sec which means an increment by 1 would be already 1ms).

[rprosperi]

The clock in the 71B only has resolution to 0.01 seconds, so milliseconds are not possible.

[floppy]

(07-26-2023 08:17 PM)rprosperi Wrote:  The clock in the 71B only has resolution to 0.01 seconds, so milliseconds are not possible.

If I understand now, the minimum precision and the minimum cycle time is 10ms. Is there any overview anywhere how many 0.01s few forth commands are consuming? example
SWAP SWAP (no effect at all on the stack).

[Garth Wilson]

(07-27-2023 08:05 AM)floppy Wrote:  Is there any overview anywhere how many 0.01s few forth commands are consuming? example
SWAP SWAP (no effect at all on the stack).

Many of the Forth words seemed to have been written a lazy way of just handing them off to BASIC and then returning the effects, along with all the overhead of doing so, and I have said before that I was able to speed up many of the Forth words, often dramatically, by re-writing, them, not even resorting to assembly language.  CHR$ was the greatest as I remember, at 14x, going from 13.5ms to under 1ms.  Bob Prosperi has asked me to write these up, but it turned out to be a huge job, because my documentation is not all in one place, nor organized, and partly because I have hardly touched my 71's in a couple of decades or more, so I would need a lot of review to refresh my mind on how to use the 71.  Consequently, I have not succeeded so far in writing this stuff up.

However, here are a few timings I have penciled in in the manual for the 82441A Forth module:
"    4ms for 1 character, no noticeable increase for 11 characters
*     multiplying 123H by 45H took 2.73ms, and 1 x 1 took 1.88ms
+     (also - ) 0.3ms
+!     370µs
-TRAILING     on a string of ABCDEFGHIJKL took 5.54ms
0     260µs
0<     270µs
0=     about 265µs
0>     about 275µs
1/X     about 7ms
2     220µs
2*     (also 2/ ) about 325µs
2+     (also 2- and 5+ and 5- ) 250µs
2DROP     215µs
2DUP     235µs
2OVER     255µs
2SWAP     0.37ms
4N@     1.9ms
<     5  A  <  took 315µs, and  A  5  -  took 335µs
=     280µs
>     5  A  >  took 330µs, and  A  5  >  took 352µs
>R     >R  R>  takes 0.6ms
@     285µs
ABS     170µs for n>=0, 200µs for n<0
AND     255µs
ASC     1.59ms
You can do BEGIN...AGAIN about 330µs per loop faster than BEGIN  -1  UNTIL if you define:

Code:

: AGAIN  ?comp  1 ?PAIRS  branch  HERE -  ,  ;  IMMEDIATE

BL     256µs
C!     336µs
C@     290µs
C@+     about 4.6ms
CHR@     13.5ms
CMOVE     moving 10 characters took about 1.4ms
CONSTANT     260µs to return a constant by referring to it after it's created
COUNT     324µs
DECIMAL     almost 2ms!
DO...+LOOP     DO  10  +LOOP  took about 1.75ms per loop.
DO...LOOP     An empty DO LOOP loops about a thousand times per second.
DROP     200µs
DUP     218µs
END$     by itself took 54ms when used in " ABCDEFGHIJKL"  W$  S!  5  END$.  LEFT$ and RIGHT$ were about the same.
HEX     took almost 2ms!
I     261µs
IF...THEN     0  IF  THEN  takes about 1.2ms.  -1  IF  THEN  takes about 1.1ms.
J     273µs
M*     by itself took an average of 6ms when used in  HEX  1000  0  DO  M*  LOOP
M/     by itself took an average of 15.44ms when used in  HEX  1000  0  DO  12345  M/  LOOP
MAX     (and also MIN) about 4ms
MAXLEN     2.12ms
N@     271µs
NOT     240µs
NULL$     8.79ms!
OVER     230µs
PICK     4  PICK  took 330µs
ROT     375µs
S!     a 9-character string took 10.15ms
S<&     concatenating a 10-character string and a 9-character string took 13.2ms
S=     In " ABCDEFGHI"  2DUP  W$  S!  WHO$  S!  W$  WHO$  S=, the S= took 2.55ms; but replacing WHO$ with just a letter A, S= took 1.173ms.
S>&     Concatenating " JKLMNOPQRS" and " ABCDEFGHI" took 16.08ms.
STRING     Returning str after creation takes 350µs.
SUB$     In " ABCDEFGHIJK"  W$  S!  W$  5  7  SUB$, the SUB$ took 52ms.
SWAP     about 300µs
VAL     48ms
VARIABLE     After a variable is created, returning its address takes 222µs.

[floppy]

Step 15 its a bit different (2048)

CAT :TAPE
NAME S TYPE LEN DATE TIME
TIMEASM TEXT 2048 07/31/23 16:22

Step 18 seems stuck
" TIMEASM:TAPE" ASSEMBLE

PASS 1 .
missing/multiple file type

TIME
FTH ERR:TIME not recognized

[Sylvain Cote]

I just redid all the steps and it is working on my side.

Just in case line ending was an issue LF (unix) vs CR+LF (windows)

I did the following on macOS:

Code:

bbedit timeasm_osx.txt  // copy & paste the FORTH source code below
lifinit -z -m cass v71time_osx.dat 64
liflabel v71time_osx FTHOSX
cat timeasm_osx.txt | textlif TIMEASM | lifput v71time_osx.dat

I did the following on Windows:

Code:

"c:\Program Files\Notepad++\notepad++.exe" timeasm_win.txt   // copy & paste the FORTH source code below
lifinit -z -m cass v71time_win.dat 64
liflabel v71time_win FTHWIN
type timeasm_win.txt | textlif TIMEASM | lifput v71time_win.dat

FORTH source code

Code:


       FORTH
*                                TIMEASM
*                        FORTH TIME: Primitive

SAVEFP EQU #E717A           FORTH entry points:  Save FORTH pointers
GETFP  EQU #E71A5                                Recover FORTH pointers
STKLFT EQU #E7320                                Lift floating-point stack
CMPT   EQU #125B2          System entry points:  Read time
IDIV   EQU #0EC7B                                Full word integer divide
HXDCW  EQU #0ECB4                                Hex to decimal
FLOAT  EQU #1B322                                Integer to floating point
CLRFRC EQU #0C6F4                                Clear fractional part
DV2-12 EQU #0C4A8                                12-digit divide

* TIME : Read system clock in seconds; return result to X
       WORD 'TIME'
       GOSBVL SAVEFP
       GOSBVL STKLFT
       P=     5              *** workaround for bug 1084
       GOSBVL CMPT           C(W) = Time in hex 512ths of a second
*
ACLC24 A=C W                 Unsupported entry point. 12B79
       C=0 W
       P= 4
       LCHEX 2A3             C = 2A30000
       D=C W                 D = 2A30000 ( 24 hours in 512th's of a second )
*
       GOSBVL IDIV
       GOSBVL HXDCW
       A=C W
       GOSBVL FLOAT
       C=0 W
       P= 12
       LCHEX 512             C = 5.12
       GOSBVL DV2-12         A,B = Time*100
       GOSBVL CLRFRC         A,B = IP(Time*100)
       GOSUB TRUNCC
       C=C-1 X
       C=C-1 X               C = TIME
       SETHEX
       D0=(5) #2FBD0         X-Register
       DAT0=C W              X = TIME
       GOSBVL GETFP
       RTNCC

TRUNCC P= 0                  unsupported system utility at 12B4A
       LCHEX 00499           rounds 15-digit A,B to 12-digit C
       ?A<=C A
       GOYES TRUN20
       C=-C A
       ?A>=C A
       GOYES TRUN20
       C=0 W
       A=A+A A
       GOC TRUN10
       LCHEX F00
       C=A S
TRUN10 RTNCC
TRUN20 C=A W
       C=B M
       RTNCC

       END

(07-31-2023 03:41 PM)floppy Wrote:  Step 15 its a bit different (2048)
CAT :TAPE
NAME S TYPE LEN DATE TIME
TIMEASM TEXT 2048 07/31/23 16:22

Yep, I get the same size, I probably added a few spaces and the file was on the edge between block sizes.

(07-31-2023 03:41 PM)floppy Wrote:  Step 18 seems stuck
" TIMEASM:TAPE" ASSEMBLE

PASS 1 .
missing/multiple file type

TIME
FTH ERR:TIME not recognized

You probably missed some of the source code.

Using EMU71 + ILPER I was able to load, compile, execute for both files: v71time_osx.dat and v71time_win.dat.

Sylvain

edit: for the source code, try "View a Printable Version" , then select page 3 and copy paste the source code.

[floppy]

Difference to previous HowTos: my system is a Debian 64bits. I search in that direction before perhaps moving into a Win11 environment.

[HP67]

(08-01-2023 10:10 AM)floppy Wrote:  Difference to previous HowTos: my system is a Debian 64bits. I search in that direction before perhaps moving into a Win11 environment.

It's usually possible to find Windows install discs online and use them in a virtualbox on Linux.

[floppy]

Using rob DEV-HB.DAT was so far weird for me too: with CAT :HDRIVE1 it output only STRINGLX on my EMU71.

pyilper see the content (see attached picture). Just EMU71 dont list it.

lifdir DEV-HB.DAT

Quote:Volume : , formatted : 11/12/11 19:56:15
Tracks: 80 Surfaces: 2 Blocks/Track: 16 Total size: 2560 Blocks, 655360 Bytes
STRINGLX LEX71 837/1024 11/12/11 19:58:39
KBD150 BAS71 1094/1280 11/12/11 19:58:57
PATTERN LEX71 171/256 11/12/11 19:59:18
GEDIT BAS71 1091/1280 11/12/11 19:59:33
KBD264 BAS71 938/1024 11/12/11 19:59:51
CUSTUTIL LEX71 1007/1024 11/12/11 20:00:10
FTHUTILA TEXT 7424/7424 11/12/11 20:00:31
BREAKPT LEX71 365/512 11/12/11 20:01:02
FTHUTILC FTH71 4608/4608 11/12/11 20:01:22
FTHUTILF TEXT 11520/11520 11/12/11 20:03:21
10 files (640 max), last block used: 198 of 2560

However " FTHUTILA:TAPE" ASSEMBLE is making "PASS 1..2 .............." fine.

Next issue.. " FTHUTILF:HDRIVE1" LOADF .. dictionnary full. I had several 32k modules on Port5 since I wanted to cope to my HP71B.
Same issue with a 128k RAM Module in Port5.

Since I have no 128k HW module for my HP71B, how to setup modules for making Forth working? try to buy 2x 62k RAM Modules or a 128k RAM? 4x32k Modules and Forth/assembler in Multimod? few advices are welcomed.

The battle of WINE Linux Win-exe EMU71 Forth ASSEMBLER ILPER ILvideo80 Pyilper is on-going.

And the DM41X I got 1 week ago is dead already after 1 week.
swissmicro has so far a very silent mail answering.. :-(
I need holiday.

Update 1. Rob file makes Pass 1 and Pass 2.. looks good
Update 2: Dictionnary full

[rprosperi]

(08-01-2023 11:11 AM)floppy Wrote:  However " FTHUTILA:TAPE" ASSEMBLE is making "PASS 1..2 .............." lets wait.. probably fine.

[snip]

Update 1. Rob file makes Pass 1 and Pass 2.. looks good

The Forth ROM assembler is always quite slow, but especially so when processing from a source file on the loop! Although " FTHUTILA:TAPE" ASSEMBLE will clearly work OK, it is much faster if instead, you copy the assembler source file to main RAM first and then assemble it locally. To do so, use:

COPY FTHUTILA:TAPE TO :MAIN
" FTHUTILA" ASSEMBLE

[Sylvain Cote]

(08-01-2023 11:11 AM)floppy Wrote:  Using rob DEV-HB.DAT was so far weird for me too: with CAT :HDRIVE1 it output only STRINGLX on my EMU71.

File catalog listing is not automatic, you have to use the down/up arrow key to see the next/previous file in CAT mode.
edit: and right/left arrow to see detailed informations of the displayed file.

[floppy]

(08-01-2023 12:44 PM)Sylvain Cote Wrote:  

(08-01-2023 11:11 AM)floppy Wrote:  Using rob DEV-HB.DAT was so far weird for me too: with CAT :HDRIVE1 it output only STRINGLX on my EMU71.

File catalog listing is not automatic, you have to use the down/up arrow key to see the next/previous file in CAT mode.

+1
Learner at work.. Thanks.
.. "FULL DICTIONNARY" still there with a 128k RAM in Port5 of EMU71.

[Sylvain Cote]

(08-01-2023 01:03 PM)floppy Wrote:  

(08-01-2023 12:44 PM)Sylvain Cote Wrote:  File catalog listing is not automatic, you have to use the down/up arrow key to see the next/previous file in CAT mode.

+1
Learner at work.. Thanks.
.. "FULL DICTIONNARY" still there with a 128k RAM in Port5 of EMU71.

Code:

FORTH [ENDLINE]
10000 GROW [ENDLINE] → grows the dictionary by 10k nibbles (5000 bytes)
. [ENDLINE] → -1 means the operation was successful

[floppy]

(08-01-2023 01:25 PM)Sylvain Cote Wrote:  

Code:

FORTH [ENDLINE]
10000 GROW [ENDLINE] → grows the dictionary by 10k nibbles (5000 bytes)
. [ENDLINE] → -1 means the operation was successful

Works. You are the boss. Rob too. And all other.
Now I have to understand how works TIME since I was thinking it would be H.MMSS as output (according translator manual). However TIME TIME F- F. in a quite slow motion show -5.41. Negativ is fine. Result could be 5.41s . more to read now in the holiday time..

[Sylvain Cote]

(08-01-2023 02:33 PM)floppy Wrote:  Now I have to understand how works TIME since I was thinking it would be H.MMSS as output (according translator manual).

From the assembly source code: TIME : Read system clock in seconds; return result to X (in floating point 4-level stack)

(08-01-2023 02:33 PM)floppy Wrote:  However TIME TIME F- F. in a quite slow motion show -5.41. Negativ is fine. Result could be 5.41s . more to read now in the holiday time..

try:

Code:

TIME 
(wait 5 seconds) 
TIME
F- 
FABS
F.

Manuals ...

• HP 82441A FORTH/Assembler ROM Owner's Manual
• HP 82441A FORTH/Assembler ROM Internal Maintenance Specification
• HP 82478A Debugger Owner's Manual
• HP 82490A HP-41 Translator Pac Owner's Manual
• HP 82490A HP-41 Translator Pac Programmer's Toolkit
  

[floppy]

Ok. The TIME we uploaded is "Read system clock in seconds; return result to X". Means thats not the same spec as the TIME from the translator module manual. Fine for me. Due to the reading precision of 1/512 = 0.002 it looks like thats the maximum precision to be achieved by activating TIME.
Having TIME TIME F- FABS F. show the execution is > ONE full TIME sequence and I could only get minimum 0.06 (mostly 0.07) in EMU71 (I have to check what it will be on the hardware) so.. for programming for example random numbers, their difference will be minimum 0.06 etc.

the question remain: what setup is the best for Forth 71B?
- 2x 62KB RAM & ROM Forth or
- 1x 128KB & ROM Forth or
- 4x32KB and move the Forth/assembler into Multimod?