Ну если не лезть внутрь ЦП, то это вполне реальный путь и он всё-равно будет теоретически намного быстрее обычного калькулятора, т.к. процессору останется исполнить ну десяток-два максимум инструкций.
Но вообще надо аккуратно исследовать вопрос — ведь калькулятор это в сути своей пресолиднейший кусок ROM, т.к. он и есть все функции бейсика включая USR которая должна обратно вывалиться в режим процессора.
Калькулятор держит стек в памяти как и ряд переменных в basic vars позволяющих определить где он заканчивается. Поэтому технически можно было бы обставить это дело таким образом, что код в RST 28 каким то образом запускает процесс калькулятора как нечто внешнее (накормив тем же адресом откуда надо выполнять инструкции), а по сигналу завершения берёт HL из известных переменных бейсика как он в общем то и делает скорее всего в оригинале.
Не понял вопроса. Английские тексты по ссылке в посте можно прочитать.
Причём замечу, что основа моего перевода взята по ссылке, но некоторые обороты речи были настолько непонятными, что я нашёл еще один вариант перевода на второго сообщения и понял из него что имеется ввиду, но ссылку на него потерял в итоге. Хотя если искать наверняка вылезет опять в результатах поиска.
К слову о Си и 8-битных процессорах буквально на днях наткнулся на KickC: forums.nesdev.com/viewtopic.php?f=2&t=20187
Пытаясь максимально сохранять синтаксис Си компилятор просто возвращается к корням — ЭВМ из 60-х и не поддерживает рекурсию. И всё начинает работать гладко и шелковисто и компилироваться в бодрый и довольно рабочий код.
Тот же CC65 на следующем коде (очень для него неудачном):
Весьма впечатляющий результат, хотя видно что еще есть куда работать.
Отсутствие локальных переменных еще позволяет производить оптимизацию с размещением переменных и параметров в одном и том же месте если они не пересекаются в callstack. Тоже недоступная для Си вещь даже если шлёпать static.
Вот такой эффект от того что как в древнем Fortran когда не было там еще ключевого слова RESURSIVE.
То есть я о чём. Просто набор команд недостаточен, чтобы сказать, это хорошо и плохо. Нужно знать растактовки команд и смотреть как будут выглядеть решения стандартных задач. И только там станет понятно, где у нас улучшено, а где просто изменено.
Я крайне с этим согласен!
И скорее всего сейчас начну говорить жуткую банальщину, но как раз эта вот растактовка меня давно уже не удовлетворяет в том же Z80.
Взять ту же самую LDIR. Блочная инструкция, двухбайтовая, пересылающая сразу блоки байт, но как?
А так что на каждый пересылаемый полезный по «ПН (полезной нагрузке)» байт сопровождается двумя считываемыми байтами инструкции и скорее всего еще больше тактов по общему смыслу.
Не сомневаюсь что это всё поднималось ранее тысячи раз.
Потому что ну реально концепция general processor на каждый байт обрабатываемых полезно данных нагрузки реально чаще всего даёт +10 байт инструкций, опкодов и адресов. Который нужно считывать.
В итоге LDIR работает полукалечно: просто выполняет LDI и делает JR -2, чтобы снова считывать 2 байта инструкции чтобы переслать 1 байт полезных данных.
И это дико бесит перфекциониста типа меня и рождает DMA-контроллеры. Просто потому что general processors сосут. Откровенно.
Понятно что там еще с прерываниями надо разобраться и тому подобное. Не всегда уместно блочить шины DMA-контроллером надолго. Может и звук защёлкать и так далее.
Но я хотел сказать лишь то что наверняка уже тысячи раз говорилось: хотелось бы чтобы в general processor были по настоящему эффективные инструкции могущие не пересчитывать байты инструкции x2-3 байта из памяти каждый раз пересылая лишь 1 байт полезных байт нагрузки.
А LDIR настолько такой не является, что её реально попают пушами.
Аааа…
в последнее время подумываю, как расширить зетник для работы с регистровым файлом по типу 6502
В Sharp LR35902 в последние 256 байт памяти замапили четыре иструкции LDH (imm8), a / LDH a, (imm8) / LDH (c), a / LDH a, (c), но блин увы, там обратная совместимость серьёзно была подпорчена и потому эти инструкции заняли место других из i8080 и будучи однобайтовыми опкодом действительно были судя по всему штукой интересной. А чтобы не ломать совместимость с Z80 тут надо тоже вклиниваться в ED-коды и 2 байта на опкод уже сильно ущемляют полезность потому что ничем не лучше однобайтного LD A,(imm6).
В связи с этим вопрос — какие то пути преодоления проблемы просматриваются? :)
Чем больше размышляю над этой идеей тем больше нравится она мне. «Выпрямить» адресацию реально же можно просто анализом и перестановкой сигналов на шине адреса. Но с другой стороны у PIXELAD еще выполняются сдвиги, т.е. вычисляется уже готовый адрес по осмысленным готовым координатам в DE.
Я конечно согласен, что выглядит это FPGA-роскошество как изврат над самой идеей general processor, а сам слой ULA при наличии нормально скроллируемых тайлового слоя и 8bpp вообще непонятно зачем нужен кроме совместимости, но я всё-таки даже восхищаюсь этим непотребством, уже больно оно так сказать по мозолям топчется. :)
Очень интересно было бы почитать (я где то слышал что на профильных форумах обсуждение было) как движок работает.
Я в эмуляторе немного анализировал что в экранной области происходит — как понял основная идея, что пустые области попиксельно никак не обрабатываются, а скроллится только активное содержимое. Но всё равно интересно какие структуры и т.п.
Ибо действительно fps и отзывчивость фантастические для спектрума.
Нет. У меня сейчас на самом деле денди с маппером MMC3 голова забита если про хобби говорить. Про Next получилось просто что одна предыдущая статья была написана уже давно, а система команд ну очень уж немного и интересно, перевести так и просилось.
Бегло взглянул на zxnDMA сейчас — оно как я понял является даже усечением Z80 DMA и насколько я понял из упрощений только то что раньше количество итераций вбивалось как X+1 (и в режиме совместимости это сохранено), а сейчас можно как X передавать в новом режиме. А в остальном вроде всё такое же, но там уже куча битовых флагов и адресов и перевод уже дело нудненькое.
xD
Тут явно надо родить анекдот класса «стадии смирения»…
Наподобие такого:
Есть три стадии развития программиста на спектруме:
1. ты не понимаешь как раскладку видеопамяти ULA
2. ты понимаешь раскладку видеопамяти ULA
3. ты не понимаешь раскладки видеопамяти не как в ULA
А вот тут поподробнее бы (тем более что текст намекает что это планировалось).
Это что за покемон? Какая то недокументированная инструкция или они в Next сделали контроллер отлавливающий появление такой последовательности? Насколько я помню Z80 там оригинальный, не через FPGA, так что ему систему команд поменять не могли по идее…
В общем дошли руки скачать образ который создал Mr.Mouse/Xentax из ссылки выше и загрузить это дело в эмулятор Commodore 64:
И вот он результат:
Погуглив еще обнаружил, что адреса $0314-0315 куда процедура SETUP сохраняет адрес PROC это ничто иное как адрес процедуры обслуживания прерывания IRQ в Commodore Basic и поэтому в видео видно, что бейсик спокойно сосуществует с этой подпрограммой как с TSR.
Осталось только так и непонятым мною почему в листинге из игры используется некий оператор! и как он должен работать, но в реализации от Mr.Mouse он логично заменён на взятие нижней и верхней половины адреса < и >. Так же там все .dword заменены на .byte.
Возможно если бы не эти затуманившие мне мозг вещи я бы и сам смог докопаться до истины ранее. Так или иначе — пасхалка супер!
P.S.
Точно: csdb.dk/release/?id=182055
Это пасхалка в квадрате — тут и отсылка к терминатору и код на Commodore 64 воспроизводящий на двух нотах мелодию из Duke3D.
Вскрывается, что это как минимум фрагмент звукового драйвера на Commodore 64 воспроизводящий небольшой фрагмент по адресу DATA на звуковом чипе SID. Так JMP $EA31 это передача управления в KERNAL для штатной обработки прерывания от видеочипа (т.е. 60 раз в секунду), а $D4xx — это порты SID. Есть вероятность, что это суперскрытая пасхалка, т.к. мне лично гугл на «Ion Maiden hidden music Commodore 64» ничего не выдаёт осмысленного.
А существуют ли планы перевести это всё в текстовой вид?
Конечно ныне век ютубов и стримов, но техническая информация не в виде текста сильно теряет в эффективной познавательной ценности.
Круто! Вязь реально уронила челюсть. И с ней мои предварительные догадки в чём суть эффекта оказались неправильными — подумал, что используется маппер с CHR-RAM и рендеринг в реальном времени происходит с очень хитрым конечно же паттерном чтобы влезло в 256 тайлов. А тут атака по всем фронтам — и спрайты и HBlank, всё в ход пущено. :) Круто.
И еще вопрос возник — у какого эмулятора такой шикарный PPU Viewer?
Но вообще надо аккуратно исследовать вопрос — ведь калькулятор это в сути своей пресолиднейший кусок ROM, т.к. он и есть все функции бейсика включая USR которая должна обратно вывалиться в режим процессора.
И надо сказать он во многих очень важных вещах отличается от данного, но проясняет некоторые моменты. Такое ощущение что переводчики с японского были сильны в разных предложениях.
Причём замечу, что основа моего перевода взята по ссылке, но некоторые обороты речи были настолько непонятными, что я нашёл еще один вариант перевода на второго сообщения и понял из него что имеется ввиду, но ссылку на него потерял в итоге. Хотя если искать наверняка вылезет опять в результатах поиска.
Пытаясь максимально сохранять синтаксис Си компилятор просто возвращается к корням — ЭВМ из 60-х и не поддерживает рекурсию. И всё начинает работать гладко и шелковисто и компилироваться в бодрый и довольно рабочий код.
Тот же CC65 на следующем коде (очень для него неудачном):
Рожает следующий тихий ужас:
А вот KickC в своём асмосинтаксисе (как можно догадаться KickAssembler) делает почти оптимально:
Весьма впечатляющий результат, хотя видно что еще есть куда работать.
Отсутствие локальных переменных еще позволяет производить оптимизацию с размещением переменных и параметров в одном и том же месте если они не пересекаются в callstack. Тоже недоступная для Си вещь даже если шлёпать static.
Вот такой эффект от того что как в древнем Fortran когда не было там еще ключевого слова RESURSIVE.
Я крайне с этим согласен!
И скорее всего сейчас начну говорить жуткую банальщину, но как раз эта вот растактовка меня давно уже не удовлетворяет в том же Z80.
Взять ту же самую LDIR. Блочная инструкция, двухбайтовая, пересылающая сразу блоки байт, но как?
А так что на каждый пересылаемый полезный по «ПН (полезной нагрузке)» байт сопровождается двумя считываемыми байтами инструкции и скорее всего еще больше тактов по общему смыслу.
Не сомневаюсь что это всё поднималось ранее тысячи раз.
Потому что ну реально концепция general processor на каждый байт обрабатываемых полезно данных нагрузки реально чаще всего даёт +10 байт инструкций, опкодов и адресов. Который нужно считывать.
В итоге LDIR работает полукалечно: просто выполняет LDI и делает JR -2, чтобы снова считывать 2 байта инструкции чтобы переслать 1 байт полезных данных.
И это дико бесит перфекциониста типа меня и рождает DMA-контроллеры. Просто потому что general processors сосут. Откровенно.
Понятно что там еще с прерываниями надо разобраться и тому подобное. Не всегда уместно блочить шины DMA-контроллером надолго. Может и звук защёлкать и так далее.
Но я хотел сказать лишь то что наверняка уже тысячи раз говорилось: хотелось бы чтобы в general processor были по настоящему эффективные инструкции могущие не пересчитывать байты инструкции x2-3 байта из памяти каждый раз пересылая лишь 1 байт полезных байт нагрузки.
А LDIR настолько такой не является, что её реально попают пушами.
Аааа…
В связи с этим вопрос — какие то пути преодоления проблемы просматриваются? :)
Чем больше размышляю над этой идеей тем больше нравится она мне. «Выпрямить» адресацию реально же можно просто анализом и перестановкой сигналов на шине адреса. Но с другой стороны у PIXELAD еще выполняются сдвиги, т.е. вычисляется уже готовый адрес по осмысленным готовым координатам в DE.
Я конечно согласен, что выглядит это FPGA-роскошество как изврат над самой идеей general processor, а сам слой ULA при наличии нормально скроллируемых тайлового слоя и 8bpp вообще непонятно зачем нужен кроме совместимости, но я всё-таки даже восхищаюсь этим непотребством, уже больно оно так сказать по мозолям топчется. :)
Я в эмуляторе немного анализировал что в экранной области происходит — как понял основная идея, что пустые области попиксельно никак не обрабатываются, а скроллится только активное содержимое. Но всё равно интересно какие структуры и т.п.
Ибо действительно fps и отзывчивость фантастические для спектрума.
Бегло взглянул на zxnDMA сейчас — оно как я понял является даже усечением Z80 DMA и насколько я понял из упрощений только то что раньше количество итераций вбивалось как X+1 (и в режиме совместимости это сохранено), а сейчас можно как X передавать в новом режиме. А в остальном вроде всё такое же, но там уже куча битовых флагов и адресов и перевод уже дело нудненькое.
Тут явно надо родить анекдот класса «стадии смирения»…
Наподобие такого:
Есть три стадии развития программиста на спектруме:
1. ты не понимаешь как раскладку видеопамяти ULA
2. ты понимаешь раскладку видеопамяти ULA
3. ты не понимаешь раскладки видеопамяти не как в ULA
А вот тут поподробнее бы (тем более что текст намекает что это планировалось).
Это что за покемон? Какая то недокументированная инструкция или они в Next сделали контроллер отлавливающий появление такой последовательности? Насколько я помню Z80 там оригинальный, не через FPGA, так что ему систему команд поменять не могли по идее…
И вот он результат:
Погуглив еще обнаружил, что адреса $0314-0315 куда процедура SETUP сохраняет адрес PROC это ничто иное как адрес процедуры обслуживания прерывания IRQ в Commodore Basic и поэтому в видео видно, что бейсик спокойно сосуществует с этой подпрограммой как с TSR.
Осталось только так и непонятым мною почему в листинге из игры используется некий оператор! и как он должен работать, но в реализации от Mr.Mouse он логично заменён на взятие нижней и верхней половины адреса < и >. Так же там все .dword заменены на .byte.
Возможно если бы не эти затуманившие мне мозг вещи я бы и сам смог докопаться до истины ранее. Так или иначе — пасхалка супер!
Точно: csdb.dk/release/?id=182055
Это пасхалка в квадрате — тут и отсылка к терминатору и код на Commodore 64 воспроизводящий на двух нотах мелодию из Duke3D.
Конечно ныне век ютубов и стримов, но техническая информация не в виде текста сильно теряет в эффективной познавательной ценности.
И еще вопрос возник — у какого эмулятора такой шикарный PPU Viewer?