The Psion-Forth Project
Table Of Contents
1 IntroductionThis project is an attempt to port a version of the Forth programming language to the Psion SIBO architecture. There is already one version of Forth, but it isn't Open Source, and so can't be considered for any of my projects. I ideally want to be able to link this Forth into the PsiStack TCP/IP system, and provide sufficient hooks into the HWIF library as to be able to develop decent TCP/IP client applications with it.
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.
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.
2 Which Forth to Port?I have considered these alternatives:
2.1 eFortheForth version 1.0 comes in assembly source form, for the 8086. It is small model, CS=DS=ES=SS, rendering it unsuitable - without modification - for SIBO, which requires CS != DS=SS=ES. Also, eForth is not ANS Forth. While this doesn't bother me unduly, I'd like to work on something that's standard. I'd rather not hack assembler - although in the end, it's the best way.
2.2 pForthRather than having to hack assembler, I'm in favour of pForth. The problem with this is that the TopSpeed C Compiler used in the Psion C SDK cannot handle the main switch() statement of the interpreter. I thought about getting round this using another compiler for that module, and patching it in to the rest of the object code. Either that, or ditch TopSpeed altogether for this project, and build it using gcc, or bcc.
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....
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.