Comments 20
P.S. Fungus: the Befunge CPU
точное попадание в ретро стиль
Еще бы цвет и цвет бордера. И вместо SD карты могло быть лучше использовать что-то вроде 25Q128.
Это оставляет около 150-200 байт на локальные переменные, чего может оказаться мало.
ZX имел в разы или в десятки раз большее количество оперативной памяти чем вся 328я атмега, получается что людям остается только 200 или 700 байт оперативной памяти, когда даже на сам экран нужно 508 байт. Звучит как очень мало.
С учетом того что вы пишете свой компилятор и процессор, можно подрубить к ардуине внешнюю оперативку и транслировать переменные программ в нее
И приделать к нему ножки, будет робот из "Звёздных войн"
Лучше взять за основу плату Wemos D1 с ESP8266 на борту. Будет вай фай встроенный. Плюс памяти у нее больше на борту др 4 мегабайтов. Клавиатуру можно взять от тв боксов и через блютус подключить ее. Да и экран лучше взять современный цветной. Там даже проводов будет меньше для работы, чем у нокиа экрана.
Тогда уж так https://habr.com/ru/post/412325/
Смотря какая цель :) я писал об этом, может быть в будущем, если уже точно ничего не выжать из данной платы будет, то можно перейти на что мощнее
Респект автору за энтузиазм, интересный проект, мне он напомнил программируемый калькулятор на ATtiny85, там похожим образом сделан интерпретатор байт-кода. Не было ли желания приблизить свой язык программирования к AVR-овскому ассемблеру, чтобы максимальное количество простых инструкций транслировались сразу в машинный код (а сложные - в вызовы функций)?
P.s. при всём уважении к 8-битным процессорам, сейчас рулят 32-битные, как справедливо заметили выше. За чуть большую цену можно собрать гораздо более производительный мини-компьютер на ESP или Blue pill...
А почему Вы применяете Arduino AtMega?
Ведь сейчас полно Arduin 32 разрядных с 32к и более на борту.
мы замечаем функцию, которая вызывается перед циклом задержки — yield, я мало чего про нее нашел, но, как я понял, это макрос, в который мы оборачиваем код и как-то можем параллельно его исполнять с основным кодом, если кто знает точно — поделитесь.
Можно считать, что это такая очень lite реализация кооперативной многозадачности. Внутри yield вызывается код из ядра arduino. Поддержка сети (если есть) например. Так то поток выполнения один (функция loop), и в нем по очереди выполняется то код, написанный вами, то служебный ардуиновский.
Это не ассемблер, это сисколы операционной системы, больше похоже на бэйсик, как раз в том же ZX была подобная организация, там даже арифметика вся была в системных вызовах (просто переход по адресу), ввиду отсутствия в процессоре умножения/деления/плавучки/тригонометрии. Ну а эмуляция RAM флешкой... Ну прям самый ленивый рецепт ленивых голубцов, какой я видел, на совершенно рандомных ограничениях - сюда только 3Д-очки прикрутить для максимального дисбаланса аппаратной конфигурации, ейбогу :3.
На счет ассемблера, тогда в x86 тоже нет ассемблера :) А если серьезно, то это называется микрокод - одна инструкция состоит из нескольких машинных инструкций, а не сисколы. Про x86 упомянул потому что сама по себе это CISC архитектура, но на самом деле у нее RISC ядро и микрокод для обратной совместимости. На счет флешки, что бы вы предложили? Пользовательские программы где то нужно хранить, самое оптимальное как по мне это как раз на флешке. Если добавим еще какие-нибудь устройства для временного хранения пользовательских программ, то:
1) больше памяти потратим на управление - ее не так уж и много изначально
2) больше пинов займем, их тоже не особо в избытке
Если у вас есть мысли по решению этих проблем, то я был бы рад, если бы вы ими поделились :)
Микрокод процессора и системные процедуры в RAM/ROM вообще не одно и то же. И ассемблер перпендикулярное им явление. И решать искусственные проблемы можно самым изощрённым способом, ваш тоже рабочий, очевидно. Моя несколько негативная оценка этого решения была чисто эстетической, никаких объективных критериев тут нет :3
Уважение автору за подобный проект! Просто поразительно, что среди современных студентов еще встречаются подобные энтузиасты. Оптимальные технические решения обязательно придут в процессе работы, главное - не забрасывать.
Флеш, определенно, будет слабым местом, интенсивные циклы перезаписи убьют память достаточно быстро, в будущем лучше изменить архитектуру.
Создаем современный ретро компьютер на Arduino