Внимание! Это временный неофициальный архив старой версии форума Полигон Призраков, созданный сочувствующим форуму участником. Этот сайт просуществует лишь до тех пор, пока администрация Полигона не сдержит своё обещание и не откроет официальный архив по адресу old.sannata.org.

Полигон-2

Форум о старых компьютерах

Объявление форума

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

Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Кассетный интерфейс
RSS

Кассетный интерфейс

Принцип работы, реализация кассетного интерфейса на современном пк

<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 7 8 * 9 10
Печать
 
Fe-Restorator
Гость

Ссылка

Kurill_GANJOU написал:
[q]
При скорости 1200 бит/c имеем:
90 (мин) x 60 (сек) x 1200 (бит/сек) = 6 480 000 бит, или 791 Кбайт.
Ну, это без учета пилот-тона, пауз, байтов CRC, синхробайтов и т. п. Теоретический предел, короче...
[/q]
Н-да, негусто. Конечно, нужно удвоить результат, ибо 2 дорожки на кассете, т.е. примерно 1600Кбайт, но и это негусто. Даже теоретически.
Интересно, чем обусловлена скорость записи на ленту, те 1200 бод. Увеличить её наверняка можно, т.е. это не предел "меньше одного магнитного домена" для ленты. Рассматриваю "идеальную ленту", без присущих ей помех.

Кай написал:
[q]
Ну мегабайт 8 получится.
[/q]
Учитывая 40 мегабайт ёмкости винча ХТ, этот результат мне больше нравится.
Сейчас на форуме
DrPass
Advanced Member


Откуда: Донецк
Всего сообщений: 3566
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
17 апр. 2005
Fe-Restorator написал:
[q]
Интересно, чем обусловлена скорость записи на ленту, те 1200 бод. Увеличить её наверняка можно, т.е. это не предел "меньше одного магнитного домена" для ленты. Рассматриваю "идеальную ленту", без присущих ей помех.
[/q]
Исключительно тем, что оно должно работать на советских бытовых магнитофонах а-ля "Весна". Т.е. запись должна быть нечувствительна к высоким шумам, узкой полосе пропускания, неравномерному движению ленты, разным скоростям на разных устройствах и т.д. :)


Fe-Restorator написал:
[q]
Учитывая 40 мегабайт ёмкости винча ХТ, этот результат мне больше нравится.
[/q]
На IBM PC XT винт был всего 10 мегабайт
Fe-Restorator
Гость

Ссылка

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" на кассету. :rolleyes: Т.е. все игрухи эпох ХТ и 286 на одной кассете...
Сейчас на форуме
uav1606
Advanced Member


Откуда: Енакиево
Всего сообщений: 4373
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
16 янв. 2008
Fe-Restorator, можно попытаться кодировать биты не только длительностью импульса (как делают обычно), но и уровнем сигнала, тогда ёмкость можно увеличить в несколько раз, но устойчивость к помехам и надёжность упадут во столько же...
Вообще, нужно смотреть в сторону модемов - используемые там типы модуляции вполне можно применить и здесь, с разными поправками, конечно.
uav1606
Advanced Member


Откуда: Енакиево
Всего сообщений: 4373
Рейтинг пользователя: 0


Ссылка


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

$10 PRINT "Hello

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

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

Прикрепленный файл (hellowld3.wav, 373780 байт, скачан: 42 раза)
Tronix
Advanced Member


Откуда: Москва
Всего сообщений: 1749
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
15 янв. 2008
Ну у меня там в проге какой-то глюк вроде на тему размера был, щаз уже не помню точно, ибо год назад писал. Возможно проявляется только на таких маленьких файлах (> 512 байт) и возможно только на васике. Можно конечно пофиксить, но честно говоря смысла особого не вижу. Видно и так, что все работает и эксперемент с LPT-портом прошел успешно. ЧТД.
Kurill_GANJOU
Newbie


Всего сообщений: 19
Рейтинг пользователя: 0


Ссылка


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

Прикрепленный файл (HELLOWLD.ZIP, 419 байт, скачан: 37 раз)
Kurill_GANJOU
Newbie


Всего сообщений: 19
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
19 апр. 2014
ВНИМАНИЕ!
Исправлен баг с неверной длиной блока при чтении. Желающим протестировать просьба скачать обновлённый вариант.

Прикрепленный файл (I15_0426.ZIP, 24401 байт, скачан: 46 раз)
SoftCat
Newbie


Всего сообщений: 54
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
26 нояб. 2010
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
Newbie


Всего сообщений: 19
Рейтинг пользователя: 0


Ссылка


Дата регистрации на форуме:
19 апр. 2014
SoftCat написал:
[q]
Например, для кассетного Бейсика Электроники МС1502 вовсе не нужно, чтобы в начале бинарного файла на Бейсике был байт FFh, он анализирует тип файла. И при записи этот байт в начало не пишет.
[/q]
Простите, куда не пишет? На кассету или на диск?

В блоке данных на кассете он и не нужен. Его функции выполняет байт 80H в кассетном заголовке. Дисковые версии Бейсика (BASIC-A/GW-BASIC) на кассету FF тоже не пишут за ненадобностью. А вот если FF не записать в дисковый файл, то как Бейсик потом поймет, что перед ним упакованный формат, а не простой текст программы? Кассетный Бейсик Электроники МС1502 вообще может выполнять дисковые операции? Оригинальный кассетный Бейсик IBM не мог в принципе.

Проблема у uav1606 была в том, что он пытался открыть кассетный блок данных (сохраненный на диск wav2cas’ом) как "родной" дисковый файл Бейсика. А это, как оказалось, не совсем одно и то же. И wav2cas здесь не при чем. Это просто форматы бинарников разные.
<<Назад  Вперед>> Страницы: 1 2 3 4 5 6 7 8 * 9 10
Печать
Полигон-2 »   IBM PC-совместимое. До 2000 года включительно »   Кассетный интерфейс
RSS

1 посетитель просмотрел эту тему за последние 15 минут
В том числе: 1 гость, 0 скрытых пользователей

Последние RSS
[Москва] LIQUID-Акция. Сливаются разъемы CF
МС7004 и 7004А на AT и XT
Пайка термотрубок
Проммать s478 PEAK 715VL2-HT ( Full-Size SBC)
Подскажите по 386 материке по джамперам.

Самые активные 5 тем RSS