FORTH for the SHARP PC-E500 (S)

[robve]

Happy to announce an update

Forth500 with floating point

GitHub Forth500 repo

The complete Forth standard FLOAT word set and most of the FLOAT-EXT word set are now available in Forth500:
>FLOAT
D>F
F!
F*
F+
F-
F/
F0<
F0=
F<
F>D
F@
FALIGN
FALIGNED
FCONSTANT
FDEPTH
FDROP
FDUP
FLITERAL
FLOAT+
FLOATS
FLOOR
FMAX
FMIN
FNEGATE
FOVER
FROT
FROUND
FSWAP
FVARIABLE
REPRESENT
DF! (not built-in, but same as F!)
DF@ (not built-in, but same as F@)
DFALIGN (not built-in, but same as FALIGN)
DFALIGNED (not built-in, but same as FALIGNED)
DFFIELD: (not built-in, but same as FFIELD: )
DFLOAT+ (not built-in, but same as FLOAT+)
DFLOATS (not built-in, but same as FLOATS)
F**
F.
F>S
FABS
FACOS
FACOSH (not built-in, see manual how to add)
FALOG (not built-in, see manual how to add)
FASIN (not built-in, see manual how to add)
FASINH (not built-in, see manual how to add)
FATAN
FATAN2 (not built-in)
FATANH (not built-in, see manual how to add)
FCOS
FCOSH (not built-in, see manual how to add)
FE. (not built-in)
FEXP
FEXPM1 (not built-in)
FFIELD:
FLN
FLNP1 (not built-in)
FLOG
FS.
FSIN
FSINCOS (not built-in)
FSINH (not built-in, see manual how to add)
FSQRT
FTAN
FTANH (not built-in, see manual how to add)
FTRUNC
FVALUE (not built-in, see manual how to add)
F~ (not built-in, see manual how to add)
PRECISION
S>F
SET-PRECISION
SF! (not built-in, but same as F!)
SF@ (not built-in, but same as F@)
SFALIGN (not built-in, but same as FALIGN)
SFALIGNED (not built-in, but same as FALIGNED)
SFFIELD: (not built-in, but same as FFIELD: )
SFLOAT+ (not built-in, but same as FLOAT+)
SFLOATS (not built-in, but same as FLOATS)

I left the hyperbolic out to save code space and keep Forth500 under 20KB. These can be easily added, see the Forth500 manual.

Note that single (10 digit) and double (20 digit) floating point precision is supported. All Forth500 floating point words operate both on single and double precision floating point values.

Other updates

• Added Forth standard REQUIRE and REQUIRED and extra -CHARS and PAUSE words.
• Improved dictionary search speed
• Support BREAK and C/CE to stop FILES and WORDS listing
• Closes the file after INCLUDE, INCLUDED, REQUIRE and REQUIRED failed
• OK[n] now shows as OK[n m] if the floating point stack is not empty with m values
• Error messages show the part of the input line where the error occurred
• Cursor blinks after an error occurred and after an ABORT or QUIT and when Forth500 starts
• Some speed improvements and code size reductions
  

Notes

The Forth500.bin file size has increased to 20329 bytes, 1869 bytes more than the previous version. The additional floating point stack requires 96 bytes for up to 8 floats. This still leaves almost 1K for BASIC and 6807 bytes for Forth programs on an unexpanded E500(S) and 43671 bytes for Forth programs on an expanded E500(S).

Initially I had estimated that the floating point word sets would require up to 2K of code space with optimized assembly code.

Luckily I was able to achieve that goal, but there were many unexpected challenges along the way to get there. I had written most of the assembly code template already weeks ago shortly after announcing that it was possible to add the floating point words sets to Forth500. The floating point stack and stack manipulation words were straightforward to implement by exploiting internal RAM as a scratchpad area. The internal RAM area of 256 bytes is also used by syscalls, which means I have to avoid conflicts or save the Forth500 internal RAM values before making the syscall to restore them afterwards. This issue became apparent with the floating point arithmetic using the "function driver" syscall. This syscall uses some internal RAM areas that are not documented in the technical reference manual. With some experimentation by dumping internal RAM to external RAM and inspecting it with Forth DUMP or post-mortem dumping in BASIC, it became clear that internal RAM BP-$20 was used (BP is the internal RAM Base Pointer by which internal RAM access can be made relative to the BP, i.e. kind of like a "register file window" which is nice).

After a bit of fiddling with this code, I settled on assigning the floating point work/scratch area at $70 in internal RAM and set the BP address to $70 like before, but in order to accommodate the floating point working area I had to move the 8-, 16- and 20-bit internal RAM registers up by an offset of 32. My attempt to move the floating point work/scratch area above the Forth500 internal RAM registers failed because of the syscall's internal RAM usage below the current BP (again, no word about this in the technical reference manual). These failed attempts led to RAM dumps, code changes and more dumps to figure out what the "function driver" syscall changed and under what conditions.

After fixing that, I ran into another problem. Adding 2.0e+3.0e returned 15.0e. What on earth!? Apparently, the "carry byte" is still used by the syscall! The carry byte allows the mantissa to overflow so it can be shifted to the right afterwards, without overwriting the exponent. To explain this, the internal format of a BCD float is laid out in bytes as follows:

(sign)(exponent)(carry)(BCD)...(BCD)(correction)(correction)

which takes 15 bytes to accommodate double precision floating point values with 10 BCD bytes for 20 digits. Note that in Forth500 we only need to store the relevant 12 bytes of a (double) floating point value. The technical reference manual states that the carry and correction bytes are "only used during operations and calculations" but evidently they must be cleared before calling the "function driver" to avoid 2.0e+3.0e=15.0e to correctly get 2.0e+3.0e=5. Phew!

By the way, the correction bytes are for roundoff. Single precision uses one correction byte with 2 digits. Double precision uses two correction bytes with 4 digits. Therefore, internally the E500(S) uses 12 and 24 digit calculations, respectively. I remember that all SHARP calculators use 12 digits internally but only 10 to display and store values in variables. Because the correction bytes appear to affect the computation, I suppose it might be possible to actually use these extra digits. Cool! But have not tried that yet.

Next I ran into some limitations of the "function driver" syscall. Apparently (again, not documented in the technical reference manual) the binary->decimal and decimal->binary operations only support up to 20 bits. That's not good enough to convert 32 bit double cells to floats and back with D>F and F>D. So back to the drawing board to write both routines in assembly from scratch.

Finally, the "function driver" syscall to convert a string to a floating point value (the BASIC VAL keyword) did not work at all like the (very lightly) documented manual stated. The U stack pointer changes (increased by 2) for no reason and the resulting float is always zero. No error value is returned. The way a string is passed to the syscall is by populating a float with a magic byte $80, the 20 bit pointer followed by the length of the string. After some fiddling with the code and RAM dumps, nothing I tried made this string->float syscall work. So back to the drawing board to write my own routine in assembly. Because string->float conversion should support both single and double precision floats, while meeting the Forth standard, and making sure all error conditions are triggered properly, I ended up with a bit more assembly code than I had anticipated.

Along the way it was fun to come up with shorter and more efficient versions of assembly code for some common tasks in Forth500. So I incorporated these little "hacks" too to improve Forth500.

I checked the Forth500 implementation over the last couple of days, but only when I had time, to see if I could break anything. So far this version works like a charm. On the other hand, my experience with the "function driver" syscall makes me a bit uneasy to feel 100% confident to be honest. SHARP should have at least offered a bit more information about this system call interface other than a table of functions supported and a sparsely written page with very basic information about this syscall.

I realize that Forth500 can still be made to run faster by 10% or so. But I will do that later. First I'm going to enjoy it a bit more to do some actual Forth programming

- Rob

[Helix]

Fantastic work!
Thank you very much, Rob

[Klaus Overhage]

It's a round thing: an extensive programming language including a detailed manual (65 pages are printed out). Thank you for that Rob, I'm thrilled. Now there are floating point numbers, so Forth go ahead and draw a sine curve in the display.
   

Code:

\ SIN-DEMO.FTH
.( Loading SIN-DEMO... )
ANEW _SIN-DEMO_

3.141592654e FCONSTANT PI

: fdx        \ step size in radians 
 4e PI F* 240e F/ ;

: sin-demo
PAGE
240 0 DO
I               \ x of pixle-coordinate
I S>F fdx F*    \ x in radians
FSIN 1e F+      \ y between 0 and  2
15.5e F*        \ y between 0 and 31
FROUND F>S
GPOINT
LOOP ;

sin-demo

From Forth500 with INCLUDE COM: loaded and started. (I previously set the PC-E500 to RAD in BASIC mode with Shift-DRG.)

[robve]

Klaus, thanks for sharing this nice little graphing demo.

Have you noticed how much easier and safer it is to use Forth500 now compared to the previous version?

I hope you can help me out here: I'm looking for including the serial file loading instructions in the Forth500 instructions, see e.g. the "E500-expanded" folder in the repo. In the meantime the repo points to this thread for instructions to load Forth500 over serial. But that means that someone has to sift through this thread to find it.

By the way, there is still one tiny little thing that annoys me when an exception occurs and the input line is longer than 40 characters then cursor left/right to edit the line displays the line, but places it at the wrong line on the screen. Another cursor movement to edit corrects this, but it is not perfect. I had tried to fix this before, but I need some time to figure out why the E500 cursor placement in this case is trickier than I had assumed.

- Rob

[Klaus Overhage]

Yes, it is much easier to try out source code from other Forth implementations because the error message shows the unknown word that needs replacing. So I stumbled upon rdrop and 0<= , which are probably in Gforth. I can deal with that now, thank you very much.

If you are looking for a solution for all PC-E500 serial transmission, then Helix has found it with its BASIC program. I don't know of any other way to write the Forth500.bin, which is around 20k bytes in size, to the upper RAM without going through the RAM disk.

I have just tried HTerm and SAVE also worked, but LOAD together with "Send file" always leads to an I/O error. That may be due to my interface: It is an old RS232 interface "IF-133" that is plugged into a COM1 socket of a PC. It was specially developed for Sharp computers at the time and has these signal lines on the 25-pin DSUB connector:
2 yellow RX input
3 white TX output
4 green RTS output
7 brown GND ground
20 blue DTR output
The specialty is that it has no line for the CTS signal. With the MBSharpNotepad I select XON/XOFF handshaking and RTS Enable (see photo) and it works.
   
Since there are different serial interfaces, your installation description should simply assume that the reader already knows what to enter on the PC in order to start the serial transmission. Then you should put Helix 5-line program in two variants for expanded and unexpanded and also the two BIN files converted into a series of numbers with Helix BINTOASC.EXE.

Do you want to describe the use of UUDECODE and LOADM as a second way for PC-E500 with 64K or more? You could/should extend the expanded version of the Forth500.bin by 16 bytes with BINTOPCE.EXE and convert it into a UUE file with UUENCODE.EXE, which you can enclose.

[robve]

(11-06-2021 10:40 AM)Klaus Overhage Wrote:  Do you want to describe the use of UUDECODE and LOADM as a second way for PC-E500 with 64K or more? You could/should extend the expanded version of the Forth500.bin by 16 bytes with BINTOPCE.EXE and convert it into a UUE file with UUENCODE.EXE, which you can enclose.

Thanks for the info, this helps. Yes, I want to include two FORTH500.UUE files, one for an expanded E500(S) and one for an unexpanded E500(S). These EXE programs are great, but I'm not much of a Windows user and often end up rewriting EXE programs myself in bash scripts or in C/C++. I'm pretty sure that UUENCODE.EXE converts the binary with the extra 16 bytes to the standard uuencode format. There is software available to convert. On the other hand, the FORTH500.UUE file that we require may perhaps include other data (besides the 16 bytes) produced by UUENCODE.EXE. Such extra data may be required to decode the file on the receiving end. Since I don't have a serial cable yet and can't try this out to verify if it works, I'll stick to using BINTOCPE.EXE and UUENCODE.EXE for the time being. I will include the serial transfer information in the READMEs and add the UUE files to the Forth500 GitHub repo.

Some good news!

I've updated Forth500 to fix the long line editing glitches. Lines up to 255 characters long are now editable without issues. To do so I had to rewrite a core part of the editor from scratch.

In the meantime I also added an FVALUE definition with corresponding TO for completeness (and FVALUE? (FVAL) and (FTO) words).

Despite these additions, the new Forth500 executable is 93 bytes shorter (20236 bytes)

- Rob

[robve]

(11-06-2021 10:40 AM)Klaus Overhage Wrote:  Do you want to describe the use of UUDECODE and LOADM as a second way for PC-E500 with 64K or more?

The Forth500 GitHub repo for the expanded E500 is updated with uudecode instructions to transfer Forth500 over serial. Also the necessary files are included.

Please check the instructions and files.

I have some questions:
- Why is it necessary to rename `UUDECODE.` to `UUDECODE.MMM`. Is that necessary? I left that part out.
- Is `FORTH500.BIN` created or `FORTH500.`? I prefer the former, but wonder if that is possible because the UUDECODE tool auto-selects `FORTH500.`?

- Rob

[Klaus Overhage]

If you run UUDECODE.BAS unchanged with RUN, this appears in the display:
RUN
UUENCODE SELF-DECODER
DRIVE(E/F) =E <Return>
DATA_fILE='UUDECODE.'
OK? (Y/N) =Y <Return>
Success

FILES "E:" then displays this new file: UUDECODE.NLNLNL 1446 Byte
The file name ends with three characters that each represent an N over an L and, according to the character set table in the manual, stand for the value 0 and probably mean NULL. I did not succeed in doing anything with this file: It can neither be loaded nor deleted. I had to erase my RAM disk with INIT "E:" to get rid of it.

I assume E.Kako chose this file name with confidence because it cannot be accidentally loaded or deleted. But how did he plan to use it? Probably it only comes with the help of one of the other extensions, which were common at the time and may still be found here.
http://www.kako.com/neta/1999-017/e5soft.html
Until this puzzle has been solved, the file name at the beginning of UUDECODE.BAS must be supplemented by a three-character extension, otherwise the generated file cannot be used with LOADM.

After CALL &BE000"COM: the file "FORTH500." is created. It is the name of the input file for UUENCODE.EXE. This name is in the first line of the FORTH500.UUE file.

Now I will check the instructions and files in GitHub.

[robve]

(11-07-2021 01:00 PM)Klaus Overhage Wrote:  FILES "E:" then displays this new file: UUDECODE.NLNLNL 1446 Byte

Got it. Changing FNAME$="UUDECODE.BIN" should fix this to produce a .BIN file to prevent the garbled extension (it can be deleted with FILES then cursor to the filename and press K to KILL). There is also the line begin 644 uudecode. in UUDECODE.BAS to self-load the binary decoder. I suppose this line doesn't need to be changed.

(11-07-2021 01:00 PM)Klaus Overhage Wrote:  After CALL &BE000"COM: the file "FORTH500." is created. It is the name of the input file for UUENCODE.EXE. This name is in the first line of the FORTH500.UUE file.

I see. This means that the line in FORTH500.UUE does not include a filename extension: begin 644 forth500

Thanks for pointing this out. I've updated the instructions.

Some observations:

These steps aren't possible with an unexpanded E500 because the UUDECODE.BAS file is too large to fit in the remaining BASIC space after reserving memory for Forth500. The FORTH500. file isn't the problem with a 32K RAM card to save it to on the F: drive. However, the UUDECODE.BAS approach seems unnecessarily complicated to produce the FORTH500. file first, then having to load it from disk to memory. There is no UUENCODE/UUDECODE option to expand the file in memory directly, which would have been nice. In that case we don't need any extra RAM card. I could rewrite UUDECODE.BAS and UUDECODE.ASM to expand the file in memory. A custom Forth500 serial loader would make the loading process simpler and potentially doable with an unexpanded E500.

- Rob

[Klaus Overhage]

I assume you mean the file UUDECODE.ASM from the archiv uudecode.zip from
http://www.andrewwoods3d.com/pce500
I think it's the back part of UUDECODE.BAS, the part. which is saved in the file UUDECODE.MMM. It can remain unchanged. The problem with the filename extension is caused by the demanding part, which for the most part also consists of machine code but for which there is no source code.

The UUDECODE.UU file in the uudecode.zip archive contains an older version of UUDECODE.BAS. In this, the demanding part looks completely different and the one behind is exactly the same. So it loads the same version of UUDECODE, just different.

UULOAD.BAS from the same archive seems to be an implementation in BASIC of the way you suggested: It reads in a UUE file via the COM interface, checks whether the first 16 bytes are as requested by LOADM and writes the bytes directly into the upper RAM. I tried it with FORTH500.UUE: It only worked 10% after 4 minutes, so I canceled it.

Please remember that UUDECODE.BAS only has to run once and can then be deleted directly. Only UUDECODE.MMM is required to load FORTH500.UUE. If you change UUDECODE.ASM so that it does not write to a file but directly to RAM, then that should also work with a 32K PC-E500. And the required part of UUDECODE.BAS could still be used for loading.

After LOADM "UUDECODE.MMM" you could enter
KILL "UUDECODE.MMM"
SAVE M "UUDECODE", & BE000, & BE595
Unfortunately, the KILL command is not programmable; you have to issue it manually.

[robve]

(11-07-2021 05:44 PM)Klaus Overhage Wrote:  UULOAD.BAS from the same archive seems to be an implementation in BASIC of the way you suggested: It reads in a UUE file via the COM interface, checks whether the first 16 bytes are as requested by LOADM and writes the bytes directly into the upper RAM. I tried it with FORTH500.UUE: It only worked 10% after 4 minutes, so I canceled it.

BASIC decoding is too slow to keep pace with the serial interface.

The UUDECODE.ASM implementation isn't complicated and the code is actually a bit convoluted. It has a lot of unnecessary extras that can be removed. Since we only want to read the uu file from COM:, the code that parses the argument passed to the decoder as a CALL argument can be removed. The file to create and write is not needed when saving the decoded data directly to memory. The display messaging, error reporting and uu file header parsing can be removed to significantly reduce the code size to a bare minimum. I played a bit with this to "trim the fat" by removing all non-essential parts and got the machine code down to 453 bytes. To bootload this code via BASIC with POKEs in hex will be more than 1K, a tad too large if 950 bytes of BASIC are available when space is allocated for Forth500 unless we move Forth500 up in memory by one or more page sizes (multiples of 256 bytes). With only 400 bytes or so remaining, rewriting UUDECODE.ASM appears an option, BUT... I cannot try it out to test it. Unfortunately, my CE-134T doesn't work with low RS232 USB dongle voltage levels. I'm glad to have received suggestions to DIY a serial interface, but I'm concerned with overvoltage levels or ESD damaging the E500.

- Rob

[robve]

(09-15-2021 11:51 PM)xerxes Wrote:  

(09-12-2021 02:00 AM)robve Wrote:  - improved execution speed and reduced code size

I'm really impressed. I no longer expected the project to be completed.
Would be nice to have Forth500 in the n-queens benchmark list too.

Forth500 n-queens benchmark on the PC-E500S: 4.15s

A little over 4 seconds on a standard PC-E500S machine with no enhancements.

By comparison, BASIC takes 1:19 minute and assembly code is of course the best at 0.114s.

I ran NQUEENS four times to get 16.6s repeatedly with +/- 0.2s deviation in the 16.6s stopwatch timing. The value S=876 is displayed.

The n-queens code in standard Forth using VALUEs instead of VARIABLEs:

Code:

8 CONSTANT RR
0 VALUE SS
0 VALUE XX
0 VALUE YY
CREATE AA RR 1+ ALLOT

: RCLAA POSTPONE AA POSTPONE + POSTPONE C@ ; IMMEDIATE
: STOAA POSTPONE AA POSTPONE + POSTPONE C! ; IMMEDIATE

: NQCORE
  0 TO SS
  0 TO XX
  BEGIN
    1 +TO XX RR XX STOAA
    BEGIN
      1 +TO SS
      XX TO YY
      BEGIN YY 1 > WHILE
        -1 +TO YY
        XX RCLAA YY RCLAA - DUP
        0= SWAP ABS XX YY - = OR IF
          0 TO YY
          BEGIN XX RCLAA 1- DUP XX STOAA 0= WHILE
            -1 +TO XX
          REPEAT
        THEN
      REPEAT
    YY 1 = UNTIL
  RR XX = UNTIL
;

: NQUEENS
  NQCORE
  ." S=" SS .
;

- Rob

[Klaus Overhage]

This is place 103 of 450 entries in the list of the Calculator Benchmark and significantly faster than the other Forth implementations!
http://www.hpmuseum.org/cgi-sys/cgiwrap/...i?read=700
Perhaps your PC still has space for a PCI-Express serial card, then you could connect your CE-134T to it. I use a Fujitsu S720 as a quiet second PC. I bought it a year ago from TOS with 4GByte RAM and 120GByte SSD including pre-installed Windows 10. It is completely sufficient for surfing and PDF reading and it has a 9-pin serial RS232-interface, to which I plugged in the interface for the Sharp with an adapter cable to 25-pin. The S720 has a DVI connector as a monitor output. There are inexpensive adapters from DVI to HDMI. I also bought a Cherry JG-07 Wireless Keyboard ncluding mouse.

[xerxes]

(11-08-2021 04:22 AM)robve Wrote:  Forth500 n-queens benchmark on the PC-E500S: 4.15s

Thank you for testing Forth500. It's much faster than I would have guessed. It's on the same level with the PC-G850VS with it's C bytecode compiler,
although the PC-G850VS runs at 8.0 MHz much faster than the PC-E500S at 2.3 MHz. The only more efficient on-calc language on a classical pocket
computer is the Pascal compiler of the PB-2000C with 1.27 seconds at 0.91 MHz.

Forth500 is very well done and a real enrichment for the pocket computer fans.

[Klaus Overhage]

Test Suite & Date calculation
I was curious whether the test suite works with Forth500. (https://forth-standard.org/standard/testsuite)
And the answer is yes, absolutely no problem. The zip archive attached below contains the file TTESTER.FTH. It starts with the lines

Code:

    \ TTESTER.FTH
    .( Loading TTESTER... )
    ANEW _TTESTER_

so that after INCLUDE COM: a message appears in the display and you can later delete the test suite from the dictionary with FORGET _TTESTER_ . This is followed by the source code of the test suite (with fewer comment blocks) and three examples at the end of TTESTER.FTH:

Code:

    T{ 1 2 3 swap -> 1 3 2 }T
    T{ 1 2 3 swap -> 1 2 2 }T
    T{ 1 2 3 swap -> 1 2 }T

The two reported errors indicate the successful completion of loading.

The first time I saw lines with T{ }T when calculating dates in Forth on this page:
https://forth-ev.de/wiki/examples:daymonthyear
But this page shows an example for Gforth and in Gforth a cell has 32 bits. For the Forth500 with its 16 bits per cell, double values ​​and double functions must therefore be used in many places. Thanks to the test suite and the many test cases, I was able to check the conversion to double. The result is the DATE.FTH file in the attached zip archive. At the end of DATE.FTH there are two examples:

Code:

    2021 12 25 ymd2day 2dup day2dow weekday CR
    2021 11 13 ymd2day D- D.

The display shows after successful loading:
Saturday
42
The first day of Christmas is a Saturday and there are still 42 days until then.

The file DATETEST.FTH contains the many test cases. If you load TTESTER.FTH and DATE.FTH beforehand (regardless of the order) then the test cases will be executed with INCLUDE COM: when DATETEST.FTH is loaded. Loading takes 100 seconds and immediately afterwards "passed successful" appears on the display. The test cases are therefore executed during loading!

The function (ymd2day) on the website is not entirely correct. The error-free version is shown on page 16 of this pdf
https://forth-ev.de/wiki/res/lib/exe/fet...018-04.pdf
(ymd2day) contains an additional 1+ at the end. That the day2dow function contains a 1+ instead of a 2+ is more a matter of taste.

It would be interesting to know whether the code coverage as described in this article for Gforth can also be determined with Forth500. But this requires a number of very special functions that are not part of the standard, such as current-sourceview...

[robve]

(11-13-2021 12:07 PM)Klaus Overhage Wrote:  I was curious whether the test suite works with Forth500. (https://forth-standard.org/standard/testsuite)
And the answer is yes, absolutely no problem.
[...]
The result is the DATE.FTH file in the attached zip archive. At the end of DATE.FTH there are two examples:

Code:

    2021 12 25 ymd2day 2dup day2dow weekday CR
    2021 11 13 ymd2day D- D.

The display shows after successful loading:
Saturday
42
The first day of Christmas is a Saturday and there are still 42 days until then.

Thanks for testing Forth500 and for providing a very useful example.

I've added DATE.FTH to the Forth500 additions on GitHub. I also added a new SEE.FTH decompiler and a Galton board demo GALTON.FTH. I plan to add more examples. Contributions to Forth500 are more than welcome

With the new CLOAD Forth500 command, I can load any Forth program without a problem with the CE-126P, not needing a serial cable to do so. Using option -dINV with PocketTools bin2wav fixed my wav transfer issues as suggested by Torsten Mücker, the PocketTools maintainer (I had helped him update PocketTools for the PC-E500 with new C code so that E500 BASIC images are fully compiled now with bas2img.) With -dINV I've not had a single transfer error. However, transfer over serial is nicer, because loading and compiling happen simultaneously. And serial is bidirectional. I'm waiting for a serial cable to arrive from Takamatsu Japan. They also offer 256KB FRAM cards for the PC-E500(S).

I made a small change to DATE.FTH. I noticed that you defined RDROP but R>DROP is already included in Forth500. Either one is not standardized, so some Forth's use RDROP and other use R>DROP. Either one makes logically sense: R>DROP means R> DROP and RDROP simply means to drop from the R stack. So use R>DROP instead of RDROP in Forth500. Also please note that I've included extra words <> and > for all numeric versions (<> > D<> D> 0<> 0> D0<> D0> F<> F> F0<> F0>) for consistency. Also note that <= and >= are not part of the standard either, but these can be easily defined using INVERT and the Forth500 < and > words that already exist:

Code:

: <=    > INVERT ;
: >=    < INVERT ;
: 0<=   0> INVERT ;
: 0>=   0< INVERT ;
: D<=   D> INVERT ;
: D>=   D< INVERT ;
: D0<=  D0> INVERT ;
: D0>=  D0< INVERT ;
: F<=   F> INVERT ;
: F>=   F< INVERT ;
: F0<=  F0> INVERT ;
: F0>=  F0< INVERT ;

If you want to get the best performance by inlining this code, then define them IMMEDIATE with POSTPONEd words:

Code:

: <=    POSTPONE > POSTPONE INVERT ; IMMEDIATE
: >=    POSTPONE < POSTPONE INVERT ; IMMEDIATE

However, these words can now only be used in definitions (i.e. when compiling) and not interpreted and executed on the command line unless their definitions include a branch to execute code when in interpreting.

Alas, Forth in general has no INLINE modifier (I think I can do that in Forth500 as its updated design allows something like that actually), but the result with IMMEDIATE and POSTPONE is the same, just a lot more code to write when the definition is long. But inlining long definitions won't keep compiled Forth compact. Inlining only two words like the ones above is useful though if you're keen to use these words instead of just writing > INVERT etc.

- Rob

[robve]

Happy to announce an update

Forth500 with complex arithmetic

Forth500 GitHub repo

This addition is based on the excellent Forth complex math library complex.fs which is "a revision of Julian V. Noble's complex arithmetic lexicon, with OpenMath principal expressions for inverse functions." The COMPLEX.FTH addition is located in the "additions" folder of the project.

Complex arithmetic is supported in single and 20 digit double precision. The COMPLEX.FTH source code file is 25K with all comments included, but compiles down to 3.2K.

The original complex.fs file loaded in Forth500 after making some minor adjustments in COMPLEX.FTH:
- removed the ENVIRONMENT? query "FLOATING-EXT" which is obsolescent. Forth500 supports FLOATING and FLOATING-EXT with FLOATEXT.FTH loaded. So I included FLOATEXT.FTH in COMPLEX.FTH.
- removed the 2*pi and pi/2 constants and changed the code slightly to support both DEG and RAD modes for polar coordinates.
- simplified fsignbit, because the E500(S) does not use the IEEE 754 floating point standard.

- Rob

[Helix]

Even if I rarely use complex numbers, it's certainly a nice addition!
Can I hope a text editor? Even a very simple one would be very useful to write and modify small definitions on the PC-E500.

[robve]

(11-24-2021 11:33 PM)Helix Wrote:  Even if I rarely use complex numbers, it's certainly a nice addition!
Can I hope a text editor? Even a very simple one would be very useful to write and modify small definitions on the PC-E500.

Good point.

The list of things I am working on, listed not in any particular order:

- a small uudecoder in assembly loaded with a small BASIC bootloader program to load Forth500 directly into memory, instead of copying to and from RAM files with the current UUDECODE.BAS. If I can get the size down to under 1K then this method will also work for 32KB E500(S) that have no RAM cards or internal memory expansions.

- speed improvements with an even faster fetch-execute cycle (Forth500 is indirectly threaded) and similarly optimizing other parts of Forth500 assembly code that convert 16 bit addresses to 20 bit addresses.

- a text file editor in Forth.

- add more additions to extend Forth500, e.g. I've already added a new Forth500-specific implementation of the SEE word to decompile Forth, added a new gforth-like TRY-IFERROR-THEN-ENDTRY specific to Forth500, and added a new FF. word to display floating point values as proper fractions with an error within the currently set PRECISION. These additions are defined in separate Forth files in the Forth500 repo and are not derived from any other libraries (on the web or elsewhere).

- add some Forth programs or games, write from scratch or perhaps port existing games (with proper acknowledgment and open source licenses).

If you can't wait for a new editor in Forth500, there is also a text editor for the E500 in BASIC called edit500 available at: http://www.andrewwoods3d.com/pce500/

Yesterday I received the USB serial cable for the E500 from Takamatsu. I'm happy with the high quality construction and internals of this device, which means I can safely test the new uudecoder via the COM: port. I also ordered a 256KB FRAM card from the shop that I use as additional RAM F: file system storage (i.e. MEM$="S2", but MEM$="B" is not possible).

The complex number library is #60 in the FSL. The reason I mentioned this is not so much that complex numbers are a necessity, but it is good to know that these advanced Forth numerical libraries compile and run with almost no change to the original source code, with only minor modifications that should not be surprising. As you can see from my earlier notes, if an FSL library does not load, then it is likely because it is checking the obsolescent FLOATING-EXT environment.

In the meantime I have several other projects/work going on, so this will have to take a few days, if not a few weeks.

- Rob

[Helix]

I'm still learning Forth, following the book Starting Forth 2nd edition. (I know it's outdated, but it's didactic and enjoyable. I have also the Forth Programmer's Handbook for a more modern reference.)

I have a problem with the KEY? word. If no key is pressed, it returns "error -57" instead of 0.
The same problem occurs with EKEY? Furthermore, if a key is pressed, EKEY? returns 255. I think it should be -1.