Полигон-2

Kurill_GANJOU написал:

[q]

Результат сохранил на диск командой SAVE. Потом в hex-редакторе сравнил созданное SAVE’ом и wav2cas’ом. Тут вот, оказывается, в чем дело:

При конвертации wav --> cas теряется тип данных в заголовке (тип 80H для сжатой бейсик-программы). Значит, Бейсик (или конвертер) такой *.cas загрузит с диска как простой текст, но не сможет разобрать, что там написано. В программе, сохраненной на диск лично Бейсиком, признак сжатого формата находится в самом начале файла и имеет значение FFH. В исходнике READBAS нашел строки:

[q]

100 OPEN FI$ AS 1 LEN=1: FIELD 1, 1 AS X$
110 OPEN F2$ FOR OUTPUT AS #2: GET 1
120 IF ASC(X$) >>255 THEN PRINT "NOT A BASIC PROGRAM SAVED IN BINARY":END

[/q]

Думаю, понятно, что это такое.
Значит, если в начало cas-файла со сжатой бейсик-прогой дописать FFH, то в таком виде (на один байт длиннее) *.cas уже может быть преобразован конвертером типа RB58 или загружен прямо в Бейсик.

[/q]

Например, для кассетного Бейсика Электроники МС1502 вовсе не нужно, чтобы в начале бинарного файла на Бейсике был байт FFh, он анализирует тип файла. И при записи этот байт в начало не пишет. Это FFh нужно для GW-BASIC'а (и ему подобных) или разных конвертеров, когда файл читается с диска и, естественно, при этом отсутствует кассетный заголовок с типом файла.

Kurill_GANJOU написал:

[q]

Кассетный Бейсик Электроники МС1502 вообще может выполнять дисковые операции?

[/q]

Нет, не может. Он только работает с кассетой.

SoftCat написал:

[q]

Может быть для текстовых файлов на Бейсике длину надо как-то корректировать?

[/q]

Во вложении – процедуры чтения/записи файлов на кассету от «Поиска-1». Там, помимо всего прочего, есть описание кассетного заголовка. Особо хотел бы обратить внимание на примечание:

[q]

«Длина записанной в файл информации, значения сегмента и смещения адреса (поля заголовка A-F) запоминаются в заголовке только для файлов типов 01, 80 и А0.»

[/q]

01 – это исполнимый бинарник; 80 – сжатая Бейсик-прога; A0 – защищенная Бейсик-прога. А прога в виде ASCII текста имеет тип 40. То есть, по идее, для него длина должна браться не из заголовка, а каким-то другим образом. Теперь понятно, почему wav2cas глючит, причем именно на этом типе данных.

Кстати, неплохо бы узнать, как в этом случае находится длина. Первое, что мне пришло в голову – это следующий алгоритм: считывается с ленты 256-байтный блок, в нем ищется какой-то маркер конца файла (рискну предположить, что это четыре идущие подряд нулевых байта). Если маркер найден, значит, файл считан до конца. Если нет – загрузить с ленты следующие 256 байт и повторить поиск, и т. д.
Хотя об этом Бейсик было бы хорошо спросить: можно попробовать выловить и дизассемблировать процедуры работы с кассетными файлами. Ловить можно, например, по обращению к INT 15.


SoftCat написал:

[q]

А Вы как учитываете длину файла, указанную в заголовке?

[/q]

Я – никак. Назначение моего обработчика кассетного прерывания – это тупо считать или записать блок данных с ленты или на ленту. А уж сколько именно байтов в этом блоке использовать, решает вызывающая этот обработчик прога. В данном случае – Бейсик, т. к. других прог для работы с кассетами IBM PC (именно PC/PCjr, а не «Поиск-1») я что-то не видел.

SoftCat написал:

[q]

Тогда поясните, пожалуйста, поподробнее, зачем Вам потребовался байт FFh в начале бинарного файла на Бейсике?

[/q]

FFh потребовался не мне, а Бейсику, чтобы он бинарник, созданный wav2cas'ом из wav'ки, мог принять за родной дисковый файл и адекватно загрузить с диска. Драйвер здесь не при чем. FFh был добавлен не драйвером, а hex-редактором. Драйвер не пишет в файл то, чего там изначально не было.

SoftCat написал:

[q]

Чем именно (при чтении бинарного файла на Бейсике) Ваш драйвер отличается от драйвера Профессора Лампочкина?

[/q]

С точки зрения конечного результата (чтение файлов) - ничем, как для бинарников, так и для других типов. А вот на уровне кода есть разница в способе опознавания битов на ленте. У Лампочкина и у разработчиков "Поиска-1" минимальная продолжительность бита вычисляется адаптивно. А у меня (и у айбиэмовцев) она тупо сравнивается с константой. Вот, мне и было интересно, как это будет работать, особенно на советских магнитофонах с их коэффициентом детонации. Опыты с "ИЖ-306С" показали, что разницы нет.

Драйвер Лампочкина не может работать на XT. А мой, как показал uav1606, по крайней мере, писать может (чтение пока не проверяли). В перспективе это позволит добавить поддержку каасетных фунций от "Поиска-1" в "Поиск-2" (а кассетный интерфейс PC / PCjr можно добавить хоть сейчас, если собрать входные-выходные цепи и загрузить мой драйвер).
Моя прога не критична к базовому адресу LPT. Этот адрес может принимать самые идиотские значения, лишь бы он соответствовал реально установленному устройству. У Лампочкина адрес LPT фиксированный - 378h. Я ради смеха ставил в BIOS setup LPT1 как 378H, 278H или вообще "Disabled". Во всех случаях мой драйвер работал корректно (при нулевом базовом адресе он, понятно, не загружался).

О записи текстов на кассету.

Сегодня провел очередной эксперимент.
Во вложении:
TXT2CAS.BAS – прога на Бейсике, копирующая текст с диска на кассету;
CAS2TXT.BAS - копирование текста с кассеты на диск;
BYKOV.TXT – текст на диске;
BYKOV.WAV - аудиопоток на кассете.

TXT2CAS “на лету” по строкам копирует текстовый файл с диска на кассету. Прога ничего не знает о длине этого файла. Если бы копирование было с диска на диск, то тактика была бы понятной: записать строку в целевой файл, увеличить размер файла в FAT на длину этой строки, потом записать следующую строку, снова обновить FAT и т. д. (как вариант - обновить размер один раз, при закрытии целевого файла). А при записи на кассету Бейсик при всем желании не может отмотать ленту назад и скорректировать длину в заголовке. Поэтому логично предположить, что для текстовых данных в заголовок пишется какое-то фиктивное значение длины, которое реально (при загрузке) не используется.
Я записал текст на кассету, оцифровал запись и прогнал wav’ку через wav2cas. Трониксовский wav2cas, как это и следовало ожидать, глюкнул.

Tronix написал:

[q]

Ну у меня там в проге какой-то глюк вроде на тему размера был, щаз уже не помню точно, ибо год назад писал. Возможно проявляется только на таких маленьких файлах (> 512 байт) и возможно только на васике.

[/q]

А длина образца текста была почти 2 килобайта. И Васиком там и не пахло - это был литературный текст, а не Васик программа. Значит, глюк связан не с малой длиной, а с неверным ее определением в принципе. Выходит, что для данных типа 00 и 40 длина берется не из заголовка, а вычисляется анализом самих данных. Вероятно, там ищется какой-то признак конца файла (это или 4 нуля подряд, или 1AH / Ctrl^Z) и по положению этого признака находится длина.

Так что, есть смысл заняться реверс-инженирингом Бейсика…

SoftCat написал:

[q]

А Вы пробовали читать бинарный файл на Бейсике через Ваш драйвер в Бейсике (как бы с кассеты)? Что при этом получается?

[/q]

Почему "как бы"? Прямо с кассеты и читал упомянутым совковым магнитофоном. Предварительно записав файл как на кассету, так и на диск, чтобы сравнить. На АТ / ATX компах с файлы с кассеты читаются успешно. Другое дело, что чтение на XT пока не проверяли...


SoftCat написал:

[q]

Kurill_GANJOU написал:

[q]

Сегодня утром разобрался, в чем дело с Бейсиком. Записал hellowld2.wav от uav1606 на кассету и пробовал загрузить в Бейсик. Моей программой считался только заголовок, после загрузки блока данных Бейсик выдал «Out of memory».
...
Что-то у нас с Tronix'ом взаимно обратные ошибки - у него неверно обрабатываются тексты на Бейсике в открытом виде, а у меня - в упакованном...

[/q]

Вот эта ошибка в связи с чем произошла?

[/q]

Там процедура выключения мотора магнитофона портила регистр, в котором драйвер возвращает кол-во считанных байт. Что интересно, на ASCII текстах этот баг не проявлялся (почему - понять не могу). Только на бинарниках. Команды PUSH / POP этот баг успешно пролечили.