|
nedoPC.orgElectronics hobbyists community established in 2002 |
|
Author |
Message |
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Естественно! И первым же делом, как в начале 90-тых начал ковырять код ПЗУ F800, чтобы освободить в ПЗУ место для личных целей. Директива U это просто JMP F000. Сейчас такой JMP никому не нужен. Ранее предполагалось, что на F000 стоит какая-то резидентная программа, например DOS или загрузчик бейсика из ROM-диска. Думаю, сейчас во всём мире нет ни одного рабочего РК86 в которое бы добавили ПЗУ РФ2 на F000...F7FF. Потому, что несеръёзным пользователям это и даром не надо, а у серъёзных пользователей на F000 адресуется РК-КНГМД. Какая у Вас польза от директивы U, если без РК-КНГМД она равнозначна JMP F800, а при наличии РК-КНГМД просто приводит к завису. Пока BALL не нашёл, - скиньте текст инициализации ВГ75 в ней. Если разрывы исчезли, значит высота знакомест - 8. Но ведь не только игра BALL, а вообще все грамотные игры с псевдографикой перепрограммируют ВГ75 на высоту знакомест в 8 линий (при этом на хорошем телевизоре видно 32 строки). Ну и как это обстоятельство извиняет то, что ваш ROM-BIOS выводит рамки с разрывами? Если ROM-BIOS расчитан, как и оригинал на высоту знакомест в 10 линий и 25 видимых строк, то и всегда при использовании стандартных входов будет только 25 строк и межстрочные разрывы. Потому, что подпрограммы ПЗУ и высота знакомест в 8 линий - это взаимоисключающие явления. При 32-х строках можно выводить в экран (обычно на 4000) только прямой записью процессором в экранный буфер. Если экран в 32 видимых строки установить сразу ниже 8000, то затираются рабочие ячейки, а если экран с 4000, то подрограммами пользоваться тоже невозможно, т.к они на экран 76D0. Поэтому я и предлагал изменить несколько байтов в стандартном ПЗУ, чтобы сделать формат экрана 64*32. При этом экранный буфер увеличится на 8*78= 624 байта и раб.ячейки придётся сдвинуть вниз, но лучше расположить их над экраном, тогда можно иметь оба формата экрана и 64*32 и 64*25, но в режиме 25-ти строк RAMTOP будет на 624 ячейки выше. С таким альтернативным ПЗУ ваши рамки будут сплошными (хотя всё-равно жирными и уродливыми, пока Вы не поставите себе альтернативный фонт с инверсией и нормальными рамками). Если никто такое альтернативное ПЗУ F800 не сделает, то его сделаю я, т.к тогда смену режима не надо встраивать в нортон, и не надо дублировать в нём все стандартные подпрограммы. И одно это уже оправдает доработку до двухстараничности ПЗУ F800 на двух РФ2 в два этажа. Это даёт два компьютера в одном, точнее два режима 25 и 32 строки. Если бы не мешали раб.ячейки на 7600, то можно было бы используя 250 свободных ячеек сделать одно ПЗУ на два режима, но увы... Остаётся вариант только двухстраничного ПЗУ F800. Схема с ЛЛ1 позволяет сплошные рамки и в режиме 25 строк. А никакой BALL или любая другая программа не сделает сплошные рамки в режиме 25 строк. Это решается только аппаратно. Потому что если сделать 25 строк высотой 8 линий, то частота кадров будет нестандартная и слишком высокая для телевизора. Хотя теоретически заменив времязадающий конденсатор в генераторе и настроив соответствующе зад.генератор частоты кадров можно добиться синхронизации. Я не умею ни изучать дампы в кодах, ни дизассемблировать коды в голове (а вырезать коды, загружать IDA, дизассемблировать и записывать результат в ASM-файл - это трата получаса, мне не настолько любопытно). Да, спасибо за идею, - это даёт экономию ещё в 3 байта. Хотя экономия за счёт исключения JMP-ов на F830/33, вероятно, подходит только для РК без доп.ОЗУ. Т.к при доп.ОЗУ нужны подпрограммы F836/39, которые читают/пишут байты в доп.ОЗУ. Я ещё с'экономил сегодня 3 байта, итого, с этими 3-мя байтами за вечер выиграно 6 байтов и наконец всего стало 250 свободных байт. Правда, 13 из них я без сожаления сразу же истратил на нормальный курсор (переключаемый в русском регистре на маленький). А никак не узнать. Потому что из всех мониторов для всех компьютеров страны только в М3 ОРИОНА предусмотрены ячейки под номер версии (т.к там всё хорошо продумано изначально). И узнавать не надо. Потому что все программы предполагают и должны предполагать в будущем, что по всем стандартным входам F803...F833 - базовый стандарт РК86. Программе ничего о ПЗУ знать не надо. А лезть внутрь ПЗУ программам запрещено. Хотя две точки F86C и F990 это уже установившийся стандарт, туда лезть в принципе можно. А уж если это специальная программа нуждающаяся в специальном ROM-BIOS (т.е она не может работать на стандартном ПЗУ), то как она будет выяснять, что стоящее в машине ПЗУ специальное или нормальное стандартное - это проблемы этой специальной программы, а не ROM-BIOS-а. Можно сделать, как я делал в драйверах, - есть функция возвращающая номер версии. Например, потратьте 2 байта, - пусть п/п-мма F82D (PUSK_VG) возвращаете в регистре А номер версии ПЗУ. Так ваша программа, сможет узнать, что это ваше ПЗУ.
|
31 Jan 2020 17:34 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Онa в восьмёрке игр, которых нет в свободном доступе сети. Только на моей кассете кооператива «Intel»… Надо бы заняться этим вопросом: Подключить магнитофон и оцифровать файлы. Один раз на Pentium'е уже делал лет 15 назад, но не помню, на каком диске остались. Да и контрольные суммы там упрямо сбоили, хоть бери и оцифровывай кассету, на которой те же игры, но переделанные мною под мои 16 Кб… Когда изучал по справочнику биты ВГ75, помню, в BALL туда восьмёрка и вписывалась… В Ball те же 30 строк, а экран сплющивался и дрожал влево-вправо, как киноплёнка. Что на заставке игры создавало особый эффект Но кадр телевизор держал. Можно те же F830 сделать с обнулением аккумулятора.
|
31 Jan 2020 22:33 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Немаленький кооператив, 106 тысяч сотрудников. Оказывается фирма Intel и программами для РК86 подторговывала и, видимо, на этом они неплохо поднялись, аж на разработку Пентиума хватило. Ну не обязательно те же стандартные 30+1 строк. Вряд-ли так, если разработчик грамотный. Т.к без особых хлопот ещё три строки можно уместить в тот же экранный буфер, что заметно опустит частоту кадров. Одну строку выигрываем опустив начало экрана до 76D0H-78-2 (что всё-же выше, чем 7633). Подряд в строках в их начале ставить код "стоп ПДП" нельзя, т.к регенерация нарушится (ведь в заглушенной строке не идёт регенерация ОЗУ). Но одну строку верхнего бордюра и одну строку нижнего бордюра можно заглушить кодом стоп ПДП, без потери регенерации. Три доп.строки возвращают частоту кадров в полосу захвата кадровой синхронизации. Тут надо упомянуть "химию" придуманную vinxru. Это именно "химия", основанная на превышении периода регенерации. Т.е в одной машине сработает, а в другой на древних 565 РУ3, в которых накопительные ёмкости уже с повышенными утечками, будут улёты. Кстати, если придумать как ставить в РК 565 РУ7, у которых период регенерации вдвое больше, то проблемы с регенерацией в таком режиме будут менее актуальны. У vinxru используется то, что обычно в реале динамические ОЗУ держат данные намного дольше, чем максимальный период указанный в их РТМ. Но и для 565 РУ7 и даже для статики идея vinxru непригодна, чтобы поиметь большее число строк при сохранении работы стандартных подпрограмм ввода/вывода. Кстати, чтобы уложиться в стандартный экр.буфер vinxru поднимает число строк до 37+1, вместо нужных 38+1. Т.к число строк отведённое на обр.ход оставлено одной строкой, то в таком режиме частота кадров - 53 ГЦ (что приемлемо). Но метод vinxru всё-равно не даёт режим в 32 строки с сохранением работы стандартных подпрограмм. Т.к даже, если начала строк совпадут (а они никак не совпадут, т.к у vinxru строчный шаг 74, а не 78), то стандартными подпрограмами выводить-то можно лишь на те же 25 строк и ролик экрана также всего на 25 строк. К тому же при при первой же очистке экрана произойдёт срыв отображения. Т.о без замены ПЗУ польза от такого режима лишь в экономии ОЗУ и уплющивании картинки. Т.е без замены ПЗУ и этот метод годится только для псевдографических игр, а для текстовых программ ничего не даёт, т.к не решает задачу поиметь 32 строки и сохранить работу стандартных подпрограмм ПЗУ. Попробуйте встроить такой режим в ваше ПЗУ F800, включая его при инициализации оконности. Кстати, делая ROM-BIOS РК на формат экрана 64*32, разумно использовать идеи vinxru по заглушке невидимых строк и сокращению строчного шага. Это сократит размер экр.буфера и поднимет RAMTOP. Т.к атрибуты не предвидятся, можно с'экономить на каждой строке 5 байтов, ставя команду "стоп ПДП" в позиции 8+64=72. Тогда строчный шаг сокращается с 78 до 73. А выигрыш на 38 строках составит 38*5= 190 байтов. По одной невидимой строке сверху и снизу экрана можно заменить всего одним байтом, что экономит ещё 144 байта. Теперь-то это уже лишнее. Я же написал, что разобрался и заимствовал эту идею, чтобы добыть эти 3 дополнительные байта: - - - Добавлено - - -При смене формы курсора в зависимости от режима клавиатуры (русский-латинский) теоретически возможна небольшая неприятность в псевдографических играх с опросом клавиш стандартными подпрограммами. Псевдографические игры меняют режим ВГ75 устанавливая режим в 32 видимых строки. Экран при этом уносят ниже 7600. Вывод на такой экран подпрограммой F809 не работает. Но опрос клавиатуры возможен, хотя чтобы курсор был в нужном месте, нужно вручную соответственно корректировать ячейки POSX, POSY (или выключать курсор). Если при таком опросе стандартными подпрограммами случайно нажать клавишу <РУС/ЛАТ>, то при смене формы курсора установится стандартный режим с экраном на 76D0 (т.к при каждой смене флага RUSLAT, чтобы изменить форму курсора, вызывается подпрограмма инициализации ВГ75). Отчего вместо псевдографического экрана 64*32 отобразится стандартный экран 64*25, причём если там коды или мусор, то изображение сорвётся. В ВГ75 нет отдельной команды для смены формы курсора, это можно менять только при инициализации ВГ75. Профессионально написанные игры имеют собственные подпрограммы для опроса клавиатуры, но подавляющее большиство обычных и псевдографических игр использует п/п-мму F81B. Чтобы избавиться от такой проблемы нужно как-то узнавать, что экран установлен не с адреса 76D0 (чтобы в этом случае не менять форму курсора). Чтение экранного адреса в ячейках 7602/03 тут не поможет, надо читать внутренние регистры ВГ75. Возможно придётся в директиву G ввести доп.параметр для запрета реинициализации ВГ75 по нажатию на клавишу <РУС/ЛАТ>, а в DOS ввести в каталоговую запись файла доп.флаг, что программа меняет режим ВГ75. Можно также ввести директиву Q, что будет отключать обслуживаниее индикации регистра клавиатуры. - - - Добавлено - - -Довёл число свободных байтов в ПЗУ РК86 аж до 273. И сделал версию с индикацией формой курсора включённого регистра клавиатура (как это принято на больших компьютерах). Скачать исходники и коды можно здесь.
|
01 Feb 2020 02:45 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
B эти выходные искал переходник с DIN на TRS, который 15 лет назад спаял. Но не нашёл. Придётся снова паять, так как без него не обойтись: Магнитофон - купленный на рынке голый механизм с усилителем Советского образца сорокалетней давности с дубовым надёжным механизмом (Все японские давно сдохли и жуют плёнки…) Обновил пост и прикрепил скриншоты, которые нарисовал по памяти. Может кому-нибудь что-то да напомнят… В выходные попробовал жарить каштаны, а они оказались горькими, как левомицетин. Как оказалось, это - конские и токсичные Пока нёбо скребло, как при ангине, задумался… Идея пришлаЧто за мода располагать ключевые точки входа в подпрограммы Монитора с самом начале? Их вполне можно было бы расположить в самом конце! И для программ на Бейсике было бы удобнее. Например: И это как раз заложено в самом начале данной темы… P.S.: Кстати, а почему Вы не дружите с машинным кодом? С моими резиновыми 16 Кб ассемблер или отладчик - были роскошью! Только дампом и программировал, не думая о мнемонике. А в игре «MARS-2» при объёме 0000…16FF столько нулей, что явно автор все подпрограммы дампом бил! Маш.код знать полезно как z80, так и i8086
|
03 Feb 2020 09:24 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
У меня вот тоже Яуза-220 с сендастовой головкой и японской механикой лет 15 проработала, а дальше стала жевать ленту. В кассетниках это происходит при чересчур сильной подмотке. Естественно, когда на приёмной бобине ещё мало ленты подмотка сильнее, а вот в самом конце стороны, когда почти вся лента уже на приёмной стороне и диаметр ленты на приёмном узле большой, - подмотка слабее. Несколько лет пользовался записывая только в конце кассет, потом и в конце стало жевать ленту. Так и лежит, и выкинуть жалко и пользы никакой. Проблема в том, что смазка между тормозными дисками высохла, отчего сцепление резко возросло. Чтобы исправить достаточно капнуть масла или вазелина между тормозными дисками, но уэел механики неразборный, никак не подлезть к дискам, не налить масла между ними. Похоже память у Вас хорошая. Три первые из четырёх картинок я видел ранее и игры эти у всех есть. Это Вы видимо про ORDOS для ОРИОНА начитались. Там входы в п/п-ммы растут от адреса C000 вниз с шагом 3, потому что в начале ORDOS стоит CCP ORDOS, которую затирает нортон для ORDOS. Вообще экономично функции вызывать по RST. А на бейсик всем плевать, т.к бейсик это вредительство. бейсик . Бейсики в компьютерах первой волны (1975-1978) применяли просто оттого, что вообще ничего другого не было и даже было невозможно в силу слабости железа. Но как только на микрокомпьютерах появились ассемблер, а затем ДОС и ЯВУ, то резидентный бейсик превратился в нонсенс, глупость.
Бейсик-интерпретатор это глупость, за что Кемени и Курцу надо давать не премию и прославлять, а объявить вредителями на десятилетия задержавшими компьютеризацию и отвратившим от программирования десятки миллионов людей.
Сказку, что бейсик-интерпретатор хоть на что-то годен, кроме первого знакомства с алгоритмами, раздули и эксплуатировали производители компьютеров. Т.к ничего другого не было, а нужно было хоть что-то показать типа "наш компьютер может что-то делать, кроме как мигать курсором и даже на что-то полезное пригоден".
На примере того же Синклера видно, что резидентный бейсик превратился в тормоз, в играх использовался лишь как загрузчик и набор некоторых подпрограмм, т.е служил в роли ROM-BIOS. В компьютерах с дисководом, например, Apple-II, бейсик хотя бы играл роль DOS (что кстати, тоже оказалось глупейшей идеей, причём её автор или Возняк или Джобс). Они дали задание создать именно такую концепцию разработчику Apple-DOS, хотя он и пытался в свою очередь убедить их, что это глупость. Что лишний раз доказывает, что бейсик ошибочно в 70-тые годы считался очень полезным и основным инструментом для микро-ЭВМ.
Когда же наконец разобрались, что бейсик-интерпретатор это вредная и бесполезная игрушка, время было упущено. Но ещё долго в литературе академики продолжали хвалить бейсик, а профессора продолжали учить и отвращать от программирования миллионы людей. Пока наконец этот беспредел не прекратили заменив бейсик в качестве учебного языка в школах и ВУЗ-ах сначала Паскалем, а сейчас и другими ЯВУ. . Потому что компилятор ассемблера избавляет от необходимости запоминать машинный язык в виде восьмиричных кодов или обкладываться справочными таблицами и на пару порядков повышает эффективность программиста. Странно, что приходится напоминать всем известное: в машинных кодах программировали лишь в самом начале 50-тых годов, пока не изобрели ассемблеры и об этом кошмаре не забыли навсегда. Даже при разработке для только что созданного микропроцессора в машинных кодах не программировали: до разработки родных ассемблеров использовали кросс-ассемблеры. Например, Билл Гейтс писал первую в мире программу для первого микрокомпьютера Альтаир-8800 транслируя кросс-ассемблером написанным Полом Аленом и прогоняемым на майн-фрейме PDP-10 гарвардского университета. Если бы он делал это в маш.кодах, то не успел бы написать бейсик за месяц. Кстати, т.к операнды задаются триадами битов, когда работают в маш.кодах восьмиричная система удобнее. Вот почему в книге Буреева и Дудко "Простейшая микро-ЭВМ на КР580" используют восьмиричную систему и во многих советских справочниках про КР580 система команд КР580 приведена в восьмиричной системе. Лучше не знать, т.к тогда возникает соблазн использовать модификацию кодов. Что является порочной и всеми осуждаемой практикой, которая очень затрудняет конверсию программ КР580 в 8086 и 6800, хотя без такого изврата конверсия делается за секунду. Для программистов на ассемблере не злоупотребляющих модификацией кода про машинные коды достаточно знать лишь количество байтов в командах (чтобы выбрать более скоростной или более экономичный по объёму вариант реализации алгоритма). А программистам на ЯВУ даже о самом существовании машинных кодов знать не требуется. Достаточно считать компилятор ЯВУ инструментом который с помощью волшебства формирует нечто волшебное (научно называемое выходным кодом), что будучи загруженным в компьютер заставляет его делать что-то полезное. Журнальные редактор+ассемблер сменой десятка байтов настраивались на ОЗУ 16К. При их размере в 4 кб с учетом экрана и раб.ячеек в 2.5 кб для текста и кода остаётся 9.5 кб. Штефановский отладчик слишком большой, а вот си-пи-эм-овский менее 4 кб. Для РК-программистов даже при наличии ОЗУ 32К очень окупался бы монтаж блока "редактор-ассеблер-отладчик" в ПЗУ 8 кб в области A000...BFFF (вместо запасного ППА D14), работающих прямо из ПЗУ (что увеличивает объём ОЗУ для исходного текста). И потому привыкнув к этому даже теперь не можете перейти к нормальным инструментам.
|
03 Feb 2020 11:18 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Почeму-то в архивах не нахожу Хорошо, что не дядя Кобол (Кабул акя)! Свой x80 я и слепил переорганизацией блоков команд из i8080/z80 в тетрады, так как всегда напрягало в уме хексы переводить в восьмиричку, когда бил/читал дампы… Пока эти дни сидел без интернета, за ночь взломал rkr-формат ассемблера и на HTML/JavaScript накидал редактор ассемблерных листингов с экспортом в rkr… Сам редактор «Ed.Mikron» файлы проглатывает и не ругается. Потому, я могу пользоваться теперь визуальными плюшками HTML и сохранять всё в rkr-файлы… Пришлось пару часиков визуально изучать фрагмент дампа с подпрограммой вывода на магнитофон и подключить интуицию, чтобы понять, где - контрольная сумма, а где - длина листинга. Сохранял парочку коротких файликов и сравнивал их дампы… Сегодня днём написал три подпрограммы: - Умножалку HL на A
- Делилку HL на A
- Вывод десятичного числа HL
- Вывод дампа десятичными числами
Подпрограммы активно используют стек и вместо циклического замыкания на метку просто помещают в стек стопку ссылок на участок подпрограммы. Сравнил производительность… - Стандартный дамп 0000…1FFF - 61 секунда
- Дамп 8-битных десятичных - 81 секунда
- Дамп 16-битных десятичных - 80 секунд
Оказывается в том же эмуляторе в Мониторе «Микро-80» дамп выводится не отдельными байтами, а словами + справа и текст помещается! Как я до этого не додумался‽ К тому же в Emu80 с SD-картой директивами «R,71»+«G» запускается оболочка Нортона. Пока интернета не было, много как наковырялся! К тому же, проверил режим 80×50 - он идеально умещается в диапазон 7000…7F9F и ячейки 7FA0…7FFF можно использовать под Мониторные… А чтобы не было проблем с регенерацией ОЗУ, знакогенератор нужно перенастроить даже не на 6×8, а 6×6. Я как-то проводил опыты и дампом бил ( не редактором) свой фонт укороченный. Правда, чем его искать, легче с нуля опять набить… (Я nes-файлы игр Денди так пытался руссифицировать. Одолел лишь «Battle City»). Кстати, тот же Emulator3000 ZX-Spectrum поддерживает: Отчего мою демку с дампом там не прогнали? Кстати…Если выводы A0/A1 микросхемы D14 перевести на A11/A12, то получим следующее: - A000…A7FF - канал «A»
- A800…AFFF - канал «B»
- B000…B7FF - канал «C»
- B800…BFFF - управляющий регистр
Как Вы предлагали, внешнее ПЗУ подключить ещё и к шине адреса процессора… Тем самым, в регионе A000…A7FF всегда будем иметь окно ПЗУ в 2 Кб, которое уже не нужно директивой «R» копировать в ОЗУ. А с каналами «B» и «C» получим уже 65536 страниц по 2 Кб ≈128 Мб! Но тут уже порт «A» ППА клавиатуры задействовать нельзя, иначе было бы уже 32 Гб! И о «Windows'86»! Планирую сделать своеобразную пародию технологии DirectX… В частности, зарезервировать в Мониторе подпрограммы, которые из-вне можно будет вызывать для получения указателей на экранную область и т.д… Об этом я задумывался ещё в 90-х, даже до знакомства с MS-DOS. Монитор имеет две функции чтения статуса экранной области: Чтение позиции курсора и чтение символа на экране под курсором. Мною планируется просто выделить несколько подпрограмм из «PUT_C»: Перемещение курсора и коррекция позиции. Вроде бы пустяк. Но с ними, в принципе, можно организовать переносимую динамичную обстановку! P.S.: В общем, работы много проделал… Мартышкиной! (В своей оконной подпрограмме выиграл ещё 4 байта!)
|
05 Feb 2020 11:24 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Раз уж упомянули редакторы, скажу, что тема текстовых редакторов для РК всё ещё актуальна (в отличие от ROM-BIOS-ов, т.е хороший текстов редактор нужен, а вот новый ROM-BIOS никем не востребован). Вам бы написать для тренировки в экономии кода (или хотя бы ради спортивного интереса) экранный текстовый редактор для РК86 размером в 2 кб. редакторы для РК86 . Эд_Микронов - два. Один журнальный из 1987 года, - полное убожество, даже не полноэкранный, а не пойми какой, очень неудобный (зато размером всего в 2 кб). И второй журнальный Эд_Микрон-2 из 1991 года размером аж в 4 кб. Который удобный и вполне приличный (с 1993 используют его версию для работы с дискетой RK-DOS).
Для РК актуален приличный текстов редактор размером не более 2-х килобайт. И такого редактора до сих нет. Есть только убогий Микрон-1, который никуда не годится. Кстати, до 1991 ничего другого из РК-редакторов вообще не было.
Потому Эд_Микрон-1 встраивали и в макроассемблер и в Паскаль и в Best-Си. Я с ними имел дело уже не на РК, а на Специалисте. И хотя для Специалиста сдуру адаптировали и убогий Микрон-1, но на Специалисте уже в 1988 был приличный полноэкранный редактор SCREEN размером тоже всего 2 кб. SCREEN мал, т.к по максимуму использовал п/п-ммы ПЗУ Специалиста. При адаптации SCREEN на ОРИОН, где нет в ПЗУ некоторых подпрограмм (и с добавкой чтения/записи файлов квазидиска из ОЗУ) размер разбух аж до 3 кб. И только выкинув МГ-функции, работу с квазидиском и Хелп, мне удалось упихать SCREEN для ОРИОНА в 2 кб. Это надо было для того, чтобы и на ОРИОНЕ использовать эр-кашные Паскаль, Си и макроассемблер (которым нужен текстов редактор именно размером до 2 кб, т.к все они работают с $800.
У меня есть исходник полноценного текстового редактора с блоками (без DOS и для RAMDOS), не хуже, чем Микрон-2, но у него размер даже более 4 кб. Написать текстов редактор размером в 2 кб сейчас я бы смог, но точно не получится компактнее, чем SCREEN. Проще адаптировать SCREEN для РК. Я уже адаптировал SCREEN в 90-тые и для ИРИШИ и для ОРИОНА. Дорабатывать немного, лишь переписать подпрограммы быстрого ролика экрана вверх и вниз (стеком). Я этим возможно займусь, но позднее, т.к РК86 меня вообще не интересует в силу отсутствия в нём графики. РК использую в эмуляторе лишь потому, что там есть поддержка и дисковода и эл.диска (а в эмуляции Специалиста пока только эл.диск), а для отладки без разницы встраивать директивы для обслуживания DOS и ROM-диска в монитор Специалиста или РК86. . Игры распространённые. Первая называется MARS2, вторая MARS3. Третья игра Saboteur немного не похожа на ваш рисунок, но ясно, что это она. Эти подпрограммы нужны всегда. У каждого они есть, но обычно их пишут тупо в лоб, чтобы не искать и самому особо не напрягаться. Скорость обычно не важна. А при использовании линкующего ассемблера проще использовать фрагменты написанные на ЯВУ, подпрограммы оформляются внешними процедурами на ЯВУ. Это экономит силы и время. Особенно, если нужна точность, т.е арифметика с плавающей точкой. Было бы интереснее, если бы с SD-карты грузилась и работала бы с ней как с приводом, - RK-DOS, CP/M или любая другая DOS, а так - это просто запускалка. Хотя для тех, кому надо только запускать, этого достаточно. 80 символов в строке на реале без замены кварца не получить. Нужен кварц 20 МГЦ вместо 16 МГЦ. Это будет уже другой компьютер несовместимый с РК86. Я не держу эмуляторов ZX-Spectrum, тем более не отечественных. Синклер меня бы интересовал, если бы в зоновскую плату как-нибудь несложно встроить режим 512*192 моно, добавив банку 565РУ6 (или статики). К сожалению, в 80-тые годы никто не слышал о клоне Timex с таким экраном и вместо такой простой доработки изобрели навороченные ATM и Профи. Сам я мечтал это сделать, но в железе слаб и не люблю сложные доработки МГТФ-ом. Хорошая идея, если код сможет работать прямо оттуда. Код в адресном пространстве ценнее, чем код перекачиваемый в ОЗУ. Возможно это ПЗУ придётся иметь скоростным (или немного тормозить одним тактом WAIT). Команды чтения портов часто тормозят одним тактом WAIT, в Z180/HD64180 есть даже возможность задавать на сколько тактов удлинять I/O операции. Это не впечатляющие темпы, я за то же время выиграл ~30 байтов, причём уже на ранее сильно уплющенном коде. Выяснилось, что эмулятор EMU80 не позволяет изменить адрес ППА ROM-диска. Приходится переходить на EMU. Сделал поддержку ROM-диска в мониторе РК86. Пока временно с директивой L (т.е ASCII не выводит, хотя код остался). Но из ROM-диска не надо грузить, а надо запускать. Теперь всё как в ОРИОНЕ - по ВК вывод каталога, по пробелу запуск. Но в отличие от ORDOS имя не требуется писать целиком (если не возникает неоднозначности). Например, если есть только один файл с именем на букву X, то для запуска достаточно ввести пробел, нажать клавишу X и затем ENTER.
|
05 Feb 2020 19:07 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Набросoк кода для вставки символа в строку прямо на экране (как в Бейсике Atari-XE) штатными подпрограммами Монитора занимает 220 байтов. Курсор активно бегает влево-вправо и всё подтормаживает при длинных строчках. Если же идти хаком и напрямую в буфере экрана работать - совместимость пострадает… Можно и в общем буфере хранить, как в Микроне. Возиться нужно… Хоть бери и в ПЗУ всё вычищай и реализуй! Вот не пойму, почему редакторы в начале памяти сидят? Приходилось всегда программы с 1100 копировать в 0000. Прямо хочется этот Микрон подкорректировать на 5000 хотя бы. Но я не знаю всех нюансов рабочей области… А где эти файлы в сети вообще? Некоторые паки имеют несколько игр, но при выборе всё вылетает или виснет. Почему же? На реальном РК я настраивал ВГ75/ВТ57 на экран 64×25. Растр хоть и был искажён позиционированием, но всё было устойчивым. Если верить онлайн описанию ВГ75, можно прикинуть: Тем самым, если знакогенератор сплющить, то вполне можно добиться устойчивого матраца… Правда в эмуляторах скроллинг такого экрана существенно тормозит. Потому и толку будет мало от такого режима для динамики. Только для статики… Эти байты я сразу же занял под параметры зуммера, чтобы они могли указываться в рабочих ячейках Монитора. Например, в 7607/7608…
|
05 Feb 2020 23:45 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
А зачем подпрограммами монитора? 64 символа строки на время её редактирования становятся строчным буфером. И для редактирования используется та же подпрограмма, в которой символы кладутся в буфер процессором командой LD (HL),A. На текстовой машине это одновременно и текст сохраняет и визуализирует. И вообще очень-очень странно, что на текстовой машине работа с текстом тормозит, вероятно у Вас применён очень неудачный алгоритм. Ведь при редактировании строки на графической машине не только редактируется буфер редактирования, но и выводятся символы в экран, что на графической машине в сто раз медленнее и то даже там абсолютно никаких тормозов при редактировании строки нет. А скорее всего дело в паршивом онлайн-эмуляторе, который искажает времянки. Эта идея даже выгодна с точки зрения экономии объёма кода. Отпадает копирование из текстового буфера в буфер редактирования, т.к вместо него используется экран, куда текст попадает при визуализации текущего окна редактирования. Но по уходу с отредактированной строки на соседнюю всё-равно надо строку нормализовывать (вставляя табуляции, где возможно и откидывая пробелы после последнего отображаемого символа), а затем копировать строку в текстовый буфер, соответственно раздвигая или сдвигая соседние строки, если новый размер строки изменился в большую или меньшую стороны. Вообще хороший текстов редактор для тормозной машины не так прост. Лучше сразу на 9000 или E000, модернизировав для работы в ПЗУ, чтобы не тратить ОЗУ. IDA в помощь. Но нет смысла связываться с Эд_Микрон-1. Зачем нужен редактор с изначально извратной идеологией. Надо написать нормальный редактор и это не так уж сложно. Если есть опыт в редакторах, то пишется за один день, если опыта нет, то за три дня. Есть тема "Игры для РК86" на ZX-PK.ru, там есть некоторые ссылки, а так гуглится "программы для РК86" и всё подряд закачивается и потом разбирается. Во вложении три игры. Полноценно эмулировать РК сложно, потому некоторые рабочие РК-игры в эмуляторе не работают или искажают картинку. Откуда возьмутся видимые 80 символов. Раз частота пиксель клока та же, то видимыми останутся те же 64-65 символов в строке. А вот если кварц заменить (чтобы общее число пикселей стало 640) и ССИ сделать аппаратным, то будут видны 80 символов. Этого в реале не может быть, т.к экран 64*50= всего 3200 байт. А даже тормозная ИРИША с эффективным тактом в 1 МГЦ сдвигает экран 16 кб за 0.25 секунды. У Вас неправильный эмулятор и неправильный алгоритм (стеком такой экран сдвинется за 0.1 сек, т.е мгновенно). Вредное псевдонаучное слово скролинг. Даже в английском языке это жаргон, а по русски это ролик экрана.
Last edited by barsik on 06 Feb 2020 15:01, edited 1 time in total.
|
06 Feb 2020 07:35 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
A как же кроссплатформенность‽ В 90-х я написал свой полудрайвер. По АР2+I/O экран грузился на ленту / с ленты. По АР2+1…3 менялась форма курсора. Строки раздвигались/схлопывались… Тогда я все накопленные знания там применил и на ленте у меня целые конспекты такими голыми экранами хранились и даже схемы… Прикрепил файл - изучайте (плесенью попахивает) Ага… Ещё в A000…A7FF! Спасибо! Они самые. Правда Saboteur несколько иной: Всё на английском, череп в заставке вместо взрыва, флаг на базе вместо атомного гриба и справа вертикальная полоса видимая… На своём УЛПЦТ том я так настраивал кадровую/строчную развёртки, что даже самые крайние символы видны были. Правда, сплющенные и завёрнутые, но видны были! Emu80 неправильный? Весь экран двигать в XXI веке‽ Дамп ПЗУ «Windows'86» есть - можете подглянуть на прокрутку ограниченной прямоугольником области: Она аккурат впритык к FE01.. Там скроллер не такой, как в оригинале с копированием (HL),(DE) в цикле. А адаптирован под любой размер окна и ширину видеостроки. Потому он подтормаживает. А режим 80×50 я именно на своём ПЗУ и тестировал, так как в других Мониторах дамп со скроллингом так просто в один взмах пальца не проверишь. Хотя, даже директивой «T4050 4FFF 4000» Монитора экран прокручивается на строку вверх довольно медленно! А к директиве «T» претензий быть не может! P.S.: Может понравится что-нибудь из моего собственного хлама: Танковое поле - мультик, Генератор комиксов, Befunge - 25 летP.P.S.: Обновил редактор…Написал более аккуратно и продуманнее. Всё равно тормоза сильные и ничто с этим не поделаешь. Строки раздвигать нужно в недрах самой подпрограммы печати символа. И, как Вы знаете, Escape-перехват я предусмотрел. Нужно лишь добавить процедуры. К тому же сам скроллер (FDD4…FE00) ограниченного прямоугольника устроен так, что прокручивать можно прямо над текущей позиции курсора (нужно лишь в ПЗУ добавить эту «Esc+0A» без принудительного смещения курсора (FECE…FDD3) вниз). Нужно прокрутку вниз написать значит (регистр BC с -78 переделать на +78) - то есть просто написать парочку команд и прыгнуть на адрес FDEC… Фрагмент Escape-драйвера Кстати… Спасибо! Теперь я в своей подпрограмме нашёл изъян: там «ADD A,B» стоит, хотя «ADD A,D» не меняет сути логики, но Escape-драйвер из-за этого дублирует все эти 7 команд! То есть в самом ПЗУ можно просто «JMP» где нужно поставить!
Last edited by Paguo-86PK on 06 Feb 2020 17:00, edited 1 time in total.
|
06 Feb 2020 11:02 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Кроме РК-подобных остальные бытовые машинки графические, нетекстовые (сделанные в трёх экземплярах Микро-80 и ЮТ88 нельзя считать платформами). А для графической машины даже говорить о редактировании текста в самом экране бессмысленно. Да и кого волнует совместимость с другими платформами, когда даже от самых массовых платформ с сотнями тысяч машин едва осталось несколько десятков машин, да и на программы для них большинству их владельцев плевать. Если от идеи редактирования строки прямо в экране машины с текстовым адаптером пойти ещё дальше, то приходим к идее редактирования буфера размером сразу в 25 строк, т.е всего экрана. С таким подходом можно даже уместить текстовый редактор всего в 1 кб (хотя потребность - уместиться лишь в 2 кб). По сути это редактор экрана, к которому добавляются две процедуры - загрузки в экран, начиная со строки номер такой-то, и запись 25-ти строк на исходное место. Это будет проще и по объёму кода меньше, но немного тормознее, чем когда (с раздвижкой/сдвижкой) в тексте обновляется всего одна строка. Именно так и делается ролик экрана (если только нет рулона, - аппаратного задания номера первой строки, что обеспечивает мгновенный ролик, как сделано в БК-010 и Океан-240). Ещё раз подчеркну: ролик даже в медленной, но текстовой машине - почти мгновенный и проблем с ним из-за скорости не может быть. И я даже могу это неопровержимо доказать используя свои знания арифметики. Для сдвижки 64*50= 3200 байтов, ролик делается 50-ю сдвигами кусков по 64 байта. Это занимает 131457 машинных тактов. Допустим эффективный такт при 50-ти строках 1 МГЦ, период маш.такта - 1 МКС. Итого ролик делается за 0.132 секунды. А экран в 25 строк роликуется всего за 0.066 секунды. Ролик стеком будет ещё на 25% быстрее. Это убедительно доказывает, что никаких скоростных проблем для ролика в РК86 нет. Кстати, если двигать экран командой LDIR, что в РК невыгодно, т.к тогда из-за наличия в РК программного бордюра слева и справа от видимой части экрана надо двигать бОльший массив, - уже не 3200 байт, а 78*50= 3900 байт. LDIR тратит 21 такт на байт и при периоде маш.такта в 1 МКС на сдвиг уйдет 1*21*3900 байт = 0.081 секунды. А экран в 25 строк командой LDIR роликуется всего за 0.04 секунды. Т.е при Z80 даже базовой скорости хватит на просмотр видео с разрешением 128*50 с частотой 25 кадров в секунду. Правда при столь высоком битрейте всей памяти РК в 32К хватит всего на 0.8 секунды такого видео. У КР580 команды LDIR нет и её для КР580 в ПЗУ РК заменяют вот такой кучкой команд: при которой на байт тратится уже 50 тактов. Что более, чем вдвое тормознее, чем у Z80. Ролик 50-ти строк при этом занимает уже 0.195 секунды. Именно так неоптимально по скорости, но экономично по байтам, и сделан ролик в ПЗУ РК86. 25 строк сдвигаются за ~0.1 секунды. Это почти мгновенно. А при необходимости ролик можно ускорить вдвое, но разницу удастся заметить только, если сделать не однократный ролик, а непрерывный. Демо с танчиками и выстрелами не оставляет сомнений в том, что добавив в это Демо ещё немного труда можно из этого сделать вполне играбельный вариант стрелялки типа "Commando" или "Ikari". А просмотр Демо на 50 строк требует специального фонта, где посимвольный шаг в 6 байт, а в эмуляторах по умолчанию стоит фонт с шагом 8 байт. Картинка получается такой.
Last edited by barsik on 07 Feb 2020 01:55, edited 1 time in total.
|
06 Feb 2020 16:57 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Попробовaть, конечно, всё можно. Даже ради интереса Вся эта затея именно ради оконности, так как давно хотел проверить. Потому и прокрутку я делаю именно окна, а не всего экрана Если заметили, все поля - интерактивные: Если в них что-то изменить, через пару секунд анимация перезапустится. Именно так я и накидал эту сценку… У меня та же картинка Причём, на реальном РК была почти такая же. Но вот, если почти вслепую набрать «D0,1FFF», то тормоза будут очевидными… Кстати, сейчас прикрепил нестабильную версию Монитора и файл с демкой. Скролл работает от позиции курсора в обе стороны: - «Esc+Вверх» (1B 19) - прокрутка вверх
- «Esc+Вниз» (1B 1A) - прокрутка вниз
- «Esc+Стр» (1B 1F) - очистка окна
- «Esc+Символ» (1B 20…7F) - эскейп-драйвер/заглушка
Во-первых, чтобы уместить код, пришлось его полностью переписать и прибегнуть к вызовам процедур. Из-за чего он стал заметно тормозить. Во-вторых, стабильность нарушилась: Если набрать неверную комбинацию, прокрутка будет непредсказуемой. Из-за чего данная версия Монитора опасна для некоторых игр… Более быстрый код прокрутки вылез за свои пределы и очень сильно сбоил. Видимо, нужно серьёзнее им заняться и перепродумать. P.S.: Таким усердием я добился малого, но ценой головной боли и пониженного давления… Нужно хотя бы недельку отдохнуть от всего этого…
|
06 Feb 2020 23:31 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Переписaл практически 45% всего кода Монитора. Все директивы на месте, но кое-что изменил: - Вызов адреса F836 передаёт управление обработчику ошибки ввода/вывода
- Директива «B» как расширение «R0,7F,0» грузит загрузчик с внешнего ROM-диска
- Директива «D» выдаёт дамп вместе с текстом
- Директива «E» передаёт управление на адрес E000
- Директива «G» работает как CALL и второй параметр указывает так же точку останова, но без порчи ячеек 0030…0032
- Директива «L» исключена
- Директива «M» выводит данные строчкой до восьми байтов
- Директива «X» не отображает указатель «PC»
- Печать символа теперь ограничивается не абсолютной пограничной координатой, а размером
- Комбинация «АР2+ПС» прокручивает область над курсором, а «АР2+СТР» очищает текущее окно
- Код 07 воспроизводит теперь любую тональность
Рабочие ячейки Монитора: - 7607:7608 - Длительность и высота «звонка» по коду 07
- 7610:7611 - Координаты окна (Left:Top) <стандартно 8:3>
- 7612:7613 - Размеры окна (Width:Height) <стандартно 63:24> (раньше был крайний угол 71:27)
- 7620:7621 - Пользовательский драйвер Esc-комбинаций
- 7622 - Размер экранной строки <стандартно 78> (используется выводом символа и прокруткой окна)
- 76CD:76CE - Адрес обработчика ошибки ввода/вывода <стандартно F86C>
Пришлось слегка изменить логику некоторых подпрограмм. Так, при вводе строки нажатие «ВК» совершает возврат без печати этого символа. Это позволило директиве «M» выводить цепочку байтов строкой, а при запуске «G»-директивой курсор остаётся на месте. Тем самым, сохранив весь привычный функционал, удалось чуточку модернизировать Монитор. А значит, кому не нужно, может высвободить ячейки FF72…FFFF (142 байта), добавляя свой функционал… Подчёркиваю: Моя версия Монитора имеет весь привычный функционал, но с некоторыми плюшками. P.S.: Как я не додумался в 90-х директивой «X» изменить SP на 76CD: После этого «G» работает не как JMP, а как CALL Внимание!Прошлый код содержал досадную ошибку: Директива «R» содержала «LD (08001H),HL» вместо «LD (0A001H),HL» и делала невозможным работать с ROM-диском! Рекомендую перекачать файл…
|
10 Feb 2020 16:29 |
|
|
barsik
Doomed
Joined: 19 Feb 2017 03:46 Posts: 583 Location: Санкт-Петербург, Россия, третья планета от Солнца, галактика Млечный Путь
|
Т.к исходника не было выложено, то из корыстных целей (с целью заимствования каких-либо идей по уплющиванию) дизассемблировал файл " okoshki.zip" и привёл полученный текст в читабельный и транслируемый вид. Используя этот исходник автор может продолжить дальнейшие модификации уже в текстовом редакторе, что намного удобнее, чем в отладчике. Этот исходник мало оптимизирован, в нём легко с'экономить ещё многие десятки байтов, из чего сразу ясно, что неэффективно программировать в отладчике. В результате трансляции, можно узнать какие стандартные внутренние входные точки сдвинуты. Кстати, константа чтения в данном алгоритме МГ-записи всегда ровно в 1.5 раза больше, чем константа записи, а в этом коде обе МГ-константы от балды. В реале читаться не будет, да и в эмуляторе при вводе WAV-файлов - тоже. Директива X не нужна. Если нет встроенного мини-ассемблера и мини-дизассемблера, какой смысл в директиве X? С середины 80-тых годов уже даже в нашей стране никто не программирует в машинных кодах, потому директивы X/G абсолютно впустую отнимают ~90 байтов. Как директива G со стоп точкой может работать по CALL? Она должна работать по сохранённым регистрам. Так что фраза " изменить SP на 76CD... после чего «G» работает... как CALL" не только непонятна, но и бессмысленна. По поводу кода РК ПЗУ. Подпрограмма COUT_A в ПЗУ РК портит регистр C. Это большой недостаток. Авторы РК для борьбы с ним используют вход в середину подпрограмм, где стек не выровнен. Делается PUSH BC и уход в подпрограмму, где до того также сделан PUSH BC. Это непрофессиональный и вредный стиль программирования. Для борьбы с такой практикой в ассемблерах 8086 даже придумали оформлять подпрограммы словом procedure, потому там никто не делает вход на внутренние точки процедур. А для 8-ми разрядок программы непрофессиональных программистов отличаются именно таким наглым обращением со стеком. Выигрыш нескольких байтов за счёт надругательства над стеком запутывает код и это чревато ошибками в ходе развития программ и сопровождения. Кстати, ещё 50 лет назад против запутывания кода JMP-ами выступал Э.Дейкстра в своей известной статье против оператора GOTO. С учётом того, что п/п-мма HEX_A в данном коде неэффективная (на целых 3 байта длиннее, чем моя), то при переделке COUT_A в SCOUTA число байтов увеличивается незначительно. Кстати, имя SCOUTA это акроним от фразы: Saved registers Console OUTput from A. Вот (не самый удачный) пример, что делают авторы РК: Эта и другие процедуры монитора короче, когда COUT_A чуть изменена, не портит BC и некорректных входов нет: | | | | Code: ; Дизассемблированное ПЗУ из файла "okoshki.zip" (с вышеупомянутым исправлением в DIR_R):
.Z80 aseg ORG 100H
RABADR EQU 0F800H DOPPPA EQU 0A000H
BASE EQU 7600H ; выше D0H байтов - служебные ячейки
EK_ADR EQU BASE ; текущий адрес на экране POSX EQU BASE+02H POSY EQU BASE+03H ESC_F EQU BASE+04H KBDFLG EQU BASE+05H ; если =0, то есть символ в SYMBUF RUSLAT EQU BASE+06H ; допустимо только 0 или FF CBEEP EQU BASE+07H LAST_K EQU BASE+09H ; эти 2 байта должны следовать подряд COUNT EQU BASE+0AH ; счётчик опросов (вначале 15) APVFLG EQU BASE+0BH ; флаг автоповтора FRELOC EQU BASE+0CH ; эта ячейка не используется
TMPSTK EQU BASE+0DH ; временно храним стек при МГ п/п-ммах WINKOO EQU BASE+10H ; Левый верхний угол окна DH EQU BASE+12H ; ширина окна -1 DV EQU BASE+13H ; высота окна -1 POINT EQU BASE+14H ; адрес откуда произошёл RST_30H R_HL EQU BASE+16H R_BC EQU BASE+18H R_SP EQU BASE+1CH R_AF EQU BASE+1EH ; ниже откладываются AF,HL,DE,BC ABREAK EQU BASE+20H LNSTEP EQU BASE+22H STOP_A EQU BASE+23H TMP_COD EQU BASE+25H P_JMP EQU BASE+26H ; для байта C3H (JMP) PAR_HL EQU BASE+27H PAR_DE EQU BASE+29H PAR_BC EQU BASE+2BH FLG_P2 EQU BASE+2DH ; флаг, что есть параметры 2 или 2,3 INV_MG EQU BASE+2EH KNS_RD EQU BASE+2FH KNS_WR EQU BASE+30H RAMTOP EQU BASE+31H COMBUF EQU BASE+33H ; буфер ввода директивы STACK EQU BASE+0CFH ; стек монитора
SA EQU 76D0H ; 76D0 начало экранной области SCBASE EQU 77C2H ; 77C2 ЛЕВ.ВЕРХН.УГОЛ ЭКР.
VG_75 EQU 0C000H VT_57 EQU 0E000H RKDOS EQU 0E000H XROM EQU 0F000H
PA EQU 8000H PB EQU PA+1 PC EQU PA+2 PU EQU PA+3
PDA EQU DOPPPA PDB EQU PDA+1 PDC EQU PDA+2 PDU EQU PDA+3
; ----------------------------------------------
.phase 0F800H
JP START JP CONIN JP LDBYTE JP COUT_C JP WRBYTE JP COUT_C JP STATUS JP HEX_A JP MSGH JP XF81B JP ASKCUR JP RD_SCR JP RD_BLK JP WR_BLK JP CHSUMM JP PUSK_VG ASKTOP: LD HL,(RAMTOP) JP SETTOP ABORT: LD HL,(BASE+0CDH) JP (HL)
; ----------------------------------------------
START: LD HL,PU LD (HL),8AH AF83F: DEC HL LD (HL),0 LD A,H CP 75H JP NZ,AF83F LD (RAMTOP),HL LD HL,221DH ; 1D2AH LD (KNS_RD),HL LD HL,P_JMP LD (HL),0C3H
LD HL,(WARMST+1) ; STACK LD (R_SP),HL LD SP,HL
LD HL,TITR CALL MSGH CALL PUSK_VG LD HL,5F0H LD (CBEEP),HL if $ ne RABADR + 06CH if1 .printx * Standard subroutine WARMST shifted ! * endif endif
WARMST: LD SP,STACK
CALL RST_18 defb 13,10,':','>'+80H LD HL,XORA LD (ABREAK),HL LD HL,WARMST PUSH HL CALL GETLIN LD A,(COMBUF) SBC A,'A'-1 LD C,A LD A,92H LD HL,0CB1DH LD DE,MASKA AF891: INC DE INC DE AF893: ADD HL,HL ADC A,A JP Z,XROM DEC C JP C,AF893 JP NZ,AF891 EX DE,HL LD E,(HL) INC HL LD D,(HL) PUSH DE CALL GETPRM LD A,L LD HL,(PAR_BC) LD C,L LD B,H LD HL,(PAR_DE) EX DE,HL LD HL,(PAR_HL) RET
; ----------------------------------------------
TITR: defb 1Fh,'oko{e~ki-86rk '
MASKA: DW 1010100100111010B
TABLE: DW DIR_C DW DIR_D DW DIR_F DW DIR_G DW DIR_I DW RKDOS DW DIR_M DW DIR_O DW DIR_R DW DIR_S DW DIR_T DW DIR_X
; ----------------------------------------------
ZABOJ: OR H JP P,GTLLO2 DEC H DEC L DEC DE CALL RST_18 defb 8,32,8+80H JP GTLLO2
; ----------------------------------------------
if $ ne RABADR + 0EEH if1 .printx * Internal subroutine GETLIN shifted ! * endif endif
GETLIN: LD HL,3FF0H GTLLO1: LD DE,COMBUF ADD HL,HL RET Z GTLLO2: CALL CONIN CP '.' JP Z,ABORT CP 8 JP Z,ZABOJ CP 7FH JP Z,ZABOJ LD (DE),A CP 13 CALL NZ,COUT_A JP Z,GTLLO1 INC H INC L JP Z,ERROR INC DE JP GTLLO2
; ----------------------------------------------
RST_18: EX (SP),HL CALL MSGH INC HL EX (SP),HL RET
; ----------------------------------------------
MSGLOO: INC HL MSGH: LD A,(HL) OR A RET Z CALL COUT_A RET M JP MSGLOO
; ----------------------------------------------
if $ ne RABADR + 012CH if1 .printx * Internal subroutine GETPRM shifted ! * endif endif
GETPRM: LD HL,PAR_HL LD DE,FLG_P2 LD C,0 CALL DIR_F LD DE,BASE+34H CALL GET_HL LD (PAR_HL),HL LD (PAR_DE),HL RET C LD A,0FFH LD (FLG_P2),A CALL GET_HL LD (PAR_DE),HL RET C CALL GET_HL LD (PAR_BC),HL RET C NOP NOP NOP GET_HL: LD HL,0 LD BC,ERROR AF960: LD A,(DE) INC DE CP 13 SCF RET Z CP ',' RET Z CP 20H JP Z,AF960 PUSH BC SUB 30H RET M CP 10 JP M,JJJ_01 CP 11H RET M CP 17H RET P SUB 7 JJJ_01: ADD HL,HL ADD HL,HL ADD HL,HL ADD HL,HL ADD A,L LD L,A POP BC JP AF960
; ----------------------------------------------
SETTOP: LD (RAMTOP),HL RET
; ----------------------------------------------
LD A,H CP D RET C
if $ ne RABADR + 0190H if1 .printx * Internal subroutine CMPDH shifted ! * endif endif
CMPDH: LD A,H CP D RET NZ LD A,L CP E RET
; ----------------------------------------------
AF996: CALL AF9A1 AF999: CALL CMPDH INC HL RET NZ DEC HL POPAF: POP AF RET
; ----------------------------------------------
AF9A1: CALL XF81B AF9A4: CP 27 RET NZ CALL PUSK_VG JP ERROR
; ----------------------------------------------
if $ ne RABADR + 01B0H if1 .printx * Internal subroutine RIGHT4 shifted ! * endif endif
RIGHT4: CALL RST_18 defb 13,10,18h,18h,18h +128 RET
; ----------------------------------------------
LDXHX@: LD A,(HL) HEXABL: PUSH BC @HEXA@: CALL HEX_A LD C,20H CALL COUT_C POP BC RET
; ----------------------------------------------
DIR_D: CALL Z,CHXHL@ PUSH HL AF9C6: CALL LDXHX@ INC HL LD A,L AND 3 LD C,8 CALL NZ,COUT_C LD A,L AND 0FH JP NZ,AF9C6 POP HL AF9D9: LD A,(HL) LD C,A SUB 20H CP 60H JP C,AF9E4 LD C,'.' AF9E4: CALL COUT_C CALL AF996 LD A,L AND 0FH JP NZ,AF9D9 JP DIR_D
; ----------------------------------------------
DIR_C: LD A,(BC) CP (HL) JP Z,AFA02 CALL CHXHL@ CALL LDXHX@ LD A,(BC) CALL HEXABL AFA02: INC BC CALL AF996 JP DIR_C
; ----------------------------------------------
DIR_F: LD (HL),C CALL AF999 JP DIR_F
; ----------------------------------------------
DIR_S: LD A,C CP (HL) CALL Z,CHXHL@ CALL AF996 JP DIR_S
; ----------------------------------------------
DIR_T: LD A,(HL) LD (BC),A INC BC CALL CMPDH JP DIR_T
; ----------------------------------------------
DIR_M: CALL Z,CHXHL@ CALL LDXHX@ PUSH HL CALL GETLIN POP HL JP NC,AFA3E LD C,';' CALL COUT_C PUSH HL CALL GET_HL LD A,L POP HL LD (HL),A AFA3E: INC HL LD A,L AND 7 JP DIR_M
; ----------------------------------------------
AFA45: PUSH BC SBC A,A LD B,A LD A,(LNSTEP) XOR B SUB B LD C,A ADD HL,BC LD A,B SCF ADC A,A ADD A,D LD D,A POP BC RET
; ----------------------------------------------
AFA56: DEC L LD HL,(EK_ADR) JP Z,AFA6B JP PO,AFD9D JP P,AFDAB CP 27 JP NZ,AFCEF LD A,1 RET
; ----------------------------------------------
AFA6B: CP 1FH JP Z,AFD80 CP 10 JP NZ,AFDB7 SCF CALL AFDD5 XORA: XOR A ; CY=0 RET
; ----------------------------------------------
ASKCUR: LD HL,(POSX) RET
; ----------------------------------------------
RD_SCR: PUSH HL LD HL,(EK_ADR) LD A,(HL) POP HL RET
; ----------------------------------------------
DIR_I: LD A,(FLG_P2) OR A JP Z,AFA91 LD A,E LD (KNS_RD),A AFA91: CALL RD_BLK CALL CHXHL@ EX DE,HL CALL CHXHL@ EX DE,HL PUSH BC CALL CHSUMM LD H,B LD L,C CALL CHXHL@ POP DE CALL CMPDH RET Z EX DE,HL CALL CHXHL@ ERROR: CALL RST_18 defb 7,'?'+128 JP ABORT
; ----------------------------------------------
RD_BLK: LD A,255 CALL LD_BC PUSH HL ADD HL,BC EX DE,HL CALL LDBCBS POP HL ADD HL,BC EX DE,HL PUSH HL CALL AFB0A LD A,255 CALL LD_BC POP HL
if $ ne RABADR + 02CEH ; FACE if1 .printx * Internal subroutine PUSK_VG shifted ! * endif endif
PUSK_VG: PUSH HL LD HL,VG_75+1 LD (HL),0 DEC HL LD (HL),4DH LD (HL),1DH LD (HL),99H LD (HL),93H INC HL LD (HL),27H LD A,(HL)
AFAE1: LD A,(HL) AND 20H JP Z,AFAE1 LD HL,VT_57+8 LD (HL),80H LD L,4 LD (HL),0D0H LD (HL),76H INC L LD (HL),23H LD (HL),49H LD L,8 LD (HL),0A4H POP HL RET
; ----------------------------------------------
LDBCBS: LD A,8 LD_BC: CALL LDBYTE LD B,A LD A,8 CALL LDBYTE LD C,A RET
; ----------------------------------------------
AFB0A: LD A,8 CALL LDBYTE LD (HL),A CALL AF999 JP AFB0A
; ----------------------------------------------
CHSUMM: LD BC,0 CHSLOO: LD A,(HL) ADD A,C LD C,A PUSH AF CALL CMPDH JP Z,POPAF POP AF LD A,B ADC A,(HL) LD B,A CALL AF999 JP CHSLOO
; ----------------------------------------------
DIR_O: LD A,C OR A JP Z,AFB35 ; если не указано константы LD (KNS_WR),A AFB35: PUSH HL CALL CHSUMM POP HL CALL CHXHL@ EX DE,HL CALL CHXHL@ EX DE,HL PUSH HL LD H,B LD L,C CALL CHXHL@ POP HL WR_BLK: PUSH BC LD BC,0 AFB4D: CALL WRBYTE DEC B EX (SP),HL EX (SP),HL JP NZ,AFB4D LD C,0E6H CALL WRBYTE CALL WR_HL EX DE,HL CALL WR_HL EX DE,HL CALL AFB86 LD HL,0 CALL WR_HL LD C,0E6H CALL WRBYTE POP HL CALL WR_HL JP PUSK_VG
; ----------------------------------------------
if $ ne RABADR + 0378H if1 .printx * Internal subroutine CHXHL@ shifted ! * endif endif
CHXHL@: PUSH BC ; <ВК>, HEX_HL, SPACE CALL RIGHT4 LD A,H CALL HEX_A LD A,L JP @HEXA@
; ----------------------------------------------
DS 2
; ----------------------------------------------
AFB86: LD C,(HL) CALL WRBYTE CALL AF999 JP AFB86
; ----------------------------------------------
WR_HL: LD C,H CALL WRBYTE LD C,L JP WRBYTE
; ----------------------------------------------
if $ ne RABADR + 0398H if1 .printx * LDBYTE for emulator B2M need be at FB98 ! * endif endif
LDBYTE: PUSH HL PUSH BC PUSH DE LD D,A AFB9C: LD A,80H LD (VT_57+8),A LD HL,0 ADD HL,SP LD SP,0 LD (TMPSTK),HL LD C,0 LD A,(PC) RRCA RRCA RRCA RRCA AND 1 LD E,A AFBB7: POP AF LD A,C AND 7FH RLCA LD C,A LD H,0 AFBBF: DEC H JP Z,AFC34 POP AF LD A,(PC) RRCA RRCA RRCA RRCA AND 1 CP E JP Z,AFBBF OR C LD C,A DEC D LD A,(KNS_RD) JP NZ,AFBDC SUB 12H AFBDC: LD B,A AFBDD: POP AF DEC B JP NZ,AFBDD INC D LD A,(PC) RRCA RRCA RRCA RRCA AND 1 LD E,A LD A,D OR A JP P,AFC0B LD A,C CP 0E6H JP NZ,AFBFF XOR A LD (INV_MG),A JP AFC09
; ----------------------------------------------
AFBFF: CP 19H JP NZ,AFBB7 LD A,0FFH LD (INV_MG),A AFC09: LD D,9 AFC0B: DEC D JP NZ,AFBB7 LD HL,VT_57+4 LD (HL),0D0H LD (HL),76H INC HL LD (HL),23H LD (HL),49H LD A,27H LD (VG_75+1),A LD A,0E0H LD (VG_75+1),A LD L,8 LD (HL),0A4H LD HL,(TMPSTK) LD SP,HL LD A,(INV_MG) XOR C JP POPDBH
; ----------------------------------------------
AFC34: LD HL,(TMPSTK) LD SP,HL CALL PUSK_VG LD A,D OR A JP P,ERROR CALL AF9A4 JP AFB9C
; ----------------------------------------------
if $ ne RABADR + 0446H if1 .printx * WRBYTE for emulator B2M need be at FC46 ! * endif endif
WRBYTE: PUSH HL PUSH BC PUSH DE PUSH AF LD A,80H LD (VT_57+8),A LD HL,0 ADD HL,SP LD SP,0 LD D,8 AFC58: POP AF LD A,C RLCA LD C,A LD A,1 XOR C LD (PC),A LD A,(KNS_WR) LD B,A AFC66: POP AF DEC B JP NZ,AFC66 LD A,0 XOR C LD (PC),A DEC D LD A,(KNS_WR) JP NZ,AFC7A SUB 14 AFC7A: LD B,A AFC7B: POP AF DEC B JP NZ,AFC7B INC D DEC D JP NZ,AFC58 LD SP,HL LD HL,VT_57+4 LD (HL),0D0H LD (HL),76H INC HL LD (HL),23H LD (HL),49H LD A,27H LD (VG_75+1),A LD A,0E0H LD (VG_75+1),A LD L,8 LD (HL),0A4H POP AF POPDBH: POP DE POP BC POP HL RET
if $-1 ne 0FCA4H if1 .printx * Internal point 0FCA4H (need for emulator B2M) shifted ! * endif endif
; ----------------------------------------------
HEX_A: PUSH AF RRCA RRCA RRCA RRCA CALL NIBBLE POP AF NIBBLE: AND 0FH CP 10 JP M,JJJ_02 ADD A,7 JJJ_02: ADD A,30H
COUT_A: LD C,A COUT_C: PUSH HL PUSH BC PUSH DE PUSH AF CALL STATUS LD A,C AND 7FH LD HL,(WINKOO) EX DE,HL LD HL,(DH) ADD HL,DE LD B,H LD C,L LD HL,(POSX) EX DE,HL LD HL,(ESC_F) CALL AFA56 LD (ESC_F),A LD (EK_ADR),HL LD HL,VG_75+1 LD (HL),80H DEC L LD (HL),E LD (HL),D EX DE,HL LD (POSX),HL POP AF POP DE POP BC POP HL RET
; ----------------------------------------------
AFCEF: CP 8 EX (SP),HL INC HL INC HL INC HL EX (SP),HL JP Z,COD_08 CP 18H JP Z,COD_18 CP 1AH JP Z,COD_1A CP 19H JP Z,COD_19 CP 1FH JP Z,CLS CP 0CH JP Z,HOME CP 13 JP Z,COD_0D CP 10 JP Z,COD_0A CP 7 JP NZ,AFDC6 PUSH HL LD HL,(CBEEP) EX (SP),HL POP BC BEEP: LD A,B BP1: EI DEC A JP NZ,BP1 LD A,B BP2: DI DEC A JP NZ,BP2 DEC C JP NZ,BEEP RET
; ----------------------------------------------
COD_18: INC HL LD A,E INC E CP C RET C CALL COD_0D COD_1A: CALL AFA45 DEC A CP B RET C AFD46: LD A,(WINKOO+1) CP D RET NC CALL AFA45 JP AFD46
; ----------------------------------------------
AFD51: INC HL INC E LD A,E CP C JP NZ,AFD51 COD_19: LD A,(WINKOO+1) CP D JP C,AFA45 AFD5F: CALL AFA45 CP B CCF JP NC,AFD5F RET
; ----------------------------------------------
CLS: LD A,78 LD (LNSTEP),A LD HL,308H LD (WINKOO),HL EX DE,HL LD HL,183FH LD (DH),HL ADD HL,DE LD B,H LD C,L LD HL,SCBASE AFD80: CALL HOME AFD83: XOR A CALL AFDC6 LD A,D CP B SBC A,A OR C SUB E JP NZ,AFD83 LD (HL),A HOME: CALL AFD46 COD_0D: LD A,(WINKOO) SUB E RET Z DEC E DEC HL JP COD_0D
; ----------------------------------------------
AFD9D: SUB 1CH AFD9F: CP 4 RET Z PUSH AF CALL NC,COD_1A POP AF DEC A JP AFD9F
; ----------------------------------------------
AFDAB: SUB 1FH AFDAD: DEC A RET Z PUSH AF CALL COD_18 POP AF JP AFDAD
; ----------------------------------------------
AFDB7: PUSH HL LD HL,(ABREAK) EX (SP),HL CP 'Y' RET NZ POP AF CALL HOME LD A,2 RET
; ----------------------------------------------
AFDC6: LD (HL),A INC HL LD A,E INC E CP C RET C CALL COD_0D COD_0A: LD A,B DEC A CP D JP NC,AFA45 AFDD5: PUSH DE PUSH HL SBC A,A LD B,A LD A,(WINKOO+1) XOR B SBC A,B ADD A,D INC D LD D,A CALL COD_0D LD A,C SUB E LD E,A LD A,(LNSTEP) XOR B SBC A,B LD C,A AFDED: PUSH DE PUSH HL XOR A AFDF0: LD E,(HL) LD (HL),A ADD HL,BC LD A,E DEC D JP P,AFDF0 POP HL POP DE INC HL DEC E JP P,AFDED POP HL POP DE STATUS: LD A,(PC) AND 80H JP Z,AFE0E LD A,(KBDFLG) OR A RET NZ AFE0E: PUSH HL LD HL,(LAST_K) CALL XF81B CP L LD L,A JP Z,AFE2A AFE1A: LD A,1 LD (APVFLG),A LD H,15H AFE21: XOR A AFE22: LD (LAST_K),HL POP HL LD (KBDFLG),A RET
; ----------------------------------------------
AFE2A: DEC H JP NZ,AFE21 INC A JP Z,AFE22 INC A JP Z,AFE51 PUSH BC LD BC,5003H CALL BEEP POP BC LD A,(APVFLG) LD H,0E0H DEC A LD (APVFLG),A JP Z,AFE4C LD H,40H AFE4C: LD A,0FFH JP AFE22
; ----------------------------------------------
AFE51: LD A,(PC) AND 80H JP Z,AFE51 LD A,(RUSLAT) CPL LD (RUSLAT),A JP AFE1A
; ----------------------------------------------
if $ ne 0FE63H if1 .printx * Internal point FE63 (need for emulator emu80) shifted ! * endif endif
CONIN: CALL STATUS OR A JP Z,CONIN XOR A LD (KBDFLG),A LD A,(LAST_K) RET
; ----------------------------------------------
XF81B: LD A,(PC) AND 80H JP NZ,AFE7D LD A,0FEH RET
; ----------------------------------------------
AFE7D: XOR A LD (PA),A LD (PC),A ; ненужное и вредное LD A,(RUSLAT) AND 1 OR 6 LD (PU),A LD A,(PB) INC A JP NZ,AFE97 DEC A RET
; ----------------------------------------------
AFE97: PUSH HL LD L,1 LD H,7 AFE9C: LD A,L RRCA LD L,A CPL LD (PA),A LD A,(PB) CPL OR A JP NZ,AFEB3 DEC H JP P,AFE9C AFEAF: LD A,0FFH POP HL RET
; ----------------------------------------------
AFEB3: LD L,20H AFEB5: LD A,(PB) CPL OR A JP Z,AFEAF DEC L JP NZ,AFEB5 LD L,8 AFEC3: DEC L RLCA JP NC,AFEC3 LD A,H LD H,L LD L,A CP 1 JP Z,AFEFA JP C,AFEF3 RLCA RLCA RLCA ADD A,20H OR H CP 5FH JP NZ,AFF06 LD A,20H POP HL RET
; ----------------------------------------------
TABK1: defb 9,0AH,0DH,7FH,8,19H,18H,1AH TABK2: defb 0CH,1FH,1BH,0,1,2,3,4,5
; ----------------------------------------------
AFEF3: LD A,H LD HL,TABK2 JP AFEFE
; ----------------------------------------------
AFEFA: LD A,H LD HL,TABK1 AFEFE: ADD A,L LD L,A LD A,(HL) CP 40H POP HL RET C PUSH HL AFF06: LD L,A LD A,(PC) LD H,A AND 40H JP NZ,AFF1A LD A,L CP 40H JP M,AFF3F AND 1FH POP HL RET
; ----------------------------------------------
AFF1A: LD A,(RUSLAT) OR A JP Z,AFF2A LD A,L CP 40H JP M,AFF2A OR 20H LD L,A AFF2A: LD A,H AND 20H JP NZ,AFF3F LD A,L CP 40H JP M,AFF3B LD A,L XOR 20H POP HL RET
; ----------------------------------------------
AFF3B: LD A,L AND 00101111B LD L,A AFF3F: LD A,L CP 40H POP HL RET P PUSH HL LD L,A AND 0FH CP 0CH LD A,L JP M,POPHL XOR 10H POPHL: POP HL RET
; ----------------------------------------------
COD_08: LD A,(WINKOO) CP E JP NC,AFD51 DEC HL DEC E RET
; ----------------------------------------------
DIR_R: OUT (80H),A LD A,90H OUT ((high PDA)+3),A ; 0A3H DIRRLO: LD (PDB),HL IN A,(high PDA) ; 0A0H LD (BC),A INC BC CALL AF999 JP DIRRLO
; ----------------------------------------------
DIR_G: CALL CMPDH JP Z,AFF86 ; если нет 2-го параметра EX DE,HL LD A,(HL) LD (TMP_COD),A LD (HL),0CDH INC HL LD SP,HL POP HL LD (STOP_A),HL LD HL,AFF94 PUSH HL AFF86: LD SP,R_BC POP BC POP DE POP HL POP AF LD SP,HL LD HL,(R_HL) CALL P_JMP AFF94: LD (R_HL),HL PUSH AF POP HL LD (R_AF),HL POP HL LD (POINT),HL LD HL,-2 ADD HL,SP LD SP,R_AF PUSH HL PUSH DE PUSH BC LD HL,(POINT) LD SP,HL LD HL,(STOP_A) PUSH HL DEC SP POP HL LD A,(TMP_COD) LD L,A PUSH HL JP WARMST
; ----------------------------------------------
DIR_X: CALL RST_18 defb 13,10,'HL' defb 13,10,'BC' defb 13,10,'DE' defb 13,10,'SP' defb 13,10,'AF' defb 19H,19H,19H,19H,19H +128 LD HL,R_HL LD B,5 AFFDD: LD E,(HL) INC HL LD D,(HL) PUSH BC PUSH HL EX DE,HL CALL CHXHL@ CALL GETLIN JP NC,AFFF5 CALL GET_HL POP DE PUSH DE EX DE,HL LD (HL),D DEC HL LD (HL),E AFFF5: POP HL POP BC DEC B INC HL JP NZ,AFFDD RET
; ----------------------------------------------
defb 3AH,2DH,44H
.dephase END
| | | | |
|
12 Feb 2020 11:34 |
|
|
Paguo-86PK
Maniac
Joined: 12 Apr 2011 20:43 Posts: 267 Location: Tashkent
|
Спасибо! Любопытно глянуть на свой код глазами другого человека. В основном - метки именованы иначе… Нормального текста пока нет. Но по мере битья листинга, дамп в окне дополняется и все бреши заполняются моим кодом. Примерно вот так Ещё не занимался кодом работы с магнитофоном и клавиатурой. И такты пересчитывать пока лень… Если я не набаламутил с тактами, то получается следующее: Такты оригинальной подпрограммы | | | | Code: WRBYTE: PUSH HL ; 11 {{ PUSH BC ; 11 PUSH DE ; 11 PUSH AF ; 11 LD A,80H ; 7 LD (VT_57+8),A ; 13 LD HL,0 ; 10 ADD HL,SP ; 4 LD SP,0 ; 10 LD D,8 ; 7 }} = 95 AFC58: POP AF ; 10 {{ LD A,C ; 5 RLCA ; 4 LD C,A ; 5 LD A,1 ; 7 XOR C ; 4 LD (PC),A ; 13 LD A,(KNS_WR) ; 13 LD B,A ; 5 }} = 66 :: x8 = 528 AFC66: POP AF ; 10 {{ DEC B ; 5 JP NZ,AFC66 ; 10 }} = 25 * KNS_WR :: x8 = 200 * KNS_WR LD A,0 ; 7 {{ XOR C ; 4 LD (PC),A ; 13 DEC D ; 5 LD A,(KNS_WR) ; 13 JP NZ,AFC7A ; 10 SUB 14 ; 7 AFC7A: LD B,A ; 5 }} = 57 / 64 :: x8 = 520 AFC7B: POP AF ; 10 {{ DEC B ; 5 JP NZ,AFC7B ; 10 }} = 25 * KNS_WR:25 * (KNS_WR - 14) + 7 :: x8 = 200 * KNS_WR - 350 INC D ; 5 {{ DEC D ; 5 JP NZ,AFC58 ; 10 }} = 20 :: x8 = 160 LD SP,HL ; 5 {{ LD HL,VT_57+4 ; 10 LD (HL),0D0H ; 11 LD (HL),76H ; 11 INC HL ; 5 LD (HL),23H ; 11 LD (HL),49H ; 11 LD A,27H ; 7 LD (VG_75+1),A ; 13 LD A,0E0H ; 7 LD (VG_75+1),A ; 13 LD L,8 ; 7 LD (HL),0A4H ; 11 POP AF ; 10 POPDBH: POP DE ; 10 POP BC ; 10 POP HL ; 10 RET ; 10 }} = 172 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; = 1475 + 376.667 * KNS_WR 95 ... 528 + x25 399 + x25 + 64 + x25 - 350 = 463 + x25 - 350 = 113 + x25 ... 160 ... 176 = 431 + 641 + x25 = 1072 + x25 | | | | |
Такты моей подпрограммы | | | | Code: WRBYTE: PUSH HL ; 11 {{ PUSH BC ; 11 PUSH DE ; 11 PUSH AF ; 11 LD A,080H ; 7 LD (VT_57+8),A ; 13 LD HL,00000H ; 10 ADD HL,SP ; 4 LD SP,00000H ; 10 EX HL,DE ; 4 LD L,C ; 5 LD H,001H ; 7 }} = 104 WRBYTE1:POP AF ; 10 {{ ADD HL,HL ; 4 SBC A,A ; 4 AND 00EH ; 7 LD C,A ; 5 LD A,H ; 5 XOR 001H ; 7 LD (PC),A ; 13 LD A,(KNS_WR) ; 13 LD B,A ; 5 }} = 73 :: x8 = 584 WRBYTE2:POP AF ; 10 {{ DEC B ; 5 JNZ WRBYTE2 ; 10 }} = 25 * KNS_WR :: x8 = 200 * KNS_WR LD A,H ; 5 {{ LD (PC),A ; 13 LD A,(KNS_WR) ; 13 SUB C ; 4 LD B,A ; 5 }} = 40 :: x8 = 320 WRBYTE3:POP AF ; 10 {{ DEC B ; 5 JNZ WRBYTE3 ; 10 }} = 25 * KNS_WR : 25 * (KNS_WR - 14) :: x8 = 200 * KNS_WR - 350 DEC C ; 5 {{ JP M,WRBYTE1 ; 10 }} = 15 :: x8 = 120 EX HL,DE ; 4 {{ LD SP,HL ; 5 LD HL,VT_57+4 ; 10 LD (HL),0D0H ; 11 LD (HL),76H ; 11 INC HL ; 5 LD (HL),23H ; 77 LD (HL),49H ; 11 LD A,27H ; 7 LD (VG_75+1),A ; 13 LD A,0E0H ; 7 LD (VG_75+1),A ; 13 LD L,8 ; 7 LD (HL),0A4H ; 11 POP AF ; 10 POPDBH: POP DE ; 10 POP BC ; 10 POP HL ; 10 RET ; 10 }} = 176 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; = 1304 + 376.667 * KNS_WR | | | | |
У меня явные расхождения по тактам - 73 против 40. Почти в два раза. Есть мысль не отнимать 14 на восьмом цикле, а прибавлять что-то в первых семи циклах. Здесь нужно возомнить себя великим математиком и серьёзно произвести вычисления всего этого дела… Если «XOR 1» заменить на «DEC A» или «CPL» - суть не изменится, но будет экономия на байт и такты… Более выровненный вариант | | | | Code: WRBYTE: PUSH HL ; 11 {{ PUSH BC ; 11 PUSH DE ; 11 PUSH AF ; 11 LD A,080H ; 7 LD (VT_57+8),A ; 13 LD HL,00000H ; 10 ADD HL,SP ; 4 LD SP,00000H ; 10 EX HL,DE ; 4 LD L,C ; 5 LD H,001H ; 7 }} = 104 WRBYTE1:POP AF ; 10 {{ LD A,L ; 5 RLCA ; 4 CPL ; 4 LD (PC),A ; 13 LD A,(KNS_WR) ; 13 LD B,A ; 5 }} = 54 :: x8 = 432 WRBYTE2:POP AF ; 10 {{ DEC B ; 5 JNZ WRBYTE2 ; 10 }} = 25 * KNS_WR :: x8 = 200 * KNS_WR ADD HL,HL ; 4 {{ SBC A,A ; 4 AND 00EH ; 7 LD C,A ; 5 LD A,H ; 5 LD (PC),A ; 13 LD A,(KNS_WR) ; 13 SUB C ; 4 LD B,A ; 5 }} = 60 :: x8 = 480 WRBYTE3:POP AF ; 10 {{ DEC B ; 5 JNZ WRBYTE3 ; 10 }} = 25 * KNS_WR : 25 * (KNS_WR - 14) :: x8 = 200 * KNS_WR DEC C ; 5 {{ JP M,WRBYTE1 ; 10 }} = 15 :: x8 = 120 EX HL,DE ; 4 {{ LD SP,HL ; 5 LD HL,VT_57+4 ; 10 LD (HL),0D0H ; 11 LD (HL),76H ; 11 INC HL ; 5 LD (HL),23H ; 77 LD (HL),49H ; 11 LD A,27H ; 7 LD (VG_75+1),A ; 13 LD A,0E0H ; 7 LD (VG_75+1),A ; 13 LD L,8 ; 7 LD (HL),0A4H ; 11 POP AF ; 10 POPDBH: POP DE ; 10 POP BC ; 10 POP HL ; 10 RET ; 10 }} = 176 ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; 104 ... 432 + x25 420 + x25 + 60 + x25 - 350 = 480 + x25 - 350 = 130 + x25 ... 120 ... 176 = 400 + 562 + x25 = 962 + x25 | | | | |
В основном - директивы. В оригинале - 2A и 1D. У меня - 1D и 22… Опечатался Спасибо за замечание! Оказывается код прочёл как Видимо, так глаза забинарились, что две команды слились! Эта тема уже обсуждалась. Я сторонник полного функционала. Тем более, в журнале РАДИО и директиву «R» выпилили в одной из публикаций. Если мне не изменяет память, под ту самую «W» для поиска по двум байтам. В то время «R» не была так важна рядовым пользователям. А сейчас она необходима в тех же эмуляторах. Тем не менее, эти «R», «G» и «X» я отправил в самый конец, как уже поняли. Можно там выпиливать, пропиливать и допиливать их как хотите! Запустите оригинальный Монитор, в «X», измените SP на 76CD, затем последовательно исполните «GF803» и «GF815». Ещё больший недостаток в том, что тот же RST_18 портит и A, и C. У меня есть вариант кода, не портящий аккумулятор: Но я не знаю, какие последствия могут быть… Изначально Монитор задуман как законченный код, без наращивания и приращивания. Потому и подобные трюки не так плохи… И код можно переписать вот так: Своими 45% я ещё толком и половины не перелопатил! Основное усердие я проявил в комбинированной «D», чтобы слиять её с «L». А так как коды этих директив безобразным образом разделялись «C», «F», «S» и «T», то пришлось всё сместить ради исключения лишнего «JMP»… P.S.: Параллельно пытаюсь писать Escape-драйвер с минимальной привязкой к рабочим ячейками Монитора. Однако, для унификации неплохо было бы иметь отдельную таблицу JMP'ов для доступа к внутренним ресурсам. Но у меня уже всё забито. А выбрасывать тот же «X» - не хорошо в моём случае. Хотя смещения окна целиком я уже добился по горизонтали. И прокрутку одной строки сделал для вставки символа: Область 64×25 полностью (64 раза) прокручивается за 8 секунд - 8 кадров в секунду. Вполне подходит для игры-скроллера… P.P.S.: Досадная проблема: Оболочка-подобие Нортона запускает программы, предварительно сильно загадив область экранного буфера. А так как моя подпрограмма печати очищает лишь область 64×25, экран сильно сбоит и срываются циклы ПДП. По 1F нужно обнулять весь буфер целиком. Но мой код размерами этого никак не позволяет! P.P.P.S.: Из многих онлайн-редакторов дампа этот достаточно удобный… И книга, оказывается, есть « ДИЗАССЕМБЛИРОВАНИЕ В УМЕ»
|
13 Feb 2020 12:26 |
|
|
Who is online |
Users browsing this forum: No registered users and 42 guests |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot post attachments in this forum
|
|