FORTH for the SHARP PC-E500 (S)

[Helix]

Some of you may be interested:
http://www.silicium.org/forum/viewtopic....62#p559662
https://github.com/Robert-van-Engelen/Forth500
I still have to make a serial cable to transfer programs, so I can't test it for now. I hope floats will be implemented.

[robve]

(09-06-2021 11:41 PM)Helix Wrote:  Some of you may be interested:
http://www.silicium.org/forum/viewtopic....62#p559662
https://github.com/Robert-van-Engelen/Forth500
I still have to make a serial cable to transfer programs, so I can't test it for now. I hope floats will be implemented.

The good news is that Forth500 is already complete, functional and tested, except for floating point, but which will be supported! Testing the E500 floating point function drivers in assembly went well today. The drivers support fp operations on single and double floats, 10 digits for single and 20 digits for double precision mantissa in BCD, -99 to +99 exponent.

The bad news is that don't have time to write the required machine code for some time. I hope to get back and have fun continuing with this project in about five weeks.

I honestly did not use Forth much since writing Forth 83 code in the 80's, so my Forth was a bit rusty. It came all back rather quickly

Sébastien Furic did a great job many years ago on his ANS pceForth implementation for the E500, which is pretty standard following the traditional dictionary structure and word calling conventions. But the old implementation was definitely not standards compliant, had some bugs and could not support some more advanced Forth methodologies, such as "caller cancelling" and "continuation passing" to name a few.

Finding documentation on the E500 CPU and system internals was made possible by sharppocketcomputers.com and others. I managed to got hold of the XASM assembler Pascal source code, translated the documentation to English and made a few changes to compile XASM with FreePascal.

I've largely rewritten the assembly and builtin Forth definitions in the 11KLOC Forth500 system source code:
- ensure standard Forth compliance (forth-standard.org) by adding missing definitions
- fixed/avoided several bugs in the old ANS pceForth implementation
- changed to case insensitive dictionary lookup
- improved execution speed and reduced code size
- improved robustness to Forth coding errors by adding stack overflow/underflow checks and dictionary overflow checks, while sill improving speed (i.e. rewrite in assembly).
- added support for printing to the CE-126P or RS232 printer via output redirection
- improved file system access commands
- improved/added graphics drawing commands and screen blitting

The Forth500 system occupies about 18K with 8.5K free space on an unexpanded 32K E500 and a (whopping) 45K free space on an expanded E500.

I don't have a serial cable (well I have the CE-134T but it won't work with a USB RS232 cable due to undervoltage). I load the object code via a wav file and cassette interface of the CE-126P printer.

- Rob

[Helix]

(09-12-2021 02:00 AM)robve Wrote:  The good news is that Forth500 is already complete, functional and tested, except for floating point, but which will be supported! Testing the E500 floating point function drivers in assembly went well today. The drivers support fp operations on single and double floats, 10 digits for single and 20 digits for double precision mantissa in BCD, -99 to +99 exponent.

Great ! It looks very promising
In fact, I don't know Forth very well. I just read the beginning of "Starting Forth", tried various Forth versions for MS-DOS, but I did not continue. It would be a nice occasion to learn Forth more seriously.
I hope I will succeed in transferring data with a serial cable.

[robve]

(09-12-2021 11:40 PM)Helix Wrote:  In fact, I don't know Forth very well. I just read the beginning of "Starting Forth", tried various Forth versions for MS-DOS, but I did not continue. It would be a nice occasion to learn Forth more seriously.

There are very few Forth introductory texts (and serious texts) that do a decent job explaining and demonstrating Forth programming "philosophy" (for lack of a better word), because Forth is not only about pushing and popping stuff on stacks.

The following video does a really good job by walking through a realistic Forth project, where he explains his decisions and his approach to solve the problem and how to refactor Forth code: https://www.youtube.com/watch?v=mvrE2ZGe-rs

He assumes a basic understand of Forth, i.e. how the dictionary works and the two stacks are used. The Forth500 dictionary structure is traditional and should be easy to follow, which helps to internally visualize the concept.

- Rob

[xerxes]

(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.

The already tested Forth implementations on pocket computers:

Code:


 55.0    HP-71B         Forth / Forth/Assembler ROM Module HP-82441A / Ver.1A
 45.1    HP-71B         Forth / HP-41 Translator ROM Module HP-82490A / Ver.2A
 31.7    PB-1000        PB-Forth
 23.5    RL-H1800       Snap Forth ROM Module
 20.0    HP-75C         Forth

[Helix]

(09-12-2021 02:00 AM)robve Wrote:  I don't have a serial cable (well I have the CE-134T but it won't work with a USB RS232 cable due to undervoltage). I load the object code via a wav file and cassette interface of the CE-126P printer.

I've managed to build a serial cable, and I can transfer BASIC programs between my PC and the Sharp PC-E500S, so it works

But now I'm stuck with the "uuencoded" thing.
I've found two packages related to uuencoding:
http://www.andrewwoods3d.com/pce500/uudecode.zip
https://www.it-pulse.eu/wp-content/uploa...uucode.zip
But they contain several programs, and furthermore they differ between the two packages.
I'm lost at this point.

Do you know which programs to choose, and how to use them?

[robve]

(09-16-2021 12:47 PM)Helix Wrote:  I've managed to build a serial cable, and I can transfer BASIC programs between my PC and the Sharp PC-E500S, so it works

But now I'm stuck with the "uuencoded" thing.
I've found two packages related to uuencoding:
http://www.andrewwoods3d.com/pce500/uudecode.zip
https://www.it-pulse.eu/wp-content/uploa...uucode.zip
But they contain several programs, and furthermore they differ between the two packages.
I'm lost at this point.

Do you know which programs to choose, and how to use them?

Congrats on the cable! I'll work on one when I get back.

Your first URL http://www.andrewwoods3d.com/pce500 has HeavyMetalMini (an arcade game). The 12K game is loaded via serial with the following HMMLOAD.BAS bootloader (I've removed some irrelevant parts):

2 REM "HMMLOAD.BAS"22/5/91
3 REM HEAVY METAL MINI LOADER
4 REM &HBB000 - &HBE118
5 REM ALLOCATE RAM WITH: "POKE&BFE03,&1A,&FD,&B,0,&4C,0:CALL&FFFD8"
6 REM TO START: "CALL&BB000"
...
20 *P:OPEN "1200"AS #1:A=&BB000
21 A$="":INPUT #1,A$:PRINT HEX$ A;":";A$:A$=MID$ (A$,7,23)
22 B$=LEFT$ (A$,2): IF LEN B$<2 GOTO 21
23 POKE A,VAL ("&"+B$) :A=A+1
24 A$=MID$ (A$,4,254):GOTO 22

The only difference is that Forth500 unexpanded starts at &B9000 and expanded starts at &B0000. RAM should be reserved with the POKE+CALL as suggested by the REM comments (see Forth500 for the specific POKE). This loader assumes that the uuencoded binary HMMHEX.TXT is sent over serial, see http://www.andrewwoods3d.com/pce500/hmm-uue.html

It looks like the bootloader just quits when serial closes? That's not 100% safe, but should work I suppose. There is also no CLOSE#1. Close first before rerunning.

If you have a 32K RAM card or expanded E500 then saving Forth500 as a RAM file can be handy in case the Forth dictionary gets damaged and you need to reload Forth500 with LOADM. I added more checks to prevent dictionary and stack overflows, but that does not make Forth500 entirely safe against mistakes (like most Forth's). For example, the wrong ! (store) address can damage the dictionary and code base.

Hope this helps.

- Rob

[Helix]

(09-16-2021 05:06 PM)robve Wrote:  Congrats on the cable! I'll work on one when I get back.

Thanks, but it's not a great accomplishment. I've used the document I posted here.
I used an FTDI board instead of a cable. As you can see in the picture, my solution is certainly not the most elegant, but it cost me almost nothing.

Quote:Hope this helps.

At first, I was even more confused!
HMMHEX.TXT is not uuencoded! It's an ASCII file containing a list of hex codes, and written in a special format.
The loader just reads the hex codes, converts them to numeric values, and POKEs these values into memory at the desired addresses.
But that could be a solution. I guess it would not be very difficult to write a program that converts the binary file to a similar ASCII file, in order to use this kind of loader.
I'll have to think about that.

There are still some things I don't understand very well.
What's the meaning of OPEN "1200"AS #1 ? I don't understand the "1200". Does it mean port COM?
And I didn't know the LOADM instruction. Even if I guess what it does, it is not in the manual…

[toml_12953]

(09-17-2021 08:45 PM)Helix Wrote:  There are still some things I don't understand very well.
What's the meaning of OPEN "1200"AS #1 ? I don't understand the "1200". Does it mean port COM?
And I didn't know the LOADM instruction. Even if I guess what it does, it is not in the manual…

1200 is the baud rate. The manual is here:

http://pocketcomputerworld.free.fr/Manuals/PC-E500.pdf

Pages 303-305 have the syntax and usage of the OPEN command.

LOADM loads machine language programs rather than BASIC programs.

[robve]

I spent about a day and a half to write the core machine code and Forth definitions of the FLOATING and FLOATING-EXT word set implementation for Forth500. I really like the E500 CPU and the ROM FCS (file control system) and IOCS (IO control system). Unfortunately, I can't finish this and tests it for a couple of weeks.

The extension includes:

- All 31 words of the Forth standard FLOATING word set: >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

- 18 words of the Forth standard FLOATING-EXT word set: F**, F., FABS, FACOS, FASIN, FATAN, FCOS, FEXP, FFIELD:, FLN, FLOG, FS., FSIN, FSQRT, FTAN, FVALUE, PRECISION, SET-PRECISION plus 16 words implicitly, because all single SFxxx and double DFxxx words are redundant (see next point): SF!, SF@, SFALIGN, SFALIGNED, SFFIELD:, SFLOAT+, SFLOATS, DF!, DF@, DFALIGN, DFALIGNED, DFFIELD:, DFLOAT+, DFLOATS, F>S, S>F

- Not implemented FLOATING-EXT words can in principle be added as Forth definitions: FACOSH, FALOG, FASINH, FATAN2, FATANH, FCOSH, FE., FEXPM1, FLNP1, FSINCOS, FSINH, FTANH, FTRUNC, F~

- All words work with both single precision (10 digits) and double precision (20) digits transparently, i.e. no special words are needed for either type

See float.s in the repo for my WIP.

The good news is that the entire addition only requires about 1.5K (float.s assembled is 1589 bytes). I decided to use internal RAM to copy floats to/from memory, which keeps the code compact and fast (the CPU has block-instructions to move blocks of data to/from internal RAM and operate on BCD in blocks). I expect the extended Forth500 implementation to use about 20K, still leaving plenty of space for user programs.

- Rob

[robve]

(09-17-2021 08:45 PM)Helix Wrote:  And I didn't know the LOADM instruction. Even if I guess what it does, it is not in the manual…

As toml_12953 suggested, LOADM loads a binary file. I believe the file loaded should include a 6 byte header with the address and length of the object code. The Forth500.OBJ file includes this 6 byte header, not the Forth500.bin which is stripped to produce a wav file with PocketTools. Have you tried sending Forth500.OBJ over serial and load it with LOADM "FORTH500.OBJ"?

- Rob

[Helix]

(09-17-2021 09:25 PM)toml_12953 Wrote:  1200 is the baud rate. The manual is here:

http://pocketcomputerworld.free.fr/Manuals/PC-E500.pdf

Pages 303-305 have the syntax and usage of the OPEN command.

Right. It appears I had misunderstood the role of format 2.

(09-21-2021 06:12 PM)robve Wrote:  Have you tried sending Forth500.OBJ over serial and load it with LOADM "FORTH500.OBJ"?

It should not work, as the manual states that "the computer can send/receive only ASCII codes" (p. 304).
I've tried nevertheless to load a binary file with the LOADM command, with various syntaxes, but I got either a 'syntax error', or a 'bad drive name' error.

Instead, I've written a small program that converts any binary file into an ASCII file. It's a DOS program (I'm not a modern guy!), so it needs DOSBOX to run. I still have to adapt the BASIC loader and test it, but it should work.

[Helix]

Now Forth500 is installed on my E500S
I've used the DOS program attached to this post. It's very simple.
In DOSBOX, entering bintoasc forth500.bin creates the ASCII file forth500.txt.
Then forth500.txt can be transferred via serial cable, and loaded with this small BASIC program (here for the expanded version):

10 OPEN "9600,N,8,1,A,C,&1A,N,N" AS #1
20 A=&B0000: INPUT #1,N
30 FOR I=A TO A+N-1
40 INPUT #1,B: POKE I,B: NEXT I
50 CLOSE : PRINT"PROGRAM LOADED": END

The transfer takes about 7 minutes. I've tried other formats for the ASCII file, but they are slower than this one.

A note on the FT232RL boards: I had two of these boards, but I could invert the signals for only one of the two. The other is certainly a fake.
Since I wanted to make another cable for my PC-G850VS, I bought a third board to the vendor who sold me the good board last year. Unfortunately, this time it was a fake!
The market seems flooded by these fake FTDI chips. They work correctly, but their parameters cannot be changed…

[robve]

(09-28-2021 03:28 PM)Helix Wrote:  Now Forth500 is installed on my E500S
I've used the DOS program attached to this post. It's very simple.

Great! It takes a bit longer to transfer over serial than I had expected from the baud rate. By comparison, the cassette interface transfer takes about 90 seconds. But it's not always successful and requires a second or even a third attempt. Fortunately, the complete floating point implementation does not appear to increase the Forth500 binary a lot, just 1.5K~2K max, thanks to the E500 system calls and the efficient CPU architecture (the SC62015 is definitely one of my favorites). So loading will not substantially increase and there is enough space left for Forth programs. I will try to keep the binary small, finding ways to shrink it further if possible. Every byte counts. I can't make much progress on this addition until I get back in three weeks.

You already know this, but I'll state this again: please note that RAM must be reserved first with the required POKEs+CALL, before running the bootloader program. Otherwise Forth500 will immediately crash.

By the way, it should be possible to send and receive ASCII data from within Forth500 over serial. Just open the COM: device with OPEN-FILE, store the fileid in a variable, then use the Forth IO words and CLOSE-FILE. It should also be possible to load source code with INCLUDE COM: when executed in Forth500. However, the SIO settings cannot be specified within Forth500. I suspect that the most recent (or default?) SIO settings will be in effect (the settings specified in BASIC). If not, we should take a look at this by making the appropriate system calls.

- Rob

[Helix]

Transfer over serial is slow because of the loop with the POKE instruction, but it's reliable. And waiting a few minutes is not a big deal. It's done just once.

I have a 256KB machine, so I don't have space problems.
Can you confirm that an internal RAM disk "E:" must be created after loading Forth500? The only memory map I know for the PC-E500 is in this page:
http://www.andrewwoods3d.com/pce500/dumptool.html
I suppose that space for RAM disk E: is reserved just ahead of the machine code area.

(09-28-2021 09:03 PM)robve Wrote:  By the way, it should be possible to send and receive ASCII data from within Forth500 over serial.

That's good to know. But I have to study your tutorial first!

[robve]

(09-29-2021 09:23 PM)Helix Wrote:  Transfer over serial is slow because of the loop with the POKE instruction, but it's reliable. And waiting a few minutes is not a big deal. It's done just once.

Glad to hear you don't mind the wait

I wonder if the following simple optimization reduces the transfer time by reading 8 bytes at once:
30 FOR J=A TO A+N-1 STEP 8: INPUT#1,B,C,D,E,F,G,H,I: POKE J,B,C,D,E,F,G,H,I: NEXT J

If the input file is not a multiple of 8 bytes, then you can save it with padding zeros to make it a multiple of 8.

(09-29-2021 09:23 PM)Helix Wrote:  I have a 256KB machine, so I don't have space problems.
Can you confirm that an internal RAM disk "E:" must be created after loading Forth500? The only memory map I know for the PC-E500 is in this page:
http://www.andrewwoods3d.com/pce500/dumptool.html
I suppose that space for RAM disk E: is reserved just ahead of the machine code area.

I'm away, so I don't have my E500 with me to try (at home I have a E500S expanded to 256KB, one regular E500S with a 32K RAM card for the F: drive and one E500). I believe the E500(S) moves the RAM disk to lower memory when allocating space, but I could be wrong. Did memory allocation fail when you have an E: drive? Perhaps the E: drive is too big? Allocating space fails if the E: drive and BASIC Programs do not leave enough space for Forth500.

- Rob

[Helix]

(09-29-2021 10:27 PM)robve Wrote:  I wonder if the following simple optimization reduces the transfer time by reading 8 bytes at once:
30 FOR J=A TO A+N-1 STEP 8: INPUT#1,B,C,D,E,F,G,H,I: POKE J,B,C,D,E,F,G,H,I: NEXT J

If the input file is not a multiple of 8 bytes, then you can save it with padding zeros to make it a multiple of 8.

Good idea! This reduces the transfer time by about 20% in my test. So it will not make a huge difference, at least for me.

Quote:I believe the E500(S) moves the RAM disk to lower memory when allocating space, but I could be wrong. Did memory allocation fail when you have an E: drive? Perhaps the E: drive is too big? Allocating space fails if the E: drive and BASIC Programs do not leave enough space for Forth500.

Nothing failed for me. I just asked the question out of curiosity, because I thought you knew the answer. I will not investigate this question as long as nothing crashes.

[Klaus Overhage]

Thank you Rob for your Forth500. For me, both the handling of the PC-E500 and the Forth language are new territory. With Forth500 I am now taking my first steps and have already learned a lot in the process:

Installation of Forth500
===============

I was able to load the "expanded" version onto a PC-E500S with 256K RAM. And even with a PC-E500 with 32K and an inserted 256K card, I have succeeded in entering MEM $ = "B" beforehand. When & B0000- & BFC00 were reserved, the Ramdisk E: and its contents were retained.

With the help of Helix Program bintoasc, Forth500.bin became FORTH500.TXT with 53k bytes. On the PC I use the program MBSharpNotepad together with an old serial interface cable (see https://manib.bplaced.net/blog/?page_id=458#) First deactivate the menu item "View / Syntax Highlighting" in MBSharpNotepad because otherwise large text files take a long time to load. Then FORTH500.TXT opened and found that the line breaks are not displayed.

Tried it and found this way as a solution: First create a new text file with MBSharpNotepad and save it. Open this file with a double click in notepad, open FORTH500.TXT also with a double click in notepad, mark everything (CTRL-A), copy and paste into the new file. Close Notepad again, the new file was now 71K and is displayed by MBSharpNotepad as normal with line breaks.

I had to change something in the Helix BASIC program because MBSharpNotepad now sends an additional 0 after each line. I named it FLOAD and appended it below. Sending the 71K file to the PC-E500 takes 18 minutes, but MBSharpNotepad shows a nice progress bar. Then you can use PEEK commands to check whether it worked: PEEK A must result in 48 and PEEK (A + 1) must result in 113.

@Helix: How do you start the data transfer to the PC-E500 on the PC?

Using Forth500
==========

After reading Rob's wonderful "Quick Forth tutorial" I wanted to create a Forth program on the PC and transfer it to the PC-E500. I opened an empty editor window in MBSharpNotepad and copied an example from the tutorial into it:

Code:


\ HELLO.FTH

.( Loading HELLO... )

ANEW _HELLO_
 
0 CONSTANT #english
1 CONSTANT #spanish
2 CONSTANT #french
VARIABLE language #english language !
: hello
  language @ CASE
    #english OF ." Hello, World!"  ENDOF
    #spanish OF ." Hola, Mundo!"   ENDOF
    #french  OF ." Salut Mondial!" ENDOF
    ." Unknown language"
  ENDCASE
 CR ;

Then saved as HELLO.FTH on the PC. Data reception on the PC-E500 is started with
COPY "COM:" TO "E:HELLO.FTH", A
and sending on the PC in the MBSharpNotepad.

The file can then be added to the dictionary from FORT500 as follows: INCLUDE HELLO.FTH
Try it with HELLO and delete it again with FORGET _HELLO_.

I'm looking forward to trying out the examples from some of the Forth books ...

[Helix]

Interesting. I didn't know the program MBSharpNotepad. I will have to try it.
On the PC side, I use HTerm:
https://www.der-hammer.info/pages/terminal.html

I'm following strictly the instructions included in the pdf I've already mentioned:
https://www.hpmuseum.org/forum/attachment.php?aid=9569

My BINTOASC program terminates each line by a CR character only (Carriage Return).
For MBSharpNotepad, maybe it will be better to terminate each line by CR + LF (Line Feed, or New Line character).
I've slightly modified this program to add a LF character. See the attachment. It works for loading BASIC programs. Perhaps you will need to change the settings of the OPEN instruction, and replace the "C" parameter by "L" ?

[Klaus Overhage]

Thank you Helix for BINTOTXT.EXE. From Forth500.bin it directly generates the 71k byte text file required for the MBSharpNotepad. And with your tip in the OPEN command to replace the parameter C with L, I can now use your original BASIC program except for this small change. The runtime has surprisingly remained at 18 minutes, it is probably given by MBSharpNotepad.

Next I tried to load the file debugger.fth from the folder "additions".

In RUN mode: COPY "COM:" TO "E:debugger.fth",A
In Forth500: INCLUDE debugger.fth
Loading debugger...
-- after 90 second --
Loading debugger... Exception #-13

Exception #-13 stands for "undefined word"

In Forth500: WORDS
The first word is "JUMP-CFA".

I think the definition of the next word "DO-OTHER" in debugger.fth maybe is incorrect.