nedoPC.org

Shaos не раз говорил, что 1-битные процессоры есть, но мне казалось,
что были они давно и это уже почти неправда...
Оказалось, что не так уж и давно, и живьём они ещё есть!
Вот интересный пример:

MC14500 1 bit CPU от Motorola




Вдвойне интересно, что и компьютеры на основе MC-14500 были, пусть и
тренировочные!

WDR-1-Bit-Computer



Интересно, как батареечка типа "Кроны" столько светодиодов тащщит!...

Удалось поместить MC14500 в GAL!

А вот это очень интересно!
А то был у нас тут человечек, утверждал, что в GAL под Proteus ничего путного сделать нельзя...

А вы не могли бы развернуть здесь проект с подробностями?
А то я собирался поэкспериментировать с ПЛМ под Proteus, но как-то руки так и не дошли...
Был бы благодарен за понятный и интересный пример.

Proteus был выбран для отладки только потому, что я не подружился с имеющими симуляторы PALASM и WinCUPL, а в железе пока прошивать нечем.
Прошивка (файл .pal) написана для GALASM, который генерирует в том числе файл .jed.
Файл .jed указывается в свойствах компонента в Proteus по аналогии с прошивкой микроконтроллера.

В файле .pal я придерживался такого формата выражения для каждой конъюнкции: сначала код инструкции, при котором нужно установить (для RRR в контексте RR - сбросить) выход, а потом условия установа. "Регистры" организованы как выражения, принимающие своё предыдущее значение, если текущая инструкция не изменяет их содержимое (не команда их изменения), и принимающие новое значение иначе. "Регистр" Result Register (RR) представляет функционал [A]LU, в одну "переменную" не поместился, пришлось вводить RRR, который ещё и инвертирован для де Моргана.

Имея перед глазами список инструкций MC14500 из handbook и диаграммы на следующих страницах с оговорками из README, вроде как остальное в .pal файле становится понятно. Упустил ли я что-то важное?

На взгляд, вроде как не упустили... попробую повторить ваш проект, если возникнут вопросы - спрошу здесь.

У меня, честно говоря, было вот какое сомнение: GAL поддерживают элементы с обратными связями типа триггера?

Т. к. ATF16V8 по функционалу - полный аналог GAL16V8, то datasheet ATF16V8 понятно описывает возможности их обоих.

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

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

Кстати, почему-то в Proteus'е вывод /OE работает не так, как я ожидал — в проекте на скрине выше выводы с триггером переходят в третье состояние при 0В на этом выводе, хотя, казалось бы, должно было быть наоборот...

Это одна из фичь, или из разряда и так сойдет.

Гал-ки прикольная (полезная) штука. Отличный пример. Всякие мелко контроллеры на них лепить, при условии, что четко понимаешь чего хочешь.

Нашёл баг, связанный с FSKP: когда я только начинал писать .pal, этот сигнал сначала устанавливался только по инструкции SKP при RR = 0, потом я с лёгкой руки добавил выставление этого сигнала по RTN, но забыл про RR, в результате при некоторых инструкциях, следующих сразу за RTN и по идее не выполняющихся, установленный RR сбрасывался.

Уже исправил в последнем коммите. Предлагаю потестить на подобные вещи.

+ Вспомнил-таки про прошивальщик GAL на Arduino, буду делать.

Тесть это в тему влиться. Но круто, баги ловить в незамысловатой прошивке ГАЛ.

p.s. Вот тут проще купить MiniPro, не отвлекаться и дальше по теме творить.

Хорошая новость: я собрал afterburner и успешно прошил им ATF16V8B.
Но спешу сообщить не очень хорошую новость: в RRR была ошибка, вместо каждой "/I2" должно было стоять просто "I2" - дело в том, что я сначала убрал избыточные повторения "/I3 + I2" в RRR, но потом решил вернуть, скопипастил не то и плохо проверил, извиняюсь. Уже отправил коммит.

Это я уже третий вариант скачиваю... хорошо, что не тороплюсь...
Так, глядишь, пока суть да дело и все баги отыщутся...
У меня просто нет Протеуса пока - на чистую Венду_7 всякий нужный софт ставлю.

P.S. А что такое "коммит", кстати?

Окей, просто думал, что из-за меня самую интересную часть исходника было не понять, поэтому тишина
Кстати, я вот думаю, всё-таки не нужно расписывать выражения в исходнике (файл .pal), или мне одному там всё понятно?
Короче говоря, коммит в этом контексте - патч. Образованными патчами версиями проекта можно управлять через систему контроля версий git. На странице github проекта обычно скачивается ветка main, в которой все патчи применены до последнего.

Решил, что просто проц - это скучно, сделал к нему некоторую периферию на тех же 16V8:

IO - однобитные 3 входа и 4 выхода (выходы можно прочитать как ещё 4 входа), логика для генератора/тактирующего устройства (инвертор и неинвертор одного и того же входа). Пока не проверил.

ROMCTL - на эту штуку ушло уйма времени, она генерирует стартовый сигнал для I2C EEPROM (часть картинки сверху) и в бесконечном цикле тащит с неё данные (снизу) начиная с самого последнего байта EEPROM, продолжая нулевым, первым, вторым, третьим и т. д., при том вывод данных EEPROM должен быть подключен через диод, тактируемые фронтом HOLD данные поступают в какой-нибудь регистр сдвига типа 74HC164, GAL14500 должен тактироваться от MSB счётчика, то есть при переходе 0 -> 8.

Уже проверил в железе с 24C08 - работает !
Исходники и jedы в репе. Вот где диаграммы делал.

Скоро, возможно, сделаю что-нибудь интересное.

Обнаружил у Proteus ещё один недочёт с 16V8 - при подаче питания выводы с регистрами должны быть установлены в 5В, но у меня было что-то другое.

А вы не пробовали поэкспериментировать с большими PLD под Proteus?

Фотка кристалла, на всякий случай:
https://siliconpr0n.org/map/motorola/mc14500/mz_mit20x/