Полигон-2

uav1606 написал:

[q]

К сожалению, ни один из них получившийся CAS-файл не смог преобразовать. Или я что-то не так делаю?

[/q]

Сегодня утром разобрался, в чем дело с Бейсиком. Записал hellowld2.wav от uav1606 на кассету и пробовал загрузить в Бейсик. Моей программой считался только заголовок, после загрузки блока данных Бейсик выдал «Out of memory». А вот записанный вечером hellowld3.wav считался без проблем. Длина блока, что ли, у меня неверно вычисляется, причем именно для сжатого формата?.. Зато hellowld2.wav успешно загрузился с ленты драйвером Лампочкина. Там оказались две строки:

[q]

10 PRINT "Hello, world"
20 GOTO 10

[/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 или загружен прямо в Бейсик.

Tronix написал:

[q]

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

[/q]

Вот Tronix как раз здесь не виноват!!! Это у мелкомягких-айбиэмовцев, по ходу, стандарт такой. Блок данных на кассете не соответствует аналогичному файлу на диске. Ну, как бинарь на кассете и ДОСовский com-файл – это не одно и то же...
Вот у меня при чтении упакованных данных точно глюк! Кому не лень, посмотрите исходник, пожалуйста.

uav1606 написал:

[q]

Так... Продолжаем эксперименты. Сохранил файл с ключом "A" после SAVE, скормил wav2cas, получился CAS-файл с текстом:

$10 PRINT "Hello

Всё. А должно быть ещё "..., world" и вторая строчка "20 goto 10".

[/q]

Моей прогой hellowld3.wav с ленты загрузился успешно (см. выше). Программой Лампочкина, впрочем, тоже. A вот wav2cas в данном случае действительно дивно глюкнул, неверно определив длину.

Tronix написал:

[q]

Видно и так, что все работает и эксперимент с LPT-портом прошел успешно.

[/q]

Пока у меня успешно заработала только запись. И то со второй попытки. Чтение же у меня пока отлажено наполовину. Что-то у нас с Tronix'ом взаимно обратные ошибки - у него неверно обрабатываются тексты на Бейсике в открытом виде, а у меня - в упакованном...

Во вложении:
HELLOWLD.BAS - файл, сохраненный командой SAVE после загрузки в Бейсик hellowld2.wav с ленты;
HELLO.CAS - после обработки hellowld2.wav wav2cas’ом. Не преобразовывается в текст и не грузится в Бейсик (аналогичен hellowld2.cas у uav1606 во вложении);
HELLOWLD.CAS - получился из HELLO.CAS дописыванием FFH в начало.

Хотя HELLOWLD.BAS и HELLOWLD.CAS отличаются концовкой (SAVE добавил еще два байта в конец), конвертируются и грузятся они совершенно одинаково.

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) и по положению этого признака находится длина.

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