ivagor, Да я бы с радостью, но не совсем представляю как его запустить.
Вид для печати
ivagor, Да я бы с радостью, но не совсем представляю как его запустить.
dk_spb, написал на почту.
ivagor, Моя старая почта умерла вместе с провайдером.
Как, похоже, и Ваша на mail.ru.
Пишите мне на d
Да, я сначала на portpc написал. Сейчас написал на gmail.
Поправил некритичную ошибку (из за недокументированного NOPа в оригинальном бейсике для 580ВМ80, т.е. в BASIC 2.5 при работе на 1821ВМ85 это тоже есть) в Basic48 (старая версия была тут). Кроме того осовременил описание - привел более удобные способы запуска в эмуляторах. Также теперь используется быстрый распаковщик.
Вложение 39688
Думаю, все заинтересованные лица заметили, но никто не озвучил - в текстовую расшифровку результатов Exercizera закрались 2 опечатки:
aluop <...> - 0CFD7555 - д.б. 0CFD75B5
<daa,cma,...> - 17CFA599 - д.б. 17CFAB99
ivagor, А может и не читал никто ;-)
Да не, я заметил когда сравнивал (это было трудно незаметить), если были несовпадения поглядывал на фото. т.к. результаты в эмуле полностью совпали с реалом я быстро успокоился и забыл про эти мелочи :)
С тестами недокументированных флагов 1821ВМ85 предлагаю пойти по простому пути и использовать 8080EXER.
Он отличается от 8085EXER только тем, что не маскирует недокументированные флаги.
Сомнительный момент только один - влияет ли на 1821ВМ85 dad на что-нибудь кроме флага переноса.
Если предположить, что не влияет, то можно использовать оригинальный вариант 8080EXER.
Возможен и альтернативный вариант - использовать ldsi вместо dad. В доках написано, что эта команда не влияет на флаги.
На базе заготовки Ramirosа сделал 2 соответствующих варианта.
Вложение 39719
Чтобы представлять, что от них можно ожидать, прогнал эти тесты:
1. В текущей версии EMU (от 13.01.2013, на странице скачивания написано 15.01.2013)
exer8080
Вложение 39715
Вложение 39716
exer8080ldsi
Вложение 39717
Вложение 39718
продолжение в следующем посте
продолжение
2. и VV 6.73
exer8080
Вложение 39720
Вложение 39723
exer8080ldsi
Вложение 39721
Вложение 39722
Видно, что в EMU версии с dad и ldsi работают одинаково, а в VV - по разному. Т.е. в эмуляторах есть 3 не совпадающих результата. Вполне возможно, что на реале будет четвертый.
dk_spb, на Вас вся надежда. Только не знаю, какой вариант (8080 или 8080ldsi) предпочтительнее. Наверно можно выбрать любой из них и посмотреть, что получится.
Оффтоп - VV не удается разогнать как следует, что меня довольно сильно раздражает
до 50 МГц разгоняется нормально (у меня покрайней мере)Цитата:
Сообщение от ivagor
50 хорошо, а 384 (в EMU столько ставил) - лучше.Цитата:
Сообщение от Ramiros
Есть по крайней мере пара программ, для которых имеют смысл такие бешеные по ретрокомпьютерным меркам частоты:
Exercizer - в принципе его можно сильно оптимизизировать.
Конвертер картинок авторства PPC - внутрь не смотрел, могу только предположить, что он написан на C.
А можно попросить схемы, те, что по 300dpi? Все ссылки, что были ранее - протухли. И ещё, в самом начале темы выкладывались дампы ПЗУ, имена файлов там 1.bin и 2.bin. Какая из какой мс? (D20 и D26).
Заранее спасибо!
В картотеке смотрели? Может этот вариант подойдет?
Из больших картинок еще есть пара png (43.png и 44.png) размерами соответственно 4871x3411 и 4847x3343 точек (по 13 Мб), но вроде страницы 1 и 2 djvu сделаны именно с них.
Образ ПЗУ наверно лучше взять из комплектов эмуляторов EMU или Virtual Vector и поделить пополам, там точно рабочие образы.
Да, оттуда и брал. Просто был разговор именно про большие файлы. Конечно, можно разобрать и на этой, но если есть оригиналы - был бы очень признателен.
Про образы из эмуляторов - хорошая идея, не подумал, спасибо!
off: Может, подскажете что-нибудь по ремонту в отдельно созданной мной теме?
Собрал в кучку jpg и png по 6128 и выложил сюда. Уникального там ничего нет, надеюсь, что кто-нибудь выложит или даст ссылку на более качественные варианты.
Подсказать по ремонту, к сожалению, не могу, я не железячник. Наверно dk_spb наиболее подкованный в данном вопросе.
Может кому пригодится.
Чтобы стандартные векторовские мониторы-отладчики при работе на ПК-6128Ц были совместимы по скорости обмена в формате MON с Вектором-06Ц нужно изменить (задать после запуска монитора) константу чтения:
NR6B
и записи:
NW47
Очень интересная инфа по недокументированным флагам 8085. Отличие от ранее известных источников - описано влияние практически всех документированных арифметических команд на недокументированные флаги. Еще там ссылки хорошие, в т.ч. по subj.
---------- Post added at 13:33 ---------- Previous post was at 13:00 ----------
Классная табличка
---------- Post added at 15:19 ---------- Previous post was at 13:33 ----------
В emu и VV многие флаги сейчас не как в вышеприведенной инфе, что вполне понятно. Есть особо огорчительные моменты, например флаг K (X5) в командах DCX/INX.
---------- Post added at 15:24 ---------- Previous post was at 15:19 ----------
Одно время даже подумывал купить отладочный комплект для 8085 (индийцы вроде еще выпускают), чтобы выяснить эти недокументированные подробности. Хорошо, что не купил, сколько денег сэкономил :)
---------- Post added at 15:35 ---------- Previous post was at 15:24 ----------
Кстати, упоминавшийся здесь эмулятор VirtiualT правильно эмулит флаг K в INX/DCX
Скорее всего доберусь до архива в конце следующей недели. Может кто другой выложит?
Русский перевод вышеупомянутой инфы по недокументированным флагам 8085.
По поводу сканов - не добрался и, к сожалению, пока не знаю, когда доберусь.
Результаты прогона exercizera в текущих версиях эмуляторов:
EMU от 29.11.2013
Вложение 44374
VV 6.76
Вложение 44375
Убрал результат VirtualT, т.к. в нем запускал измененную (в связи с особенностями Tandy) версию exercizera и это кое-где повлияло.
А почему результаты-то разные?Цитата:
Сообщение от ivagor
Нужен эталонный образец, с чем сравнивать.
В emu команда RIM не влияет на аккумулятор (не реализована?). В VV детально не проверял, но по крайней мере состояние INTE в бите 3 отражается.
Возможно сделаю более детальный (но менее широкий) чем exercizer тестик. Основная задача - узнать значения недокументированных флагов (вернее значения соответствующих CRC) при выполнении арифметических и логических операций. Для этого можно перебрать все возможные значения операндов. Для 8битных и однооперандных 16битных (inx, dcx и т.д.) все нормально. Для 16+8 битных (ldsi и ldhi) уже похуже, но более-менее приемлемо. А вот для 16+16 битных (dad, dsub) время выполнения теста при полном переборе операндов очень большое.
Может быть у кого-нибудь есть конструктивные предложения, как ограничить набор перебираемых операндов, по крайней мере для dad и dsub?
Думаю нет смысла тестировать команды с каждым регистром, достаточно А,В,М то же самое про рег. пары.
Сделать "короткий"и "полный" режимы тестирования. По умолчанию-короткий с использованием только основных РОН и прямой адресацией: для 8-битных операций, или +- для 16-битных.Цитата:
Сообщение от ivagor
Вопрос. А зачем CRC считать? Ставим стек на конец проверяемой области, и после каждой операции для теста делаем push PSW. Потом-просто проверяем этот участок памяти против "контрольного" для соответствующего проца, выводя номер теста, ошибочные и ожидаемые значения флагов и/или регистра <A>. Вроде, так быстро будет, и можно готовый дамп прогона теста хоть на диск/ленточку скинуть если надо
Спасибо за отклики, но похоже мне стоило подробнее описать свое видение вопроса.
1. О всех комбинациях регистров речь не идет, это было бы полезно для авторов эмуляторов, но затраты времени на реале и без этого неприемлемые. Прикиньте, сколько займет перебор 2^(16+16) комбинаций операндов для dad и dsub.
2. Как без CRC я не понял. Нам ведь как раз нужно получить "контрольные" значения. Можно, конечно, получить результаты "в чистом виде", т.е. сами значения регистра флагов, но их очень-очень много - где хранить? Есть вариант сразу передавать (например через магнитофонный выход) в PC, но это не снимает вопрос с длительностью тестирования, кроме того я могу что-то недоучесть (т.к. отладить общение реала с PC я не могу), а потом, после многочасового тестирования вылезет плюха - и что делать? Еще хуже, если я ее "исправлю" и вылезет другая, думаю ситуация примерно понятна.
Возвращаясь к исходной постановке вопроса - может все же существуют методики сокращенного тестирования, без полного перебора комбинаций операндов (и, строго говоря, флагов влияющих на результат выполнения команды), может кто ткнет меня в них носом?
Чет я не пойму, а даташита на 8085 нету чтоле?
На всякий случай наверно стоит озвучить очевидную вещь - за счет чего предполагается ограничить число тестовых комбинаций операндов. Все же значения флагов - не случайные и даже не псевдослучайные величины. Есть формулы для вычисления этих флагов. Основные неоднозначности с dsub (про dad в 8085 в общем-то все написано) - при вычислении разных флагов как учитываются составляющие операндов/результата? Про флаг Z, например, явным образом написано, что в dsub учитываются и старший и младший байт результата.
---------- Post added at 17:40 ---------- Previous post was at 17:33 ----------
Даташита, в котором было бы написано например, как устанавливается флаг AC командой dsub мне не известно.Цитата:
Сообщение от Tronix
В принципе 8085 (AMDшный вариант) разобрали практически полностью (ссылки я выше приводил, оттуда есть еще ссылки), для полного счастья еще бы сделали его реализацию на Verilog или VHDL (или на чем там).
Предварительная версия теста недокументированных флагов 8085.
Можно увидеть отличия emu
Вложение 44648
и VV
Вложение 44649
Версия стэндэлонная для ПК6128, но сделана как бы под CP/M + "наноэмулятор двух функций CP/M", т.е. при необходимости очень легко переделать под CP/M. Пока тестируется часть команд с разрядностью операндов 8, 8+8 (надо бы еще добавить adi и т.п., а также с M) и 16. Очевидно, что такой подход к тестированию команд с разрядностью операндов 16+8 и тем более 16+16 по времени неприемлем.
Исходник в комплекте, может кто заметит ошибки или будут какие-то предложения по улучшению.
Вот еще результаты VirtualT v1.5
Набирал вручную, поэтому ошибки не исключены, хотя и маловероятны.Код:inr a K:B4BFE7CD V:5140CBAD
dcr a K:B4BFE7CD V:14907484
daa K:B4BFE7CD V:941D8FBB
ral K:B4BFE7CD V:941D8FBB
rar K:B4BFE7CD V:941D8FBB
rlc K:B4BFE7CD V:941D8FBB
rrc K:B4BFE7CD V:941D8FBB
add b K:E2ACA54D V:70669BEA
sub b K:E2ACA54D V:F40F4344
ana b K:E2ACA54D V:3A917959
ora b K:E2ACA54D V:3A917959
xra b K:E2ACA54D V:3A917959
inx h K:22757277
dcx h K:74C300AE
Три эмулятора и в каждом свое видение 8085.
Давайте я уже что-нибудь запущу на реале.
Или завтра или на НГ каникулах
dk_spb, заранее спасибо, но все же тестик пока неполный. Как тестировать dsub примерно придумал, ldsi и ldhi пожалуй даже не стоит тестировать.
Неожиданно тестик становится сериалом как минимум в двух частях, т.к. все результаты не влезают на экран, хотя я и выкинул название и копирайт и уменьшил межстрочное расстояние.
Вот результаты прогона в emu (поленился делать еще и в VV)
Вложение 44710
Для SIM RIM считается CRC для аккумулятора, а на флаги они не влияют.
Время работы вполне терпимое, в районе 15 минут.
Во второй части будут dad и dsub. Может что-нибудь еще, что я забыл в первой части.
ivagor, ты сразу опиши суть тестирования, чтоб потом исправлять было проще.
ftst1
1. Все, кроме sim rim:
Тестируются все возможные комбинации операндов + два варианта флагового регистра (00000000/11111111 - строго говоря, такие числа туда пишутся, но бит 3, конечно, всегда будет 0, все равно это ни на что ни влияет).
Перед тестом каждой команды инициализируютcя два CRC флагов (для K и V).
После каждого изменения операнда маскируется флаговый регистр - сначала выделяется флаг K, потом V и обновляются соответвующие CRC.
2. SIM RIM - тестируются все 256 (можно было ограничиться 128ю) возможных значений аргумента SIM + два возможных значения INTE. Каждый раз читаем по RIM и обновляем CRC.
Вторая часть теста флагов 8085.
Результаты в emu:
Вложение 44760
и VV
Вложение 44761
arhl и rdel тестируются аналогично inx и dcx в первой части.
Флаги K, AC и V в dad и dsub тестируются в два приема - все комбинации младших байтов и все комбинации старших байтов аргументов (флаги как всегда тоже в двух вариантах: 00000000 и 11111111). AC в dad (да и K тоже) можно было не тестировать, но я не стал делать отдельный вариант теста, все равно время работы второй части всего 6 с половиной минут.
Тестирование флага P в dsub отличается тем, что первый операнд всегда 0, второй меняется от 0 до 65535.
Проверять S, Z и C в dsub мне кажется не стоит, и так все понятно.
По скорости тесты можно оптимизировать, но смысла в этом не вижу - речь о минутах, а не о часах, в отличие от эксисайзера.
dk_spb, теперь все тесты готовы, если сможете проверить на новогодних каникулах - было бы очень здорово.
То есть я этот .rom перегоняю в .wav и запускаю?
Сколько времени ориентировочно займет (ночь, сутки, и т.д.)?