Emu80 v.4

[Pyk]

в прошлой версии эмулятора были также машинки Micro80 и ЮТ88.
будут ли они добавлены в эмулятор ?

Да, будут. Никаких сложностей с ними нет, сделаю, когда руки дойдут...

У меня вопрос по ВИ53 для РК86, что имеется ввиду под оригинальной схемой? Т.е. какая из схем?

Вот эта, из журнала "Радио":
http://emuverse.ru/wiki/%D0%A0%D0%B0...%D0%92%D0%9853
А какие были альтернативные?

Файлы с неверной КС грузить приходится по два раза по два раза Так задумано? и только по директиве "I"

Там скорее всего дело не в неверной контрольной сумме, а в полном ее отсутствии или еще каким-то образом нарушенном формате файла. Монитор пытается еще читать с ленты, а файл уже кончился, вот он заново и спрашивает его. В таком случае лучше отменить выбор файла во второй раз. Возможно, в прошлых версиях поведение эмулятора в подобных случаях было другим - я посмотрю. А откуда такие "битые" файлы вообще?

Нет аппаратной псевдографики, но это так, чисто к сведению,я и не прошу, меня Emu в этом плане устраивает, почти.

Не понял, о чем речь, о кодах C0-EF? Они отображаются точно так, как должны на этих машинах, в отличие от Emu... Или о чем-то другом?

а вот нет драг-энд-дроп-а, это сильнее расстраивает)

В каком виде хочется драг-энд-дроп? Перетащить файл в окно эмулятора для загрузки? Если это действительно нужно и кажется удобным, сделаю.

[Advertiser]

[zebest]

Перетащить файл в окно эмулятора для загрузки?
у "конкурентов" очень хорошо работает, перетащил файл, он и запустился.

речь, о кодах C0-EF

О них. ну понятно, что не должны. Но это все же эмуляторы. Где то и должны, поэтому я и сказал, что в Emu меня почти устраивает эмуляция этих кодов, хоть их и не должно как бы существовать.

А откуда такие "битые" файлы вообще?

Файлы мои. Сами они не битые, вполне рабочие, но без КС или совсем или с неверно посчитанной. опять же - Emu их грузит и даже не думает ругаться.

[barsik]

Понятно, что из-за отсутствия MODE 2, прерывания в машинах на КР580 нельзя использовать для незаметного опроса клавиатуры

можно, если клавиатуру опрашивает сама программа

Имелось в виду то, что при ОЗУ с 0 и отсутствии контроллера прерываний, прерывания нельзя использовать в системном ПО, т.е в ROM-BIOS и DOS работающей в старших адресах, т.к прерывания требуют постоянного присутствия какой-то ерунды по адресу 38.

Но конечно в одной конкретной игре прерывания выравнивают темп игры и делают мгновенной реакцию на нажатия.

без необходимости терять на это драгоценное процессорное время.

Это невозможно. Общие потери процессорного времени при опросе клавиатуры по прерываниям могут даже увеличиться. Хотя визуально и в скорости реакции на клавиши игра при прерываниях выигрывает относительно версии с программным опросом.

Преимущество клавиатуры на прерываниях в том, что игра тормозится хоть и немного больше, но зато равномерно при прогоне всех участков программы. Без прерываний в тех местах программы, где CALL F81B вызывается часто, - торможение большее, а в тех участках кода, где это делается редко, - торможение меньшее. Программисту трудно добиться баланса, чтобы темп игры не колебался, общее торможение не упало бы чрезмерно, а реакция на клавиши осталась удовлетворительной.

[Pyk]

Общие потери процессорного времени при опросе клавиатуры по прерываниям могут даже увеличиться

Я имел в виду конкретно замену F803, где в подпрограмме Монитора задержка автоповтора и писк при нажатии реализованы с помощью циклов. Прерывания в данном случае позволили эффективно использовать это время в основной программе.

[barsik]

перенос из темы "игра Элитэ на КР580", т.к там это оффтопик.

можно... добавить прерывания в Специалист... назвать как-нибудь эту доработку (условно "Специалист 2017"), опубликовать спецификацию

Новую платформу из-за нескольких резисторов объявлять не нужно. Чем больше платформ, тем меньше на них пользователей. Зачем платформа, если на ней будет только её автор? Пользователей СПЕЦИАЛИСТА осталось 3 человека (надеюсь после настройки плат новоделов станет чуть больше).

Тогда если я или автор другого эмулятора заявит поддержку "Специалиста 2017"

Вот смотрим эмулятор АМИГИ. В нём можно поменять кучу всего, процессоры, периферийные БИС, ROM, память, дисководы, винчестер. Всё настраивается во вкладках. Так сложилось оттого, что было много моделей и не проблема смена комплектации в конкретной машине.

Почему же в отечественных эмуляторах надо вводить платформы. Нужен один эмулятор, но в нём вкладки, где всё дополнительное можно задать. Для СПЕЦИАЛИСТА тоже было бы удобно задавать во вкладках:

- 3 типа цвета и один монохром
- конструкция ПЗУ (многостраничное или нет)
- выбрать содержимое ПЗУ
- определить ОЗУ или ПЗУ в верхней области выше ПЗУ C000...CFFF
- выбрать тип КНГМД
- задать винчестер
- задать контроллер на 'microSD'
- задать ROM-диск и его содержимое
- задать число доп.банок ОЗУ
- задать внешний электронный диск
- задать наличие прерываний
- задать тиккер на МГ-входе
- задать ВИ53 на 3 канала

Так удобнее, чем какие-то платформы. Каждый сможет быстро выбрать вариант для отладки своей программы под своё конкретное железо. У пользователя может быть сделана всего одна или две доработки.

Если же делать платформы, то их число перевалит за тысячу. Из школы мы знаем, что число сочетаний равно "n-факториал". Считайте. Потому вкладки удобнее, чем платформы задаваемые конфиг-файлами. Но это лишь предложение исходя из того, как это делается в иностранных эмуляторах.

Предположительно реализация не создаст особых проблем, т.к каждое устройство в Вашем эмуляторе задается несколькими строчками в текстовом файле. Потому перенастройка во вкладках просто заканчивается записью соответствующего текстового файла, избавляя пользователя вникать в устройсво конфиг-файлов разных эмуляторов. К тому же часть железа уже и так выбирается во вкладках (например цвет 4/8/монохром).

[Pyk]

barsik, спасибо, я понял идею (в этом плане хорошо организованы настройки в эмуляторе Orion/Z от Error404).
В планах подобное есть, но, увы, не в самых ближайших.

Конечно, здесь все равно есть тонкая грань между существовавшими общепринятыми расширениями и современными предложениями вроде прерываний, пока не поддержанными ни софтом, ни железом. Но это все обсуждаемо и решаемо - можно вынести их в отдельную вкладку экспериментальных настроек и т.п.

[barsik]

Недавно мне понадобился эмулятор СПЕЦИАЛИСТА работающий с РК-КНГМД. И естественно, выбор пал на великолепный много-платформенный эмулятор EMU80 от Pyk.

В попытке проверить RAMDOS, RAMDOS-Commander, защищённые от копирования программы, их инсталляторы, МГ-компоновщик и SP-COPY, я столкнулся с проблемой загрузить программу с автостартом. На СПЕЦИАЛИСТЕ это делается без всяких директив, просто по сбросу.

Возможно, чтобы разобраться в использовании эмулятора мне нехватило ума и информации. Но т.к инструкции нет, то в итоге я вообще не смог найти в эмуляторе EMU80 возможности загрузить даже одноблочный файл по сбросу с автостартом.

В итоге пришёл к выводу, что такой возможности в эмуляторе EMU80 вообще нет из-за использованного алгоритма. А даже если бы такая возможность была, это всё-равно не позволило бы грузить МГ-программы защищённые от копирования и даже просто многоблочные программы. Т.к принцип эмуляции магнитофона здесь основан на перехвате единственной подпрограммы LDBYTE (C377, С806). Причём предполагается, что эта подпрограмма вызывается из подпрограммы ввода массива, в которой передаются адреса для ввода блока, а в конце массива следует контрольная сумма.

Но в многоблочных программах только первый блок, что является программным загрузчиком остальных блоков, идёт в таком формате, а остальные блоки не содержат ни адресов, ни контрольных сумм (т.к первичный загрузчик их и без того знает).

При такой концепции эмуляции магнитофона, магнитофон эмулируется не в реальном времени, оттого ни МГ-константы ввода/вывода CLD и CSV, ни скорость CPU вообще не играют роли, а в самом ПЗУ весь код подпрограммы ввода байта можно забить любой информацией (это даёт удобство при модификациях ROM-BIOS специально для эмулятора).

А вот эмуляция обоих типов дисководов в эмуляторе EMU80 сделана полноценно, в реальном времени. Поэтому, кстати, такт эмулируемого CPU в конфиге понижать нельзя, - перестаёт работать дисковод. Потому в EMU80 работают форматёры дисков, а в EMU форматёры не работают.

Но даже и в такой концепции, полагаю, нет проблемы сделать и автостарт одного блока и ввод многоблочных программ. Но надо вводить все байты идущие с ленты. Пилотоны можно опустить, а вот все синхробайты E6, необходимы. Таким образом именно отсутствие в формате RKS байта E6 приводит к неприятностям. Именно по этой причине в формате GAM все байты E6 были сохранены.

При этом желательно эмулировать подпрограмму C377 с той же скоростью, с какой она прогоняется в реальной ЭВМ (для чего надо "посмотреть" на CLD в ячейке 8FFF). Однако концепция перехвата LDBYTE не позволит грузить МГ-файлы использующие нестандартный низкоуровневый формат записи. Потому имеющиеся возможности ленинградского монитора по чтению МГ-формата ZX-Spectrum и МГ-формата MSX не могут работать в эмуляторе EMU80.

А пока процедура ввода по первому вызову C377 просто открывает файл с заданным именем, интерпретирует первые 4 байта как адреса блока и считав файл, далее, вероятно, по понижению стека на 1 уровень (что соответствует RET из п/п-ммы C414 ввода массива) а скорее всего по выходу на конкретный адрес делается возврат в программу 8-ми разрядки. Этим объясняется, что лениградский монитор СПЕЦИАЛИСТА (в котором 100% совмещены все стандартные входные точки, но также и все нестандартные точки), не работает на ввод с магнитофона.

Можно и не зацикливаться на подпрограммах ввода байта (C377 и C806), а перехватывать подпрограммы ввода блоков - C3F9, c414, С422 и C824. Тогда по LDBYTE будет читаться служебная информация, а по входу в процедуры ввода блока читаться блок данных из файла.

Предположив, что возможно удастся загрузить и автозапустить по сбросу файл в WAV-формате с помощью нажатия на ALT-W, я попробовал грузить те WAV-файлы, что без проблем грузились в эмулятор от b2m. Но почему-то получил сообщение, что формат файлов неправильный, хотя эти записи нормально грузятся и в реале.

Вот такая ситуация по работе с магнитофоном. Выяснилось, что RAMDOS, даже если эмулировать внешний эл.диск на РУ7 или заменить его на внутренний RAM-диск из доп.ОЗУ, использовать на EMU80 не получится не только потому, что там другой формат магнитофона, но и потому, что программы там грузятся по сбросу.

Пока получается, что для программ работающих с дисководом надо использовать EMU80 от Pyk, а для магнитофонных программ работащих в реальном времени - эмулятор EMU от b2m.

Надеюсь, что описание возможностей упомянутых эмуляторов не вызовет озлобление их авторов в мой адрес. Если я кардинально заблуждаюсь и просто не умею пользоваться чужими программами без документации, прошу прощения и подробных инструкций.

[barsik]

Так что же насчёт МГ-формата орловского монитора. Как такой файл ввести в эмулятор?

принцип эмуляции магнитофона здесь основан на перехвате единственной подпрограммы LDBYTE (C377, С806). Причём предполагается, что эта подпрограмма вызывается из подпрограммы ввода массива

Нет, это не предполагается

Ну так расскажите о принципе эмуляции работы с магнитофоном в вашем эмуляторе. Всем это будет интересно узнать.

Ясно, что для перехвата используется попадание программы на адреса C377 и C806, т.е на стандартную подпрограмму ввода байта. Но не ясно по какому критерию Вы определяете, что прогон программы ввода байта закончился. b2m в своём эмуляторе делает это вполне понятным образом, он контроллирует точки выхода из п/п-рамм ввода байта и вывода байта. Поэтому его эмулятор не проблема настроить на любое ПЗУ конкретного компьютера. А вот как Ваш эмулятор настроить на конкретное ПЗУ нет никакой информации, а догадаться об этом изучая файлы EMU80.conf и Specialist.conf невозможно. Расскажите как Вы определяете, что ввод байта закончился.

для формата MSX, интересно было бы попробовать перехватить также и эти вызовы.

В этом нет проблемы. Т.к побайтовый обмен в любом МГ-формате имеет точку входа и точку выхода, то достаточно отлавливать вход в соответствующую исполнительную часть подпрограммы LDBYTE. Если перехватывать вход в подпрограмму LDBYTE и точку выхода из неё по RET, то Вас совершенно не волнует какой физически формат использует ПЗУ, это может быть даже и не МГ-формат, а например формат передачи по проводний линии со скоростью 8 кб в секунду.

А в ленинградском мониторе перехватывать ввод/вывод в любых форматах вообще не проблема. Так как в нём подпрограммы LDBYTE/SVBYTE векторизованы (идея заимствованая из монитора SP580), кстати, как и в ОРИОНЕ.

Итак, в ленинградском мониторе СПЕЦИАЛИСТА введены два вектора:

8FD3/D4 - ASAVE - адрес исполнительной части п/п-ммы записи байта на МГ
8FD5/D6 - ALOAD - адрес исполнительной части п/п-ммы чтения байта с МГ

а подпрограммы работы с МГ в ленинградском мониторе вот какие:

.
LDBYTE:	PUSH	HL
	LD	HL,(ALOAD)
	EX	(SP),HL
	RET

SVSB:	LD	A,0E6H		; вывод на МГ синхробайта
SVBYTE:	PUSH	HL
	LD	HL,(ASAVE)
	EX	(SP),HL
	RET

Так что, если Вы перехватили точки входа LDBYTE/SVBYTE, то Вы перехватили ввод/вывод байта во всех форматах, в том числе и когда загружен драйвер для обмена по проводной линии.

В ленинградском мониторе при включении частотной MSX-кодировки нажатием НР+F3 (включение обратно фазовой кодировки - НР+F4), то просто в ячейки ALOAD/ASAVE подставляются другие адреса. Однако в ленинградском мониторе в процедурах ввода/вывода используются не тупые программные паузы программной петлёй, а в паузе между фронтами процессор в правом верхнем углу экрана (по адресу из ACOUNT) выводит число - адрес ячейки куда (откуда) в данный момент происходит ввод (вывод) байта.

8FD7/D8 - ACOUNT (B00B) - экранный адрес куда выводится счётчик при вводе/выводе

А если Вы подменяете прогон реальных МГ-подпрограмм, то естественно и счётчика на экране не будет, если только Вы сами не захотите его выводить. Потому в эмуляторе от b2m счётчик при работе с магнитофоном бежит, а при Вашем алгоритме эмуляции магнитофона этого нет.

При такой концепции должен работать ввод многоблочных программ (вскоре попробую это проверить заменив ПЗУ в эмуляторе). Но перехват подпрограмм LDBYTE/SVBYTE никак не поможет грузить защищённые программы в которых содержится свой загрузчик с МГ, причём даже, если формат не хитроумный с антикракерскими мерами, а стандартный двухфазный, но точка входа в процедуру ввода иная.

Оказывается эмулятор от b2m тоже не совершенен по работе с магнитофоном. Там тоже какая-то "химия". Т.к он не грузит коммерческие программы защищённые форматом записи (естественно, в WAV-виде). А грузит только программы, что используют стандартную п/п-мму ввода байта.

[Pyk]

Так что же насчёт МГ-формата орловского монитора. Как такой файл ввести в эмулятор?

Я не спец по Специалисту, "Орловский" Монитор - это какой?
(Насчет Ленинградского позже отвечу - не дошли руки пока до него)

[barsik]

Ороловский монитор это основной монитор, который используют все (в т.числе и Вы в эмуляторе) и на который сдуру в программах делают вызовы, тогда как есть ROM-BIOS, жаргонно называемый загрузчиком, т.к это не RAM-монитор, а просто набор 19-ти базовых подпрограмм. Делать вызовы на C800 неправильно, т.к не все применяют именно орловский монитор, мониторов может быть много разных, а ROM-BIOS один.

Но теперь эту неприятность уже не исправить, т.к слишком поздно. Потому что сначала адаптации системного ПО от РК86, а затем и авторские программы некоторых совсем малограмотных товарищей полезли на входы C800. Однако почти все игры работают через загрузчик. Так что теперь орловский монитор - просто стандарт, альтернативы нет. Загрузка по сбросу это свойство загрузчика, не монитора. Для себя я чуть изменил загрузчик, теперь он, по нажатию на НР после сброса стартует из ROM-диска в формате ОРИОНА файл с оффсетом 800.

Орловский монитор характерен тем, что он зачем-то имитирует все основные входы монитора РК86, но по адресу C800, а не F800, хотя схемы совмещения адресации не опубликовали (т.к тогда до этого ещё не додумались). Кстати, прилагательные даже образованные от имён собственных и фамилий людей пишутся с маленькой буквы. Монитор А.Волкова это понятно тот, который был опубликован с самим компьютером и который работает из ОЗУ (8D00), а не из ПЗУ и потому может грузиться с ленты.

В журнале был ещё новожировский монитор и ещё какой-то (увы, сейчас не имею под рукой журналов МК). Но они совершенно не в тему и программы их не используют. Никакого смысла в них нет, т.к любые доработки, в т.числе и содержимого ПЗУ должны оставаться совместимыми, а всё неудовлетворяющее этой аксиоме, это просто чушь. Несовместимость уже попробовал КООП SP580, но всё равно и после них "вылезали деятели", до которых это не дошло.

В волковском мониторе нет формата с именем, только формат пригодный для загрузки по сбросу. Формат с именем также можно загрузить по сбросу, если у пользователя скорость реакции превышает 3 секунды. Для этого надо дождаться когда пройдёт первый пилотон, блок имени и начнётся второй пилотон. Вот тогда и надо нажимать на сброс. Есть много ранних пост-доработок волковского монитора, которые тоже работают в ОЗУ, а дополнительно имеют встроенный дизассемблер КР580 и иногда используют МГ-формат РК86 и есть версии и с форматом ОРИОН CHANGER$, служащие для интерфейса с другими бытовыми ЛК.

Я уже в какой-то теме предложил маркировать формат с именем расширением .SPT (Specialist tape), чтобы не было путаницы с форматом .RKS, при котором в начале файла просто стоят 4 байта с адресами загрузки, а последними байтами вставлена КС (и что неприятно даже байта E6 в начале нет, что очень печально, т.к нарушает логику и делает файл непригодным для прямой конверсии в WAV).

Для автоматизации переименования можно сделать специальную программку на бейсике Quick Basic (или даже Power Basic, который получше, т.к даёт при компиляции меньший и более скоростной код). Эта программка будет проверять все файлы с расширением .RKS и если обнаружится файл у которого в дампе первым байтом стоит D9, то у такого файла расширение имени будет изменено на .SPT.

А то, что в эмуляторе EMU80 по сбросу выскакивает окно для выбора загружаемого файла, то это можно исправить не кастрацией загрузчика, а сделать так, что по нажатию одной красной кнопки сброс, всё как и сейчас - загрузка блока с автостартом уничтожена. Но если нажать кнопку сброс удерживая клавишу <Control> или <Shift>, то выводится окно запроса файла с расширением именно и только .RKS.