+516.99
Рейтинг
1433.86
Сила
  • avatar aa-dav
  • 1
Но из схемы выбивается последняя последовательность 0,1,2,3,4,5 — заключительная, следующая после 6-7-8.
Я не понял почему.
1 такт из 4 фаз работаем над 1 разрядом мантиссы X- пропуск 2 тактов из 4 фаз каждый — 1 такт из 4 фаз работаем над 2 разрядом мантиссы Х — и так далее. Как тут быть?
По сути это и есть мой вопрос из выше — как именно и что обрабатывается в каждом такте — почему Фролов утверждает что каждый разряд одного числа которое хранится вперемешку с двумя другими числами требует трёх микроинструкций при том что уже после первой в разрезе кольца оказывается разряд другого числа, а на следующем такте там опять будет разряд третьего числа. Тут я и не понял чем должны заниматься эти две микроинструкции и поэтому закралось подозрение что чего то не понимаю в общей схеме работы.
Однако снова подумаем — если каждая макроинструкция программы отрабатывает за 42 такта и за эти 42 такта кольцо проворачивается ровно 1 раз, то получается, что в начале следующей инструкции мы снова оказывается в начале X. Тогда следует логичный вроде бы вывод — что для того чтобы обработать два соседних числа в этой «нарезке слайсами», то значит микрооперации 0-1-2 и обрабатывают сразу три числа одновременно цифра-за-цифрой. Так что ли? Т.е. предполагается «последовательно-параллельная» обработка трёх чисел за раз?
Хмм…
Вот это и есть по сути мой вопрос.
  • avatar aa-dav
  • 1
Еще немного погуглил. Похоже что кастомизированные под конкретную игру чипы от Holtek имеют маркировку HT113xA, где x — это цифра или буква конкретной игры. Например тут: www.alldatasheet.com/view.jsp?sField=2&Searchword=HT11&list=65 еще более полный ряд таких чипов виден от Space War до Casino.
Но конкретно Brick Game там почему то нет, зато в другом месте я её нашёл и это литера «L»: www.datasheetarchive.com/pdf/download.php?id=41f9ee0128a8926ce590ad66f8cc9513bb98f2&type=P&term=brick%2520game
В «L» судя по всему прошивался тетрис как раз. И опять таки судя по маркировке ядром везде действительно служил HT-1130 просто уже прошитый чем нужно в конкретных A-шках.
  • avatar aa-dav
  • 1
Тоже буквально в этом году натыкался на эту тему на nesdev и натыкался еще вот на какую интересность: www.digchip.com/datasheets/parts/datasheet/196/HT1130.php

HT1132A Space War LCD Game
HT1134A Pin Ball LCD Game
HT1136A Football LCD Game
HT1137A Motorcycle LCD Game
HT113AA Streetfighters LCD Game
...

Например по первой ссылке: www.digchip.com/datasheets/parts/datasheet/196/HT1132A.php
The is a single chip Space War LCD Game designed by HOLTEK. This LCD Game has two modes (mode 1 and mode 2) of playing…
И в datasheet www.digchip.com/datasheets/parts/datasheet/196/HT1132A-pdf.php прямо показаны что там должно быть табло по типу «волк ловит яйца» с фиксированными LCD-элементами. Сам datasheet датируется 1998 годом, так что тут явно попахивает ориентацией компании Holtek на игровой рынок с поисками разных реализаций наладонных игр на базе какой то одной архитектуры 4-битного микроконтроллера (что действительно типично для калькуляторов и часов).
И вряд ли конечно только Holtek развивал эту нишу, так что наверняка есть альтернативные чипы.
  • avatar aa-dav
  • 1
Насчёт мантиссы я еще примешиваю сведения вот отсюда: vak.ru/doku.php/proj/calculator/b3-34
Здесь автор довольно резонную и звучащую крайне разумно в свете всего сказанного мысль говорит, что команда ИК13 разбита на 3 синхропрограммы именно потому что авторы девайса выработали жёсткую схему: первая синхропрограмма в первой фазе команды обрабатывает мантиссу, вторая синхропрограмма (вторая фаза) — экспоненту и, наконец, третья — некие доп-функции главная среди которых — условный переход. Звучит весьма разумно.
Почему первая фаза состоит не из 8 3-4-5? Тут мне кажется тоже всё логично — во первых нужно как то иначе обработать знак (0-1-2), далее обрабатываются 7 знаков экспоненты (3-4-5) и последний разряд по схеме создателей чем то выделяется, поэтому он перескакивает на (6-7-8). Повторюсь — звучит логично.
Мантисса так же состоит из трёх разрядов — знак и две цифры.
Опять видим, что знак во второй фазе соответствует 0-1-2, далее «срединные» 3-4-5 и опять особым образом почему то нужно последнюю цифру замкнуть 6-7-8. По крайней мере в этом усматривается схема, хотя знания того как перенос работает тут немного не вписывается — но возможно как раз потому что я не понимаю почему на каждый разряд отведено 3 микроинструкции, если мы знаем что такт разбит на микротакты и там 4 действия типа сложить разряд побитово уже как то вписано…
  • avatar aa-dav
  • 1
Еще вопрос хочется задать — после чтения вот тут: habr.com/ru/post/467501/
Складывается какая то противоречивая картинка. С одной стороны говорится, что каждая инструкция программы исполняется 42 такта по числу _тетрад_ в «кольцах».
С другой говорится что одна тетрада обрабатывается за 1 такт (микрокоманду).
Но с третьей стороны опять же утверждается, что в процессе исполнения инструкции для обработки той же мантиссы нужно по 3 повторяющихся микрокоманды в той же первой фазе команды:

Вот эти вот 3-4-5 вроде как обрабатывают одну цифру/тетраду мантиссы.
Чего то я тут явно недопонимаю, т.к. эти сведения имхо противоречивы.
  • avatar aa-dav
  • 0
P.S.
Похоже что Кристофер починил проблему.
  • avatar aa-dav
  • 0
Хм, у него последние дни на гитхабе какие то шевеления по багрепортам и видимо чего то в процессе отвалилось. Я там отрепорчу.
В архиве вроде есть релизы еще мартовские где файл есть: bintray.com/christopherpow/nesicide/download_file?file_path=nesicide-win-x86-34a7fa6.tar.bz2
  • avatar aa-dav
  • 1
Почитал побольше про ИК13xx и всё это дело — две статьи на хабре и прочих ресурсах.
Охренеть! xD Архитектура впечатлила. Интересно — прошивки уже полностью до последнего винтика расковыряли в плане осознания что в них происходит алгоритмически или всё еще там зияют чёрные дыры непоняток «почему оно работает?»?
  • avatar aa-dav
  • 0
С флагами открытия в F_OPEN прям какая то «бида». Крутил-вертел, но так и не смог заставить работать по документации из ссылки выше флаг
MODE_OPEN_CREAT = $08; Open existing or create new
Вот всё остальное работает:
Может открыть существующий файл и выдать ошибку если его нет.
Может создать файл если его нет или стереть его содержимое если он есть и открыть.
И даже может создать новый файл если такого еще нет, но выдать ошибку если он есть.
Но блин создать новый или открыть на запись старый (не стирая предыдущего содержимого) — нифига, даёт ошибку.
Хотя технически это можно реализовать двумя попытками открытия, но как то странно. Надеюсь детские болезни.
  • avatar aa-dav
  • 0
У меня есть просьба к зубрам уже хорошо соприкоснувшимся с ZX Spectrum Next проверить черновик моей обзорной статьи про архитектуру Next OS: gamedev.ru/flame/forum/?id=231961&page=17&m=5253430#m241 на предмет актуальности, неверных сведений и так далее. Надеюсь она и тут станет полезной в итоге.
  • avatar aa-dav
  • 0
Жаль. Было бы неплохо если бы это стало стандартом и в самом esxDOS. Как я понял документация по работе в «командной строке/бейсике» esxDOS сама говорит, что вместо имени текущего диска можно подставлять символ *, т.е. тут есть некая монолитность.
  • avatar aa-dav
  • 0
Откопал крайне любопытный документ по NextOS + esxDOS для Next: raw.githubusercontent.com/z88dk/techdocs/master/targets/zx-next/nextos/nextzxos_api.pdf
Например, в разделе про esxDOS там есть очень ценное замечание, что не обязательно всякий раз вызывать функцию GetSetDrv чтобы получить номер текущего диска когда нужно вызвать функцию которой нужно передать номер диска. Оказывается в аккумуляторе можно передать символьные значения:
A='*' для текущего диска и
A='$' для системного диска (где установлена NextOS или, видимо, сама esxDOS)
Так же там есть важное замечание, что к любым вызовам надо относится так, что они уничтожают AF,BC,DE,HL, но сохраняют все остальные регистры (например тот же IX).
В общем полезно почитать…
  • avatar aa-dav
  • 0
На 8 битах, имхо, оптимум — 256x192 точек как в спектруме. Ну во первых 256x256 это перебор с точки зрения стандартного соотношения сторон картинки 4:3. А 256x192 это как раз 4:3. Во вторых насколько я понял телевизионный сигнал что NTSC что PAL имеет предел эффективного разрешения по цвету в строке и потому о 640 например уже речи быть не может. Вроде бы предел это где то от ~400 что ли, но не скажу тут точно.

Однако действительно вопрос глубже — как «выдавить» при этом нормальную цветность.
Монохром как мы знаем в спектруме том же отнимает 6144 байта и раскраска знакоместами порождает клэшинг при попытке графонить графоний. Да и скроллинг в играх, а давайте уже не лукавить — игры это для нас очень важно — просто убивает и производительность и всё на свете — апдейтить 6Кб с приличным фпс — трудно для восьми бит.

Поэтому, имхо, оптимальность картинки в целом надо искать на пересечении текста и консольных принципов тайловой графики, причём одно плавно вытекает из другого, ибо не зря в Famicom/NES/Денди память тайлов офдоки называют CHR (character) ROM/RAM, ибо технически это действительно 256-значные символы квадратно-гнездовой сетки 8x8.
Однако Famicom, имхо, пример как немного перемудрили и ради призрачной экономии зарезали немало хорошего.
Главное — это аппаратный скроллинг по как минимум двум страницам видеотекста бесшовно перетекающий с прокрутной одна в другую.
Причём вот именно страницы текста имеют разрешение 32x32 символа, т.е. по вертикали виртуальное разрешение 256 пикселей, но оно используется чтобы организовывать бесшовный скроллинг с «проворотом» между границ.
Две экранных области текста пристыковани друг к другу слева-направо, над ними как бы «летает» видеоокно 256x192 на кинескоп управляемое одним 8-битным регистром прокрутки по вертикали и одним 9-битным регистром прокрутки по горизонтали (512 эффективных пикселей).
Но конечно чтобы игры на таком тексте делать еще нужны аппаратные спрайты.
В общем по лекалам денди я бы сделал так:
4Кб — память A изображений 256 тайлов 8x8 2bpp
4Кб — память B изображений 256 тайлов 8x8 2bpp
(одна область формирует тайлы для фона, другая — для спрайтов)
1Кб — текстовая видеостраница X 32x32 символа
1Кб — текстовая видеостраница Y 32x32 символа
(если произвольно скроллить, то видеостраницы пристыкованы прямоугольником «XY»)
256 байт — цветовые атрибуты видеостраницы X
256 байт — цветовые атрибуты видеостраницы Y
(2 бита на знакоместо/тайл выбирают ему палитру из 4-х возможных, в одном байте описывается 4 соседних символа/тайла квадратиком, что удобно для концепции метатайлов).
Но с таким потайловым и удобным для скроллинга фоном нужно конечно еще спрайты. Именно для них нужна память изображений Б ибо одной там реально маловато.
А чтобы всякие Elite делать нужно иметь второй видеорежим где первые 8Кб можно превратить в монохром, т.е. уже чистую графику.
  • avatar aa-dav
  • 1
P.S.
И еще по вашему процессору я не понял как делается CALL — LR вроде есть, но непонятно что в него записывать.
  • avatar aa-dav
  • 1
Стив Возняк неплохо это показал запихнув в 256 байт монитор для Apple-I
О! Спасибо за напоминание про плотность кода и виртуальный процессор Возняка — у меня ведь есть новый материал на эту тему. :)
  • avatar aa-dav
  • 1
Недавно были опубликованы исходники порта Doom на SNES созданного Рэнди Линденом считай что своими силами (id software вообще поначалу не была в курсе): gbx.ru/?showtopic=142214
По ссылке я новость написал с минимумом технических подробностей (но история сама, имхо, интересная), но сам же заинтересовался чипом SuperFX — это 16-битный процессор с архитектурой созданной под влиянием идей RISC который на 16-битной SNES позволял эффективно рисовать 3Д-графику — у ЦП SNES с этим есть ряд проблем. А у SuperFX прям как у Z80Next есть команда PutPixel и много прочего. Чип SuperFX впаивался в картридж SNES аки маппер в денди и рулил и педалил 3Д-графоний на 16 битах.

Думаю краткий обзор архитектуры SuperFX станет предметом моей следующей статьи, но тут распишу идею из него которая мне тоже понравилась и которую в таком виде нигде не видел.
Опкоды там как правило однобайтовые, но бывают префиксы.
Шестнадцать 16-битных регистров во многих инструкциях кодируются в четырёх битах как в статье: 0xAB, где A — код инструкции, а B — код регистра. Из этого правила есть немало исключений, но рассмотрим, например, операцию сложения:

ADD R5

В своей первичной форме она рассматривает R0 как аккумулятор и к нему прибавляет указанный в инструкции регистр R5. Т.е. берёт аккумулятор и R5, складывает их и результат записывает обратно в аккумулятор. Окей.
Однако можно временно на одну эффективную инструкцию сменить что будет являться приёмником операции — это делает инструкция TO:

TO R4
ADD R5

Здесь эффект будет таков, что сумма R0 и R5 будет записана в R4. После выполнения ADD приёмник по умолчанию опять станет R0.
Точно так же есть однобайтовая инструкция FROM которая так же меняет временно какой регистр будет служить первым операндом:

FROM R3
TO R4
ADD R5

Выполнит следующее: сумма R5 и R3 запишется в R4, а аккумулятор окажется вообще не при делах.
Для еще больше краткости есть однобайтовая же инструкция WITH которая сразу выставляет и FROM и TO в один и тот же указанный регистр.
Но и это еще не всё — WITH взводит еще один внутренний флаг который модифицирует поведение инструкций FROM и TO если они встречаются после неё. В SuperFX отсутствует специализированная команда MOVE, зато если после WITH сразу же идёт FROM, то происходит копирование из регистра указанного во FROM в регистре запомненном в WITH. И наоборот — инструкция TO скопирует из регистра запомненного по FROM в регистр указанный в себе.

FROM Rn ; код 0xBn - выставляет Sreg в n
TO Rn   ; код 0x1n - выставляет Dreg в n
WITH Rn ; код 0x2n - выставляет и Sreg и Dreg в n

Довольно забавная система команд — байтово-ориентированная, но постоянно на каких то полухаках, префиксах и сменах текущих целей и назначений.
Каждый боролся за плотность кода как мог. :)))
Ну если не лезть внутрь ЦП, то это вполне реальный путь и он всё-равно будет теоретически намного быстрее обычного калькулятора, т.к. процессору останется исполнить ну десяток-два максимум инструкций.
Но вообще надо аккуратно исследовать вопрос — ведь калькулятор это в сути своей пресолиднейший кусок ROM, т.к. он и есть все функции бейсика включая USR которая должна обратно вывалиться в режим процессора.
Калькулятор держит стек в памяти как и ряд переменных в basic vars позволяющих определить где он заканчивается. Поэтому технически можно было бы обставить это дело таким образом, что код в RST 28 каким то образом запускает процесс калькулятора как нечто внешнее (накормив тем же адресом откуда надо выполнять инструкции), а по сигналу завершения берёт HL из известных переменных бейсика как он в общем то и делает скорее всего в оригинале.
P.S. Да по названию и «hidden message» легко гуглится второй вариант тут: soranews24.com/2012/12/19/obscene-messages-from-developer-discovered-in-1980s-nes-game/
И надо сказать он во многих очень важных вещах отличается от данного, но проясняет некоторые моменты. Такое ощущение что переводчики с японского были сильны в разных предложениях.
А это сообщение есть на английском? :)
Не понял вопроса. Английские тексты по ссылке в посте можно прочитать.
Причём замечу, что основа моего перевода взята по ссылке, но некоторые обороты речи были настолько непонятными, что я нашёл еще один вариант перевода на второго сообщения и понял из него что имеется ввиду, но ссылку на него потерял в итоге. Хотя если искать наверняка вылезет опять в результатах поиска.