Похоже, что это файлы на Бейсике. Видимо, утилита про них не знает и пытается интерпретировать сигнатуру в начале файла как адрес.Цитата:
Сообщение от Titus
Вид для печати
Похоже, что это файлы на Бейсике. Видимо, утилита про них не знает и пытается интерпретировать сигнатуру в начале файла как адрес.Цитата:
Сообщение от Titus
Отписался в теме Специалиста о результате.
Подскажите по формату кассетной записи на РК86.
Я так понимаю, что вначале идет адрес начала файла, адрес конца, затем тело, затем два нулевых байта, затем синхробайт 0xE6, а затем какие-то два байта. Контрольная сумма? Как она вычисляется?
Беззнаковое сложение. Один байт просто сумма, второй - циклическая сумма. http://www.danbigras.ru/RK86/Naladka/CRC.html
Нулевых байтов может быть два (большинство компьютеров) либо один (Партнер). При чтении лучше не полагаться на количество нулевых байт, а просто ждать синхробайт.Цитата:
Сообщение от Titus
На Микроше формат другой - синхробайта и нулевых байт в конце нет, сразу идет контрольная сумма, к тому же и считается она по-другому...
Попробовал посчитать на своих записях - в половине случаев не совпадает старший байт, который является циклической суммой.Цитата:
Сообщение от Pyk
Приведите пример кода, который подсчитывает сумму, тогда проблем не будет.
ПЗУ Микроши не дизассемблировал, т.к никогда не имел. КС для Специалиста, РК86 и Ориона:Цитата:
Сообщение от Titus
Код:.
CHSUM: LD BC, 0
CHSLOO: LD A, C
ADD A, (HL)
LD C, A
PUSH AF
CALL CMPDH
JP Z,POPAF
POP AF
LD A, B
ADC A, (HL)
LD B, A
INC HL
JP CHSLOO
POPAF: POP AF
RET
CMPDH: LD A,H
CP D
RET NZ
LD A,L
CP E
RET
Код:.
CHSUMMA PROC ; BEGADR:DX, ENDADR:CX, RET:BX
MOV SI, DX
XOR BX, BX
CHSLOO: ADD BL, ES:[SI]
PUSHF
CMP SI, CX
JZ POP_F
POPF
ADC BH, ES:[SI]
INC SI
JMP CHSLOO
POP_F: POPF
RET
CHSUMMA ENDP
Странно. Так и считаю. Значит где-то накосячил, т.к. старшая часть суммы в половине случаев не сходится.
В тех файлах для специалиста, которые загружаются загрузчиком, я контрольных сумм не видел. Какой там формат?Цитата:
Сообщение от barsik
Для загрузки по сбросу контрольная сумма не нужна. Очевидно А.Волков взял МГ-процедуры от МИКРО-80, т.к это был единственная доступная информация про работу с МГ, хорошо документированная в ж.РАДИО за 1982. А т.к там, ни в формате монитора, ни в формате бейсика, контрольные суммы не использовались, то и Волков сделал так же.Цитата:
Сообщение от Titus
Потому в загрузчике по сбросу процедура загрузки такая: после инициализации служ.ячеек (что просто копирование подпрограммой COPY C42D блока начальных констант из ПЗУ в ОЗУ) и вывода стартового сообщения, делается следующее:
Подпрограмма C3F9 - это ввод блока с поиском синхробайта по адресам следующим сразу за синхробайтом (причём младший и старший байты адреса следуют в стандартном порядке Intel, а не шиворот-навыворот, как у РК86). Контрольная сумма этой подпрограммой не читается и не контролируется. И это было сохранено и в зверковском загрузчике и повторено в ленинградском мониторе. Так что по сбросу можно загрузить даже дохлый файл.Код:.
CALL C3F9
LD HL,(ASTART)
JP (HL)
Хотя директивный монитор А.Волкова (тот, что грузится на 8D00) контрольную суммы при записи выдаёт. Если после синхробайта E6 стоит D9, D9, D9, то это формат с именем, а не формат для загрузки по сбросу.
Грамотная многоблочная программа может вышибать управление и при вводе по I. Это достигается тем, что блок грузится прямо в стек, подменяя адрес возврата из C3F9, но это нехорошо, т.к в разных мониторах разное число служ.ячеек и стек ставится по разному, что делает такой перехват зависимым от конкретной версии ПЗУ. Вот в ОРИОНЕ перехват удобнее, т.к там есть адрес вылета по ТАЙМ-АУТ, когда нет фронтов на время более 2-х периодов.
Titus, вот готовый фрагмент для подсчета КС в формате РК/Специалиста из исходников 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);