Pyk, я у себя сделал загрузку bin, файл преобразуется на ходу в текущий формат rk? с правильной контрольной суммой.
Pyk, я у себя сделал загрузку bin, файл преобразуется на ходу в текущий формат rk? с правильной контрольной суммой.
Направление мысли верное (облегчение жизни пользователя), но реализация идеи неверная. Я уже давно прошу авторов эмуляторов сделать то же самое, но для ORD-файлов. Т.е возможность задать в конфиг файле то, в какой именно формат автоматически конвертируется ORD-файл, если в окне открытия файла выбрать файл с расширением ORD.
Удобнее всего все программы хранить и грузить в эмуляторы в ORD-виде, а также нет препятствий для трансляции ассемблером файлов прямо в ORD-вид. В BIN-файле, а точнее в DAT-файле (потому что файл можно считать и DES, и BIN, и OCT, и HEX) нет адресов загрузки и длины.
И кстати, длина задаваемая длиной самого MSDOS-файла не годится, т.к на выходе трансляторов размер файла выдаётся кратным 128-ми байтам, а не с точностью до байта. Формат ORD допускает и КС и дату файла (и эта дата файла удобнее, т.к её можно вручную подставить, она не меняется при модификациях файла и автоматически подставляется при трансляции).
Можно конечно придумать свой формат аналогичного назначения, в котором есть адреса начальный, конечный или адрес загрузки и длина файла (что удобнее), но зачем, если уже почти 30 лет существует и успешно используется ORD-формат.
Последний раз редактировалось barsik; 27.03.2018 в 09:04.
barsik упорно продвигает свой ord формат, несмотря на то что все программы для Специалиста идут в rks формате. И этот формат сложился де-факто как основной для Специалиста.
Формат не мой, а исторический с 1991 года и кто первый его использовал неизвестно. Он служил для хранения на дискетах программ с произвольным адресом. Хранить файлы в магнитофонном формате глупее, чем в общепризнанном дисководном.
Как слОжился, так и разлОжится, если в эмуляторы встроить единый формат для всех платформ.
Так получилось потому, что эмуляторы писали люди не имеющие дисководов на реальных машинах и использовали в качестве информации только стартовые статьи в журналах. А практически любой пользователь 8-ми разрядок несколько лет помучившись с магнитофоном, затем покупал дисковод и забывал о магнитофоне как о кошмарном сне. Зачем же этот кошмар возродили в эмуляторах?
Зачем вообще нужно поддерживать МГ-формат базовых мониторов? Когда я в 1997-98 писал свой первый эмулятор РК86, я не стал встраивать поддержку МГ-процедур. Монитор в ПЗУ для отладки/загрузки вообще не использовался. Глупо использовать монитор в кодах КР580, если мы на IBM PC. Сам эмулятор, позволял не только отладку, но и ввод/вывод/запуск блоков в формате ORD (а когда увидел чужой эмулятор с форматом GAM, добавил загрузку GAM). МГ-формат в файлах да и сам командный монитор в ПЗУ были не нужны вообще. Задача монитора в ПЗУ в реале - только загрузка и иногда отладка, зачем же и на PC заставлять пользователя мучиться как было в реале.
А при написании эмулятора ОРИОНА мне даже в голову не пришло делать не только поддержку магнитофона, но и вообще любой ввод отдельных блоков. И дискеты и все квазидиски формируются автоматически при старте эмулятора (загружаясь из подготовленных пользователем подкаталогов).
Это мгновенно изменяется запуском простейшей программы написанной даже на бейсике (например, Power-бейсик для Windows), которая сканирует все файлы подкаталога в поиске RK? файлов и конвертирует их как надо, причём записывая флаг, для какого конкретно типа ЭВМ данная программа. В 4 свободных байта заголовка можно записать флаг о том, для какой конкретно ЭВМ данная программа и даже для какого процессора (Z80 или КР580).
Последний раз редактировалось barsik; 27.03.2018 в 19:25.
Vinxru сделал свой SD контроллер с поддержкой файловой системы и запуском rks файлов по умолчанию, а что изобрёл barsik с поддержкой ord файлов?
Ну вот, как всегда, люди которым нечего возразить по существу, а хоть что-то возразить очень хочется, переходят на личности.
Некрасиво кого-то в чём-то упрекать, причём даже не разобравшись в сути. А уж если упрекаете, то следовало сказать так, - вот я fifan сделал то-то и то-то, а не о том, что кто-то другой что-то сделал. К тому же ещё не вечер, - я занялся Специалистом лишь пару месяцев назад и даже с доработками железа ещё не определился.
ORD это формат файлов, во-первых, для хранения на PC, во-вторых для эмулятора, и в-третьих, для дисковых DOS в которых у файлов нет адреса. Потому такие файлы поддерживаются в моих эмуляторах РК86 и ОРИОНА и все рэтро-файлы на PC, в т.числе и для Специалиста и ИРИШИ я храню в таком виде.
Для Специалиста с базовым объёмом ОЗУ в качестве DOS годится только RK-DOS, в которой файлы имеют в каталоговой записи стартовый адрес, потому там файлы хранятся без всяких заголовков и соответственно ORD-файлы вообще не нужны. ORD-файлы это просто формат хранения, такой же как RKS. И для его поддержки на реале ничего не нужно. Это лишь формат удобный для хранения на PC и для эмулятора.
Кстати, для реала на ОРИОНЕ я был противником ORD-файлов, т.к они абсолютно необходимы только для ORDOS, а для CP/M я написал конвертор, который из ORD-файлов делал COM-файлы (запускаемые из CP/M вообще в любой банке), что удобнее, чем ORD-файлы (т.к для их запуска нужны специальные средства, а COM-файлы запускает сама DOS).
Последний раз редактировалось barsik; 27.03.2018 в 21:25.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
Стандарты устанавливают не концептологи, а те, кто пишет ПО.
Скрытый текст
ретро - не бЭйсик[свернуть]
ПК8010 "Корвет"+ExtRom+AY, Atari 65XE+SDrive, Дельта-С(52ИС)+AY, Scorpion ZS 1024+SMUC
Я за .rks формат. Прост и самодостаточен. И весь архив игр уже в нем давно.
Точно. Стандарты на формат файлов для эмулятора создаёт автор эмулятора, потому именно им я это и предлагал. К тому же это совсем просто, никого не напрягает, а проблему КС при трансляции решает.
К тому же, я выше упомянул, что у меня нет проблемы КС. А если бы и была, то есть простое решение без модификации эмуляторов - запускать (BAT-файлом) при старте эмулятора как бы препроцессор конвертор форматов, который из исходного каталога все находящиеся там ORD-файлы конвертирует в правильный RKS и помещает их в каталог .../EMU/spec/PROGS/.
- - - Добавлено - - -
Так я и не предлагал убрать RKS формат. Я лишь предложил новый (старый) универсальный формат в качестве решения проблемы подгонки КС при трансляции.
Кстати, что Вы скажете на счёт того, чтобы ввести в эмуляторы укороченный формат RKS?
Суть в том, что файл тоже с расширением 'rks', но байтов в нём меньше на 2 байта, т.е просто нет контрольной суммы. Эмулятор открывая файл должен проверить есть КС или нет, и если её нет, то посчитать и выдать посчитанную КС в конце ввода. Вот и всё решение проблемы КС при трансляции.
У меня эмулятор не пытается считать контрольную сумму, по скольку необходимости в ней практически нет. На магнитной ленте - нужна. В образе кассеты не нужна.
Взять, к примеру, популярные форматы образов дисков для Спектрума - trd и т.д. Там нет контрольных сумм. И именно по тем причинам, что носители в наши время надежные. А за контроль качества архива отвечают архиваторы, которые делают это на порядки лучше, чем давно устаревшая КС.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)