Версии игр и софта, найденные на кассетах

[Bedazzle]

Кидай сюда если не жалко.

Секретного ничего нет:
https://pastebin.com/CU3Zy1Bk

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

А вот остальными файлами: CMD KEY ZXK ZXS пока тупик...

ZXS - 30 байт хедер, потом идёт бейсик

[crackintosh]

потом идёт бейсик

ыыы... для "особо одаренных", что за бейсик

[Bedazzle]

ыыы... для "особо одаренных", что за бейсик

TAP - можно представить как архив, когда несколько файлов объединяются в один, друг за другом "паровозиком".
Чтобы разделить этот "архив" на исходные файлы, требуется дополнительная информация - длина файла, который идёт дальше (один или больше).
Кроме длины файла, самих данных, ещё добавляют байт контрольной суммы.

Т.е. внутри "архива" в общем случае, лежат:
1) длина первого файла и флаг, определяющий тип (заголовок, или блок данных)
2) первый файл (заголовок, как на ленте)
3) контрольная сумма
4) длина второго файла и флаг
5) второй файл (обычно бейсик)
6) контрольная сумма
7)....

далее идут картинка и основной блок

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

[Chwe]

ZXS точно не совпадают по структуре с неким ZXS, который понимает древний TAPER (других программ заявляющих поддержку ZXS я пока не нашёл). ZXS хорошо режется по принципу ДЛИНА-ДАННЫЕ, как TAP (LL + LL bytes of data), но содержимое блоков странновато, даже если выкинуть нули:





Не совсем понятно, откуда взять длину «настоящих» данных второго блока (собственно BASIC кода)?

В принципе, если предположить, что для блоков данных (0xff) структура опять же LL xx [LL-2 байт данных как в TAP], то примерно что-то вырисовывается. xx, скорее всего, длина данных в блоке минус «добивка» для выравнивания. Но это не работает для BASIC блоков. Или я что-то упускаю?

[SlashNet]

и хвосты забиты нулями.

Очень похоже на "приколы" файловой системы CP/M. В CMD файлах аналогичная ситуация.

[Bedazzle]

В принципе, если предположить, что для блоков данных (0xff) структура опять же LL xx [LL-2 байт данных как в TAP], то примерно что-то вырисовывается. xx, скорее всего, длина данных в блоке минус «добивка» для выравнивания. Но это не работает для BASIC блоков. Или я что-то упускаю?

Бейсик если без сохранённых переменных, длину в принципе, можно собрать по строкам (два байта номер строки, два байта длина).

[Advertiser]

[Chwe]

Бейсик если без сохранённых переменных, длину в принципе, можно собрать по строкам (два байта номер строки, два байта длина).

Ага, так тоже можно, но есть лучше идея. А что, если там какое-то RLE, через который пропущен обычный TAP. Формат что-то вроде: CC FF data, CC - длина/количество, FF -- как интерпретировать (00 -- использовать data как есть, 0x8x -- повторяем один байт CC+x раз). Насчёт FF надо ещё подумать, но, вроде, почти всё сходится.

[crackintosh]

Скрипт можете написать?

[Lethargeek]

У тапок формат очень простой: два байта длины, флаг, массив байт, чексумма; два байта длины, флаг... и т.д. для каждого файла внутри тапки

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

[Bedazzle]

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

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