Конвертор ZX-картинок для Специалиста

[fifan]

Превосходно! Посмотрел все 18 картинок. Делал всё через эмулятор emu. Главный файл gfx.rks тоже не грузился - убрал первые четыре байта в файле и загрузил сразу в память по адресам 0100...24B5. Далее по <5> просмотрел все картинки. Проблемы с загрузкой файлов может быть в том, что в конце файла должна быть указана контрольная сумма блока данных, по крайней мере в файле gfx.rks её не было.

[Advertiser]

[CityAceE]

Делал всё через эмулятор emu.

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

Главный файл gfx.rks тоже не грузился

А у меня грузился без проблем при старте эмулятора. Но я особо не разбирался, может там оно и не туда вовсе грузилось и не так. Я все эксперименты проводил с Emu80.

Проблемы с загрузкой файлов может быть в том, что в конце файла должна быть указана контрольная сумма блока данных, по крайней мере в файле gfx.rks её не было.

Вполне может быть. Во всех моих файлах, включая картинки, контрольная сумма пустая, вернее левая. Во-первых, Emu80 игнорирует факт несовпадения КС, а, во-вторых, я попросту не знаю как на лету эту сумму генерировать в SjASMPlus, из которого я получаю скомпилированный файл. Подозреваю, что этого нельзя будет сделать. И придётся полученный rks прогонять через какую-то внешнюю утилиту, которая будет пересчитывать и добавлять контрольную сумму. Есть ли где-то готовое описание алгоритма, по которому вычисляется контрольная сумма Специалиста, чтобы самому не копаться в ПЗУ?

[Pyk]

Есть ли где-то готовое описание алгоритма, по которому вычисляется контрольная сумма Специалиста, чтобы самому не копаться в ПЗУ?

Алгоритм такой же, как в РК-86, вот фрагмент из Emu80:

        uint16_t cs = 0;
        for (uint16_t i = 0; i < fileSize - 1; i++) {
            cs += buf[i];
            cs += (buf[i] << 8);
        }
        cs = (cs & 0xff00) | ((cs + buf[fileSize - 1]) & 0xff);