Полигон-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 добавил еще два байта в конец), конвертируются и грузятся они совершенно одинаково.