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

Цитата:

---

Сообщение от crackintosh

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

---

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

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

Цитата:

---

Сообщение от crackintosh

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

---

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

https://i.imgur.com/QqHVBOh.png

Цитата:

---

Сообщение от Bedazzle

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

---

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

Цитата:

---

Сообщение от crackintosh

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

---

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

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

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

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

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

Вложение 81912

Вложение 81913

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

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

Цитата:

---

Сообщение от Bedazzle

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

---

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

Цитата:

---

Сообщение от Chwe

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

---

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

Цитата:

---

Сообщение от Bedazzle

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

---

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

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

Цитата:

---

Сообщение от Bedazzle

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

---

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

Цитата:

---

Сообщение от Lethargeek

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

---

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