• 1 Introduction
  • 1.1 Why Forth for SIBO development?
  • 1.2 Current status
  • 1.3 Acknowledgements
• 2 Which Forth to Port?
  • 2.1 eForth
  • 2.2 pForth
  • 2.3 hForth
• 3 Download
• 4 Mailing List

The finished product will be released under the GNU General Public License. It should run on all Psion SIBO kit, although I'll only be able to test it on the 3c, the 3, and emulators.

1.1 Why Forth for SIBO development?

I have no code available yet - I have plenty on disk here, but nothing ready to publish. I have taken the EXE model (dual segment) of hForth, converted it to build under Borland Turbo Assembler, and am integrating code that provides access to the SIBO console. This requires the building of a separate console/device library, which I'll test in a C harness before patching it into hForth. The hForth kernel seems to work OK so far - it boots as far as the console initialisation code, which breaks, and causes an OS panic. Hopefully, I've done the Turbo Assembler conversion 100% - any missing patches are likely to take a very long time to track down.

1.3 Acknowledgements

• Chris Jakeman, and the UK Forth Interest Group, for publicising this project in Issue 101 of ForthWrite.
• The denizens of comp.lang.forth for advice on which Forth to choose.
• Leo Brodie, Alan Wakefield, Elizabeth Rather and Edward Conklin for the books I've used for re-learning Forth.
• Dr. Wonyong Koh, for hForth.

• eForth, a small, 8086-assembly language Forth, ANS-aligned
• pForth, a medium-sized ANS-Forth, written entirely in C.
• hForth, a small ANS-Forth, derived from eForth.

This is known as a non-trivial exercise, and since this is Yet Another Spare Time Project, of which I have virtually none, I've abandoned pForth, leaving me with....

2.3 hForth

It should build easily under Borland Turbo Assembler, but it doesn't.

Since the hForth code has to be linked with Psion's SIBO C Startup code, and several library routines, the hForth kernel is not the first object file - this is reserved for the startup code. Now, under the SIBO C SDK/TopSpeed Linker, all object modules' data segments are grouped under DGROUP, and are fixed up so that references relative to the start of each module refer to their correct place in the full DGROUP segment. Not so with the Turbo Asseembler/Linker! It seems that this linker does not fix up correctly, in that all references to the data segment in a given module are kept as relative to the start of that module's data segment (i.e. 0000, not start-of-this-data-segment-in-DGROUP). So, I've had to manually go through all the hForth code, and explicitly specify DGROUP segment overrides.

This took ages - both to discover, and to do. Apparently, the Turbo Assembler ignores ASSUME DS: DGROUP in MASM mode, but honours it in Ideal mode. I know F.A. about Ideal mode, have no desire to learn, and haven't time to - this code is foreign enough without worrying about whether I've ported it to (effectively) a different language.

To do this patch, I built hForth, redirected all errors to a file, and used a Perl script to go through the list of errors, the map file, and the source, and patch in DGROUP overrides into the relevant source lines, in both code and data segments. I also did some by hand. This is rather scary, and if hForth doesn't work when I've finished, this is probably where the error lies.

3 Download