- БК и "современные" 1.2МБ дисководы
-
? Макс Багаев@ - 13.12.2013 20:24
Написал пару заметок из собственного опыта по подключению к БК/УКНЦ "современных" 1.2МБ дисководов
+ дополнил это фотографиями перемычек
http://forum.maxiol.com/index.php?showtopic=4770
¤
Опыт модернизации блока дисководов МС5310 c фото
оказалось что надо не только флопы поменять но и БП тоже. точнее можно начать с замены БП.
http://forum.maxiol.com/index.php?showtopic=4771
-
? всезнайка - 06.03.2016 15:45
не знаю что у тебя там с 1.2мб дисководом, у меня проблем нет. вот с 1.44" пришлось немного помыкаться. лучше по старее на 720 кб сразу найти.
-
? anonymous - 07.03.2016 09:29
Макс, я там в теме наоффтопил, но гляньте, вдруг что найдётся по тому тику. Буду признателен, к БК у меня именно таки подключены, как описал в строках по доработке.
-
? Макс Багаев@ - 07.03.2016 20:10
Про такие крутые приводы только слышал, живьем не видел!
-
? RADIX50 - 06.04.2016 23:45
RE: "всезнайка - 06.03.2016 15:45
не знаю что у тебя там с 1.2мб дисководом, у меня проблем нет. вот с 1.44" пришлось немного помыкаться..":
#
В свое время(в "переходные" 90-е) опытным путем как-то само собой выяснилось,что 1.2МБайтные FDD - как бы это сказать.. более "беспроблемные" (правда,при подключении оных не к БК/УКНЦ, а к тогдашним портативным ЭВМ типа как те старые "Тошибы", еще с ч/б-дисплеями..): в общем,у тех пользователей,кто изначально на свой лэптоп устанавливал 5.25" дисководы(на 1.2МБайт)- никаких проблем не возникало(в т.ч.,при добавлении второго привода на 1.44М), а тем,кто,"в угоду портативности", заказывали сначала установку 1.44МБ-приводов, приходилось,как сказано в том сообщении, "помучаться"(не помню уже,с чем там была связана основная проблема - может,с прошивками самих тогдашних контроллеров FDD).. Кстати,у 5.25"-приводов - выше надежность хранения данных(как чтение,так и запись), и форматов много всяких разных поддерживают(физически/аппаратно), а у 1.44МБ-приводов(3.5") - основных форматов всего 2шт.: на 720К и на 1.44М(впоследствии), а надежность хранения данных - заметно ниже(имеется в виду,при работе в режимах высокой плотности,т.е., "выше мегабайта").
Насколько помню,связано это с тем,что 5.25"-дисковод имеет некий "запас"(конструктивный), а 3.5"-дисковод,в силу несколько более высокой плотности записи, видимо, подходит к определенному "техническому" пределу возможностей, так сказать, "вплотную", не обеспечивая запаса надежности(по макс. допустимым для данного магнитного слоя носителя токам подмагничивания,уровню записи(остаточной намагниченности) и др. параметрам).
Отсюда и довольно заметный процент "брака"(нечитаемости или "сваливания" в нечитаемость) дискет,отформатированных в режиме "высокой плотности"(1.44М) на 3.5"-дисководах,даже полностью исправных и корректно отъюстированных/отрегулированных. Перевод сбоящей 1.44М-дискеты в "низкую" плотность(путем заклейки "окошка" с краю) - позволяет нормально работать с нею,правда,уже в режиме 720(800)К.
...
В свою очередь,хочу поинтерсоваться: доводилось ли кому-нибудь из уважаемых Коллег(в смысле,форумских) применять/пытаться пользоваться дисководами высокой плотности в режиме 1.2(1.44)МБайт на БК/ДВК/УКНЦ(возможный "подвох" состоит в том,что "обычные" контроллеры при штатной тактовой частоте могут просто не обеспечивать требуемую надежность обмена данными при такой плотности записи, - т.к., как минимум,вдвое вырастает поток/объем данных,которые надо корректно пересылать туда и обратно)?
-
? Дмитрий - 07.04.2016 01:03
Пробовал подключать 3,5 1.44 к БК. Но пара имевшихся, видимо, не имела датчика низкой плотности, потому как что с заклеенным окошком, что с не заклеенным не работали от слова "никак" - каждая дорожка с ошибкой (вроде не найден адресный маркер, но могу ошибаться).
¤
А насчет "вплотную" не соглашусь, ибо в те годы форматировал 1.44 дискету на максимальные 1.78Мб с помощью старой fformat + 800.com. И в Винде дискета нормально читалась и писалась на весь объем (в досе только с 800.com).
-
? maxstudios@ - 07.04.2016 09:02
Я в те года тоже столкнулся с проблемой заклеенного окошка.
Выяснил, что обычная чёрная изолента, наклеенная с обеих сторон на окошко, не даёт результат. Пришлось во внутрь этого окошка вставлять кусочек чёрного пластилина, сдавливая его с обеих сторон пальцами, а затем ещё залеплять с двух сторон чёрной изолентой - вот тогда всё начинало работать без проблем под КНГМД-326 БК-11М.
Помню, специально ходил в магазинчик РС-комплектующих, чтобы купить 3.5" дисковод MITSUMI - работали они адекватно и стабильно, диски от БК прекрасно читались на РС.
А насчёт плотности - помню, была ещё плотность 2.88 Мб на 3.5" дисководах. Называлась вроде бы HD.
:)
-
? Anonymous - 07.04.2016 10:29
「RADIX50 - 06.04.2016 23:45
В свою очередь,хочу поинтерсоваться: доводилось ли кому-нибудь из уважаемых Коллег(в смысле,форумских) применять/пытаться пользоваться дисководами высокой плотности в режиме 1.2(1.44)МБайт на БК/ДВК/УКНЦ(возможный "подвох" состоит в том,что "обычные" контроллеры при штатной тактовой частоте могут просто не обеспечивать требуемую надежность обмена данными при такой плотности записи, - т.к., как минимум,вдвое вырастает поток/объем данных,которые надо корректно пересылать туда и обратно)?」
Я использую два 1.44 на БК и один 1.44 на Кванте, для переноса данных стандартными дискетами, но со scsi-контроллером и сами флопы подсоединяются через слегка переделанный контроллер teac fc-01. Я писал об этом здесь, в теме про 1.44 на БК.
-
? RADIX50 - 07.04.2016 10:50
RE:"? Дмитрий - 07.04.2016 01:03
Пробовал подключать 3,5 1.44 к БК...
¤
...насчет "вплотную" не соглашусь...;
...fformat + 800.com...":
#
В том сообщ-ии имелось в виду,во-первых,штатные параметры форматирования/емкости;во-вторых,имелось в виду.. забыл,как по-научному зовется этот параметр, - ну,в общем,у любых устр-в/приборов есть т.наз. "граничная частота"(образно/грубо говоря), напр., у кассетных магнитофонов "разрешающая способность"(так сказать) по спектру воспроизводимых частот оканчивается примерно на 14000Гц(верхняя граница); конечно,есть магнитофоны,воспроизводящие и более высокие частоты(по паспорту), напр.,та же "Яуза-МП-220С"(25...16000Гц в режиме МЭК1/IEC1), но это достигается,так скажем,определенными ухищрениями(схемотехника,построение "адаптивно-диффер. подмагничив-я" и т.д.),и получить высококлассную запись на кассетной технике - так скажем,довольно сложно; у катушечных("бобинных") - граничная частота лежит в районе 23000Гц(верхняя,опять же), т.е., не самый сложный "бобинник" 2-го класса(с буквами "...-МПК-2###-Стерео" в названии) вполне способен "без напрягов"(и усложнения эл/сх по сравн-ю с "эталонной") воспроизводить спектр частот до 22000-23000Гц(в МЭК-1,т.е.,если на ленте с магн. слоем "Fe2O3"), а "навороченные"(типа "Олимп-МПК-004") - те вообще выдают "верхи" до 32000Гц(захватывая уже начальный ультразвуковой диапазон), а лучшие студийные(с широкой лентой ~4..6см) магнитофоны пишут/играют частоты до 50кГц(при частоте подмагничивания 1.5МГц), но это уже,опять же,"с ухищрениями". А у CD(-AUDIO) - граничная воспроизводимая частота лежит в районе 5..7кГц(в свое время просчитано сначала специалистами журнала "Радио",а чуть позже - журнала "КомпьюТерра",в 1995 и 1997г соответственно), - потому даже если просто "на слух" - то ощущается,что "бобинный" магнитофон играет в принципе "лучше","сочнее", чем кассеты и CD(который "супер-звук" обеспечивает только для записи речи(как раз те самые 5..7кГц максимум),а "верхи/низы" он чисто электрически не способен воспроизводить качественно; это решаемо увеличением частоты дискретизации до ~200кГц против стандартных 44.1кГц, но делать это ни один производитель не станет); да и,кстати,"сидюки"(аудио),в большинстве случаев,в тех же студиях, - пишутся "с бобин"(доподлинно известно от самих студийщиков).
Ну,это был небольшой "почти-оффтоп",а,возвращаясь к исходному вопросу, имелось в виду,что,при работе/пользовании,опытным(практическим) путем был установлен некий "предел",лежащий в районе ~1.3МБайт(для FDD высокой плотности). Проявляется это при наблюдении за свойствами(сохранностью) дискет 5.25" и 3.5": те же "5.25" на 1.2МБ 10- и более-"летней" давности прекрасно сохранились и читаются(и пишутся) в подавляющем большинстве случаев, а вот среди "3.5" на 1.44МБ, полежавших пару лет, - полно нечитаемых либо сбойных(плюс,еще вопрос качества изготовления 3.5"-дискет,особенно,в последнее время). Перевод 1.44М-дискеты в режим "720К"(т.е.,ниже вот этого "критического порога") путем заклейки окошка - снимает эту проблему: сбоящий на 1.44М диск начинает прекрасно читаться и форматироваться на 720(800)КБ.
Кстати,вот этот момент(с "критическим порогом" емкости/плотности дискет) - у кого-то из производителей(не дискет,а самого комп."железа") в каком-то "ДатаШите" упоминается(и опять же,сей момент был в свое время разобран в техническом подразделе "КомпьюТерры" в середине 90-х гг, - со ссылкой на оных же производителей дисководов).
#
RE:"FFORMAT+800.com":
Да,программа FFORMAT(by Shamarokov A., фирма "НПО LAB-6 GROUP",если не путаю) - прекрасная вещь(и мне очень нравится,моя,прям,любимая :) ) - незаменимый инструмент(до сих пор применяем,когда нужно). Кстати,все драйверы типа "800.com"(в т.ч. PU_1700, 900.com, DM8.com и их аналоги) FFORMAT при запуске отключает(у нее есть свои встроенные,ничем не хуже),для работы он ей не нужен(больше мешает,чем помогает).
Кроме того, FFORMAT может увеличивать(по запросу пользователя пред форматир-ем) скорость и надежность работы дискет(3.5" и 5.25",любых) - смещая начальный сектор на каждой дорожке таким образом,чтобы учитывать время перемещения головки с трэка на трэк(при DOS-форматировании первый сектор успевает уже "ускользнуть" от подошедшей головки,и приходится ждать его появления еще почти целый оборот, а FFORMAT смещает первые сектора на дорожках с учетом этого,"выкладывая" их этак.. "лесенкой", - в результате чего первый сектор оказывается под головкой почти сразу после того,как она встала на эту дорожку,- подробнее см. в докум. к FFORMAT'у,в главе "До чего не додумался Питер NORTON"), и "сдвигая"(т.е., не размечая) сектора на сбойных участках магн. покрытия дискеты(при фирменном алгоритме "ускорения доступа" FFORMAT - там допускается "сдвигание" плюс/минус аж чуть не в три сектора), тем самым их "обходя", - в результате чего дискета,ранее сбоившая после DOS Format, SAFE Format и даже всяких "PC-TOOLS", - после форматирования FFORMAT'ом начинает нормально(и в 1.5..2.5 раза быстрее - за счет "лестничной" "выкладки" первых секторов) читаться(и меньше "сыпаться" со временем). Кстати,это можно даже услышать - прислушавшись к щелчкам позиционера FDD при загрузке с "обычно-форматированной" и "FFORMAT'овской" системной дискеты: т.к. головка находит первые сектора дорожек почти сразу,то меньше время ожидания,и следоват-но,чаще следуют "щелчки" механики привода,и загрузка(хоть DOS,хоть UNIX/LINUX-boot,идет намного быстрее). :)
Подробнее - см. документацию к FFORMAT'у - там енто усе автором хорошо расписано :)
#
Означенный "предел" в ~1.3МБ - он,скорее всего,связан с (удельной?)плотностью записи(бит/кв.мм) и,как минимум,со свойствами самого ферромагнетика(рабочего магн. покрытия дисков): т.наз."коэрцитивностью"(грубо говоря, "отдачей"), величиной "копирэффекта"(меж соседними областями,где размещены сектора/дорожки), шириной "окна" петли гистерезиса(для данного материала магн. носителя - напр., Fe2O3(МЭК-1), CrO2(тип2/МЭК2), FeCrCo(тип 3,МЭК-3) или "Metal", он же "тип IV"/МЭК-4,самый "крутой") и мн.другими. И,как и для "обычных" магнитофонов(а флоп и даже HDD - по сути ими и являются,только цифровые и с электронным управлением), - означают определенную "верхне-граничную" величину(повторюсь), выше которой получить высокие параметры "сложно" либо так или иначе "затратно"(если даже в принципе или технически это все же возможно).
#
Форматы(опять же,свыше емкости в ~1.3МБайт), до физического максимума в 1.78МБайт (85дорожек,20секторов,2головки - в меню у FFORMAT,если ничо не путаю), несмотря на то,что могут быть выполнены FFORMAT'ом, - тем не менее, по предупреждению самого же автора FFORMAT'а(см.,опять же,документацию), - являются НЕСТАНДАРТНЫМИ(и не всегда гарантируемыми!!). Т.к.: а)дорожки номерами свыше 82-й - могут ФИЗИЧЕСКИ НЕ поддерживаться дисководом/контроллером(даже на навороченном IBM PCшном,не говоря уже о "простеньком" 1801ВП1-097/ВП1-128); б)число секторов свыше 15(18) - то же самое,что в п."а)". И еще пункт "в)": как говорит в документации сам Шамароков(FFORMAT), "сделав несистемную(а тем более - системную) дискету нестандартного формата,особенно ближе к 1.78МБ, - ОБЯЗАТЕЛЬНО ПРОВЕРЬТЕ, - БУДЕТ ЛИ ВАША ЭВМ РАБОТАТЬ С НЕЮ!"(и приводится куча примеров/моделей флопов,когда после ЗАВЕРШЕНИЯ загрузки - такая дискета просто перестает читаться в ОС,хотя загрузка была 100% успешна). Тем более,что: г) даже в "то" время автору попадались экземпляры дискет,которые нормально "держали" формат в 1.44М, но тут же начинали "сыпаться" при форматировании свыше 1.65МБайта.
Хотя,у меня,на моей тогдашней AMD 486DX4-120(системн.плата марки "BEKTRON-P4O7 rev.2.00"),дискеты на 1.78М,даже системные,нормально виделись даже после загрузки в DOS(без всяких "800"/"PU_1700"),а на другановском "Пеньке"(P-120,сист.плата "UNIIMPORT") - бывали "глюки"(возможно,связано с особенностями аппаратного контроллера FDD на этих платах,т.к. дискеты пробовали одни и те же самые).
Т.е.,опять же,длительное хранение данных на таких дискетах - ну.. не всегда может быть надежно. :)
-
? RADIX50 - 07.04.2016 11:47
RE:"? maxstudios@ - 07.04.2016 09:02
Я в те года тоже столкнулся с проблемой заклеенного окошка":
Да,в свое время тоже это выяснили :)
Расскажу,почему так происходило.
В большинстве 5.25"-приводов датчик "заклейки"(правда,в том случае это - защита записи,ну да неважно) в большинстве случаев - оптический(на просвет стоят диоды "фото-" и "свето-",короче,оптопара).
А в 3.5"- там и на "запись",и на "плотность", - в большинстве моделей стоят не оптопары,а "микрики"(либо вообще пружинные контакты,причем,довольно жесткие/грубые),которые продавливают изоленту,при этом выдавая сигнал "замкнуто"(т.е.,"плотность высокая" или "запись разрешена",если "собачка" сломана и была заклеена).
Я в таких случаях дополнит-но "усиливал" дырку,производя армировку кусочком ластика либо просто мятой/жеваной бумажкой,заклеив черной изолентой с обоих сторон(пластилин все же липкий/жирный и пачкается) :)
...Бывали и исключения из оного "правила": попадалось примерно 10..12%(от общего числа имевшихся устройств) 5.25"-FDD,у кого вместо оптронов стояли как раз "микрики"(продавливавшие иногда даже сплошной конверт "фирменных" дистрибутивных дискет, - такие "флопы" у нас звали "убийца дистрибутивных дискет",т.к. на "нормальных" приводах записанную на такие дискеты инфу(для приколу - порно_GIF'ки или пахабные рассказы в формате .TXT) невозможно было стереть,не отвинтив оптодатчик "запрет записи" :-D). Был,кстати,"фирменный" 5.25"-флоп(раритетный экземпляр,надо сказать!!), у которого дискета вставлялась и выдвигалась КАК У 3.5"-ДИСКОВОДА(т.е.,на панели не поворотный "рычажок", а кнопка(!),а внутри - рама по контуру конверта 5.25"-дискеты), - да,и конечно же,с функцией "убийца дистрибутивных дискеток"(а как же иначе!) :-D :-D
Ну,и соответственно,иногда попадались модели 3.5"-дисководов со встроенными ОПТОДАТЧИКАМИ(взамен штатных "микриков"/механ.контактов) - для таких армировка окна плотности (и защиты от) записи НЕ требовалась(у самого на рабочем компьютере стоял именно такой, и я долгое время не мог понять: почему на соседскоЙ ЭВМ не срабатывала плотность "720КБ",хотя окошко на моей дискете заклеено,пока не выяснилось). :) :)
#
RE:"помню, была ещё плотность 2.88 Мб на 3.5" дисководах. Называлась вроде бы HD":
Насколько помню "системные" обозначения некоторых форматов,нумерация была такая:
720КБ - DS,DD(2-стор,"двойн.плотн."): 80 дор.,9сект.,2головки;
Все,что выше 800КБ, - шло уже как "HD"(общая,так сказать,категория):
1.2М - QD-15(2S,HD): 2головки,80дор.,15секторов;
1.44М - QD-18(2S,HD - выбито на пластм.корпусе 3.5"-дискеты): 2стор.,80дор.,18секторов;
...
Форматы емк-тью свыше 1.8М - обозначались как "ED"- extended density.
2.88M - "ED": 2головки/160(???)дорожек, или 2головки/80дорожек/36(???) секторов.
Визуально - дискета 2.88МБ определяется таким образом: если смотреть на ее лицевую часть(наклейкой к себе), повернув защитной шторкой рабочей поверхности диска(сдвижная,с краю дискеты,ею вставляется в щель флопа) "вверх" (при этом передвижная "собачка"-защелка окна защиты записи будет внизу=слева, а окно плотности записи - справа внизу), - то окно плотности записи будет "двойное"(две квадратных дырочки) либо однарное,но по площади "как две"(справа-внизу).
НО!
Дело было в том,что такие емкости/форматы "не пошли" - т.к.,а) требовали специальных дисководов 3.5"(у которых ФИЗИЧЕСКИ установлен еще один датчик плотности записи и имеется соотв. электросхема управления током подмагничивания/предкомпенсации и т.д. !!); б)специальных дискет(с магн.слоем на основе модифицированного Ферро-Кобальта(тип III/МЭК-3) или "Метал"(тип IV/МэК-4),с большой "коэрцитивностью"), рассчитанных на такие режимы записи(как магнитная лента для магнитофонов - то же самое).
Для сравнения: для 1.2/1.44М хватало "CrO2"(распространенный "тип II"/МЭК-2,цвет черно-блестящий),а для 180/360/720/800К - "обычного массового" Fe2O3("тип I"/МЭК-1,цвет от темно-рыжего до темно-коричневого) - в общем,все,как для "привычной" магнитной записи.
Аналогично,как и в случае с магнитными лентами типов "3" и "4"("железо-кобальт" и "металл"), дискеты с таким магн.слоем получились очень дорогими, а сами дисководы - мало что дорогими,так еще и очень капризными и ненадежными(в работе/ремонте/обслуживании) и чувствительными к воздействиям(намагничивание деталей привода посторонними магн.полями, нарушение юстировки блоков головок/приводов и т.п.).
Поэтому дискеты и приводы на 2.88МБ распространения не получили и очень быстро ушли с рынка.
...Конечно,можно расширить окошко плотности записи(надфилем) у обычной дискеты на 1.44, но,во-первых,обычный 1.44М-дисковод не умеет читать/писать диски на 2.88М(загляните в щель - нет там справа второго "микрика"), а во-вторых,сама 1.44М-дискета(DS/HD) чисто физически(в силу недостаточной "отдачи" магнитного слоя) не сможет "удержать" формат в 2.88М(аналогичный опыт можно провести,просверлив дырочку "высокой плотности" в 3.5"-дискете "DD",изначально рассчитанной на 720К, и сформатировать ее на 1.44 или хотя бы 1.2М: если получится,то скоро перестанет читаться). Аналогично тому,как лента типа "I"(Fe2O3) не сможет работать в режиме "II","III","IV"(запишите музыку на "простую" кассету,тип "1",включив магнитофон в режим "CrO2"..."Metal" и послушайте): расширенный частотный диапазон она просто "не удержит"(звук будет "глухой" и "грязный").
Примерно так :)
-
? RADIX50 - 07.04.2016 12:05
SUBJ:"дискеты на 2.88МБ":
...Однако,емкость 2.88МБ все же можно получить на "обычном" 1.2/1.44М-дисководе,не модифицируя физически ни флоп,ни дискеты.
Есть такая программа(пакет программ): XDF.COM(по-моему,драйвер и форматтер) и XDFCOPY.COM(копировщик таких дискет), загружается по принципу 800.com или PU_1700.com(резидентно).
Число секторов/дорожек остается тем же самым,но эти программы умеют форматировать,изменяя емкость сектора(делая ее более чем 512Байт) - но,опять же,сам контроллер FDD должен физически предоставлять такую возможность(напр., i8272 различает/умеет делать 256,512,1024,2048 Байт/сектор,задается программно через регистр).
Беда в том,что больше никакие программы,кроме самих "XDF",такие дискеты не читают,а SCANDISK или NDD может вообще запросто "грохнуть" всю инфу,посчитав такую дискету "сбойной" и "вылечив" ее в известный ему "стандартный" формат 1.2/1.44(т.е.,скопировать,допустим, том архива(.RAR, .ACE, .ZIP) с такой дискеты,если "посыпется", - будет невозможно).
Хотя,нет,вру: дистрибутивный пакет дискет от "исходной" Windows-95(сборка 4.00.950, 24.08.1995) как раз-таки записан томами по 1.77МБ(в модифицированном/похожем на XDF формате), но распознается только самим установщиком(при запуске SETUP с жесткого диска - работает "как обычно",ничем не отличаясь).
...
Вот,видимо,после "провала" с "стандартным" форматом 2.88М, вышли из положения таким способом,написав такой нестандартный драйвер :)
-
? MM - 07.04.2016 14:35
1.44/1.6 метра емкость диска 80 треков на БКшке с 4 мгц 1801ВМ1 никак не допрыгнуть аппаратно - без навороченного контроллера по типу КЖД ДВК.
Дело в том, что на 3 мгц частоты процессора уже не хватает для стабильной поставки данных в ВП1-128 ( на запись ) - для конкретной стабильности записи нужно не менее 3.5 мгц. Соответственно, на 2 мгц 1801ВМ1 совсем никак не может писать диски 720/800 кбайт по причине недостаточности быстродействия М-ЭВМ БК.
Если необходим контроллер МД с теоретической возможность писать 1.44 плотность 80 треков - это ВГ93. Да, она содержит массу непрятных особенностей, но гуру Z80 приделывали её к своим М-ЭВМ с изрядным разгоном и получали хорошие результаты - гуглим.
Если приделывать такой наворот к БКшке - потребуется вариант "Кочана" с обвесом - т.е. нечто, весьма похожее на контроллер ГМД Э-85 или аналогичное изделие для Э-60 . Ну или использование более быстрых процессоров в БК - не менее 700 т. рег-рег - в районе 1801ВМ2-8 мгц или 1806ВМ2-5 мгц. Это только теория...
-
? RADIX50 - 07.04.2016 14:47
RE:"? Anonymous - 07.04.2016 10:29
...два 1.44 на БК и один 1.44 на Кванте, для переноса данных стандартными дискетами,со scsi-контроллером...":
#
...Посмотрел(еле откопал прошлые сообщения)..
Если флопы работают именно в режиме "HD"(1.44MBytes),и "TEAC FDC-01" модифицированный, то,скорее всего,это уникальный(в смысле,"штучный") экземпляр, к сожалению,не массовый. :)
В 1990-е гг,по имеющейся от бывших "Горбушечников" информации,на том легендарном рынке "проскакивало" довольно много оригинальных модификаций,как правило,тоже "единичных",ни с чем больше не совместимых(включая расширение ОЗУ до 4МБайт или,напр., варианты ПЗУшных DOSов/копировщиков/дебуггеров(типа RAMON или ИВФ) с поддержкой FDD,пусть и в своем нестандартном формате,для БК-0010 без доп.ОЗУ и т.п.), но все они были сделаны либо "под себя", либо "под конкретную задачу"(вплоть до того,что контроллеры FDD также паялись по собственной,более или менее сложной,схеме, - естественно,не гарантируя совместимость с массовыми/стандартными устр-вами/форматами).
Вопрос этот,оказывается,"всплывал" здесь и раньше,но,видимо,"совместимых"("повторимых") разработок пока нет.
В сообщении(в вопросе) речь шла об использовании 1.2/1.44МБ-дисковода в режиме "HD" на "стандартном" контроллере(естественно,с обратно-совместимой поддержкой формата на 360/720К),с возможностью форматирования системных дискет и загрузки с них.
Из совокупного мнения знающих людей(с кем удалось более-менее плодотворно пообщаться на эту тему,которые действительно попытались вникнуть в суть вопроса,а не начинали сразу же советовать "купить "i386"-ю и забыть об этом"), отталкиваясь от того факта,что в годы оные тогдашние "IВМ 8086-XT" старших моделей(а также первые "286-AT") одно время комплектовались контроллером,поддерживавшим FDD на 1.2(1.44)М, хотя,"икстишка",грубо говоря,по быстродействию примерно такая же(тактовая частота тоже около 4.4МГц), - общими усилиями удалось прийти к выводу, что повышенная скорость передачи данных в оба направления ("от" и "к" диску) обеспечивалась,предположительно,наличием в XTшном FDD-контроллере некоего "DMA-буфера"(как его называли респонденты,возможно,тоже "условно"), как раз,по их мнению,и обеспечивавшего запоминание/хранение части передаваемых данных(в обе,причем,стороны),которые не удавалось корректно обработать "на лету", и "добавлявшего"("вываливавшего") их на интерфейс при наличии таковой возможности.
В случае с "БК-0010/011", видимо,подобный контроллер(работающий на "-10"-й и "11"-й моделях) пока не удалось сконструировать(хотя,где-то на форуме периодически-"точечно" идеи на эту тему проскакивают).
-
? RADIX50 - 07.04.2016 15:12
RE:"? MM - 07.04.2016 14:35
1.44/1.6 метра емкость диска 80 треков на БКшке с 4 мгц 1801ВМ1...;
...наворот к БКшке - потребуется вариант "Кочана" с обвесом...":
#
Немного не успел прочесть сообщение(не вовремя обновилась открытая страница),прошу прощения :)
...Но,да,при обмозговке вопроса тоже в итоге склоняюсь к похожему варианту(получается примерно по тому же принципу,как с ISAшными звуковыми платами в свое время,содержавшими "на борту" довольно мощный спец.процессор для обработки именно звуковых данных(с ЦАП и/или АЦП "в обе стороны"), а потом просто выдававших "готовый" ".WAV"(или RAW/BIN) нужного качества(16-24bit, 44-96kHz и т.д.) на интерфейс.
Только вместо "КАЧАН"(и обвеса) возникает идея попытаться прикрутить уже имеющуюся м/сх марки NEC 6####(не помню цифры..), как-то попадавшуюся при беглом просмотре стандартных библиотек PCAD'а при поиске какого-то элемента, - в общем-то,почти готовый контроллер(правда,только FDD,а не как в "SMK-##"),и вроде бы,с мультиплексированной I/O-шиной(по-моему,даже еще и инверсная). Т.к.,если этот "NEC #####" заявлен как поддерживающий высокую плотность(судя по библиотечным обозначениям сигналов на выводах), то,возможно,что почти все необходимое там внутри имеется(включая указанную чуть выше буферизацию на запись и чтение). Похожий чип(аппаратный контроллер FDD) по сей день ставится на материнские платы для IBM PC(как ноутбуки,где был конструктивно предусмотрен FDD как таковой, так и настольные), только,естественно,чип другой марки(т.к. эти ЭВМ - другой архитектуры, с DEC/ALPHA не совместимые), но принцип тот же :)
...
Про БКшный контроллер на "ВГ93"(по-моему,какой-то армянский,название на "-дзе") - да,было и такое(интересно,насколько совместим он с остальным БКшным ПО и получаемы(ми) формат(ами) дисков). :)
-
? Дмитрий - 07.04.2016 15:51
>> Если необходим контроллер МД с теоретической возможность писать 1.44 плотность 80 треков - это ВГ93. Да, она содержит массу непрятных особенностей,
Так ведь есть НЕК/Интел МС контроллеров дисковода (про нее как раз и говорит ув. RADIX50) - на ней разве не получится изготовить контроллер? Зачем ваять на глючном? Или НЕК/Интел достать сейчас нереально?
-
? RADIX50 - 07.04.2016 16:16
To: Дмитрий 07.04.2015 15:51
RE:"ВГ93":
#
Да и на ВГ93("синклеровской") сделан был контроллер FDD(нашел как называется - от армянской фирмы МУП "Ширакадзэ"), правда,мне "живьем" не попадался,хоть убей, но название и внеш.вид - запомнил(в свое время видел на "барахолке" в 90-е), уж не знаю,насколько она там глючная и как эти глюки "софтово" маскируются :)
Интеловский - это i8272(аналог нашего КР 1810ВВ72,чтоль,из комплекта поставки "СМ609","ЕС-1840"; возможно,чем-то похож на "1818ВГ93"(может быть), но все же он отличается).
...
А "NEC6####" - есть в станд.библиотеке установочных элементов в PCAD'е :)
Наверняка,в реале тоже есть(раз включена в библиотеку стандартных элементов) :)
Достать,думаю,не такая уж проблема(надеюсь),пусть хоть и на платах (кучкой,на барахолке,с разборки аппаратуры,допустим). Вопрос может быть в адресации(к этой "NEC 6####"): т.е.,как минимум,какие регистры,где расположены(на какие адреса "отзываются",и т.д.) и совместимости такого контроллера с имеющимся ПО для БК(0010 и 0011,а возможно,еще и для проектируемой "-0012"),т.е.,сможет ли тот же MKDOS или ANDOS(или "Micro-UNIX-БК") с его помощью работать с дискетами.
...Могу обратить внимание еще на один момент: сделать-то можно(допустим) FDC БК на 1.44МБ, но большинство имеющегося ПО и образов дисков(причем,как на БК,так и на ZX) - "заточены" под 720КБ(та же "TR-DOS" , "CP/M" и похожие).. Кстати,вот,тут "вылез",оказывается(см. сообщение от ММ чуть выше) еще один "глюк" - неустойчивое чтение/запись даже в режиме 720КБ(хотя,упомянутые мною контроллеры FDD 1.2/1.44 для тех же PC XT, - они работали без всяких там "подгонов" и "подборов" частоты: просто вставляешь в разъем(в ЭВМ) и подключаешь к дисководу, - и даже на тактовой частоте в 4.5МГц они умудрялись обеспечивать корректную работу и на 1.2/1.44М, и на 720К, - видимо,действительно в том контроллере имелась встроенная буферизация для предотвращения "выпадения" передаваемых данных при работе в режимах "высокая плотность"?).
-
? Дмитрий - 07.04.2016 17:52
>> но большинство имеющегося ПО и образов дисков(причем,как на БК,так и на ZX) - "заточены" под 720КБ
Там все через "драйвер". То бишь софту пофигу формат дискеты. Драйвер перенастраивается на другое кол-во секторов на дорожке и все. АНДОСу мб и плоховато будет, ибо заточен под 800кб, а CSI/MKDOSу - пофигу. Тот же МКДОС работает с разделами до 32мб.
-
? maxstudios@ - 07.04.2016 20:51
Не знаю, как там МК-DOS, а вот с AN-DOS у меня проблем вообще не возникало относительно переделки дисков от БК на PC.
Помнится, была в составе AN-DOS утилитка маленькая, выглядела при запуске типа так:
1. БК -> IBM
2. IBM -> БК
Утилитка что-то делала с нулевой дорожкой, наверное приводила её формат в соответствие с выбранным форматом, после чего диск читался на РС или на БК.
Думаю, что именно AN-DOS работала с форматом на 720 Кбайт, так как на РС никаких драйверов и программ я никогда не запускал, всё работало сразу - в WORD-е диски БК читались сразу и без проблем.
Ещё в то время я думал - почему на БК нельзя было сразу взять формат РС, чтобы не было проблем с чтением дисков дабы не мучать эту утилитку постоянно.
Кстати, до сих пор интересен этот вопрос на аппаратно-программном уровне, может кто умный объяснит мне и всем эту разницу? И возможно ли вообще написать DOS, которая будет работать в стандарте флоппи дисков от РС на 720 Кбайт?
;)
-
? Дмитрий - 07.04.2016 21:51
А зачем? У меня вообще безо всяких программулек диски БК читались на РС и наоборот. Хз как насчет обычного КНГМД, но СМК делал это "из коробки". Там в одном месте задержка ставилась в два раза больше и все работало.
-
? RADIX50 - 07.04.2016 21:55
RE:"? maxstudios@ - 07.04.2016 20:51
Помнится, была в составе AN-DOS утилитка маленькая, выглядела при запуске типа так:
1. БК -> IBM
2. IBM -> БК...":
Это служебная утилита "IBM-2-BK"(и ей обратная "BK-to-IBM"). Чтоб прочитать БКшный диск на IBM,надо было выполнить ее в режиме "БК-to-IBM": эта программка вносила изменения в нулевой (boot-)сектор нулевой дорожки, т.к.,если этого не сделать,то IBM,не найдя в бут-секторе дискеты сигнатуру "55Ah",на нее "ругнется" и видеть эту дискету откажется наотрез(будет выдавать сообщение типа "Non-DOS-Disk Error"), несмотря на то,что физически и логически БКшная дискета будет 100% исправна. Ну,а т.к. БК И IBM - машины разные(несовместимые по системе команд и ассемблерам/машинн.коду), то загрузочная запись в нулевом секторе дискеты от БК будет содержать совершенно другие машинные команды,нежели на IBMской(в т.ч.,байт-дескриптор описания носителя тоже будет не 55Ah,а другой,принятый в той системе,для какой отформатирован диск для БК,который мы будем пытаться прочесть на IBM). Аналогичным же образом та же IBM под DOSом не всегда читает IBMовские же диски,но отформатированные в стандарте POSIX(родная файл.система некоторых версий UNIX), а та же УКНЦ - в упор не видит диски в "FAT" от IBM(а в UNIX/LINUX дескрипторы для стандартных типов оборудования - опять же,"свои",т.е.,другие).
Отредактировав нужный файл на IBM,чтобы прочесть его на БК, перед переносом дискеты на БК теперь нужно либо на БК,либо на IBM выполнить утилиту в режиме "IBM->to-BK"(которая заменит в нулевом секторе временно вписанную в нужное место сигнатуру 55Ah на другое значение,принятое на БК/УКНЦ),и дискета будет читабельна уже на БК(и НЕчитабельна на IBM,т.к. эти машины/системы - изначально несовместимы,разные архитектуры).
#
RE:"сразу взять формат IBM...": ну,по сути,в общем-то,практически так оно и было сделано. Потому что в те времена все стали разинув рты смотреть на IBM как на "идола", при разработке ANDOS господин Надежин взял в качестве основы стандартный формат "FAT12",с той лишь разницей,что в какие-то атрибуты файлов/директорий вместо принятых на IBM значений заносится,например,адрес загрузки файла(для БК); в другие поля - длина файла,в третьи поля - контрольн.сумма(и т.п.),что понятно ANDOS'у,но "непонятно" для IBM; сама же по себе секторно-дорожечная структура - в целом такая же,как в "стандартном" FAT12.
Похожие "непонятки" наблюдались в свое время у нас в дисплейном классе при переноске дискет между ЭВМ марки "YAMAHA-MSX-1"(по сути, Hi-End-версия "Синклера") и собст-но,IBM как таковых: IBM прекрасно читала корневой каталог "Ямаховских" дискет(тоже FAT12), но вот дальнейшая работа с файлами,кроме как копирование, была невозможна(из-за некоторых различий в _логической_ структуре форматов носителей): ни один файл нельзя было ни открыть на просмотр,ни удалить.
Вот такая вот штука :)
#
RE:"написать DOS...": ну,в виде "одиночных"/разрозненных попыток/экземпляров что-то "наваять" - это уже было сделано(в те же 90-е гг) многими Кулибиными-БКшниками-одиночками(в отсутствие интернета,не знавшими о существовании других таких же "одержимых"), о чем свидетельствует "куча всяких разных DOSов,практически несовместимых между собой...(C)".
Написать "одну","большую", DOS(а вроде бы,в 1995г. клуб "ELESIM",помимо подключения к БК CD-ROM'а, "замахнулся" на написание "БК-Windows"), - наверное,возможно, - но при наличии большого объема памяти(ОЗУ) и определенного,как говорит ув.тов. ММ(см.выше) увеличения быстродействия ЦП БК-0010(-0011).
Т.к., напр., корневой каталог с того же CD-ROM на БК прочитать вполне можно(он занимает килобайты), а вот оцифровать даже монофонический звук с качеством 16бит/44.1кГц, не говоря уже о воспроизведении ".MP3", - уже нет(если не применить какой-то специализированный чип/устройство типа того же аппаратного MP3-декодера типа "TMS#####",пару лет назад предлагаемого ув. "TheGWBV",есть у нас такой персонаж на форуме).. Ну,или как предлагает ММ, "блок "КАЧАН" с кучей обвязки"(для работы с 1.44МБ-дисками на БК-0010/0011).
...При наличии ЦП с более высоким быстродействием ряд вещей(напр., образно говоря, преобразование/распознавание из БКшного в IBMский формат) можно будет делать "на лету",располагая более развитым алгоритмом(размещаемым в расширенном объеме ОЗУ), и т.д.
Вот,на мой взгляд,примерно вроде так :)
-
? TheGWBV@ - 07.04.2016 22:11
ЕМНИП в прошивке стандартных КНГМД есть ошибка кода, которая не позволяет работать с 9-ю секторами на дорожке, а с 10-ю -- без проблем.
АНДОС-овская утилита нужна была только для загрузочных (на БК) дискет и меняла область загрузчика так, чтобы другая система не впала в шок и панику от прочитанного :)
Вин-95-98 принимали дискеты с 10-ю секторами на дорожке как свои родные, но форматировать их нужно было на БК.
Не помню точно, были ли БК-утилиты для переноса файлов с 9-ти секторных дискет ИБМ на БК и обратно, которые использовали собственный код для работы с ВП-128 (драйверы форматирования такие точно были/есть)...
Имхо, сейчас уже нет смысла писать драйверы КНГМД для ДОС под формат 720 Кбайт и дискеты -- лучше переписать прошивку КНГМД для целей работы с SD-картой, сохранив стандартные точки входа и формат блока параметров (чтобы старый софт не заметил подмены). Если используется SMK/Booster, там есть возможность прицепить драйвер вашего устройства хранения к RAM BIOS и перенаправить на него дисковые запросы ДОС. При этом SD-карту можно разделить на две партиции -- на одной будет раздел FAT16, например, а на другой образ HDD БК в формате АльтПро. Работы в этом направлении ведутся (пишется утилита для работы с ФС FAT16 непосредственно на самой БК-ашке, которая позволит обмен файлами между разделами МКДОС "на HDD" и разделом FAT16 на SD-карте)...
-
? Anonymous - 07.04.2016 22:12
「? RADIX50 - 07.04.2016 14:47 Если флопы работают именно в режиме "HD"(1.44MBytes),и "TEAC FDC-01" модифицированный, то,скорее всего,это уникальный(в смысле,"штучный") экземпляр, к сожалению,не массовый. :)」
Отнюдь, http://bitsavers.trailing-edge.com/pdf/teac/brochures/TEAC_FD-55GS_Brochure_Feb91.pdf ,модификация заключается в переделке на 3.5" 1.44мб заменой прошивки.
-
? TheGWBV@ - 07.04.2016 22:27
>> RADIX50 - 07.04.2016 21:55
>> ...а вот оцифровать даже монофонический звук с качеством 16бит/44.1кГц, не говоря уже о воспроизведении ".MP3", - уже нет(если не применить какой-то специализированный чип/устройство типа того же аппаратного MP3-декодера типа "TMS#####",пару лет назад предлагаемого ув. "TheGWBV",есть у нас такой персонаж на форуме).
Персонаж то есть, но такого предложения не помнит, хотя принципиально не против прицепления мр3-декодера к БК :)
-
? RADIX50 - 07.04.2016 22:34
RE:"написать DOS..в стандарте IBM-флоппи дисков на 720К"(дополн-е к предыд.сообщ-ю):
_
...Да по-моему,тоже уже написано: на той же IBM есть утилита для чтения на "XT-шке" дисков от RT-11 :)
Дисков от RT-11 в те годы под рукой не было,а XT'шка с этим софтом - была ))
#
To: TheGWBV:
RE:"чтоб другая система не впала в шок от прочитанного :) ... ":
Ну,в общем-то,я как раз об этом и говорил(см. мои сообщ-я чуть выше), т.к. дескрипторы(описания носителей) для разных систем(и ЭВМов) могут быть разные(напр.,взять тот же NTFS'ный диск на той же IBM: он виден только в BIOS-SETUP'е и спец.утилитами типа "ACRONIS" или "P_MANAGER",и более ничем; не говоря уже о разных файловых системах на разных дисках разных ЭВМ).
Вот :)
-
? RADIX50 - 07.04.2016 22:50
To: TheGWBV
RE:"MP3-декодер на БК":
...Одно время,когда "зацепились" за эту идею(в момент обсуждения оной),была куча вариантов и предложений, но,к сожалению,к единому мнению придти не удалось,а идея со временем как-то немного "заглохла" :)
Один из вариантов был сделать плеер на БКшный "LPT"(он же "УП"),по-моему,как раз с Вами мы его немного пытались обсудить(но там тоже,как и в случае "шинного" декодера с подкл-ем на МПИ,требовалось аппаратное декодирование с помощью м/сх то ли "STA####", то ли "TMS####",либо какой-то другой похожей), если ничего не путаю :)
...И в итоге,под "шквалом" предложений/вариантов идея "завязла"(но все же так или иначе Вы убедили,приведя к выводу,что кидать байты в порт "УП" на тот декодер - не такая уж и сложная задача). :)
Да и вообще,в общем-то,без особой разницы,какой декодер(чип,м/сх) впаян, главное,чтоб работало :)
На том же "ZX" - и .wav,и .mp3 уже давно "синклеристы" слушают :)
-
? TheGWBV@ - 07.04.2016 23:14
>> RADIX50 - 07.04.2016 22:50
>> ...(но все же так или иначе Вы убедили,приведя к выводу,что кидать байты в порт "УП" на тот декодер - не такая уж и сложная задача). :)
Такое помню :) Если у этого модуля ещё и буфер FIFO будет килобайта на 4-е, может даже получится 64кбит/с мр3 воспроизводить любой длительности.
"STA####" в итоге Бустеру достался, но пока там не прижился...
-
? maxstudios@ - 08.04.2016 00:19
Из всей вышеприведённой информации я почерпнул, что диски не работали только загрузочные, и утилита нужна была только для загрузочных дисков. Не загрузочные диски должны работать и на БК и на РС.
Так?
Когда-нибудь проверю. ;)
...
А вот почему не прижился STA#### на Бустере? Он там остался физически, доступ какой-то к нему есть?
-
? CD-Inc - 09.04.2016 01:03
TheGWBV права: модификация нужна только для загрузочных АНДОС-дисков.
Через обычную АНДОС-800кб-дискету на ХР перетаскивал без проблем.
-
? maxstudios@ - 09.04.2016 10:33
Странно вот что - если 720*2=1440, то заклеиванием окошечка на дискете мы получаем 1440/2=720 Кбайт.
А тут пишут, что 1440/2=800 Кбайт. :)
800 Кбайт на РС для 3.5" дисковода - это явно не стандарт.
;)
-
? MM - 09.04.2016 11:20
720 из 800 - это МС ДОС отгрызает себе - она там на диске водится в тени. В RT-11 такого почти нет - ОС открыто болтается в каталоге. Ну разве что начальный загрузчик отжирает ~4 блока ( 2 кбайт ) из объема диска.
-
? RADIX50 - 09.04.2016 11:32
RE:"
Странно вот что - если 720*2=1440, то заклеиванием окошечка на дискете мы получаем 1440/2=720 Кбайт.
А тут пишут, что 1440/2=800 Кбайт. :)":
#
Насколько помню(из курса обучения), формат дискеты получается не делением "1440/2", а путем перемножения количества поверхностей(цилиндров)*кол-во дорожек*кол-во секторов*емкость одного сектора. Т.е.,2стор *80дор * 9сект * 0.5КБ = 720К
Для случая 800К - это будет 80дорожек при 10секторах на дорожке(и на 5.25", и на 3.5" форматируется даже обычным FORMAT.COM при задании ключа /T:## /n:## в ком.строке даже в DOS 6.##/5.##, а также расписано в меню программы FFORMAT).
Для дискет "не высокой"(т.е., "DD"-плотности) формат в 800К является одним из "предельных",но еще "стандартным",читаемым обычными средствами; а вот если сформатировать 83 или 85дорожек,в зависим-ти от того,сколько сможет поддерживать конкретный экземпляр дисковода, - вот тогда уже да, пошел "нестандарт",вроде всяких там "836КБ, 932КБ" и т.д.).
...Кстати,на большинстве 5.25"-HD-дисководах(которые 1.2МБ) дискета "DD"(даже полностью "стандартного" формата на 720КБ,80дор/9сект.), без драйвера типа "800.com", "900.com", "PU_1700.com" - никак не читается(приходится или запускать резидентный драйвер,или форматировать на 360К) - проверено в свое время в долгих и упорных попытках сформатировать "не-HD"-дискету(5.25") на возможно б_О_льшую емкость,и чтобы не было сбоев записи-чтения информации.
...Уж не знаю,в чем тут дело - в самих дискетах или в FDD-контроллере у IBM PC, но факт оставался фактом: позиционер дисковода как-то "нездорОво" лязгал и щелкал(а в режиме 360К/1.2М он работал тихо и плавно,хотя и у 720К,и у 1.2М - число дорожек одинаково и оно = 80).
Примерно так :)
-
? RADIX50 - 09.04.2016 11:37
...Подробнее - см. в документации к программе FFORMAT v.2.70(2.99), - там автором про все возможные форматы дисков прекрасно разобрано.
:)
-
? RADIX50 - 09.04.2016 11:42
RE:"720 из 800":
MS-DOS "отгрызает", насколько понимаю,в любом случае и от любого объема форматированного диска: и от 360К, и от 720К, и от 1.2(1.44), и от 1.79МБ(макс. допуст. формат для 3.5", при макс.доп. числе дорожек и секторов, см. меню прогр. FFORMAT), и от 2ГБайт(жесткого или FLASH-диска), т.к. ей требуется место для размещения своих системных файлов: в простейшем случае, IO.SYS, MSDOS.SYS(в Win9x- этот файл текстовый) и COMMAND.COM для DOS 6.22 занимают ~46КБ дискового пространства, причем,файл COMMAND.COM НЕ является скрытым и может быть скопирован оператором ВРУЧНУЮ.
-
? maxstudios@ - 09.04.2016 13:10
Вот нашел ссылочку http://bk0010.narod.ru/docs/800kb_floppies.html
Там как раз указана разница - на БК 10 секторов, а на РС - 9 секторов.
Вот я и думаю - может, AN-DOS умеет писать не 10, а 9 секторов на дорожку?
Кстати, ув.ММ писал, что быстродействия БК не хватает для записи 18 секторов на дорожку.
А ведь если секторов на дорожку нужно будет не 10 а 9, то запись получится надёжнее!
Думаю, что в AN-DOS мог использоваться свой нестандартный драйвер под 9 секторов, чтобы диски были всечитаемыми - как на БК, так и на РС.
По вышеприведённой ссылке, в самом низу, есть "...таблица параметров стандартных форматов флоппи-диска 5.25”... ". Вот выдержка из этой таблицы:
720k (РС) /dev/fd0h720 1440 9 2 80 0 0x23 0x01 0xDF 0x50
800k (БК) /dev/fd0h800 1600 10 2 80 0 0x25 0x01 0xDF 0x2E
...
Но есть ещё один нюанс - дескриптор носителя под MS-DOS.
По ссылке: https://support.microsoft.com/ru-ru/kb/75131
можно увидеть, что для 3.5" дисководов использовалась только разница в количестве секторов на дорожку.
То есть, для 720 Кбайт - 9 секторов, для 1.44 Мбайт - 18 секторов, и для 2.88 Мбайт - 36 секторов.
Но вот вопрос - если в РС будет вставлена дискета от БК на 10 секторов (800Кбайт), то какой дескриптор тогда нужно указать на диске, чтобы он читался на РС? Ведь на 10 секторов работали только 40 дорожечные форматы.
В общем, интересная тема, но сложноватая для разборок.
:)
-
? RADIX50 - 09.04.2016 13:53
RE:"диски всечитаемые":
Ну,IBM,напр.(под DOSом,конечно), читает YAMAHA'вские дискеты(они на 720К, 3.5"), видны файлы в корневом каталоге и т.п., какие-то небольшие различия есть только в логической структуре(кластер,директория,файл - объекты логические, сектор/дорожка - объекты физические). А возм-ть,допустим,удалять файлы(на IBM с дисков YAMAHA или наоборот) - это уже дело другое :)
Кстати,та же IBM (в DOS'е) не прочитает свой же диск(хоть FDD,хоть HDD) стандартного же (720, 1.2/1.44) формата, если он сформатирован под какой-нидь POSIX, HPFS или NTFS (нужен особый спец. драйвер). Причем,NTFSные диски видятся только из BIOS либо в крайн.случае FDISK'ом, но только как физ. устр-во(HDA1, 40GB,допустим). Аналогичная штука была при форматировании HDD(на IBM PC) с помощью программ т.наз. "уплотнения дисков"(логического увеличения емкости) типа SUPERSTOR, STACKER, DISKSPACE(DOUBLESPACE) и аналогичных: при загрузке с HDD - все нормально(если не "грохнется" SUPERSTOR), при загрузке с флопа - видны только A: и B: (ну и L: - допустим,сидюк), и усе :)
Причем,дескриптор у каждой О.С. и каждой Ф.С. - свой(NTFSные диски нечитабельны в режиме,грубо говоря, "FAT" и HPFS).
Посмотреть можно.. по-моему,открыв исследуемый диск/раздел в программах типа Partition Magic(у меня - PM v.8,допустим), ACRONIS Director Suite (я использую v.10.1.###),и где-то во вкладке "convert filesystem type..."(где предлаается выбор,во что преобразовать файл.систему данного диска: от FAT12 до всяких там POSIX'ов , SUN_FS и "/EFI") - при пролистывании списка возможных вариантов,по-моему,как раз напротив каждого названия файл.системы(и/или поддерживающей ее ОС) все эти байты дескрипторов как раз и выводятся(правда,только,как я понимаю,для IBM PC). Когда пришлось конвертировать NTFSный диск в FAT32,я обратил на эту штуковину внимание, но,т.к. "портировать" 40Гигабайт на другую ЭВМ(типа SUN_SPARC или DEC ALPHA 21264, допустим ;-D ) задачи не стояло,то особо "в дебри" не лазил(бегло просмотрел список ФС и архитектур,их поддерживающих, и закрыл).
...
RE: "выдержка из этой таблицы":
по поводу "IBM": там значение "1440",по-моему,как раз в сводке для 3.5"-дисков; для 5.25" параметры немного отличаются(см. ниже,после подборки про 5.25"); я сам там тоже немного "заплутал" поначалу,да еще этот идиотский русский перевод от "Мисро-$oft"'а :)
-
? RADIX50 - 09.04.2016 13:56
...или это из раздела где "800К-диск в Линуксе"(с таблички на "народе.ру")? :)
..Да,тут есть чего обмозговать.. :)
-
? maxstudios@ - 09.04.2016 14:17
Насколько я знаю, тип дисковода 3.5" или 5.25" вообще не играет никакой роли. Шина FDD не даёт возможности определить, на сколько дюймов дисковод подключен. На РС выбор используемого дисковода нужно делать в БИОС-е, а на БК вообще всеядный КНГМД - лишь бы регистры работали, да быстродействия хватало.
Вот поэтому меня и удивило использование "своего" формата диска на БК, хотя можно было изначально ориентироваться на 9 секторов и 720 Кбайт.
Кстати, я в основном сидел на AN-DOS-е в 90-е года, и всегда думал что объём диска 5.25" на БК равен 720 Кбайт, а не 800 Кбайт.
Можно попробовать отформатировать дискету в AN-DOS-е, а затем на РС попробовать прочитать все её параметры. Ну или просто почитать полное описание AN-DOS, если есть такое.
:)
-
? MM - 09.04.2016 14:22
Давно боролся с 253 ПЗУ - году так в 1988, перегонял с ИБМ 720 файлы. В 1-м секторе ИБМ не пишет заголовок сектора, который обязателен на БК - а так общее расположение и к-во инфы на дисках почти совпадает, т.е. на ИБМ тоже 800 кбайт диски фактически.
И еще один момент - как быть с таблицей фрагментирования ФАТ на БК ?
-
? RADIX50 - 09.04.2016 15:24
To: maxstudios@ - 09.04.2016 14:17
Мож,я чего "упустил", но в инфе,приведенной на указанных линках
https://support.microsoft.com/ru-ru/kb/75131;
https://support.microsoft.com/en-us/kb/75131;
http://bk0010.narod.ru/docs/800kb_floppies.html, по крайней мере,для IBM, - формат "720К" для 5.25"-FDD в списке вообще не значится(и приведенное мною выше воспоминание о работе с дисками/дискетами оное обстоят-во в той или иной степени подтверждает), и не читается 5.25"-дисководом физически("позиционер трещит и лязгает", см.выше), даже если в BIOS выбрать,"обозвав" 5.25"-FDD как 3.5"(т.е.,все равно не хочет нормально видеть 720К). Т.е.,получается,что какие-то отличия все же есть(т.к.,напр.,стандартным способом,без "800" или "PU_1700", дискету 1.2МБ на 1.44 не отформатируешь). Логическая структура дискет, видимо,будет одинаковая(если скопировать посекторно в режиме DISKEDIT A: /M, и если общий объем хранимых данных на 1.44-диске не более 1.2М,- то скопируется и будет работать,если загрузочная),а физически эти форматы(и сами диски) - разные(в перв.очередь,по размерам :) ).
...К сожалению,проверить соответствие дискет на разных архитектурах ЭВМ тогда возм-ти особой не было(единственной "не-Интел" машиной с 1.2М-дисководом в конторе тогда был какой-то "Квант"(из ряда "ДВК",видимо,самая "крутая",топовая,модель?), но все дискеты были 5.25" низкой плотности(в центре диска на центровом отверстии под шпиндель имелось такое колечко,пластиковое же,приклеенное к диску заводским способом, - что указывало на дискеты с низкой плот-тью записи; дискеты "HD" на 1.2МБ такого колечка в центре НЕ ИМЕЛИ), а загрузочно-пусковая дискета с каким-то аналогом RT-11(на наклейке коряво было кем-то нацарапано "игры крутыые") была сформатирована вообще,чтоль,на 400К,даже меньше возможных 720).
...Еще,на каком-то другом радиофоруме, попадалась мне тема насчет каких-то различий в схемотехнике 3.5 и 5.25"-дисководов(товарищ "боролся", подключая "не тот" флоп к какой-то другой "ретро-машинке"), и там шла речь о том,что 3.5"-флоп на шину(34-контактную) не выдает(или выдает?) какой-то сигнал,выдаваемый(или не выдаваемый),соотв-но, 5.25"-флопом; и ему кто-то советовал какой-то вывод шины(на самом флопе),то ли 7-й,то ли 6-й,то ли вообще 5-й контакт, - "посадить" на "плюс" либо "на корпус". Т.е.,какие-то нюансы все-таки имеются.
А еще от одного("Синклериста",правда,не БКшника) недавно узнал,что,если купить "современный"(последних выпусков) 3.5"-флоп(не б/у,новый,с магазина!),тот же MITSUMI,допустим,то в большинстве случаев,у них на "гребенке"(IDC-34) из штатных 34 контактов отсутствует едва ли не половина, и,благодаря чему,сами эти дисководы ФИЗИЧЕСКИ не поддерживают форматы с объемом МЕНЕЕ стандартного 1.44М(нет датчика плотности "720/1.44",только "защита записи") и еще какие-то режимы(т.е.,являются так или иначе,аппаратно-"урезанными", хотя,что там еще можно "урезать",я слабо представляю,и так привод сам по себе,в общем-то,не особо сложный), и,естественно,часть сигналов,приходящих с контроллера, они просто не обрабатывают("не слышат",т.к. эти линии,где нет контактов на колодке,они просто висят "в воздухе").
Однажды сам нарвался на такой флоп,правда,в контейнере для подкл-я по USB. Отсоединение самого флоппика от USB-моста и подключение его напрямую к материнской плате IBM(под DOSом) ничего не изменило: "заклеенные" 720К-диски он все равно не видел(по причине отсутствия датчика плотности),и "не умел" перемещать головки "назад"(старые флопы 3.5" прекрасно это делают,особенно,при попытках прочесть/форматнуть сбойящую дискету, - это видно при работе со снятым верхним кожухом). При попытке форматировать на 720К(ключ /F:720) выдавал ошибку "MEDIA ERROR". Как-то удалось сформатировать на 720К в режиме "высокой плотности", "поиграв" с ключами FORMAT'а(вроде бы,набрав белиберду вроде /TR:40 /N:18), - видимо,в режиме с "пропуском дорожек"("через одну"). Но сам режим при этом - все равно оставался "высокой плотности"(а дискета вышла "со сбоями").
Так что,думаю,если брать "совсем" уж "современные" дисководы высокой плотности, - то,наверно, все же есть какие-то "нюансы" аппаратного характера,нам покуда не известные..
#
RE:"отформатировать дискету в AN-DOS-е, а затем на РС попробовать прочитать...":
В доке к ANDOS v.3.30 сам Надежин говорит,что на PC с активным резидентом "PU_1700" в памяти - совершенно нормально читаются все БКшные дискеты. И он же(Надежин) предлагал,что,при наличии сбоев при форматировании дискет на БК(под ANDOSом),возможно,из-за неизвестных ему тогда причин,обозначенных чуть выше ув.тов. ММ("нехватка" тактовой частоты), - рекомендуется сформатировать дискету на 720К на IBM(незагрузочную), а потом,поставив ее на БК,произвести "осистемливание" - при этом начальный загрузчик и нулевой сектор будут перезаписаны БКшной служебной информацией,и будут нормально работать на БКшке.
..
Насколько помню,вот примерно,так :)
-
? maxstudios@ - 09.04.2016 16:08
Ну мне в настоящее время уже не интересны 5.25" дисководы, так как рабочие 3.5" найти гораздо проще. :)
По ссылке http://bk0010.narod.ru/docs/800kb_floppies.html
в самом низу вообще-то как раз указаны все доступные форматы для 5.25", а не для 3.5".
По ссылке https://support.microsoft.com/ru-ru/kb/75131
при сравнении форматов по обеим ссылкам видно, что 5.25" и 3.5" не отличаются.
Фактически может и есть какие-то отличия, но ведь очевидно, что 9 и 10 секторов - разные форматы.
и 9 секторов как раз используются, а 10 - нет.
Благодарю за ценную информацию про "урезанные" современные дисководы 3.5", надо быть осторожным.
:)
-
? maxstudios@ - 09.04.2016 16:42
Добавлю к предыдущему моему сообщению:
По обоим ссылкам можно заметить, что 360 Кбайт на 5.25" диске на 2 стороны по 9 секторов - это просто 40 дорожек вместо 80. Увеличение количества дорожек в два раза дало соответствующее увеличение объёма в два раза - с 360 до 720. А объём 1.2 Мбайта получился путём увеличения количества секторов с 9 до 15. Такое количество секторов вряд ли доступно на БК.
У меня был 5.25" дисковод TEAC от РС, на 40 дорожек, работал ОЧЕНЬ ХОРОШО!
При осмотре головки этого дисковода я тогда ещё заметил, что ширина записывающей части в два раза больше, чем на аналогичном 80 дорожечном дисководе. То есть, ошибок на 40 дорожечном было гораздо меньше за счёт удвоенной ширины полоски записи.
:)
-
? RADIX50 - 09.04.2016 17:52
RE: ? maxstudios@ - 09.04.2016 16:42
...ширина дорожек записи...":
Да,примерно то же самое справедливо и для катушечных магнитофонов(в сравнении с кассетными), и для студийных(в сравнении с обычными катушечными): чем шире дорожки записи и выше скорость ленты, - тем выше и качество записи(то же самое обратно-справедливо и к магнитно-цифровым дисковым "магнитофонам",коими дисководы FDD и HDD,по сути,и являются). Совершенно справедливое наблюдение,поддерживаю! :)
#
RE:"maxstudios@ - 09.04.2016 16:08
мне в настоящее время уже не интересны 5.25" дисководы...":
Строго говоря,тема-то озаглавлена как "...БК и современные 1.2МБ-дисководы", потому я из этого и исхожу,а во-вторых,считаю,что нельзя обделять поддержкой этот тип накопителей/носителей,т.к. вдруг у кого-то сохранилась куча великая дискет 5.25", а в будущем появится контроллер типа "SMK-HD-1.2/1.44M"(чем черт не шутит?)..
RE:"при сравнении форматов по обеим ссылкам..":
На микрософтовском форуме(https://support.microsoft.com/ru-ru/kb/75131) значение "1440"(секторов) на странице - всего одно,и находится оно в главе "720,1.44,2.88"(а это,как ни верти,_стандартные_(речь ведь идет о них) форматы для 3.5"-дисковода). Далее,идет перечисление возможных форматов 5.25"-FDD: 180,320,360,1.2M(заметьте, 720К в _этом_ списке НЕТУ!),а после него - идет "добавка",как получить формат 250 и 500К,опять же,на дисководе 1.2М(а не 1.44,т.к. у 1.44М - столько форматов просто нет: стандартных у него всего 2шт: 720 и 1.44).. Плохо,наш форум не позволяет постить картинки,как в том же QIP(русский "пейджер" ICQ,а не корпус 1801ВП-128 :) ), - я бы там подчеркнул и отметил,на что обратить внимание :) :)
На форуме на "народе.ру" - там,да,действит-но в самом низу перечислены форматы.
Но сразу могу сказать,что на 1.2М- дисководе 5.25"-дискету на 1.6 не отформатируешь: физически максимальный объем(при форматировании FFORMAT'ом на IBM - я лично экспериментировал,желая "большую дискету задешево" :-) ) составляет 1.52МБ(параметры что-то вроде 85дорожек,17секторов),и то она плохо держит инфо(начинает "сыпаться") и перестает видеться сразу после загрузки,если системная.
Формат 1.6МБ и выше - это прерогатива чисто 3.5"-дискет(не исключено,что составитель мог ошибочно указать "5.25" или,начав составление списка форматов с этого размера(5.25"),далее увлекся и вписал туда все остальные имеющиеся параметры форматирования).
Возможно,UNIX-подобные системы содержат набор параметров(и драйверов/(под)программ/процедур,их понимающих) для форматирования дискет подобным образом(примерно как в FFORMAT'е на IBM или связки "/TR:## /N:##" у DOS-Format),но,так или иначе,производится форматирование "с оглядкой" на тип/вид дисковода(т.е.,все равно каким-то образом система получает его физические параметры). Ведь нельзя "заклеенную" дискету(переведенную в режим "низкая плотность" 720К) сформатировать на 1.44М : какой бы "всеядный" ни был контроллер, физику не обманешь: на 720К-дискете(с ее параметрами магнитного слоя) запись с токами подмагничивания,как для режима "1.44", - окажется невозможной либо некачественной(будет перегрузка либо магнитного слоя(неспособность принять сигнал такого большого уровня/частоты),либо усилителя записи-чтения дисковода), - потому дисковод выдает сообщение типа "Media Error - disk UNUSABLE".
Аналогично, дисковод 5.25"(1.2М) форматы емкостью выше 1.5МБ не обеспечивает чисто физически - из-за плотности записи.
Скорее всего, на http://bk0010.narod.ru/docs/800kb_floppies.html приведены ВСЕ форматы(параметры настройки драйверов),так или иначе,поддерживаемые системой(и это очень хорошо,что они там поддерживаются/имеются,хотя бы в виде "стандартн.библиотек"), а при запуске процедуры форматирования - введенный параметр ком.строки оценивается на предмет его выполнимости(сообразно физич.параметрам дисковода как такового) и либо выполняется,либо пользователю выдается "отказ".
...Приведу выдержку из документации по моей любимой "FFORMAT"(для IBM PC):"
===========================================================================
(...)
.PIF файл запускает FFORMAT с опцией /ZO
_
Подобно другим существующим на территории России и ближнего
зарубежья программам для форматирования гибких дисков, эта
программа действительно форматирует гибкие диски на любой формат
и позволяет просматривать каталоги дисков перед форматированием
без драйверов 800 и PU_1700. Главное, что выгодно отличает
FFORMAT от других программ - это свой собственный оригинальный
Boot сектор. Если вы случайно оставите в дисководе несистемный
диск, отформатированный FFORMAT, при загрузке, то вместо
привычного "Non-system disk or disk error ..." вы увидите вполне
нормальный DeskTop с окном, сообщающим, что этот диск несистемный
(человек, знающий что такое BOOT-сектор и впервые видящий этот
BOOT, как правило "впадает в осадок"). Вам останется только
вынуть диск и "нажать" на кнопочку "Ok" в окне сообщений. Вся
процедура рисования DeskTop'а и прочих прибамбасов умещается в
512 байт вместе с расширенной таблицей диска.
_
Возможные варианты форматов в зависимости от типа дисковода:
360 Кб дисковод
+ 180 Kb 40 дорожек 9 секторов 1 сторона
200 Kb 40 дорожек 10 секторов 1 сторона
+ 320 Kb 40 дорожек 8 секторов
+ 360 Kb 40 дорожек 9 секторов
400 Kb 40 дорожек 10 секторов
420 Kb 42 дорожки 10 секторов
430 Kb 43 дорожки 10 секторов (может не поддержи-
ваться дисководом)
720 Кб дисковод (3'5" и 5'25")
+ 720 Kb 80 дорожек 9 секторов
+ 747 Kb 83 дорожки 9 секторов (Девяткин просил)
800 Kb 80 дорожек 10 секторов
820 Kb 82 дорожки 10 секторов
830 Kb 83 дорожки 10 секторов (может не поддержи-
ваться дисководом)
1.2 Мб дисковод
+ 180 Kb 40 дорожек 9 секторов 1 сторона
200 Kb 40 дорожек 10 секторов 1 сторона
+ 320 Kb 40 дорожек 8 секторов
+ 360 Kb 40 дорожек 9 секторов
400 Kb 40 дорожек 10 секторов
420 Kb 42 дорожки 10 секторов
430 Kb 43 дорожки 10 секторов (может не поддержи-
ваться дисководом)
+ 720 Kb 80 дорожек 9 секторов
+ 747 Kb 83 дорожки 9 секторов (Девяткин просил)
800 Kb 80 дорожек 10 секторов
820 Kb 82 дорожки 10 секторов
830 Kb 83 дорожки 10 секторов (может не поддержи-
ваться дисководом)
+ 1.2 Mb 80 дорожек 15 секторов
1.36 Mb 80 дорожек 17 секторов
1.44 Mb 80 дорожек 18 секторов (*)
1.47 Mb 82 дорожки 18 секторов (*)
1.49 Mb 83 дорожки 18 секторов (*)
(может не поддержи-
ваться дисководом)
1.44 Мб дисковод
+ 720 Kb 80 дорожек 9 секторов
800 Kb 80 дорожек 10 секторов
820 Kb 82 дорожки 10 секторов
830 Kb 83 дорожки 10 секторов (может не поддержи-
ваться дисководом)
+ 1.44 Mb 80 дорожек 18 секторов
+ 1.52 Mb 80 дорожек 19 секторов
1.6 Mb 80 дорожек 20 секторов
1.68 Mb 80 дорожек 21 сектор (*)
1.72 Mb 82 дорожки 21 сектор (*)
1.74 Mb 83 дорожки 21 сектор (*)
(может не поддержи-
ваться дисководом)
_
(*) - 800.COM не форматирует такие форматы
При форматировании используется Interlive=2
+ - форматы, для которых FFORMAT позволяет восстановить 0
дорожку и остальные дорожки тоже
_
Форматы, имеющие 83 дорожки, могут не поддерживаться вашим
дисководом (особенно если он старый). Однако большинство
современных дисководов позволяют форматировать до 84-85 дорожек.
Форматирование на 83 дорожки 9 секторов введено по просьбе
Девяткина М. Как выяснилось, компьютер "Поиск", (...), не может
правильно прочитать 10 секторов на дорожку, если дискета
отформатирована на нормальном дисководе, и нормальный дисковод не
может прочитать 10 секторов, если дискета отформатирована на
"Поиске", (...). (Поиск больше похож на PC Jr нежели на XT. У
него для обращения к дискам DMA не используется (похоже, что
контроллера DMA там вообще нет), и процессор выполняет все
операции путем ввода/вывода в порты. Совместимость не соблюдается
(естественно!), и о назначении портов, по-моему, знают только
разработчики BIOS "Поиска".) Восстановление дискет на "Поиске"
может не работать. Претензии, я надеюсь, ясно к кому.
============================================--------------(...)".
_
Вот,примерно так :)
-
? RADIX50 - 09.04.2016 18:07
To: maxstudios
SUBJ: плотность записи/720К на IBM 5.25"-FDD
#
...Расскажу даже больше. :-D
Однажды,в 1997г., случайно найдя на прошедших через мои руки дисках-сборниках программ эмулятор БК0010/0011(в комплекте с загрузочным образом ANDOS 3.30) и удивившись объему полезной инфы на том "диске"(ANDOS),я приволок с конторы FDD 5.25" на 720К и подключил его к своей "AT486DX-120", - желая сделать системную дискету для БК(вроде,в эмуляторе была такая функция,чтоб работать с ANDOS-дисками,пользуясь установленным на IBM дисководом). ...Мгм,не тут-то было!..
Во-первых,такого типа дисковода в BIOS(хоть и "extended-версия" для того времени,с некоторыми "наворотами") не нашлось: только или 360К,или 1.2М(5.25"), или 720К,но 3.5"(в этом режиме он не заработал вовсе). Во-вторых,даже в назначенном ему режиме "1.2МБ" - напрочь отказывался и форматировать на 720К(даже как для IBM), и видеть уже готовые диски на 720К - как IBMные,так и БКшные..
А на штатной "ЕС-1845",откуда он был взят, - тот же дисковод работал "как часики" - и на 360,и на 720К. :)
Вот такая вот штука получилась с плотностью записи, будь она неладна ;-) ;-)
Так что,"крутость" компьютера - на мой взгляд,еще не показатель :)
Вот :)
-
? RADIX50 - 09.04.2016 21:03
To: MM - 09.04.2016 14:22
SUBJ: как быть с таблицей фрагментирования ФАТ на БК ?
#
Не знаю,насколько поможет в данном случае моя "выкладка",но все же приведу свои соображения.
Насколько я имею представление о разных подходах,так сказать,к проектированию, - в UNIX-подобных системах и M$DOS(в свое время хреново "содранной" с консоли,если ничо не путаю,той же RT-11,только переработанная до состояния "с ног на голову",как всегда и делала "M$"),каждый подход имеет свои преимущества и недостатки.
Если в RT-11 файлы на диск писались "линейно"(почти как на ленту,можно сказать),то фрагментация там практически отсутствовала или была сведена к минимуму: т.к. при сохранении файла сначала определялся размер сохраняемых данных,после чего на диске ему выделялся самый большой сегмент свободного места; при сохранении/копировании других файлов - выделялась половина от самого большого оставшегося фрагмента свободного места; потом - "половина-от-половины-половины...", и т.д., пока линейно лежащие участки своб.места(длиной два блока и более,хотя,насчет этого, могу быть неточен..) не заканчивались вовсе(т.е.,команда DIR показывает наличие свободных блоков,вроде,в достаточном объеме,но сохранить/скопировать на диск файл не удается).. Либо,одиночные блоки свободн.простр-ва возникали при изменении объема ранее сохраненных файлов в меньшую сторону(при правке текста реферата/курсовой или упорядочении файла СУБД). Для устранения этого была команда "SQUEEZE"(ее кто-то из программистов у нас звал "команда по размножению бэд-блоков" :-D ),которая "выкладывала" файлы "паровозиком"(т.е.,линейно и без промежутков).
В MS-DOS(да и вообще,по-моему,везде,где применяется FAT),с переходом на "секторный"(а не "спиралевидно"-дорожечный,как в RT-##-системах) формат записи, - там возм-ть фрагментации дисков,можно сказать,заложена в саму основу файловой системы. Причем,FAT32 фрагментирована намного больше,чем FAT12/FAT16(напр.,задача поиска корневого каталога на FAT32-диске,особенно,при восстановлении данных в случае сбоя/порчи/"глюка" файл.системы или драйвера/ОС, - мягко скажем, "очень даже творческая"), - даже в том случае,если обращаться к диску FAT32 только из-под DOSа,когда нет многопотоковой записи,когда каждая программа начинает "складывать" там,где ей удобно,а потом начинается "метание" головок туда-сюда в поисках очередного свободного кластера..
...Ну,а т.к. ANDOS(которая делалась с определенной оглядкой на MS-DOS на IBM PC) тоже базируется на "удобной" и "стандартной" FAT(-16),следовательно,так или иначе "наследует" некоторые свойства своего "образца-прототипа"(в част-ти,ту же возм-ть фрагментации файлов при записи). Если не путаю,в комплекте ANDOS 3.30 Надежин добавил программу типа "DEFRAG",для частичного выполнения некоторой дефрагментации, но особо на ней в документации внимание не "заострялось"(видимо,фрагментация на дисках БК не такая "страшная",как на IBM,либо все "упирается" в малый объем штатного ОЗУ,накладывающий ограничения на сложность алгоритма/размер программы в памяти).
Возможно,в DOS 6.22 использование/заполнение свободного места как-то отслеживалось встроенным алгоритмом(т.к. уже говорил выше,что FAT16-диски,записанные/заполненные под DOS/Win3.##/WinNT 3.5X, заметно менее фрагментированы,чем если под Win9X/WinXP).
Если стоит задача именно в снижении уровня фрагментации файл.системы на БК,то возможный выход - в добавлении(как отдельный драйвер или встраивание в ядро I/O-подсистемы ОС) некоего аналогичного алгоритма,при открытии файла на запись/сохранение резервирующего для него начальный кластер как самый первый кластер самого длинного свободного участка на FAT-диске БК.
Полагаю,что полностью избавиться от фрагментации файлов на FAT-дисках будет невозможно(разве что если файлы будут настолько маленькие,чтобы полностью влезать в один кластер :) ),повторюсь,в силу вложенной в нее идеологии от M$ и Б.Гейтса.
...В других ОС,таких,как OS/2(с используемой в ней файл.сист. марки "HPFS"), - дефрагментация и частично лечение(обработка "потерянных кластеров","кросс-линков" и глюков директорий, - ну,как минимум,на уровне SCANDISK или NDD,а то и побольше) файловой системы производится при каждой (пере-)загрузке ОС,а при работе - частично поддерживается в "фоновом"("прозрачном",незаметном для пользователя) режиме. Особо вдаваться в "дебри" не буду,но там используется система сквозного протоколирования(что и какими программами делалось и "не доделалось") и т.наз. "spare-блоков"(в случае надобности их оперативного "ремапа" для предотвращ-я потери данных при сбоях или отключениях питания). Вышедшая позже файл.сист. NTFS,хоть и имеет созвучное название, но такого набора ф-ций,как в HPFS, не предоставляет(она "заморочена" в "свою" сторону,и задумывалась "MS" вообще как полностью закрытая файл.система,не предназначенная для "обнародования",так сказать..).
Но реализация на БК алгоритмов,сходных с оными в HPFS, - скорее всего,потребует создания новой полноценной ОС либо надстройки над имеющимися(RT-11, RAFOS/FODOS, ANDOS....) и увеличения функциональных возм-тей самой ЭВМ БК(большой объем ОЗУ,подключение более емких и быстрых носителей; возможно,разработка контроллеров "специально под это дело")..
Sorry за возможный offtop(в некотор. местах).. Если что,пусть Коллеги меня дополнят или поправят.. :)
-
? maxstudios@ - 09.04.2016 22:42
>>>? RADIX50@ - 09.04.2016 18:07
Если всё описано правильно, я заметил пропущенный вариант: в режиме 3.5" на 720 Кбайт форматирование не проверялось?
В режиме 1.2 Мбайта форматировать на 720 Кбайт естественно не получилось - разница в количестве секторов сработала.
Вообще, в БИОС-е нужно устанавливать 3.5" (1.44Мбайт), чтобы читались диски 3.5" на 720 Кбайт с заклеенным окошком плотности, а также могли работать 5.25" дисководы на 720 Кбайт.
Дисководы 5.25" рассчитанные на 1.2 Мбайта, не будут работать на объём 720 Кбайт - там нужно как-то отрегулировать скорость вращения шпинделя, может есть перемычки какие, но у меня так и не получилось 5.25" 1.2 Мбайта дисковод запустить и пользоваться на БК.
Мало того, диски 5.25" повышенной плотности объёмом 1.2 Мбайта не форматировались дисководом на 720 Кбайт, видимо материал напыления другой.
Поэтому я давно уже настроен на 3.5" дисководы.
Дисководы 5.25" я так и не смог найти в продаже, ни на 720 Кбайт, ни на 1.2 Мбайт.
Хотя один-два раза вроде нападал на такие объявления, на там цены были завышены страшно.
А 3.5" дисководы у меня есть - один в РС, другой просто так лежит и ждёт БК.
Вообще, я бы хотел для БК пишущий CD-привод подключить, чтобы полноценно записывать-читать болванки. Новые программы, демки, игрушки можно было бы распространять на CD-дисках, оформляя их очень даже прилично. К тому же, есть уменьшенный до 3" стандарт болванок для CD и DVD приводов. Это вообще находка и сокровище для будущего БК!
:)
-
? Дмитрий - 10.04.2016 01:32
>> у них на "гребенке"(IDC-34) из штатных 34 контактов отсутствует едва ли не половина, и,благодаря чему,сами эти дисководы ФИЗИЧЕСКИ не поддерживают форматы с объемом МЕНЕЕ стандартного
>> 1.44М(нет датчика плотности "720/1.44",только "защита записи")
У меня "полный" IDC флопа, один хрен не имеет датчика плотности. Надо искать старые флопы - последних лет выпуска (перед сворачиванием производства) 100% не имеют датчиков плотности.
¤
>> Вообще, я бы хотел для БК пишущий CD-привод подключить, чтобы полноценно записывать-читать болванки.
Нет никаких преград. Читать БК с сидюка может хоть сейчас (это обычное IDE-устройство), главное написать драйвер разбора структуры данных. А для записи нужен отдельный драйвер. Либо сразу писать прозрачный драйвер пакетной записи. Тогда чтение/запись такого сидюка ничем не будет отличаться от чтения/записи винта.
-
? RADIX50 - 10.04.2016 10:57
RE:"maxstudios@ - 09.04.2016 22:42
...пропущенный вариант..":
Да,все верно,этот режим проверить не удалось,т.к. тот 5.25"-FDD вообще отказался "изображать" флоп на 3.5" :-) Ну ни в какую! :)
При включении IBM,к коей он был временно подцеплен, поначалу вроде бы все было нормально(проводится пробная проверка включения мотора,зажигается светодиод "обращение к FDD" на морде,головки двигаются от TRK00 до TRK79), но,после завершения POST и перехода ЭВМ к загрузке - все "виснет" намертво: шпиндель крутится, светодиод горит,а головки "забыли" вернуться на TRK00,чтоб попытаться "поймать" IPL на нулевой дорожке :)
При выставлении любого режима "5.25", тот флоп тут же "вспоминал",что он дисковод, и переставал "виснуть".
В режиме "360К" - форматировал и читал все,в режиме "1.2М" - не очень(т.к. он на 720К).
Кстати,замечу,что с FDD 5.25" высокой плотности такой "финт" прокатывал(у меня даже было одно время "перепутано" после установки второго FDD,и я не знал,какой из них правильно выставить "A" и "B"), правда, NDD (DOSовский) иногда ругался на формат(не на ошибки/данные!) дискет(ы),а в остальном - все работало,пока не разобрался с "A" и "B"(когда понадобилась системная дискета для аварийной загрузки ЭВМ).
...Потому,тот 5.25" 720КБ-флоп был возвращен на штатное место("на ЕС-1845"), - где,повторюсь,он начинал работать "как часы": все форматы в пределах 180..360..400..720..800КБ - прекрасно и пишет,и читает! :)
...
RE:"пишущий CD-привод на БК";
RE:"Дмитрий 10.04.2016 01:32
Нет никаких преград...":
#
Сей вопрос уже тоже обсуждался(правда,не здесь,а в "личке"). Мне тоже приходила такая идея.
Но,как мне объяснили спецы,разбирающиеся в программировании I/O-процедур на ATA-девайсах, тут есть некоторые подводные камни.
Во-первых,нет никакого стандарта на хранение и обмен данными между БКшками(какую файл.систему выбрать: ISO,UDF,EFI или что-то из "юниксового" и т.п.), - проще тогда уж по локалке через ИРПС(как на КУВТах) или через параллельн. порт (кстати,в ANDOSе есть такая утилита для копирования данных меж 2-мя БК чрез порт "УП").
Во-вторых: ПРОЧИТАТЬ CD-R на БКшке еще можно(даже на "БК0010"),благо каталог там занимает килобайты(влезет даже в базовое ОЗУ БК0010,если не грузить Бейсики-Фортраны); теоретически,можно было бы даже слушать CD-AUDIO(если суметь написать драйвер,аналогичный виндовым MCICDA.DRV).
А вот с DVD,даже на чтение, - уже сложнее(там и объемы,и скорость передачи данных - на порядки выше).
Но опять же,возникает вопрос: ЧТО именно будем читать с CD-R(кроме музыки)? Ну разве что,какие-нибудь там сборники литературы(книг) в формате .TXT(и то сделанные для IBM PC),ну,мож,небольшие картинки в формате .PCX/.BMP(что влезут в ОЗУ)... И усё... :)
#
С записью CD-R(а тем более,CD-RW) - дела обстоят,мягко говоря,похуже.
Как мне объяснили в ответ на мой вопрос "а можно ли.. и почему бы не..?", подключить CD-привод на чтение в принципе - можно(для этого паяется третья вилка IDC40 в параллель к SLAVE-разъему контроллера типа SMK или отдельного HDDшного(не знаю,есть ли такие на БК?),привод ставится как бы "вторым SLAVE'ом" в режиме "3 устр-ва на IDE" и теоретически,можно управлять CD-приводом,подавая ему команды на интерфейс через контроллер,- ну так это все еще надо знать/найти/запрограммировать). Но для записи CD-R нужно,во-первых,выполнить весьма "критичные" требования CDR-привода по скорости подачи на него данных(а даже древние CDR-драйвы - минимальным режимом считают запись на скорости в 4X,не менее!- ну,кроме,разве что WEARNES-CR-###,у кого скорость = "3X"); во-вторых, как мне объяснил знающий чел., сеанс записи CDR надо выполнить "за один раз",т.е.,сразу, - а для этого тогда уж,чтоль,сразу 1ГБ ОЗУ на БКшку ставить надо(чтоб была наивысшая скорость доступа к требуемым на запись данным,т.к. ОЗУ - быстрейшая часть любой ЭВМ).
В-третьих, как недавно объяснил нам ув.тов.MM, быстродействия БК/скорости обмена с периферией при существующем раскладе, на некоторых экземплярах БК и контроллеров(FDD или SMK), - не хватает даже для обеспечения работы с FDD 1.2/1.44M(а это примерно 70..100КБ/сек всего лишь; у простого FDD - 50КБ/с) и для устойчивого обмена на 720К, - то что уж там говорить про обмен с CD-R-приводом,да еще в режиме "BUFFER UNDERRUN"!
В-четвертых, запись CD-R(W)/DVD-R(W) осуществляется "не просто так",как на FDD/HDD("взял да записал"), а с помощью целого списка т.наз. MMC-команд("эмэмси",мультимедийные команды записи), коих в наборе там - "целый Кодекс"(много), и у каждого привода есть еще "свои",кроме "общих". И к ним вдобавок - еще целый протокол обмена(или их набор). Насколько понимаю, это для избежания "произвольного" включения лазера на "прожиг"(запись) и порчи уже имеющегося(записанного) носителя либо оптики самого привода(если диск - "готовый",т.е.,заводской штамповки,незаписываемый); да и вообще, все вопросы к разработчикам CD-приводов :)
#
RE:"это обычное IDE-устройство":
Не совсем обычное. У HDD - да,алгоритм обмена по стандарту "ATA", а у IDE CD/DVD - не ATA, а "ATAPI"(пакетный-интерфейс-сделанный-для-ATA). В 1984г,когда "Сони" с "Филипсом" делали первый в мире CD-привод, у них там что-то не получалось технически,либо были сложности из-за каких-то там "авторских прав", и они выдумали вот такую хитрую систему, сделав немного "через анус" :)
Т.е.,"внутри" IDEшный CD/DVD - он не является чисто-ATA(IDE)-устройством. Физический формат записи у него - не секторный,как на магнитных дисках,а спиральный(как на грампластинках,коей все CD/DVD/BLURAY и являются,только записано там не резцом-иглой,а лазером), и с "блочной" структурой записи(примерно как в RT-11 в режиме "MX1"/"MX2" или "MY1",если не путаю). И напрямую,по крайней мере,из-под DOS на IBM,он не видится(а видится как сетевой диск объемом 136 МБайт),а реальные параметры можно получить,только обратившись специальной программой(типа SYSINFO или MHDD,допустим),различающей HEX-наименования устр-в на системной(и IDE тоже) шине ЭВМ.
А IDE-разъем - используется просто для подключения CD/DVD-дисковода к ЭВМ,и не более того(а обмен инфой реализован по принципу "передача не-IDEшных данных по IDE"),чтобы можно было работать с этим приводом.
...Единственная мне известная ОС(на IBM), где поддержка CD/DVD "на чтение" встроена в само ядро ОС, - это "ФизТехСофт-DOS"(PTS-DOS) образца 1994г. Ну,еще,мож,на UNIX-подобных(но их мы сейчас не рассматриваем).
Т.е.,мож,я ошибаюсь,но изначально,"внутри" ATAPI CD больше все же "похож" на SCSI(по внутр. представл-ю данных). Мож,для других систем/машин он бы и подошел "напрямую",а вот на IBM PC - ну,пришлось вот таким образом его "притягивать за уши" к IDE(ATA)-шине.. :)
...
Вот,вроде,примерно так :)
Если что,не бейте сильно :) ...P.S.: да,драйвер для ATAPI(IDE) CDD - скорее всего,действительно нужен(или он понадобится) - либо в виде "надстройки/плагина" к существующим ОС(либо как системная задача для той же RT-11/FODOS/RAFOS/microUNIX), либо как в виде "ANDOS-CD-ATAPI"-версии(аналогично концепции "системный монитор с поддержкой флопа", как в "прошивке" N326(327) и аналогичных,плюс обращающийся к этим регистрам "DOS").
-
? maxstudios@ - 10.04.2016 15:09
>>>? RADIX50 - 10.04.2016 10:57
Очень много и интересно, благодарю.
Но я уже написал, что идеальным вариантом был бы не 5" вариант CD-диска, а уменьшенный стандарт - там что-то в районе 200 Мбайт объём. К тому же, в продаже я до сих пор вижу и CD-R, и CD-RW обоих размеров. То есть, их выпускают, они и не дорогие. Другой вопрос - найти в продаже CD-приводы.
Надо конечно изучить этот вопрос, найти разницу между DVD и CD приводами. Может быть, современные DVD-приводы под IDE и SATA (с переходником на IDE) также могут быть использованы. Я пользовался всегда для записи дисков только NERO разных версий, и помню что ограничение скорости записи очень даже прилично работает - записывал DVD я всегда не выше 6х скорости, а то и 4х. Такие диски писались долго, но читались всегда идеально, по сравнению с записанными на возможном указанном пределе.
Есть даже ещё такой вариант - выбрать к примеру, формат ISO, записывать такие диски на РС с помощью той же NERO, а на БК только нужен будет драйвер для чтения дисков.
;)
-
? Дмитрий - 10.04.2016 16:09
>> идеальным вариантом был бы не 5" вариант CD-диска, а уменьшенный стандарт - там что-то в районе 200 Мбайт объём.
Без разницы. Диски уменьшенного размера и объема есть, а приводов нет. Так что все равно будет 5,25 привод висеть.
¤
И да, согласен, писать на БК не нужно. Главное, чтобы читал. Писать архивы можно и на РС.
-
? TheGWBV@ - 10.04.2016 16:37
ЕМНИП, ув.тов. Terra в своё время написал БК-драйвер для CD-привода ;-)
-
? RADIX50 - 10.04.2016 19:33
RE:"уменьшенные CD/DVD-R...": специальных CD/DVD-приводов под диски "уменьшенного" диаметра(CDR 200МБ) мне не попадалось.. По-моему,существуют только стандартные приводы размера 5.25",который придется и использовать, - хотя,да,соглашусь, "мини-привод" CD/DVD на БКшке смотрелся бы весьма стильно - примерно как аккуратный картридж FD-контроллера и рядом стоящий маленький 3.5"(720K) FDD на той же "YAMAHA-MSX"(компоновка этой микро-ЭВМ,стоявшей у нас тогда в дисплейном учебн.классе, мне очень нравилась, и в глубине души хотелось бы иметь примерно такой же вариант дизайна и на уже доступной мне тогда "БК-шке").. А особенно хорошо у "Ямахи" была проработана клавиатура: ничего нигде не залипает,ход кнопок - идеальный(при всем при том,что сколько людей на них работало в течение недели - по 40чел. по 6 уроков ежедневно!), и никаких "дребезгов" и "залипаний"! :) :)
#
RE:"болванки уменьшенный стандарт":
Ну,тут тоже не все однозначно. в продаже они вроде бы,бывают, но это сильно зависит от региона и магазинов(поставщиков). Дело все в том,что спрос на них не очень большой(и вообще,изначально,этот формат планировался как "сувенирный", а до их появления,году так примерно в 1996-м, помню,у нас на факультете "продвинутые" чуваки делали подобные мини-диски из обычных CD-R,просто обрезая их до меньшего размера,со всеми,правда,"вытекающими", - отслойка фольги,низкая надежность хранения и т.д.).
Пока вроде,да,в продаже попадаются. Но спрос на такие диски - не очень большой,и их иногда подолгу не бывает в продаже,да и стоимость у них ощутимо выше "обычных",стандартного размера(5.2").
Тут ситуация примерно такая же,как с батарейками размера R10(советская "А332" 1.5Вольт): до последнего времени в продаже они вроде были, их редко,но все же народ покупал, а вот с февраля текущего года - они(бат. "R10") куда-то все "пропали",а у народа на руках осталось довольно много устройств/приборов,использующих именно этот формат батарей(прицелы ПНВ,рыбацкие фонари(пит. 3*А332), радиоприемники, часы, и что самое главное, - тестеры/АВОметры,коих у народа полно использовалось), - в настоящий момент оставшиеся,по сути,без возможности замены элементов питания(у самого несколько таких АВОметров,как раз под такую батарейку!).. :( :(
#
RE:"запись CD/DVD на низкой скорости": да,чем НИЖЕ скорость записи,тем выше надежность хранения(и чтения) данных.
Ну,мне больше нравится программа "WinOnCD",хотя,пользуюсь и NERO,и др. программами,которые "мелкие,но шустрые"(шустрые - в том смысле,что не такие громоздкие как тот же NERO с его пухлейшими "редакторами обложек", и меньше "тормозят" в диалогах с пользователем), и могут все то же,что и NERO,но умещаются на любой архивной флэшке и работают без установки на конкретную ЭВМ(со своей флэшки запустил,записал,вышел,и усё), хотя,опять же,это вопрос вкуса(но мне,допустим,нравится).. :)
#
#
RE: %SUBJ%: "БК-001# и CD-ROM":
...Нашлись вот такие статьи по этому поводу:
http://r-games.net/31746-opisanie-po-podklyucheniyu-cd-rom-k-bk.html
Описание по подключению CD-ROM к БК;
и немного подредактированная,но в целом такая же копия на странице:
http://www.bk001x.ru/forum/122-153-1
(по-моему,как раз от упомянутого ув.TheGWBV персонажа с ником "Terra")
«Подключение CD-ROM к БК» [16.01.1998] - Всё об «Электроника БК0010(-01), БК0011(М)»,
..В обоих случаях SUBJ пока находится в стадии "проекта"(примерно как наш недавно обсуждаемый "MP3-декодер/плеер на БК"), нет даже "стэндового" варианта пробной "сцепки" этих устройств.
...Еще на просторах Сети где-то попадались мне разрозненные источники информации, что на подключение CD к "БК-001#" вроде "замахнулись",если не путаю, клуб "ELESIM" и "Клуб "БК"-САМАРА",- по крайней мере, в период примерно с 1997г. по 2013-й страницы были доступны(после 2007г. - уже как "архивные",но все же),и там выделенным шрифтом говорилось о том,что "возобновлены активные работы по созданию схемотехники подключения...", - но к сожалению,ни одна из этих "контор" тоже так и не смогла довершить начатое..
На те страницы я периодически заходил,посматривал; а после 2014-го (и в настоящее время) - увы,эти ресурсы более недоступны,даже в поиске(скорее всего,"сдохли" сервера), что для меня очень печально..
...В общем-то,если бы не "лихие 90-е", - то,полагаю,то CD-R на "БК-001#" вполне мог бы успешно работать...
Почему у нас всегда в стране все вот так?.. Те же и "Ямаха", и "АМИГА", и тот же "ZX" - живут и процветают,а на "БК"-шке всегда проблемы?..
#
RE:"драйвер CD на БК": нуууу,допустим,можно сделать по аналогии с DOS "Физ-Тех-SOFT",включив поддержку CD в ядро.. Правда,опять же,помните времена "до ATAPI-CD", - когда существовало минимум 3 разных варианта интерфейсов CD-приводов для IBM,типа "Philips", "SONY" и "Panasonic",не имевших "стандартного"(IDE ATAPI) интерфейса,а включавшихся ТОЛЬКО через спец. порт на ЗВУКОВОЙ ПЛАТЕ(с коими и распространялись в те годы под названием "Multimedia Kit"), а потом,после 1997г.,когда пошли CD на "IDE-ATAPI",народ начал массово избавляться от ставших "немодными" CD с "проприетарными" интерфейсами?.. Помните? Я помню :) :)
Так что опять же,надо обмозговать подход(выбор) типа и "стиля" написания драйвера (пока что для ЧТЕНИЯ) CD/DVD на БК или доработать драйвер от Terra(если что-то сохранилось).
#
RE:"формат ISO": да их там много: и ISO, и UDF, и еще какие-то,напрямую читаемые всякими UNIXами/QNXами..
Вопрос в том,что записываемые данные должны быть в формате "БКшном"(выше уже говорил об этом), иначе - что там будем читать-то? Сборники рефератов в MSDOS-".TXT"(кодировка ANSI), чтоль? :-D :-D
-
? RADIX50 - 10.04.2016 19:52
RE:"писать архивы можно и на PC":
...Ну,можно записывать диски и на БК,в общем-то(опять же,выше это уже говорилось,и обсуждалось ранее в "личке" еще до этого, с некоторыми участниками форума).
Возможный подход я вижу таким образом: на носителе достаточного объема(HDD/FLASH от 2ГБ и больше) с помощью средств DOS (или любой др. ОС БК - RT11,RAFOS/FODOS,m-UNIX...) создается некий "образ" будущего 650..700МБайтного диска CD "БК-001#" в некоем формате(ISO/UNIX или чисто-БКшные,"непонятные" для IBM :-P ). Потом,с помощью некоего драйвера или,лучше,запускаемой программы,типа варианта "NERO" или "WinOnCD",открывается этот файл-образ CD,производится уточнение параметров CDR-привода (марка,модель,тип,минимальная использ.скорость - хорошо бы,чтоб было доступно "1X",нам много не надо!); уточнение параметров CDR-диска(а вот тут может быть загвоздка,т.к. "болванки" практически все с мин. скоростью "4X" и выше,а сам привод тут же подстраивается под них,считав ATIP-зону с CDR/DVDR!); инициализация ("сброс/установка") CDR-привода в нужный режим; согласовка доп.параметров в диалоге с пользователем; далее,при получении "OK" от оператора, - считывание 700МБайт в ОЗУ(вот зачем на БКшке нужен будет 1ГБ ОЗУ!), выборка нужной/подходящей команды из MMC-набора,поятной данному CDR-приводу; получение сигнала готовности от привода; блокировка прерываний от всех внешних устройств(кроме,разве что,кнопок "КТ"("ESC") и "СТОП" на клавиатуре "БК-001#") и... запуск режима записи как такового... :)
-
? maxstudios@ - 10.04.2016 20:37
Если диски записывать не на БК, то никакой 1Гбайт ОЗУ на БК не нужен. Всё что нужно записать, собирается на CF, затем через картридер переносится на РС, а там уже записывается с помощью каких-нибудь программ записи дисков.
А насчёт приводов уменьшенного размера я не писал, имелось ввиду только использование маленких дисков с меньшим объёмом для удобства. Если не будет их в продаже - можно записывать на большие.
Просто думается мне, что с ОЗУ Бустера и БК-12 в 32-64 и выше Мбайт объёмы у новых программ будут уже не 16-128 Кбайт, а гораздо больше. Один только экран стандарта VGA 640х480 или 800х600 с большим набором цветов будет буквально "жрать" ОЗУ.
Поэтому стоит заранее продумать возможность сохранения и распространения таких объёмных творений, не будет же это всё храниться на CF.
Хотя можно конечно через инет всё распространять (типа готовых образов для записи), а хранить эти образы можно и на РС даже без записи, но лучше всё-таки записывать.
Исходя из всего вышеперечисленного, может и не нужен CD-привод на БК пока, но в будущем было бы удобно.
Ещё я придерживаюсь мысли, что формат записи должен быть обязательно читаемым и на РС, и на БК.
То есть, писать драйвер для БК под CD-привод нужно под стандарт РС.
:)
-
? RADIX50 - 10.04.2016 22:30
RE:"хранить на CF": ну,конечно,электромеханический,"обычный"(не-SSD) HDD - намного надежнее,и альтернатив ему еще долгое время не будет. CF,как и SD, - тоже "дохнут"(ну,конечно,в зависим-ти от производителя и качества самой продукции/конкретного экземпляра),сейчас сам занимаюсь восстановл-ем данных с двух таких носителей(старые,но важные/ценные фото),потихоньку матерясь :)
Конечно,лучше хранить данные на разнотипных носителях числом более двух(напр., на CD/DVD-R, HDD и на FDD; или CD,HDD и в интернете на емайл,или в LAN-сети на работе,и т.п.).
Но вообще,CF-диск(как на БК с контроллером,так и у меня сейчас на ноуте) - штука удобная(и при работе/отладке - весьма шустрая,и не боится ударов,как эл./механ.HDD),согласитесь? ;)
#
RE:"драйвер на БК под CD-привод под стандарт PC":
...Нууу.. вот.. тот же ANDOS - он именно так,в общем-то,и создан("с оглядкой",как я говорил,на IBM PC).. А мы вот в результате не могём никак разобраться,сколько секторов на дорожку правильно форматировать - 10 или 9 ... :-D
Вот не получилось бы при разработке такого драйвера как с БКшными дискетами на IBM(см. наши с вами предыд.сообщения),когда "вроде бы читает,а вроде бы и нет"..
Ну,"обычную" CDFS(CD-Aud. в стандарте "REDBOOK"),скорее всего,приспособить можно(диски слушать,не MP3шные,естественно.. :) ), а для переноса данных - вот тут,наверно,"надо думать,чего как"..
#
RE:"приводы уменьшенного размера":
Да все я понял!.. Я всего лишь просто помечтал,как хорошо бы смотрелся такой мини-CD/DVD-привод 3.5" рядом с БКшкой(если б такие существовали в "металле") - думаю,не хуже,чем на "Ямахе"(компактно,красиво и работает!): стоят рядом с БКшкой такие три коробочки на столе: FDD,HDD и CDD 3.5"(используют одно питание +5V, никаких лишних проводов,все идет по одному кабелю(многопроводный круглого сечения,типа "шнур",как на "Ямахе" сделано), - удобно и стильно).. :) :) :)
Правда,аудио-CD такого "малого" формата мне вот не попадались,думаю,что фирменных не найдем,разве что если сами не сделаем(так что придется все равно подключать "большой" CD-драйв) :)
Эх! )) Пока что остается только мечтать )))
...Кстати,недавно попалась инфа,что в СССР делали FDD-приводы 3.5" на 1.44М - но ОЧЕНЬ ограниченным тиражом(ага,совеццкий "limited edition" :-D),но "в массы" они,к сожалению,не пошли(т.е.,считай,"нет их").. А могли бы быть.. ))
#
RE:"формат записи читаемый на PC и БК":
...Ну,IBM PC,если разобраться,тут не столь уж прям "законодатель мод". Как правило,IBM PC использует уже сделанное другими производителями ранее,и вообще,как опытные программисты говорят, является "шагом назад" в компьютерной технике. Например, мало кто знает,что разработанный(вроде бы,изначально тоже не совсем для "Интелов") стандарт ATA/IDE изначально подразумевает подкл-е до 8 дисков(в IBM PC - максимум до 4), "флоповый" стандарт(изначально - интерфейс S.A.S.I.,давший основу для современн. SCSI) - до 4 FDD на одной машине(на IBM снова "урезано" до 2-х FDD,а щас - воще до одного,т.к. первые 6 контактов на плате бывают не запаяны - а это как раз сигналы выборки привода)..
Та же DEC ALPHA из группы 21X64 - полностью 64-битная машина, IBM PC - ну,типа,32-бит(а из возможных 64бит шины адреса на DIMM-модулях - видится только 2^32= 4ГБ,а реально - меньше,где-то 3.2ГБ ОЗУ - опять "урезали" - зачем??).
Виндовое меню "Пуск" - копирует аналогичное из UNIX-систем,существовавшее задолго до "Win-95/NT4",а MS-DOS - аналогичную командную консоль от UNIX/RT-11..
Да и много еще можно привести подобных примеров на эту тему..
...
Полагаю разумным взять за основу стандартный,исторически существующий(еще с "до-IBMных",так сказать, времен) формат, принятый/понятный в UNIX(и ее аналогах) ОС, типа какой-нидь "SIERRA/FS"(1987г.,предшественник ISO) или наподобие UFS(более современный,насколько понимаю),читаемый также и на IBM (тем более,что машины типа "БК-001#",ДВК/УКНЦ и похожие - они являются ЭВМ "не-Х86",т.е.,не-"Интел"-совместимой архитектуры и не обязаны под нее подстраиваться,это своя "ветвь" развития, по линии DEC/Motorola). Или делать что-то вроде "POSIX-поверх-ISO" (раз уж на БК есть micro-UNIX),включив поддержку CD в ядро ОС(т.е.,"сидюк" будет видеться без всяких доп.драйверов как обычный FDD) :) :)
Вот это было бы круто! ))))
...Да,только не надо забывать,что,если даже взять "удобный" ISO-формат,то данные все равно останутся БКшные,не всегда "понятные" для IBM PC,как те же,например,дискеты(то 720КБ,то 800КБ :-D).
...
Хотя,собст-но, такой формат,читаемый и там,и там, - он уже есть: это образы дисков БК (*.BKD или *.IMG), хранимые на IBM и пересылаемые по эл.почте, и довольно успешно "восстанавливаемые" на реальные диски БК или "подключаемые" в программные эмуляторы БК,работающие опять же на IBM.. :) :) :)
Так что,в принципе,такой "формат" уже "придуман" и без всякой там "БК-CDR" и т.п. :) :) :)
Вот :)
-
? maxstudios@ - 10.04.2016 22:56
Просто я не сижу на UNIX, я пользователь ОКОН. :)
К тому же, ВИНДА является массово используемой для домашних пользователей. Поэтому и предлагаю делать сразу так, чтобы диски могли свободно читаться и на БК, и на РС - эмулятор под ВИНДУ в этом случае будет сразу видеть те образы БК-дисков, которые будут записаны на CD-диски.
Но это всё конечно в будущем, не срочно. Бустер ещё не готов, а на написание программ-демок-игр-драйверов под него нужно будет ещё время в большом количестве.
Но "определить горизонты", я считаю, можно и сейчас. А то действительно получится, как в те 90-е - кто во что горазд, никакой согласованности, даже под муз.сопры умудрились разработать два стандарта, а потом спорили, у кого же правильней (на самом деле стандартов много, и ZX-стандарт взят только для передирания ZX-музыки на БК).
Сейчас время очень хорошее, так как всю работу можно согласовывать со всеми, все будут в курсе новья, могут советовать и придираться. :)
-
? RADIX50 - 10.04.2016 23:49
To: maxstidios 10.04.2016 22:56
SUBJ: "CD-R(и "ISO"-FS) на БК":
Ну, "не виндою единой",наверно,жив народ,я полагаю.. )
Т.к.сам знаю как минимум более одного человека(тоже,кстати, "одержимые",вроде нас :-D), у которых основная используемая система - как раз UNIX-подобная, и ЭВМ у них - системы "не-X86"(не-"Интел"-совмест., типа "Альфы" или SPARC'а), причем,и настольная,и ноутбуки(!),что интересно..
Да и вообще,как говорится,"покажите мне,что такого можно сделать в виндах,чего нельзя было бы сделать в UNIX'е?" ;-D
(т.к. "Винда" - в больш. случаев,по сути,"дохлое подобие" UNIX'ов,заимствование идей "микро$офтом" и "обрубание" их в худшую сторону; а графический тогдашний "MACOS"(он тоже,кстати,на UNIXe) программисты, даже "виндовые", меж собой зовут "Windows-1984", - что весьма показательно,надо заметить..) ;-D
#
RE:"стандартов много": да,стандартов много. И те же "COVOX'ы", например(известные нам в виде "резисторно-поразрядной" сборки на порт LPT IBM / УП БК),- это не весь "КОВОКС",это лишь его "оконечная" часть в виде такого нехитрого "ЦАП" для вывода звука на аудиовыход(а основная часть,"ядро",COVOX'а - это устр-во со сложной логикой, - почти что микропроцессорное,но попроще,включаемое меж шиной ЭВМ и вот этим "ЦАПом" из резисторов). Т.к. в России со "сложными" м/сх были тогда проблемы,потому и решено было "передрать" только "оконечную часть" от "COVOX"'а,которую мы,собственно,и знаем как "COVOX" - в целях простоты и экономии.
#
RE:"определить горизонты": нет,я ни в коем случае не придираюсь(боже упаси!), тем более,что на своей шкуре тоже доводилось в свое время это испытывать,и я знаю,что это такое,когда,как говорится,"мешают работать"(было бы "по делу" - тогда да,я разумную критику всегда слушаю и воспринимаю; а когда не по делу,то "тут уж извините",как говорится..), я стараюсь обратить внимание на "скрытые" "подводные" камни и моменты,возможно,многим не известные,- чтобы постараться это как-то учесть в разработке(чтобы потом самим же или нашим последователям не "мучиться",как говорится)..
К сожалению,не располагаю нужной материально-технической(и документальной) базой(а также,частично,- знаниями) по ряду определенных вопросов общей темы, иначе бы постарался,при возможности, сделать все сам(как,наверно,и большинство из здесь присутствующих)... :)
Да,сейчас в этом плане(согласовок и консультирования) проще,т.к. есть связь(и народ читает форум,что есть весьма хорошо!), потому,надеюсь,что "с мертвой точки" нашу тему удастся "сдвинуть"(сначала хотя бы доделать ту мелкую периферию и прочую "обвязку", вроде всяких программаторов,контроллеров,переходников и т.п., которые не были реализованы в 90-е гг, а потом уже браться за расширение архитектуры основной ЭВМ).
#
RE:"ISO/CD - драйвер":
...Я тут вот чо подумал..
Мож,тогда уж сразу(нежели шоб мучаться с этим ISO/UFS) попытаться выполнить реализацию поддержки файл-системы "Фул-эФэС"(см.линк)?
http://proolepedia.kharkov.org/index.php/FoolFS
...Будет как раз,и просто,и надежно,и "везде-реализуемо"(на любом носителе,неважно какого типа),еще и "MSDOS-совместимо" - да и вообще афффтор хотел сделать это для OS "RT-11"(!!!!!), о чем говорит в самом низу документа :-D :-D :-D
-
? maxstudios@ - 11.04.2016 00:18
Прикольная ссылочка, особенно убило это:
"...ну и что, что это будет тормозить, и пространство используется неэффективно, но зато программируется легко, идите в жопу..." :-D
Аффтор приколист, это обнадёживает. :-D
...
Всё-таки не хочется мне пока осваивать UNIX-ы, привык к ОКНАМ.
Да и программы всё-таки делаются по ВИНДУ - и эмулятор, и NERO.
...
Очень хорошо, что формат позиционируется, как MSDOS совместимый.
Но если этот формат новый, то ВИНДА и NERO уже автоматически исключаются из списка используемых.
А мы получаем новые проблемы - написание спец.программы для записи дисков в этом новом формате.
Думается, что на первое время проще всё-таки "подстроиться" под РС, взяв один из "стандартных" форматов ВИНДЫ, тот же ISO или UDF, не помню какие ещё там есть в списке.
:)
-
? RADIX50 - 11.04.2016 00:20
To: maxstudios@ - 11.04.2016 00:18
SUBJ: "аффтор приколист":
О,да! Мне тоже нравится! :-D
Ну,чо,поможем аффтору? )))))
-
? maxstudios@ - 11.04.2016 00:22
Дополню предыдущее своё сообщение - под новый формат придётся писать программу для записи дисков как под ВИНДУ, так и под UNIX, что не есть дело лёгкое и быстрое. Я немного соображаю в БК-ассемблере и Бейсике, но с РС-программированием не сталкивался вообще.
:)
-
? maxstudios@ - 11.04.2016 00:24
А как помогать аффтору?
-
? RADIX50 - 11.04.2016 00:43
To: maxstudios@ - 11.04.2016 00:18
SUBJ: "ISO или UDF":
Ну,тут все упирается в основном в объем ОЗУ на БК,и быстродействие,опять же,связки "сидюк+контроллер".
UDF,наверно,будет "слишком круто"(слишком большие объемы данных там хранятся)..
Для начала,разве что, CDFS+UFS(и, возможно,+ISO,но,опять же,если готовить данные для записи,то следует помнить,что формат - БКшный,не IBMный, т.е.,опять же,надо делать осн. привязку к UNIX'у(который не для IBM,а для не-"Интелов"): там инфо хранится,наверно,в похожем на БК стандарте,раз машина не IBM-совместимая, - я почему и говорю о бОльшей "оглядке" на UNIX; кстати,ISO там тоже прекрасно поддерживается,более того,есть системная команда MKISOFS для обслуживания ISO-томов в UNIX)..
Ну,если CD-A на БК послушать,в принципе,можно,то у меня в голове крутится вопрос,сколько займет алгоритм чтения с файл.системы ISO-диска,и впишется ли он в доступное ОЗУ?..
Т.к. считаю правильным попытаться "наваять" оный драйвер для БК-0010(чтобы у всех работало,и никого не обидеть),сообразно его "ОС"(точнее,правильнее это будет ДМОС,"драйвер-мониторная ОС"), и совместимость "смотрела" как бы "вверх",т.е.,чтоб "десяточные"(от БК-0010) программы работали и на "БК-0011".
Возможно,на первых порах оный драйвер можно будет грузить хоть с магнитофона, а впоследствии его можно будет "доделать" до включения в состав ОС.
Хотя,если алгоритм драйвера получится таким,что будет занимать почти все доступное ОЗУ(особенно,на "БК-0010"), то его хочешь-не хочешь,придется включать в состав ANDOS или UNIX-styled ОС(RT-11 и сходные), где есть т.наз. DMON(или любой так или иначе,daemon,"диспетчер"/микроядро),который,в случае надобности большого объема ОЗУ(загрузки/запуска большого исполняемого "бинарника"), выгружается сам(оставляя мелкую программку-"возвратник",чтоб она подгрузила "демона" обратно по завершении "большой" программы), тем самым освобождая почти все ОЗУ для работы запускаемой программы.
Ну,т.е.,так же примерно,как это делает тот же NORTON(Volkov)-Commander на IBM или даже ANDOS на БК.
...
Конечно,ОЗУ на "БК-0010" нужно в любом случае расширить,придумав какой-то отдельный сменный "модуль"(т.наз. "блок расширения" или "кассету ОЗУ",как это называется на "РК-86"), который можно использовать отдельно(не в составе SMK или "чисто-FDD"-контроллера), даже при работе на БК-0010 в "бездисково-магнитофонном" варианте, - естественно,"увязав" корректную адресацию этого блока Доп.ОЗУ с работой мониторной программы(собст-но,сама ПЗУшная DMOS БК как таковая,хранимая в 1801РЕ##-чипе) таким образом,чтобы оно было "всегда видно" при подсоединении этого блока к шине БК-0010(ну,и -0011,если надо,хотя там своего ОЗУ впаяно 128КБ).
-
? RADIX50 - 11.04.2016 00:51
RE: "программа и под "винду" и под UNIX":
Ну,в UNIX'е она,скорее всего,уже есть как стандартный драйвер(я про ISO), а вот для Виндов и БК,как минимум,да,понадобится.
...Если про "Дурацкую ФС" для "Пруликса"(Proolix_OS), то,видимо,да,будет надо и для IBM,и для БК, и для UNIX )))
...Хотя,если "FOOL_FS" заявлена "аффтором" как "POSIX(and MSDOS)-compatible",то,возможно,удастся с ней работать стандартными средствами ОС класса "UNIX"(но программу форматирования в такую ф.с., некий "F_FS_formatter",да,придется разработать) :) :)
-
? maxstudios@ - 11.04.2016 01:06
Пока на БК-0010 работает только СМК-512, Бустер не доделан.
Поэтому, чисто физически уже доступно подключить CD или DVD привод через СМК-512 к БК.
Памяти на БК-11М будет 512+128, а на БК-0010 - 32+512. Думаю, что в этот объём можно будет запихать драйвер.
А вот чисто программная поддержка - драйвер для БК, поддерживающий форматы РС - пока отсутствует.
Чисто теоретически, можно написать драйвер для БК, который будет определять хотя бы какой-то один формат (тот же ISO, к примеру), и диск от БК на РС будет представлять собой кучу файлов-папок длиной 800 Кбайт, как это уже было сделано при работе с винчестерами - эти папки на РС будут именно папками, а на БК они будут представлены как диски, или лучше - каталоги. Эти нюансы нужно продумывать, исходя из разборок с выбранным форматом записи на CD-диск.
В этом случае такие диски будут "видны" и на БК и на РС, записываться они должны будут только в одном поддерживаемом формате.
:)
-
? maxstudios@ - 11.04.2016 01:15
Не знаю кстати, что выдаёт РС при подключении БК-шного винта, а также интересно было бы узнать, как видится CF на РС.
:)
-
? RADIX50 - 11.04.2016 01:23
RE:"бустер не доделан...":
...Ну,ведь есть же еще стандартный,физический "SMK-64"(не ПЛИСовский), есть контроллеры "только-FDD" с добавленным "вторым этажом" блоком доп.ОЗУ (ну,те же 64К*16бит,или не меньше 8КБ*16бит,если это для "DOS_B10").. :)
Потому,полагаю,можно пока ориентироваться на мЕньшие объемы (наличия) ОЗУ,т.к. пока не у всех есть SMK-512 (помню,тут года 2.5 назад в старых ветках форума, кто-то про него сказанул: мол,типа,"..ну и что вы там в этих 512КБ делать будете? - программу,которая складывает "2+2" в верхних адресах?" :) - "шутник" попался)..
#
RE:"ISO": вот не помню точно,какое там ограничение на размер(число эл-тов) корневого каталога, но надо будет стараться при подготовке данных/образов для записи(кстати,ISO,оказывается,с помощью идущего в комплекте плагина прекрасно открывает WinRAR с версии v2.9 и выше, ну и NERO/WOC тоже) делать столько каталогов,чтобы влазить в ограничения,налагаемые как "стандартной" ISO,так и БКшных ОС(т.е.,опять же,как я говорю,"ориентироваться на наименьшие возможности").
...
А для начала,полагаю разумным как-то выйти на ув.тов. Terra'у - чтобы "поднять"(из пыльных архивов :) ) и посмотреть,на какой стадии находятся его наработки по этому вопросу(чтобы использовать уже сделанное,по возм-ти,с минимальными доработками).. Сначала - чтение CDA(допустим),тем более,что,вроде, по его словм,аппаратно-программный плеер уже написан; потом - эксперименты с чтением "несложных" CD(ну,от IBM,конечно), - с целью просто увидеть корнев. каталог диска и корректно отобразить хотя бы имена файлов..
Т.е., "не все сразу",и здесь нужно двигаться постепенно.
-
? RADIX50 - 11.04.2016 01:30
RE: maxstudios@ - 11.04.2016 01:15
SUBJ: "как видится CF на РС":
Да так и видится,как обычный жесткий диск соотв. объема. Я сразу подключил ее в ноут(взамен HDD), отформатировал(т.к. сделал там еще один раздел), немного "поигрался" с параметрами FDISK'а и др. программ для HDD-maintenance(вроде все показывает как надо,ничего такого "хитрого" не заметил), после чего перенес туда образ диска C:\ (с установленной WinXP и тем софтом,что мне надо), и перезагрузил машину.
После перезагрузки - все заработало так же,как при наличии эл./механ. HDD (кстати, на "линейном чтении" грузится весьма шустро, - аж увидевший работу ноута с "CF-диском" коллега поинтересовался: "Нифига себе? Это ты SSD,чтоль,поставил? Крууто!.."). Типа,мол,машина не игровая нифига,а стала "летать" шустро ))
...Так что,ничего хитрого )))
-
? maxstudios@ - 11.04.2016 02:07
У меня вот нет никаких старых устройств, кроме КНГМД недособранного. Но для IDE-устройств это ничто.
У меня вариантов два - купить СМК-512, или ждать выхода Бустера. Оба устройства дают дополнительную память. То есть, исходя из всех возможных вариантов, минимум 64 килобайта для драйвера всё-таки будет. Вот уже наклюнулся предельный размер драйвера. :)
...
В принципе, сформировать диск можно просто - одна папка будет в корне каталога, в ней будет уже куча папок по 800 Кбайт, а в каждой такой папке будет уже куча файлов по 16 и меньше Кбайт.
Можно даже высчитать, сколько таких папок по 800 Кбайт будет доступно. И ещё бы узнать, какое количество файлов на диске является пределом. :)
Если грубо посчитать, то 700 Мбайт нужно разделить на 800 Кбайт, получим где-то 875 таких папок-дисков. Если минимальный записываемый объём будет равен 512 байтам, то получим 1600 таких блоков-файлов. То есть, теоретически, максимальное допустимое число записываемых файлов будет равно:
875*1600=1400000 файлов. Если минимальный объём увеличить до 1 Кбайта, или до 2-4-8-16 Кбайт, то допустимое количество файлов соответственно уменьшится. Но нужно конечно знать ограничение количества файлов в CD-форматах.
:)
-
? maxstudios@ - 11.04.2016 02:11
Насчёт CF - мне интересно, как видится CF на РС, которая работает на БК через СМК-512.
Видит ли РС такую "БК-шечную" CF?
-
? maxstudios@ - 11.04.2016 09:42
Нашел описание ISO 9660 тут:
http://www.bog.pp.ru/work/cdfs.html
Но думаю, что надо бы поискать информацию у Михаила Гука.
-
? TheGWBV@ - 11.04.2016 11:06
"CF на РС, которая работает на БК через СМК-512" видится, видимо, как не форматированный носитель :)
Скорее всего, поддержку/сохранение формата MBR и партиций не стали делать из-за экономии места на HDD (чтобы БК-ашке больше секторов досталось) и немного укоротить код прошивки СМК. Хотя, теоретически, ничего не мешало оставить MBR, разбивать диск на две партиции, и вторую использовать как БК-ашную...
-
? RADIX50 - 11.04.2016 12:01
RE:"предельный размер драйвера";
RE:"КГМД недособранный":
Да,с простым FDC - HDD не воспользоваться,конечно.. Это верно :)
Нужен SMK или что-то похожее)))
В большинстве случаев народ в подобных случаях склоняется все же в пользу аппаратных,т.е.,физических(не ПЛИСовых) устр-в, т.к. есть случаи,когда "реальный" образец и его "FPGA/ПЛИС-клон" работают по-разному(либо "ПЛИС"-версия вообще не стартует,я говорил об этом выше). По этой же причине не всем нравится работать в эмуляторах(тут один мне как-то выдал: мол,"зачем вы тут из [..-на] город городите,мол,возьмите ноутбук-386, запихните туда свою прошивку со своим АН-ДОСом,если он вам так нравится,и пользуйтесь,мол,а про обычную БКшку - забудьте!", - ну воще не в теме человек,явно!). Все же реальная "БК-001#" - намного интереснее и.."живее",что ли: она вот она,стоит и работает,"шевелится".. Ни с каким эмулятором,пусть и на "386-й",не сравнить.. :)
Эмулятор - есть эмулятор,особенно программный.. Сколько мне попадались(на IBM,в смысле), - все какие-то "корявые" либо "глючные", либо тупо эмулируют "бездисковую" БК-0010(а магнитофон как я подключу?) с идущими в комплекте несколькими бинарниками(как правило,пара "тетрисов" и какие-нибудь шашки-саперы,и усе). Причем,самая основная часть - правильная трансляция/эмуляция команд из одной архитектуры в другую,- тоже "не айс"(у кого-то в документации к ней об этом сказано,у кого-то нет: типа,написал,шоб кое-как работало, "и ладно")..
...
Размер драйвера - ну,если делать/отлаживать на "бездисковой" БК(для встроенного DMOSа), - это одно дело; если делать для другой дисковой ОС,то немного другое дело(я про то,что окончательный размер файла драйвера- будет,скорее всего,определяться особенностями рабочей среды или ОС: сам алгоритм,"костяк" драйвера займет какой-то объем,плюс добавятся еще алгоритмы для "увязки" оного с ОС). Ну,если получится,то можно попытаться "уложиться" в 15.5КБ ОЗУ(как "БК-0010" при выходе в DMOS,где знак вопроса и курсор,- где мы набираем команду "START 1000"),сначала ориентируясь на этот объем(но у нас есть "козырь" в том,что ЭВМ 16-разрядная,т.е.,допустимые команды,по идее,могут быть так сказать,"шире",чем на "8-битках",т.е.,за один шаг можно "смолотить" аж 2 байта). Уж если совсем "не удастся" "вписаться",то да,следующая "градация" - это 64КБ(хотя,были контроллеры и с 16КБ доп.ОЗУ,и с 32-мя,кстати! :) ). Хотя,в ОС,где имеется какой-никакой "демон"("диспетчер"), запустить "большую" программу или драйвер - в определенном смысле несколько "проще"(за счет его "самовыгрузки" при надобности)..
...Я думаю,что если не усложнять задачу(пока что надо "научиться" только "прочитать" и все),то вполне может получиться..
#
Кстати,года 4(или даже больше) тут на форуме один участник уверял(в какой-то момент сцепившись с кем-то "в перепалку",по-моему..),что,мол,"у него было сделано,БК с контроллером SD-карточки,мол,тут несложно"(и вроде бы,с программной поддержкой,позволяющей вести I/O-обмен); по-моему,было выставлено даже фото его "устр-ва" в виде "все-на-проводках"(карточка SD(не CF!) включалась без адаптера,все проводки были припаяны напрямую к дорожкам SD).. Но сейчас на форуме этого персонажа нет.. А было бы интересно узнать у него хотя бы базовую "концепцию" его устройства(т.к. с завода SD-карточки идут форматированными под FAT32,довольно "громоздкую" по части организации хранения "длинных каталогов",а мы пока находимся "на уровне" FAT16)..
#
RE:"CF на PC,которая работает через SMK-##":
Ну,если носитель(CF или HDD) отформатирован в UNIX-подобной системе(RT-11,RAFOS и похожие) или в какой-то нестандартной(или каким-нибудь "RAMON"'ом), - то,как физ.устройство,его BIOS(или FDISK),скорее всего,увидит(скажет,что Non-DOS-диск); логическая же структура(файлы,дерево директорий..) - возможно будет увидеть,если ОС(на IBM) его поддерживает(всякие POSIX'ы и им подобные). В DOS - думаю,что даст ошибку(ага,а NDD ринется сразу его "лечить" в "стандартный" формат :-D),как минимум.
Если диск будет с FATом,то,предполагаю,что возможно будет прочитать его в режиме "DISKEDIT.exe /M"(хоть что-то увидеть)..
...Да и вообще,многое,наверно,зависит от того,какой дескриптор.. ;-)
-
? RADIX50 - 11.04.2016 12:11
Кстати,нам в контору однажды приносили DALLASS'овский электронный "диск-на-чипе"(немеханический,т.е.,можно так сказать,"флэшка" 80-х годов),со слов принесшего, "с инфой для какой-то там "Электроники-то-ли-60-то-ли-80,на ней стоял!"(Э-60,Э-85,более мощные машины этой же архитектуры,DEC-совместимой), типа,мол, "ну,IBM - продвинутая машина,должна прочесть!"(конец цитаты).
Ан не прочла.. (товарищ хотел,видимо,"вытащить" какую-то нужную ему информацию,но на своей работе штатными средствами это было либо неудобно,либо нельзя по инструкции) :) :)
Да,и интерфейс там был не IDE. Судя по соединителю,больше похож на SCSI или какой-то другой(чтобы подключить этот "псевдодиск",инженер ходил в др.отдел за каким-то контроллером,который,в итоге,ничего там и не увидел).
Так что,дескрипторы,господа, - енто великая вещь! ))))
-
? RADIX50 - 11.04.2016 12:16
RE:"не стали делать сохранение MBR...":
А-а,так там еще и MBR нету :-D
Воо как! ))
Значит,правильно кто-то говорил на другом форуме: что,мол,на HDD для IBM есть какая-то определенная обязательная инфа, а на "не-интелах",в частности, "БК-001#", эта инфа на HDD необязательна,т.к. на "БК" работа ведется "напрямую"(я так понял,"по регистрам"),"не вчитываясь", - главное,чтоб устр-во физически присутствовало на шине,т.е.,было запитано и подключено. Тогда я ничо не понял из той фразы,а теперь вот добавилась еще "крупинка" информации на эту тему :)
-
? TheGWBV@ - 11.04.2016 13:38
IBM/MS-DOS-совместимого MBR нет. Самобытный - есть :)
Теоретически, можно переписать примерно половину прошивки СМК, чтобы SD-карта (один из её разделов или даже файл №1 ФС FAT16), вставленная в Бустер, отображалась для БК-ашных ОС как БК-HDD. Но смысла в этом не особо много, пока есть в продаже CF :) Думаю, пока будет достаточно утилит обмена файлами FAT16<->БК или монтирования дефрагментированного файла образа дискеты, например, вместо дисковода A: или B: исполняемых в самой БК-ашке...
-
? RADIX50 - 11.04.2016 16:39
To: TheGWBV 11.04.2016 13:38
RE:"SD-карта":
Не,не на SMK. SMK там точно не было(чел. как раз и предлагал обойтись без оного,раз такой дефицит чипов "ВП1-128"). У него,насколько помню,было сделано все на нескольких м/сх неспециализированных(не знаю,мож,пара регистров и дешифратор,или какая-нидь "531АП2П"),размещенных на маленькой "макетке"(где вместо дорожек одни "точечки" сделаны), и небольшим числом проводов подсоединено к колодке.. по-моему,все же на "УП"(примерно как наш "MP3-декодер",куда,видимо,аналогичным способом "закидывались байты" ;) ...)
У SD интерфейс,судя по числу контактов,все же,наверно,последовательный(а УП-порт тем и хорош,что позволяет вывести распайку и для принтера,и для "БК-mouse") :)
#
RE:"CF-карты":
В продаже они пока есть,но в осн. в крупных городах(в регионы - разве что привезут под заказ с некоей определенной переплатой),т.к. производители,возможно,уменьшили объемы выпуска из-за снижения спроса в связи с переходом на гаджеты,использующие SD/MMC и др. похожие форматы. Да,CF - они даже немного развиваются: недавно находил CF аж на 64,128 и 256ГБайт емкостью(хотя,местные продавцы(кому лень открыть интернет,видимо) пытались меня уверить,что,мол,"щас больше 4ГБ не делают").
...Вот если где и надо переписать(точнее,чуть подправить) прошивку, - так это для снятия ограничения на максимал. объем носителя,распознаваемый SMK или иным сходным IDE-контроллером(кстати,сейчас уже "вошло в моду" SATA,т.е.,в будущем,когда IDE-диски(HDD,CD и DVD) закончатся,придется придумывать SMK-SATA-контроллер,а вот там уже "так просто" не сделаешь,ибо там все организовано,как я понимаю,программно,и такой же "бардак",как и на USB - "черт-ногу-сломит"). Вроде бы, ув.Voland'у вопрос про ограничение объема IDE-накопителя не так давно на форуме задавали,он объяснил,что дело тут именно в "подправке" прошивки, т.к. в свое время семейство "SMK-##" делалось немного "в спешке" или еще по каким-то причинам не был учтен этот момент(т.е.,насколько помню,пока что для SMK ограничение составляет 2ГБ на устройство). Конечно,подойдет,я думаю,и любой IDE HDD(даже большего объема,чем 8ГБ,который тоже является неким "ограничением",но для IBM,хотя,современные BIOS эти ограничения в "1024цилиндра" успешно обходят в режиме LBA-кодирования).
...Кстати,поиск тут теперь,после "улучшения сайта",работает? Не "все сообщения от пользователя такого-то", а именно поиск(как был раньше - по слову,фразе,части фразы, ну,и имя персонажа можно набрать - тоже вроде,находилось)?..
-
? maxstudios@ - 11.04.2016 17:08
CF - карты есть в продаже и в citilink.ru, и в ulmart.ru, и на aliexpress.
На aliexpress есть даже переходники с одной или двух microSD на CF - сделано в виде карты CF с одним или двумя слотами под microSD.
Ещё есть в продаже переходники SATA-IDE.
Поэтому никаких проблем с устройствами под СМК-512 или Бустер быть не должно.
А вот насчёт ограниченного объёма на устройствах под СМК-512 или Бустер я не слышал.
:)
-
? RADIX50 - 11.04.2016 17:19
RE:"SATA<->IDE":
Есть, но это,опять же,вопрос,насколько точно и корректно они передают сигналы с IDE на SATA(и назад). Т.к. был не так давно случай,когда "завалили" файловую систему на SATA-диске,подключенном через такой "контроллер-конвертор"(видимо,этот "черный ящичек" в один прекрасный момент дал "глюк" при записи данных,со всеми вытекающими..), причем так "основательно",что корректно восстановить что-л. оттуда, мягко говоря, сложновато..
Что-то в них может быть реализовано тоже "по остаточному" принципу или "а,фиг с нею". Попадался еще похожий переходник,который требует обязательной поддержки UDMA на IDE HDD,но реально ее не использует (видимо,требуется для начальной инициализации привода при подаче питания), что "отсекает" возможность использования дисков объемом менее 4ГБ(а вот их бы как раз бы и надо было применить).
Так что тут тоже есть нюансы(я ни в коем случае не придираюсь!) :) :)
-
? maxstudios@ - 11.04.2016 20:25
Ну винт для БК я, скорее всего, не соберусь использовать, так как 3.5" харду нужно +12 и +5 вольт.
Если только 2.5" винт от ноута пришпандорить. :)
IDE - разъём мне нужен исключительно для CD или DVD приводов.
У меня в запасе есть один LG CD-резак с шиной IDE, должен быть рабочим с вероятностью 99% - надо проверить будет. Также есть 2 или 3 DVD-резака разных фирм, но вот работоспособность у них под вопросом - отдали просто так. Будет очень хорошо, если в итоге у меня будет два рабочих привода - и CD и DVD. Можно будет экспериментировать и найти разницу в их работе.
:)
-
? Terra - 12.04.2016 00:10
http://bk0010.org/files/terra/tda.zip тут есть исходники по cd-rom, только не актуально это уже кажется - это было интересно когда винты дорогие были и хотелось создать архив всего-что есть. Плеер аудио нормальный был в последних клубах где-то, можно порыть ещё что-то, если кому интересно.
-
? Дмитрий - 12.04.2016 00:23
>> CF - карты есть в продаже ... и на aliexpress.
https://geektimes.ru/post/142651/
¤
Эти карты будут типа такого "винта"? Не, спасибо...
-
? Макс Багаев@ - 12.04.2016 09:37
2maxstudios
¤
цеплять пишущий CD/DVD привод к БК для записи CD-R CD-RW лишено смысла
тк надо обеспечить минимально(!) поток данных не менее 150КБ в секунду (1х)
¤
единственный вариант - это DVD-RAM приводы LG
но где вы возьмете диски ? они давно исчезли из свободной продажи
¤
так что CF-карта - наше все
тем более что с их покупкой проблем нет
-
? RADIX50 - 12.04.2016 10:03
RE:"фэйковый внешний винт":
Совершенно не такие. Речь шла об форматах SD(MMC) и CF(Compact Flash - твердотельный микродиск с эл.сигналами как у IDE/PATA-интерфейса),см. хотя бы http://www.kenrockwell.com/tech/lexar/600x-32gb.htm
На контроллере SMK-512 под нее предусмотрен штатный разъем; на SMK-64(-16,-32,-128,...) и у меня на ноуте - включена через пассивный переходник(два разъема,под CF ответный и как у HDD IDE,а меж ними печатные проводнички на плате), работает уж несколько лет.
Ну,а SD - все видели/знаете,думаю,нет нужды их показывать )
-
? RADIX50 - 12.04.2016 10:43
..Да,и,поскольку косвенно так или иначе имеем к этому отношение(БЦВМ корабля МКК "Буран"/"Энергия" имела сходную с КР1801/КР588 архитектуру,а на МКС и по сей день применяется мультиплексированно-демультиплексированные линии связи/управления), - то, несмотря на небольшой "оффтоп", но тем не менее, - всех с Днем Космонавтики!
...Понравилась статейка:
https://geektimes.ru/post/274032/
Экипаж звездолета "Россия"... :)
...Ну,кому интересно будет,там по линкам можно прочитать 3главы рассказа Павла Виноградова,60-летнего космонавта(летающего!!) о МКС,космонавтах и космосе в целом,а также о происшествиях на орбите... :)
-
? RADIX50 - 12.04.2016 13:59
RE:"maxstudios@ - 11.04.2016 20:25":
...в запасе есть один LG CD-резак с шиной IDE...есть 2 или 3 DVD-резака разных фирм, но вот работоспособность у них под вопросом - отдали просто так":
Как вариант - подключить их к IBM PC и попробовать,сформировав архив на 700МБ(CD-R/RW) и 4500МБ(DVD R/RW),записать его на "-RW"-болванку(соотв.формата) с целью проверки работоспособности(перезаписываемый диск формата "-RW" - для того,чтоб не "тратить" болванку в случае некорректной,т.е.,со сбоям/ошибками, записи..).
А на БК - ну,разберемся,со временем-то )
-
? maxstudios@ - 12.04.2016 15:54
Дмитрию:
Упомянув aliexpress, я имел ввиду только переходники с microSD на CF, и обычные настоящие CF. Речи о винтах-подделках не было. Не думаю, что такая подделка была куплена с aliexpress - деньги отправляются продавцу только после подтверждения получения посылки покупателем, если всё устраивает покупателя. Отсутствие "шороха или скрежета", присущего любому винту, должно насторожить. В этом случае открывается "спор" по данной сделке и дальше можно получить с продавца компенсацию. А за такой конкретный обман этих "продавцов" просто выкинут с aliexpress.
...
Максу Багаеву:
Я и не собирался пишущий CD-R использовать на БК для записи дисков, только для чтения.
Выше это уже обсуждалось между мной и RADIX50. Расшифрую - диски предполагалось записывать на РС, информацию для записи перегонять с БК на РС через СF, а на БК потом только читать готовые записанные диски.
...
RADIX50:
Да, будет время - проверю все свои приводы на работоспособность.
...
Раньше продавали игры и программы на кассетах и дисках. Для приставок продавали картриджи - пластмассовые коробки с маленькой платкой и микрухами.
В настоящее время программы статично сохранять можно только на CD, DVD, BluRay - дисках. На винте информация подвержена изменениям и краху, на флешках также доступно изменение хранимой информации.
Всё-таки получается, что диски - самое надёжное для хранения средство, не подверженное ни вирусам, ни случайному удалению-изменению.
:)
-
? Дмитрий - 12.04.2016 15:59
>> Совершенно не такие. Речь шла об форматах SD(MMC) и CF(Compact Flash - твердотельный микродиск с эл.сигналами как у IDE/PATA-интерфейса),см. хотя бы http://www.kenrockwell.com/tech/lexar/600x-32gb.htm
Я не то имел в виду. И я в курсе как выглядят SD и CF. Китайский CF на 8/16Гб может оказаться на самом деле закольцованной флэшкой на 1Гб, по цене полноценного 8/16 гигового аналога.
-
? Дмитрий - 12.04.2016 16:03
>> А за такой конкретный обман этих "продавцов" просто выкинут с aliexpress
Там море таких "шутников". И появляются все новые. Так что "выкинут", "честность" - это не про всех китайцев. Приятель заказывал ворох какой-то фигни, пришла половина рабочих, половина откровенно дохлых. Написал на форуме отзыв про этого шутника, так он задолбал на ломаном англ. писать, чтоб приятель убрал негативный отзыв. Приятель наотрез отказался. Даже в случае полного возмещения стоимости покупки.
-
? RADIX50 - 12.04.2016 22:19
RE:"пишущий CD-R":
Ну отчего же нет? ))
Я как раз-таки и не против,если это удастся реализовать.. Нужно всего-то обеспечить поток данных "на выдачу" под запись CD-R в объеме 176КБ/с (~ в 2 раза выше битрейта FDD в HD-режиме),из которых 150КБ/с - данные пользователя,а 26КБ - служебные данные самого привода(юзеру не видны), ну,или,в крайн.случае,704КБ/сек, если привод окажется "упрямым",и подавай ему не ниже "4X" )))
Возможно,сие удастся реализовать,используя блок с 1801ВМ3А(МПИ'шный),разработанный под рук-вом ув. MM (он все же побыстрее "1801ВМ1")..
Только надо сразу определиться с выбором файл.системы и форматом записи как таковым - чтоб не создавать себе же проблем в будущем,и усе :)
RE:"закольцованные флэшки на 1ГБ": мне,слава богу,не попадались,но такие случаи у коллег наблюдал.. )
Для этого есть системные программы типа "Flash-Detect" и им подобные,которые: а)читают firmware флэшки; б)выдают реальный ее объем.
Причем,подобным подделкам подвержены и SD,и CF(и там,и там пользователи портили свои данные,когда сохраняемый объем доходил до точки "петли").
Мне попадались такие SDшки,что в осн. "дохнут"(10м-цев полежала - и перестает читаться), или нарушается контакт на контактной группе(т.е.,в кард-ридере не определяются,а при вставке в ф/а - вполне; видимо,там более жесткая конструкция картоприемника или встроенная защита от ошибок).
#
RE:"отсутствие шороха и скрежета":
Ну,при использовании CF вместо HDD на ноуте - оно именно так и обстоит :) :)
"Электронный диск" работает совершенно бесшумно. Слышно только,как "звенят" преобразователи ШИМ в ноуте,когда идет "запись/чтение" с "HDD"(всплески потребляемого тока,которые отслеживаются ШИМ'ом),ну и еще вентиляторы ноута(которые стали включаться реже из-за отсутствия подогрева от HDD).
Кстати,если заказываемый диск - был SSD(в USB-коробочке), то он тоже будет бесшумный,и подкопаться будет сложнее..
...Кстати,при вскрытии корпуса прибора - в больш.случаев лишаешься гарантии(т.е.,надо еще придумывать,как ты это определил; а если еще и сфоткал да выложил в интернет - значит,сам предоставил улики против себя,что нарушил гарантию,т.е.,как было с советской аппаратурой,"залез под пломбу"; и,если у них юристы грамотные,то тебя же еще и "раскрутят" по полной программе).
#
RE:"CD, DVD, BluRay... - самое надёжное для хранения средство, не подверженное ни вирусам, ни случайному удалению-изменению...":
Немного не соглашусь. Еще как подвержено!..
Пример 1: друг вез в одной сумке чистящие салфетки с жидкой пропиткой,еще какой-то набор чистящей "компьютерокосметики" и портмонэ с дисками(CDR,CDRW,DVD-R записанные,архив свой). И,в общем,пока ехал по ухабам,все это "встряслось",и жидкая пропитка вытекла из салфеточной баночки(ибо рассчитано было,что банка будет стоять на днище ровно и не трястися), потекла по дискам CD/DVD-R.. Результат: "разъело" там все(туда,где попало): произошло эл./хим. "травление" поверхности(да даже достаточно просто нарушить гладкость или чуть замутнить), и почти весь архив погиб. Благо,что остались образы NERO(как подготовил к записи) и прочее содержимое архивов на других ЭВМ(еще не успели стереть как уже сделанное,а потому в данн.момент не нужное), и можно оказалось повторить запись. Диски CD/DVD,которые "фабричные", "штампованные", остались целы,хотя,картинку(типографскую) с одной стороны на них тоже чуть попортило".
Пример2: у др.коллеги(ксати,отличник-выпускник ф-та "ЭВМ" по специализации "устр-ва хранения данных") стояла полочка(помню,прибивали с ним ее,по всем правилам,ставили на стену :) ),на ней были "по всем правилам" записанные диски CDR/DVDR. И,значит,В один прекрасный момент,когда начались солнечные деньки(примерно к середине февраля), то солнышко,проходя по небу,на часок своим краешком "проводило" по этой полочке(а так,в общем и целом,комната/квартира-то у него выходила на теневую сторону дома,и даже днем приходилось всегда включать свет в комнатах), результатом чего явилось "сдыхание" бОЛьшей половины его архива. Причем,диски не были "на прямом солнечном свете", они хранились хоть и в прозрачных,но коробках(вот этих,новомодных, slim-варианта).
Пример 3: диск CDR(и особенно DVDR) запросто перестает читаться,если на нем надписать шариковой ручкой,даже с "тупым",округлым,пишущим узлом(нет-нет,на "тыльной" части,где "этикетка",если диск односторонний). Полно случаев,когда при использовании фломастеров,сделаных как "специально для надписей на CD/DVD" содержащаяся в чернилах "химия" разъедает лакопокрытие(специально,как сказано,предназначенное для надписей фломастером и надпечатки),в результате чего диск тоже портится.
Пример 4(про вирусы): в одном зарубежном "продвинутом" журнале,выходившем с "CD-приложением" в каждом номере издания,произошел такой казус: при записи "мастер-диска" для тиражирования в комплект была включена зараженная обычным "файлово-бутовым" вирусом программа,предлагавшаяся пользователям к применению.. Которая и разошлась э-э-э... полным тиражом... :-D
Т.е., один файл,содержащий обычный "бутовый" или файловый вирус, будучи записанным на диск,по сути дела, "рушит" весь архив,превращая его в "бомбу" или "подлянку"(иногда "подложенную" самому же себе).. Причем,при надобности восстановл-я файлов с такого архива - еще не сразу сообразишь,откуда у тебя завелся вирус на вроде бы "чистой" до этого системе(на "карантинной" машине, ни к каким сетям не подключенной)..
Пример 5(из личного опыта): однажды снял полную копию данных со "сдыхающего" HDD,записав ее на DVD+R("болванка" однократной записи,не из дешевой ценовой категории и известной фирмы). Т.к. надо было идти(время в обрез), то надписать ее забыл,положил среди других дисков.. Через некоторое время тот HDD уже "не завелся",а понадобились данные,там хранившиеся.. Когда же нужная DVDR была найдена,то ровным счетом с нее ничего не прочиталось. НИ-ЧЕ-ГО. Она превратилась в "пустую" незаписанную(ни одна дисковая утилита не показывает наличия там даже "зачаточных" признаков какой-либо записи: дескриптор "T.O.C.",флаг открытия/закрытия сессии записи и т.п.), хотя,запись была произведена НЕ в режиме "тестирования", да и на самой болванке видно,что запись на ней ЕСТЬ(т.е.,"выжженная" зона более мутная). Все перепробованные DVD-приводы и служебные программы говорят,что "диск пустой,доступная емкость 4500МБайт".
Мистика какая-то!.. %-)
Пример 6(из личного): сколь-нибудь успешное чтение даже корректно и правильно записанной CD/DVDR хорошего производителя,бывает,не гарантируется вследствие некоторой разницы в юстировке DVD приводов(он работает,но оптика "чуть-чуть",под другим углом,выставлена, - примерно та же ситуация,как головки у магнитофонов..), разницы в алгоритмах "поиска дорожки" и обработки ошибок(один привод будет пытаться читать до посинения,пока не прочтет,а другой чуть "споткнулся" - сразу выдает "ERROR"), и еще полно случаев,когда,например, пытаешься прочитать диск на приводе,находящемся в относительно холодном помещении. Т.е.,густеет смазка деталей,"плывут" конденсаторы в схеме управления автофокусировкой линз оптики, - и.. вот тебе результат.. Сначала было подумали,что так же "сдохла" DVD-"болванка"(как в предыд.примере),попробовали другую.. Нет,то же самое: привод шуршит головками и "подкручивает" диск(то быстрее,то медленнее,в цикле..),как будто диск нечитаемый(хотя,в данн. случае, "нечитаем" как раз сам привод). Короче говоря,воспользоваться единственным в стэндовой ЭВМ DVD-приводом в тот раз не удалось(а время поджимало,и нужно было выполнить определенные действия).. В общем,самым "устойчивым" оказался,как ни странно,старый CD-привод(не пишущий), не помню марку,но по скорости - "24X max."(конечно,в тех условиях ни о каких "24X" речи не шло,он читал обычными 6..8-ю "скоростями",правда,диск CD,не DVD).
Причем,что интересно,ноутбучные DVD(RW)-приводы,как ни странно,"на холоду" работают лучше, чем "настольные"(которые всегда считались более лучшими и функциональными).
#
Вот потому я в одном из своих сообщ-й и говорил о том,что лучше хранить данные на 2-3 разнотипных носителях(с разными принципами действия).
А в общем/целом,- "ничто не вечно под Луной" :)
Вообще,наверно,самый надежный способ хранения - как ни странно,на дискетах! )))
Как написал один чел. на каком-то "технофоруме", "... ну вот смотрите: 1 гигабайт дискет разом НЕ СДОХНЕТ, а 1 ГБ HDD - запросто!"(конец цитаты) :-D
Думаю,во многом чел. прав: HDD сдохнет "сразу" и весь, а дискеты - хоть что-то,да останется! )))
Энтропия,блин! )))
-
? RADIX50 - 13.04.2016 00:44
To: Terra - 12.04.2016 00:10
SUBJ: "исходники по cd-rom":
Пока не имею возм-ти прочитать архив на "реальном "железе""(просмотр бинарника .bkd на IBMовском вьюере/HEX-edit'e не помог,т.к. читабельного текста там не выявил :) ), потому хочу уточнить(если что,сильно не бейте): там только исходники драйвера или что-то еще было в комплекте?.. Я имею в виду,по какой схеме проводилось физическое сопряжение "БК-001#" и CD-R(OM)-привода: делался индивидуальный переходник на "УП БК" с обвязкой,куда "закидывались байты",или на МПИ, или разрабатывался какой-то "свой" контроллер,или ипользовался уже готовый из "стандартных"(SMK или другие,поддерживающие HDD/IDE)?..
#
...Да,и еще хотелось бы узнать(скорее,этот вопрос,получается,уже ко всем): кто-нибудь пытался экспериментировать с применением на БК контроллера КЖД(т.е., HDD) от ДВК?.. А УКНЦшный(КЖД)? У кого какие результаты получились?.. Сохранились какие-то схемы или их фрагменты/варианты?..
Есть вариант с переходником для применения на БК УКНЦшного контроллера FDD(он на схожей элем.базе построен,в т.ч.,на "ВП1-128"), но схема эта распростр-я не получила,т.к. самим же автором было сказано,что есть определенные нюансы("...программы,использующие стандартный на БК доступ к контроллеру, на УКНЦшном работать не смогут").. Какие-то еще "нюансы" имелись и для случая с КЖД-контроллером от ДВК при задействовании его для БКшки(ув.тов. Надежин сразу же,не вдаваясь в подробности, "не советовал повторять")
-
? Terra - 13.04.2016 11:57
так текст весь в кои-8, а вы воспользуйтесь программой BKDE.exe от gid из комплекта его же эмулятора. Cd-rom цепляется слейвом на SMK.
-
? MM - 13.04.2016 16:47
КЖД от ДВК цепляется на МПИ БК0011/М в соответствии с распиновкой. Кабель к КЖД должен содержать каждый 2-й провод общий - для снижения помех. Максимальная длина кабеля - 1 метр, но желательно не более полуметра.
Грузиться необходимо с обычного гибкого диска с штатным драйвером DW.SYS . В самом драйвере в области боот-блока в его текст внести коррективы - слова 112 и 114 должны содержать копии по записи регистров 177716 и еще какого-то. Типовое содержание 112 - 005000 ( 8 ) - соответствующее 1-й странице ДОЗУ БК0011/М на 040000, 2-й странице - на 100000 адресах. Перегружаться на винт можно командой BOOT DW0: .
*
Современные IDE пишущие приводы, выпуска после 2005 г. не требуют соблюдать норматив скорости потока данных - по крайней мере в моделях Пионер.
Встроенная интеллектуальная микропрограмма сама все исправляет при записи, латает все дыры. Однако, всегда есть риск, что автомат сделает что-либо неправильно.
*
Вопрос о стардартных ФС на IDE - винтах и проигрывателях до сих пор открыт. Это объясняется существенным размером кода , необходимом для полноценной ( прозрачной для старого софта БК ) реализации алгоритма, причем в самом ПЗУ блока КНГМД/IDE.
А так контроллер IDE ДВК разработки уважаемого господина anonymous не заморачивается такими мелочами - винт просто делен на сектора по 32 метра - в количестве до ~255 секторов, общей суммарной емкостью до 8 гбайт. Контент АП винта с адресами больше 8 гбайт может поддерживаться программами пользователя.
-
? Terra - 13.04.2016 22:39
судя по этому документу https://www.dropbox.com/s/oy7l7jj4xz316ee/%D0%B2%D0%B8%D0%BD%D1%87.%D0%B4%D0%BE%D0%BA.txt?dl=0 КЖД подключали в Питере в 1993 GASP Inc. (авторы отладчика Paradise).
-
? Макс Багаев@ - 15.04.2016 15:43
Замолвлю словечко про надежность носителей, тк у меня есть "некоторый" опыт
1. мною писанные диски 5.25" отлично прочитались спустя 20 лет. следует отметить что ГМД130 20-25летней давности писанные не мной читаются хуже
(предстоит перелопатить >400 дискет с софтом для ДВК/0585)
2. CD-R надежны. самые старые CD-R у меня датируются 96-97м годом - читаются почти на максимуме и сейчас.
следует отметить что технологические диски, в плане сохраняемости не уступают "фирме"
общее количество записанных CD-R у меня >10K (точного количества не считал)
в брак вылетели только две партии 100шт - Mirex c печатью и Memorex с печатью в были вовремя переписаны.
3. DVD-R очень надежны, фатально их поцарапать практически невозможно. и писать можно на диски с царапинами.
их у меня >4K
4. BD-R - еще удобнее - объем больше скорость больше. рекомендуется к использованию.
их у меня >1.5K
вылеты единичные, все обнаружены на стадии записи. после отказа от NERO - брака нет совсем.
¤
по поводу приводов
надо понимать, что после перехода на пластиковые линзы, привода стали крайне недолговечны
те если TEAC W540 спокойно писали 10-20тыс дисков
то DVD привода живут максимум 2-3 года, после чего качество записи падает.
грубо говоря писать что-либо на современном приводе старше 2х лет не рекомендуется.
по выбору приводов
CD - Ricoh, TEAC (как ни странно плексторы показали себя как посредственные писалки с невысоким ресурсом)
DVD - LG (да, тут лыжа оказалась лучше всех из-за качества и мультиформатности)
BD-R - Pioneer
¤
самые плохие приводы - NEC, Yamaha
¤
если интересно - напишу про винты
-
? Макс Багаев@ - 15.04.2016 15:46
да, еще, про солнце - наслушавшись баек что мол солнце убивает диски
собственноручно жарил около 10 разных дисков на окне в течении полугода - с весны по осень
результат удивил: некоторые синие (вербатимы и меморексы) поменяли свой цвет
меморекс стал вообще оранжевым! (остальные фталциатиновые сохранили вид)
и самое важное - все нормально прочитались!
-
? RADIX50 - 25.04.2016 20:55
RE:" Макс Багаев@ - 15.04.2016 15:43("надежность носителей...") ":
RE:"самые плохие приводы - NEC...":
#
Да,у каждого производителя есть свои "нюансы",равно как и у производимых им приборов(напр.,ноуты конкретного определенного модельного ряда имеют свои конкретные "болячки",напр.,формиров-е трещин вблизи петель экрана(из-за слишком сильной заводской затяжки гаек),плохой контакт на одном из сокетов под ОЗУ,из-за чего иногда "завешивается" вся машина при пуске,и т.п.).
Кроме этого,из-за "открытости" архитектуры IBM PC и многообразия номенклатуры производимых изделий(делают кто,что и как хочет, в отличие от той же DEC/MOTOROLA,например),существуют такие комбинации девайсов и "обвязки" (либо пары "привод+носитель",допустим), при которых возникают такие сочетания,допустим, тех же приводов и DVD-болванок, когда конкретный диск(хоть записанный,хоть штампованный) НЕ ЧИТАЕТСЯ ни на одном из известных/имеющихся в наличии приводов; либо конкретный привод, не читающий конкретный тип носителей(напр., у нас в конторе были DVD-приводы,которые "В УПОР" не хотели работать с дисками типа "DVD-R/(-RW)", а "плюсовые" форматы, "DVD+R/+RW" - прекрасно писали/читали).
...И,в общем/целом, вне зависимости от материала линз(пластик/стекло/спец.пленки и др.), приводы(равно как и вся другая аппаратура/техника) "старых","прежних" выпусков, - изготовлена с намного более высшим качеством сборки,нежели теперешняя("экономят" буквально на всем,даже на конденсаторах,напр.,фильтров питания,а ведь это,по сути,весьма критичный элемент для любой аппаратуры!).
...
RE:"Если интересно - напишу про винты":
Да,конечно,интересно.. Если можно,озвучьте,плиз! :) :)
...
RE:"солнце убивает диски":
...Ну,опять же,везде по-разному(разное качество в зависим-ти от партии и конкретн. экземпляра "болванки"). Напр.,в наличии полно болванок марки "VERBATIM"(признанной/считающейся одной из лучших), которые,бывает,почти перестают читаться,стоит их чуть потаскать с собой даже в CD/DVD-"портмонэ"(где кармашки из таких флиссовых салфеточек): сначала на поверх-ти дисков появляются "точечки"-отпечатки от этих самых салфеточек(прям повторяющие текстуру самой ткани салфетки),потом диск перестает читаться вовсе(имеется в виду,записываемые болванки; люминевая "штамповка" в этом плане несколько более устойчива). Но,в то же время, есть DVD-болванки,треснувшие почти на всю толщину,но,тем не менее,еще читаемые(недавно сам обнаружил несколько штук таких,оперативно перезаписав их на новые).
А еще попалась "болванка"(тоже DVD -\+ R(W)),которая,полежав в не очень теплом помещении,будучи 2-слойная, - при взятии в руки расслоилась "на две" - как раз.. по промежутку меж этими слоями! :-D
Хотел ее сфоткать(просто показать),но меня отвлекли(надо было выполнить некоторую возникшую оперативную задачу),а оставленную(тоже напоказ,на видном месте) без присмотра "болванку" кто-то из коллег выкинули.
...
Да тут солнце,по-моему,"убивает" не только диски,а было более одного случая,когда портились микросхемы ПЗУ(когда забыл наклеить поверх окошка черную изоленту,а дверцы/крышка блока была оставлена открытой часа на 3..4); причем,даже не именно "_солнечный_", а просто дневной(непрямой,рассеянный!) свет, имеющийся в помещении в течение "световой" части (рабочего) дня.
Приходилось тащить программатор и перезаписывать прошивку заново(если бинарники имелись); причем, коллегами была сделана/собрана и велась(пополнялась) библиотека прошивок для разной имевшейся в хозяйстве аппаратуры, - как раз на такие "пожарные" случаи.
...
RE:"результат удивил...":
Ну,строго говоря,наверное,не стоит особо обольщаться на заявленные производителями "100лет хранения данных"(на оптич.дисках,в смысле). Проводимые ими тесты - это т.наз. "лабораторное" "старение"(при упрощенных условиях и каких-либо "допущениях",принятых самим же производителем,т.к.,вроде бы,единых "ГОСТов",тем более - у "буржуев", на эти эксперименты, насколько знаю, - нет,каждый пробует/тестирует своим способом,"кто-на-что-горазд").
Реальный срок(если болванка будет храниться в темном отапливаемом помещении при стандартных усл-ях по влажности и т.п.) может составлять.. ну,лет 20-ть..
Вообще,в пр-пе,чем выше плотность записи данных, - тем,в принципе, ниже надежность носителя(закон физики).
Да даже дело и не столько в плотности,а в устаревании носителей и,скорее даже, самих форматов записи. Как сказал один чел. в своем интернет-блогге, - "доходит до маразма: когда внук или даже сын - не может посмотреть папину/дедову свадьбу, записанную на такой диск стандартным для своего времени способом!"(конец цитаты).
Пример: сейчас немного найдется устройств,поддерживающих формат "LD"("Laser Disc") - лазерная запись видео и музыки АНАЛОГОВЫМ способом(типа,натуральная "ультра-компактная" "грампластинка",записанная лазером). В свое время,до 1995г.,примерно, - было выпущено довольно много фильмов и аудиоальбомов разных авторов(правда,не у нас,а за рубежом,в Европе/США; у нас были доступны в виде "фирменных" копий, обозначаемых продавцами как "прямо-с-лазерки"). Хотя,качество записи,по крайн.мере,у виденных мною работающих экземпляров, - было,прямо скажем,повыше,чем у всяких там MPEG4/DivX/XVid и им подобным..
Вот примерно так :)
-
? Макс Багаев@ - 04.05.2016 04:50
продолжу
я думаю стоит пояснить какие проблемы несет в себе запись на плохом приводе или старом приводе
как я понимаю, все примерно представляют физическую природу записи на оптические диски - прожигание питов
разной длины - длинный "1" короткий "0"
тк физического прожигания не происходит, а только изменение состояния красителя то контрастность питов зависит от мощности лазера и качества оптической системы
соответственно привода с грязными линзами, слабыми лазерами не будут обеспечивать необходимой контрастности для длительного хранения носителей
из опыта диски записанные на NEC/Yamaha начинали "плохо читаться" уже через 2-4 года
.
касаемо юстировки - привода по природе своей имеют полную возможность настроится на любой трек и качественно записанный диск будет читаться на любом приводе
соответственно если диск начинает читаться только на одном приводе, это все показания для его перезаписи
те контрастность падает (она вообще падает со временем) и уже не любая оптическая система способна снять данные
.
да, я забыл похвалить пионеры - CD-читалки - 24х и 32х
это были самые быстрые (по времени позиционирования) привода
.
про солнце
как я уже сказал прямое воздействие солнца не способно убить диски, однако оно явно может повлиять на контрасность питов (см выше про кардинальное изменение цвета болванок)
соответственно как уже было сказано, при записи на плохие привода, можно получить что и солнца хватит "на добивание"
c микросхемами памяти тоже самое - те если микросхема изначально бракованная то и солнечного света хватит для порчи
тк микросхемы тоже проверяли на воздействие солнца
из опыта - некоторые буржуйские стерлись через месяц, наши РФ2 - вообще никак. те есть зависисмость еще и от технологии производства и размеров кристаллов.
.
про Verbatim
надо понимать что это торговая марка, под которой были и реально качественные диски произведенные Taiyo Yuden (к примеру Verbatim Crystal)
но и откровенная лажа индийского производства (как правило 90% всех вербатимов)
определить просто - прочитать ATIP
.
да, нативные CMC были как правило лучше тех что маркированы Verbatim
.
еще про солнца и болванки. как я уже писал - был вылет 2х партий дисков с печатью
(про печать я говорю совершенно не случайно)
тут следует вспомнить про устройство диска
начнем с низу
поликарбонат
краситель
отражающий слой
лак
надписи краской
.
технологические диски отличаются от этого только отсутствием надписей краской
.
так вот - если эти надписи, по какой-то причине (втч и воздействие солнца)
начнут дифундировать в лак или иными способами его повреждать
то диск перестанет читаться
.
в моем случае именно это и произошло - на местах надписей мирекса - возникла "шагрень" которая и стала мешать чтению
.
так что лысая технология потенциально более долговечна при наличии качественного лака
.
.
¤
про винты
на самом деле тут роман писать можно, особенно если начать вспоминать легендарные серии жестких дисков
я пока ограничусь актуальными советами
- сейчас показатели SMART не являются конечной инстанцией
те по показателями винт может быть "жив" а в реальности уже труп
- проверить просто - запускайте селфтест при помощи smartctl (есть порт и под винду)
и после прохождения длинного оффлайн теста можно сказать что винт жив
.
да, не все производители поддерживают селфтест
как я помню его не понимает самсунг - полностью игнорирует
проблемы с поддержкой есть у WD/Hitachi/Toshiba
нормально работает на Seagate/Quantim/IBM
.
про SCSI
Я думаю многие системные инженеры (администраторы) сталкивались с проблемой систематически "выпадающих" SCSI жестких дисков на серверах [мы говорим про hotswap]
причем "выпадывает" как правило, один и тот же жесткий диск
как правило после "вынул-вставил" он работает снова но через какое-то время все повторяется
.
как оказалось причина очень проста - разъемы в которые вставляются жесткие диски в cервер не впаяны (!) в бекплан плату, а просто вставлены и держаться только за счет трения
очевидно, что такой контакт никак нельзя назвать надежным.
.
лечить просто - вынуть бекплан плату и пропаять все контакты
лично вылечил сервер HP DL380G4 страдавший этой проблемой
.
про долговечность железа
да, качество железа падает катастрофически
те если хороший топовый БП мог гарантированно отработать 7-8 лет
то сейчас такой же топовый - 2-3 года
те равно как и обычный.
.
материнские платы и бессвинцовые припои
для понимания - свинец в припое был всегда основой и что важно - пластификатором припоя, тем самым обеспечивая некую пластичность паянному соединению.
соответственно все современные бессвинцовые припои стали значительно хуже по механической и вибрационной стойкости
.
а теперь вернемся к материнским платам - все в курсе что мосты чипсета давно в упаковке BGA и держатся на припое
соответственно если температурные коэффициенты чипа и платы отличаются - контакт будет нарушен
раньше эту проблема решалась за счет пластичности припоя и невысокого нагрева самого чипа
сейчас же сочетание смертеное - те чипсеты нуждаются в принудительном охлаждении (и не верьте что там хватит простого радиатора) и бессвинцовый припой
результат - типовая неисправность видеокарт/ноутов/материнок - отвал чипсета/чипа
.
совет - см выше - обеспечьте максимальное охлаждение чипсета, этим вы реально продлите ресурс железа.
-
? Severyanin - 05.05.2016 02:18
Ох уж эти бессвинцовые припои. С ними всё отваливается буквально в руках.
-
? MM - 05.05.2016 03:57
Рохсовые припойчики и беременные бачки - это проделки китайси, для Повышения спроса и уменьшения ремонтопригодности.
Если делать аппарат по старым добрым технологиям времен 486 и П1 - железка запросто 20 лет протянет, с профилактикой или даже без таковой - а за 20 лет китайся с голоду подохнет, им более 10 лет - песец. Сейчас и вовсе на 5 лет нацелились...
*
А вот ежели делать по совковым технологиям времен 1980-х, усё обильно "желтить" и "зеленить" - тогда и 30 лет - не срок...
*
Я вот на радиолюбителей удивляюсь - ставят в свои поделки китайские малогабаритные бачки типа 22 мк 16 в. по 5 руб, и не догадываются поставить такой же типономинал серии К53 ( фактически вечные ). Если брать тип К53-14 - то он максимум в пару раз дороже выйдет, зато - железка переживет создателя, даже если это школьник...
-
? RADIX50 - 06.05.2016 19:39
RE:" Макс Багаев@ - 04.05.2016 04:50
...про Verbatim":
_
По поводу перемаркировки: мне попался диск,перемаркированный "наоборот": т.е., сверху - напечатан логотип фирмы "VS"(ну,из недорогих,видимо..), а "в промежутках" картинки (да и вообще,если просто под другим углом посмотреть) - под низом гордо красуется "VERBATIM"! :-D :-D
Обычно,сколько помню, делали(подделывали),выдавая всякую "фигню" под "VERBATIM", а тут - наоборот! :-D
#
RE:"микросхемы тоже проверяли на воздействие солнца...;
некоторые буржуйские стерлись через месяц, наши РФ2 - вообще никак...":
О,даа! Сейчас еще немножко расскажу,из личного опыта.. :-D
...Приходит один знакомый "Синклерист", приносит 2 м/сх: какая-то из наших РФ2/РФ4("с окошком") и буржуйская типа 27##(2764/27128). Мол,вот,прошивку выполнили,но поторопились, надо зашить туда "бинарник" пропатченный. Ну,а чтоб перепрошить, надо,ясное дело,стереть. Ну,кладем под кварц.лампу, выдерживаем стандартный интервал, читаем на программаторе - не стерлись. Выдерживаем еще раз. Не стерлись. Вытаскиваем кварц.лампу в каптерку, включаем там "на подольше" - "нехай там воняэ!",как кто-то из коллег посоветовал.
Все равно не стерлись.Содержимое читается программатором,корректная контрольн.сумма подсчитывается.. :-D :-D
Берем какую-то дощечку,втыкаем в нее булавки(швейные,с шариком на конце),меж них пристраиваем эти обе м/сх, выставляем за окно на _прямой_ солнечный свет. ...И как-то про них забываем(занятые текущей работой),вспомнив только под конец дня(около 18:00).
Снимаем,смотрим на программаторе. ЧИТАЮТСЯ! :-D
Озадаченные заинтересованные коллеги чешут репу: "Да блин.. Весь день на солнцепеке!.. За день самому насмерть сгореть можно,а не то что микросхемы!.. :-D"(у солнца-то интенсивность больше,чем у лабораторной лампы).
Ну,в общем,ни буржуйская "27##", ни наша "РФ"-ка - так и не удалось их "обнулить".
Общими усилиями(и мыслями) сошлись на том,что "...ну,где-то там на стекле окошка чипа, - ну,мож,какой блик образовался,и недозатёрлось.."(хотя,лично проверяли, - чтоб кристалл освещался полностью,без "теней", да и окна наши отделовские на южную сторону выходили, нам солнышко весь день светит "напрямую", да и фанерка была ориентирована "на солнце",вроде бы,тоже правильно,и находилась СНАРУЖИ,т.е., на улице,на прямом солнцепеке в ясный жаркий день,когда была засуха и +38'C в тени,а на солнце - и того выше!).
Причем,про быль насчет порчи информации в аналогичных УФ-ППЗУ даже при НЕПРЯМОМ (рассеянном) дневном свете(что я чуть выше рассказывал), - оный товарищ в курсе(тоже вспомнили,поржали немного). :)
...
Вот такие вот.. микросхемы.. попались, уж не знаю,хорошо это или плохо, - но вот примерно так! :-D
-
? MM - 06.05.2016 20:36
Насчет УФ ППЗУ.
Абсолютно правильнь написал уважаемый господин RADIX50 - настоящий совок 573РФх на редкость плохо трется.
Я, когда был дефецит 1801РР1, тер 573РФ3 на 250-ватт керосинке в 1 см. от раскаленной до ~500 градусов колбе ( собственно горелке ) по нескольку часов. И ИС была примерно так в ~200 градусах по цельсию - видимо, заряд скорее стекал из-за температурной течки кремния, чем от УФ-воздействия.
Однако, КС573РФ4 полежала у меня в полуметре от лампочки ЛД-20 и за 2 месяца стерлась наполовину - некотрые проплешины достигали нескольких байт кряду. Есть мнение, что уже в 1992 г. в РФ4 ставили капиталлистический кристалл - а они там приучены следовать ТУ не только в очетах 27-му съезу КПСС, всё-таки рыночная экономика, и за гадство будут наказаны отсуствием спроса.
*
Прошлогодняя "каруселька" - полчаса при 400 ватт прямой новодкой - хер что протерлось, продал по 150 руб для коллекционров.
http://itmages.ru/image/view/3061442/30a0cd6d
*
Кстати, 564КП2 не предназначены для коммутации отрицательного напряжения - т.к. технологи не осилили процесс...
-
? a214 - 07.05.2016 02:32
... керосинка никаких УФ не излучает - мамочке в солярий отдайте,там сотрётся ...
а прибор Фотон российского производства с МЯГЧАЙШИМ на начальной границе уф стирал даже РФ1 запросто ... Про ДРЛ вообще нужно промолчать ... глаза берегите ...\
-
? Макс Багаев@ - 09.05.2016 14:20
да, для стирания УФПЗУ Фотон самый лучший вариант (причем старая модификация с широкоспректральной лампой)
ДРЛ-ка, не смотря на большую мощность стирает не лучше, а местами даже хуже, тк по видимости нужные линии спектра у нее менее мощные чем надо
-
? RADIX50 - 27.10.2016 19:42
- << Форум