Spectrum Computing

added floating point support (with ROM calculator), including full-featured float<->string conversions (using calculator routines, so "42E18" can be parsed, and "4.2E+19" will be printed. i guess we're very close to 0.2.0 public release. ;-)

p.s.: don't expect the current development speed to stay the same after 0.2.0 release, tho. the system is more-or-less feature complete now, and for 0.3.0 release i need to complete various libraries, write documentation, and so on. the kind of work i don't really love to do.

the huge delay with new release is due to... oh... i spent last week writing x86 forth from scratch, in asm and forth. ;-) UrAsm already has UrForth built in, but it becomes more and more limiting to have forth built into assembler, and not vice versa. ;-) the plan is to create a full-featured cross-compiler/emulator. yeah, it prolly means porting Zymosis to Forth (or maybe to x86 asm). ;-)

anyway, 0.2.0 will still be UrAsm-based. and i will backport new loops implementation, with full break/continue support. oh, the joy of Forth: the code from quite big 32-bit system can be taken to little Speccy as-is, because UrForth was made mostly compatible with dsForth.

p.s.: UrForth Native is fully working now (and passes ANS tests where i think it worth support ANS standard). but i want it to be self-hosted, so i wrote (ahem... borro... wrote!) a huge part of built-in x86 assembler already.

and if you want to know why i'm doing all that, considering that there are prolly at least a billion of really good native x86 forth systems... because i can, of course.

so UrForth is self-hosting system now, which means that i have a working metacompiler framework. now i'm slowly doing natural-syntax Z80 assembler in it, and will use its metacompiler to cross-compile dsForth sources. all that means that dsForth project is not dead, and instead of being a mess of urasm and custom "almost-forth" syntax, it will be almost completely normal Forth, properly cross-compiled (with optimisiations, and better turnkey).

UrForth took slightly longer to write than i expected (3 weeks; i'm simply fine-tuning it now), due to writing natural-syntax x86 assembler in it first. that is, usual Forth assemblers are quite ugly, often looking like "4 [ebp] ecx mov". it is very easy to write the asm engine like that, but it is a PITA to use. so i wrote a custom parser and a "natural-syntax" asm, which accepts normal things, like "lea eax,[esi*4+edx+8]" instead.

i will do the same for Z80 assembler, and then will port current dsForth sources to the new system.

it means that there will be no 0.2.0 dsForth release, i'll jump staight to 0.4.0.

Hello can I take a look at this dsForth, please ?
Could I have a link please ? The previous links I clicked do not work...
Thanks, Roland

pandoraefretum wrote: ↑Tue Mar 22, 2022 9:58 pm Hello can I take a look at this dsForth, please ?
Could I have a link please ? The previous links I clicked do not work...
Thanks, Roland

sure, no problems!
here is the latest sources i have (and built binaries too). you will need my UrAsm project if you will want to rebuild it.

sorry for the state of the code: i was in the middle of rewriting the whole system on top of my new 32-bit x86 UrForth (which would be used as a testbed, and as a cross-compiler), but somewhat… ran out of steam. i'll eventually return to the project, but don't know when and how, especially now (i'm living in UA).

there is also experimental +3DOS version too (.dsk binary should work on +3).

p.s.: if you want to fork the project, or use some of its parts for your own, be my guest! ;-)

So you have cross compilation from PC to x86 dos system and zx spectrum?

Any .tap files of demos available of the games?

nope, not yet. for various reasons i stopped working on it after creating a barely working proof-of-concept. basically, lack of time. but with new UrForth/C i may revisit this once again. the idea is still interesting, and optimising cross-compiler could be quite fast.

tbh, the main reason why i moved this project to "do it sometimes… later" is lack of users. i myself don't really need it in the finished form (i can use the pieces i already have), and most other ZX/Z80 Forth users seem to already have their own Forth systems (which is expected ;-). so now this is something i would do when i'll have some free time left from my free time. ;-)

@ketmar,

I'm very slowly working my way through the Melbourne House Abersoft Forth book, and this example works fine in the original Abersoft Forth



However, in your version there doesn't seem to be the graphics routines:



Am I doing anything wrong?

dsForth is not really compatible with Aberforth anymore. this word is called "DRAWLINE" there, if i remember it right. ;-)

that is, instead of "sx sy plot ex ey draw" use "sx sy ex ey drawline".

"125 0 PLOT I 99 DRAW" should be "125 0 I 99 DRAWLINE"

@PeterJ, also, please, note that dsForth is not fully FIG-Forth compatible too. for example, instead of "<BUILDS … DOES>" you should use "CREATE … DOES>". it also has some modern words too, like "VALUE" and "DEFER".

but "<BUILDS … DOES>" will return in the next version, removing it was a design mistake. ;-)