Emu80 v.4

[NEO SPECTRUMAN]

как раз в gam e6 и есть


ZEman, выкинь его и попробуй


вот короче
CHESS.7z

[Advertiser]

[ZEman]

NEO SPECTRUMAN, а в чём редактировали ?

[NEO SPECTRUMAN]

https://mh-nexus.de/en/hxd/

еще норм winhex

[Pyk]

да и в своих rka я не ставил синхробайта
может его на оборот нужно выкидывать из gam?

Просто все эмуляторы учитывают, что E6 в начале файла может присутствовать, а может не присутствовать и не смотрят на расширение. Поэтому и встречаются неправильно сформированные файлы: gam-файлы с E6 и, наоборот, rk - без E6...
Но изначально было так: rk - с синробайтом (формат моего эмулятора), gam - без синхробайта (формат эмулятора Демина).
GAM - с синхробайтом
RK - без синхробайта
Чтобы получить RK из GAM, действительнро нужно выкинуть из него первый байт E6

[barsik]

gam - файл для RK-86, отличается от rkr отсутствием первого байта 0xE6

Вообще-то мне казалось, что всё наоборот. Во всех GAM-файлах из дистрибутивов 1998-99 годов все GAM-файлы с байтом E6. И до сих пор это так. Мне не попадались GAM-файлы без Е6 в начале. А RKR-наоборот все лишены байта E6, отчего ими опасно пользоваться в эмуляторах. Поэтому я все файлы храню или в ORD-формате, что предпочтительнее, или в GAM.

Поэтому и встречаются неправильно сформированные файлы: GAM-файлы с E6 и, наоборот, RK - без E6... Но изначально было так: RK - с синробайтом (формат моего эмулятора), GAM - без синхробайта (формат эмулятора Демина)

Но вот эти сведения ввели меня в замешательство. Если есть такое безобразие, то получается, что вообще нет стандарта. Раз стандарта нет, то лучше использовать единый стандарт ORD. В нём есть свободный байт, куда можно писать тип компьютера (младший ниббл, и особенности модификации или доработки, можно истратить бит на тип Z80/КР580). Важно, что сохраняется уникальное имя даже при хранении на дискетах.

Эмуляторы должны во всех процедурах чтения признавать ORD-формат и, в зависимости от того какой формат они ждут, сами конвертировать ORD в магнитофонный формат с нужными синхробайтами, пилотонами, паузами и т.п и выдавать эту смесь байтов на п/п-мму LDBYTE. Тогда и не будет "моря форматов", в которых сами их авторы уже запутались. Если не использовать ORD, как быть с форматом ИРИШИ, которая принимает файл в виде блоков, причём разной длины (и это не только в играх со своим загрузчиком, но и просто формат монитора имитирует посекторный обмен).

[Pyk]

barsik, спасибо, это меня переклинило Действительно, GAM - с синхробайтом, rk - без. Прошу прощения за то, что ввел в заблуждение, предыдущие сообщения поправил. А неправильные файлы (переименованные gam в rk) мне все же попадались...

[NEO SPECTRUMAN]

а 0 перед последним синхробайтом и контрольной суммой?
их может не быть вообще?
или нужен хотя бы 1
максимальное количество не ограничено так понимаю

а если туда произвольные данные а не (но не е6)
они будут просто пропускаться?
как сделано в настоящем загрузчике?

- - - Добавлено - - -

получается, что вообще нет стандарта.

получается что да
так как файл который захочет грузится с e600 (хотя как стартовый адрес это....)
будет не правильно трактоватся
и загрузится с 00**
да еще и...

а из за отсутствия ограничения на количество 00 перед последним синхробайтом и контрольной суммой
нельзя никак проверить по размеру первый e6 синхробайт или старший байт адреса....

[barsik]

Перед последним синхробайтом и контрольной суммой нуля может не быть вообще? Или нужен хотя бы один? Максимальное количество не ограничено, так понимаю. А если туда произвольные данные (но не Е6)? Они будут просто пропускаться? Как сделан ввод с МГ в настоящем РК86 ?

В стандартных входах РК есть п/п-мма ввод массива, которая полностью реализует директиву I. Не знаю как в клонах, а в самом РК это работает так. Сначала вызывается подпрограмма ввода двух байтов с поиском синхробайта (в роли которого E6 или его побитовая инверсия). Она пропускает любое число байтов, любых кроме E6 (или его инверсии). Любые байты передавать можно, если только из двух соседних байтов при их сдвигах в аккумуляторе не возникнет Е6.

Как только синхробайт найден, он тоже откидывается и дальше всё работает синхронно, - вводятся заказанные два байта. Затем вызывается подпрограмма ввода 2-х байтов уже без поиска синхробайта. Это будут 4 байта адресов загрузки. Далее зыпускается цикл ввода байтов до тех пор, пока текущий адрес ввода не станет равен конечному.

И вот тогда наступает момент, который Вас интересует. РК86 снова вызывает подпрограмму ввода 2-х байтов с поиском синхробайта. Таким образом, число байтов между концом блока и синхробайтом Е6 может быть любым, при условии, что среди этого потока битов нет байта Е6. Мне кажется, что байт 0 перед Е6 тоже не обязателен. Происходит сдвиг принятых битов, пока не возникнет Е6. Так что, если идут 2 байта 60 и 0Е, то по ним тоже произойдёт синхронизация. Это из-за того, что в этом формате нет побайтовой синхронизации (а в формате MSX есть). Именно поэтому перед синхробайтом выдают длинный пилотон, т.е блок из 256 (а иногда и более) нулей, чтобы человек услышав звук, мог нажать на <ВК>. Если пилотон не выдавать, а сразу начинать передачу с Е6, то шумы с выхода МГ могут сформировать ложный синхробайт.

Так, т.е с любым числом нулей до СБ контрольной суммы и любой паузой, сделано в РК86. Но в ОРИОНЕ претендующем на МГ-совместимость - не так. Там паузу вообще нельзя ввести, сразу возникает ТАЙМ-АУТ и уход на подпрограмму ERR_MG (ошибки чтения с МГ). И ОРИОН ожидает ровно 3 байта, причём в данном случае, точно не обязательно 2 нулевых и третий синхробайт Е6. Эти 3 байта могут быть любыми, т.к ОРИОН не сихронизируется по синхробайту, чтобы считать КС, он просто пропускает 3 байта и считывает 2 следующих, которые и оказываются контрольной суммой.

В СПЕЦИАЛИСТЕ контрольная сумма примыкает прямо к блоку данных. И никакой новой синхронизации по Е6 не делается. КС является как-бы частью блока, в смысле, что вводится с той же синхронизацией, отчего пауза перед КС недопустима.

Кстати, блок с КС может вводиться с инверсией. То есть вторым синхробайтом может служить байт являющийся побитовой инверсией E6 (это 19) и КС тогда надо тоже передавать в инверсии. Такой трюк сработает на РК86, т.к при второй синхронизации будет правильно поставлен флаг инверсии сигнала с МГ. А вот в ОРИОНЕ такой трюк не пройдёт. Т.о, это способ иметь формат РК86 несовместимый с ОРИОНОМ. Впрочем, для этого даже не надо исхитряться, достаточно добавить на один ноль больше или меньше перед КС.

Думаю, что в РК86 введётся и без (двух или иного числа) нулевых байтов между блоком и Е6, но пусть кто-нибудь проверит. Я могу сделать такую запись, если есть эмулятор, умеющий делать запись.

Я тут недавно узнал, что можно вводить МГ-записи в РК86 без гашения изображения на экране. Так что никто не хочет сделать для РК86 новый "монитор", где экран не будет гаснуть? Это теперь можно сделать, т.к пару месяцев назад в теме "РК86 на Z80" я освободил в ПЗУ РК86 КР580, если верно помню, ~80 ячеек. Этого должно Вам хватить на модернизацию подпрограммы чтения байта с МГ. Чтобы это сделать, надо сначала "кракнуть" коммерческую защиту от копирования и извлечь из неё подпрограмму чтения.

[Pyk]

NEO SPECTRUMAN, в принципе, barsik все правильно уже написал.
Дополню лишь, что в Партнере (rkp) используются два нулевых байта перед КС, в РК и остальных - один. Но, как и следовало ожидать, все файлы считываются на всех машинах. Допускаю, что так будет и без нулевых байтов - можно проверить при желании.

А файл с E600 ни на одной из этих машин располагаться не может, так как ни на одной из машин в этом месте нет пользовательского ОЗУ. В Апогее видео-ОЗУ разве что, но и в этом случае что-то грузить туда как минимум странно. Так что реально проблем с этим не возникает.

[barsik]

Реальный РК86 читает инверсный блок, т.е когда синхробайт не Е6, а 19. А эмуляторы читают такие записи? Ведь один магнитофон не инвертирует сигнал, а другой инвертирует. А адрес 19XX для загрузки блока вполне может быть и для РК86. Синхробайты нужны.

Если заставить всех пользователей иметь магнитофоны без инверсии, то в ПЗУ можно с'экономить более 20-ти байт! Если эмуляторы не читают инверсные записи, то так и надо сделать. Никто не хочет проверить эмуляторы на соответствие реалу? Надо проинвертировать все биты записи и даже пилотон тогда станет не цепочкой нулевых байтов, а байтов FF.