DEV Community: Alexey Bolshakov

Forth made neural networks suffer

Alexey Bolshakov — Tue, 09 Jun 2026 12:06:58 +0000

... and My Cursor Bill

Read the original in Russian: Forth Made Neural Networks Suffer (and My Cursor Bill)

Fail of the Week

Inspired by the fact that with AI I managed to write a package manager for Forth literally in one evening, plus several modern utilities, I started thinking. It works out well, of course. But it's somehow expensive. What if I try to train a neural network and run it locally? I'd save money and gain experience!

For most modern programming languages, neural networks are quite ready. They were trained on metric tons of examples. But Forth somehow got skipped. I searched coder models for a list of languages they were trained on and couldn't find a model that lists Forth as supported. If we're talking about using models in Cursor, the most accessible agent—Auto—can't handle Forth programming at all. Here I "lost it" again and said—"let's go all in" (Opus 4.7)—solve it! In that mode the models actually started getting somewhere. Sometimes not on the first try. Sometimes really not on the first try, but still successfully.

Overall, Forth turned out to be a tough nut for neural networks: top models output something, but slowly, painfully, rewriting dozens of times, rearranging words, running tests, and accumulating context. Forth made everything grind—the hardware, and my wallet too. Not a triumph-of-Forth story—a slow lesson in how neural networks and the tooling around them actually work, while chasing an atypical AI problem and, as always, stepped on every rake. The goal shifted: build AI that can beat Forth without going broke.

What is frules

Simple answer—you explain to AI how to write Forth and... Profit? Not so fast!

frules is not "yet another ChatGPT prompt"

I had a hypothesis that AI simply doesn't know what Forth is and you just need to give it all the information. I thought that, of course, not out of nowhere, but after long chat dialogues with AI. After which we concluded that we need to assemble a knowledge dataset, and then the model would be able to program!

From what I knew, I asked AI to download the entire Gforth manual and examples of working with it. Write theses on Forth programming. I also added Brodie's book to the dataset, converting it to MD along the way (yay! now you can read it online). After that, many generalized theses AI had already formed were rewritten almost completely. Plus, we tried to make a block of typical programming tasks, like on Codewars. The hardest part was that there were no solutions to the tasks, and I spent a lot of time and money having AI solve all 98 tasks so the solutions would pass the tests. In places it was genuinely painful. Because toward the end there were about 10 tasks at level 7 out of 10 on the difficulty scale. And each one took at least an hour.

From previous dialogues with AI it became clear that this stage would have to be solved on the smartest models. Set the right tasks, solve them correctly, and get working examples. A weak model won't solve the task, and won't even write a correct test. By solving tasks and getting the right answer, we essentially "extract" from the large model how it was trained to solve problems. On one task that no AI could solve in 2–3 attempts, I just checked the tests myself. And it turned out the test itself was wrong—incorrect expected answers were specified (neural network hallucinations), and one model fooled another, while the other vainly tried to solve the correct problem and verify it with the wrong test. As always, the third party suffered (me).

Then, after passing that checkpoint, I added library code from theForthNet and tasks from Rosetta with solutions (dang, I didn't have to solve those—everything's there!). But when the models analyzed it, things weren't that simple. First, the original dataset was logically split across knowledge areas so each had several solutions. And Rosetta tasks turned out to be mostly duplicates. So we took only about 10 of them, not 500+. Other tasks there were game-like and wouldn't (in AI's opinion) help learn programming. But the dataset could still be expanded. It also turned out the solutions exist, but they don't pass tests on gforth. From that point AI decided to start fixing those tests, but I stopped the process, realizing I couldn't endure another sprint of fixing broken tasks emotionally or financially—and we hadn't even gotten to training yet.

So the hardest part is behind me, I thought. The dataset is ready. But AI doesn't need all the material in raw form! It needs to take only specific distillations. At this stage AI, having processed everything, did what it calls "distillation" and formed a set of .mdc files on how to program. Grouping that information by topic along the way.

What came out in the end

rules (.mdc) — distillation of Gforth manual, Brodie, Rosetta, theForthNet;
eval — 151 challenges (98 train / 53 hold-out blind);
gforth — judge: every gold solution marked TESTS OK.

We got a library—a knowledge base you can install (via script) into your Forth project, and when working with AI it will use all these rule files.

Cursor picks up rules from .cursor/rules/

But in principle, I think you can read it yourself and understand something. It's hard to evaluate all of this. Validating everything alone takes a long time.

Training your own model — Track A

Background. Before starting to "really" train a model—with data, on GPU—I had discovered RAG at work as a data source for the model. That is, we take a general-purpose model and connect an external vector database. We got a model of how our production is organized and could ask questions and get answers. Building a vector DB turned out to be an art form of its own. I watched from the sidelines as AI wrote scripts to "correctly" lay data into vectors. Then I'd ask questions and AI answered not how I wanted. And then the programming AI fixed the indexes. At that point I had a weak understanding of how it all works "under the hood." But I came to understand that for some of my work questions I don't need AI at all. I need to build tooling that fetches data, processes it, and outputs results. That knowledge would come in handy a bit later...

Assuming RAG wasn't quite what I wanted—I wanted to master the fine-tuning pipeline with my own data. That case where datasets are prepared somehow. Then you train the neural network and an extra layer of knowledge grows on it and boom—the model learned to program in Forth! Cool (I thought). My understanding at the time was: Model+RAG is when we have constantly changing knowledge. We easily swap the vector DB and don't need to retrain the model. But if we need to "bake" knowledge into the model—that's when we train it.

So I wouldn't wait forever for results, I asked AI to create this Track A for me: take the smallest 0.5B model, fine-tune it, see what it learned, understand the dataset assembly pipeline, training launch, and output. And only after that move on to larger models we'd train longer.

Well. My laptop has a 4070 with 8 GB and training is actually quite fast: literally a few minutes. The model is small. What did I get? A network that outputs repeatedly repeating nonsense instead of Forth code. Then we trained longer—added repetitions, I started staring at the numbers and felt I was starting to understand: epochs, error percentage. That percentage started dropping. But the final model still output a mix of Python code and Forth words.

Then we discussed the result with AI and how to improve it. I wanted the network to output something more useful. Give it more data. But then I was reminded that I wasn't really supposed to get a normal result, because the goal was—to master the tooling pipeline! Damn. Still, I did manage to see the model learned something. At that moment Track A should have been closed—chalk it up as the first pancake—and move on (without trying to get something meaningful from the small model). But... My AI said there was a bug in my scripts: data was truncated and the model trained on the wrong stuff. OK—fix it! We trained on proper data. And miracle: the model... didn't learn to program in Forth, but there was progress! It started formatting results as syntactically valid Forth definitions : forth-word commands ; and I was even a little happy.

The Track A stage was decided closed—no more fine-tuning the 0.5B model. Why? Because the "sandbox" goal is done, but the dream "0.5B model learns Forth"—isn't. What remained was understanding why—it's not too few epochs, repetitions, or data. It's something fundamental I hadn't grasped yet.

Time to take stock

Pause after Track A—questions before buying more GPU.

Many questions piled up, and without answers we couldn't move forward. Wild impulses started: buy my own powerful computer and GPU (which one?), maybe go to the institute, there's a cluster of 4×A100, or rent cloud. But for what?

While solving tasks, AI throws a lot of ML terminology. I collected them and started discussions. Plus, after experiments and measurements—you need to interpret results correctly, draw conclusions, and I didn't know how. So we had a long phase of talking to understand what we'd done, what conclusion to draw, and what to do next. We talked and talked, new questions appeared, new terms appeared. I asked follow-up questions on them. It's a good mechanism to learn what you don't know (we can't know what we don't know). We gradually spun up the dialogue.

Some questions I asked repeatedly, coming back many times. Apparently I just didn't want to believe some of my misconceptions.

The small model was planned from the start only for debugging the training pipeline and learning the tooling. But seeing the first results, I forgot all that and wanted to improve the network to get the right result—Forth code. And I stubbornly looked for ways to solve that.

Stages of accepting the futility of building your own Forth-programming network

AI: The 0.5B model is too small and can't be trained. With that capacity it practically can't do anything. And it won't output Forth results and can't. Even top cloud models struggle.

Before I accepted that thought, a whole chain of learnings and realizations happened. Surely not all of them are correct.

Realization +1: RAG is just text in the prompt. There is no direct connection between the neural network and the vector DB. There's no secret socket into the vector DB. All RAG data is inserted as text together with my original question in the prompt. All of that lands in context. The model understands that and starts answering accordingly.

Knowledge +1: Fine-tuning with LoRA—patterns baked into the weights via a thin adapter on a frozen base. You can merge and get a new model. But on my PC that's unrealistically slow. I may be wrong, but merge hits CPU and disk, and GPU doesn't help at all. So these are two different ways to add knowledge to the network. But with RAG—context is spent; with LoRA—it isn't.

Realization +1: LoRA doesn't replace RAG/rules in context. And context is only what exists—facts, theses. But overall, an answer with RAG can be better than from training.

Debating with AI about how and why to train a model—partial understanding appeared of why you shouldn't train too long on the same data, minimizing error. Train too long and the answer gets "memorized," but you want an answer through reasoning. That's why not every task in the dataset has an answer. So we teach the network via task–answer, then give a new task and expect an answer through reasoning. But we want an independent solution from the network. Then, having its reasoning—the answer—we can validate it because we have the correct answer for the task. Alas. It seems 0.5B isn't enough even to memorize answers.

Knowledge +1: Hold-out ("set aside")—tasks that weren't in training (neither in challenge-train.jsonl nor in train-merged for that slug). Used only to test the model blind, not how well it memorized the textbook.

What can you expect from a 0.5B network at all? And what to expect from a network in general? How does it work? We use networks and it's some kind of magic. Understanding how they work—that's higher magic. But at least understand what and how it answers.

Knowledge +1: a network is basically a predictor of the next correct token given the current context.

What? What do you mean?

Realization +1: understanding how AI "thinks," what it can output, which tasks it can solve and which it can't—one of the key moments for getting a developer tool.

And here I start guessing I'm going the wrong way entirely. I want direct Forth code generation from the neural network! But expecting reverse Polish notation (RPN (1 2 +)) generation directly from the network is a mistake. Neither because of small training data volume nor because of its nature—generating words sequentially—it can't undo its words and rearrange them (without an external tool).

Realization +1: services like Cursor just build a set of tools around a "thinking" model. Textual ones, because there's no other way to communicate. The model has one primitive: question → answer. What looks like an Agent with "reasoning" in the UI—Cursor under the hood: just several skills and MCP tools.

But the thought still won't leave me alone. Why do 0.5B models exist then?

Remember: no network runs Forth in its head, doesn't imagine a stack, doesn't keep one in memory. It can use context as a notepad, like a human. But you need a much larger network. Small models can do very simple things, like autocomplete.

Along the way it turned out model size is fixed too. LoRA won't "grow" 0.5B to other sizes by adding data. The network always stays the same size.

Then I tried to understand what we were actually training the network on. For example, I trained it on word definitions: factorial, fibonacci, etc. I saw loss change. It drops; seems like train longer and all will be well. I asked what that affects. But in the end I was told that loss down to 1 is normal training; below that is memorization. And there's no correct answer to when to stop training. Train to very low error and on prompt fib you get an exact, memorized answer. Like a student with 10 years of Russian but given some English words to memorize. They'll memorize them and only say those. But can't do anything else.

I also tried to understand how a neural network as a tree differs from a tree of Forth words and concepts. The model can understand and classify any part of a Forth expression. Each word is a separate concept. Maybe train on simple stack operations first, addition, etc. Turns out I didn't train the model on basics and immediately asked it to solve hard Forth tasks. Maybe that's why it doesn't solve them?

Knowledge +1: you can't make a model that writes Forth from a Python-trained model on 100 examples.

Knowledge +1: expecting exact formulations from a network is a mistake. The nature of the network is to err in small details and syntax—and it will definitely err in Forth syntax. Models are trained long and hard to generate JSON. Training a model from scratch—a home user doesn't have those resources (technical or dataset-wise).

But what did we achieve? At first I got a very strange answer from the small model. Then I fine-tuned. Saw the loss drops mentioned above, but nothing got better. Then it turned out there was prompt desync—an error in training data scripts. After fixing, answers looked somewhat like the truth. But only somewhat:

Word	Model	Reference (tests/ans/)
gcd	begin dup 0= … while dup 0= … dup 1 swap gcd	begin dup while tuck mod repeat drop
factorial	0= if drop exit then 1* factorial	dup 1<= if drop 1 exit then dup 1- recurse *
divisible?	1 div 0= if 1 else 0	mod 0=

The word definition was wrapped in the correct format : word ( … ) … ;—already not markdown/return format as before. But logic is wrong on all three. gforth fairly fails the tests.

The model doesn't copy strings from jsonl (gcd is in train)—0.5B can't hold the algorithm even with correct SFT.

But the smoke test wrote "OK" because it only checked for ":" at the start of the definition and ";" at the end. It doesn't compare to reference or require TESTS OK.

Train had no basics in order of increasing difficulty (curriculum)—went straight to hard tasks (gcd/factorial). The table above is the outcome: even honest SFT didn't save it. Track A closed for good.

But the idea kept spinning in my head that logically a Forth tree and a neural network thinking tree are very similar and generating Forth code for a neural network is like writing down the classification path of what you realized. But I can't explain how to express that. And I don't know if that understanding can be applied to the result.

Again and again we discussed this and each time AI explained I can't do it that way. Better to get from AI a properly described algorithm in a language AI knows, or pseudocode, and use an external conversion utility to get Forth code! Because the utility does it fast, cheap, and accurately. Unlike the neural network, which does it by processing huge data arrays and still has a nonzero chance of erring on some letter. It's like hammering nails with a microscope.

After that I gave up. And admitted we have to do it that way. Plus I was already guessing that working directly with syntax and notation isn't programming yet. You still need to understand algorithms, data structures, and have experience solving tasks with algorithms and structures. Algorithmic tasks! And Coder models are trained for exactly that—you should use their output. And convert that output to Forth non-neurally.

How? I started asking—can models output AST? That's almost Forth. No direct answer that some model outputs AST was found, but per AI, during training models saw millions of trees from compiler textbooks. But to get AST, programmers supposedly ask for the answer as Lisp S-expressions.

Task: 1 + (2 * 3)

AST (Lisp format, which models generate well): (+ 1 (* 2 3))

Transpiler output to Forth: 1 2 3 * +

Forth and Lisp are mirrors. You can express one in terms of the other.

What else? Assembler? Not quite. Assembler for a stack VM? Yes!

Stack languages LLMs know 10 out of 10:
WebAssembly (WASM): In text form (.wat) WASM is a pure stack machine.
Java bytecode (JVM): JVM computation is strictly on the operand stack.
PostScript (PS): PDF printer language. Plot twist: PostScript is a Forth dialect! Same RPN, same words dup, pop (drop analog), exch (swap analog).
CIL (.NET bytecode) and Python bytecode (dis) — also stack-based.

Then I conclude the final Forth result can come another way—through an external conversion tool. As part of the toolset around the AI model—the so-called "factory."

I decided to stop at WASM

Look how strikingly similar WASM is to Forth:
WASM code (model writes it without errors):

get_local $a
get_local $b
i32.add

Then we dumbly replace and get Forth.

Well, let's sum up again:

My thesis: "Forth should be easy for a tree/neural network"

AI's answer: Forth is easy for a compiler, not for an autoregressive LLM:

LLM generates left to right; RPN requires "holding the operation in your head" while placing operands. Forth mixes data and metaprogramming (immediate, ['], create/does>)—the transformer doesn't "execute" that, only imitates text. So your chain "parse task → write as tokens" is right—but the middle (parse → RPN) must be an algorithm, not the network, and certainly not a 0.5B network.

After that I wanted to clearly separate "tool vs task" and which of my tasks should be solved by neural networks and which by "factory" ecosystem tools.

What not to expect from AI (architectural limits):

Execute code, hold a stack "in its head," rollback on error—no internal VM; only text.
Guaranteed correctness—never; only probability.

Then we talked a bit about training a model from scratch (not retuning from Python to Forth, but training on Forth from zero). That process is unviable for home development. You'd need to teach all levels of programming. But even with lots of money and specialists—the idea of generating Forth text is wrong. The network will still err; if not, that's hammering nails with a microscope.

But what can we do? We can build a "Factory" from the toolchain!

So we can get from a large model the essence of the algorithm and code in notation convenient for Forth translation. Convert with tools. Verify with tools. Deliver the answer. Thus we spare the large model the pain, suffering, and huge token spend of programming in Forth.

So the task changed a lot philosophically: AI shouldn't write Forth itself—it should use external tools to get Forth and verify the result. And for validating conversion, the Forth ecosystem tools built in a few days help: fmix + test, lint flint, fcov coverage.

If it works, we get Forth code cheaper. If Cursor+Opus runs on this tools functionality, results should be cheaper.

Thus we arrived at understanding and reinvented (the wheel)—what everyone calls skills/tools.

Realization: there are no monolithic AI neural nets that program. We don't use them. We use AI ecosystems that eventually produce program code. At home we run one mono model. Then we're surprised—why is it so dumb. But we're comparing one small model to a big set of large models and tools around them.

AI terminology

Terms AI actively used explaining how it works. There's a funny bit: we discuss AI with AI )) I'll give them as AI explained them to me. In the context of our dialogue. I think it's better to look up each word online for a more correct explanation. Here the list itself is what matters.

Term	In plain words	What happens technically	For Forth / frules
Parameter	Network "memory cell"	One trainable number in a matrix	0.5B = 500 million such numbers
0.5B / 7B	Model size / capacity	Parameter count; more → more patterns	0.5B — too little for stack algorithms
Pretrain	"School of life" on the internet	Predict next token on huge corpus	Forth ≈ 0%; Python, C, "code in general" plenty
Token	Chunk of text (~word/part)	LLM input/output unit	`: gcd` may be 2–3 tokens
Transformer	LLM architecture	Attention: each token "looks at" previous ones	No stack, no VM — only text
SFT	Supervised fine-tuning	Textbook: prompt → reference answer	Your `train-merged.jsonl`
Instruct / instruction-tuned	"Assistant" model	SFT on "question → answer" dialogues	`Qwen2.5-Coder-0.5B-Instruct`
LoRA	Thin "overlay"	Few new weights; base frozen (QLoRA: 4-bit)	~17 MB on top of 0.5B
QLoRA	LoRA + compressed base	Base in 4-bit, only adapter trains	Track A on RTX 4070
Loss	Guessing error	Cross-entropy: how far off on next token	Low loss ≠ working Forth
Epoch	One pass over entire jsonl	How many times model saw each line	3 ep on 139 lines — little for generalization
Overfit / memorization	Memorized train, doesn't transfer	Great on same prompts, bad on new	Old run: memorized rules, not gcd
Generalization	Transfer to new	Works on prompts/tasks outside train	0.5B + Forth: practically none
Memorization	Copying train pairs	Answer ≈ string from jsonl	0.5B didn't even do that for gcd
Curriculum	Simple to complex	First `1 2 +`, then `: square`, then gcd	Not in frules; needed for small models
Hold-out	Tasks not in train	Verification only	`eval_holdout` in `tests/challenges/`
System prompt	Role / rules in chat	First message `role: system`	SFT: short (~50 tok); Ollama: full rules
Reasoning	Step chain to answer	Model generates intermediate steps (CoT)	Forth stack = needs "scratchpad" or algorithm
CoT (chain-of-thought)	"Think aloud" in text	Answer: stack, analysis, then code	Helps large models; 0.5B breaks on long chain
Rules (frules)	Text in prompt, not weights	`.mdc` in SYSTEM; weights unchanged	Cursor / Ollama — stronger than LoRA 0.5B
Merge LoRA	Merge adapter into base	Full weights for Ollama/GGUF	Separate from Forth quality
GGUF / Ollama	Local inference format	Quantized model for chat	Rules in Modelfile ≠ train jsonl

Side products of this exciting week

While I was doing all this, some tools were created along the way. I wanted to estimate what we got: by time period, functionality, and code volume.

Repo	Period	Versions	In one line	Code*
fmix	2024 → 24.05	0.7.x	Package manager	~1.2k LOC `.4th`
fsemver	24.05, 1 day	0.1.x	Semver library (for fmix/flint)	~360 LOC
fcov	24.05, 1 day	0.1→0.3	Coverage tool: console/JSON/LCOV/HTML	~2.8k LOC
flint	24.05, 1 day	0.1→0.2.2	Lint duplicate `: word`	~825 LOC
fenum	22.05	0.1.x	Library for `ulist` and `enum` (used in flint/fcov)	~750 LOC
fhdlgen	20–24.05	0.3.1	DSL→Verilog converter (next time)	~2k LOC
frules	25–31.05	0.1.x	151/98/53, Track A closed, docs hub	gold ~6.5k; rules ~2.1k md

*LOC excluding forth-packages/ — just to gauge scale.

May 24 — flint, fcov, fsemver written in one day with Opus 4.8. frules — six more days: challenge bank, gold, first checks (Track A), Forth docs hub.

Usually I hate wasting money on nothing. Not here: I don't regret the money or sleepless nights. Learned and realized too much in those days. Many skills helped on my day job too.

In short: antipatterns

"Opus will write all the : word ... ; code" — overhard + overkill + overinvoice.
"LoRA will learn postfix" — no (Track A closed).
Expecting a "factory" from 0.5B — you get an intern, not an assembly line.
Generating Forth directly when you need IR → transpiler.

Five paid invoices in one week (May 23–29): $75.06 + $50.85 + $34.66 + $75.00 + $27.84 ≈ $263. The bill climbs with rot and thinking.

What did we learn?

- What did we learn, Palmer?
- I don't know, sir.
- I don't know either. I guess we learned not to do it again.
- Yes, sir.
- I'm not sure what we actually did.
- Yes, sir. It's… hard to say.
- Good grief.

Sources

VitaSound:

To be continued ...

Forth заставил страдать нейросети

Alexey Bolshakov — Tue, 09 Jun 2026 07:53:40 +0000

... и мой Cursor-счёт

Fail недели

Вдохновившись тем, что с помощью ИИ мне удалось написать буквально за вечер пакетный менеджер для Forth, а так-же несколько модерновых утилит я задумался. Получается, конечно, хорошо. Но как-то дорого. А что, если попробовать обучить нейросеть и запускать ее локально? И денег сэкономлю и опыт получу!

Для большинства современных языков программирования, нейросети вполне готовы. Их обучали на килотоннах примеров. Но вот Forth каким-то образом обошли. Я поискал coder сети на предмет списка языков, на которые обучали, и не смог найти сеть, где есть Forth в списке поддерживаемых. Если говорить о вариантах использования моделей в cursor, то самый доступный агент=Auto вообще не справляется с программированием на Forth. Тут я опять "психанул" и говорю - "а давай на все деньги" (Opus 4.7) - решай! В таком режиме у компьютерных мозгов начало даже что-то получаться. Иногда не с первого раза. Иногда прям очень не с первого раза, но все же успешно.

Вообще, Forth оказался крепким орешком для нейросетей: топовые модели что-то выдают, но долго, мучительно, десятки раз переписывая, переставляя слова, запуская тесты и накапливая контекст. Forth заставил как следует поскрипеть железные шестерёнки — и мой кошелёк тоже. Это не история о том, как «Forth победил AI». Это история о том, как я постепенно начал приходить к пониманию того, как работают нейронные сети и экосистема вокруг них, решая нетипичную для ИИ задачу и как всегда, собрав все возможные грабли. История о том, как я начал приходить к пониманию того, как сделать "AI, который победит Forth". История о том, как это сделать эффективнее, не оставшись без денег.

Что такое frules

Ответ прост - объясняешь ИИ, как писать на Forth и ... Profit? А вот и нет!

frules — это не «ещё один prompt для ChatGPT»

У меня появилась гипотеза, что ИИ просто не знает, что такое Forth и надо ему просто дать всю информацию. Подумал я так, конечно же, не на ровном месте, а после длительных диалогов в чате с ИИ. После чего мы пришли к тому, что нужно собрать датасет со знаниями, и уж тогда модель сможет программировать!

Из того, что я знаю, я попросил ИИ скачать весь GForth мануал и примеры работы с ним. Написать тезисы по программированию на Forth. Так же добавил в датасет источники книгу Brodie попутно преобразовав ее в формат MD (ура! теперь ее можно читать онлайн). После этого многие обобщенные тезисы, что ИИ уже сформировала, переписались почти полностью. Плюс к этому, мы попытались сделать блок из типичных программерских задач, как это происходит на Codewars. Сложнее всего оказалось то, что решений задач нет, и я спустил кучу времени и денег на то, чтобы ИИ мне решила все 98 задач таким образом, чтобы решения проходили тесты. Местами было прям больно. Потому что под конец осталось порядка 10ти задач уровня 7 из 10 по шкале сложности. И на решение каждой уходило минимум по часу времени.

Из предыдущих диалогов с ИИ стало ясно, что этот этап придется решать на самых умных моделях. Ставим правильные задачи, правильно решаем и получаем рабочие примеры. Слабая сеть и задачу не решит, и даже тест правильный не напишет. Решая задачи и получая правильный ответ, мы, по сути, "вытаскиваем" из большой модели то, как она научена решать задачи. Вообще, на одной задаче, которую за 2-3 захода ни одна ИИ не могла решить, я просто взял и проверил тесты, уже сам. И выяснилось, что в принципе сам тест составлен не правильно - были не верные ответы указаны (галлюцинации нейросети), и вышло так, что одна сеть обманула другую, а другая тщетно пыталась решить правильное задание, и проверить его неправильным тестом. Пострадавшим, как всегда, оказалась третья сторона (я).

Потом, пройдя эту контрольную точку, я добавил просто код библиотек с theForthNet и задачи из Rosettа с решениями (чооорд, можно было не решать, там все есть!). Но анализ электронными мозгами показал, что не всё так просто. Во-первых, изначальный датасет у нас был логически разбит по разным областям знаний, чтоб по кажому было несколько решений. И задачи из Rosetta оказались в основном дублирующими. Поэтому из них взято всего порядка 10 штук, а не 500+. Другие задачи там были игровые и никак (по мнению ИИ) не помогли бы научиться программировать. Но можно было всё же, расширить датасет. Еще выяснилось, что решения то есть, но на gforth они не проходят тесты. С этого момента ИИ решила начать исправлять эти тесты, но я этот процесс остановил, поняв, что еще раз спринт по починке неработающих задач я уже ни эмоционально ни экономически не перенесу, а мы ведь еще и до обучения не дошли.

Итак, самое сложное позади, подумал я. Датасет готов. Но в чистом виде весь материал не нужен ИИ! Ему нужно взять только какие-то конкретные выжимки. На этом этапе ИИ прям обработав все это сделала то, что она называет "дистилляция" и сформировала набор .mdc файлов о том, как же надо программировать. Попутно сгруппировав эту информацию по темам.

Что в итоге вышло

rules (.mdc) — дистилляция Gforth manual, Brodie, Rosetta, theForthNet;
eval — 151 challenge (98 train / 53 hold-out blind);
gforth — судья: каждый gold solution помечен как TESTS OK.

Получилась библиотека - база знаний, которую можно установить (с помощью скрипта) в свой проект на Форте, и если работать с ИИ, то он все эти файлы с правилами будет использовать в работе.

Cursor подхватывает rules из .cursor/rules/

Но в принципе, я думаю, что можно и самому почитать и что-то понять. Тут сложно всё это оценить. Валидировать всё это одному — долго.

Обучение своей модели - Track A

Предпосылки. Перед тем, как начать "по настоящему" обучать модель, именно данными, именно на GPU - мной на работе был для себя открыт RAG как источник данных для модели. То есть, мы берем модель общего назначения и в качестве внешнего источника - подключаем доступ к векторной базе. Мы там получили модель данных о том, как организовано наше производство, и могли задавать вопросы и получать ответы. Создание векторной БД оказалось отдельным видом искусства. Я со стороны наблюдал, как ИИ само пишет скрипты для того, чтобы "правильно" разложить данные в векторы. Потом я задавал какие-то вопросы и ИИ отвечала не так, как я хочу. И далее программирующая ИИ исправляла индексы. На тот момент вообще было слабое понимание, как это все происходит "под капотом". Но я пришел к пониманию того, что по некоторым моим рабочим вопросам мне ИИ вообще не нужно. Мне нужно просто сформировать некий инструментарий, который данные добудет, обработает и выдаст. Это знание мне пригодится немного позже...

Предположив, что RAG это не совсем то, что я хочу - я захотел освоить пайплайн дообучения модели своими данными. Тот самый случай, когда каким-то образом готовятся датасеты. Потом ими обучают нейросеть и на ней вырастает дополнительный слой знаний и у нас модель "бац" и научилась программировать на Forth! Круто (думал я). В моем понимании на тот момент было то, что Модель+RAG это когда у нас постоянно меняющиеся знания. Мы легко и непринужденно меняем векторную БД и нам не надо переобучать модель. А вот если нам нужно "запечь" знания в модель - вот тогда мы ее и обучаем.

Чтобы не состариться раньше, чем будет получен результат, я попросил ИИ создать мне как раз этот Track A, где мы возьмем самую маленькую модель 0.5B дообучим ее, увидим то, что она научилась, поймем пайплайн сбора датасета, запуска обучения и выходной результат. И уже после этого пойдем дальше на большие модели, которые будем обучать дольше по времени.

Чтож. На моем ноутбуке используется 4070 на 8 Гб и в принципе обучение происходит достаточно быстро: буквально несколько минут. Ведь модель небольшая. Что я в итоге получил? Получил сеть, которая вместо Forth кода выдает какую-то многократно повторяющуюся ерунду. После чего мы обучили сеть подольше - добавили повторения, я начал всматриваться в цифры и мне показалось, что я начал что-то понимать: эпохи, процент ошибок. Этот процент начинал снижаться. Но итоговая модель все равно вместо Forth выдала смесь кода на Python и слов Forth.

Дальше мы пошли обсуждать с ИИ полученный результат и как его улучшить. Мне захотелось, чтобы сеть выдавала что-то более полезное. Дать ей больше данных. Но тут мне напомнили, что я, в общем-то, и не должен был получить нормальный результат, потому что целью было - освоить инструментальный пайплайн! Блин. Однако, увидеть, что модель чему-то научилась - у меня вышло. В этот момент надо было закрывать Track A, выкидывать первый блин комом и идти дальше (не пытаясь получить от малой модели что-то осмысленное). Но... Мой ИИ мне сказал, что в моих скриптах нашлась ошибка: данные были обрезаны и модель обучалась не тем, чем нужно. Хорошо - исправляем! Обучили модель уже нормальными данными. И о чудо: модель ... не научилась программировать на Forth, но прогресс был! Она уже начала оформлять результат в виде синтаксически верных определений Forth : forth-word commands ; и я даже немного обрадовался.

Сам этап Track А решено было закрыть и дальше не дообучать модель на 0.5B. Почему? Потому что цель - "песочница" выполнена, а мечта «модель 0.5B выучит Forth» — нет. Оставалось понять почему — это не мало эпох, повторений или данных. Это что-то фундаментальное, чего я еще не понял.

Время собирать камни

Накопилось много вопросов, и без ответов на эти вопросы двигаться дальше было никак нельзя. Начались дикие душевные порывы: купить свой мощный компьютер и видеоплату (а какую?), а может в институт сходить, там кластер из 4хA100, или может арендовать облако. Но для чего?

В процессе решения задач, ИИ выдает очень много терминов из области ML. Я их собрал и начал обсуждения. Кроме этого, проведя эксперименты и замеры, нужно ведь правильно трактовать результат, уметь делать выводы, а я их делать не умею. Поэтому у нас начался длительный этап общения с целью понять, а что же мы сделали, какой из этого сделать вывод и что делать дальше. И вот мы с ней общались и общались, у меня появлялись новые вопросы, появлялись новые термины. Я по ним задавал дополнительные вопросы. Это хороший механизм узнать то, что ты сам не знаешь (мы не можем знать то, чего не знаем). Постепенно раскрутили диалог.

Некоторые вопросы я задавал неоднократно, возвращаясь по много раз. Видимо, мне просто не хотелось верить в некоторые свои заблуждения.

Маленькую модель с самого начала планировалось использовать только для отладки пайплайна обучения и освоения инструментария. Но увидев первые результаты, я все забыл и захотел улучшить работу сети, чтобы получить верный результат - код на Forth. И я упорно пытался найти варианты решений этого вопроса.

Стадии принятия тщетности идеи созать свою сеть, программирующую на Forth

ИИ: Модель 0.5B Слишком мала и ее не обучить. С таким объемом она вообще не может практически ничего. И результат на Forth она не выдаст и выдать не может. Даже топовые облачные модели работают с трудом.

Пока я дошел до приниятия этой мысли, произошла еще целая цепочка познаний и осознаний. Наверняка не все из них верные.

Осознание +1: RAG - это просто текст в промпт. То есть, нету никакой прямой связи нейросети и векторной БД. Сеть никуда через отдельную дырку не ходит. Все данные из RAG просто текстом вставляются вместе с моим изначальным вопросом в промпт. Всё это попадает в контекст. Модель это понимает и начинает в соответствии с этим отвечать.

Знание +1: А вот дообучение LoRA - это уже привычки в весах. Но база-сеть та же, но над ней адаптер. Можно выполнить операцию merge и будет новая модель. Но как оказалось, на моем ПК это нереально долго. Я могу быть не прав, но merge упирается в процессор и диск, и GPU тут вообще никак не помогает. В общем, это два разных метода добавить знаний сети. Но в случае с RAG - тратится контекст, а в случае с LoRA нет.

Осознание +1: LoRA не заменяет RAG/rules в контексте. А контекст - это только то, что существует - факты, тезисы. Но в целом, ответ от наличия RAG может быть лучше, чем от обучения.

Дискутируя с ИИ про то, как обучать модель и зачем - появилось частичное понимание, почему не стоит долго обучать модель одними данными, максимально снижая ошибку. Если обучать долго, то ответ будет "зазубриваться", а нужно получить ответ через рассуждение. Именно поэтому не на все задачи в датасете есть ответы. Это как раз для того, чтобы мы научили сеть через задача-ответ, а потом уже даем новую задачу, и ожидаем ответ через рассуждения. Но решение от сети ждем самостоятельное. Далее, имея её рассуждение - ответ, мы можем его валидировать, потому что у нас имеется правильный ответ на задачу. Но увы. Похоже, что размера сети 0.5В не хватит даже на то чтобы зазубрить ответы.

Знание +1: Hold-out («оставлено не решенным») — задачи, которые не попадали в обучение (ни в challenge-train.jsonl, ни в train-merged для этого slug). Их используют только чтобы проверить модель вслепую, а не «насколько она зазубрила учебник».

А что вообще можно ждать от 0.5B сети? И что вообще в целом ждать от сети? как она работает? Мы же пользуемся сетями и это какая то магия. А понимание, как они работают - высшая магия. Но хотя бы понять, что и как она отвечает.

Знание +1: сеть - это вообще предсказатель следующего правильного токена исходя из текущего контекста.

Что? В смысле?

Осознание +1: осознание того, как думает ИИ и что она может выдавать в ответ, какую задачу она может решить, а какую нет - один из ключевых моментов для получения инструмента разработчика.

И вот тут я начинаю догадываться, что иду вообще не туда. Я то хочу получить от нейронки прямую генерацию кода на Forth! Но требовать от сети генерацию обратной польской нотации (RPN (1 2 +)) - напрямую это ошибка. Она ни в силу малого объема обучающих данных, ни в силу своей природы - последовательно генерировать слова - вообще не может отменить свои слова и переставить их (без применения внешнего инструмента).

Осознание +1: сервисы типа cursor - просто создают набор инструментов вокруг думающей модели. Причем текстовых, потому что другого способа связи нет. У модели один примитив: вопрос → ответ. То, что в UI выглядит как Agent с «размышлениями», — Cursor под капотом: это просто несколько скиллов и инструментов mcp.

Но мне по прежнему не дает покоя мысль. А зачем тогда существуют такие модели по 0.5B?

Нужно помнить, что никакая сеть не запускает forth в голове, не представляет себе стек и не имеет его в памяти. Она может пользоваться контекстом как блокнотом, в общем, как и человек. Но нужно на много больший объем сети. Маленькие модели могут делать какие-то очень простые вещи, типа автодополнения.

Попутно выяснилось, что еще и размер модели фиксирован. LoRA не «вырастит» 0.5B до других размеров, если добавлять данных. Сеть всегда остается такого же размера.

Дальше я пытался понять, а чему же мы тогда учили сеть? Например, я учил сеть определению слов: факториал, фибоначи итд. Видел как меняется loss. Он снижается, казалось бы, можно поучить подольше и все будет хорошо. Задавал вопросы, на что это влияет. Но в итоге мне рассказали, что при снижении loss до 1 - это нормальное обучение, а меньше уже зазубривание. Да и вообще нет правильного ответа на вопрос - при каком loss надо заканчивать. Если обучить до очень низкой ошибки, то просто на запрос fib придет ответ точный, зазубренный. Как если бы у школьника был объем знаний 10 лет русского языка, но ему еще дали зазубрить какие-то слова на английском. Ну он их зазубрит, и только их сможет сказать. Но другого ничего сделать не сможет.

Вообще я попробовал понять, а чем нейросеть, как дерево, отличается от дерева слов и понятий Forth? Модель же может понимать и классифицировать любую часть Forth выражения. Каждое отдельное слово - это отдельное понятие. Может стоит сначала обучить простым стековым операциям, сложение там итд. А то получается, что я базовым вещам модель не обучил, а сразу прошу решать сложные задачи на форте. Может она поэтому не решает?

Знание +1: из модели обученной под Python миллионами примеров не сделать модель, которая будет писать на Forth на базе 100 примеров.

Знание +1: вообще, просить и ожидать от сети точные формулировки - это ошибка. Сама природа сети в том, что она ошибается в мелких деталях и синтаксисе и прям точно ошибется в синтаксисе форта. Чтобы модели генерили json их очень долго и упорно учат. Научить модель с нуля - у домашнего пользователя нету таких ресурсов (ни технических, на научно-датасетовых)

Но чего же удалось добиться? Я сначала получил вообще очень странный ответ на малой модели. Потом стал дообучать. Увидел выше указанные снижения loss, но лучше не стало. А потом вообще выяснилось, что был рассинхрон промптов. То есть ошибка в скриптах данных на обучении. После исправления, в итоге получились ответы похожие на правду что-то. Но только именно что похожие:

Слово	Модель	Эталон (tests/ans/)
gcd	begin dup 0= … while dup 0= … dup 1 swap gcd	begin dup while tuck mod repeat drop
factorial	0= if drop exit then 1* factorial	dup 1<= if drop 1 exit then dup 1- recurse *
divisible?	1 div 0= if 1 else 0	mod 0=

Само пределение слова было обернуто в правильный формат : word ( … ) … ; есть — это уже не markdown/return формат ответа, как было. Но логика неверна на всех трёх. При проверке gforth справедливо падает на тестах.

Модель не копирует строки из jsonl (gcd в train есть) — 0.5B не удерживает алгоритм даже при корректном SFT.

Но smoke тест писал «OK», потому что он проверял наличие ":" в начале определения слова и ";" в конце. Он не сравнивает с эталоном и не требует TESTS OK.

В train не было базовых основ по возрастанию сложности (curriculum), а сразу шли определения сложных задач (gcd/factorial). Таблица выше и есть итог: даже честный SFT не спас. По факту Track A закрыли окончательно.

Но в голове всё же крутилась идея о том, что логически дерево форта и дерево мышления нейросети очень похожи и генерировать Форт код для нейросети - как будто бы просто записать путь классификации того, что ты осознал. Но я не могу объяснить, как это выразить. И не понимаю, можно ли это понимание применить к результату.

Раз за разом мы обсуждали эту идею и каждый раз ИИ мне объясняла, что мне так не сделать. И что лучше получить от ИИ - нормально описанный алгоритм, в виде кода на известном ИИ языке программирования, или псевдокоде и уже с помощью внешнего преобразования утилитой - получить Форт код! Потому что утилита сделает эту операцию, быстро, дешево и точно. В отличие от нейросети, которая будет делать это путем обработки огромных массивов данных и при этом будет иметь ненулевой шанс ошибиться в какой-нибудь букве. Это все равно, что забивать гвозди микроскопом.

После этого я сдался. И признал, что надо делать именно так. Тем более, я уже начал догадываться, что прямая работа с синтаксисом и нотацией - это еще не программирование. Нужно ведь еще алгоритмы понимать, структуры данных и иметь опыт к решению задач используя алгоритмы и структуры. На решение алгоритмических задач! И Coder модели как раз на это и обучены и надо использовать результат их работы. И этот результат уже преобразовывать в Forth не нейронным способом.

А каким способом? Я начал спрашивать, а может быть модели могут выдать AST? Это почти Forth. Прямого ответа на то, что какая-то модель умеет отдавать AST не нашлось, но по мнению ИИ, при обучении, модели видели миллионы деревьев из учебников по компиляторам. Но чтобы получит AST утверждается, что программисты просят показать ответ в виде List - S-выражений.

Задача: 1 + (2 * 3)

AST (в формате Lisp, который отлично генерируют модели): (+ 1 (* 2 3))

Результат скрипта преобразования в Forth: 1 2 3 * +

Вообще Форт и Лисп - зеркальны. Их можно выражать один из другого.

Какие еще варианты? Ассемблер? Не совсем то. Ассемблер для стековой виртуальной машины? Да!

Вот стековые языки, которые LLM знают на 10 из 10:
WebAssembly (WASM): В текстовом виде (.wat) WASM — это чистая стековая машина.
Байт-код Java (JVM): Вычисления в JVM происходят строго на стеке операндов.
PostScript (PS): Язык принтеров PDF. А теперь шок-контент: PostScript — это диалект Форта! Он использует ту же Обратную Польскую Запись, те же слова dup, pop (аналог drop), exch (аналог swap).
CIL (Байт-код .NET) и Байт-код Python (dis) — тоже стековые.

Далее я прихожу к выводу о том, что итоговый Forth результат можно получить вообще другим путем - через внешний инструмент преобразования. В составе набора инструментов вокруг ИИ модели - так называемого "завода".

Остановиться решил на WASM

Смотри, как поразительно WASM похож на Форт:
Код на WASM (модель пишет его без ошибок):

get_local $a
get_local $b
i32.add

Далее мы тупо заменяем и получаем Forth.

Чтож, подобьем еще раз:

Мой тезис: «Forth должен быть простым для дерева/нейросети»

Ответ ИИ: Forth прост для компилятора, не для autoregressive LLM:

LLM генерирует слева направо; RPN требует «держать операцию в голове», пока кладёшь операнды. Forth смешивает данные и метапрограммирование (immediate, ['], create/does>) — трансформер этого не «исполняет», только имитирует текст. Поэтому ваша цепочка «разобрать задачу → записать токенами» правильная — но середина (разбор → RPN) должна быть алгоритмом, а сетью, и тем более не сетью на 0.5B.

После этого мне захотелось четко разграничить "инструмент-задача" и какие из моих задач надо решать нейросетями, а какие - инструментами экосистемы "завода".

Чего не стоит ждать от ИИ (архитектурные ограничения):

Исполнять код, держать стек в «голове», откаты при ошибке — нет внутренней VM; только текст.
Гарантированная корректность — никогда; только вероятность.

Потом мы немного поговорили про то, что кроме дообучения модели, есть еще и обучение модели вообще с нуля (не переучивать с Python на Forth, а учить на Forth с нуля). И что этот процесс для домашней разработки вообще нежизнеспособен. Нужно научить делать все уровни программирования. Но даже если иметь много денег и специалистов - ошибочна сама по себе идея делать текст на Forth. Нейросеть все равно будет ошибаться, а если нет, то это забивание гвоздей микроскопом.

Но что мы можем сделать? Мы можем сделать "Завод" из тулчейна!

Ну и далее, выходит, что мы можем получить от большой модели саму суть алгоритма и код в удобной для трансляции в Форт нотации. Инструментально преобразовать. Инструментально проверить. Дать ответ. Тем самым мы избавим большую модель через боль, страдания и большие затраты токенов, программировать на Forth.

Так что задача сильно поменялась с точки зрения философии решения: ИИ не должен писать на Forth сам, а должен с помощью внешних инструментов получить форт и проверить результат. И для валидации преобразования как раз пригодятся написанные за несколько дней инструменты для Forth экосистемы: fmix + test, lint flint, fcov coverage.

Если все получится, то мы сможем получать Forth код, но обходиться это будет дешевле. Если cursor+Opus запускать над этим tools функционалом, то результат должен получаться дешевле.

Таким образом, мы пришли к пониманию и изобрели (велосипед) такое понятие, которое все называют skills/tools.

Осознание: монолитных ИИ нейронок, которые умеют программировать - нет. Мы ими не пользуемся. Мы пользуемся ИИ экосистемами, которые умеют в итоге получить программный код. А дома мы запускаем одну моно модель. И потом удивляемся - я че она такая тупая. Но мы сравниваем одну маленькую модель с большим набором больших моделей и инструментов вокруг них.

Терминология ИИ

Термины, которые ИИ активно использовала, объясняя мне принципы своей работы. Вообще в этом есть забавный момент: мы с ИИ обсуждаем ИИ )) Я их дам прямо так, как их мне объяснила ИИ. В рамках контекста нашего с ней диалога. Я думаю, лучше по каждому слову искать в интернете более корректное объяснение. Тут ценен именно сам перечень слов.

Термин	По-простому	Что происходит технически	Для Forth / frules
Параметр (parameter)	«Ячейка памяти» сети	Одно обучаемое число в матрице	0.5B = 500 млн таких чисел
0.5B / 7B	Размер / ёмкость модели	Число параметров; больше → больше паттернов	0.5B — мало для алгоритмов на стеке
Pretrain (претрейн)	«Школа жизни» на интернете	Predict next token на огромном корпусе	Forth там ≈ 0%; зато Python, C, «код вообще» в достатке
Token (токен)	Кусок текста (~слово/часть)	Единица входа/выхода LLM	`: gcd` может быть 2–3 токена
Transformer	Архитектура LLM	Attention: каждый токен «смотрит» на предыдущие	Нет стека, нет VM — только текст
SFT	Supervised fine-tuning	Учебник: prompt → эталонный ответ	Ваш `train-merged.jsonl`
Instruct / instruction-tuned	Модель «ассистент»	SFT на диалогах «вопрос → ответ»	`Qwen2.5-Coder-0.5B-Instruct`
LoRA	Тонкая «накладка»	Мало новых весов; база заморожена (QLoRA: в 4-bit)	~17 MB поверх 0.5B
QLoRA	LoRA + сжатая база	База в 4-bit, учится только adapter	Track A на RTX 4070
Loss (потери)	Ошибка угадывания	Cross-entropy: насколько модель промахнулась по следующему токену	Низкий loss ≠ рабочий Forth
Epoch (эпоха)	Один проход по всему jsonl	Сколько раз модель видела каждую строку	3 ep на 139 строк — мало для обобщения
Overfit / зазубривание	Запомнила train, не переносит	Отлично на тех же промптах, плохо на новых	Старый run: зазубрила rules, не gcd
Generalization (обобщение)	Перенос на новое	Работает на промптах/задачах вне train	0.5B + Forth: practically нет
Memorization	Копирование train-пар	Ответ ≈ строка из jsonl	Даже этого 0.5B не сделала для gcd
Curriculum	От простого к сложному	Сначала `1 2 +`, потом `: square`, потом gcd	В frules не было; нужно для маленьких моделей
Hold-out	Задачи не из train	Только для проверки	`eval_holdout` в `tests/challenges/`
System prompt	Роль / правила в чате	Первое сообщение `role: system`	SFT: short (~50 tok); Ollama: full rules
Reasoning (рассуждение)	Цепочка шагов к ответу	Модель генерирует промежуточные шаги (CoT)	Forth-стек = нужен «scratchpad» или алгоритм
CoT (chain-of-thought)	«Думай вслух» в тексте	В ответе: стек, разбор, потом код	Помогает большим моделям; 0.5B ломается на длинной цепочке
Rules (frules)	Текст в промпте, не в весах	`.mdc` в SYSTEM; веса не меняются	Cursor / Ollama — сильнее LoRA 0.5B
Merge LoRA	Влить adapter в базу	Полные веса для Ollama/GGUF	Отдельно от качества Forth
GGUF / Ollama	Формат локального inference	Квантованная модель для чата	Rules в Modelfile ≠ train jsonl

Побочные продукты этой увлекательной недели

Пока я всем этим занимался, попутно создавались некоторые инструменты. В итоге, мне захотелось попробовать оценить объемы того, что получилось: по периоду времени, объему функционалу и объему кода.

Repo	Период	Версии	Одной строкой	Код*
fmix	2024 → 24.05	0.7.x	Пакетный менеджер	~1.2k LOC `.4th`
fsemver	24.05, 1 день	0.1.x	Semver-библиотека (для fmix/flint)	~360 LOC
fcov	24.05, 1 день	0.1→0.3	Инструмент Coverage: console/JSON/LCOV/HTML	~2.8k LOC
flint	24.05, 1 день	0.1→0.2.2	Lint дубликатов `: word`	~825 LOC
fenum	22.05	0.1.x	Библиотека для `ulist` и `enum` (используется в flint/fcov)	~750 LOC
fhdlgen	20–24.05	0.3.1	Преобразователь DSL→Verilog (расскажу в следующий раз)	~2k LOC
frules	25–31.05	0.1.x	151/98/53, Track A closed, docs hub	gold ~6.5k; rules ~2.1k md

*LOC без forth-packages/ — просто чтоб оценить объемы.

24 мая — flint, fcov, fsemver были написаны всего за один день с помощью Opus 4.8. frules — ещё шесть дней: challenge bank, gold, первые проверки (Track A), hub с документацией по Forth.

Обычно меня душит жаба, за бесцельно потраченные деньги. Но здесь — нет: ни денег, ни бессонных ночей не жалею. Слишком много узнал и осознал за эти дни. Многие навыки пригодились и на основной работе

Коротко: антипаттерны

«Opus напишет весь код : word ... ;» — overhard + overkill + overinvoice.
«LoRA научится postfix» — нет (Track A закрыт).
Ждать от 0.5B «завода» — получите стажёра, не конвейер.
Генерировать Forth напрямую, когда нужен IR → transpiler.

Пять оплаченных инвойсов за неделю (23–29 мая): $75.06 + $50.85 + $34.66 + $75.00 + $27.84 ≈ *$263**. Счёт ползёт вместе с rot и thinking.

Чему мы научились?

Источники

VitaSound:

Продолжение следует ...

FMix: пакетный менеджер для Forth

Alexey Bolshakov — Mon, 18 May 2026 23:12:43 +0000

В современных языках программирования мы почти всегда ожидаем, что рядом с языком будет удобный инструмент для работы с проектом.

В Elixir есть Mix. В Rust есть Cargo. В Ruby есть Bundler и RubyGems. В Haskell есть Cabal и Stack. В JavaScript есть npm, pnpm и Yarn. В Go есть modules.

Мы привыкли, что можно создать проект одной командой, описать зависимости в одном файле, подтянуть их из сети, запустить тесты, собрать релиз. Это кажется базовой частью экосистемы, а не отдельной роскошью.

Но у старых языков программирования часто другая история.

Когда многие из них создавались, такой подход ещё не был стандартом. Код распространялся иначе, проекты были устроены иначе, а экосистемы развивались без привычных сегодня package managers и build tools.

И это до сих пор чувствуется.

Почему я задумался об этом

Для одного из своих проектов я использую Forth.

Forth — очень интересный язык. Минималистичный, прямой, необычный. В нём есть что-то очень привлекательное: ты находишься близко к вычислениям, близко к стеку, близко к самому железу вычислительной машины (которую иногда я делаю сам).

Но когда я начал писать на Forth что-то более-менее похожее на проект, мне быстро стало не хватать привычных вещей:

создать новый проект;
описать зависимости;
скачать зависимости;
запускать тесты;
иметь понятную структуру проекта;
подключать библиотеки из Git;
не держать всё вручную в голове.

Да, можно использовать git submodules, можно копировать файлы руками, можно придумывать свои соглашения. Но для меня это не очень удобный путь. Я хотел что-то ближе к тому, к чему привык в современных языках.

Я нашёл библиотеку f.4th, связанную с theforth.net. Это полезный инструмент, но у него другой подход: библиотеки и версии хранятся на своём сервере.

Мне же хотелось уметь подтягивать зависимости прямо из Git-репозиториев. Например, указать GitHub URL, ветку или тег, и получить библиотеку в проект.

Так появилась идея сделать fmix.

Что такое FMix

fmix — это небольшой build tool и package tool для Forth, вдохновлённый Elixir Mix.

Репозиторий: github.com/VitaSound/fmix

Он не пытается быть большим фреймворком. Его задача проще: дать Forth-проекту минимальный набор привычных инструментов.

Сейчас fmix умеет:

fmix new example
fmix packages.get
fmix test
fmix version

То есть можно создать новый пакет, подтянуть зависимости, запустить тесты и посмотреть версию инструмента.

Создание проекта

Новый проект создаётся так:

fmix new example
cd example

После этого появляется базовая структура проекта:

example/
  example.4th
  package.4th
  README.md
  tests/
  forth-packages/

package.4th — это файл описания пакета. В нём указывается имя, версия, лицензия, основной файл и зависимости.

Пример:

forth-package
    key-value name example
    key-value version 0.1.0
    key-value license COPL
    key-value description example
    key-value main example.4th

    key-list dependencies f git https://github.com/VitaSound/f tag 0.2.4
    key-list dependencies ttester git https://github.com/VitaSound/ttester tag 1.1.0
end-forth-package

Мне нравится, что сам файл тоже написан в стиле Forth. Это не JSON, не YAML и не TOML, а маленький декларативный Forth-формат.

Зависимости из Git

Главная причина, по которой я начал делать fmix, — это зависимости из Git.

В package.4th можно указать зависимость так:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git branch main

Или так, если нужна конкретная версия через tag:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git tag 0.1.0

После этого достаточно выполнить:

fmix packages.get

Зависимости будут установлены в локальную папку проекта:

./forth-packages/

Структура позволяет хранить разные версии одной библиотеки рядом друг с другом:

forth-packages/
  f/
    0.2.4/
  ttester/
    1.1.0/

Подключать зависимость можно обычным require:

require ./forth-packages/f/0.2.4/f.4th

Поддержка theforth.net

Хотя мне хотелось Git-зависимостей, я не хотел полностью отказываться от существующей экосистемы.

Поэтому fmix также умеет работать с пакетами из theforth.net через f.4th.

Например:

key-list dependencies f 0.2.4

Таким образом, в одном проекте можно использовать и Git-зависимости, и пакеты из theforth.net.

Тесты

Ещё одна базовая вещь, которой мне не хватало, — запуск тестов.

В fmix есть команда:

fmix test

Она запускает тесты из директории tests/.

Можно запустить и конкретный файл:

fmix test tests/some_test.4th

Для тестов используется ttester. Если ttester есть в зависимостях проекта, fmix берёт его из ./forth-packages. Если нет — использует версию из установленного FMIX_HOME.

Для меня это важно: тесты должны запускаться одной командой. Даже если проект маленький.

Что было исправлено в последних версиях

fmix пережил уже несколько поколений изменений.

Первые версии я писал сам. Но я не очень сильный Forth-разработчик, поэтому многие вещи давались тяжело. Одну крупную переработку я сделал с помощью Gemini. Последнюю версию я уже доводил с помощью Cursor.

В последних релизах было исправлено довольно много практических проблем.

Появился GitHub Actions CI: workflow собирает GForth 0.7.9 из исходников и запускает:

gforth fmix.4th -e version
gforth fmix.4th -e test

Позже появился release pipeline: при push version tag автоматически создаётся GitHub Release, а текст релиза берётся из файла .github/RELEASE_NOTES_X.Y.Z.md.

Также были исправлены проблемы с путями. Раньше часть логики была завязана на PWD, теперь проект определяется через текущую директорию запуска. Это важно, потому что FMIX_HOME указывает на установленный fmix, а команды должны работать с текущим проектом.

Были исправлены ошибки при установке зависимостей:

git clone теперь проверяет результат;
неуспешные shell-команды завершают GForth с exit code 1;
перед git clone создаются родительские директории;
git fetch и checkout выполняются так, чтобы ошибка не маскировалась;
для Git-команд используется GIT_TERMINAL_PROMPT=0, чтобы команда не зависала в non-interactive окружении.

Ещё одна важная вещь — валидация входных данных. fmix проверяет имена пакетов, версии, пути, Git URL и Git refs перед тем, как вызывать cp, sed или git. Это не сложная система escaping, а простой whitelist, но он отсекает пробелы, ;, $, backticks, pipes и другие shell metacharacters.

Неожиданная проблема: терминал

Отдельная история была с терминалом. Перед тем, как пользоваться командой fmix в консоли, ее нужно прописать как alias.

Так вот при запуске через простой alias вроде:

alias fmix='gforth "$FMIX_HOME/fmix.4th" -e'

после выполнения команд терминал иногда оставался в плохом состоянии. На prompt появлялись странные символы вроде:

0c0c
[?2004l

Особенно это проявлялось в WSL.

В версии 0.4.4 я перешёл на launcher script bin/fmix. Он восстанавливает TTY после команд, сбрасывает bracketed paste mode и немного очищает накопившийся ввод из /dev/tty. На самом деле все эти вещи я бы точно не разрешил самостоятельно. Я терпеливо помогал нейросети раз за разом пробовать некоторые гипотезы, чтобы исправить эту проблему. В отличие от тех ИИ, что я пробовал раньше, в этот раз я только один раз решил прервать ИИ и создать новый контекст, потому что она как будто зациклилась в бесконечном исправлении.

Однако, получилось и теперь вместо alias рекомендуется использовать:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

И запускать просто:

fmix

Установка

Сейчас установка выглядит так:

git clone https://github.com/VitaSound/fmix.git ~/fmix

Затем нужно добавить в shell config (например .bashrc):

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

После этого команда начнет работать прямо в консоли:

fmix version

Важно: сейчас fmix рассчитан на Linux, Git, sed, cp и GForth 0.7.9.

Я не рекомендую использовать GForth более ранних версий и версию из Snap. Snap запускает программы в изолированном окружении, из-за чего текущая директория и пути могут не совпадать с тем, что ожидает shell session. Это ломает команды вроде new и packages.get.

Лучше использовать GForth из apt, локальную сборку или tarball с официальной страницы GForth.

Зачем это всё

Мне кажется, что старым языкам очень нужны такие инструменты, чтобы соответсвовать современным реалиям.

Не обязательно огромные. Не обязательно идеальные. Но хотя бы такие, которые закрывают базовые сценарии. Когда у языка есть удобный инструмент вокруг проектов, он становится дружелюбнее.

Новому человеку проще попробовать язык. Опытному пользователю проще начать новый проект. Библиотеки проще переиспользовать. Тесты проще запускать.

Это не меняет сам язык, но меняет опыт работы с ним. Позволяет взять старый инструмент в новые проекты.

В случае Forth это особенно интересно. Forth часто воспринимается как что-то старое, странное и нишевое. Но, возможно, часть этой «старости» находится не только в языке, а в отсутствии привычной современной обвязки.

Если добавить удобные инструменты, язык может ощущаться совсем иначе.

Что дальше

fmix пока маленький и экспериментальный.

Сейчас он умеет создавать пакеты, подтягивать зависимости из Git и theforth.net, запускать тесты.

В будущем хочется улучшать совместимость, добавить документацию, и, возможно, добавить больше команд вокруг разработки Forth-пакетов.

Но уже сейчас мне стало гораздо удобнее работать над своими Forth-проектами. Но это уже совсем другая история

Ссылки

FMix: a package manager for Forth

Alexey Bolshakov — Mon, 18 May 2026 23:12:32 +0000

In modern programming languages, we almost always expect the language to come with a convenient tool for working with projects.

Elixir has Mix. Rust has Cargo. Ruby has Bundler and RubyGems. Haskell has Cabal and Stack. JavaScript has npm, pnpm and Yarn. Go has modules.

We are used to being able to create a project with one command, describe dependencies in one file, fetch them from the network, run tests, and prepare a release. It feels like a basic part of the ecosystem, not a luxury.

But older programming languages often have a different story.

When many of them were created, this approach was not yet a standard expectation. Code was distributed differently, projects were structured differently, and ecosystems grew without the package managers and build tools we now take for granted.

And you can still feel it today.

Why I Started Thinking About This

For one of my projects I use Forth.

Forth is a very interesting language. It is minimalistic, direct, and unusual. There is something very attractive about it: you are close to computation, close to the stack, and close to the actual hardware of the computer, which I sometimes build myself.

But when I started writing something in Forth that looked more or less like a project, I quickly began missing the usual things:

creating a new project;
describing dependencies;
downloading dependencies;
running tests;
having a clear project structure;
connecting libraries from Git;
not having to keep everything manually in my head.

Yes, you can use git submodules, copy files by hand, or invent your own conventions. But for me, this is not a very convenient path. I wanted something closer to what I am used to in modern languages.

I found the f.4th library, which is connected to theforth.net. It is a useful tool, but it follows a different approach: library code and versions are stored on its own server.

I wanted to be able to pull dependencies directly from Git repositories. For example, specify a GitHub URL, a branch or a tag, and get the library into the project.

That is how the idea for fmix appeared.

What Is FMix

fmix is a small build tool and package tool for Forth, inspired by Elixir Mix.

Repository: github.com/VitaSound/fmix

It does not try to be a large framework. Its goal is simpler: to give a Forth project a minimal set of familiar tools.

Right now fmix can do this:

fmix new example
fmix packages.get
fmix test
fmix version

In other words, you can create a new package, fetch dependencies, run tests, and check the tool version.

Creating a Project

A new project is created like this:

fmix new example
cd example

After that, you get a basic project structure:

example/
  example.4th
  package.4th
  README.md
  tests/
  forth-packages/

package.4th is the package description file. It contains the name, version, license, main file, and dependencies.

Example:

forth-package
    key-value name example
    key-value version 0.1.0
    key-value license COPL
    key-value description example
    key-value main example.4th

    key-list dependencies f git https://github.com/VitaSound/f tag 0.2.4
    key-list dependencies ttester git https://github.com/VitaSound/ttester tag 1.1.0
end-forth-package

I like that the file itself is also written in a Forth-like style. It is not JSON, YAML, or TOML. It is a tiny declarative Forth format.

Dependencies from Git

The main reason I started making fmix was Git dependencies.

In package.4th, you can define a dependency like this:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git branch main

Or like this, if you need a specific version via a tag:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git tag 0.1.0

After that, you only need to run:

fmix packages.get

Dependencies will be installed into the local project directory:

./forth-packages/

This structure makes it possible to keep different versions of the same library side by side:

forth-packages/
  f/
    0.2.4/
  ttester/
    1.1.0/

You can include a dependency with the usual require:

require ./forth-packages/f/0.2.4/f.4th

Support for theforth.net

Although I wanted Git dependencies, I did not want to completely abandon the existing ecosystem.

So fmix can also work with packages from theforth.net through f.4th.

For example:

key-list dependencies f 0.2.4

This means one project can use both Git dependencies and packages from theforth.net.

Tests

Another basic thing I was missing was running tests.

fmix has this command:

fmix test

It runs tests from the tests/ directory.

You can also run a specific file:

fmix test tests/some_test.4th

Tests use ttester. If ttester exists in the project dependencies, fmix loads it from ./forth-packages. If not, it uses the version from the installed FMIX_HOME.

For me, this matters: tests should run with one command. Even if the project is small.

What Was Fixed in Recent Versions

fmix has already gone through several generations of changes.

I wrote the first versions myself. But I am not a very strong Forth developer, so many things were difficult for me. I made one major refactoring with the help of Gemini. I finished the latest version with Cursor.

The latest releases fixed quite a few practical problems.

GitHub Actions CI was added: the workflow builds GForth 0.7.9 from source and runs:

gforth fmix.4th -e version
gforth fmix.4th -e test

Later, a release pipeline was added: when a version tag is pushed, a GitHub Release is created automatically, and the release text is taken from .github/RELEASE_NOTES_X.Y.Z.md.

Path handling was also fixed. Previously, part of the logic depended on PWD. Now the project is detected from the directory where the command is started. This matters because FMIX_HOME points to the installed fmix, while commands should operate on the current project.

Several dependency installation problems were fixed:

git clone now checks its result;
failed shell commands make GForth exit with code 1;
parent directories are created before git clone;
git fetch and checkout are executed so that failures are not hidden;
Git commands use GIT_TERMINAL_PROMPT=0, so the command does not hang in a non-interactive environment.

Another important thing is input validation. fmix validates package names, versions, paths, Git URLs, and Git refs before calling cp, sed, or git. It is not a complex escaping system, but a simple whitelist. It rejects spaces, ;, $, backticks, pipes, and other shell metacharacters.

An Unexpected Terminal Problem

There was a separate story with the terminal. Before using the fmix command in the console, it had to be configured as an alias.

When running through a simple alias like this:

alias fmix='gforth "$FMIX_HOME/fmix.4th" -e'

the terminal sometimes ended up in a bad state after commands finished. Strange symbols appeared in the prompt, for example:

0c0c
[?2004l

This was especially visible in WSL.

In version 0.4.4, I switched to the bin/fmix launcher script. It restores the TTY after commands, resets bracketed paste mode, and briefly drains queued input from /dev/tty. To be honest, I would definitely not have solved all of that on my own. I patiently helped the neural network try hypothesis after hypothesis to fix the problem. Unlike the AI tools I had tried before, this time I only had to stop the AI once and create a new context because it seemed to get stuck in an endless correction loop.

But it worked, and now instead of an alias it is recommended to use:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

And then run it simply as:

fmix

Installation

Right now installation looks like this:

git clone https://github.com/VitaSound/fmix.git ~/fmix

Then add this to your shell config, for example .bashrc:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

After that, the command should work directly in the console:

fmix version

Important: at the moment fmix expects Linux, Git, sed, cp, and GForth 0.7.9.

I do not recommend using earlier versions of GForth or the Snap version. Snap runs programs in a confined environment, so the current directory and paths may not match what the shell session expects. This breaks commands like new and packages.get.

It is better to use GForth from apt, a local build, or a tarball from the official GForth page.

Why This Matters

I think old languages really need tools like this to fit modern realities.

They do not have to be huge. They do not have to be perfect. But they should at least cover the basic scenarios. When a language has convenient tooling around projects, it becomes friendlier.

It is easier for a newcomer to try the language. It is easier for an experienced user to start a new project. Libraries are easier to reuse. Tests are easier to run.

This does not change the language itself, but it changes the experience of working with it. It allows an old tool to be used in new projects.

In the case of Forth, this is especially interesting. Forth is often seen as something old, strange, and niche. But maybe part of that “oldness” is not only in the language itself, but also in the absence of familiar modern tooling around it.

If we add convenient tools, the language can feel very different.

What Is Next

fmix is still small and experimental.

Right now it can create packages, fetch dependencies from Git and theforth.net, run tests, and publish releases through GitHub Actions.

In the future, I would like to improve compatibility, add documentation, and maybe add more commands around Forth package development.

But even now, it has become much more convenient for me to work on my Forth projects. But that is another story.

AD9833 DDS Generator Board

Alexey Bolshakov — Thu, 19 Mar 2026 16:52:05 +0000

A frequency generator board based on the AD9833 chip. Purchased as a frequency-tunable clock signal source. The board is equipped with a 25 MHz oscillator. It can generate signals from 0 to 12.5 MHz (though waveform quality may not be satisfactory across the entire range). The waveform can be switched between sine, sawtooth, and square wave. All necessary signals are brought out to pin headers. Controlled via SPI interface.

Architecturally, it contains one 28-bit phase accumulator register, two frequency tuning registers, and two phase offset registers. Only one pair (frequency/phase) can be active at a time. This allows for frequency modulation without phase discontinuity or phase modulation, if needed. However, there is no dedicated hardware input for selecting the register pair – switching is possible only via SPI commands.

Oscilloscope waveforms follow below.

Test setup

To control the DDS, commands must be sent via SPI. I am using an STM8 (STM8S105K4T6) with its hardware SPI. It was crucial to find the correct SPI operating mode. For the STM8 (and likely for STM32 as well), this is Mode 2 (CPOL = 1, CPHA = 0). For more details, refer to the documentation.(RM0016 - STM8S Series and STM8AF Series 8-bit microcontrollers (20.4 SPI registers)). Oscilloscope: C1-112A, 10 MHz bandwidth; probe: generic Chinese P6100 type, rated for 100 MHz. Multimeter: Aneng M20, used as a frequency counter.

I did not write firmware for the microcontroller in the conventional sense. Instead, I flashed the STM8 with the eForth system and connected to it via a serial console. From the console, I sent SPI commands directly, after pre-defining the necessary intermediate words. It looked roughly like this:

...

: word.hi $0100 / ;
: word.lo $00ff and ;

: spi_wr8 SPI_DR c! TXE? ;
: spi_wr16  dup word.lo swap word.hi spi_wr8 spi_wr8 ;
: spi_wr16n dup word.lo swap word.hi nss.lo spi_wr8 spi_wr8 BSY? nss.hi ;
: spi_wr32n nss.lo spi_wr16 spi_wr16 bsy? nss.hi ;

...

$2100 spi_wr16n         // reset
$5c20 $4a3d spi_wr32n   // freq0
%0111111111111111 %0100000000000000 spi_wr32n   // freq0
%0111111111111111 spi_wr16n %0100000000000000 spi_wr16n
$9c29 $8a3d spi_wr32n   // freq1
$c000 spi_wr16n         // phase0f
$e000 spi_wr16n         // phase1
$2000 spi_wr16n         // sine
$2020 spi_wr16n         // square
$2002 spi_wr16n         // saw

It turned out that I used the system interactively, rather than reflashing the firmware each time. This approach reminds me of working with the Erlang virtual machine, where you can debug and modify running code on the fly on production.

Oscilloscope Waveforms

Sine 1 KHz

10 KHz, 50 KHz, 100 KHz, 500 KHz, 2 MHz, 4 MHz, 8 MHz
10 KHz

50 KHz

100 KHz

500 KHz

2 MHz

4 MHz

8 MHz

Saw 1 KHz

10 KHz, 50 KHz, 100 KHz, 500 KHz, 2 MHz, 4 MHz, 8 MHz
10 KHz

50 KHz

100 KHz

500 KHz

2 MHz

4 MHz

8 MHz

At 2 MHz, floating peaks on the sawtooth waveform are already visible. At 4 MHz, they become very pronounced. And at 8 MHz, we end up with 25/8 = 3.125 samples per period.

Purely to explore my oscilloscope and probes, I also tried the square wave mode. However, I couldn't be bothered to recalculate the frequency grid. In square wave mode, the period is twice as long, so the resulting frequencies were different.

5 kHz

25 KHz, 250 KHz, 1 MHz, 2 MHz, 4 MHz
25 KHz

250 KHz

1 MHz

2 MHz

4 MHz

4 MHz more wide

Starting from 1 MHz, jitter is obviously present; at 2 MHz, it becomes visible on the oscilloscope waveform.

By the way (for those who aren't aware), it's important to note that at high frequencies, to avoid degrading signal edges, you should use the probe in 10:1 attenuation mode. This reduces the probe's loading effect on the circuit (and it's even better to avoid using alligator clips altogether). However, this will require increasing the oscilloscope's input amplifier gain by a factor of 10 to compensate for the attenuation.

Also, don't forget to adjust the probe compensation for accurate waveform display, using a small dielectric (non-metallic) screwdriver.

For comparison, here's a photo showing the same signal — a 2 MHz square wave — captured with the probe set to 1X versus 10X attenuation.

2 MHz - 1х

2 MHz - 10х

By the way, the original probe that came with the C1-112A is also quite decent.

2 MHz - 10х

Conclusions

I acquired this board for experiments in the field of hybrid sound synthesis for my synthesizer project. In the future, I plan to use it for a DCO (Digitally Controlled Oscillator) module — but not with a fixed Master Clock frequency; rather, with a frequency that is a multiple of the generated note frequency. This way, the DAC in the DCO can utilize its full scale and DAC resolution without skipping steps. All of this is part of the effort to combat generation accuracy loss and aliasing... But that's a whole different story.

Links

1 The original version of this article

https://mysku.club/blog/aliexpress/79168.html

2 My Telegram channel "Programmer's Tips": https://t.me/ProProgs

3 eForth - Forth for microcontrollers

https://github.com/TG9541/stm8ef/wiki/STM8-eForth-Programming

4 Links about my synth project

https://github.com/UA3MQJ/fpga-synth/wiki

https://github.com/VitaSound/hdl-modules

https://soundcloud.com/vitasynth

http://www.youtube.com/channel/UCGi-A9KGhKhKzVT_baVw3HA

https://vk.com/vitasound

https://boosty.to/vitasound

Плата DDS генератора AD9833

Alexey Bolshakov — Thu, 19 Mar 2026 16:35:39 +0000

Плата с DDS генератором частоты на базе микросхемы AD9833. Приобретена в качестве источника тактового сигнала, перестраиваемого по частоте. На плате установлен генератор на 25 МГц. Может генерировать сигналы от 0 до 12.5 МГц (но не во всем диапазоне вас устроит форма сигнала). Можно переключать форму сигнала: синус, пила, меандр. Всё, что нужно, выведено на штыревые контакты. Управляется по SPI. Архитектурно содержит один 28-битный регистр аккумулятора, два регистра приращения, два регистра фазы. В один момент времени может быть выбрана только одна из двух пар. Это позволит, если необходимо, сформировать частотную модуляцию сигнала без разрыва фазы или фазовую модуляцию. Однако, отдельного входа выбора пары нет, переключение возможно только командами по SPI.

Далее осциллограммы

Стенд

Для управления DDS нужно подавать команды по SPI. Использую STM8 (STM8S105K4T6) и его аппаратный SPI. Очень важно было найти правильный режим работы SPI. Для STM8 (и наверняка для STM32) это будет mode 2 (CPOL = 1 and CPHA = 0). Подробнее, см. документацию(RM0016 - STM8S Series and STM8AF Series 8-bit microcontrollers (20.4 SPI registers)). Осциллограф С1-112А полоса 10 МГц, щуп китайский на 100 китайских МГц (P6100). Мультиметр Aneng M20 в качестве частотомера.

Прошивку для микроконтроллера в привычном для всех виде я не писал. Просто поставил на микроконтроллер STM8 систему eForth и далее подключался к нему через консоль. И уже в консоли отправлял команды через SPI, задав перед этим необходимые промежуточные слова. Выглядело это примерно вот так

...

: word.hi $0100 / ;
: word.lo $00ff and ;

: spi_wr8 SPI_DR c! TXE? ;
: spi_wr16  dup word.lo swap word.hi spi_wr8 spi_wr8 ;
: spi_wr16n dup word.lo swap word.hi nss.lo spi_wr8 spi_wr8 BSY? nss.hi ;
: spi_wr32n nss.lo spi_wr16 spi_wr16 bsy? nss.hi ;

...

$2100 spi_wr16n         // reset
$5c20 $4a3d spi_wr32n   // freq0
%0111111111111111 %0100000000000000 spi_wr32n   // freq0
%0111111111111111 spi_wr16n %0100000000000000 spi_wr16n
$9c29 $8a3d spi_wr32n   // freq1
$c000 spi_wr16n         // phase0f
$e000 spi_wr16n         // phase1
$2000 spi_wr16n         // sine
$2020 spi_wr16n         // square
$2002 spi_wr16n         // saw

Получилось, что я пользовался системой интерактивно, а не перепрошивая каждый раз. Мне такой подход напоминает работу с Erlang виртуальной машиной, когда можно на ходу отлаживать и менять работающий код.

Осциллограммы

Синус 1 КГц

10 КГц, 50 КГц, 100 КГц, 500 КГц, 2 МГц, 4 МГц, 8 МГц
10 КГц

50 КГц

100 КГц

500 КГц

2 МГц

4 МГц

8 МГц

Пила 1 КГц

10 КГц, 50 КГц, 100 КГц, 500 КГц, 2 МГц, 4 МГц, 8 МГц
10 КГц

50 КГц

100 КГц

500 КГц

2 МГц

4 МГц

8 МГц

На 2 МГц уже видно плавающие пики пилы. На 4 МГц видно уже очень отчетливо. Ну и на 8 МГц у нас получается 25/8 = 3,125 отсчета на период.

Исключительно ради изучения своего осциллографа и щупов, попробовал меандр. Правда сетку частот пересчитывать было лень. В режиме меандра, период в 2 раза длиннее, поэтому частоты получились другие.

5 КГц

25 КГц, 250 КГц, 1 МГц, 2 МГц, 4 МГц
25 КГц

250 КГц

1 МГц

2 МГц

4 МГц

4 МГц более развернуто

Начиная с 1 МГц, ясное дело - джиттер, на 2 МГц его видно на осциллограмме.

Кстати (для тех, кто не в курсе), важно, что на высоких частотах, чтобы не портить фронты, нужно использовать щуп в режиме 1:10, чтобы он меньше влиял на схему (а еще лучше не использовать крокодил). Но потребуется усилить сигнал в 10 раз уже на входном усилителе осциллографа.

Так же, не стоит забывать подстраивать делитель для правильного отображения, диэлектрической отверточкой.

Для сравнения, фото, как выглядит один и тот же сигнал - меандр 2 МГц, но 1Х или 10Х

2 МГц - 1х

2 МГц - 10х

Кстати, родной щуп от С1-112А тоже неплох

2 МГц - 10х

Выводы

Эту плату я брал для экспериментов в области создания гибридного синтеза звука своего синтезаторного проекта. В дальнейшем планируется использовать для модуля генератора DCO (Digital VCO) но не с фиксированной частотой Master Clock а с частотой, кратной частоте генерации, для того, чтобы DAC в DCO использовал всю свою шкалу и разрядность, не пропускал шаги. Все это в рамках борьбы с потерей точности генерации, борьбы с алиасингом... Но это уже совсем другая история

Ссылки

1 Исходная версия этой статьи

https://mysku.club/blog/aliexpress/79168.html

2 Мой канал в TG "Советы программиста" https://t.me/ProProgs

3 eForth - язык Forth для микроконтроллеров

https://github.com/TG9541/stm8ef/wiki/STM8-eForth-Programming

4 Ссылки по моему синтезаторному проекту

https://github.com/UA3MQJ/fpga-synth/wiki

https://github.com/VitaSound/hdl-modules

https://soundcloud.com/vitasynth

http://www.youtube.com/channel/UCGi-A9KGhKhKzVT_baVw3HA

https://vk.com/vitasound

https://boosty.to/vitasound