Видео интервью с Надежиным - Электроника БК-0010/0011M

РУС

Видео интервью с Надежиным
[+] Старые сообщения (20)
? Voland@ - 23.01.2014 10:09
Кстати, вопрос программистам: если Алексей Надежин поделится исходниками Андос, насколько сложно допилить андос до поддержки на винте разделов увеличенного размера, хотя бы как в МК-DOS лог. диски - 32Гб ? Но только сделать полноценную партицию, которую всю можно забить файлами и папками, а не логическими дисками, как в МК-DOS (хотя, может это и не важно). Еще удлинить бы имена файлов..
Это я к тому, что предстоящую полную каталогизацию софта сейчас придется делать исключительно в формате MK-DOS, т.к. в нем и лог. диски 32мб поддерживаются и имена файлов длиннее.
? Александр...@ - 23.01.2014 10:34
Интервью было не с Савельевым, а ASP:
http://www.old-games.ru/articles/53651.html
А Савельев немного написал про себя тут:
http://bk.pictures2.com/
¤
Собрать то все в одном месте несложно. И не важно, где оно было опубликовано изначально. Главное, чтобы товарищ админ bk0010.org нам помог. ;) Ну, я тоже не против. Статья про отечественные домашние компьютеры у меня в очереди уже лет 10 стоит. :(
¤
ЗЫ: БК, конечно, никакого отношения к Ямахе не имел. И до PC XT ей тоже было очень далеко. Но это уже лирика.
? gid@ - 23.01.2014 10:48
Зависит от исходников. Для разделов увеличенного размера нужно вводить FAT16. При этом надо будет либо жёстко привязываться к СМК, либо отказаться от БК10, т.к. памяти на это потребуется много.
Например, для DX-DOS это сделать не сильно сложно, тем более что там я заметил хвосты, как будто поддержку FAT16 оттуда намеренно убрали. Я полностью дизассемблировал весь DX-DOS и начал было разбираться, но так и не разобрался до конца.
Длинные имена - штука хорошая, но сильно прожорливая до памяти. И как мне кажется, тормозить будет сильно. Чтобы отобразить длинное имя, надо либо всю директорию хранить в памяти, а на это может тупо не хватить доступного линейного пространства ОЗУ БК, либо для сборки каждого имени каждый раз перечитывать всю директорию, выискивая нужные записи с кусками имени (Это если мы говорим о формате МС-ДОС ФАТ).
? Terra - 23.01.2014 11:51
А я когда-то давно дезассемблировал ANDOS, может где-то что-то и осталось (распечатка точно была). Мне бы хотелось услышать историю про ANDOS 3.0, который с реальными подкаталогами msdos. У меня когда-то был образ, который умер вместе с HDD.
? gid@ - 23.01.2014 12:17
[ANDOS 3.0, который с реальными подкаталогами msdos]
Неужели такое действительно было? Почему же во всём интернете, ни у одного человека нету такого образа?
В DX-DOS кстати нету функционала для работы с реальными подкаталогами. Зато грамотно организована работа с файлами. Там как и в RT-11 можно открыть достаточно много файлов, лишь бы ОЗУ хватало, т.к. на каждый открытый файл требуется буфер ввода/вывода + буфер блока параметров.
Если Алексей Надежин поделится исходниками, а так же наработками, которые не увидели свет по разным причинам, то это может уменьшить количество заново изобретаемых велосипедов.
? Ammo1@ - 23.01.2014 16:12
Прошло много лет и я действительно многое забыл. Я не пиарюсь на тему БК, просто автор этого видео попросил рассказть о БКшке и показать её - пришлось в гараже откапывать.
¤
По поводу Andos 3.0. Она так и не была доделана - я что-то делать начал, но не хватило сил и усидчивости. Увы, подробности уже не помню.
¤
Исходники Andos дать могу, если смогу их найти. Осталась куча дискет и что-то есть на PC.
? RADIX50 - 23.01.2014 16:27
RE: to all, но в первую очередь, to Voland:
¤
? Voland @ - сегодня 10:09
допилить андос до поддержки на винте разделов увеличенного размера, хотя
бы как в МК-DOS лог. диски - 32Гб ? Но только сделать полноценную
...
Вот этот вопрос как-то среди форумских пытался поднимать,но он скорее
упирается даже не в каталоги MS-DOS,а в саму hardware: еще господин
Надежин в доке к ANDOS v3.30 говорил,что сам контроллер на базе чипа
"ВП1-128" поддерживает HDD максимум до 2ГБ(и то не у всех работали,были
такие сообщ-я на старых ветках форума,примерно так 2008..2005гг),как
я понимаю,чисто физически.
Меня интересует вопрос(никто так и не смог внятно сказать,но все же задам
еще раз,может,какая инфа появилась): в чем там подвох,с чем связано это
ограничение на емкость в 2ГБ(вот не понял только: на ОБЩИЙ объем всех
подключенных HDD к контроллеру,или только на каждый диск на каждом канале
(MASTER/SLAVE). Сам А.Надежин рекомендовал HDD на 40.. 120 МБ(желат-но,в
габаритах 2.5",чтоб питать его от +5V,убрать в корпус БКшки и воще о нем
забыть),и чтоб ни мегабайтом больше.
...И где ж такой диск счас найти можно,кроме музея-то?..
Почему нельзя подключать HDD хотя бы "стандартных" для (BIOS) IBM PC
объемов (до 8.3ГБ,они еще попадаются на вторичном рынке и у "барыг",а также
списываются с предприятий в рез-те апгрейда) и видеть полный его объем?
Это "глюк" программный или аппаратный?.. На IBM PC попадалась мне такая
программа "MODBIN",она путем патченья некоторых байтов в BIOS(бинарнике)
заставляла материнку видеть HDD бОльшего,чем в станд.поставке,объема(я,
напр.,на древней своей Am486DX5-133 сделал поддержку до 160ГБайт,если не
больше),и вытаскивать на экран пункты меню BIOS SETUP,которые также могли
не отображаться в заводской поставке(напр.,более гибкое меню "экономия
энергии",режимы "усыпления/просыпания" дисплея,HDD и др.подключенных уст-в,
или доп.настройки вкладки "INTEGRAL PERIPHERALS")..
Возможно ли в случае с firmware для того же "SMK-##"(или стандартного,что
"чисто-FDD" контроллера) устранить сие ограничение,идя тем же путем,как в
"MODBIN"?..
_
Тогда действительно можно было бы видеть весь объем HDD,записывая на него
каталоги/директории и любые образы дисков...
...
_
_
RE: "В DX-DOS кстати нету функционала для работы с реальными подкаталогами."
...Да и сама DXDOS- большой раритет. У кого-то есть такая,или хотя бы образ
ее дискеты?..
...Да и вообще мне непонятно: зачем было делать кальку с не самой лучшей DOS
от IBM PC(т.к. в те же времена уже были DOS от др. фирм,с куда более широкими
возм-тями,чем "M$",которая просто сделала их урезанный,по сути,вар-т,не изобретя
ничего нового: напр.,меню по F8 в MS-DOS появилось к версии 6.00,хотя в др.
дос,типа PCDOS(32-битная) это меню уже было с версии чуть не 4.##), причем это
DOS от машины совершенно другой несовместимой с "DEC" архитектурой?!..
Или планировалось запускать .EXE-файл из DX-DOS в M$-Do$ ?.. А не будет работать!
А может,запускать .EXE/.COM-файлы от IBM на DX-DOS БК-0010?.. Тоже не думаю,что
работало бы без ковыряния бинарника как минимум(по сути дела,написать ту же прог.
заново,но для БК,- что в ряде случаев и делалось,перенося игры с ZX)...
...И много ли у кого софта создано под DX-DOS?..
_
_
RE:"Кстати, вопрос программистам: ...":
...Да,к программистам UNIX,наверное... Может,пока не подклеивать DX-DOS к FAT32 IBM,
а присмотреться к POSIX?.. Она,если не путаю,как раз уже сразу 16-разрядная
(POSIX-16,есть и более современная POSIX-32),да и существовала с незапамятных времен
на ЭВМ с микро-архитектурой типа той же PDP(ОЗУ - в пределах 2сотен кБ),и позволяла
работать с имевшимися тогда носителями.
Конечно,это не FAT16,и "напрямую" MS-DOS'ом не видна,но вот большинство UNIX-подобных
систем FAT-диски могут определять,монтировать и с ними работать..
Тем более,что UNIX для "не-Интеловской" архитектуры - система,по сути дела,"родная"
(да и "Виндов" тогда еще не было в проекте).. и,наверно,неплохо продуманная(за столько
лет своего существования)..
_
_
_
To: VOLAND
Еще такая вещь(SORRY за оффтоп),раз уж прошел разговор о емкости носителей(тоже
пытался задавать в разное время на форуме,пока что народ тоже не особо в курсе).
"FDD 1.44 vs SMK-## на "БК-001#-##" ": вот в свое время,в СНГ поставлялись партии
последних XT-шек(IBM XT),комплектовавшимися FDD на 1.2/1.44МБ. Насколько понимаю,
XT-шка с тактовой частотой те же 4.7 МГц(в БК штатно - 4.5),объем бинарников
тогдашних DOSов примерно 64КБ(ненамного больше,чем у БК и ZX),- и 1.44M дискеты.
Слышал здесь на форуме,что 1.44M-диск дает больший поток данных,чем на 720K,и
проц 1801ВМ не сможет его обрабатывать на лету(захлебнется),что и является осн.
проблемой к подключению таких FDD к БК.
В чем там была хитрость на тех последних "XT-шках"(контроллеры вроде стандартные,
понимали и старые дискеты на 720К),и в чем хитрость сделать такую же штуку на БК?
...Правда,современные дискеты на 1.44 - такая бяка.. А на 720К они вроде держатся
нормально(проверял с заклейкой окна высокой плот-ти на разных дисководах)...
? RADIX50 - 23.01.2014 16:45
RE:"Длинные имена - штука хорошая, но сильно прожорливая до памяти. И как мне кажется, тормозить будет сильно. Чтобы отобразить длинное имя, надо либо всю директорию хранить в памяти, а на это может тупо не хватить доступного линейного пространства ОЗУ БК...":
...
Вот попалась мне как-то такая штука: назвается "Micro-UNIX для IBM PC". На 5-ти дискетах
дистрибутив(по 1.44М,стандартные). Ничего особенного,UNIX как UNIX...
Но! При работе инсталлятора обратил внимание на выводимые имена распаковываемых файлов.
Они были больше,чем стандарт MSDOS "8.3"(а загрузчик той "Микро-Юних" стартовал как раз
с MSDOS v6.22 или аналогичной)!.. Посмотрев в самих архивах(и распаковав каждый из них
по отдельности на диск,тогда еще,под FAT16),я увидел,что для длинных имен там применяется
особая запись,содержащая какие-то спец.символы и разрешенные в MSDOS фигурные скобки.
И при складывании частей имени файла(-ов),эти самые скобки осуществляют роль указателей,
по которым надо "сложить" имя,и при чтении файла средствами самой MSDOS имя складывается
в "полное" как бы "автоматически",без всяких там обрезаний и добавлений "~1",как это делает
наша хваленая "Виндовц". При копировании архивов или даже отдельных файлов из них
под MS-DOS(без режима "LFN",т.е.,не под DOS 7.## от "Win9X")- никакой порчи длинных имен также не происходило..
Поскольку тот "Micro-UNIX" мог работать даже на слабой "PC XT/jr" (сильно урезанная XT,в
первую очередь,с очень малым объемом ОЗУ, 56..80КБ), да еще с такими длинными именами,- то
может,попытаться реализовать сходный метод записи длинных имен и на БК?.. Тем более,что MS-DOS такие имена читает и не "портит",как свои же,но "Виндовые".
...Что-то про эти дела читал в свое время,- у виндов там немного другой метод хранения,
как было сказано,"кусков" имени...
? Voland@ - 23.01.2014 16:51
я там опечатался, имелось ввиду конечно 32 МБ, а не Гб, гигабайты для коллекции ретрософта уж точно ни к чему, он влезет на несколько логических дисков по 32Мб.
Поддержка дисков объемом больше 2Гб, по словам моего разработчика - чисто программная проблема (уровня прошивки СМК видимо), аппаратно вообще никаких проблем нет.
Про FDD 1.44 я у него как-то спрашивал, быстродействия должно хватить по его словам, там получается 32 мкс на слово, что в принципе должно быть даже с небольшим запасом, все-таки цикл там короткий.
Но отладить работу СМК с 1.44-дискетами невозможно без программиста, который бы написал тест для диагностики проблем и оперативно его бы корректировал, для продвижения по багофиксам.
? gid@ - 23.01.2014 19:53
>>? RADIX50 - сегодня 16:27
[в чем там подвох,с чем связано это ограничение на емкость в 2ГБ]
Вот в чём: товарищи из АльтПро, разработавшие свою таблицу разделов поступили недальновидно.
Описатель раздела в таблице состоит из двух слов:
слово 0: координаты начала раздела.
мл. 4 бита = номер головки
ст.11 бит = номер дорожки.
раздел начинается всегда с сектора 1.
бит 15 - признак защищённого раздела.
слово 1: длина логического диска в блоках.
Отсюда ограничения:
длина - 65536 * 512 = 32Мб макс. размер раздела.
размер - 11 бит - 2048 дорожек, 4 бита - 16 головок. 2048 * 16 * 63(стандартное кол-во секторов на дорожке) * 512 = 1008 Мб. (если секторов 64 - как раз получается 1024 Мб)
Если про бит 15 врут, и он тоже входит в номер дорожки, то ограничение увеличится до 2Гб. Я читал два варианта документации. В одной говорилось про бит 15, что если он 1 - то раздел считается защищённым, а в другой про это ничего не говорилось.Если не использовать режим CHS, а перейти к использованию 24 bit LBA, то мы упрёмся в физический предел 8Гб (8192 Мб). Использование 48 bit LBA, для преодоления этого предела скорее всего не стоит затрат.[Да и сама DXDOS- большой раритет. У кого-то есть такая,или хотя бы образ ее дискеты?]
Кому было интересно, у того есть. По сути, публичный образ этой системы - это демо версия, использовать эту систему как систему всё равно невозможно. Видимо авторы задумывали её продавать, но немного не успели по времени, популярность БК к тому времени уже прошла.
¤
[F8 в MS-DOS ... Или планировалось запускать .EXE-файл из DX-DOS в M$-Do$]
Вы смешиваете в одну кучу Операционную Систему и Файловую Систему. В общем случае эти вещи могут быть не связаны.
? anonymous - 23.01.2014 19:54
2 RADIX50
「контроллер на базе чипа "ВП1-128" поддерживает HDD максимум до 2ГБ」
1. ВП1-128 никаким образом с винчестером не связана.
2. Ограничение программное из-за способа адресации CHS и выделения недостаточного количества бит на номер головки и номер цилиндра. Там 4 бита на номер головки и 12 бит на номер цилиндра использовалось, если память не подводит.
「В чем там была хитрость на тех последних "XT-шках"」
В PC-совместимых компах обмен данными при чтении/записи гибкого диска производится с использованием контроллера DMA, который позволяет в лучшем случае передавать в каждом цикле следующий байт. В БК же процессор сам извлекает/помещает слово в регистр данных контроллера, затрачивая при этом 3 цикла - на выборку команды, на доступ к источнику данных и на доступ к приемнику данных.
? anonymous - 23.01.2014 19:57
2 gid
「Использование 48 bit LBA, для преодоления этого предела скорее всего не стоит затрат.」
В моем контроллере используется LBA32, где 28 бит на номер блока, т.е. ограничение в 128Гб.
? MM@ - 23.01.2014 20:16
Самые разнообразные предложения по винчестеру ...
Проблема - если сразу напрямую, сводится к написанию прошивки ПЗУ в адресе 160000, которая будет понимать винчестеры - размеченные и отформатированные под NTFS, и отдельные диски - это просто имена файлов по 32 метра в корневом каталоге винта, первом его разделе ( если он деленый ). Например - DECDSC00.DAT - носитель 0-го винчестера, DECDSC01.DAT - носитель 1-го винчестера и т.п.
Емкость такого раздела может быть - 250х32 метра - 8 Гбайт. Для более больших разделов целесообразно использование специального софта пользователя, работающего с диском напрямую. Почему именно 32 метра на диск - это классическое ограничение внутренней структуры ОС RT-11 - вообще оно скорее исскуственно создано при написании этой ОС - в конце 1960-х годов такой размер диска представлялся более, чем нужным. ( Ну и закладочку оформили конкретную - что бы потом героически это преодолевать
за денюшки лопухов - клиентов... ).
ИМХО - по московским расценкам такая прошивка вполне потянет на новые жигули последней модели.
В тексте такой прошивки должен быть выбор варианта расположения адресов контроллера винта - ввиду того, что расположение в варианте СМК годится только для ВМ1, ВМ2 - а вот для ВМ3 неособо - это мы скоро узнаем от уважаемого программиста из Чебоксар.
Самое оптимальное расположение - Самарский вариант + 000100 ( 8 ) ( по адресам ) - это решение всех железных проблем.
( Адреса самарского контроллера налазят на встроенный в ВМ3А диспетчер памяти ).
? Дмитрий - 23.01.2014 22:34
>> отформатированные под NTFS
Нафик этот НТФС!!!! Это такой густой лес, только этой тормозни на БК не хватало. Там памяти надо немало. Смысла - НОЛЬ.
? Voland@ - 23.01.2014 22:57
Да главное хоть слегка расширить ограничения. Ютиться по 8 символов в имени, 200 файлов/директорий в каталоге, каталог не более 800 кб (в МКДОС лог диск в зависимости от кол-ва файлов можно увеличить до 1.5-2МБ) - уже ни в какие ворота не лезет...
? gid@ - 23.01.2014 23:53
Вы опять путаете физику и логику. В прошивке по адресу 160000 должен сидеть драйвер, который обеспечивает физический обмен данными с винтом, ему похер на ваши структуры и форматы, он просто пишет и читает секторы винта по заданному номеру блока LBA и по заданному адресу ОЗУ.
А что это за данные - решает файловая система, которая пользуется этим драйвером. А как пользоваться файловой системой решает операционная система.
И это - две разные задачи, которые друг от друга почти не зависят.
? Аноним - 24.01.2014 00:42
>И это - две разные задачи, которые друг от друга почти не зависят.
Золотые слова!!!
? Voland@ - 24.01.2014 01:00
>> И это - две разные задачи, которые друг от друга почти не зависят.
Так я и не спорю, это кто-то выше спрашивал про ограничение размера винта. Понятное дело, что ФС - это чисто программная архитектура в ОС.
? Александр...@ - 24.01.2014 01:05
Ребята, давайте философские вопросы про файловые системы переместим в другой топик? ;)
? SPY@ - 24.01.2014 01:28
Здесь собеседники хотят прозрачно намекнуть человеку из кинофильма, что общественность нуждается в новенькой 326-й с драйвером винта, да еще работающим без доп. ОЗУ. - ИМХО.
? Дмитрий - 24.01.2014 10:32
Прошивку 326 по-любому надо переписывать. Предусмотреть возможность юзать LBA вместо CHS. Какой-нить бит: 0 - CHS, 1 - LBA. Главное, чтоб она могла работать с винтами больших объемов (LBA32 за глаза), а формат файловой системы - дело второе. От плавающей запятой в прошивке можно отказаться. Помнится была программа записи МБР, вроде в комплекте со служебной программой SERVICE для контроллеров АльтПро. Там при записи можно было выбрать - ставить МБР с/без "драйвера" арифметики. Я досконально не разбирался что и как там, но, вроде после загрузки МБР сначала ставился драйвер арифметики где-то по адресу доп. ОЗУ контроллера (170000-176777), а потом шла загрузка ОС. Так что можно взять этот вариант на вооружение и убрать из 326 лишнее, а освободившееся место полноценно использовать для реализации поддержки LBA.
<< Форум