какой формат файла rks?
вроде гдето видел
есть утилита для пересчета crc файла?
Вложение 64780
Вид для печати
какой формат файла rks?
вроде гдето видел
есть утилита для пересчета crc файла?
Вложение 64780
Откуда этот файл? В нем заголовок неправильный: 3 байт должен быть 81, а не 01 - это старший байт конечного адреса
Контрольная сумма файла DF3A, нужно последние 00 00 поменять на 3A DF.
Процедуру подсчет КС вот только на днях приводил:
http://zx-pk.ru/threads/6505-radio-8...l=1#post955672
Либо из Монитора пересохранить.
Ваш файл не грузится потому что Вы конечный адрес указали меньше начального 8000...014С, а надо 8000...814F. Во вложении правильный файл и с контрольной суммой. Если КС нет или она неверная, то грузить можно только по сбросу, т.к тогда КС не контролируется. Симпатичная картинка.
Распространённых форматов эмуляторов есть всего два - с именем и без имени. Они выводятся по O и W, а вводятся по I и R, соответственно.
А, если Вы применяете ленинградский монитор, то доступен еще формат РК86 (загрузка по Y), формат ОРИОНА (загрузка по @), формат ZX-Spectrum (загрузка по J), а также в формате MSX (после НР+F3). Естественно, в эмуляторе для форматов отличных от двухфазного, конфиг эмулятора д.быть соответственно настроен (указаны точки перехвата МГ-подпрограмм).
Итак формат без имени:
256 байтов 00 (пилотон)
E6 синхробайт
Нач.адрес (младший, старший)
Кон.адрес (младший, старший)
Сам файл длиной кон.адрес минус нач.адрес +1
Контрольная сумма (младший, старший)
Формат с именем:
256 байтов 00 (пилотон)
E6 синхробайт
D9, D9, D9 - признак формата с именем
до 17 байтов имени, но последний всегда 0
768 байтов 00 (второй пилотон)
E6 синхробайт
Нач.адрес (младший, старший)
Кон.адрес (младший, старший)
Сам файл длиной кон.адрес минус нач.адрес +1
Контрольная сумма (младший, старший)
Как видите, формат с именем отличается только наличием заголовка с именем. Потому второй пилотон специально сделан долгим, и если для файла с именем нажать на сброс во время второго пилотона, то можно ввести файл с именем с автоматическим запуском по окончании ввода (а также загрузить по директиве R).
В формате для эмулятора начальные байты, а именно первый пилотон и байт Е6 откинули. Пилотон не нужен, а вот байт E6 откинули зря, он нужен, потому, что его наличие позволяет слеплять блоки многоблочных программ в один файл простым слиянием. Таким и был формат GAM в эмуляторе Дёмина (он отличается от формата RK? только наличием лидирующего байта E6).
Эмуляторы EMU и EMU80 понимают формат GAM и даже если в формате RKS оставить лидирующий байт E6, то эмуляторы всё-равно загрузят верно. Т.е эти эмуляторы лидирующий E6 всегда отбрасывают. Это не вредит потому что в РК и ОРИОНЕ на адрес E6xx ничего не грузится, а для Специалиста нет программ грузящихся на адрес xxE6, начальные адреса всех программ кратны xx00.
На реальных кассетах использовался формат с именем, но для эмуляторов сочли его ненужным (т.к имя есть у файла Windows), потому для эмуляторов для файлов в виде кодов больше используется формат без имени, а для файлов в виде WAV используется формат с именем.
К сожалению, у авторов эмуляторов не хватило фантазии придумать разные расширения для разных форматов. Причём при попытке загрузить по I файл предназначенный для ввода по R, происходит завис. Потому такая путаница очень раздражает при эксплуатации эмуляторов (что в очередной раз доказывает, что если хочешь иметь удобный эмулятор, то сделай сам). Для сокращения путаницы я использую для формата с именем расширение 'RKS', а без имени - 'rks'. Кстати, если использовать эмулятор EMU80, то в конфиге можно задать типы файлов с которыми будет работать эмулятор.
Кстати, при ленинградском мониторе (в отличие от орловского), можно загрузить любой блок в двухфазке с любой скоростью и от любого компьютера, если указать начальный и конечный адреса. Например, ввести R1000,8F00 и по бегущему счётчику узнать конечный адрес загрузки. Можно проще - R1000 (неуказанный второй параметр принимается нулём). При этом с указанного адреса введутся все байты следующие сразу за байтом E6.
Теперь как подгонять КС блока.
К сожалению, хотя на Си написать это совсем несложно, конвертора DAT-файла кодов программы в формат RK? для Windows до сих пор никто не удосужился написать. Причём это должна быть программа работающая с командной строкой, тогда достаточно включить её запуск BAT-файлом сразу после трансляции, но перед стартом эмулятора.
Если Вы используете в эмуляторе ленинградский монитор, то не проблема подставить КС вручную с помощью редактора UltraEdit в HEX-режиме. Для этого файл грузят (по I или по R - без разницы). Ленинградский монитор подсчитывает и выводит контрольную сумму введённого блока (а орловский монитор выводит только надпись "ОШИБКА"). Достаточно посмотреть эту сумму и вручную подставить в конце файла или задать в исходнике.
- - - Добавлено - - -
Код:.
.Z80
aseg
ORG 100H
KS EQU 0EEEEH
RABADR EQU 8000H
defb 0D9H,0D9H,0D9H
defb 'DEMO игры ELITE',0
DS 256 - ($-100H)
defb 0E6H
DW RABADR, RABADR+LENGTH -1
.phase RABADR
. . . . тело самой программы . . . . .
ZZZ aset $ and 0FH
if ZZZ ne 0
rept 10H-ZZZ
defb 255
endm
endif
LENGTH EQU $-RABADR
DW KS
.dephase
END
Вот так я оформляю программу транслируемую для Специалиста в макроассемблере М80 от Microsoft. Запускаю трансляцию, линковку и запуск странслированной программы в эмуляторе BAT-файлом, так что закончив набор текста, просто запускаю BAT-файл (можно прямо из UltraEdit, там есть такие возможности, т.е можно обойтись и без BAT-файла) и через секунду уже в эмуляторе, проверяю программу, для чего нажимаю НР+F9 (для прерывания загрузки по сбросу), затем I для ввода RKS файла.
Пока программа отлаживается, я не обращаю внимания на KS, а когда программа отлажена, то остаётся только посмотреть выводимую КС при вводе и подставить её в исходник вместо константы KS и ещё раз странслировать. Потому меня проблема из-за того, что ассемблер не умеет сам считать и подставлять КС в объектный код, не волнует. А вообще в ассемблере такая функция была бы полезной.
Кстати, для написания программ для 8-ми разрядок нет альтернативы макроассемблеру M80 и текстовому редактору UltraEdit, - всё остальное гораздо хуже.
Подо что эта программа? У меня на эмуляторе не работает.
barsik, откуда я должен был узнать структуру файла .RKx?
все что я знаю получено анализом имеющихся образов кассетных файлов
а там все грузится по адресу 0 и второе слово получается вот такое вот.
про crc я в курсе но формул не знаю да и нет у меня такой функции в sjasm.
Я запускал в эмуляторе EMU80 с указанием CPU КР580. Может быть для Вашего эмулятора мешает первый байт E6, удалите его. А вообще попадаются файлы у которых первый байт E6. Потому лучше сделать как сделали авторы других эмуляторов, - всегда игнорируйте лидирующий байт E6, это синхробайт.
Убрал 0xE6. Как я его не заметил.
На самом деле, этот байт в образ пихать не надо, раз его нет в большинстве образов.
Да и контрольная сумма излишня. Тем более, что стандартному загрузчику она не нужна.
Согласен, кто к чему привык, то и лучше.
Хотя без некоторых свойств в макроассемблере (например, .phase) программировать сложнее. Кстати, на M80 можно в одной и той же программе писать кусок кода на Z80 (после оператора .Z80), а другой кусок кода на ассемблере 6502 (после оператора .6502), что удобно, если в ЭВМ, как в Apple-II, стоят сразу два программно переключаемых процессора.
В мониторе Специалиста есть директива K<нач.адр>,<кон.адр>, считающая КС (по подпрограмме F82A в РК86). Так что после ввода, зная адреса загрузки, этой директивой можно сосчитать КС.
А зачем Вам считать КС?
КС нужна только, если использовать орловский монитор, т.к с ним не знаешь адрес загрузки блока, т.к этот монитор не выводит адреса при неверной КС, но если и так знаешь адрес загрузки блока (чтобы ввести команду Gaddr<ВК>), то и это неважно. Используйте автостартовость монитора Специалиста по сбросу, где КС не контролируется.
А чтобы начать отладку встроенным отладчиком эмулятора, используйте эмулятор EMU80, задав в конфиге выход в отладчик по команде HALT. В нужном месте программы ставите HALT и сразу по старту программы оказываетесь в нужном для отладки месте (нажимаете U, чтобы пройти HALT) и далее шагаете по шагам нажимая F7 или F8.
Можно HALT и не использовать, но тогда надо по листингу трансляции смотреть адрес, где нужен останов и перед запуском программы выйти по АЛТ-D в отладчик, набрать A, затем нужный адрес, перейти туда и с помощью клавиши F5 поставить там стоп точку. Потому для ускорения проще вставить HALT при трансляции. Но чтобы вылет в отладчик по HALT срабатывал, поставьте в конце конфига для Специалиста строку:
cpu.debugOnHalt = yes
А кстати, я плохо понимаю ассемблер КР580, потому пишу в мнемониках Z80 и часто по привычке вставляю JR и другие Z80-команды, отчего в эмуляторе программы улетают и приходится много часов искать ошибку трассировкой. По счастью недавно Pyk ввёл в EMU80 возможность вылета в отладчик по недокументированной команде. Это здорово помогло. Так, что если Вы пишете на ассемблере Z80 для КР580, то Вам очень поможет такая строка в конфиге:
cpu.debugOnIllegalCmd = yes
Я не считаю КС в окончательной сборке, я просто смотрю в эмуляторе, что написано на экране после ввода (неважно по R или по I) и это число подставляю в исходник и снова транслирую. У меня при трансляции BAT-файлом результирующий файл копируется в подкаталог '...\EMU80\spec\PROGS\'.
Эмулятор EMU80 всегда при отладке загружен, из него выходить незачем (да и грузится он несколько секунд, что нервирует). После трансляции для ввода программы набираю R (или I) и нажимаю <ВК>. Контрольная сумма не волнует, потому что использую ленинградский монитор, а он выводит и адреса загрузки и реальную КС введённого блока по окончании загрузки. Если интересует могу поделиться конфигами Специалиста для EMU80 и EMU с прерываниями 50 Гц, дисководами, ROM-диском и ОЗУ в 1 мб.
Вообще-то, надо бы нацарапать программку, работающую из командной строки, которая считает КС файла в формате RKS без имени. Любой программист это напишет за 5 минут. Но я написать это могу только для MSDOS, т.к для Windows не программирую. Если кого-то это устроит (для прогона программ MSDOS надо иметь Win XP, не выше), то могу это сделать.
Раз уж речь зашла о Emu80, могу еще предложить грузить файлы через Alt-F3 (с автозапуском) или Alt-L (без автозапуска). КС при этом игнорируется.
Ну или drag-n-drop'ом файл бросать в окно эмулятора, что равносильно Alt-F3.
- - - Добавлено - - -
jerri, вот, кстати, готовый скрипт от vinxru для формирования rks-файла с подсчетом КС:
https://github.com/alemorf/retro/blo...s/-make-rks.js
Там же есть -compile.bat, из которого он вызывается...
Pyk, я у себя сделал загрузку bin, файл преобразуется на ходу в текущий формат rk? с правильной контрольной суммой.
Направление мысли верное (облегчение жизни пользователя), но реализация идеи неверная. Я уже давно прошу авторов эмуляторов сделать то же самое, но для ORD-файлов. Т.е возможность задать в конфиг файле то, в какой именно формат автоматически конвертируется ORD-файл, если в окне открытия файла выбрать файл с расширением ORD.
Удобнее всего все программы хранить и грузить в эмуляторы в ORD-виде, а также нет препятствий для трансляции ассемблером файлов прямо в ORD-вид. В BIN-файле, а точнее в DAT-файле (потому что файл можно считать и DES, и BIN, и OCT, и HEX) нет адресов загрузки и длины.
И кстати, длина задаваемая длиной самого MSDOS-файла не годится, т.к на выходе трансляторов размер файла выдаётся кратным 128-ми байтам, а не с точностью до байта. Формат ORD допускает и КС и дату файла (и эта дата файла удобнее, т.к её можно вручную подставить, она не меняется при модификациях файла и автоматически подставляется при трансляции).
Можно конечно придумать свой формат аналогичного назначения, в котором есть адреса начальный, конечный или адрес загрузки и длина файла (что удобнее), но зачем, если уже почти 30 лет существует и успешно используется ORD-формат.
barsik упорно продвигает свой ord формат, несмотря на то что все программы для Специалиста идут в rks формате. И этот формат сложился де-факто как основной для Специалиста.
Формат не мой, а исторический с 1991 года и кто первый его использовал неизвестно. Он служил для хранения на дискетах программ с произвольным адресом. Хранить файлы в магнитофонном формате глупее, чем в общепризнанном дисководном.
Как слОжился, так и разлОжится, если в эмуляторы встроить единый формат для всех платформ.
Так получилось потому, что эмуляторы писали люди не имеющие дисководов на реальных машинах и использовали в качестве информации только стартовые статьи в журналах. А практически любой пользователь 8-ми разрядок несколько лет помучившись с магнитофоном, затем покупал дисковод и забывал о магнитофоне как о кошмарном сне. Зачем же этот кошмар возродили в эмуляторах?
Зачем вообще нужно поддерживать МГ-формат базовых мониторов? Когда я в 1997-98 писал свой первый эмулятор РК86, я не стал встраивать поддержку МГ-процедур. Монитор в ПЗУ для отладки/загрузки вообще не использовался. Глупо использовать монитор в кодах КР580, если мы на IBM PC. Сам эмулятор, позволял не только отладку, но и ввод/вывод/запуск блоков в формате ORD (а когда увидел чужой эмулятор с форматом GAM, добавил загрузку GAM). МГ-формат в файлах да и сам командный монитор в ПЗУ были не нужны вообще. Задача монитора в ПЗУ в реале - только загрузка и иногда отладка, зачем же и на PC заставлять пользователя мучиться как было в реале.
А при написании эмулятора ОРИОНА мне даже в голову не пришло делать не только поддержку магнитофона, но и вообще любой ввод отдельных блоков. И дискеты и все квазидиски формируются автоматически при старте эмулятора (загружаясь из подготовленных пользователем подкаталогов).
Это мгновенно изменяется запуском простейшей программы написанной даже на бейсике (например, Power-бейсик для Windows), которая сканирует все файлы подкаталога в поиске RK? файлов и конвертирует их как надо, причём записывая флаг, для какого конкретно типа ЭВМ данная программа. В 4 свободных байта заголовка можно записать флаг о том, для какой конкретно ЭВМ данная программа и даже для какого процессора (Z80 или КР580).
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).
Стандарты устанавливают не концептологи, а те, кто пишет ПО.
Скрытый текст
ретро - не бЭйсик[свернуть]
Я за .rks формат. Прост и самодостаточен. И весь архив игр уже в нем давно.
Точно. Стандарты на формат файлов для эмулятора создаёт автор эмулятора, потому именно им я это и предлагал. К тому же это совсем просто, никого не напрягает, а проблему КС при трансляции решает.
К тому же, я выше упомянул, что у меня нет проблемы КС. А если бы и была, то есть простое решение без модификации эмуляторов - запускать (BAT-файлом) при старте эмулятора как бы препроцессор конвертор форматов, который из исходного каталога все находящиеся там ORD-файлы конвертирует в правильный RKS и помещает их в каталог .../EMU/spec/PROGS/.
- - - Добавлено - - -
Так я и не предлагал убрать RKS формат. Я лишь предложил новый (старый) универсальный формат в качестве решения проблемы подгонки КС при трансляции.
Кстати, что Вы скажете на счёт того, чтобы ввести в эмуляторы укороченный формат RKS?
Суть в том, что файл тоже с расширением 'rks', но байтов в нём меньше на 2 байта, т.е просто нет контрольной суммы. Эмулятор открывая файл должен проверить есть КС или нет, и если её нет, то посчитать и выдать посчитанную КС в конце ввода. Вот и всё решение проблемы КС при трансляции.
У меня эмулятор не пытается считать контрольную сумму, по скольку необходимости в ней практически нет. На магнитной ленте - нужна. В образе кассеты не нужна.
Взять, к примеру, популярные форматы образов дисков для Спектрума - trd и т.д. Там нет контрольных сумм. И именно по тем причинам, что носители в наши время надежные. А за контроль качества архива отвечают архиваторы, которые делают это на порядки лучше, чем давно устаревшая КС.
Файл "rk?" это образ магнитофонной записи. Если есть на ленте контрольная сумма - она должна быть и в файле, нет на ленте - нет и в файле.
Titus, не "rk", а "rk?". От последней буквы суть формата не меняется, просто образ магнитофонной записи для того или иного РК совместимого компьютера. rks как раз наиболее худший представитель. Мало того, что несовместимых компьютеров и их мониторов как грязи, так еще и в рамкам одного ПК нет единого стандарта.
Справедливо.
Проблема из-за того, что изначально в 1998 году при разработке эмулятора РК86 не ввели единый универсальный формат для эмуляторов, а затем стали всё делать по подобию формата РК86. Но у РК всего один формат, а у других компьютеров по несколько форматов. Потому кодировать формат одной буквой неудобно. Хотя у ОРИОНА и Специалиста по два формата, для эмулятора выбрали примитивный, а формат с именем откинули (а он нужен для загрузки файлов в DOS).
Кстати, непонятно как поступили с ОРИОНОМ у которого первый формат это формат РК, а второй - формат с именем, где имя необходимо. Логично использовать RKR (хотя программа не для РК) и расширение RKO для формата с именем.
Не обязательно, чтобы расширение указывало на тип компьютера, т.к программы разных ЭВМ не смешивают в одном каталоге. А вот информация о формате важна, т.к при попытке загрузить не тот формат происходит завис.
Скрытый текст
Кстати, для Специалиста есть ещё один МГ-формат, - формат RAMDOS. Хотя в реале он совместим с форматом с именем. Там есть дополнительные информационные байты, идущие сразу после нулевого стоп-байта имени. Для ввода монитором по I они не вредят, т.к идут до второго пилотона и байта E6. Т.е есть ещё один формат с расширением RKS и тут уж я не знаю как отличать разные форматы RKS, т.к третьего регистра букв нет.
Пока адаптацией RAMDOS я не занимался, но это несложно (исходники есть), - достаточно лишь переписать две подпрограммы чтения и записи байта в эл.диск из доп.ОЗУ (в оригинале внешний эл.диск). Недосуг было этим заняться, но надеюсь вскоре займусь этим.
Имея универсальный формат хранения для эмуляторов, в котором есть уточняющие информационные байты, многие проблемы снимаются. Незачем всю информацию о формате вкладывать в одну букву в расширении файла.
Можно подумать о использовании расширений:
rks_L - формат для загрузки по сбросу без КС (от слова Loader)
rks_V - формат волковского монитора (или rks_R, т.к грузится по R)
rks_O - формат орловского монитора (или rks_I, т.к грузится по I)
Изменить это в эмуляторах несложно. Пусть в окне выбора файла выводятся все файлы начинающиеся с букв RK и проблема снята.
Можно также использовать расширения RKS1, RKS2, RKS3. Или SP1, SP2, SP3, а для ОРИОНА OR1, OR2. Тут в имени содержится информация и о компьютере и о формате файла.[свернуть]
Что значит суть? Если под сутью Вы понимаете идею, то да, а вот сам формат для разных компьютеров разный.
barsik, поздно что либо менять. Да и смысла нет, rk? это просто преобразованный wav. В имени wav даже тип компьютера не указан, не говоря уже о формате заголовка. Еще с rk? проще разобраться эмулятору и при необходимости подсунуть файл в нужном формате.
И хай это останется так впредь. Продолжайте хранить свои файлы у себя в этом формате.
Вот именно. Если тебе нужен не образ кассеты - делай другой формат (да хоть образ дискеты). Но если ты это называешь именно образом кассеты и хочешь, чтобы его грузил код написанный для кассеты - будь ласка, соблюдай устоявшийся формат. Ведь если бы он не соответствовал требованиям, он бы не продержался так долго, а вот барсиковый так нигде и не всплыл. ;) Хотя он полезен для случая связи реала с РС, который выполняет роль внешнего накопителя.
Частично. Если бы это было так, то была бы возможна обратная конверсия, но тупо преобразованные в WAV блоки не грузятся, им не хватает пилотона и синхробайта E6.
Поздно было бы, если бы авторы эмуляторов умерли. Но пока новые версии EMU80 выходят раз в месяц (версии EMU чуть реже), а ввести универсальный формат эмуляторов с авто-конверсией файлов при вводе в нужный формат очень просто. А выводить в окне выбора файла другие имена ещё проще.
А вы давно смотрели архивы программ для ОРИОНА?
Нет у меня своего формата, я пользуюсь широко распространёнными форматами. У меня так получилось само собой, потому что только с помощью орионовской MSCOMM$ была связь с PC (фирменные читалки CP/M на Пентиуме перестали работать). ОРИОНОМ я считывал программы с дискет и кассет других компьютеров и с помощью MSCOMM$ С.Коровкина переносил файлы на PC. Потому все файлы всех рэтро компьютеров на PC оказались в ORDOS-формате. И это оказалось удобно, тем более, что у меня есть ПО для работы с такими файлами на PC.
Я предложил лишь изменить расширения файлов, чтобы убрать путаницу или же ввести универсальный формат эмуляторов. Против ORD-формата возражают те, у кого осталось магнитофонное мышление пользователя из ранних лет компьютеризации.
Вот пример удобства ORD-формата. Для старта игр в своей DOS error404 пришлось файлы игр делать файлами оверлея и для каждой игры писать свой стартёр, что удвоило число файлов, загромоздив обзор. А если бы это были ORD-файлы, то это бы не понадобилось. В некоторых версиях DOS для ОРИОНА ORD-файлы запускались из CCP и любой приличный Нортон их также запускал. Хуже того, чтобы теперь эти файлы взять для старта в другой DOS, недостатчно просто скопировать DAT-файлы, приходится ковырять стартёры для каждой игры, чтобы узнать адреса и размеры и вручную конвертировать в пригодный формат.
Эти файлы запускаются в любой продвинутой версии CP/M.
Если говорить о стартере, то там он один. И не какого нового стартера для каждой игры писать не надо, достаточно подправить адреса для загрузки файлов из одного хранилища, т.е оверлея. По сути это лоадер файлов для загрузки разношерстных адаптированных игр от ZX. Получилось очень удобно. Лоадер храним в USER0, оверлеи допустим в USER1.
Да кстати Error404, стартеров не писал. Они из глубокого прошлого, насколько я помню. А что сделал Error404, он обернул оверлеи декомпрессором. Отчего размер оверлея уменьшился в разы.
И форматом ORD это не решить, он для другого был придуман. У авторов Ориона существовал аналогичный формат BRU. Вот мне интересно как их можно запускать из CP/M, когда эти форматы были придуманы для хранения файлов ORDOS на дискетах. И соответственно были рассчитаны для запуска и работы в ORDOS.
Я утверждать не буду, может у кого-то они, и запускались в СР/М, но это уже другая тема.
Да просто в Орионе первый Монитор (с командной строкой), в котором была поддержка файлов в формате РК, практически не использовался. В то же время существовал удобный механизм для работы с файлами с именем в оболочке ORDOS в виде программы CH4$, потому и был выбран этот формат в качестве ленточного rko. Со Специалистом же ситуация другая - там директивы Монитора всегда работали, поэтому использование самого простого формата, доступного для загрузки из голого Монитора, мне показалось наиболее логичным, по крайней мере тогда, в 99-м...
Кстати, ord и bru - это ведь один и тот же формат?
Что вижу о том и пишу.
Ошибаетесь. Программы типа LORD форматом ORD именно эту задачу и решили.
Без проблем.
Во-первых, с 1991 на моих дистрибутивных дискетах была программа TAPE READER, которая читала с МГ формат РК86 (формат CH$ тогда еще не распространился) и записывала на дискету в виде COM-файла, причём не такого тупого, как делали конверторы ORD в COM для банки 1 от М.Бриджиди и С.Коровкина, а в универсальный COM, который можно запускать из любой банки ОЗУ (при старте вычислялось в какой банке работает CP/M). Потому проблем с запуском игр из любой CP/M не было и ORD-формат для запуска игр был совсем не нужен. Потому и ORD-формат придумал не я. И потому встраивать старт ORD-файлов из CCP CP/M было не надо.
Некоторые программы ORDOS работают не только лишь при наличии в ОЗУ ORDOS, но главное - с файлами в квазидиске ORDOS. Потому, если снабдить ORDOS COM-файл стартёром, что перед запуском загружает на B800 ORDOS и форматирует квазидиск (так и делается при запуске ORD из нортонов в банке 1), то сама программа ORDOS (например текст.редактор) работать будет, но текстовый файл из квазидиска не считает, т.к квазидиск будет пуст. Потому-то и придумали программы типа LORD$ и PMBB$. ORD-формат был нужен как для этого, так и для того, чтобы был один файл игры, что можно запускать и из ORDOS и из нормальной DOS.
Я пользовался DOS в банке 2, а с конца 90-тых пользуюсь DOS в банке 0, причём квазидиск ORDOS можно сохранять. Для обоих случаев есть программы LORD.COM позволяющие заполнять квазидиск ORD-файлами, потому из CP/M можно использовать все программы ORDOS и запускать их из CP/M. А т.к файлы DOS$ хранились в ROM-диске, то ни CCP ORDOS-а, ни ORDOS-нортоны были вообще не нужны. По выходу из ORDOS-программы стартовал EXT$ в 20 байтов и пользователь снова мгновенно оказывался в NC или LORD CP/M. Т.е программы ORDOS оказывались точно также доступны и из CP/M, только для старта не с крошечных квазидисков ORDOS, а с дискеты, освобождая квазидиски для данных.
Понятно. Я этим заинтересовался, т.к никогда не использовал чужие эмуляторы для программ ОРИОНА (своего хватает), оттого и не знал. Думал, что и там у Вас организовалась путаница форматов из-за отсутствия фантазии на имена и желания все форматы для эмулятора сделать подобными РК86.
Естественно. В программах для BRU (ALT33$, BRU4.COM, ATLAS$) достаточно изменить 3 байта, чтобы на дискетах не надо было хранить все файлы в 2-х вариантах ORD и BRU.
На самом деле, оба варианта были. Первый (COM-файл загрузчик + файл-оверлей с кодом игры для страницы 0) был сделан в 20 веке как временное решение для АСРМ и подобных CP/M, работавших в странице 1 ОЗУ (и потому просущестововал долго став как постоянное решение :) ). Там была еще особенность в том, что несжатый код некоторых игр был больше ТРА и такие файлы можно было грузить только из оверлея внешним загрузчиком (COM-файл не может быть размером более ТРА), поэтому и не было смысла что-то менять и cделано было одинаково для всех игр ZX - и больших и мелких.
А вот когда уже в 21 веке для Альтаир-ДОС (она работает в странице 2) захотелось сделать сборник игр для SD-карты, то не стал перепиливать загрузчики для другой страницы, а прилепил распаковщик (пакер работает на РС, код игры ужимается в полтора-два раза, т.к. обычно рыхлый из-за графики и музыки) что дало уменьшение кода всех игр и теперь все они помещаются в ТРА (и можно обойтись одним файлом, без загрузчика), и распаковщик, стартуя из кода пожатого СОМ-файла игры и работая в F-области, берет входящий (сжатый) поток из страницы 2, а исходящий поток кладет сразу в нужную страницу по нужному адресу (т.е. без лишних пересылок).
Запускать ордосовское в виде СОМ-файла имеет смысл только для игр (которым по сути не надо ничего), т.к. для системных надо в ОЗУ окружение для Ордос: саму Ордос, ROM/RAM диски, корректное содержимое F-области (фонт и переменные Монитора) - все то, что работающая CP/M обычно к моменту старта этого ордософайла затерла своим кодом. Ну и такие мелочи как некуда сохранять результат.
jerri, есть ли новости об элите?
линия с исходником для специалиста
рекомендации по ускорению, улучшению, итд принимаются
Код:;hl xy начала
;de xy конца
;
;x,y 0,0
;
;
; x,y 3,4
beginning
ld hl,#1020 ; yx dest
ld de,#3060 ; yx sour
call line00
jp beginning
bitstream db #80,#40,#20,#10,#08,#04,#02,#01
;в HL - yx конца
;в DE - yx начала
line00
ld a,h ;вычисляем DY
sub d
ld bc,#141c ;создаем базовые изменения координат
jp nc,line1 ;основная пара de
inc b
;поэтому меняем DE><HL если рисуем сверху вниз
cpl
inc a
line1 ld h,a ;H=DY
ld a,l ;вычисляем DX
sub e ;
jp nc,line2
inc c ;если рисуем справа налево то меняем направление
cpl
inc a
line2 cp h ;DX=DY?
ld l,a
jp c,line3
;если меньше то считаем основной координатой DY
ld l,h
ld h,a
ld a,b
ld b,c
ld c,a
line3 ld a,b ;обозначаем как менять координаты
ld (line5),a
ld a,c
ld (line6),a
ld b,h
ld a,h
inc l
inc b
line4
push af,hl,de
;здесь печать точки - в de координаты yx
ld a,e
rra
rra
rra
and #1f
add a,#98
ld h,a
ld l,d
ld a,e
ex de,hl
and #07
ld hl,bitstream
add a,l
ld l,a
ld a,(de)
xor (hl)
ld (de),a
pop de,hl,af
line5 nop
sub l
jp nc,line7
line6 nop
add a,h
line7
dec b
jp nz,line4
ret
в тему вызывается ivagor
zx_, неправильное колдунство. Правильное такое: в тему кастуется @ivagor ! Трахти-бидохти-бидох!
Не знаю, какие ограничения есть для процедуры рисования линии в элите на специалисте, но про сократить я ничего умного в данном случае сказать не могу, процедура очень компактная. А вот ускорить можно. Если в приведенной процедуре вынести расчет адреса по координатам из цикла, а в цикле только сдвигать маску и инкрементировать составляющие адреса, то она ускориться в 2 раза. Тестировал по сумме двух циклов (x0=0, y0=0, x1=255, y1=255-0 и x0=0, y0=0, x1=255-0, y1=255). Но есть процедура, которая быстрее в 2.7 раза. Если нужно в основном рисовать средние и длинные линии (примерно >16 точек), то эту процедуру можно еще ускорить за счет развертывания циклов, но она станет непотребно толстой.
ivagor, нет ограничений
там конвейер и длина не более 252 по горизонтали и 191 по вертикали соответсвенно