 |
nedoPC.orgElectronics hobbyists community established in 2002 |
 |
| Author |
Message |
|
barsik
Doomed
Joined: 19 Feb 2017 03:46
Posts: 584
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: 584
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: 584
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: 584
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: 584
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: 584
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: 584
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: Alikberov and 18 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
|
|
