Полигон-2

Всем привет
Многие из нас помнят те времена, когда пк спектрум или "ПОИСК" были вершиной развития компьютерной техники В те добрые времена программы хранились на магнитофонных кассетах, так как дисководы а тем более жесткие диски были далеко не у каждого
Захотелось реализовать кассетный интерфейс на современном пк.
Думал найти готовую программу позволяющую работать с кассетой- но таких програм оказывается нет. Разве что эмуляторы спектрума, позволяющие конвертировать спек кассеты в tap или tzx файлы.
Некоторая информация есть сдесь
кассетный порт IBM
IBM Cassette tape
http://www.i-assembler.ru/182/9-10.html
http://www.cyberguru.ru/progra...age24.html

Также удалось найти исходники биоса "ПОИСК-1" в которых есть и исходники кассетных функций, даже с понятными русскими коментариями (Кому нужно, могу выслать).
Хотел переделать исходники, чтобы реализовать кассетный интерфейс на ком или лпт, но...
Есть некоторые аппаратные отличия которые мешают так просто это сделать...

Кто что может посоветовать ? Ни кто не писал драйверов кассетного порта ?
Может все таки есть готовые програмки ?

Кассетный интерфейс более раритетный чем самый старый флопик
Так что давайте попробуем его реализовать

Смущает то, что в отличии от ПОИСК выход таймера не подключен к пятому биту порта 62h. Это использовалось при записи на кассету для некой синхронизации. Таймер осчитывал длительность импульса а проц проверял состояние этого процесса именно через 62 порт.
И выход на магнитофон был непосредственно от таймера. А как его вывести скажем на лпт ?
Я пробывал использовать чтение счетчика таймера 0 на лету для этих целей.
Тоесть проц считал значение счетчика 0, сохранил. После этого цикл считывания счетчика и сравнение на допустимую разницу с сохраненным значением.
Но покамисть эта версия нормально не заработала.

Да, информация записывалась 256 байтными блоками
Информация на касете кодируется просто длинной импульса - как азбука Морзе Длительность периода 1 -1000 мкс (2 полупериода по 500 мкс), длительность периода 0 -500 мкс (2 полупериода по 250 мкс). Кассетный порт определяет только полярность сигнала, форма сигнала значения не имеет.

При записи на кассету на пк ПОИСК получалось, что пока таймер отсчитывает и выдает на магнитофон полупериод сигнала, а процессор в это время получает новый бит данных и ждет момента (анализируя 5 бит порта 62 )быстренько перезагрузить таймер в соответствии с новым битом данных.

А если всем занят только процессор, все его "брожения" по програмному коду портят временную х-ку сигнала...
По крайней мере мой боевой 286 почемуто нормально не справляется...

Попробую на современном компе. Еще есть вариант припаять провода к динамику...
В общем процес разработки еще идет

Оффтоп: Интересно, насколько хорошо "программная" кассета будет дублироваться на повышенной скорости, т.е. High Speed Dubbing ?
И заодно, можно-ли восстановить прогу из такого дубля, чтоб вновь записать на ленту, уже в нормальном режиме?
(Достались несколько кассет, либо уже повреждённых, либо "быстродублированных", не различить толком, и содержимое неизвестно, мож вовсе не программа а какой-нть факс...).

Fe-Restorator, а предположительно это кассеты спектрум ?
Спектрумовсие кассеты, помоему, были гораздо более распространены чем IBM.
На сколько я знаю, на некоторых спеках была возможность писать/читать с удвоеной скоростью. Может Вам такие достались ?
А на чем Вы их читали ?

Кстати появилась мысль - нельзя ли для работы с кассетами использовать модем ?
Звуки по крайней мере очень похожи
Хотя наверное пока разберешься с модемовским протоколом, можно 20 раз на лпт сделать

Может эта информация пригодится :
http://www.danbigras.ru/RK86/RK_PC/RK2PC.html

Profesor_lampochkin написал:

[q]

Захотелось реализовать кассетный интерфейс на современном пк.
Думал найти готовую программу позволяющую работать с кассетой- но таких програм оказывается нет.

[/q]

В свое время на DG-Tech обсуждалось, там Tgw_Lead выклавывал утилиту, пишущую в формате Радио-86РК.
Он и здесь зарегистрирован, спроси у него, пусть скинет.

А как такой вариант? http://www.autospiel.ru/pattern4515.html

Дело за софтом

zOrg, да действительно Вот и приложили бы к этой штуке диск с драйвером читающий спек/IBM кассеты Все, пишем жалобу производителю

мастер бук Скорее всего этот плеер определяется как аудио устроиство, по типу как USB микрофоны и гарнитуры. Тогда подойдёт любой аудиоредактор, но в любом случае нужно будет кодек писать под соответствующий формат записи кассеты.

DrPass написал:

[q]

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

[/q]

Я так и делаю, когда на Atari кассеты пишу Просто тут народ насчёт интерфейса запаривается, вот и предложил как вариант.

Интересно а винил в качестве носителя информации (не аудио) никогда не пробовали использовать?

Кай Ачуметь! Вот кстати и "дисковод" http://forum.white-label.ru/showthread.php?t=155268

Внезапно интересная тема.
Может, ее из флейма перекинуть куда-нибудь в IBM-совместимые?

[q]

КАК BIOSу обяснить, что у него висит не FDD ?

[/q]

Никак. BIOS игнорирует стример. Управление стримером с Floppy-интерфейсом происходит лишь благодаря программной поддержке. Софтовое, стало быть.

Ближайший аналог (упрощённо) "звуковая карта" Covox для LPT порта. Она ведь тоже не принтер...

Это не касается аппартатных решений для стримеров с Floppy интерфейсом. Содержащих в себе более высокоскоростной контроллер, чем для FDD и, иногда, микросхему(ы) для компрессии данных. Например, плата CMS TC-15

[q]

Магнитофон подключается к лпт

[/q]

[q]

Ближайший аналог (упрощённо) "звуковая карта" Covox для LPT порта. Она ведь тоже не принтер...

[/q]

...Я знал, что именно примитивным 4/8-х разрядным (софтовым) DAC/ADC на LPT эта затея и кончится. Главное, что работает.

[q]

Интересно а Атарский XC-12 можно к LPT подцепить на чтение запись?

[/q]

К LPT то вряд ли, а вот конвертер SIO в COM я как-то видел.

Однако, лучше tnt23 спросить. Он значительно выше специалист по таким вопросам.

[q]

програмки для работы с IBM кассетами

[/q]

всё же эта фраза должна звучать

[q]

програмки для работы IBM с кассетами

[/q]

Profesor_lampochkin написал:

[q]

Прикольно было вспомнить свой первый ПК ПОИСК-1, загрузить с кассеты игру кошки-мышки

[/q]

Ты это, выложи игру "кошки-мышки" куда-нибудь, другим тоже будет прикольно вспомнить
И если еще что-то кассетного есть, тоже выложи, пжлст

Оказывается было еще и такое "Программное средство Копировщик"
Документацию о нём можно скачать тут

Кто знает где можно скачать сами эти програмки, а не документацию ?

Спасибо за классные игрушки

Теперь мы все сможем их загружать, тк в выше указанный архив с програмками для работы с кассетами IBM, я только что дополнил програмкой, CCMS1502,
которая копирует файлы с кассеты формата ПК "Электроника МС1502" на диск.

Как оказалось (после долгого ковыряния в турбодебагере) заголовки кассетных исполняемых файлов ПОИСКа и МС1502 отличаются.

В ПОИСКе соблюдается формат заголовка IBM и для исполняемого файла !!! А в электронике заголовок немного упростили - выкинули все ненужное (тип файла, значение сегмента и значение смешения).
Так как байт типа файла стоял перед размером, то в электронике слово указывающее размер "сьехало" на этот байт ближе к началу.
В общем в ПОИСКе байты 0a,0b указывают длину файла, а в электронике 09,0a
Это только для исполняемых файлов. Бейсик файлы одинаковы

[q]

А то стример есть, а читать - нет

[/q]

Модель стримера какая?

...попробуйте... http://h20000.www2.hp.com/bizs...wEnvOID=14
Это под DOS.
...Интересный у Вас стример. Умеет читать QIC-40, читать-писать QIC-80 и QIC-80XL. У меня такого пока нет (конкретно такой модели от Irwin/Archive/Conner, а не совместимого по форматам).

Alex_B, программа и есть для чтения кассет ПОИСК-1 Позже добавлена поддержка формата МС-1502. Всё это уже есть в архиве+ програмка записи на кассету
С MESS работать не приходилось...

Kurill_GANJOU, а можно схемку этого "усилителя-формирователя"?

...магнитофоны "Маяк" недаром называли "Маньяк". Диктофонный размыкатель тока мотора был и на более простых моделях: "Спутник" и "Легенда".

Ладно, смотрю схемы. Магнитофон AKAI GX-A5X с проводным ПДУ, нормально разомкнутый. Увы, у него линейные 250 милливольт...

Н-да, не все браузеры поддерживают tag image file format.

Я уже упоминал про колонки. Не понимаю, почему нельзя подключить их ко 2-му конт. LPT через простейший согласователь (например, такой) и послушать, формирует ли прога сигнал записи?

Все бы ничего, только в пилот тоне есть какие-то повторяющиеся каждые ~55мс "провалы".

Tronix написал:

[q]

Все бы ничего, только в пилот тоне есть какие-то повторяющиеся каждые ~55мс "провалы"

[/q]

Ну, это уже хорошо. Большое спасибо uav1606 и Tronix'у!!! Я вообще не был уверен, что на ХТ будет хоть какой-то звук...

uav1606 написал:

[q]

тот драйвер, видимо, не делает CLI перед началом вывода блока данных (и STI по завершению).

[/q]

А перед записью блока запрета прерываний действительно не было. CLI / STI были в процедуре записи бита (WRITE_BIT) добавлены мной (изначально в листинге IBM их и там не было). Но без них на АТ получался звук как раз вот с такими провалами.

Пользуясь подсказкой uav1606, исправил исходник и вставил запрет / разрешение в WRITE_BLOCK. Из WRITE_BIT, понятно, убрал за ненадобностью.

Самое смешное, у айбиэмовцев запрета прерываний не было ни в WRITE_BLOCK, ни WRITE_BIT. Как у них при этом получался непрырывный сигнал, до сих пор не могу вкурить.

Во вложении, собственно, исправленная прога.

Проверил с новой версией, вроде бы разрывов в пилот-тоне нет:



Сам WAV-файл во вложении.

Кстати, отключение прерываний стопорит на XT часы, поэтому с этими самыми CLI/STI при записи больших блоков могут быть проблемы.

Насчёт той схемки выше - можно заменить К561ЛН2 на К155ЛН2? А то что-то 561-х у меня нет...

Tronix, а можно подробнее, как конвертить? А то у меня он что-то пишет: "Can't find pilot tone".
И что потом можно с этими CAS-файлами сделать? Их можно в какой-нибудь эмулятор закинуть?

uav1606 написал:

[q]

отключение прерываний стопорит на XT часы

[/q]

Это понятно. Так и должно быть.
uav1606 написал:

[q]

... поэтому с этими самыми CLI/STI при записи больших блоков могут быть проблемы

[/q]

А вот об этом, пожалуйста, поподробнее.

uav1606 написал:

[q]

Насчёт той схемки выше - можно заменить К561ЛН2 на К155ЛН2?

[/q]

К сожалению, ТТЛ (ТТЛШ) серия очень плохо работает в линейном режиме. Так что лучше не заменять. Фигня получится. К554СА3 есть? Могу нарисовать лично проверенную схему на компараторе.

Tronix написал:

[q]

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

[/q]

Это команда SAVE "имя_файла", A
Буква "A" (или "a") чере запятую после SAVE латинская, кончно.

Tronix написал:

[q]

Для бинарей вроде бы тоже мне встречался какой-то конвертор, типа из бинарника преобразует в тектовый исходник.

[/q]

Точнее, конвертер из упакованного бейсик-формата в обычный текст. И этому горю можно помочь. У меня таких конвертеров две штуки (см. во вложении). Один на голом асме, а второй вообще на бейсике написан.

Ну да, вот асмовый точно то самое, что я на каком-то cd-rom встречал типа "Hacker '97". Но дело не в конвертации, а в том, что конвертировать - нечего.

Kurill_GANJOU написал:

[q]

В перспективе я хочу написать программу, которая позволит грузить в память (и запускать) кассетные бинарники прямо с ленты. Это для любителей "тёплого лампового звука", так сказать...

[/q]

Запускать на PC, соответственно? Но вопрос что запускать... IBM Diagnostics а) была в двух вариантах: на кассете и на дискете. То есть есть ее дискетная версия. б) кассетная запускается через basic, то есть бинарные данные в память сначала грузит небольшой загрузчик на бейсике. Если делать программу, грузящую бинарник прямо с ленты, нужно либо скипать этот бейсиковый загрузчик и грузить в память бинарь самостоятельно а потом передать ему управление, либо грузить бейсик, который грузит загрузчик, который грузит бинарный тест.

А для программ и игр с "отечественных" компов вроде бы Профессор Лампочкин уже написал такую программу - на PC запускается обычный кусок "монитора" Поиска, откуда можно грузить кассетную программу для него же.

Как сделать универсально - как распознавать, грузится ли IBM Diagnostics, Поиковый формат или от MC-1502? Имхо никак, придется вводить ключи, задающие что мы щаз грузим. Если IBM diagnostics - скипаем бейсик блок, грузим бинарь туда-то и передаем управление по такому-то смещению. Если Поиск - то грузим сразу блок туда-то и джампаемся туда-то. Если MC-1502, то помним что размер в заголовке у нас не в байтах а в блоках по 512 байт, и поступаем примерно как с Поиском.

Немного оффтопика, ЭксКузьмайте.
1) Какова ёмкость стандартной 90-минутной кассеты? Так скажем, неформатированная ёмкость: тупо пишем бесконечный поток битов на все 4 дорожки (2S2T).
Вроде-бы помещалось по 15 спековских игрушек на моно-дорожку МК60 (мельком заметил где-то на развале тех времён). Т.е. (15*2+15)*2=90 игр на 4-х дорожках МК90. Разумеется, сии попугаи весьма неточные...
2) Поскольку прог "от поиска" всё-ж не так много, появилась мысль преобразовать сию программу в некое подобие "арвид"-а, и складировать на ленту обычные РС-проги. Например, для переноса с современного компа в ХТ. В обход промежуточных первопней, сказей, траблов с лапете-линками, с флоппи-сайквестами и прочих. На компе формируем бит-WAV, скармливаем магнитофону/флеш-плейеру, а с него - в ХТ, в денди, ещё куда-там 8 бит могут поместиться. И обратно тем-ж путём.
3) Идея-фикс: RAID-TAPE. Т.е. запись одного файла сразу на 2 ("стерео")дорожки. Бит-стереозапись. Просто из спортивного интересу, не более того.

[q]

Какова ёмкость стандартной 90-минутной кассеты?

[/q]

Лучшие модели стримеров D/CAS TEAC умели записывать 45 мегабайт на 135 метров 3.81 ленты. (17 дорожек)
Делим на 4... Вносим поправку на коэрцитивную силу носителя и детонацию механизма... Ну мегабайт 8 получится.

У спектрумов - атари - коммодоров на одну дорожку (грубо) килобайтов 100.

Kurill_GANJOU написал:

[q]

При скорости 1200 бит/c имеем:
90 (мин) x 60 (сек) x 1200 (бит/сек) = 6 480 000 бит, или 791 Кбайт.
Ну, это без учета пилот-тона, пауз, байтов CRC, синхробайтов и т. п. Теоретический предел, короче...

[/q]

Н-да, негусто. Конечно, нужно удвоить результат, ибо 2 дорожки на кассете, т.е. примерно 1600Кбайт, но и это негусто. Даже теоретически.
Интересно, чем обусловлена скорость записи на ленту, те 1200 бод. Увеличить её наверняка можно, т.е. это не предел "меньше одного магнитного домена" для ленты. Рассматриваю "идеальную ленту", без присущих ей помех.

Кай написал:

[q]

Ну мегабайт 8 получится.

[/q]

Учитывая 40 мегабайт ёмкости винча ХТ, этот результат мне больше нравится.

DrPass написал:

[q]

На IBM PC XT винт был всего 10 мегабайт

[/q]

Изначально - да. Однако, наиболее распространён именно ST251-ый, (урезать его до 10 мегабайт как минимум - глупо) посему и взят 40-вник за точку отсчёта.

DrPass написал:

[q]

работать на советских бытовых магнитофонах а-ля "Весна". Т.е. запись должна быть нечувствительна к высоким шумам, узкой полосе пропускания, неравномерному движению ленты, разным скоростям на разных устройствах и т.д.

[/q]

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


PS. Быстрый поверочный расчёт:
примем величину рабочего зазора магнитной головки в 5 мкм, тогда за секунду можно "уписать" 47,6/0,005=9520 бит.
Теперь "заштампуем" всю ленту: 9520*(90мин*60сек*2дорожки)=102816000 бит на ленту. Делим на 8, имеем 12852000байт, т.е. 12,8 мегабайт на ленту. Теоретический предел, так-сказать.

Спортивный интерес побороться за такой объём уже проявился. Осталось оценить, насколько сие реально. Для начала - методом цифровой эмуляции.

PPS. Верится с трудом, но
Кай написал:

[q]

Лучшие модели стримеров D/CAS TEAC умели записывать 45 мегабайт на 135 метров 3.81 ленты.

[/q]

а Вика бачит "as much as 0.6GB of data" на кассету. Т.е. все игрухи эпох ХТ и 286 на одной кассете...

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

$10 PRINT "Hello

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

WAV во вложении.

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

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

SoftCat написал:

[q]

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

[/q]

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


SoftCat написал:

[q]

Kurill_GANJOU написал:

[q]

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

[/q]

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

[/q]

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

SoftCat написал:

[q]

Но можно выход звуковой карты использовать вместо магнитофонного выхода и проигрывать WAV-файл.

[/q]

Это если под рукой два компьютера. А у меня он один. Экперименты с драйвером проходят по голым ДОСом, а оцифровка в wav - под Виндой. Опять же, желательно учитывать характеристики реального магнитофона (детонацию ленты и проч.).

Profesor_lampochkin написал:

[q]

РАДЧЕНКО Л.И.
КОМПЛЕКС ПРОГРАММ
ДЛЯ ОБРАБОТКИ И ТИРАЖИРОВАНИЯ ПАКЕТОВ ФАЙЛОВ
"К О П И Р О В Щ И К

[/q]

У меня был его пакет для БК - большего рукожопия в те времена было найти сложно.