Вы имеете ввиду RK-DOS? Именно ту, перетранслированную для Z80 из файла "RKDOS_for_TEST.RAR", что я выложил для проверки в реале? У меня вообще-то нет особых причин думать, что они нерабочие, т.к я получил их, - одну "кромсанием" рабочего исходника RK-DOS для ОРИОНА, а вторую косметическими изменениями в оригинальной РК-ДОС для КР580. Но т.к обе версии не проверялись в реале и при переделках почти всегда возникают ошибки и с первой попытки обычно ничего не работает, то я и предложил их проверить в реале тому, у кого есть Z80 процессор в РК86 и стандартный РК-КНГМД по адресу F000. Так что конкретных ошибок я указать не могу. Если они есть, их надо определить при проверке в реале или хотя-бы в эмуляторе.Сообщение от Pyk
Из текста сообщения понял, что Вы проверили эти коды в эмуляторе, который эмулирует и РК-ДОС и процессор Z80. О существовании такого эмулятора ничего никому ещё не известно. Не сообщите ли подробности о новой версии своего эмулятора EMU80 для Z80? Если действительно сделана эмуляция железа РК-КНГМД, то это удобно, чтобы проверять ДОС на базе дисковода. А вот Z80 в РК86 это пока не актуально.
Эта строка не помогла, хотя появились отличия. Если при 'mem1' вообще ничего на экране не было, то теперь кое-что на экране есть. Но удивляет, что выводится только часть символов.
Теперь снова про глюк в работе отладчика из ОЗУ 8400...BFFF и тот же самый глюк при работе отладчика из ПЗУ E000. Этот глюк не связан со стеком, т.к одинаков при стеке - в основном ОЗУ и в ОЗУ выше 8000.
Как с конфигом, где основное ОЗУ совмещено с помощью 'frame' с ОЗУ окна 8400, так и с конфигом, где эти ОЗУ (mem1 и mem8400) - разные, отладчик ведёт себя так, как я и описывал, - не удаляет RST в основном ОЗУ.
Но если закомментировать одну строку так
// map[0][F100-F1FF]=DOPPPA.data
то отладчик в верхних адресах работает отлично, но естественно коммутации ОЗУ в окне 8400...BFFF - нет, хотя само ОЗУ в области 8400...BFFF - есть. Таким образом, всё портит коммутация кусков памяти в окне.
Таким образом отладчик может работать в ОЗУ выше 8000 только, если нет коммутации, а значит ОЗУ в эмуляторе B2M можно расширить только лишь на 15 кб... Я не понимаю сути явления, т.к другие программы, кроме отладчика, похоже, работают из старших адресов. И виноват в этом именно эмулятор, т.к, как указано выше, тот же самый код работает отлично, если убрать коммутацию ОЗУ. Причём и отладчик на E000 (т.е якобы в ПЗУ) ведёт себя точно так же, хотя там ОЗУ не коммутируется.
Я не мог знать насчёт паузы в 5 секунд между вводами по I? Ведь документации нет. Это объяснило почему дефект возникал не всегда. И то, что выполнение какой-то промежуточной команды перед второй директивой I помогало избавиться от дефекта. И это явный глюк эмулятора, а не особенность. Если пользователь страдает, то это всегда глюк. Если произошёл "отлов" прогона входа RDBYTE, чётко указанного в конфиге, то уж сам Бог велел при этом закрыть все файлы. И ссылки на паузу в 5 секунд и ожидание продолжения ввода предыдущего блока, после входа в RDBYTE - неуместны.
Зачем ждать 5 секунд. Достаточно тайм-аута в пол секунды. И это не объясняет откуда берётся старший байт адреса следующего блока равный FF. Предположительно это байт КС предыдущего блока. FF потому, что для неокончательных файлов я не устанавливаю правильную КС, - это ни к чему, если файл ещё изменится 20 раз. Но не важно по каким причинам искажается адрес ввода. В любом случае эмулятор не должен вводить блок в адреса выше C000. Так что с тем, что это глюк спорить невозможно. Но это нормально, все программы содержат ошибки.
Синхронизация должна происходить по байту E6. Это лишний раз доказывает, что формат 'GAM' лучше, чем надуманный формат 'RK', т.к в нём есть байт синхронизации E6. Но эмулятор B2M правильно считывает и файлы с расширением RK. И даже вообще любые файлы с произвольным расширением. Он просто считает первые 4 байта как адреса ввода. А если первый байт E6, то его игнорирует. Вследствие этого, по директиве I файл в формате RK в эмулятор B2M нельзя ввести на адреса E600...E6FF. А вот в формате GAM - можно.
Лишние байты есть всегда. Файлы записанные в CP/M имеют кратность 128 байт. Поэтому после трансляции очень редко появляется GAM-файл у которого длина чётко равна длине блока плюс служебные байты в начале и конце блока. Точнее это может случиться только с вероятностью 1/128-мая, т.е на практике почти никогда.
И кстати, раз уж речь о вводе файлов. А что насчёт ввода других форматов? В частности ORD. Ведь как-то Вы вводите при эмуляции СПЕЦИАЛИСТА и ОРИОНА другие МГ-форматы, кроме формата МИКРО-80 и РК86. Точнее, - задача вводить файлы не с магнитофона, а с винчестера. Это же проще, чем эмулировать ввод с магнитофона.
Когда я делал эмулятор РК86, то сразу решил не "заморачиваться" с магнитофоном. Ввёл в сам эмулятор функцию загрузки файла. А уж какой он, в каком формате этот файл, это эмулятор не волнует. Эмулятор получает от КР580-программы имя файла, адрес загрузки и максимально допустимый размер файла и просто грузит файл с винчестера. Аналогично при записи. Но самое трагичное, что ориентация на магнитофон и низкоуровневую эмуляцию железа, а не на файлы на винчестере, лишает возможности тестировать в эмуляторе ДОС. А особенно, когда даже низкоуровневой эмуляции РК-КНГМД нет. Хоть какой-то выход из этого - это эмуляция большого ОЗУ, используемого в качестве эл.диска.
У меня файлы для всех БК (в том числе РК86) - в формате ORD и этот формат понимает мой эмулятор РК86. Очень неудобно транслировать все программы в двух видах - и в виде GAM и в виде ORD. Формат ORD удобен тем, что он годится и для МГ-ленты (или WAV-файла) и для дискового файла. Форматы RK и GAM при выгрузке на ленту теряют имена файлов.
Я не представляю, как загрузить в эмулятор B2M файл в формате ORD. Ещё большее неудобство возникает при вводе файлов в ИРИШУ. Потому-что там формат записи на МГ не содержит ни адреса загрузки, ни длины файла. Поэтому приходится помнить эти данные или хранить их на бумажке. Я с этим намучился ещё на реальной ИРИШЕ (потерял из-за этого кучу файлов). И был дико удивлён, когда обнаружил такую-же ерунду и в эмуляторе. Здесь задача ввода ORD-файлов, на порядок более актуальна.
Я пользовался экранными отладчиками 80x86. Отладчиком эмулятора B2M пользоваться неудобно. Почему пользователь экспериментальным путём должен устанавливать, что делают команды отладчика, приведённые в HELP-е? HELP должен быть исчерпывающе понятным.
В отладчиках должна быть команда PASS для прохождения подпрограмм без трассировки. В отладчике ИРИШИ из 1977 года нажимаешь P на команде CALL или RST и она прогоняется, как одна команда ассемблера. И кстати, о якобы ущербности командного режима относительно графического представления отладчика. Видя фрагмент кода и зная, где надо остановиться, на порядок быстрее ввести команду 'G,xxxx', чем подгонять курсор куда-то, ставить там стоп-точку и затем нажимать на <F5>. А если стоп точка вообще не на экране, то переход к ней отнимает ещё больше времени.
Видел отладчики которые показывают дамп ОЗУ, куда указывает текущий HL. Удобно если в отладчике работают символьные клавиши, а не только функциональные и мышь. Например, по P,S,A,B,D,H может выскакивать окно для HEX-ввода регистров. По нажатию I,C,Z,E... могут переключаться на обратный флаги. По нажатию только одной клавиши курсор должен перескакивать в нужное окно. В визуальном отладчике тоже удобно иметь команды.
У программирующих для 8080/Z80 не бывает листинга LST, это же не MASM или TASM для 80x86. У них бывает только файл с расширением PRN, где тоже есть таблица меток.
Почему запрашиваются HEX-числа с СИ-префиксом '0x'? По нажатию клавиши окно очищается, в том числе и префикс. Просто HEX-число, без префикса не вводится. Приходится вручную вводить ещё и префикс 0x, что раздражает. Если уж окно очищается, то префикс '0x' следовало оставить, чтобы пользователю не пришлось вводить его вручную. А если уж необходима подсказка, что ожидается HEX-число, то это можно сделать в заголовке окна.
Да и странно ожидать что-то другое кроме HEX-чисел, мы же в отладчике, не в бейсике. Всё должно быть для удобства пользователя.
Ответить с цитированием