• ? RADIX50 - 09.04.2016 13:56
  ...или это из раздела где "800К-диск в Линуксе"(с таблички на "народе.ру")? :)
  ..Да,тут есть чего обмозговать.. :)
• ? 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:04
  RE:"
  maxstudios@ - 08.04.2016 16:29
  ...заменитель ВП-014 на платке, один-в-один повторяющий её работу? Или предусмотреть два режима работы - первый тот, который был задуман под USB-хост и прочее, а второй - один-в-один замена ВП-014?":
  #
  Помнится,года уже с 2 назад(примерно), как-то спрашивал насчет этого девайса, но,т.к. "ВП014-й эмулятор" тогда еще не был доделан(шло только обсуждение возможности создания оного), то "ходили" только отрывочные сведения.
  Значит,не одному чел. в голову приходила такая идея,и в итоге все же копию многострадального чипа удалось-таки доделать(тем более,что где-то прошлой весной-летом на форуме проскакивали сообщения даже о реверс-инжиниринге кристаллов упомянутых редких м/сх)? Если так,то хорошо :)
  ...To: maxstudios:
  Позволю себе немного "присоединиться" к Вашему,так сказать,вопросу,если позволите-с :)
  Да,мне тоже приходила в голову такая идея,что, при условии,если "вскрытие" кристалла успешно получится,то, ввиду страшнейшего дефицита оных ВП'шек, - может быть,было бы разумным попытаться реализовать т.наз. "pin-2-pin" физический аппаратный своего рода "эмулятор"(хоть на куске платы,хоть на ПЛИСине в корпусе,Похожем на "оригинал" в виде QIP42, - лишь бы работало!), который можно было бы впаивать прямо в плату(или сажать на колодку) взамен оригинальной м/сх-прототипа. Тем более,что,опять же,насколько помню,про ПЛИСовский вариант "ВП1-037" такие разговоры точно были(и в ПЛИС-версии -"037"-й планировалось,вроде бы,даже исправить ошибки разработчиков оригинального чипа,сохранив функционал).
  Только в моем,так сказать,"варианте"(при обдумывании) никаких доп.ф-ций типа "USB-хвостА" не предполагалось(зачем, ведь это же просто,грубо говоря,"черный ящик", выполняющий только свою задачу коммутации сигналов: ВП1-014 - по-моему,клавиатура; ВП-037 - I/O дисплея), тем более,что при выявлении ошибок в сделанной "ПЛИСовской копии" - все равно придется прошивать новый экземпляр,взяв "чистую",новую "матрицу".
  "USB-хвост" уместен,разве что, в аппаратном эмуляторе ПЗУ типа 1801РЕ/РР## и 573РФ3 для загрузки в него других "бинарников"(и то только в случае применения на др. аппаратуре/вместо другой ПЗУшки).
  В общем случае, я предполагал, что будут реализованы именно "стандартные", "1:1" ПЛИсовские копии исходных прототипов,которые можно будет просто впаять в плату("как 1:1 замена ВП-###") и собирать/отлаживать устройство дальше.
  ...
  Кроме "ВП1-014", "-037", полагаю уместным создание "копий" таких чипов,как 1801ВП1-128, а также,возможно,нелишними были бы "ВП1-120", "ВП1-065", "-055"(магистральные приемопередатчики для сетевого обмена,если не путаю). Касательно "ВП-128" - пробегала информация о том,что была получена эл/схема кристалла,достаточно пригодная для того,чтоб "загнать" ее в ПЛИС.
  Беда только в том,что,поообщавшись с имеющимися в доступности спецами,кто практическим образом работает с этими ПЛИС, узнал о наличии некоего "побочного эффекта", проявляющегося в том,что есть не единичные случаи, когда реальная схема,"воссозданная" в ПЛИС,равно как и изначально "ПЛИС"'овское устройство, собранное(повторенное) на "дискретных" эл-тах(либо воще на натуральной "рассыпухе",без м/сх), - при всей правильности соединений элементов меж собой, - отказываются запускаться(нечто подобное говорил ранее в т.ч., и тов. KISSER).
  Не знаю,с чем это связано,но процент "незапусков" так или иначе отличен от нуля.
  ...
  RE:"USB-хост"(немного повторюсь): ну,если в использованной для повторения прототипа устр-ва ПЛИСине он изначально есть(как элемент конструкции),то он,конечно,там и останется. Хотя,для устройств с "жесткой" логикой(контроллеры клавиатуры/дисплея/памяти или I/O-каналов,а также FDD/HDD),где не требуется "на ходу" или слишком часто менять алгоритм работы, он особо и не нужен.
  В эмуляторах ПЗУ - возможно использование USB-хоста ПЛИС для смены эмулируемой "прошивки"(содержимого ПЗУ 1801РЕ##), хотя,меня лично, вполне бы устроила и "вглухую" используемая копия той же,допустим, "1801РЕ1-326" или "РЕ2-017/-018"(которая сделана без возможности изменения - что-то вроде этакого записанного CD-R или DVD-R - диска). Кстати,если в ПЛИС эмулируется перезаписываемое ПЗУ(573РФ3 или 1801РР##), то,по идее, должен поддерживаться и такой режим, когда "скопированная" ППЗУшка вставляется в программатор(БКшный или промышленный) и "прошивается" стандартным способом с его помощью,а не через USB-выход ПЛИС(т.е.,ПЛИС-носитель "вбирает" в себя информацию,получаемую с выводов того программатора ПЗУ 573РФ3 или 1801РР,которым в данный момент "шьется" "скопированная" м/сх, и,соотв-но, и БКшка,и программатор ПЗУ,в свою очередь,видят такую "микросхему-копию" как свою родную "РФ"/"РР" или "ВП", - без всяких доп.настроек и условностей). Ну,т.е.,как говорится, "черный ящик": на входе подаем один сигнал,с выхода снимаем другой, - такой,как нужно.
  ...
  Кстати,по имеющейся информации, опытная партия "ПЛИС-эмуляторов" м/сх типа "1801РЕ"/"РФ" в кол-ве нескольких штук все же была создана, и как раз,по-моему,под рук-вом упомянутого Вами тов. VSLAV'а. :)
• ? 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 НЕ является скрытым и может быть скопирован оператором ВРУЧНУЮ.
• ? RADIX50 - 09.04.2016 11:37
  ...Подробнее - см. в документации к программе FFORMAT v.2.70(2.99), - там автором про все возможные форматы дисков прекрасно разобрано.
  :)
• ? 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 - 08.04.2016 12:50
  http://megajohn.embedders.org/mjprojects/3fam_hal_ps2keyb_to_uknc/img/big/unkc_on_ibm.gif
  ...даже каким-то образом задается ремап кнопок УКНЦ на кнопки кейборды PS/2(если не путаю,вроде,на УКНЦ тоже схема соединений кнопок "пассивная"(без м/сх,обычная "сетчатая")..интересно,насколько сильно различие с клавиатурой БКшной?..).
• ? RADIX50 - 08.04.2016 12:40
  RE:"Вопрос к владельцам реальных БК..";
  "...переходник клава PS/2 - плата БК001#...":
  #
  что-то типа вот такого,как на(точнее,для) УКНЦ?
  http://megajohn.embedders.org/mjprojects/?device=uknc&f0=1&f1=1&f2=0&f3=0&f4=0&w0=1&w1=1&w2=1
  ...
  Так же,точно,аппаратный,"черный ящик",принимает "PS/2",выдает.. ("ДКОИ-8R"?).
  В указанном случае,умельцы подобрали размеры платы так,что можно установить и на шлейф,и сразу на
  сами разъемы клавиатуры внутри ЭВМ.
• ? RADIX50 - 07.04.2016 22:50
  To: TheGWBV
  RE:"MP3-декодер на БК":
  ...Одно время,когда "зацепились" за эту идею(в момент обсуждения оной),была куча вариантов и предложений, но,к сожалению,к единому мнению придти не удалось,а идея со временем как-то немного "заглохла" :)
  Один из вариантов был сделать плеер на БКшный "LPT"(он же "УП"),по-моему,как раз с Вами мы его немного пытались обсудить(но там тоже,как и в случае "шинного" декодера с подкл-ем на МПИ,требовалось аппаратное декодирование с помощью м/сх то ли "STA####", то ли "TMS####",либо какой-то другой похожей), если ничего не путаю :)
  ...И в итоге,под "шквалом" предложений/вариантов идея "завязла"(но все же так или иначе Вы убедили,приведя к выводу,что кидать байты в порт "УП" на тот декодер - не такая уж и сложная задача). :)
  Да и вообще,в общем-то,без особой разницы,какой декодер(чип,м/сх) впаян, главное,чтоб работало :)
  На том же "ZX" - и .wav,и .mp3 уже давно "синклеристы" слушают :)
• ? 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 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ский формат) можно будет делать "на лету",располагая более развитым алгоритмом(размещаемым в расширенном объеме ОЗУ), и т.д.
  Вот,на мой взгляд,примерно вроде так :)
• ? 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К, - видимо,действительно в том контроллере имелась встроенная буферизация для предотвращения "выпадения" передаваемых данных при работе в режимах "высокая плотность"?).
• ? 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"(по-моему,какой-то армянский,название на "-дзе") - да,было и такое(интересно,насколько совместим он с остальным БКшным ПО и получаемы(ми) формат(ами) дисков). :)
• ? 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 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М, вышли из положения таким способом,написав такой нестандартный драйвер :)
• ? 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 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 - 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)МБайт на БК/ДВК/УКНЦ(возможный "подвох" состоит в том,что "обычные" контроллеры при штатной тактовой частоте могут просто не обеспечивать требуемую надежность обмена данными при такой плотности записи, - т.к., как минимум,вдвое вырастает поток/объем данных,которые надо корректно пересылать туда и обратно)?
• ? RADIX50 - 06.04.2016 22:51
  to: MM
  RE:"Вопрос к владельцам реальных БК :
  ...переходник клава PS/2 - плата БК0011М... - кто-нибуть купил бы?":
  ¤
  Купил бы.
  ...Да и вообще,в пр-пе,подобная штука была бы весьма полезна в хозяйстве в комплекте БКшных "шурешек"
  (этот вопрос,насколько помню, обсуждался при встрече); а уж какой там (спец-)процессор впаян будет(быстрее БКшного или хоть лампово-релейный) - особой роли не играет(важно чтоб работало в принципе)..
• ? RADIX50 - 06.04.2016 18:58
  RE:"почем домен?
  RE:"16.03.2016 20:47
  Волька, не сдавайся!...
  На оплату домена - можем скинуться по 100 рублей! Можешь сообщить в почту номер QIWI кошелька, а мы накидаем...":не про
  ¤
  Да можно и накидать,как товарищ предлагает, я лично не против.. Думаю,что есть люди,кто и по 2,и по 3 сотни скинулся бы, - главное,чтоб зазря не пропало.
•   «   1 |  2  |

?