Чип NXH5104

[kotenok gav]

Dmitriy40 в сообщении #1462661 писал(а):

32КБ мало?! По сравнению с 16 байтами?!

По сравнению с 16 байтами - много. Но все равно мало.

Dmitriy40 в сообщении #1462661 писал(а):

А вот есть и 5В 1МБайт

Неплохо, кажется. Посмотрю....

-- 14 май 2020, 19:59 --

Да, хороший чип, кажется. Спасибо!

-- 14 май 2020, 20:02 --

Правда, расстояние между пинами малое...

[Dmitriy40]

Ну и ещё момент: можно конечно в любой калькулятор поставить 100Г память — но зачем?! Обычно сначала думают зачем нужна память, потом сколько её нужно, потом какие операции с ней необходимы (а какие можно сэмулировать) — и уж потом пытаются её подключить. Такой простой "процессор" просто не сможет обработать большой массив данных из огромной памяти (чисто учебную задачу сложить все числа из массива проигнорирую), потому ставить ему память более сотен (на самом деле даже единиц) килобайтов смысла нет. Обычно увеличение памяти сопровождается усложнением процессора, повышением его скорости вычислений, функциональных возможностей, написанием компиляторов для него (писать даже на асме, не говоря уж про машинные коды, программу в десятки КБ машинного кода это тоже уже практически подвиг).

-- 14.05.2020, 13:36 --

Да ну, жалкий TSOP44 с шагом 0.8мм. Под лупой (или без если зрение позволяет) и тонким жалом (0.4-0.6мм) вполне паяется. Или феном. Вы собирались паять вдвое меньший корпус ...

-- 14.05.2020, 13:43 --

Кстати для запайки можно поискать макетку такого типа только под 44 вывода и шаг 0.8мм:


-- 14.05.2020, 13:49 --

Ещё вариант, 32Мбита, 5В, 2Мх16, TSOP48.

-- 14.05.2020, 14:02 --

Кстати я ошибся, там не 8 фаз в каждом такте, а всего 5, уже терпимее. А значит обменяться байтом по SPI за одну команду точно не выйдет.

[EUgeneUS]

Dmitriy40 в сообщении #1462671 писал(а):

Да ну, жалкий TSOP44 с шагом 0.8мм. Под лупой (или без если зрение позволяет) и тонким жалом (0.4-0.6мм) вполне паяется.

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

[Dmitriy40]

EUgeneUS
Ну, я не пайщик, у меня почти никогда так не получается. Потом эти сопли удалять на порядок труднее чем сразу запаять иголкой по ножкам.

Ради интереса сваял программулю расчёта чисел Фибоначчи для этого "компьютера", удалось обойтись 8-ю типами более-менее универсальных команд, программа влезла в память с трудом:

Начальное состояние:
        R15=N - счётчик чисел
        R14=1 - текущее число
        R13=0 - предыдущее число

Программа:
res:                    ;количество разных команд
        movAR   A,R15   ;1
calc:
        movRA   R15,A   ;2
        movAR   A,R13
        movBR   B,R14   ;3
        movRB   R13,B   ;4
        addR    R14     ;5
        out     R14     ;6
        movAR   A,R15
        ldiB    B,1     ;7
        djnzA   calc    ;8      A=A-B, переход если не обнулилось
        hlt             ;9?

[EUgeneUS]

Dmitriy40 в сообщении #1462696 писал(а):

djnzA calc ;8 A=A-B, переход если не обнулилось

А у этой штуки нет команды условного перехода

Dmitriy40 в сообщении #1462696 писал(а):

Ну, я не пайщик, у меня почти никогда так не получается.

Флюс нужен хороший, с наклоном платы и жала паяльника поиграть, чтобы излишек припоя затекал на жало.

[Dmitriy40]

EUgeneUS в сообщении #1462700 писал(а):

Dmitriy40 в сообщении #1462696 писал(а):

djnzA calc ;8 A=A-B, переход если не обнулилось

А у этой штуки нет команды условного перехода

Не мои проблемы: флаги из АЛУ в control unit заведены, микрокод имеет возможность выполнить разные действия в зависимости от состояния флагов.
Можно даже чуть упростить программу:

Программа:
res:                    ;количество разных команд
calc:
        movAR   A,R13   ;1
        movBR   B,R14   ;2
        movRB   R13,B   ;3
        addR    R14     ;4      R=A+B
        out     R14     ;5
        ldiB    B,1     ;6
        movAR   A,R15
        subR    R15     ;7      R=A-B
        jnz     calc    ;8
        hlt             ;9?

-- 14.05.2020, 16:19 --

Пересылка счётчика команд по шине данных для получения команды из памяти, на что тратится одна фаза из пяти, отдельно доставляет ... Сэкономили четырёхпроводный шлейф и один мультиплексор, но затратили целую фазу на это, да ещё и MAR портится, что уж ни в какие ворота и портит много возможностей! Да и вообще объединённая шина данных с адресами не слишком удобна.

-- 14.05.2020, 16:43 --

kotenok gav
62256 можно подключить адресом к регистрам A,B, а данные на шину данных. Останется найти два сигнала управления и добавить два кода команд: чтение байта в регистр по адресу из A,B и запись байта из регистра по адресу из A,B. И всё, память до 64КБ "встроена" (зачем — по прежнему непонятно).
Добавив третий регистр и сигналы управления им и команды его загрузки/выгрузки, можно подключить и до 16МБ памяти.

[Dmitriy40]

Что я бы сделал с этим недокомпьютером (в произвольном порядке):
1. Разделил бы шину адреса команд, пустил её со счётчика команд напрямую (через мультиплексор) в ОЗУ. Можно исключить первую фазу тактового цикла. И реже портить MAR.
2. Не знаю зачем им два аккумулятора (А и В), я бы добавил мультиплесоры их обхода, чтобы можно было подать байт из ОЗУ (регистров) прямо на входы АЛУ: проверить на ноль, на отрицательность, уменьшить/увеличить счётчики.
3. Может быть отдельный физический регистр-счётчик повторов циклов, хотя бы один внутренний цикл будет быстрее и меньше портить буферов/регистров.
4. Дополнительные операции в АЛУ. Хотя бы логику и может быть сдвиги (без них тяжело делать много полезных вещей, тот же программный I2C/SPI). Сейчас я не представляю как в ячейку ОЗУ (которое по совместительству регистры) загрузить произвольное число по модулю более примерно полусотни (трёх команд сложения/вычитания с константой). Ну как?!
5. Изменить подключение старших битов при чтении регистра команд чтобы можно было задавать не только положительные, но и отрицательные константы.
6. Добавить входной регистр, подключенный прямо к уже имеющимся переключателям ввода кода программы. Фактически лишь переключить их на шину данных через 74245. Можно будет общаться с пользователем.
7. ПЗУ микрокода заменить на ОЗУ, добавить мелкое ПЗУ и сделать на нём микропрограмму загрузки основного микрокода и даже основного ОЗУ из внешнего источника. Конечно ради 16 памяти команд заморачиваться не стоит, но ради уже 1К кода стоит.
8. Увеличить разрядность счётчика команд, адресной шины, объёма основного ОЗУ.
oo-1. Добавить портов, выходных, входных, последовательных, ЦАП, АЦП.
oo. Ну и запустить всю эту махарайку МГц так на 4-5, т.е. на 1млн команд в секунду. Только аккуратно посчитать все задержки и гонки (что само по себе увлекательнейшее занятие). Получится практически PIC по возможностям, только размером со стол.
Не всё из вышеперечисленного разумно, наверняка логичнее будет перепроектировать заново, придерживаясь каких-то зафиксированных принципов (разумный минимализм, разделение шин и потоков данных, укорачивание тактового интервала, упрощение и универсализация команд). Или даже повторить какую-нибудь известную архитектуру, PIC или 6502 или ещё что.

[kotenok gav]

Dmitriy40 в сообщении #1462774 писал(а):

И реже портить MAR.

А как оно портится?

Dmitriy40 в сообщении #1462774 писал(а):

два аккумулятора (А и В)

Это регистры.

Dmitriy40 в сообщении #1462774 писал(а):

7. ПЗУ микрокода заменить на ОЗУ, добавить мелкое ПЗУ и сделать на нём микропрограмму загрузки основного микрокода и даже основного ОЗУ из внешнего источника. Конечно ради 16 памяти команд заморачиваться не стоит, но ради уже 1К кода стоит.

Тут вы немного не поняли. Код сам пишется в виде команд-инструкций, которые управляют микрокодом в виде уже сделанного там EEPROM. Для загрузки кода, вместо сделанного RAM, я хочу как раз приделать "жесткий диск" в виде EEPROMов.

Dmitriy40 в сообщении #1462774 писал(а):

8. Увеличить разрядность счётчика команд, адресной шины, объёма основного ОЗУ.

Это я и так хотел сделать.

Dmitriy40 в сообщении #1462774 писал(а):

Ну и запустить всю эту махарайку МГц так на 4-5, т.е. на 1млн команд в секунду.

Это я тоже и так хотел сделать (ну, наверное, не на столько, надо будет посмотреть, сколько там из резисторов и конденсаторов может получиться).

С остальным согласен, хорошие идеи, попробую сделать.

[Dmitriy40]

kotenok gav в сообщении #1462779 писал(а):

Dmitriy40 в сообщении #1462774 писал(а):

И реже портить MAR.

А как оно портится?

А как иначе (в обход него) подать адрес команды из счётчика команд на вход адреса ОЗУ?
Насколько я понял, там в первой фазе всегда происходит передача адреса команды из счётчика команд в MAR, во второй фазе читается код команды в IR, и лишь с третьей фазы может что-то выполняться.
Хотя я по видимому уже придираюсь, что-то не выходит у меня ничего особо полезного без порчи MAR, что портится он, что не портится, разница малозаметна. Кроме одной фазы каждого такта конечно.

kotenok gav в сообщении #1462779 писал(а):

Dmitriy40 в сообщении #1462774 писал(а):

два аккумулятора (А и В)

Это регистры.

На мой взгляд это довольно бесполезные регистры, они (чтение из них) полезны лишь для пересылок, но любая операция АЛУ портит (использует) их оба. Даже когда операнд непосредственный, в коде команды, подать его в АЛУ в обход регистров невозможно. Даже ни счётчик на одном из них не сделать, ни операции R=АЛУ(R,A) не выполнить без порчи B, ни проверить регистр на ноль без порчи сразу обоих А и В.
Вон в PIC вообще один аккумулятор и ничего, все команды одноадресные (как и здесь) и однако всё нормально работает. А тут добавили второй аккумулятор, но криво, фактически что есть он, что нет его, разницы никакой (другое дело что он необходим для работы АЛУ, но тогда делать из него чтение уже совсем бред).

kotenok gav в сообщении #1462779 писал(а):

сколько там из резисторов и конденсаторов может получиться

А при чём тут они? Дело в задержках микросхем.

-- 14.05.2020, 21:08 --

А, кстати, забыл добавить ещё один важный пункт:
oo-2. Добавить аппаратный регистр указателя стека и команды работы с подпрограммами. Без них код писать очень уж тяжко. И занимает он просто ужас сколько места. Которого и так мало.

[kotenok gav]

Dmitriy40 в сообщении #1462786 писал(а):

А как иначе (в обход него) подать адрес команды из счётчика команд на вход адреса ОЗУ?

А, понял. Это решается тем, что все команды будут на "жестком диске", а в RAM только данные.

Dmitriy40 в сообщении #1462786 писал(а):

А при чём тут они? Дело в задержках микросхем.

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

Dmitriy40 в сообщении #1462786 писал(а):

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

Это будет посложнее, мб сделаю.

Dmitriy40 в сообщении #1462786 писал(а):

И занимает он просто ужас сколько места. Которого и так мало.

Ну так будет много места - (частично) не будет проблемы)

[Dmitriy40]

kotenok gav в сообщении #1462796 писал(а):

Dmitriy40 в сообщении #1462786 писал(а):

А при чём тут они? Дело в задержках микросхем.

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

А выбирается она по критериям надёжности работы всех узлов. И только потом считаются номиналы RC цепочек в генераторе. Намёк: если поставите RC на частоту 1ГГц, то работать оно гарантированно не будет, даже если такая частота и появится в проводе CLK. Потому для каждой из 5-ти фаз определяется самый долгий (с учётом времён предустановок уровней) путь распространения сигнала в самом наихудшем случае (со всеми допусками на разброс номиналов и температуру), делается запас процентов 20 (например на шинные эффекты) и частота устанавливается не выше полученной. Для LS серии и такой сложности схемы это прикидочно единицы МГц, может и меньше.

kotenok gav в сообщении #1462796 писал(а):

Dmitriy40 в сообщении #1462786 писал(а):

И занимает он просто ужас сколько места. Которого и так мало.

Ну так будет много места - (частично) не будет проблемы)

Ну и привыкнете к плохому (писать линейный код методом copy-paste вместо иерархического). Фактически это привычка делать лишнюю работу и плодить ошибки вместо качественного кода и технологий его написания. Так и от циклов можно отказаться, всегда же можно их развернуть в линейный код ... Привыкать лучше к хорошему ...

-- 14.05.2020, 21:59 --

kotenok gav в сообщении #1462796 писал(а):

Это решается тем, что все команды будут на "жестком диске", а в RAM только данные.

Это называется Гарвардская архитектура. И у неё есть недостатки, иногда существенные.

[kotenok gav]

Dmitriy40 в сообщении #1462803 писал(а):

Ну и привыкнете к плохому (писать линейный код методом copy-paste вместо иерархического). Фактически это привычка делать лишнюю работу и плодить ошибки вместо качественного кода и технологий его написания. Так и от циклов можно отказаться, всегда же можно их развернуть в линейный код ... Привыкать лучше к хорошему ...

Ну, вообще можно делать такие "псевдо-функции":

0: данные
1: данные
2: данные
3: что-то делает функция с 0 и 1
...
4: что-то делает функция и записывает ответ в 2
5: записываем что-нибудь в 0
6: записываем что-нибудь в 1
7: вызываем функцию

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

Dmitriy40 в сообщении #1462803 писал(а):

И у неё есть недостатки, иногда существенные.

Какие?

[Dmitriy40]

Можно конечно сварганить псевдофункции с указанием им каждый раз руками адреса куда потом вернуть управление, но это костыли и трата дефицитного регистра.

Из недостатков:
1. Приходится дважды-четырежды дублировать очень многие функции, получающие в аргументах массивы/строки, ведь они могут лежать как в RAM, так и в ROM и команды доступа к ним разные.
2. Приходится каждый раз помнить где лежит переменная (массив, строка) и если вдруг понадобилось сменить ей месторасположение, то моментально глобальное исправление кода.
3. И самое противное что не всегда расположение массивов/строк известно на момент компиляции, бывает оно вычисляется уже в runtime, и тогда с ними работать это мрак.
4. Невозможно организовать своп кусков кода из внешней памяти.
5. Приходится иметь отдельные команды для чтения ROM, со всем богатством адресации, это усложняет устройство управления и расходует пространство кодов операций.
В принципе всё это решаемо, так или иначе, но ... Когда приходится вместо одной большой atof() делать их две практически одинаковых с разным только типом аргумента (flash и ram), приводящему к отличию буквально в паре команд глубоко внутри циклов, это раздражает. А strcmp() надо уже 4 варианта ... Или делать отображение (части) одной памяти в другую, фактически нивелируя преимущества раздельной архитектуры.

[kotenok gav]

Я вот тут подумал... Дублирование же наоборот, будет, если будет возможность читать/писать данные и в RAM, и на HDD (еще я понял, что идеальное разделение данных и команд невзможно - в коде всегда бывают какие-нибудь константы)? Как решается эта проблема в обычных компьютерах?

[Sender]

Dmitriy40 в сообщении #1462873 писал(а):

3. И самое противное что не всегда расположение массивов/строк известно на момент компиляции, бывает оно вычисляется уже в runtime, и тогда с ними работать это мрак.

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