краткое описание:

каталог CVS используется системой контроля версий, внутрь можно не лазить

arh.py скрипт на Python создания снапшота проекта в каталоге /backup/BF/YYYYMMDD.HHMM.zip
пользоваться необязательно, мне просто спокойнее периодически его запускать

Makefile файл описанич проекта для компиляции с помощью стандартной утилиты make,
нужно будет посмотреть чтобы понять как запускаются компиляторы

MODE16.4th настройка целевого компилятора на 16-битный режим
MODE32.4th настройка целевого компилятора на 32-битный режим

TC.4th целевой компилятор, я пользовался нестандартным, надо переписывать

vm.cpp движок на Си с элементами С++ для POSIXных систем

dos16.bat запуск make для компиляции DOS-версии движка и 16-битного байт-кода
win32.bat запуск make для компиляции win32-версии движка и 32-битного байт-кода
unix.rc запуск make для компиляции UNIX-версии движка и 32-битного байт-кода

EMPTY.4th простейшее приложение, ничего не делает, написано на неправильном форте
для неправильного ЦК

CTLSTRUC.4th демка стрктур управления, написано на неправильном форте
для неправильного ЦК

это были файлы, теперь послойная структура системы:

1) железо + хост-ОС + драйвера + набор бинарных библиотек + ... = хост-платформа

2) примочки поддерживающие протокол обмена сообщениями с движком -- большие платформенно-зависимые куски типа виртуальных графических консолей или числодробилок

3) движок-интерпретатор (пишется на чем угодно, хоть на асме под голое железо без хост-ОС)

4) байт-код (отдельные приложения или их набор включая GUI, серверы, менеджеры ресурсов и т.п.
см микроядерные ОС)

программы могут работать самостоятельно требуя только движок, или требовать чтобы были параллельно запущены другие модули (движок поддерживает многозадачность на уровне
интерпретации байт-кода, поддержки многозадачности от железа не нужно, лишь бы хватало
памяти)

в перспективе -- научить несколько движков на одном компе или на сети разных компов
работать как (гетерогенный) кластер, причем програчно для программ перекидывать
байт-код задач и блоки XMEM памяти между узлами (параллельно запущенными движками).

ЗЫ: XMEM -- это память, выделяемая вне адресного пространства форт-процесса, для работы
с ней предусматривается набор команд типа блочной пересылки, выделения, ресайза, освобождения,
принудительного свапа и т.п.

сами исходники целиком постить смысла не вижу, только небольшие куски с описаниями,
так что тащите свежатинку с http://akps.ssau.ru/forth/BF/ или регистритесь
и пользуйтесь CVS (геморройнее, и для анонимного использования недоступно -- есть http снапшот).