Элита для Специалиста

[jerri]

какой формат файла rks?
вроде гдето видел

есть утилита для пересчета crc файла?

64780

[Pyk]

Откуда этот файл? В нем заголовок неправильный: 3 байт должен быть 81, а не 01 - это старший байт конечного адреса
Контрольная сумма файла DF3A, нужно последние 00 00 поменять на 3A DF.

Процедуру подсчет КС вот только на днях приводил:
http://zx-pk.ru/threads/6505-radio-86rk-raznoe.html?p=955672&viewfull=1#post955672

Либо из Монитора пересохранить.

[barsik]

Ваш файл не грузится потому что Вы конечный адрес указали меньше начального 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, - всё остальное гораздо хуже.

[Titus]

Подо что эта программа? У меня на эмуляторе не работает.

[jerri]

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

про crc я в курсе но формул не знаю да и нет у меня такой функции в sjasm.

[barsik]

Подо что эта программа? У меня на эмуляторе не работает.
Я запускал в эмуляторе EMU80 с указанием CPU КР580. Может быть для Вашего эмулятора мешает первый байт E6, удалите его. А вообще попадаются файлы у которых первый байт E6. Потому лучше сделать как сделали авторы других эмуляторов, - всегда игнорируйте лидирующий байт E6, это синхробайт.

[Titus]

Убрал 0xE6. Как я его не заметил.
На самом деле, этот байт в образ пихать не надо, раз его нет в большинстве образов.
Да и контрольная сумма излишня. Тем более, что стандартному загрузчику она не нужна.

[jerri]

Кстати, для написания программ для 8-ми разрядок нет альтернативы макроассемблеру M80 и текстовому редактору UltraEdit, - всё остальное гораздо хуже.

ой я вас умаляю
на вкус и цвет.
чем КС считаешь при окончательной сборке?

[barsik]

Ой я вас умаляю, на вкус и цвет...Согласен, кто к чему привык, то и лучше.

Хотя без некоторых свойств в макроассемблере (например, .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, не выше), то могу это сделать.

[Pyk]

Раз уж речь зашла о Emu80, могу еще предложить грузить файлы через Alt-F3 (с автозапуском) или Alt-L (без автозапуска). КС при этом игнорируется.
Ну или drag-n-drop'ом файл бросать в окно эмулятора, что равносильно Alt-F3.

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

jerri, вот, кстати, готовый скрипт от vinxru для формирования rks-файла с подсчетом КС:
https://github.com/alemorf/retro/blob/master/specialist-game_lines/-make-rks.js
Там же есть -compile.bat, из которого он вызывается...

[uart]

Pyk, я у себя сделал загрузку bin, файл преобразуется на ходу в текущий формат rk? с правильной контрольной суммой.

[barsik]

Pyk, я у себя сделал загрузку bin, файл преобразуется на ходу в текущий формат rk? с правильной контрольной суммой.
Направление мысли верное (облегчение жизни пользователя), но реализация идеи неверная. Я уже давно прошу авторов эмуляторов сделать то же самое, но для ORD-файлов. Т.е возможность задать в конфиг файле то, в какой именно формат автоматически конвертируется ORD-файл, если в окне открытия файла выбрать файл с расширением ORD.

Удобнее всего все программы хранить и грузить в эмуляторы в ORD-виде, а также нет препятствий для трансляции ассемблером файлов прямо в ORD-вид. В BIN-файле, а точнее в DAT-файле (потому что файл можно считать и DES, и BIN, и OCT, и HEX) нет адресов загрузки и длины.

И кстати, длина задаваемая длиной самого MSDOS-файла не годится, т.к на выходе трансляторов размер файла выдаётся кратным 128-ми байтам, а не с точностью до байта. Формат ORD допускает и КС и дату файла (и эта дата файла удобнее, т.к её можно вручную подставить, она не меняется при модификациях файла и автоматически подставляется при трансляции).

Можно конечно придумать свой формат аналогичного назначения, в котором есть адреса начальный, конечный или адрес загрузки и длина файла (что удобнее), но зачем, если уже почти 30 лет существует и успешно используется ORD-формат.

[fifan]

barsik упорно продвигает свой ord формат, несмотря на то что все программы для Специалиста идут в rks формате. И этот формат сложился де-факто как основной для Специалиста.

[barsik]

barsik упорно продвигает свой ORD формат
Формат не мой, а исторический с 1991 года и кто первый его использовал неизвестно. Он служил для хранения на дискетах программ с произвольным адресом. Хранить файлы в магнитофонном формате глупее, чем в общепризнанном дисководном.


этот формат сложился де-факто как основной для Специалиста
Как слОжился, так и разлОжится, если в эмуляторы встроить единый формат для всех платформ.

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

Зачем вообще нужно поддерживать МГ-формат базовых мониторов? Когда я в 1997-98 писал свой первый эмулятор РК86, я не стал встраивать поддержку МГ-процедур. Монитор в ПЗУ для отладки/загрузки вообще не использовался. Глупо использовать монитор в кодах КР580, если мы на IBM PC. Сам эмулятор, позволял не только отладку, но и ввод/вывод/запуск блоков в формате ORD (а когда увидел чужой эмулятор с форматом GAM, добавил загрузку GAM). МГ-формат в файлах да и сам командный монитор в ПЗУ были не нужны вообще. Задача монитора в ПЗУ в реале - только загрузка и иногда отладка, зачем же и на PC заставлять пользователя мучиться как было в реале.

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


все программы для Специалиста идут в RKS формате
Это мгновенно изменяется запуском простейшей программы написанной даже на бейсике (например, Power-бейсик для Windows), которая сканирует все файлы подкаталога в поиске RK? файлов и конвертирует их как надо, причём записывая флаг, для какого конкретно типа ЭВМ данная программа. В 4 свободных байта заголовка можно записать флаг о том, для какой конкретно ЭВМ данная программа и даже для какого процессора (Z80 или КР580).

[fifan]

Vinxru сделал свой SD контроллер с поддержкой файловой системы и запуском rks файлов по умолчанию, а что изобрёл barsik с поддержкой ord файлов?

[barsik]

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).

[marinovsoft]

Стандарты устанавливают не концептологи, а те, кто пишет ПО.

ретро - не бЭйсик

[Titus]

Я за .rks формат. Прост и самодостаточен. И весь архив игр уже в нем давно.

[barsik]

Стандарты устанавливают не концептологи, а те, кто пишет ПОТочно. Стандарты на формат файлов для эмулятора создаёт автор эмулятора, потому именно им я это и предлагал. К тому же это совсем просто, никого не напрягает, а проблему КС при трансляции решает.

К тому же, я выше упомянул, что у меня нет проблемы КС. А если бы и была, то есть простое решение без модификации эмуляторов - запускать (BAT-файлом) при старте эмулятора как бы препроцессор конвертор форматов, который из исходного каталога все находящиеся там ORD-файлы конвертирует в правильный RKS и помещает их в каталог .../EMU/spec/PROGS/.

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


Я за .RKS формат. Прост и самодостаточен. И весь архив игр уже в нём давно
Так я и не предлагал убрать RKS формат. Я лишь предложил новый (старый) универсальный формат в качестве решения проблемы подгонки КС при трансляции.

Кстати, что Вы скажете на счёт того, чтобы ввести в эмуляторы укороченный формат RKS?

Суть в том, что файл тоже с расширением 'rks', но байтов в нём меньше на 2 байта, т.е просто нет контрольной суммы. Эмулятор открывая файл должен проверить есть КС или нет, и если её нет, то посчитать и выдать посчитанную КС в конце ввода. Вот и всё решение проблемы КС при трансляции.

[Titus]

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

[Spectramine]

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

В scl есть контрольная сумма. (Ну и в спектрумовских образах ленты, постольку, поскольку в конце каждого блока идет байт контрольной суммы так же, как и на реальной ленте.) Также, вроде бы, есть в fdi/td0/udi, но не уверен.

[Titus]

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

[uart]

Файл "rk?" это образ магнитофонной записи. Если есть на ленте контрольная сумма - она должна быть и в файле, нет на ленте - нет и в файле.

[Titus]

Файл "rk?" это образ магнитофонной записи. Если есть на ленте контрольная сумма - она должна быть и в файле, нет на ленте - нет и в файле.

Не .rk, а .rks. Если запись в формате стандартного загрузчика, то там контрольной суммы вполне может не быть.

[uart]

Titus, не "rk", а "rk?". От последней буквы суть формата не меняется, просто образ магнитофонной записи для того или иного РК совместимого компьютера. rks как раз наиболее худший представитель. Мало того, что несовместимых компьютеров и их мониторов как грязи, так еще и в рамкам одного ПК нет единого стандарта.

[barsik]

несовместимых компьютеров и их мониторов как грязи, так еще и в рамкам одного ПК нет единого стандарта.
Справедливо.

Проблема из-за того, что изначально в 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. Тут в имени содержится информация и о компьютере и о формате файла.

От последней буквы суть формата не меняется
Что значит суть? Если под сутью Вы понимаете идею, то да, а вот сам формат для разных компьютеров разный.

[uart]

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

[HardWareMan]

ORD это формат файлов, во-первых, для хранения на PC, во-вторых для эмулятора, и в-третьих, для дисковых DOS в которых у файлов нет адреса. Потому такие файлы поддерживаются в моих эмуляторах РК86 и ОРИОНА и все рэтро-файлы на PC, в т.числе и для Специалиста и ИРИШИ я храню в таком виде.
И хай это останется так впредь. Продолжайте хранить свои файлы у себя в этом формате.

barsik, поздно что либо менять. Да и смысла нет, rk? это просто преобразованный wav.
Вот именно. Если тебе нужен не образ кассеты - делай другой формат (да хоть образ дискеты). Но если ты это называешь именно образом кассеты и хочешь, чтобы его грузил код написанный для кассеты - будь ласка, соблюдай устоявшийся формат. Ведь если бы он не соответствовал требованиям, он бы не продержался так долго, а вот барсиковый так нигде и не всплыл. ;) Хотя он полезен для случая связи реала с РС, который выполняет роль внешнего накопителя.

[barsik]

RK? это просто преобразованный WAV
Частично. Если бы это было так, то была бы возможна обратная конверсия, но тупо преобразованные в WAV блоки не грузятся, им не хватает пилотона и синхробайта E6.


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


а вот барсиковый [формат] так нигде и не всплылА вы давно смотрели архивы программ для ОРИОНА?

Нет у меня своего формата, я пользуюсь широко распространёнными форматами. У меня так получилось само собой, потому что только с помощью орионовской MSCOMM$ была связь с PC (фирменные читалки CP/M на Пентиуме перестали работать). ОРИОНОМ я считывал программы с дискет и кассет других компьютеров и с помощью MSCOMM$ С.Коровкина переносил файлы на PC. Потому все файлы всех рэтро компьютеров на PC оказались в ORDOS-формате. И это оказалось удобно, тем более, что у меня есть ПО для работы с такими файлами на PC.

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

Вот пример удобства ORD-формата. Для старта игр в своей DOS error404 пришлось файлы игр делать файлами оверлея и для каждой игры писать свой стартёр, что удвоило число файлов, загромоздив обзор. А если бы это были ORD-файлы, то это бы не понадобилось. В некоторых версиях DOS для ОРИОНА ORD-файлы запускались из CCP и любой приличный Нортон их также запускал. Хуже того, чтобы теперь эти файлы взять для старта в другой DOS, недостатчно просто скопировать DAT-файлы, приходится ковырять стартёры для каждой игры, чтобы узнать адреса и размеры и вручную конвертировать в пригодный формат.

[OrionExt]

Для старта игр в своей DOS error404 пришлось файлы игр делать файлами оверлея и для каждой игры писать свой стартёр, что удвоило число файлов, загромоздив обзор.
Эти файлы запускаются в любой продвинутой версии CP/M.

Если говорить о стартере, то там он один. И не какого нового стартера для каждой игры писать не надо, достаточно подправить адреса для загрузки файлов из одного хранилища, т.е оверлея. По сути это лоадер файлов для загрузки разношерстных адаптированных игр от ZX. Получилось очень удобно. Лоадер храним в USER0, оверлеи допустим в USER1.

Да кстати Error404, стартеров не писал. Они из глубокого прошлого, насколько я помню. А что сделал Error404, он обернул оверлеи декомпрессором. Отчего размер оверлея уменьшился в разы.


А если бы это были ORD-файлы, то это бы не понадобилось. В некоторых версиях DOS для ОРИОНА ORD-файлы запускались из CCP и любой приличный Нортон их также запускал.
И форматом ORD это не решить, он для другого был придуман. У авторов Ориона существовал аналогичный формат BRU. Вот мне интересно как их можно запускать из CP/M, когда эти форматы были придуманы для хранения файлов ORDOS на дискетах. И соответственно были рассчитаны для запуска и работы в ORDOS.

Я утверждать не буду, может у кого-то они, и запускались в СР/М, но это уже другая тема.

[Pyk]

Кстати, непонятно как поступили с ОРИОНОМ у которого первый формат это формат РК, а второй - формат с именем, где имя необходимо. Логично использовать RKR (хотя программа не для РК) и расширение RKO для формата с именем.
Да просто в Орионе первый Монитор (с командной строкой), в котором была поддержка файлов в формате РК, практически не использовался. В то же время существовал удобный механизм для работы с файлами с именем в оболочке ORDOS в виде программы CH4$, потому и был выбран этот формат в качестве ленточного rko. Со Специалистом же ситуация другая - там директивы Монитора всегда работали, поэтому использование самого простого формата, доступного для загрузки из голого Монитора, мне показалось наиболее логичным, по крайней мере тогда, в 99-м...

Кстати, ord и bru - это ведь один и тот же формат?

[barsik]

Если говорить о стартере, то там он одинЧто вижу о том и пишу.


И форматом ORD это не решить, он для другого был придуман.Ошибаетесь. Программы типа LORD форматом ORD именно эту задачу и решили.


Вот мне интересно как их можно запускать из CP/M, когда эти форматы были придуманы для хранения файлов ORDOS на дискетах. И соответственно были рассчитаны для запуска и работы в ORDOS.
Без проблем.

Во-первых, с 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, а с дискеты, освобождая квазидиски для данных.


потому и был выбран этот формат [с именем] в качестве ленточного .rko
Понятно. Я этим заинтересовался, т.к никогда не использовал чужие эмуляторы для программ ОРИОНА (своего хватает), оттого и не знал. Думал, что и там у Вас организовалась путаница форматов из-за отсутствия фантазии на имена и желания все форматы для эмулятора сделать подобными РК86.


Кстати, ord и bru - это ведь один и тот же формат?Естественно. В программах для BRU (ALT33$, BRU4.COM, ATLAS$) достаточно изменить 3 байта, чтобы на дискетах не надо было хранить все файлы в 2-х вариантах ORD и BRU.

[Error404]

Да кстати Error404, стартеров не писал. Они из глубокого прошлого, насколько я помню. А что сделал Error404, он обернул оверлеи декомпрессором. Отчего размер оверлея уменьшился в разы.


На самом деле, оба варианта были. Первый (COM-файл загрузчик + файл-оверлей с кодом игры для страницы 0) был сделан в 20 веке как временное решение для АСРМ и подобных CP/M, работавших в странице 1 ОЗУ (и потому просущестововал долго став как постоянное решение :) ). Там была еще особенность в том, что несжатый код некоторых игр был больше ТРА и такие файлы можно было грузить только из оверлея внешним загрузчиком (COM-файл не может быть размером более ТРА), поэтому и не было смысла что-то менять и cделано было одинаково для всех игр ZX - и больших и мелких.

А вот когда уже в 21 веке для Альтаир-ДОС (она работает в странице 2) захотелось сделать сборник игр для SD-карты, то не стал перепиливать загрузчики для другой страницы, а прилепил распаковщик (пакер работает на РС, код игры ужимается в полтора-два раза, т.к. обычно рыхлый из-за графики и музыки) что дало уменьшение кода всех игр и теперь все они помещаются в ТРА (и можно обойтись одним файлом, без загрузчика), и распаковщик, стартуя из кода пожатого СОМ-файла игры и работая в F-области, берет входящий (сжатый) поток из страницы 2, а исходящий поток кладет сразу в нужную страницу по нужному адресу (т.е. без лишних пересылок).



И форматом ORD это не решить, он для другого был придуман. У авторов Ориона существовал аналогичный формат BRU. Вот мне интересно как их можно запускать из CP/M, когда эти форматы были придуманы для хранения файлов ORDOS на дискетах. И соответственно были рассчитаны для запуска и работы в ORDOS.


Запускать ордосовское в виде СОМ-файла имеет смысл только для игр (которым по сути не надо ничего), т.к. для системных надо в ОЗУ окружение для Ордос: саму Ордос, ROM/RAM диски, корректное содержимое F-области (фонт и переменные Монитора) - все то, что работающая CP/M обычно к моменту старта этого ордософайла затерла своим кодом. Ну и такие мелочи как некуда сохранять результат.

[zx_]

jerri, есть ли новости об элите?

[jerri]

jerri, есть ли новости об элите?

играбельного пока, извините, нет.
но я не бросил, не думайте.

[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

[zx_]

в тему вызывается ivagor

[ZX_NOVOSIB]

zx_, неправильное колдунство. Правильное такое: в тему кастуется ivagor ! Трахти-бидохти-бидох!

[ivagor]

Не знаю, какие ограничения есть для процедуры рисования линии в элите на специалисте, но про сократить я ничего умного в данном случае сказать не могу, процедура очень компактная. А вот ускорить можно. Если в приведенной процедуре вынести расчет адреса по координатам из цикла, а в цикле только сдвигать маску и инкрементировать составляющие адреса, то она ускориться в 2 раза. Тестировал по сумме двух циклов (x0=0, y0=0, x1=255, y1=255-0 и x0=0, y0=0, x1=255-0, y1=255). Но есть процедура (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=941952&viewfull=1#post941952), которая быстрее в 2.7 раза. Если нужно в основном рисовать средние и длинные линии (примерно >16 точек), то эту процедуру можно еще ускорить за счет развертывания циклов, но она станет непотребно толстой.

[jerri]

ivagor, нет ограничений
там конвейер и длина не более 252 по горизонтали и 191 по вертикали соответсвенно

[jerri]

появилось время
пересмотрел линию
теперь будет быстрее



bitstream db #80,#40,#20,#10,#08,#04,#02,#01




;в DE - yx начала
;в HL - yx конца
line00
ld a,h
sub d
;h<d?
jp nc,line1
;h>d
ex de,hl
cpl
inc a
line1
ld b,a
;b=vertical cntr DY

ld a,l
sub e
;a=DX
;e<l?
jp nc,line_lr
;e>l
line_rl
cpl
inc a
ld c,a
;c=horizontal cntr
cp b
;c?b
jp c,line_rlv
;c>b
line_rlh
display "line_rlh ",$
;right left horizontal
call de_coo
ld a,b
ld d,c
inc d
line_rlh0
push af
ld a,(hl)
xor e
ld (hl),a

ld a,e
or a
rla
jp nc,line_rlhb
ld a,1
dec h
line_rlhb
ld e,a
pop af
sub b
jp nc,line_rlh1
add a,c
inc l
line_rlh1
dec d
jp nz,line_rlh0
ret
line_rlv
display "line_rlv ",$
;right left vertical
call de_coo
ld a,c
ld d,b
inc d
line_rlv0
push af
ld a,(hl)
xor e
ld (hl),a
inc l
pop af
sub c
jp nc,line_rlv1
add a,b

push af
ld a,e
or a
rla
jp nc,line_rlvb
ld a,1
dec h
line_rlvb
ld e,a
pop af
line_rlv1
dec d
jp nz,line_rlv0
ret









line_lr
ld c,a
cp b
;c?b
jp c,line_lrv
;c>b

line_lrh
display "line_lrh ",$

;left right horizontal
call de_coo
ld a,b
ld d,c
inc d
line_lrh0
push af
ld a,(hl)
xor e
ld (hl),a

ld a,e
or a
rra
jp nc,line_lrhb
ld a,128
inc h
line_lrhb
ld e,a
pop af
sub b
jp nc,line_lrh1
add a,c
inc l
line_lrh1
dec d
jp nz,line_lrh0
ret
line_lrv
display "line_rlv ",$

;left right vertical
call de_coo
ld a,c
ld d,b
inc d
line_lrv0
push af
ld a,(hl)
xor e
ld (hl),a
inc l
pop af
sub c
jp nc,line_lrv1
add a,b

push af
ld a,e
or a
rra
jp nc,line_lrvb
ld a,128
inc h
line_lrvb
ld e,a
pop af
line_lrv1
dec d
jp nz,line_lrv0
ret
de_coo
;de=source
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 l,(hl)
ex de,hl
;hl=addr
;e=bitstream
ret

[blackmirror]

Не должно быть в цикле рисования линии push/pop af, лучше dx или dy встроить в код и править при вызове.

[jerri]

blackmirror, поясни

[blackmirror]

jerri, сейчас ошибка лежит в A, а в BC лежит dx и dy, но чтобы поменять точку или маску приходится сохранять A в стеке, поскольку регистров не хватает. Можно одну из инструкций sub/add b/c поменять на инструкцию с константой, которая будет меняться на реальный dx или dy перед циклом. А ошибку переместить в освободившийся регистр, откуда её быстрее будет достать чем из стека.

[jerri]

jerri, сейчас ошибка лежит в A, а в BC лежит dx и dy, но чтобы поменять точку или маску приходится сохранять A в стеке, поскольку регистров не хватает. Можно одну из инструкций sub/add b/c поменять на инструкцию с константой, которая будет меняться на реальный dx или dy перед циклом. А ошибку переместить в освободившийся регистр, откуда её быстрее будет достать чем из стека.

вариант конечно.



bitstream db #80,#40,#20,#10,#08,#04,#02,#01




;в DE - yx начала
;в HL - yx конца
line00
ld a,h
sub d
;h<d?
jp nc,line1
;h>d
ex de,hl
cpl
inc a
line1
ld b,a
;b=vertical cntr DY

ld a,l
sub e
;a=DX
;e<l?
jp nc,line_lr
;e>l
line_rl
cpl
inc a
ld c,a
;c=horizontal cntr
cp b
;c?b
jp c,line_rlv
;c>b
line_rlh
;right left horizontal
call de_coo
ld a,b
ld (line_rlhb0),a
ld d,c
inc d
line_rlh0
ld a,(hl)
xor e
ld (hl),a

ld a,e
or a
rla
jp nc,line_rlhb
ld a,1
dec h
line_rlhb
ld e,a
ld a,b
sub 0 ;b
line_rlhb0 equ $-1
jp nc,line_rlh1
add a,c
inc l
line_rlh1
ld b,a
dec d
jp nz,line_rlh0
ret
line_rlv
;right left vertical
call de_coo
ld a,c
ld (line_rlvb0),a
ld d,b
inc d
line_rlv0
ld a,(hl)
xor e
ld (hl),a
inc l
ld a,c
sub 0 ;c
line_rlvb0 equ $-1
ld c,a
jp nc,line_rlv1
add a,b
ld c,a

ld a,e
or a
rla
jp nc,line_rlvb
ld a,1
dec h
line_rlvb
ld e,a
line_rlv1
dec d
jp nz,line_rlv0
ret

line_lr
ld c,a
cp b
;c?b
jp c,line_lrv
;c>b

line_lrh

;left right horizontal
call de_coo
ld a,b
ld (line_lrhb0),a
ld d,c
inc d
line_lrh0
ld a,(hl)
xor e
ld (hl),a

ld a,e
or a
rra
jp nc,line_lrhb
ld a,128
inc h
line_lrhb
ld e,a
ld a,b
sub 0 ;b
line_lrhb0 equ $-1
jp nc,line_lrh1
add a,c
inc l
line_lrh1
ld b,a
dec d
jp nz,line_lrh0
ret
line_lrv

;left right vertical
call de_coo
ld a,c
ld (line_lrvb0),a
ld d,b
inc d
line_lrv0
ld a,(hl)
xor e
ld (hl),a
inc l
ld a,c
sub 0 ;c
line_lrvb0 equ $-1
ld c,a
jp nc,line_lrv1
add a,b
ld c,a
ld a,e
or a
rra
jp nc,line_lrvb
ld a,128
inc h
line_lrvb
ld e,a
line_lrv1
dec d
jp nz,line_lrv0
ret
de_coo
;de=source
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 l,(hl)
ex de,hl
;hl=addr
;e=bitstream
ret

[blackmirror]

Не уверен в нужности ld a,1/ld a,128 после rra/rla и условного перехода, может там нужны rrca/rlca ?

[Lethargeek]

рекомендации по ускорению, улучшению, итд принимаются
ты бы хоть инфы сперва дал побольше - для начала, линию рисуешь куда? в буфер, повторяющий структуру (части) экрана?

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

и сколько памяти позволительно потратить на процедуру?

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

так, навскидку, основной цикл раза в полтора возможно ускорить

[jerri]

ты бы хоть инфы сперва дал побольше - для начала, линию рисуешь куда? в буфер, повторяющий структуру (части) экрана?


ты Элиту на Акорне видел?

все рисуется на экран - экран большой буферизовать не куда




и сколько памяти позволительно потратить на процедуру?

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

так, навскидку, основной цикл раза в полтора возможно ускорить

ну ты код то пиши

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


Не уверен в нужности ld a,1/ld a,128 после rra/rla и условного перехода, может там нужны rrca/rlca ?

если эта команда есть в наборе i8080 то думаю можно и так.


ссыль на последний RKS (https://www.dropbox.com/s/bmlq6jzh75gregj/eliteline.rks?dl=0)

[HardWareMan]

Не уверен в нужности ld a,1/ld a,128 после rra/rla и условного перехода, может там нужны rrca/rlca ?
если эта команда есть в наборе i8080 то думаю можно и так.
В треде про i8080 попрошу говорить на его мнемониках. В контексте процитированного, у i8080 есть RLC/RRC/RAL и RAR. Первые два цикличные с копированием в 'C, вторые через 'C.

[jerri]

В треде про i8080 попрошу говорить на его мнемониках. В контексте процитированного, у i8080 есть RLC/RRC/RAL и RAR. Первые два цикличные с копированием в 'C, вторые через 'C.

я бы не против но эти ваши мнемоники i8080 дичайшая дичь
мнемоники z80 более логичны и просты для понимания
для сравнения

INX B INC BC
INR B INC B

согласись то что в правой колонке понятно без доп пояснений

ну и как бы SJAsm эти ваши i8080 мнемоники не знает

[Lethargeek]

ты Элиту на Акорне видел?
это в которой всё мерцает и мигает? а у тебя еще и проц дохлей примерно в два раза


все рисуется на экран - экран большой буферизовать не куда
но ты же не на весь экран рисуешь... или на весь??


ну ты код то пиши
я бы сделал как-нибудь вот так:

; основной цикл для "горизонтальных" отрезков

; "прямая" подветка
_hh0:
or (hl)
ld (hl),a
dec CTR
ret z
_hh1:
ld a,ERR
sub DY
ld ERR,a
jp c,_hd2
_hh2:
ld a,MASK
rrca
ld MASK,a
jp nc,_hh0
inc h
or (hl)
ld (hl),a
dec CTR
jp nz,_hh1
ret

; "диагональная" подветка
_hd0:
or (hl)
ld (hl),a
dec CTR
ret z
_hd1:
ld a,ERR
sub (DY-DX)
ld ERR,a
jp nc,_hh2
_hd2:
inc l
ld a,MASK
rrca
ld MASK,a
jp nc,_hd0
inc h
or (hl)
ld (hl),a
dec CTR
jp nz,_hd1
ret

основной цикл для "вертикальных" - аналогично
CTR, MASK, ERR - распихиваешь в любые из регистров b c d e
в оставшийся свободный можно поместить одно из значений DY или (DY-DX)
второе придётся вписывать прямо в код

[jerri]

это в которой всё мерцает и мигает? а у тебя еще и проц дохлей примерно в два раза


ну во первых они вычисляют каждую точку
чтото похожее на первый вариант брошенный сюда




но ты же не на весь экран рисуешь... или на весь??


в оригинале кусок экрана 192*256


много лишних телодвижений


я бы сделал как-нибудь вот так:

; основной цикл для "горизонтальных" отрезков

; "прямая" подветка
_hh0:
xor (hl)
ld (hl),a
dec CTR
ret z
ld a,MASK
rrca
ld MASK,a
jp nc,_hh0
inc h
jp _hh0
; "диагональная" подветка
_hd0:
or (hl)
ld (hl),a
dec CTR
ret z
inc l
ld a,MASK
rrca
ld MASK,a
jp nc,_hd0
inc h
jp _hd0

основной цикл для "вертикальных" - аналогично
CTR, MASK, ERR - распихиваешь в любые из регистров b c d e
в оставшийся свободный можно поместить одно из значений DY или (DY-DX)
второе придётся вписывать прямо в код

короче ты предлагаешь добавить еще по 3 варианта линий
и да - линии рисуются по XOR

[blackmirror]

jerri, для горизонтальных линий |dx|>|dy| цикл можно разделить на 3 части: две рисуют хвосты не кратные 8 точкам, а средняя часть разворачивается для 8 точек и рисует без сдвига маски. Тогда dx, dx-dy, err и cnt помещаются в регистрах, исчезает сдвиг маски и счётчик проверяется один раз на 8 точек. Но требуются варианты на увеличение и уменьшение Y, (или правка 8 инструкций в основной части и 2 в хвостах для диагональной подветки).

[Lethargeek]

ну во первых они вычисляют каждую точку
чтото похожее на первый вариант брошенный сюда
всё равно без буфера получится эпилепсия


в оригинале кусок экрана 192*256
так это только 6 кб! а еще бока экрана можно использовать под нераздражающий нужный "мусор"


много лишних телодвижений
"лишние телодвижения" - это лишние потраченные такты
у тебя сейчас (по последнему вложению) в цикле получается 88-102 такта на пиксель (кстати, ora перед rrca - лишнее)
у меня в примере 76-87 тактов на пиксель, причём в среднем (с учётом вероятности переходов) должно быть ближе к 77


короче ты предлагаешь добавить еще по 3 варианта линий
короче, не тупи! это был кусок для dx>dy, еще нужен лишь один похожий для dy>dx

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


и да - линии рисуются по XOR
да хоть как на спектруме команды динамически заменяй

[blackmirror]

еще можно для "сильногоризонтальных" добавить ветку, как только что предложил blackmirror
но, возможно, эффект слишком незначительный по сравнению с z80 получится, и для немногих
Там эффект будет и для 254/255 тоже, в развернутом цикле будет ld/xor/ld для модификации точки, ld/sub/ld для изменения ошибки, jc для перехода в другую ветку, плюс inc/dec y в диагональной ветке. А счётчк и x будут модифицироваться один раз на 8 точек.

[HardWareMan]

jerri, опять - двадцать пять. Достаточно было упомянуть SJAsm, что дескать это он не понимает язык оригинала, но нет, надо обязательно впихнуть своё мнение что "дичь", что тяжело запомнить и не логично. Ну да, я слышал, что современная молодежь имеет проблемы с памятью, но ты то вроде не из этих.

А, понятно, если бы ты упомянул только SJAsm, я бы естественно порекомендовал другой, который может. В общем, секта как есть, в действии. Вот поэтому "Илиты" никогда не будет на i8080, потому как она будет на недо-Z80.

[ivagor]

HardWareMan, если программисту удобнее мнемоники z80, если привычный инструментарий для них, если больше вероятность отклика и содействия других программистов (понимающих мнемоники z80 на форуме побольше, чем помнящих/понимающих 8080), то лучше их и использовать. Если результат будет приемлемо работать на 8080, то на чем исходная программа - совершенно без разницы, хоть с включением фрагментов C, бейсика и чего угодно. Задача и так сложная и объемная, зачем еще ставить дополнительные барьеры и проверять на прочность мотивацию.

[shurik-ua]

Я подозреваю гдето в мире уже ктото сделал набор регулярных выражений которые из одной мнемоники делают другую.

[ivagor]

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

[jerri]

всё равно без буфера получится эпилепсия





так это только 6 кб! а еще бока экрана можно использовать под нераздражающий нужный "мусор"

мне пока нечего туда пихать




"лишние телодвижения" - это лишние потраченные такты
у тебя сейчас (по последнему вложению) в цикле получается 88-102 такта на пиксель (кстати, ora перед rrca - лишнее)
у меня в примере 76-87 тактов на пиксель, причём в среднем (с учётом вероятности переходов) должно быть ближе к 77

ora рудимент от rra

ну для горизонтальных и вертикальных линий и диагональных линий я и твое слегка ускорил
только я боюсь экономия будет около 0.1% по факту изза малого количества таких линий





короче, не тупи! это был кусок для dx>dy, еще нужен лишь один похожий для dy>dx


у меня и так используются 4 подпрограммы - угол 0-45 45-90 слева направо и столько же справа налево



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


расчеты сожрут всю выгоду от скорости.
эт я еще до кругов не дошел.

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


jerri, опять - двадцать пять. Достаточно было упомянуть SJAsm, что дескать это он не понимает язык оригинала, но нет, надо обязательно впихнуть своё мнение что "дичь", что тяжело запомнить и не логично. Ну да, я слышал, что современная молодежь имеет проблемы с памятью, но ты то вроде не из этих.


мое мнение про дичь это мое мнение
ты отрицаешь что мнемоники z80 более логичны и удобны?



А, понятно, если бы ты упомянул только SJAsm, я бы естественно порекомендовал другой, который может. В общем, секта как есть, в действии. Вот поэтому "Илиты" никогда не будет на i8080, потому как она будет на недо-Z80.

ага это будет некошерная Илита потому что скомпилирована на некошерном компиляторе и написана некошерными мнемониками? так чтоли?

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

текущая версия линии
дополнения, предложения есть?



bitstream db #80,#40,#20,#10,#08,#04,#02,#01




;в DE - yx начала
;в HL - yx конца
line00
ld a,h
sub d
;h<d?
jp nc,line1
;h>d
ex de,hl
cpl
inc a
line1
ld b,a
;b=vertical cntr DY

ld a,l
sub e
;a=DX
;e<l?
jp nc,line_lr
;e>l
line_rl
cpl
inc a
ld c,a
;c=horizontal cntr
cp b
;c?b
jp c,line_rlv
;c>b

or b
jp nz,line_rlh
inc c
line_rlh
;right left horizontal
call de_coo
ld a,b
ld (line_rlhb0),a
ld d,c
ld a,e
line_rlh0
xor (hl)
ld (hl),a

ld a,b
sub 0 ;b
line_rlhb0 equ $-1
jp nc,line_rlh1
add a,c
inc l
line_rlh1
ld b,a

ld a,e
rlca
ld e,a
jp nc,line_rlhb
dec h
line_rlhb
dec d
jp nz,line_rlh0
ret
line_rlv
;right left vertical
or b
jp nz,line_rlv2
inc b
line_rlv2
call de_coo
ld a,c
ld (line_rlvb0),a
ld d,b
line_rlv0
ld a,(hl)
xor e
ld (hl),a
inc l
ld a,c
sub 0 ;c
line_rlvb0 equ $-1
ld c,a
jp nc,line_rlv1
add a,b
ld c,a

ld a,e
or a
rlca
ld e,a
jp nc,line_rlv1
dec h
line_rlv1
dec d
jp nz,line_rlv0
ret

line_lr
ld c,a
cp b
;c?b
jp c,line_lrv
;c>b
or b
jp nz,line_lrh
inc c
line_lrh

;left right horizontal
call de_coo
ld a,b
ld (line_lrhb0),a
ld d,c
ld a,e
line_lrh0
xor (hl)
ld (hl),a

ld a,b
sub 0 ;b
line_lrhb0 equ $-1
jp nc,line_lrh1
add a,c
inc l
line_lrh1
ld b,a

ld a,e
rrca
ld e,a
jp nc,line_lrhb
inc h
line_lrhb
dec d
jp nz,line_lrh0
ret
line_lrv

or b
jp nz,line_lrv2
inc b
line_lrv2
;left right vertical
call de_coo
ld a,c
ld (line_lrvb0),a
ld d,b
line_lrv0
ld a,(hl)
xor e
ld (hl),a
inc l
ld a,c
sub 0 ;c
line_lrvb0 equ $-1
ld c,a
jp nc,line_lrv1
add a,b
ld c,a
ld a,e
rrca
ld e,a
jp nc,line_lrv1
inc h
line_lrv1
dec d
jp nz,line_lrv0
ret
de_coo
;de=source
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 l,(hl)
ex de,hl
;hl=addr
;e=bitstream
ret

[Lethargeek]

мне пока нечего туда пихать
да хоть код пихай


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


у меня и так используются 4 подпрограммы - угол 0-45 45-90 слева направо и столько же справа налево
да при чём тут это? можно сделать ветки, можно код перед входом патчить, дело в другом
у меня в примере обе подветки - части ОДНОГО цикла, рисующего слева направо для dx>dy
они обе в цикле отрабатывают, но в разных пропорциях в зависимости от наклона отрезка
вычитание из ошибки разных чисел в разных подветках избавляет от коррекции ошибки:

add a,c
+ регистр еще при этом освобождает



расчеты сожрут всю выгоду от скорости.
какие расчёты? плюс одна проверка, переход, сдвиг
другое дело, что выгодных отрезков немного будет



текущая версия линии
всё еще 80-94 такта на пиксель (в цикле для лежачих отрезков)


дополнения, предложения есть?
второй недостаток:

rrca
ld e,a
jp nc,line_lrhb
inc h
line_lrhb
dec d
jp nz,line_lrh0
ret
вероятность выхода по завершению заведомо очень низкая
потому вместо jp выгоднее проверять на ноль условным ret
а для этого перенести декремент с проверкой в начало
и переход на него совместить с условным переходом после rrca
(который, напротив, происходит часто - в 7 из 8 случаев)
выигрыш - 5 тактов на каждый пиксель
у меня в примере уже так сделано

[jerri]

да хоть код пихай

зачем?




да при чём тут это? можно сделать ветки, можно код перед входом патчить, дело в другом
у меня в примере обе подветки - части ОДНОГО цикла, рисующего слева направо для dx>dy
они обе в цикле отрабатывают, но в разных пропорциях в зависимости от наклона отрезка
вычитание из ошибки разных чисел в разных подветках избавляет от коррекции ошибки:


у тебя ошибка в коде
сделай нормальную линию




какие расчёты? плюс одна проверка, переход, сдвиг
другое дело, что выгодных отрезков немного будет

о чем и речь




всё еще 80-94 такта на пиксель (в цикле для лежачих отрезков)


второй недостаток:

вероятность выхода по завершению заведомо очень низкая
потому вместо jp выгоднее проверять на ноль условным ret
а для этого перенести декремент с проверкой в начало
и переход на него совместить с условным переходом после rrca
(который, напротив, происходит часто - в 7 из 8 случаев)
выигрыш - 5 тактов на каждый пиксель
у меня в примере уже так сделано

ну это можно поправить
видел бы ты оригинал, идеалист блин

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

Lethargeek
смотри что скажешь?



bitstream db #80,#40,#20,#10,#08,#04,#02,#01




;в DE - yx начала
;в HL - yx конца
line00
ld a,h
sub d
;h<d?
jp nc,line1
;h>d
ex de,hl
cpl
inc a
line1
ld b,a
;b=vertical cntr DY

ld a,l
sub e
;a=DX
;e<l?
jp nc,line_lr
;e>l
line_rl
cpl
inc a
ld c,a
;c=horizontal cntr
cp b
;c?b
jp c,line_rlv
;c>b

or b
jp nz,line_rlh
inc c
line_rlh
;right left horizontal
call de_coo
ld a,b
ld (line_rlhb0),a
ld d,c
ld a,e
line_rlh0
xor (hl)
ld (hl),a
dec d
ret z
line_rlh2
ld a,b
sub 0 ;b
line_rlhb0 equ $-1
jp nc,line_rlh1
add a,c
inc l
line_rlh1
ld b,a

ld a,e
rlca
ld e,a
jp nc,line_rlh0
dec h

xor (hl)
ld (hl),a

dec d
jp nz,line_rlh2
ret
line_rlv
;right left vertical
or b
jp nz,line_rlv2
inc b
line_rlv2
call de_coo
ld a,c
ld (line_rlvb0),a
ld d,b
line_rlv0
ld a,(hl)
xor e
ld (hl),a
dec d
ret z
line_rlv1
inc l ;движение по вертикали
ld a,c
sub 0 ;c
line_rlvb0 equ $-1
ld c,a
jp nc,line_rlv0
;движение по горизонтали
add a,b
ld c,a

ld a,e
or a
rlca
ld e,a
jp nc,line_rlv3
dec h
line_rlv3
xor (hl)
ld (hl),a

dec d
jp nz,line_rlv1
ret

line_lr
ld c,a
cp b
;c?b
jp c,line_lrv
;c>b
or b
jp nz,line_lrh
inc c
line_lrh

;left right horizontal
call de_coo
ld a,b
ld (line_lrhb0),a
ld d,c
ld a,e
line_lrh0
xor (hl)
ld (hl),a
dec d
ret z
line_lrh2
ld a,b
sub 0 ;b
line_lrhb0 equ $-1
jp nc,line_lrh1
;движение по вертикали
add a,c
inc l
line_lrh1
ld b,a

ld a,e
rrca
ld e,a
jp nc,line_lrh0
inc h
xor (hl)
ld (hl),a

dec d
jp nz,line_lrh2
ret
line_lrv

or b
jp nz,line_lrv2
inc b
line_lrv2
;left right vertical
call de_coo
ld a,c
ld (line_lrvb0),a
ld d,b
line_lrv0
ld a,(hl)
xor e
ld (hl),a

dec d
ret z
line_lrv1
inc l
ld a,c
sub 0 ;c
line_lrvb0 equ $-1
ld c,a
jp nc,line_lrv0

add a,b
ld c,a
ld a,e
rrca
ld e,a
jp nc,line_lrv3
inc h
line_lrv3
xor (hl)
ld (hl),a
dec d
jp nz,line_lrv1
ret
de_coo
;de=source
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 l,(hl)
ex de,hl
;hl=addr
;e=bitstream
ret



https://www.dropbox.com/s/bmlq6jzh75gregj/eliteline.rks?dl=0 в работе

[Lethargeek]

зачем?
чтобы место не пропадало (у тебя на буфер же не хватало)
ну и суй на боковушки редкоизменяемые данные или код


у тебя ошибка в коде
где конкретно? это адаптация со спека, там же работало


сделай нормальную линию
что значит "нормальную"? медленней? :v2_laugh:


смотри что скажешь?
лучше, но ~5 тактов для лежачих линий всё так же лишние (для стоячих кабы не еще больше)

[jerri]

буфер не предусмотрен
и к тому же он сожрет всю скорость специалиста

так что вариант только один - рисовать достаточно быстро



где конкретно? это адаптация со спека, там же работало

ты отнимаешь DX а DY не прибавляешь



лучше, но ~5 тактов для лежачих линий всё так же лишние (для стоячих кабы не еще больше)

выигрыш не ощущается
я не дему с лежачими линиями пишу

там много больше лишнего
диагональные линии - тупо
inc l и rlca/rrca

горизонтальные
rlca/rrca

вертикальные
inc l



что значит "нормальную"? медленней? :v2_laugh:


рабочую версию для специалиста
чтобы рисовал вертикальную, горизонтальную и наклонные линии

[Lethargeek]

буфер не предусмотрен
и к тому же он сожрет всю скорость специалиста
ерунда, обсчёт 3D сжирает больше в разы
тут добавится только время на переброску буфера
но хоть мигать не будет


ты отнимаешь DX а DY не прибавляешь
:v2_laugh: :v2_dizzy_facepalm:
во-1, всё наоборот (для лежачих) - перепутал ты сейчас DX и DY
во-2, посмотри внимательно вот сюда, в код второй подветки того же цикла:

_hd1:
ld a,ERR
sub (DY-DX)
ld ERR,a
jp nc,_hh2
помнишь школьное правило "минус на минус даёт плюс"?
так что нету никакой ошибки - прибавление из цикла вынесено


рабочую версию для специалиста
чтобы рисовал вертикальную, горизонтальную и наклонные линии
ты совсем уже обленился :D

[jerri]

ерунда, обсчёт 3D сжирает больше в разы
тут добавится только время на переброску буфера
но хоть мигать не будет


обсчет 3д даже на спеке вполне сравним с перебросом экрана (всего кстати 4к)
а вот насчет специалиста я вообще не уверен. во первых 6к во вторых команды для переброски слабоваты.



:v2_laugh: :v2_dizzy_facepalm:
во-1, всё наоборот (для лежачих) - перепутал ты сейчас DX и DY
во-2, посмотри внимательно вот сюда, в код второй подветки того же цикла:


ничего я не путал.
при рисовании по горизонтали DY вычитаем DX прибавляем
при рисовании по вертикали DX вычитаем DY прибавляем



помнишь школьное правило "минус на минус даёт плюс"?
так что нету никакой ошибки - прибавление из цикла вынесено


я не вижу рабочей версии твоей программы

[Lethargeek]

обсчет 3д даже на спеке вполне сравним с перебросом экрана (всего кстати 4к)
доооо, канешна:

например, при отлёте глядя в задний экран время отрисовки станции = 80-90 тыщ тактов
пауза между отрисовками, то есть всё остальное время игрового кадра ~480 тыщ тактов
из которых надо сразу вычесть еще 90 тыщ на очистку и переброску буфера
разница в 5 раз... ну, пусть в 4 раза... или что же тогда жрёт основную часть ~400 тыщ тактов, если не 3d-расчёты, по-твоему?


ничего я не путал.
при рисовании по горизонтали DY вычитаем DX прибавляем
при рисовании по вертикали DX вычитаем DY прибавляем
нет, всё ты перепутал, заявляя:

ты отнимаешь DX а DY не прибавляешь
тогда как в примере вычитал я как раз DY, как и положено


я не вижу рабочей версии твоей программы
не наглей, я не обязан делать за тебя всю работу, да и времени сейчас на это у меня нет
дал пример проверенного на спеке способа экономичного обсчёта ошибки
понимающему - достаточно, не желаешь пробовать и думать - ССЗБ

[ivagor]

Сравнил скорость последней версии линии (https://zx-pk.ru/threads/28977-elita-dlya-spetsialista.html?p=999710&viewfull=1#post999710) jerri и линии blackmirrora (https://zx-pk.ru/threads/21907-demo-effekty-dlya-vektora.html?p=941952&viewfull=1#post941952), которую уже упоминал (https://zx-pk.ru/threads/28977-elita-dlya-spetsialista.html?p=997923&viewfull=1#post997923) в этой теме. Тестировал как написано в упоминаемом посте. Текущий вариант jerri на несколько байт короче и на несколько процентов медленнее.
Отмечу, что в посте blackmirrora он кое-где использовал команды z80 отсутствующие у 8080, но замена там очевидна.
У jerri осталась лишняя команда OR A в районе между line_rlvb0 и line_rlv3 (тестировал без нее).
Я это все к чему. Достигнутая скорость линии вполне товарная, быстрее можно, но не намного, если не отказываться от сдвига маски и не разворачивать цикл.

[jerri]

на данный момент длина процедуры 214 байт - есть ли смысл раздувать вот это в 8 раз ради

ivagor, сколько даст ускорения вот этот вот этот разворот цикла?

[ivagor]

есть ли смысл раздувать вот это в 8 раз
Нет, для элиты конечно не надо раздувать. При заполнении линиями квадрата 256x256 выигрыш 20-21%, для квадрата 128x128 - 18-19%, дальше я промежуточные не замерял, а в районе 15x15-16x16 точек процедуры сравниваются по скорости. На коротких линиях без развертывания быстрее, громоздкая инициализация самомодифицирующегося кода съедает выигрыш.
Понятно, что для применений, где нужна бескомпромиссная максимальная скорость линии во всем диапазоне и нет ограничений по размеру программы можно делать выбор между "обычной" процедурой для коротких и развернутой для длинных. Но элита на мой взгляд не тот случай.

[Lethargeek]

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

[zx_]

про линии вспомнилось еще
http://www.asvcorp.ru/darch/asv/sgidemo/index.html

[shurik-ua]

Кароновирус кароновирус, может из за него всё таки допишется i8080 elita, но скорее это пришельцы к нам прилетят.

я как-то обещался воплотить этот проект - но я думаю это таки невозможно.
слишком уж неподъёмная задача для меня - поэтому я пас, звыняйте (

[zx_]

shurik-ua, даже не подходил небось
эт издалека страшно

[zx_]

jerri, может есть подвижки ? демка какая)

[jerri]

jerri, может есть подвижки ? демка какая)

подвижки есть. демки пока нет.

[SpaceEngineer]

Не будет Элиты на Специалисте?

[NEO SPECTRUMAN]

пока нет :)