Просмотр полной версии : Программирование на ассемблере
Хочу как-то более реалистично закруглить тему про сферические сопроцессоры в вакууме. Предметно-ориентированные ускорители - замечательная штука, но их надо реализовать в плисе, реализовать в эмуляторе, написать/адаптировать под них программы. Теоретически все это возможно, но верится с трудом. Есть вариант проще - свести к минимуму тормоза 8080 в векторе. Все циклы >4 тактов поджать до 4. Ну и сделать эту возможность программно включаемой/отключаемой, чтобы общение с магнитофоном и демы не страдали. Ускорение ориентировочно до 15-20%.
На гит-*-абе можно делать проекты где много участников, но все равно многим не нравится формат и все это кажется пугающе сложным. И я, хоть и пользуюсь всей этой хренью на протяжении десятилетий, полностью с ними согласен.
Мне больше нравится формат вики.
Я только за. Вики наверное формат более понятный для большинства потенциальных контрибуторов. Главное, чтобы был энтузиазм все это добавлять и поддерживать. А наводить красоту можно потом и постепенно.
моя проблема с вики только в том, что очень часто до наведения красоты дело не доходит и в конце концов все остается даже без оглавления и вся инфа оказывается закопанной где-то в непонятных недрах. Потом ты с чем-то таким эзотерическим начинаешь разбираться. Задаешь вопрос. Все отмахиваются -- ну там вики есть, там все написано. На вики находится случайным образом 2-3 противоречащих друг другу версии, ни одна из которых не соответствует тому, что ты видишь своими глазами. На форуме куча вопросов, ответы -- "ну там вики есть, надо нормально поискать". Такой современный вариант "все работает, надо только нормально настроить". Основной тезис -- вики без дисциплины обречена быть помойкой. Но на мое брюжжание обращать внимание не стоит. В любом случае собранная воедино информация лучше форума, где вообще найти ничего невозможно.
- - - Добавлено - - -
Хочу как-то более реалистично закруглить тему про сферические сопроцессоры в вакууме. Предметно-ориентированные ускорители - замечательная штука, но их надо реализовать в плисе, реализовать в эмуляторе, написать/адаптировать под них программы. Теоретически все это возможно, но верится с трудом. Есть вариант проще - свести к минимуму тормоза 8080 в векторе. Все циклы >4 тактов поджать до 4. Ну и сделать эту возможность программно включаемой/отключаемой, чтобы общение с магнитофоном и демы не страдали. Ускорение ориентировочно до 15-20%.
Тут я выступлю с контрзанудством о том, что скорость собственно только для демок и игр и нужна и только в них и ценится. И ценится именно в контексте историческом, без радикальных изменений. Для чего нужно разгонять Вектор сейчас? Чтобы быстрее сортировать свою мощную базу данных, или чтобы заниматься обработкой больших текстовых документов, или графику готовить для публикаций? Может быть чтобы сервер на Векторе обрабатывал больше запросов из интернета? Это не злой сарказм, а такой, вычислительный.
Сферический сопроцессор в вакууме мне кажется имеет потенциал такой же, как дополнительные чипы в картриджах у NES и SNES. Если кто-то сделает игру для Вектора на картридже, а на картридже будет свой акселератор, это по-моему очень круто. Надо начинать от игры, а не от абстрактного акселератора. Объем задачи уже не для одиночки, даже у молодого и энергичного столько времени физически нет. А выхлопом даже при самом успешном исходе смогут насладиться буквально единицы.
ivagor, пожалуйста, перестаньте использовать жаргонные дурные словечки вроде "рыба".
скорость собственно только для демок и игр и нужна и только в них и ценится
Ну так игры будут быстрее, я только демки вычеркнул.
Для чего нужно разгонять Вектор сейчас?
Лично мне для рейкастера и 3d крутилки любое увеличение быстродействия будет приятно. Не говоря уже о маргинальных проектах с эмуляцией других компов, но там 20% не спасают.
ivagor, пожалуйста, перестаньте использовать жаргонные дурные словечки вроде "рыба".
Степень дурости жаргонных словечек субъективна, на мой взгляд таких не использую. Главное, что не нарушаю правил форума.
Отдельно интересно, как "рыба" попала в дурные и где я последний раз использовал это слово на форуме?
- - - Добавлено - - -
Про демки уточню. Там где есть привязка к развертке или биперная музыка (что уж совсем редкость), там надо старые растактовки. А где такты не должны совпадать, можно включить и повышенную скорость. Вспомнил, что смотрел арзака в конфигах 6128 и z80. Там за счет более быстрых mov r,r/ inr/ dcr ну и некоторых других команд практически побеждался тиринг, т.ч. и некоторые демки можно и нужно ускорять разгоном проца.
Про демки уточню. Там где есть привязка к развертке или биперная музыка (что уж совсем редкость), там надо старые растактовки. А где такты не должны совпадать, можно включить и повышенную скорость. Вспомнил, что смотрел арзака в конфигах 6128 и z80. Там за счет более быстрых mov r,r/ inr/ dcr ну и некоторых других команд практически побеждался тиринг, т.ч. и некоторые демки можно и нужно ускорять разгоном проца.
Понимаю. Тут можно случайно спуститься в бесконечный спор за то, что же такое настоящая демосцена и все такое, так что я не буду. Отталкиваясь от своего довольно бедного опыта демосценерства, что-то для Вектора и так может быть непросто протолкнуть просто потому, что это малоизвестная платформа и никто не понимает, что с этим делать и по какой мерке судить. Отсюда возможны ветвления -- вариант 1) поскольку платформу все равно никто не понимает, всем все равно, модифицированная она или нет; 2) всем и так не понятно, это уже практически Wild (то есть категория демо на утюге итд) а тут еще и модифицированная.
То есть я рад конечно, что Арзак меньше рвется с z80, но вся тема-то была сделать его такого огромного именно на 8080. С чисто технической точки зрения на тех, кто знает Вектор (на троих-четырех человек в мире), он произвел какое-то минимальное впечатление. А если бы я сделал его же для Вектора с z80, или тем более со сферическим акселератором на ПЛИС, это уже было бы из категории "ну конееееечно....".
Есть вероятность, что Арзака можно чуть улучшить (текущий вариант мне нравится, но если было бы еще круче, то почему бы и нет) в рамках стандартного 06Ц с 8080. Сместить картинку и частично оптимизировать вывод, сколько-то места для изощренных выводилок там есть. А проба с более быстрыми процами как раз указывает пути совершенствования.
ivagor, я всячески приветствую улучшение и развитие, да хоть римейки, сиквелы и даже приквелы. И не буду напрягаться, если они будут на чем-то нестандартном. Все, что я сказал выше -- это мое личное отношение именно сейчас и только к тому, что я сам делаю. И оно тоже все время меняется, это не так что за всю жизнь сказал. То есть пожалуйста не надо думать, что я презираю Вектор с z80 и гипотетическим акселем.
...
Лично мне для рейкастера и 3d крутилки любое увеличение быстродействия будет приятно.
...
Если думать о 3d, то там и дополнительная быстрая математика, скорее всего, была-бы не лишней.
Контроллер прямого доступа к памяти, "это не наш метод"... без грандиозной доработки железа не обойтись... т.к. внешнее торможение процессора не предусмотрено (HOLD вход усажен на землю) нужно будет дороги резать... с прерываниями разбираться...
Не. Простая замена процессора в панели, выглядит более привлекательно. И при этом оставить полную совместимость со штатным 8080.
Если имеет место быть Вектор с Z80 и ВМ1, то почему не может быть Вектор ещё и с 8080++ ;)
Если думать о 3d, то там и дополнительная быстрая математика, скорее всего, была-бы не лишней.
Да, в первую очередь быстрое умножение, ну и деление. Хотя можно помечтать о векторном (иронично!) сопроцессоре, но не буду опять слишком отрываться от земли.
т.к. внешнее торможение процессора не предусмотрено (HOLD вход усажен на землю) нужно будет дороги резать
Для внутрипроцессорного контроллера DMA ничего дополнительно снаружи резать не надо (в частности HOLD трогать не надо), это фактически встроенный сопроцессор. Другое дело, что при грамотной реализации работы такого внутреннего контроллера нужно проявить аккуратность. По хорошему после завершения единичной транзакции, завершающейся записью в озу вектора, надо проверять запрос прерывания и обрабатывать, если есть. А после возвращения из обработчика продолжать. Основная сложность тут - все учесть и сделать правильно, я бы не стал выбирать такую штуку на начальном этапе обучения.
ivagor, если мы всё ещё о скорости графики говорим в контексте "сделать из Вектор-06Ц фэнтезийный девайс", то можно же в другую сторону пойти:
внешний мощный графический чип, чтобы процессор от графики сильно разгрузить.
Видеосигнал можно объединять с родным от Вектора, тем самым сохранив полную совместимость.
Где-то здесь на форуме были энтузиасты, прикручивали подобное к Спектруму.
Если думать о 3d, то там и дополнительная быстрая математика, скорее всего, была-бы не лишней.
часто применяют (заранее просчитанные) таблицы
можно же в другую сторону пойти:
внешний мощный графический чип, чтобы процессор от графики сильно разгрузить.
Желание апгрейдить 8080 есть у KTSerga, желающих подключить к вектору что-то вроде V9990 (хотя лучше 9958) я не наблюдаю.
внешний мощный графический чип, чтобы процессор от графики сильно разгрузить.
Видеосигнал можно объединять с родным от Вектора
Либо так, либо подумать в сторону амиговского copper'а, который пишет в штатную видеопамять, но умеет очень быстро делать ряд операций, разгружая ЦП. А уж если совсем помечтать, то объединить этот условный copper с аппаратным спрайтовым или спрайтово-тайловым движком. Не уверен, нужно ли при этом объединять аналоговый видеосигнал, т.к. в той же NES, вроде как, сделано гораздо проще - если в определённой точке экрана есть пиксель спрайта, то рисуется он, а если нет (или он прозрачный) - то рисуется пиксель фона, в качестве которого на "Векторе" ИМХО и логично использовать штатные видеопамять и видеоконтроллер.
Таким образом, copper дал бы возможность аппаратного ускорения графических эффектов, которые не "натянешь" на спрайтово-тайловые движки. И, с другой стороны, не было бы типичного для игровых приставок ограничения, когда графика обязательно должна быть "втиснута в прокрустово ложе" спрайтово-тайловой парадигмы (в этом плане интересно почитать про боль портирования Another World на Sega)
Желание апгрейдить 8080 есть у KTSerga, желающих подключить к вектору что-то вроде V9990 (хотя лучше 9958) я не наблюдаю.
Пусть не к "Вектору", а к "Ориону" 9958 успешно подключён (https://disk.yandex.ru/i/ttSP2PRCLGQL4w). Ещё видео с заполнением текстового экрана. (https://disk.yandex.ru/i/npOV-FeNR9fwdw) Кроме того, подключал TMS9929A, он недорогой и его легко купить. Конечно, он ощутимо слабее 9958, но и с ним можно получить хорошие графические и текстовые возможности.
Думаю, проблем с подключением к "Вектору" быть не должно. Я, даже, думал об этом, но не реализовал.
Improver
04.10.2022, 06:12
Пусть не к "Вектору", а к "Ориону" 9958 успешно подключён (https://disk.yandex.ru/i/ttSP2PRCLGQL4w). Ещё видео с заполнением текстового экрана. (https://disk.yandex.ru/i/npOV-FeNR9fwdw) Кроме того, подключал TMS9929A, он недорогой и его легко купить. Конечно, он ощутимо слабее 9958, но и с ним можно получить хорошие графические и текстовые возможности.Это здорово, но как там насчёт обратной совместимости с ПО для Ориона? Т.е. старые программы могут выводить картинку через эти подключения без доработок? Полагаю, что нет... :(
Это здорово, но как там насчёт обратной совместимости с ПО для Ориона? Т.е. старые программы могут выводить картинку через эти подключения без доработок? Полагаю, что нет... :(
Во-первых, это можно сказать про любую железку, которую ПО компьютера не понимает. Для этого и существуют драйверы. Во-вторых, старые программы прекрасно выводят картинку через штатный видеоконтроллер. В третьих, моей целью было только показать возможность подключения видеопроцессора на собственном примере, вроде как сказать: "Вот, ребята, это возможно, ничего сложного - смотрите сами. Нужно только сделать." Я планировал создать для "Ориона" аппаратно-программный комплект для разработки игр и других приложений, использующих видеопроцессор. Но, по некоторым причинам, продолжать не стал. Возможно, кто-нибудь реализует подобное и для "Вектора".
Improver
04.10.2022, 12:53
Во-первых, это можно сказать про любую железку, которую ПО компьютера не понимает. Для этого и существуют драйверы. Во-вторых, старые программы прекрасно выводят картинку через штатный видеоконтроллер.Я не возражаю, железка интересная получилась, но если бы у неё была возможность обрабатывать картинку в той же самой штатной видеопамяти, типа, программа без драйвера рисует картинку по-старому, а с драйвером начинает использовать ускоритель. А так уже давно была идея подключить к Вектору обычную vga или ega видеокарту через isa-порт -- это просто, быстро, эффективно, но совершенно несовместимо со всем ПО.
- - - Добавлено - - -
Кстати, а схемкой подключения 9958 к Ориону не поделитесь? ;)
если бы у неё была возможность обрабатывать картинку в той же самой штатной видеопамяти, типа, программа без драйвера рисует картинку по-старому, а с драйвером начинает использовать ускоритель.
Это возможно с устройством подобным тому, которое разрабатывал Syntal. К ВУ подключается плисовая девборда со своим видеовыходом, и записи в VRAM дублируется и наружу. Так можно получить и чисто потребительские плюшки (корректный видеосигнал, одинаковые точки в HiRes, скандаблер и т.п.) и программные навороты. Но тут так - msxные VDP можно на векторе задействовать сравнительно просто, например частично депортировав msxные игрушки с переводом эмуляции видео обратно на VDP, а с ПО под новые возможности вопросов больше.
Кстати, а схемкой подключения 9958 к Ориону не поделитесь? ;)
https://disk.yandex.ru/i/9YLNSgG2iNzLdQ
На схеме два типа памяти, можно устанавливать любой.
msxные VDP можно на векторе задействовать сравнительно просто, например частично депортировав msxные игрушки с переводом эмуляции видео обратно на VDP, а с ПО под новые возможности вопросов больше.
По поводу портированных с MSX игр - так как эти игры, насколько я помню, все с MSX1, то и видеопроцессор можно использовать попроще, вместо дорогого V9958 (9938) - дешёвый и доступный TMS9929A. Правда, есть два минуса - чтобы получить с него выход RGB, нужно сделать схему-преобразователь (9929 выдаёт компонентный сигнал) и видеопамять лучше заменить на статическую, это ещё четыре корпуса. Но ничего сложного и дефицитного не потребуется.
А насчёт ПО - Андреем Родионовым разработаны библиотеки для BDS-C (http://sysadminmosaic.ru/msx/maestro/maestro) специально для MSX. Думаю, этот компилятор и эти библиотеки вполне можно использовать на "Векторе" для разработок. Конечно, потребуется кое-что подправить.
тут было пустопорожнее брюжжание о том, что чипы от MSX можно ведь попрограммировать в составе компьютера MSX
;A(=C)=HL/DE
;HL=HL%DE
UDiv16168:
mvi b,8
mov a,l
mov l,h
mvi h,0
UDiv16168_1:
dad h\ push psw\ add a\ mov c,a\ adc l\ sub c
sub e\ mov l,a\ mov a,h\ sbb d\ mov h,a
jnc UDiv16168_2
pop psw
jc UDiv16168_3
dad d
.db 3Ah ;lda ...
UDiv16168_2:
pop psw
UDiv16168_3:
inr c
mov a,c
dcr b
jnz UDiv16168_1
ret
Можно ли сократить приведенную процедуру? Или ускорить без увеличения размера?
Главное, чтобы в A получалось частное. Остаток в HL; частное в C; B и DE - все это не критично.
Получилось сократить на 5 байт и ускорить:
;A(=L)=HL/DE
UDiv16168:
mvi b,8
xra a
UDiv16168_1:
dad h\ adc a\ mov c,a\ jc UDiv16168_2
mov a,h\ sub e\ mov a,c\ sbb d
mov a,c
jc UDiv16168_3
UDiv16168_2:
mov a,h\ sub e\ mov h,a\ mov a,c\ sbb d
inr l
UDiv16168_3:
dcr b
jnz UDiv16168_1
mov a,l
ret
Заплатить пришлось порчей остатка, но добавив одну команду можем его сохранить при необходимости.
Привет всем...
А есть - Pretty assembler не как web страница,
а как приложение с .exe файлом?
И кроме Pretty assembler'а есть еще какой-нибудь софт,
типа assembler + monitor под Вектор-06Ц?
electroscat
25.06.2023, 20:57
Привет всем...
А есть - Pretty assembler не как web страница,
а как приложение с .exe файлом?
На гитхапе прити ассемблера есть его исходники для сервера, и там же вроде есть описание как запустить это под винды локально, используя встроенный веб сервер веника, или типа того уже не помню. Все это работает, в порядке, только без эмулятора,но все компилится и можно запустить дальше на эмуле типа "башкирия" под винды.
И кроме Pretty assembler'а есть еще какой-нибудь софт,
типа assembler + monitor под Вектор-06Ц?
Есть несколько эмулей еще.
Чтобы prettyasm запустить локально, нужен локальный сервер. Например, если установлен Питон, то проще всего в каталоге, где сорцы ассемблера, запустить "python3 -m http.server 8000" и тогда ассемблер будет на http://localhost:8000/ Сорцы ассемблера - https://github.com/svofski/pretty-8080-assembler Но кнопка "RUN" так работать все равно не будет, потому что эмулятор будет расположен на другом домене. Чтобы все заработало вместе, надо аналогичным образом разместить у себя vector06js. Если правда интересно, могу попробовать рассказать как это сделать. Но по-моему это того не стоит.
Чтобы локально программу собирать есть отличные ассемблеры. Я иногда пользуюсь TASM 3.2, например: https://www.ticalc.org/archives/files/fileinfo/250/25051.html
А чтобы запускать и отлаживать есть эмуляторы.
По-моему идейно это скорее из темы "Программирование": https://zx-pk.ru/threads/34480-programmirovanie.html
Там замечательная сводка всевозможных средств разработки под Вектор.
parallelno
26.06.2023, 22:30
Привет всем...
А есть - Pretty assembler не как web страница,
а как приложение с .exe файлом?
И кроме Pretty assembler'а есть еще какой-нибудь софт,
типа assembler + monitor под Вектор-06Ц?
Мне очень нравится retroassembler. Быстрый и гибкий в настройках. Интегрируется в visual studio code. Есть подсветка синтаксиса и линки на ошибки сборки. Легко прыгать на код где что-то пошло не так.
Привет всем...
Да хотел, что-нибудь попробовать написать...
Не большое...
У меня первый мой комп был - Вектор-06Ц...
Но книжки по ассемблеру не было в поставке - не разобрался...
В комплекте шли брошюры - Basic, monitor и книга со схемами...
Процедура (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1181358&viewfull=1#post1181358) неинтересная для общественности, но для полноты картины дополню обработкой деления на 0.
Как вариант:
1. В начале добавляем
mov a,e\ ora d\ rz
2. Меняем
mvi b,8 на mvi b,7
...
jnz UDiv16168_1 на jp UDiv16168_1
После таких изменений и дополнений на выходе флаг Z=1 будет индикатором деления на 0. Флаг S=0 тоже показывает деление на 0.
parallelno
28.06.2023, 08:58
Привет всем...
Да хотел, что-нибудь попробовать написать...
Не большое...
У меня первый мой комп был - Вектор-06Ц...
Но книжки по ассемблеру не было в поставке - не разобрался...
В комплекте шли брошюры - Basic, monitor и книга со схемами...
Это здорово что есть энтузиазм! Здесь очень много толковых ребят. Если есть конкретные вопросы, то уверен помогут!
Если отвлечься от требований (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1181349&viewfull=1#post1181349), которые мне были нужны для конкретной программы, то процедуру (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1181358&viewfull=1#post1181358) можно разлочить до 8=24/16. Убираем XRA A в начале и MOV A,L в конце и вуаля:
;L=AHL/DE
;AH=AHL%DE
Правда если нужна проверка делителя на ноль в начале, то она в таком случае усложняется
inr e\ dcr e\ jnz $+6
inr d\ dcr d\ rz
Все знают традиционный вариант преобразования HEX полубайта в символ
cpi 0Ah
jc $+5
adi 7
adi 30h
Некоторые (теперь и я) знают оптимизированный вариант для x86 с вычитанием и десятичной коррекцией, котрый предложил Norbert Juffa.
Этот вариант 1 в 1 преобразуется для z80 (возможно там он его и подсмотрел), а вот 8080/85/ВМ1 не поддерживают десятичную коррекцию после вычитания.
Берем идею, по сравнению с z80 добавляется cmc (что сущая ерунда на фоне традиционного подхода)
cpi 0Ah
cmc
aci 30h
daa
Редкая, но приятная ситуация, когда получается одновременно ускорить и сократить.
parallelno
22.07.2023, 07:44
Если я правильно нагуглил описание команды daa, то она устанавливает флаг carry в один если коррекция была. Если я ничего не напутал то вроде должно работать следующие:
Daa
Aci 30h
Поправьте пожалуйста если ошибся
Для уточнения тонкостей работы команд 8080 удобно ориентироваться на проверенные реализации 8080, например (https://github.com/begoon/i8080-core/blob/e03de57b88e2da41f35876a1a896af6c1bab3cc2/i8080.c#L521)
Если у нас исходная цифра в младшем полубайте, то переноса в CY не будет, только в AC (если A-F), поэтому к сожалению ACI тут не поможет и единицы не хватает (для A-F).
- - - Добавлено - - -
Можно вычитать не до DAA, а после и тогда избавляемся от CMC и, казалось бы, догоняем по эффективности x86 и z80. Но есть проблема - в большинстве случаев мы используем преобразование полубайта в составе преобразования байта и перед данным фрагментом будет команда ANI 0Fh, которая установит AC и для его сброса придется добавить например ORA A.
ora a
daa
cpi 10h
sbi 0CFh
- - - Добавлено - - -
parallelno, спасибо, после твоего поста взглянул на проблему комплексно и получилось вот что (ORI 0F0h вместо ANI 0Fh в традиционном варианте):
ori 0F0h
daa
cpi 60h
sbi 1Fh
Т.е. в итоге само преобразование полубайта сравнялось по эффективности с z80, а 8080 не так уж плох.
parallelno
22.07.2023, 10:09
Вроде ani сбрасывает carry флаг?
- - - Updated - - -
Если следовать реализации которую ты указал то можно сдвинуть вначале на b0h, а потом вычесть 60h
Adi b0h
Daa
Cmc
Sui 61h
Или что-то упускаю?
- - - Updated - - -
Не sui, а вычесть с carry. Но я по памяти не помню мнемонику
- - - Updated - - -
Или не 61h, а 5fh, нужно покумекать :))
- - - Updated - - -
Да, вроде нужно вычесть с carry 2fh, чтобы стало +30h для чисел, и +37h для букв
- - - Updated - - -
Не, я все напутал. Но ответ где-то рядом. Сейчас соберусь и напишу. :))
- - - Updated - - -
Adi b0h
Daa
Aci 30h
- - - Updated - - -
Поправка.
Adi a0h
Daa
Aci 30h
- - - Updated - - -
Если мой код работает, то с ani 0fh получается по тактам тоже самое что у тебя.
- - - Updated - - -
А если так
Ori f0h
Daa
Прибавить аккуратно с carry чтобы попасть в нужное значение
:)
- - - Updated - - -
Прибавить кажется нужно что то вроде такого a0h + 30h - f0h
А если так
Ori f0h
Daa
Прибавить аккуратно с carry чтобы попасть в нужное значение
Честно говоря я не понимаю. Варианты, которые я привел решают задачу преобразования полубайта hex->символ или отдельно или в составе преобразования байта, а какую задачу ты предлагаешь решать?
parallelno
22.07.2023, 10:27
Что кажется равносильно e0h.
То есть код будет
Ori f0h
Daa
Aci e0h
- - - Updated - - -
Я пытаюсь решить задачу преобразования числа от нуля до 15 в hex символ.
- - - Updated - - -
Логика в коде такая:
Делаем из числа от нуля до 15 число от от f0h до ffh.
Затем используем daa. Если число от f0h до f9h, то daa прибавляет 60h и сбрасывает carry. Диапазон получается от 50h до 59h, после прибавляем e0h, получаем диапазон от 30h до 39h.
Если число было от 10 до 15, то daa команда прибавит ещё 6 и установит carry, а aci прибавит carry.
- - - Updated - - -
Возможно я где-то ошибся, поправь пожалуйста
DAA в таком случае всегда будет устанавливать CY и этот код правильно будет работать только для A-F. Если заменить ACI на ADI, то правильно будет работать только для 0-9.
parallelno
22.07.2023, 12:05
Точно. Спасибо за подсказку! Нужно ещё покумекать потом будет:)
- - - Updated - - -
Было бы классно проверить на реальном векторе выставляется ли флаг переноса когда происходит коррекция младших четырех бит.
По поводу флагов 8080 (причем и у клонов интел, в т.ч. ВМ80, и у amd) уже все проверяли на реалах. С 8085 и z80 тоже все выяснили. Из околовекторовских процов недоэмулирован только 580ВМ1, но и там, насколько помню, неточности не касаются CY и AC.
Все знают традиционный вариант преобразования HEX полубайта в символ
Всем известный был вроде:
ADI 90h
DAA
ACI 40h
DAA
Получается тут (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1182743&viewfull=1#post1182743) я изобрел велосипед, зато тут (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1182760&viewfull=1#post1182760) (второй в посте) все же немного улучшил.
parallelno
22.07.2023, 22:19
Всем известный был вроде:
ADI 90h
DAA
ACI 40h
DAA
Классный вариант. Спасибо. Я правда не встречал его.
- - - Updated - - -
Получается тут (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1182743&viewfull=1#post1182743) я изобрел велосипед, зато тут (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1182760&viewfull=1#post1182760) (второй в посте) все же немного улучшил.
Отличная идея с Ori! Спасибо.
Думаю - ладно, я темный, посмотрю как там у профессионалов. Векторовские и cp/m программы: Монитор-отладчик, basic 2.5, эмулятор рк/микроши, sid (cp/m), basic-80 5.2 (cp/m) - везде традиционный вариант с условным переходом. Т.е. вряд ли можно сказать, что все знают (любой вариант) преобразования hex->символы без условного перехода.
Improver
23.07.2023, 11:07
везде традиционный вариант с условным переходом.И то же самое в РДС и Т-72 -- я тоже посмотрел. :)
Уточню, пока меня не поймали - в случае SIDа я посмотрел реализацию перевода hex->символ в досе, в остальных случаях - внутренние процедуры программ. - ошибка!
- - - Добавлено - - -
Заканчиваю тупить - сначала я все правильно написал, в SIDе своя процедура.
На векторе до сих для рисования кругов видел только алгоритм Мичнера. Он и в драйверах устройств/бейсике, и сам делал (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=989448&viewfull=1#post989448). Попробовал "метод Jesko" (https://en.wikipedia.org/wiki/Midpoint_circle_algorithm). Он проще и быстрее, но при маленьких радиусах результат получается менее круглый, чем по Мичнеру.
Интересующиеся ассемблером 8080 наверняка видели уроки программирования для Специалиста, которые делает CityAceE. Графика симпатичная и стало интересно, как выглядит на векторе программа из пятой части (https://zx-pk.ru/threads/35471-spetsialist-programmirovanie-na-assemblere.html?p=1194065&viewfull=1#post1194065). Возможно потом (когда выйдет последний урок) кто-нибудь захочет раскрасить графику и/или переработать исходник и сделать "истинно векторовскую" версию.
CityAceE
06.02.2024, 19:10
Графика симпатичная и стало интересно, как выглядит на векторе программа из пятой части.
Класс! Было очень интересно увидеть, как всё это крутится на Векторе! И даже код остался с минимальными изменениями. Теперь стало ещё интереснее продолжить, раз это всё можно легко (?) перенести на Вектор.
У меня на очереди опрос курсорных клавиш и пробела. На выходе из этой процедуры в регистре А некоторые включенные биты:
; Опрос клавиатуры на предмет нажатия курсорных клавиш и пробела
; Результат в регистре А
; A = 0 - не было нажатия
; Отдельные установленные биты:
; 0 - Вниз
; 1 - Вверх
; 2 - Вправо
; 4 - Влево
; 5 - Пробел
Надеюсь, что это легко будет повторить для Вектора.
Глядишь - новая игра родится, сразу на две платформы. А ещё "Орион" есть, строение экрана аналогичное...
CityAceE
06.02.2024, 19:43
Раз уж пошла такая пьянка... ivagor, svofski, очень интересует ваше компетентное мнение. Я так понимаю, что если вы не смотрите мои ролики, то наверняка хотя бы исходники просматриваете. Цель моих роликов показать как что делается, так сказать, "в лоб", без каких-то ухищрений. Чтобы несведущие люди поняли, что нет здесь никакого волшебства - всё достаточно легко и просто. И тем не менее, мне немного стыдно показывать эти вещи широкой аудитории, так как я понимаю, что я где-то ошибаюсь, что-то можно сделать оптимальнее (короче, быстрее и т.д.). В общем, покритикуйте, пожалуйста, мой код, несмотря на то, что он в неправославных мнемониках Z80.
Можно наверно было замахнуться на мультиплатформенный пример, хотя с учетом видео получилось бы пожалуй слишком громоздко, разбухнет в разы.
Есть что оптимизировать, например в выводе спрайта вместо чтения в C можно сразу ORить и XORить с (HL). Но эту процедуру и так придется переделать, если выводить такие большие спрайты сразу на экран, то для уменьшения мигания стоит это делать построчно.
Пожелание от самозванного орфографа поменять strite на sprite.
Нескромный вопрос - откуда графика?
Я так понимаю, что если вы не смотрите мои ролики, то наверняка хотя бы исходники просматриваете.
Я ролики смотрю, но обычно с выключенной головой. Да и зачем тут критиковать -- выжимать такты надо тогда, когда их не хватает. Понятность имеет большую ценность.
Пятый посмотрел целиком.
- - - Добавлено - - -
Согласен со svofski, что понятность в обучающих примерах на первом месте. Но все же моменты вроде упомянутого лишнего чтения в C лучше убирать, они мешают понятности как и излишняя оптимизация.
CityAceE
06.02.2024, 22:52
в выводе спрайта вместо чтения в C можно сразу ORить и XORить с (HL)
Отлично! Спасибо! Вот я реально забыл про возможность OR'ить и XOR'ить сразу с (HL). А заодно и от лишних PUSH/POP BC удалось избавиться. Превосходно!
Нескромный вопрос - откуда графика?
Я несколько раз в разных частях видео упоминал и в комментариях писал, что 99% графики дёрнуто из Rodland (Rod-Land) со Спектрума. Вода из Dizzy. Кирпичи на стене по-моему из Montana Jones 2. Наверное, что-то ещё откуда-то дёргал, но уже не вспомню.
Пожелание от самозванного орфографа поменять strite на sprite.
Тоже, конечно, поправлю :)
Адаптировал было урок 7 (https://zx-pk.ru/threads/35471-spetsialist-programmirovanie-na-assemblere.html?p=1194537&viewfull=1#post1194537) CityAceE для вектора, но потом подумал - есть же Chip&Dale (http://caglrc.cc/scalar/ware/393/) Дениса Федина (или ускоренный вариант (https://zx-pk.ru/threads/30425-vnutrennosti-programm.html?p=1160954&viewfull=1#post1160954)). Примерно тот же подход, только в цвете и уже не мигает (ну от мигания и CityAceE избавится в следующих уроках).
А может имеет смысл попробовать сделать подобный простенький движок с открытым исходником для вектора? Вдруг у кого-то есть идеи по геймдизайну и он умеет рисовать (или знает где взять/сконвертить графику), но не хочется разбираться в деталях векторовского железа. Знание ассемблера 8080 все равно понадобится, но без железных подробностей. В крайнем случае можно даже замахнуться на мультиплатформенный (хотя бы на пару компов с 8080) движок, если кто-то из невектористов заинтересуется. Ключевой момент - речь об очень простом движке, примерно как в Чипе с Дейлом.
CityAceE
15.02.2024, 17:55
А может имеет смысл попробовать сделать подобный простенький движок с открытым исходником для вектора?
В общем-то, я примерно то же самое и делаю. Для другого компьютера на i8080 нужно будет только переписать процедуру вывода спрайта и тайлов (и, если нужно, саму графику перевести в линейный формат и раскрасить), ну и опрос клавиатуры переделать. Да и в моём варианте эти же процедуры необходимо оптимизировать по скорости, так как я сейчас основной упор делаю на понятность, так что никаких развёрнутых циклов и запись в экран через стек.
А вообще идея, конечно же, классная! Уверен, что ты со своим опытом сделаешь всё с максимальной оптимизацией. А если вдруг (???) потребуется какая-то подмога по Специалисту, то я конечно же подключусь.
Кстати, изначально у меня вся графика в линейном формате. Это я специально для Специалиста её конвертировал. Могу поделиться, если вдруг нужно.
Адаптировал было урок 7 CityAceE для вектора
А можно всё-таки посмотреть на эту адаптацию? Ну очень интересно посмотреть как оно на Векторе смотрится!
Все же добавил двойную буферизацию (можно глянуть в v06x в базыре), управление курсором.
Кстати, изначально у меня вся графика в линейном формате. Это я специально для Специалиста её конвертировал. Могу поделиться, если вдруг нужно.
Многоцветную графику (аркада, амига, атари ст) из rod-land и из диззи я бы попробовал вставить, если есть.
CityAceE
15.02.2024, 20:46
Все же добавил двойную буферизацию (можно глянуть в v06x в базыре), управление курсором.
Прекрасно! На Векторе смотрится просто отлично! А цветов добавить, так вообще будет загляденье!
Иван, пожалуйста, на пальцах в двух словах растолкуй свой метод двойной буферизации. У меня получается просто какая-то сложная конструкция. Или, если не жалко, ещё лучше исходник или хотя бы его часть покажи. Я тогда твой метод в следующем уроке покажу и расскажу.
Многоцветную графику (аркада, амига, атари ст) из rod-land и из диззи я бы попробовал вставить, если есть.
Увы, у меня только со Спектрума.
Мне не хотелось напрягаться и я пошел простым путем - два буфера (экрана), рисуем в невидимом, когда нарисовали показываем и рисуем в другом невидимом, когда нарисовали показываем и круг замкнулся. В v06x в базыре видно, что два экрана и обновляющиеся части выделяются красным. Специалисту это к сожалению не подойдет, но ты же сказал в видео, что нужно рисовать спрайт в невидимом буфере и потом эту часть экрана обновлять. Понятно, что это сложнее и я туда не полез, раз можно двойную буферизацию. Есть конечно дубовый простой метод - каждый раз рисуем/копируем из оригинала в теневой буфер, накладываем спрайты и выводим на экран. Если игровая область не очень большая (например 256x128, 4 Кб) и процессор не очень медленный, то получается приемлемо. Ну это я общеизвестные вещи пишу, а насчет частичного обновления лучше у jerri проконсультируйся, он специалист по движкам.
Я тут подумал, что к моменту, когда кто-нибудь созреет (а может это никогда не случится), я все забуду и вновь погружаться в тему будет проблематично. Поэтому вместо потенциального своего движка выкладываю исходник модифицированного движка CityAceE. Все желающие могут сами доработать под свои требования. Это уже вариант без аппаратной двойной буферизации, чтобы легко масштабировать до 8 или 16 цветов. Ну и оптимизировал по скорости. Очень внимательный зритель в некоторые моменты может заметить тиринг, но на мой взгляд терпимо, жить можно. Зато тут заметно шустрее, 30+ FPS вместо 12.5 FPS в urok7rom06c. Свое участие в данном проекте завершаю, разве что готов многоцветный вариант сделать, если кто-нибудь выцепит графику из аркады/амиги/атари ст.
Тут нет пиксельной точности по горизонтали и разворотов спрайтов, но CityAceE планирует рассмотреть эти вопросы. Поэтому оставил некоторые рудименты специалистовского оригинала, хотя на векторе можно (и по-хорошему нужно) без них. Во многих случаях можно обойтись и без пиксельной точности.
Еще тут привязка к одному спрайту, но доделать до нескольких несложно. Временные тайлы (куда впечатывается спрайт) будут не жестко 60-63, а какие назначите.
Потихоньку копаю арифметику, с умножением кое-что получилось. Цитата из вики про алгоритм Карацубы "На практике алгоритм становится эффективнее обычного умножения при умножении чисел длиной порядка сотен двоичных (десятков десятичных) разрядов, на числах меньшей длины алгоритм не даёт существенного преимущества из-за большего, чем в наивном алгоритме, числа требуемых сложений, вычитаний и сдвигов." Но это про современные процы, а у 8080 нет аппаратного умножения даже малой разрядности, поэтому граница применимости сдвигается. Если коротко, то по моим экспериментам начиная с 32*32=64 (через 3 умножения 16*16=32 вместо 4х) Карацуба безоговорочно быстрее, хотя и не намного, т.к. только одна ступень. Понятно, что с увеличением числа ступеней выигрыш будет расти. Многоразрядные умножения не особо востребованы для 8080, но сферы применения найти можно, например в библиотеках плавучки с двойной точностью для ЯВУ.
Процедура рисования эллипсов с примером и исходником. По сравнению с другим (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=989448&viewfull=1#post989448) вариантом есть как преимущества так и недостатки.
Недостатки:
1. Медленнее
2. Максимальные радиусы в 2 раза меньше
3. Нет дуг
Преимущества:
1. Не нужно держать в памяти здоровенные таблицы
2. Можно гораздо более точно задавать соотношение радиусов
Процедура с колес, при желании можно оптимизировать и по скорости и по размеру. Алгоритм отсюда (https://www.geeksforgeeks.org/midpoint-ellipse-drawing-algorithm/), если кому интересно.
- - - Добавлено - - -
Забыл сразу написать - в комплекте идут тормозные, но компактные процедуры умножения, возможно кому-нибудь пригодятся.
Портанул SINCOS CORDIC (http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html#mozTocId663023) (автор Andre Adrian) на 8080 (мнемоники остались z80).
Хотел ускорить "фонтан", но встроенная в бейсик реализация через ряды в модерновых версиях оказалась быстрее (в 2.5 медленнее). При замене части тригонометрии на LUT средствами бейсика фонтан ускоряется на четверть.
Тем не менее целочисленные SINCOS для 8080 могут кому-нибудь пригодиться. Отличие от оригинала z80 - т.к. регистров у 8080 меньше, то на выходе результат остается в памяти, не в регистрах.
Проблема в отсутствии у 8080 команд арифметического сдвига вправо. Если ограничить точность 2 или 3 байтами, то можно сделать весьма эффективную реализацию для 8085, там есть заветная команда ARHL.
metamorpho
04.04.2025, 22:09
Портанул SINCOS CORDIC (http://www.andreadrian.de/oldcpu/Z80_number_cruncher.html#mozTocId663023) (автор Andre Adrian) на 8080 (мнемоники остались z80).....
А ROM есть ? Или в чём его компилировать ?
Хотел ускорить "фонтан", но встроенная в бейсик реализация через ряды в модерновых версиях оказалась быстрее (в 2.5 медленнее). При замене части тригонометрии на LUT средствами бейсика фонтан ускоряется на четверть.
а что вы хотите получить? Генерацию синусоиды заданной частоты можно реализовать без таблиц - на одном умножении и трех сложениях на каждый сэмпл.
А ROM есть ? Или в чём его компилировать ?
Это не законченная программа, только функция и пример вызова, без визуализации, поэтому в ROM смысла нет. Касательно компиляции - я забыл приложить tasm.inc, исправился (https://zx-pk.ru/threads/29144-programmirovanie-na-assemblere.html?p=1212550&viewfull=1#post1212550)
Что касается грубых, но простых и быстрых аппроксимаций, можно глянуть например тут (https://www.youtube.com/watch?v=1xlCVBIF_ig) (оценка точности первого варианта здесь (https://namoseley.wordpress.com/2012/09/18/a-quick-and-dirty-sinx-approximation/)). В комментариях есть более точный (и сложный) вариант cos(pi x) = 4x^3-6x^2+1, x от 0 до 1.
Компактные и быстрые генераторы таблиц (https://github.com/neonz80/sine?tab=readme-ov-file) для z80.
Пример (исходник и ROM) использования CORDIC для рисования полупериода SIN (сверху) и COS (снизу).
На практике использовать для подобных целей CORDIC нецелесообразно (считает со сравнительно высокой точностью, поэтому долго), лучше взять например вышеупомянутые процедуры генерации таблиц.
- - - Добавлено - - -
С другой стороны, те простые процедуры могут оказаться слишком грубыми для некоторых рисовальных применений. Есть компромисс - CORDIC, но уменьшить число байт до 1-2 и соответственно уменьшить число итераций (это резко ускорит расчет).
а что вы хотите получить? Генерацию синусоиды заданной частоты можно реализовать без таблиц - на одном умножении и трех сложениях на каждый сэмпл.3 сложения то - на кой??? Всегда делал на одном умножении + одном сложении. Правда - на ARM.
ну да, можно умножение и сложение, но тогда нужно вначале косинус угла с шагом посчитать.
ну да, можно умножение и сложение, но тогда нужно вначале косинус угла с шагом посчитать.Это всего два полных вычисления. Зато потом можно хоть тысячи сэмплов гнать, тратя на каждый всего по: 1умножение+1сложение.
В тестовом режиме запустил обновление Прекрасма https://caglrc.cc/pretty-testing
Многие нововведения показаны в Главрыбе (первая в рыбном меню).
* в проекте много буферов, их можно .include один в другой. Быстрое переключение между табами Alt+1,2.. (На Линуксе Ctrl, на Маке Cmd)
* проект надежно хранится в localStorage. выгружается архивом zip, загружается обратно
* добавлен препроцессор, кроме #ifdef... можно даже делать макросы с параметрами. Ограничение -- они должны быть в одну строку
* в текстовом редакторе добавлен режим vim и раскраски (см. шаверма-меню слева от табов) - для быстрого перебора тем правый клик выбирает пункты без закрытия меню
* запуск эмулятора по хоткеям Ctrl+Alt+B (Cmd+Opt+B/C на Маке). Закрывается обратно по тому же сочетанию. Можно больше вообще руки с клавиатуры не поднимать.
* добавлена загрузка в эмулятор через вав (иконка с кассетой внизу)
* улучшены сообщения об ошибках. сверху показывается индикатор количества ошибок, клик проматывает редактор к следующей ошибке.
* исправлены мелкие глюки
Фанаты РК, Микроши, Апогея, Специалиста, Партнера теперь могут ликовать, запуская свои программы прямо в Прекрасме. Это стало возможным, благодаря встроенному emu80 (https://online.emu80.org/). Огромное спасибо Pyk за эмулятор и титанические усилия по интеграции!
На подходе еще платформы.
Добавлен Микро-80.
ВОЛНУЕМСЯ ТЧК
Чтобы любители Бейсика не чувствовали себя обделенными, я убрал фактически искусственное ограничение на запуск Бейсиковских программ из Прекрасма.
https://caglrc.cc/pretty-testing/?https://gist.githubusercontent.com/svofski/ecbd83861c1d9aa78bf4e0defc32d74f/raw/7c22d6b42153b15f7fb2fa15d4227ca3e4d17691/basic-0.bas
RUN запускает, все как у больших. Тут конечно совсем все непроверенное, но как-то фурычит. Можно даже любоваться на токены прямо в желобе. Переключение в режим Бейска происходит по расширению буфера, если .bas или .asc -- то Бейсик.
Появился повод добавить несколько красивых рыб на Бейсике.
https://caglrc.cc/pretty-testing/?basic-rybov
так уж получилось, что в Бейсике работает препроцессор и .include
Для Вектора появился отладчик. Для удобного использования окно эмулятора надо задочить кнопкой на тулбаре со стрелкой вправо. Брекпойнты можно ставить, кликая на адрес в желобе. Память и регистры редактируются инплейс. Изменения в памяти не будут отображаться в листинге, но в окне дизассемблера будут. В нем всегда видно актуальный код, даже для тех адресов, которых нет в редакторе.
Если нужно поставить точку останова куда-нибудь за пределы исходного кода, можно ввести адрес в окне дизассемблера и кликнуть слева от нужной инструкции.
Хозяйке на заметку.
Софтовые реализации умножения Бута не пользуются популярностью на 8-битках, т.к. на большинстве ретропроцов уступают классическим процедурам через беззнаковое умножение с обрамлением учета знаков. Но 8085 благодаря команде ARHL позволяет эффективно реализовать знаковое умножение 8x8 по алгоритму Бута. В эмуляторе 6128 получилось на 7% быстрее, чем через беззнаковое умножение (самая быстрая нетабличная процедура) с обрамлением.
- - - Добавлено - - -
на 7% быстрее, чем через беззнаковое умножение
А если еще задействовать команду DSUB, то просто фантастика - на 12% быстрее, чем знаковое через беззнаковое (догоняет по скорости просто беззнаковое умножение!) и пара DE свободна. Получается на 8085 можно сделать по этому алгоритму даже знаковое умножение 8x16 или 16x8.
Improver
28.09.2025, 11:00
А если еще задействовать команду DSUB, то просто фантастика - на 12% быстрее, чем знаковое через беззнаковое (догоняет по скорости просто беззнаковое умножение!) и пара DE свободна.А можно пример реализации такого умножения, в исходниках? Не то, чтобы он был прямо сейчас нужен, но чтобы не изобретать велосипед потом...
Завтра выложу, вчера долго тупил, но к вечеру сделал нормальный вариант 16x16. Еще одно замечательное свойство - при побайтном увеличении разрядности второго множителя сложность и время работы процедуры будут расти практически линейно, можно сделать хоть 16x64. У традиционного умножения разрядность сумматора = разрядности произведения, а тут = разрядности первого множителя. К большому сожалению не вижу как это можно эффективно реализовать на 8080 и 580ВМ1, но для 8085 и z80 это замечательный алгоритм.
Знаковое умножение Бута 16x16 для 8085. Мнемоники 8085 не используются, вместо них .db, что расширяет круг совместимых ассемблеров. Можно еще добавить ускоренную обработку байтов 00 и FF во втором множителе.
Для 8080 изобрел велосипед (плохо гуглил, 100% такой вариант должны были где-то описать) - беззнаковое умножение Бута с левыми сдвигами. К сожалению толку нет (пробовал 8x8 и 8x16) - медленнее традиционных процедур, больше размер и регистров использует больше, сплошные недостатки.
Спасибо, удобный инструмент для тестирования программ (https://caglrc.cc/pretty-testing/).
Только почему набранный латиницей текст внутри PRINT переводит в кириллицу?
Спасибо, удобный инструмент для тестирования программ (https://caglrc.cc/pretty-testing/).
Только почему набранный латиницей текст внутри PRINT переводит в кириллицу?
КОИ7 потому что, маленькая латиница ~ большая кириллица. Все только в верхнем регистре.
КОИ7 потому что, маленькая латиница ~ большая кириллица. Все только в верхнем регистре.
КОИ-7 Н2 (https://ru.wikipedia.org/wiki/%D0%9A%D0%9E%D0%98-7#%D0%9A%D0%9E%D0%98-7_%D0%9D2) получается.
svofski, подскажите пожалуйста, есть ли планы добавления в https://caglrc.cc/pretty-testing/ других Бейсиков, кроме уже имеющегося для «Вектор-06Ц»?
svofski, подскажите пожалуйста, есть ли планы добавления в https://caglrc.cc/pretty-testing/ других Бейсиков, кроме уже имеющегося для «Вектор-06Ц»?
Нет. Этот было добавить просто, я скорее убрал искусственные препятствия для его работы. Вот что можно сделать, так это обновить встроенный Бейсик на версию поновее, но я не знаю какая правильная.
Кстати, все уже работает по главной ссылке https://svofski.github.io/pretty-8080-assembler/
Вот что можно сделать, так это обновить встроенный Бейсик на версию поновее, но я не знаю какая правильная.
Насколько разобрался, вот эта версия на данный момент крайняя — https://caglrc.cc/scalar/ware/940/ — и по той же ссылке обновляется.
Возможно ли добавление в качестве альтернативной, без замены базовой версии Бейсика?
Насколько разобрался, вот эта версия на данный момент крайняя — https://caglrc.cc/scalar/ware/940/ — и по той же ссылке обновляется.
Возможно ли добавление в качестве альтернативной, без замены базовой версии Бейсика?
Это уже не самая последняя. Хотя наверное она была бы вполне достаточной для большинства случаев.
Альтернативы это сложно.
Кстати, все уже работает по главной ссылке https://svofski.github.io/pretty-8080-assembler/
На Safari, похоже, поломалось создание нового проекта. При нажатии на New в консоль летит такое:
[Error] Failed to load resource: the server responded with a status of 404 () (FileSaver.min.js.map, line 0)
На Safari, похоже, поломалось создание нового проекта. При нажатии на New в консоль летит такое:
[Error] Failed to load resource: the server responded with a status of 404 () (FileSaver.min.js.map, line 0)
А чему это мешает? Это просто map от min.js, его не было и не будет.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot