Hi all, After more than one year of development, Solo Forth (http://programandala.net/en.program.solo_forth.html) is quite mature and stable, and I'm already using it to develop several projects in Forth, which is the best way to test the system deeply. I think it will be ready to be downloaded and tried before October.
Solo Forth has a small kernel with only the words needed by the kernel itself, but a huge library of useful code, stored on the sectors of disks, a la classic Forth. Simple and efficient. Library requirements are managed with non-standard words: `need`, `[needed]`, `[unneeded]`, conditional comments `?\` and `?(` and other simple tools. But the standard `[if]` is included in the library, just in case. Solo Forth is focused on cross-development with a ZX Spectrum 128 emulator. Therefore, Forth programs are written in the host OS, in standard files, with standard modern tools, and then converted to blocks in a ZX Spectrum disk image with fsb2 (http://programandala.net/en.program.fsb2.html), including the required modules of the library, ready to be compiled by the ZX Spectrum. Of course, the library includes an optional command line classic block editor, so it's possible to write programs in the Forth system as well, block after block, but there's no advantage doing so. DOS support is modular and can be extended. G+DOS was my first goal from the start and it's very well supported, with only a few things still missing. +3DOS was my second planned goal, but its module is only sketched, not usable yet, mainly because I still have to finish (in Gforth) a module of fsb2 to create +3DOS disk images from a source file, copying it directly into the sectors. MGT disk images (for G+DOS) are a simple dump of the actual disk contents, but the DSK format has a lot of metadata to describe every part of the disk. Recently, as a challenge, I have started the support for TR-DOS, which I used a lot on the actual machine many years ago. I've discovered TRD disk images are simple dumps of the actual disks, but creating a library disk from its original source file is a bit more complicated than in G+DOS, because track 0 must be preserved, with its metadata sector. Otherwise the Fuse emulator does not accept it. So I had to write a little program in Gforth that creates a fake track, and integrate the operation into the Makefile that builds the whole system. Beside, TR-DOS seems to be easy to use from machine code (at least, much easier than G+DOS). As probably you know, though the system was designed in England in 1984..1986, it soon became very popular (actually, cloned) in Russia, where it's the de facto standard of all ZX Spectrum Russian clones. Most relevant low-level information about TR-DOS out there is in Russian (for example, in Virtual TR-DOS: http://vtrdos.ru), while there are only few articles in English, in World of Spectrum (unfortunately, the original manuals of the Beta Disk and Beta 128 Disk interfaces are very sparse on technical information); but automatic translations from Russian are enough to understand most of it. One problem I've found is G+DOS disks are 800 KiB, while the maximum capacity of TR-DOS disks (80 tracks, double side) is 636 KiB (640 minus 4 KiB of sector 0, which as said can not be used by Forth, at least not totally and not without tricks). This forced me to compact the library, combining as much blocks as possible and reorganizing the requisites and the conditional compilation... In the future, IDEDOS (http://www.worldofspectrum.org/zxplus3e/) ResiDOS (http://www.worldofspectrum.org/residos/) and ESXDOS (http://esxdos.org/) seem better options for a cross-development ZX Spectrum Forth, because they support hard disks and Compact Flash, also with FAT file systems. By the way, TR-DOS seems very slow when loading from disk, compared to G+DOS, probably because of its simple disk structure and its small 256-byte sectors. (A directory entry of TR-DOS occupies only 16 bytes, while G+DOS uses 256, including a bit map of used sectors.) I didn't test it, but I think maybe +3DOS is even slower than TR-DOS, though for other reasons. Anyway, implementing the +3DOS support will be a pleasure, because it's very well documented and has every entry point you can dream of (also Garry's IDEDOS and ResiDOS are excellent in those aspects). Regards, -- Marcos Cruz http://programandala.net
