HP-71 Forth/Assembler ROM fix

[J-F Garnier]

I published on my site a simple fix for the two major bugs of the assembler in the Forth ROM (buggy B=B+B A and D1=AS opcodes). I found this fix several years ago, but it now makes sense to publish it since the FRAM71 module now allows to load (and possibly modify) the hardwired part of the Forth/Assembler ROM.

http://www.jeffcalc.hp41.eu/emu71/bug71.html#forth

A couple of simple POKE may implement the fix, after loading the regular ROM:
POKE "E76A8","4" ! instead of "5"
POKE "E76C4","9" ! instead of "8"
Note that the ROM checksum is unchanged by this fix.

I let the FRAM71 experts devise the exact patch loading procedure :-)

J-F

[Dave Frederickson]

I patched HRDFORTH.BIN prior to loading it into Emu71. Seems to work, no slight-of-FRAM magic necessary. Am I missing something?

Dave

[J-F Garnier]

(12-02-2015 05:58 PM)Dave Frederickson Wrote:  I patched HRDFORTH.BIN prior to loading it into Emu71.

Easy...

Quote:Seems to work,

Here is a short test assembly code to check the bugs and the fix:

Code:


  LEX 'TEST' 
  ID #5C  
  MSG 0  
  POLL 0 
  ENTRY FNCT
  CHAR #F  
  KEY 'TST'  
  TOKEN 1
  ENDTXT

  NIBHEX 00
FNCT 
  GOTO LBL1  
  B=B+B A   * bug 1
  D0=AS 
  D1=AS     * bug 2
LBL1 
  C=0 W  
  P= 14  
  LCHEX 1  
  GOVLNG #0F216

  END

With a genuine Forth/assembler ROM, the result is

Code:


...
0012 00055           FNCT
0013 00055 6C00        GOTO LBL1
0014 00059 C5          B=B+B A   * bug 1
0015 0005B 138         D0=AS
0016 0005E 138         D1=AS     * bug 2

* duplicate label
0017 00061           LBL1
0018 00061 AF2         C=0 W
0019 00064 2E          P= 14
0020 00066 301         LCHEX 1
0021 00069 8D612F0     GOVLNG #0F216
0022 00070
0023 00070             END
...
 ERRORS : 001

showing the wrong D1=AS code (undetected), and the duplicate label error created by the bad B=B+B A opcode class.

With the fix, the two errors disappear.

[Sylvain Cote]

(12-02-2015 08:02 AM)J-F Garnier Wrote:  I let the FRAM71 experts devise the exact patch loading procedure :-)

(12-02-2015 08:01 PM)J-F Garnier Wrote:  Easy...

Yeah, sure, I wonder, who is the expert here! LOL

[rprosperi]

(12-02-2015 05:58 PM)Dave Frederickson Wrote:  I patched HRDFORTH.BIN prior to loading it into Emu71. Seems to work, no slight-of-FRAM magic necessary. Am I missing something?

Dave

For a real 71B w/FRAM71, you need to do this:

Load the HC ROM image into first F_Block
Change jumpers to move this to E0000
Use the POKE statements JFG provided, or maybe easier with the RAM editor
Issue FRAM71 config to reconfigure E0000 as ROM

Voila...

I found a file from John Baker from around 1986 with 5 patches to the FORTH Assembler that fix these fundamental code-generation bugs, plus some other bugs in how the assembler works (e.g. with more than 100 symbols, the assembler listing will not be generated properly if not in DECIMAL mode, and other similarly obscure stuff). I can post it if anyone is interested.

Back then, patching the assembler was done by adding complex RAM-based patches to the FORTHRAM file, but now that we can patch the HC ROM image, it may be feasible to generate simple patches like these for all 5 issues.

[Dave Frederickson]

I've updated the FRAM71 Tool Kit to include a FORTH HC ROM loader, F2R2, that includes the two patches above.

F2R2

Code:

0010 DIM A$[64]
0015 ASSIGN #1 TO HRDFORTH:TAPE
0020 S$="30000"
0030 E$="3FFFF"
0040 S=HTD(S$)
0050 E=HTD(E$)
0060 FOR I=S TO E STEP 64
0070 READ #1;A$
0080 I$=DTH$(I)
0090 POKE I$,A$
0100 DISP I$
0110 NEXT I
0120 ASSIGN #1 TO *
0130 POKE "376A8","4"
0140 POKE "376C4","9"
0150 END

Dave

Edit: Fixed bug in code per below post.

[Sylvain Cote]

(12-03-2015 05:10 PM)Dave Frederickson Wrote:  ...
0015 ASSIGN #1 TO HRDFORTH:TAPE
0020 S$="30000"
0030 E$="3FFFF"
...
0130 POKE "E76A8","4"
0140 POKE "E76C4","9"
0150 END

Dave,

I will not work, because you are targeting the page E instead of the page 3.
Here is the corrected code ...

0130 POKE "376A8","4"
0140 POKE "376C4","9"

Sylvain

[Dave Frederickson]

(12-03-2015 06:09 PM)Sylvain Cote Wrote:  I will not work, because you are targeting the page E instead of the page 3.
Here is the corrected code ...

Hi Sylvain,

Thanks for that "expert" catch.

The Tool Kit has been updated.

Dave

Edit:

(12-03-2015 01:35 AM)rprosperi Wrote:  I found a file from John Baker from around 1986 with 5 patches to the FORTH Assembler that fix these fundamental code-generation bugs, plus some other bugs in how the assembler works (e.g. with more than 100 symbols, the assembler listing will not be generated properly if not in DECIMAL mode, and other similarly obscure stuff). I can post it if anyone is interested.

Someone already did! FIX5A

[Erwin]

(12-03-2015 06:40 PM)Dave Frederickson Wrote:  

(12-03-2015 06:09 PM)Sylvain Cote Wrote:  I will not work, because you are targeting the page E instead of the page 3.
Here is the corrected code ...

Hi Sylvain,

Thanks for that "expert" catch.

The Tool Kit has been updated.

Dave

Edit:

(12-03-2015 01:35 AM)rprosperi Wrote:  I found a file from John Baker from around 1986 with 5 patches to the FORTH Assembler that fix these fundamental code-generation bugs, plus some other bugs in how the assembler works (e.g. with more than 100 symbols, the assembler listing will not be generated properly if not in DECIMAL mode, and other similarly obscure stuff). I can post it if anyone is interested.

Someone already did! FIX5A

Hi, a question on the experts. I have the FRAM71 kit and installed all (for me - like i described in a post of mine) necessary programs. What about those above FIX5A fixes? How to implement them with the Forth/assembler in the FRAM71?

best regards
Erwin

[rprosperi]

(11-24-2018 09:24 PM)Erwin Wrote:  Hi, a question on the experts. I have the FRAM71 kit and installed all (for me - like i described in a post of mine) necessary programs. What about those above FIX5A fixes? How to implement them with the Forth/assembler in the FRAM71?

best regards
Erwin

The fixes to the assembler only change the FORTHRAM file, so there is no need to worry about if you have the FORTH/Assembler in ROM or FRAM71.

The assembler, written in FORTH, had 'hooks' built-in to allow later patches to replace an opcode, or even much more as John Baker's 5th patch proves, into the RAM file.

If you want to implement all the changes, you simply load the patch file (" FIX5A" LOADF) into a blank FORTHRAM file, and then make that your new starting place to build your own stuff on top of.

But note a couple important things:

1. The 'revised' assembler is now invoked via " MYSOURCE" SASM, so that you can still invoke the original using " MYSOURCE" ASSEMBLE.

2. The new assembler discards some of the built-in pseudo-ops that control the assembly type (e.g. for LEX file header, keyword tables, etc.), requiring you to manually craft (the normally auto-generated content with) CON(i) N, NIBASC 'chars' or NIBHEX N pseudo-ops with the proper bytes, for the header, LEXID, etc.

So, while this does give you much more fine-tuned control, I'd suggest deferring jumping to that version until you've used the basic stuff for a while.

[Erwin]

(11-24-2018 09:49 PM)rprosperi Wrote:  

(11-24-2018 09:24 PM)Erwin Wrote:  Hi, a question on the experts. I have the FRAM71 kit and installed all (for me - like i described in a post of mine) necessary programs. What about those above FIX5A fixes? How to implement them with the Forth/assembler in the FRAM71?

best regards
Erwin

The fixes to the assembler only change the FORTHRAM file, so there is no need to worry about if you have the FORTH/Assembler in ROM or FRAM71.

The assembler, written in FORTH, had 'hooks' built-in to allow later patches to replace an opcode, or even much more as John Baker's 5th patch proves, into the RAM file.

If you want to implement all the changes, you simply load the patch file (" FIX5A" LOADF) into a blank FORTHRAM file, and then make that your new starting place to build your own stuff on top of.

But note a couple important things:

1. The 'revised' assembler is now invoked via " MYSOURCE" SASM, so that you can still invoke the original using " MYSOURCE" ASSEMBLE.

2. The new assembler discards some of the built-in pseudo-ops that control the assembly type (e.g. for LEX file header, keyword tables, etc.), requiring you to manually craft (the normally auto-generated content with) CON(i) N, NIBASC 'chars' or NIBHEX N pseudo-ops with the proper bytes, for the header, LEXID, etc.

So, while this does give you much more fine-tuned control, I'd suggest deferring jumping to that version until you've used the basic stuff for a while.

Great - thanks for your fast response :-) very helpful
kind regards
Erwin

[Dave Frederickson]

As Bob noted, the F/A's assembler is written FORTH, but there are other 71B assemblers.

Of note is Joachim Siebold's ASM71 cross assembler for the 71B.

https://github.com/bug400/asm71

I suspect that Joachim's assembler includes all the bug fixes.

Dave

[rprosperi]

I also found a version of the F/A ROM assembler fixes that takes care of 4 out of 5 of the bugs, but does not make the drastic changes that the FIX5A version does.

Here is a version that circulated in a file called ASMFIX4

Code:

HEX
CREATE NEWB
42502 , B423D , 20422 , 5304 , 1000 ,
CREATE NEWD
44505 , 13D31 , 20534 , 39305 , 1 ,
: NEWCODE 2DUP
" B=B+B" S= IF 2DROP NEWB -1 ELSE
" D1=AS" S= IF NEWD -1 ELSE 0
THEN THEN ;
: ASSEMBLE
DECIMAL HERE PAD OVER - 0 NFILL
PAD 2+ DUP C@ 2* + 2+ SP@ 2DUP <
IF OVER - 0 NFILL ELSE 2DROP THEN
['] NEWCODE 2FC79 ! ASSEMBLE
0 2FC79 ! ;

It also has the virtue of being understandable without requiring encyclopedic knowledge of how the assembler itself works.

Just use " ASMFIX4" LOADF into a new/empty FORTHRAM file and it will fix all the bugs any reasonable person is likely to encounter, and all the changes are 'invisible' in the sense that you can fully use the assembler as documented, with all specified features working as documented. It basically just fixes the real bugs.

[Erwin]

(11-25-2018 03:45 AM)rprosperi Wrote:  I also found a version of the F/A ROM assembler fixes that takes care of 4 out of 5 of the bugs, but does not make the drastic changes that the FIX5A version does.

Here is a version that circulated in a file called ASMFIX4

Code:

HEX
CREATE NEWB
42502 , B423D , 20422 , 5304 , 1000 ,
CREATE NEWD
44505 , 13D31 , 20534 , 39305 , 1 ,
: NEWCODE 2DUP
" B=B+B" S= IF 2DROP NEWB -1 ELSE
" D1=AS" S= IF NEWD -1 ELSE 0
THEN THEN ;
: ASSEMBLE
DECIMAL HERE PAD OVER - 0 NFILL
PAD 2+ DUP C@ 2* + 2+ SP@ 2DUP <
IF OVER - 0 NFILL ELSE 2DROP THEN
['] NEWCODE 2FC79 ! ASSEMBLE
0 2FC79 ! ;

It also has the virtue of being understandable without requiring encyclopedic knowledge of how the assembler itself works.

Just use " ASMFIX4" LOADF into a new/empty FORTHRAM file and it will fix all the bugs any reasonable person is likely to encounter, and all the changes are 'invisible' in the sense that you can fully use the assembler as documented, with all specified features working as documented. It basically just fixes the real bugs.

Hi,
fine that's an easy way :-) thanks for sharing

[J-F Garnier]

Let me add another small bug in the Forth Assembler, that has been recently reported to me by an eminent member of this community :-)

The Forth Assembler generates null-bytes at the end of some lines in the assembly listing (the file or device specified by the LISTING variable).
Null bytes have generally no effect on printers, but emu71/Dos and the ILper printer show null bytes as star '*' characters (for a good reason), and can make the listing file quite obscure.
The effect can be noticed when the listing file is the Emu71 display, or the ILPer printer window, or a HP71 file that is later printed to Emu71 or ILPer by PLIST.

When using Emu71 or ILPer, a workaround is to use a HP71 file as the listing destination, and then use LIST (and not PLIST) to list or print it.
Note also that null-bytes are also generated if the listing file is the DOSLINK device, but just editing the PC file with notepad (for windows systems) replaces the null bytes by space characters.

J-F

[Christoph Giesselink]

Does it still make sense to use the HP-71 Forth/Assembler ROM for new projects?

No doubt, it will be complicated to translate any Forth programs into another programming language. It also will be a little bit difficult to replace the Assembler Macros to make LEX programming more easily?

So is ASM71 the right way?

I think not. Some years ago I began writing some very easy test programs to check the behavior of the HP-IL ROM on requests over the HP-IL mailbox. The first steps I made with HP-71 Forth/Assembler, but entering the code with an HP-71 editor is IMHO horrible. So my development process was writing the source code on the PC as ASCII file, convert the file into a TEXT1 file to transfer it with DOSLINK to the HP-71 and then compile it with the Forth/Assembler ROM.

For me is ASM71 another brick in the wall of Star Assembler, AREUH, CLASS, GNU-Tools, ...

All common, these are Saturn assemblers from a time HP hasn't published his own development tools.

So my reference is the HPTools assembler package v3.0.9. With this assembler I wrote my HP48 SysRPL and Assembler programs, was able to do the same thing with the HP49G, could compile the Aplet/eLesson framework files for the HP38G/HP39G. Back to the roots I used HPTools v3 to write the HP28C ROM upload program with the opcode restrictions of the 1LK7 CPU.

Finally I created with the help of the HP-71 JPC ROM and other sources a small framework for compiling LEX files on the PC:

Code:


    TITLE LEX TEST
* ***********************************
* ENTRY POINTS
* ***********************************
=FNRTN1    EQU    #0F216

* ************************
* --LEX    header--
* ************************
    CON(2)    #5D        LEX ID
    CON(2)    #01        LOWEST TOKEN
    CON(2)    #04        HIGHEST    TOKEN
    CON(5)    0        NEXT LINKED LEX
    NIBHEX    F        NO SPEED TABLE
    CON(4)    (TxtbSt)+1-(*)    OFFSET TO TEXT TABLE
    CON(4)    0        OFFSET TO MESSAGE TABLE
    CON(5)    0        OFFSET TO POLL HANDLER
* ************************
* ------MAIN TABLE------
* ************************
    CON(3)    (ONEt)-(TxtbSt)
    REL(5)    ONEf
    NIBHEX    F        keyword is a BASIC function

    CON(3)    (TWOt)-(TxtbSt)
    REL(5)    TWOf
    NIBHEX    F        keyword is a BASIC function

    CON(3)    (THREEt)-(TxtbSt)
    REL(5)    THREEf
    NIBHEX    F        keyword is a BASIC function

    CON(3)    (FOURt)-(TxtbSt)
    REL(5)    FOURf
    NIBHEX    F        keyword is a BASIC function

* ************************
* ---Text table---
* ************************
TxtbSt

* names must be in alphabetical order

FOURt    CON(1)    (+)-(*)-2    cmdlen * 2 - 1
    NIBASC    \FOUR\
+    CON(2)    #04        TOKEN ID (entry in main table)

ONEt    CON(1)    (+)-(*)-2    cmdlen * 2 - 1
    NIBASC    \ONE\
+    CON(2)    #01        TOKEN ID

THREEt    CON(1)    (+)-(*)-2    cmdlen * 2 - 1
    NIBASC    \THREE\
+    CON(2)    #03        TOKEN ID

TWOt    CON(1)    (+)-(*)-2    cmdlen * 2 - 1
    NIBASC    \TWO\
+    CON(2)    #02        TOKEN ID

TxTbEn    NIBHEX    1FF        TEXT termination
*
********************************
* ONE entry
********************************

* IDS v1 7.5.1 Entry point
*    NIBHEX    8        bit parameter numeric
*    NIBHEX    4        bit parameter string
*    NIBHEX    2        bit parameter array
*
*    NIBHEX    C        3rd parameter numeric or string (if present)
*    NIBHEX    8        2nd parameter numeric
*    NIBHEX    4        1st parameter string
*    NIBHEX    23        argument count range (min=2,max=3)

    NIBHEX    00        argument count range (min=0,max=0)
ONEf    CON(3)    #024        NOP3 break for Emu71
        C=0     W               Clear all digits in register C.
        P=      14              Set the pointer register to the most-significant
        LCHEX   1               Load the most-significant digit in register C's
        GOVLNG  FNRTN1          Send the result back to the system.

********************************
* TWO entry
********************************
    NIBHEX    00        argument count range (min=0,max=0)
TWOf    CON(3)    #024        NOP3 break for Emu71
        C=0     W               Clear all digits in register C.
        P=      14              Set the pointer register to the most-significant
        LCHEX   2               Load the most-significant digit in register C's
        GOVLNG  FNRTN1          Send the result back to the system.

********************************
* THREE entry
********************************
    NIBHEX    00        argument count range (min=0,max=0)
THREEf    CON(3)    #024        NOP3 break for Emu71
        C=0     W               Clear all digits in register C.
        P=      14              Set the pointer register to the most-significant
        LCHEX   3               Load the most-significant digit in register C's
        GOVLNG  FNRTN1          Send the result back to the system.

********************************
* FOUR entry
********************************
    NIBHEX    00        argument count range (min=0,max=0)
FOURf    CON(3)    #024        NOP3 break for Emu71
        C=0     W               Clear all digits in register C.
        P=      14              Set the pointer register to the most-significant
        LCHEX   4               Load the most-significant digit in register C's
        GOVLNG  FNRTN1          Send the result back to the system.
    END

Something heard about the MASD syntax?

It's easily spoken a macro language extension for writing assembler programs more structural. It became important, when HP introduced the HP49G and some sample programs especially for this calculator used this syntax. HPTools v3 supports this also.

For me, one compiler fits all in the Saturn CPU world.

[rprosperi]

(11-26-2018 07:33 PM)Christoph Giesselink Wrote:  So my reference is the HPTools assembler package v3.0.9. With this assembler I wrote my HP48 SysRPL and Assembler programs, was able to do the same thing with the HP49G, could compile the Aplet/eLesson framework files for the HP38G/HP39G. Back to the roots I used HPTools v3 to write the HP28C ROM upload program with the opcode restrictions of the 1LK7 CPU.

Finally I created with the help of the HP-71 JPC ROM and other sources a small framework for compiling LEX files on the PC...

Thanks Christoph, for your comments and especially for sharing the LEX file template; this is extremely similar to the style proposed by John Baker back when he was busily writing almost everything for the 71B. For simple/small LEX files, the macro pseudo-ops in the F/A ROM assembler work fine, but I can understand your goal of wanting to use a single tool suite for all the Saturn targets!

Do you know where the HPTools pkg v3.0.9 is available to download? I naturally thought it may be on hpcalc.org, but the latest version I see there is v3.0.8 (awfully close of course, but no doubt 3.0.9 was released for a reason....)

[Dave Frederickson]

(11-26-2018 10:48 PM)rprosperi Wrote:  Do you know where the HPTools pkg v3.0.9 is available to download?

I suspect v3.0.9 is for Mac.

http://www.hpmuseum.org/forum/thread-799...l#pid70084

[rprosperi]

(11-26-2018 11:19 PM)Dave Frederickson Wrote:  I suspect v3.0.9 is for Mac.

http://www.hpmuseum.org/forum/thread-799...l#pid70084

He may have the Mac version too, but I know Christoph doesn't build on a Mac so it appears he has both Win & Mac (and maybe Linux too).

[Christoph Giesselink]

(11-26-2018 10:48 PM)rprosperi Wrote:  Do you know where the HPTools pkg v3.0.9 is available to download? I naturally thought it may be on hpcalc.org, but the latest version I see there is v3.0.8 (awfully close of course, but no doubt 3.0.9 was released for a reason....)

I build my Windows version in 2008/2010 from the 3.0.9 SVN sources at bubblestuff.com dated Apr. 29th, 2011, which base on the sources from 2008 for the MAC. In the SVN sources from 2011 is a patch for SLOAD I made 2010. SLOAD calculated a wrong HP-71 checksum, when the checksum is on an odd address.

The bubblestuff repository is not accessable any more, wether the public or the developer access.

Official 3.0.9 change log:

3.0.9: Thanks to William Graves
- Project File for MS Studio 2008
- Fixed signed/unsigned mismatches in sload