Здравствуйте, IT, Вы писали:
IT>Я учился летать — это пять!
IT>Над OLE DB.
Каюсь, облажался. Меня AlexEagle в привате как раз пару часов назад разубеждал. Разубедил. А я-то грешный всю жизнь был уверен, что в конце концов все эти ADO/OLE DB/Jet/DAO банально дергают ODBC-драйвер... так дураком и помру...
Здравствуйте, LaptevVV, Вы писали:
LVV>А по поводу ввода информации в АСУ тоже могу сказать, что у нас тоже был специальный отдел, который этим занимался... Например, задача по учету готовой продукции обычно начиналась с того, что поступающую информацию набивали на перфокарты. Для контроля, естественно, набивали два разных оператора. А потом этот двойной комплект уже вводился программой на ленту и программа выбрасывала все несовпадения. Далее были корректировки — опять двойной ввод... И так до тех пор, пока, вся информация в правильном виде не попадала на ленту. И только потом начинался обсчет и вывод ведомостей.
Преимущество тройного ввода заключалось в том, что позволяло применять мажоритарное голосование при верификации данных и автоматически корректирвать без дополнительного ввода. Конечно, 100% надежности не было и здесь, но условие достаточности выполнялось.
LVV>Второй способ контроля — контрольные суммы — стал применяться. когда перфоввод заменили на ввод сразу на магнитные ленты — были такие устройства. Человек набирал так же, как на перфораторе, но запись шла прям на ленту. Контрольная сумма считалась самим устройством. А чеоловек должен был ввести посчитанную независимо для сравнения. Это тоже было еще то удовольствие. На наших советстких машинах это как-то не очень прижилось, а вот на серии СМ-1420 (pdp-11) был такой период, когда такой ввод активно использовался.
Вот уж где маразм-то. Посчитать контрольную сумму вручную — так же трудоемко, как и ввести все данные заново. Но котрольная сумма определяет лишь сам факт несовпадения, она не отвечает на вопрос "где". И надо было делать в случае, если контрольные суммы не совпадали? Выполнять ручную верификацию, после чего — подсчет контрольной суммы по-новой? Но извините! Это то же самое, что ввести данные три раза и выполнить "умную" верификацию и корректировку. Вот уж воистину, эти компьютерщики очень часто не понимают простой инженерной логики
Это навеяло мне скандал с подделкой метро-карточек в Москве. Тат было как-то все очень просто — надо было заклеить часть магнитной полосы скотчем вдоль, а когда израсходуешь — отклеить, проехаться один раз, после чего можно снова заклеивать. Проблема была в том (не знаю, как сейчас, может уже исправили), что система верификации была крайне тупой — на карте 3 независимые магнитные полосы, из которых выбиралась та, на которой максимальное количество поездок, это число декрементировалось и все три полосы прописывались заново. Если бы верификация выполнялась мажоритарно, такой фокус бы не прошел. Помню в какой-то конфе был мощный флейм по этому поводу. Народ думал, что на карточке только 2 полосы, но потом вылез один из разработчиков (вел он себя на редкость по-хамски) и объяснил, что полосы-то на самом деле 3 и работает это "вот так", после чего был уличён в полной некомпетентности.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, LaptevVV, Вы писали:
LVV>Здравствуйте, LaptevVV, Вы писали:
LVV>>У них в системе Инес-2 программа получения информации из поля Parm содержала 42 команды, а мне удалось уложиться в 42! И короче я уже больше нигде не видел. LVV>Пардон! У них было 43, а у меня — 42.
Ну что ж Вы так Я понял, что у них было 42, а у Вас — 41
... << RSDN@Home 1.1.4 beta 3 rev. 241>> ... <<Winamp is playing "Mary Black — Summer Sent You">> ...
Здравствуйте, LaptevVV, Вы писали:
LVV>Ну, а в 1981 году я перешел на другую работу и тут уже попал на дисплеи — расскажу завтра.
Так мне повезло, что я в 1981 году попал в единственную в своей жизни команду, с которой смог проработать 7 лет — это был мой рекорд! Команда целиком состояла из выпускников нашего фака ПММ — 1974, 1975 и 1976 года выпуска. Начальники были тож наши... А сам я стал маленьким начальником — сектора. В подчинении было порядка 10 сотрудников.
Машинное время мы снимали по соседству — в одном проектном институте. Но институт был уровня республиканского, поэтому там стояла ЕС 1052 (потом ЕС-1055) с безобразно большим количеством памяти — 512 КИЛОбайт. На этой памяти крутилось несколько десятков пользователей за дисплеями и еще операторы гнали пакетные задачи-рачеты (это не считая оерационной системы!). Дисплеи были зеленого цвета. Я не спец в электронике, но изображение на экране высвечивалось не по точкам, а как-бы линиями. Ну электронщики знают, как это называется.
Размер телевизора был примерно 17-19 дюймов по диагонали, но работал он только в текстовом режиме, символы были большими — порядка 25 строчек, а количество символов, естественно — 80, как на перфокарте.
Система называлась ДУВЗ — Диалоговый Удаленный Ввод Заданий. В отличие от нашего российского Примуса, с которым я был знаком только теоретически, эта являлась адаптированной версией соответствующей версии IBMовской системы, но какой — не скажу. Я тогда уже перестал следить за соответствием. Фактически мы готовили такую же колоду карт, но набивали ее на клавиатуре дисплея (не персонального компьютера — ничего кроме трубки — не было!). То есть те же карты JCL в колоде присутствовали. Затем выдавали команду на выполнение и результат получали тоже какбы в виде распечатки, но на экране. Если нужно, то запускали печать — это мы делали редко, в основном, в конце работы, чтобы иметь бумажный вариант последних изменений. Печать была в машинном зале и нам приносили распечатку, поскольку программистов в зал не пускали — мы сидели в отдельном помещении.
Естественно, для входа в систему мы вводили логин и пароль... Уже тогда.
Потом недолго была так называемая СРВ — Система Реального Времени. Тут уже был нормальный командный язык, системная подсказка на экране. Можно было вводить массу команд — то есть не надо было создавать пакет-колоду. Отдельные команды были на все: трансляцию, редактирование связей — тогда линкер назывался редактором связей и обладал мощнейшими возможностями по формированию оверлейной структуры. Он понимал собственный язык, с помощью которого задавались особенности сборки модулей. Но в простейшем случае по умолчанию, конечно создавал монолитный модуль.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Нужно сказать, что на ЕС ЭВМ была масса операционных систем! Дос — это была простая система с фиксированным числом задач и фиксированным распределением памяти. ОС MFT была значителоьно более развита с точки зрения сервиса файловой системы, но распределение памяти тож было фиксированным. Разделы назначались при генерации (сейчас это называется инсталляцией-установкой) конкретной конфигурации системы.
Генерация — потому что ось представляла собой колоссальное количество макросов. Генерация состояла в том, что создавался пакет макровызовов с конкретными параметрами макросов. Для этого на компьютере была предустановлена минимальная система с транслятором-ассемблером (макроассемблером). Процесс генерации занимал несколько часов, потом ситему проверяли на работоспособность — та еще работа... Часто оказывалось, что параметры заданы не те или не так — не стыковались у некоторых макросов сочетания... И приходилось перегенерировать систему. Поэтому в системные программисты (а они как раз и занимались такой работой) старались брать людей, уже имевших опыт
А фиксированные разделы памяти мог изменить и оператор — была у него такая команда. Каждая задача, естественно, попадала в такой раздел, размер которого был наиболее подходящь — память прописывалась в задании. Каритинку такой системы можно видеть в книге Олиферов — сетевые операционные системы. Они сдирали как раз с тех IBMовских осей.
На смену ей довольно быстро пришла OC MVT — MultyVariableTask — мультипрограммирование с переменным числом задач. И тут уже была классика — загрузчик запрашивал память у оси и загружал туда задачу.
Кстати, сама IBM/360-370 была машина очень даже ничего! Там была встроенная десятичная арифметика, и двоичная, и плавающая... Только память была устроена как "старшие разяды по младшему адресу"... И это казалось естественным — я потом долго не мог привыкнуть на СМ (pdp-11) к адресации "младшие разряды по младшему адресу". Система прерываний была прообраз нанешней с вектрами, но векторов было всего 6 (кажется) и никаких стеков. Вектор был не вектор, а PSW — Processor Status Word размером в 64 бита. И там была вся информация о состоянии процессора — вместе с адресом текущей команды (кажется 24 бита, поскольку до гигабайтов тогда не додумались еще). РОНы, естественно, отдельно. И это действительно были Регистры ОБЩЕГО назначения, а не так как в Интеле — каждый специализировнный.
Было 6 "старых" PSW и 6 "новых" PSW. И одно — текущее. При возникновении прерывания текущее сохранялось в "старом", а в текущее попадало "новое". Естественно, первое, что делал обработчик — сохранял "старое" гденить у себя так, чтобы потом можно было открыть прерывания и обрабатывать вложенные. Стека — не было! Во всяком случае, реализованного в составе процессора.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, AndrewVK, Вы писали:
AVK> Но с пересечением процессорами некоторой черты (где то 300-500МГц) они перестали быть узким местом. Для современных настольных систем производительность процессора на многих задачах сверхизбыточна. И даже если мы напишем софт по старинке — с морем оптимизаций и хардкода, ничерта это не даст в потребительском плане.
Конечно, "сетевые черви" вообще без оптимизации написать можно.. но САПР или КАД средних размеров, например... можно, но зачем нужен такой большой и страшный тормоз?
AVK> Вот JIT и GC как раз и утилизируют эту лишнюю процессорную мощность... Я еще не видел ни одного юзверя, который бы мне так вот заявил — задолбало уже своей высокой скоростью современное ваше ПО, надыть что-то с этим делать уже , конгресс собирать...., например
Позвольте, уважаемый, поставьте себе какой-нибудь дурацкий ВинБар, чтобы он Вам показывал на Вашем ПК загрузку процессора, и посмотрите, ресурс это или нет... когда я, например, матерюсь на какое-нибудь монстроидальное приложение, он (индикатор) показывает максимум, почему-то
хотя все мегасовременные платформы, это конечно хорошо и правильно — должны же зарабатывать деньги с++ и асм программеры кот. пишут все эти гипер системы, продавая их сиШарперам
AVK>Еще один момент — этот процесс практически непрерывен, пока непрерывно увеличение мощностей компьютерных железок. Неделю назад забыли про прямое программирование котроллеров, позавчера про прерывания, вчера про ассемблер, сегодня про рукописную графику, звук, завтра забудем про управление ресурсами, сетевые протоколы. А взамен получаем GC, JIT, интеллектуальные ФС, паттерны, широкое использование метапрограммирования, Software Factories, громадные стандартные библиотеки, слоднейшие IDE и много другого.
тут самая классная фраза — "забудем про управление ресурсами" а что в вашем понимании ресурс?
ага, как же. У меня есть некоторые хорошие знакомые ребята, целые комьюнити, которые считают, что самый мега-супер-современный язык — это асм.. и пишут на нем разный софт, есс-но
Здравствуйте, LaptevVV, Вы писали:
LVV> Я не спец в электронике, но изображение на экране высвечивалось не по точкам, а как-бы линиями. Ну электронщики знают, как это называется.
Это называется монохромный монитор. Для получения монохромного изображения нет необходимости в теневой маске, поэтому никаких точек у такого монитора нет. А линии есть . Потому что развертка нужна вне зависимости от наличия теневой маски.
LVV>Размер телевизора был примерно 17-19 дюймов по диагонали, но работал он только в текстовом режиме, символы были большими — порядка 25 строчек, а количество символов, естественно — 80, как на перфокарте.
ИМХО ты ошибаешься. Я видел сии дивайсы. Мониторы там конечно были огромные, но вот видимая часть хорошо если 14" была.
LVV>В отличие от нашего российского Примуса, с которым я был знаком только теоретически
А вот я как раз Примус даже немного ковырял. Но нам повезло — у нас все таки компы были профильными по специальности и с примуса нас очень быстро пересадили на намного более крутые дивайсы под названием Мазовия (вроде как болгарского производства). Сии дивайсы имели унутре русский 8086 (КР1810ВМ86), 2 5.25 дисковода половинной высоты и винт на 5МБ, тож болгарского производства, а понаруже 12" зелененький монитор. По сравнению с ЕС-184х эта была весьма неплохая машина. Более того, их удалось потом проапгрейдить до 286 и 40МБ IDE винта стандартной комплектухой.
Здравствуйте, Ligen, Вы писали:
L> L>Конечно, "сетевые черви" вообще без оптимизации написать можно.. но САПР или КАД средних размеров, например... можно, но зачем нужен такой большой и страшный тормоз?
Во как — раз GC так сразу большой и страшный тормоз. Видимо зря я так много писал. Я то все это писал в надежде обосновать что, что применение современных технологий с оверхедом по какому то одному ресурсу отнюдь не означает что в итоге система целиком будет работать медленнее. Ладно, расскажу о еще одном примере, по моему даже в каких то учебниках он есть, практически классика.
Итак — есть у нас некий сервер. Функционал у него такой — клиент к нему обращается первый раз, модифицирует состояние на сервере, потом еще раз модифицирует. Ну и в итоге через какое то, довольно продолжительное время отключается. Стандартный вобщем то сценарий. Пишем программу — состояние между вызовами храним в памяти, прикручиваем механику управления жизнью сессии (стандартно, по таймауту с последнего обращения). Пусть даже, для контраста, мы написали собственный менеджер состояний, который работает с ними неимоверно быстро, писан на ассемблере, да еще и ввиде драйвера, чтобы не было тормозов на пересечении колец защиты. Запускаем. Работает.
Но клиентов становится больше. Отлично, берем 2килобакса (условно) — докупаем память, ставим два процессора. Эффект есть, работает.
Но клиентов становится больше. Берем 10 килобаксов — покупаем память, четырехпроцессорную маму с процессорами. Эффект конечно есть, но не то чтобы очень. Потому как 4х-процессорные системы на общей шине уже половину вычислительных ресурсов тратят на войну на этой самой шине, память свыше 4Гиг напрямую не адресуется, а через PAT тормозит.
А клиентов тем временем ... правильно, становится больше. Ну и что дальше — тратить уже сотни килобаксов на мейнфрейм с продвинутой архитектурой в надежде получить прирост хотя бы на 10%?
Это очень характерный пример того как эффективный код при том является плохо масштабируемым.
А знаешь какие стандартные решения проблемы? Их в общем то два (больше конечно, но эти самые простые).
1) Не храним состояние на сервере. На первый взгляд полный бред. В самом медленном вроде бы месте в системе — канале от юзера до сервера, мы вдруг резко, на несколько порядков, увеличиваем оверхед. А на практике сняв нагрузку с памяти мы избавились от узкого горлышка в системе, а увеличение мощностей каналов на сервере уже дается значительно дешевле.
2) Отказываемся от хранения состояния в памяти и сбрасываем его в БД. Еще веселее — доступ к диску на несколько порядков медленнее, чем к памяти, тем более через наш супердрайвер. Но в итоге картинка та же самая — дисковая подсистема апгрейдится сравнительно легко и в итоге за те же деньги мы получаем большую производительность (естественно для огромного количества пользователей, для небольшого их количества новый вариант несопоставимо мделеннее).
Вот такой вот парадокс. То же самое и с GC и JIT. Далеко не факт что узким местом в системе является процессор и вполне возможно что их применение в итоге общую производительность увеличит. А может и уменьшит. Все зависит от задачи.
AVK>> Вот JIT и GC как раз и утилизируют эту лишнюю процессорную мощность... L> Я еще не видел ни одного юзверя, который бы мне так вот заявил — задолбало уже своей высокой скоростью современное ваше ПО, надыть что-то с этим делать уже , конгресс собирать...., например
Не понял что то твоей иронии. Я ж не говорил что лишняя оптимизация вредит пользователю. Она вредит производителю софта.
L>Позвольте, уважаемый, поставьте себе какой-нибудь дурацкий ВинБар,
Зачем? У меня вон янус стоит с тем самым JIT и GC. Уж чего чего, а в процессор он точно не упирается.
L> чтобы он Вам показывал на Вашем ПК загрузку процессора
А нафига мне эта загрузка процессора?
L>, и посмотрите, ресурс это или нет... когда я, например, матерюсь на какое-нибудь монстроидальное приложение, он (индикатор) показывает максимум, почему-то
Ну матерись, если тебе так легче. А я нет. Если уж совсем криво написано я просто понижаю приоритет задачи. И все. Ну может заплачу лишних 10 копеек за свет.
L>хотя все мегасовременные платформы, это конечно хорошо и правильно — должны же зарабатывать деньги с++ и асм программеры кот. пишут все эти гипер системы, продавая их сиШарперам
Опять не понял иронии. Что "с++ и асм программеры" продают "сиШарперам"?
L>тут самая классная фраза — "забудем про управление ресурсами" а что в вашем понимании ресурс?
Ресурс Память, диск, сетевые соединения etc.
L>ага, как же. У меня есть некоторые хорошие знакомые ребята, целые комьюнити, которые считают, что самый мега-супер-современный язык — это асм.. и пишут на нем разный софт, есс-но
Здравствуйте, AndrewVK, Вы писали:
LVV>> Я не спец в электронике, но изображение на экране высвечивалось не по точкам, а как-бы линиями. Ну электронщики знают, как это называется.
AVK>Это называется монохромный монитор. Для получения монохромного изображения нет необходимости в теневой маске, поэтому никаких точек у такого монитора нет. А линии есть . Потому что развертка нужна вне зависимости от наличия теневой маски.
Нет, это было еще до растровых дисплеев, ты наверное их просто не застал. Это были так называемые "Дисплеи с произвольным сканированием луча (каллиграфические или векторные дисплеи)". http://ermak.cs.nstu.ru/kg_rivs/kg01.htm#tth_sEc0.8
Развертка там конечно же была, но не "пилообразная", как на всех современных ЭЛТ, а произвольная. Соответственно, изображение было чисто векторным, регенерируемым в соответствии с "дисплейным файлом". Дисплейный файл — это набор команд, типа MoveTo/LineTo.
У нас такие стояли на ЕС-1022, но очень старые, там было всего 80x16 знакомест. Очень забавно выглядели символы на этом дисплее — линии очень ровные и красивые, но сами символы — кривоватые, поскольку было весьма непросто обеспечить хорошую точность состыковки линий. Там даже не было ЦДА (цифровой дифференциальный анализатор) — они появились потом, на графических дисплеях с запоминающей трубкой. А прорисовка линий выполнялась при помощи чисто аналоговых интеграторов на операционных усилителях. Мгновенная позиция луча определяется током в отклоняющих катушках ЭЛТ. Ток определяется напряжением на выходе интегратора. На вход интегратора подается нужное напряжение, определяющее скорость нарастания напряжения на выходе, и, соответственно, скорость нарастания тока в отклоняющей катушке. Вот у нас луч уже двигается с определенной скоростью по X. По Y — все то же самое, управляемое другой цепью. Вот у нас луч уже чертит отрезок по люминофору в нужном направлении. Чтобы все это было видно, дисплейный процессор должен циклически сканировать буфер с командами и постоянно рисовать по одному и тому же месту. Так что развертка была, но совсем не похожая на растровую, с модуляцией яркости.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, McSeem2, Вы писали:
MS>Нет, это было еще до растровых дисплеев, ты наверное их просто не застал. Это были так называемые "Дисплеи с произвольным сканированием луча (каллиграфические или векторные дисплеи)". MS>http://ermak.cs.nstu.ru/kg_rivs/kg01.htm#tth_sEc0.8 MS>Развертка там конечно же была, но не "пилообразная", как на всех современных ЭЛТ, а произвольная. Соответственно, изображение было чисто векторным, регенерируемым в соответствии с "дисплейным файлом". Дисплейный файл — это набор команд, типа MoveTo/LineTo.
MS>У нас такие стояли на ЕС-1022, но очень старые, там было всего 80x16 знакомест. Очень забавно выглядели символы на этом дисплее — линии очень ровные и красивые, но сами символы — кривоватые, поскольку было весьма непросто обеспечить хорошую точность состыковки линий.
Да, именно такие!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, SchweinDeBurg, Вы писали:
SDB>Впрочем, довольно лирики! — потому как, не ради словесного самолюбования затеял я этот пост. Заранее приношу покаянные извинения за то, что он несет на себе довольно заметный отпечаток автобиографичности — но так уж получилось...
Фух, наконец-то дочитал. Ну вы и нафлудили
Интересный пост, прикольное обсуждение, правда, почему-то съехавшее на тему "Я стар, я очень стар, Я — СУПЕР-СТАР!!!"
Всплакнул даже при упоминании 21-го прерывания. А когда дочитал до "Turbo Vision", так вообще, пошёл налил себе стакан водки и вот так прямо без закуски...
И тем не менее... Хотя я тоже отношусь к поколению, которое программировало скальпелем на перфокартах и пишу код уже столько лет, сколько хватит трём программерам вне категорий, но хныканья вашего, господа, не разделяю и по своей первой оконной библиотеке не тоскую. И даже не собираюсь. Не дождётесь! Старому хламу место на помойке, в крайнем случае на чердаке, вместе с доморощенными графическими библиотеками, 2-х килобайтными экзешниками и прочими фортранами, MFC'ями и COM'ами. Не скрою, было, я тоже горевал по всему этому, но в какое-то время научился делать генеральную уборку в своей голове, вытряхивать оттуда пыль, выскабливать по углам паутину и освобождать место для нового. Я даже уже перестал бояться становиться на старт вместе с молодыми, зная, что они неизбежно вырвуться вперёд и помчаться быстрей меня к финишу. Перестал бояться, потому что знаю, что всё равно приду первым, ну как минимум одним из первых, т.к. они будут бежать напролом, а я знаю где срезать углы А потом... опять генеральная уборка, на старт и всё сначала. Такова наша програмистская селяви.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Если нам не помогут, то мы тоже никого не пощадим.
Ну вот...
Работали мы с Ленинградом — было несколько договоров... Один из договоров наши мужики реализовывали на PL-1, но не просто а со встроенным Лиспом... Сначала лисповские операторы обрабатывались препроцессором, но к концу договора все это реализовали в виде отдельной библиотеки с динамическим выделением памяти... Естественно, все это задавалось линкеру для сборки...
А потом мы резко перешли на pdp-11.
Причем надо было писать типовую реализацию бортовой системы реального времени. Машины еще не было, аппаратуры еще не было... А мы уже писали...
После ЕС ЭВМ архитектура pdp-11 производила, конечно, странное впечатление. Но чем больше мы в нее врубались, тем более стройной и последовательной она нам казалась...
Двухадресная система команд, 8 регистров общего назначения, причем в это число входил и указатель стека и IP, который назывался Program Counter. 12 методов адресации, в том числе автоинкремент регистров... Никаких исключений среди РОНов не было, можно было в команде явным образом использовать и SP и PC с любыми допустимыми режимами адресации... Сочетания режимов адресации — тоже какие угодно... Один аргумент мог быть, например, в памяти, а другой — стек... Или оба в памяти...Плавающая арифметика имела свои регистры — сейчас не помню сколько.
Особенно интересно была устроена память... Вначале память имера только 64К байтов... Но в старших моделях памяти было уже 256К... Самое интересное, что машина была 16-ти разрядной, и виртуальный адрес был МЕНЬШЕ реального, который был 18 разрядов — естественно, существовалааппаратура отображения...Это единственный компьютер, который мне попался с такой особенностью... В остальных всегда виртуальный был больше реального... Байты уже были "по младшему адресу — сладшие разряды"...
Система прерывания — уже векторная, Интел потом слизал с нее свою таблицу вектров прерываний реального режима...
Но самое интересное — это, конечно, система ввода-вывода! Такой мне не попадалось больше нигде! Каждое устройство имело рчяд регистров, совершенно типичных, например, регистр состояния и управления, регистр данных... Самое интересное. что эти регистры имели реальные адреса на адресной шине... Таким образхом не было нужды в отдельных командах ввода-вывода... Ввод вывод выполнялся обычной командой пересылки mov! А если нужно было установить или проверить биты, то это можно было сделать логическими командами or и and. Только в командах нужно было использовать абсолютную адресацию для адресов регистров...
Это была ПЕСНЯ!!!!!!
Для реализации оси, которую мы писали, естественно, на ассемблере, была придумана целая технология... Сначала на СМ-1420 писалась программа с абсолютным режимом адресации... Результат трансляции помещался на гибкий диск... Затем гибкий диск переносился на (почти) персональный ВУМС (прообраз ДВК), где загружался в память... Затем переходили в аппаратный режим работы, в котором был встроенный отладчик программ — то, что у микрософта потом было в виде debug сделано. Функциональность была достаточно хорошая, поэтому отлаживали программу в восьмеричных кодах... Представляете, как я тогда знал расположение всех разрядов любой команды! После отладки по отдельному проводу "сливали" исправленный код в целевой компьютер с такой же архитектурой, но имевший заводской номер 1 (!!!!!!), потом номер 2 — до третьего мы так и не добрались...
И проверяли уже там...
Нам пришлось кроме классических частей оси полностью писать всю систему ввода-вывода, поскольку ВСЕ устройства были нашими доморощщенными — разрабатывала та же ленинградская контора...
Дотчики были дискретные и Аналоговые — естественно, через АЦП... Клавиатуры не было — был специальный пульт с кнопками, каждая из которых вызывала прерывание... Из устройств вывода было оригинальное устройство бегущая строка...Как в рекламе сейчас делают... Или в кассах где-нить...Был довольно хороший телетайп, который был и устройством печати... Но самым замечательным был дисплей! Он хоть и не был цветным, но дисплей IBM PC ему в подметки не годился! 1. на экране одновременно совмещались 3 поля — одно текстовое и два графических. В памяти дисплея можно было прошить до 128 константных слайдов... Таким образом, на экран одновременно можно было выводить и статический текстовый слайд, статический графический слайд, и изменяемую графическую информацию... Дисплей имел систему команд, поэтому слайды выводились одной командой... Вы же помните. что регистры устройства — это адреса памяти!
В общем, как только нам в работу поступил этот дисплей — мы на нем стали отдлаживать прерывания от таймера...Выводили просто на экран, как в электронных часах... Мужики смеялись: Будильник за 7 миллионов рублей...
Продолжим попозже...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>Особенно интересно была устроена память... Вначале память имера только 64К байтов... Но в старших моделях памяти было уже 256К... Самое интересное, что машина была 16-ти разрядной, и виртуальный адрес был МЕНЬШЕ реального, который был 18 разрядов — естественно, существовалааппаратура отображения...Это единственный компьютер, который мне попался с такой особенностью...
А что тут особенного? Совершенно стандартное решение. Есть даже на современных х86, называется РАТ.
LVV>Но самое интересное — это, конечно, система ввода-вывода! Такой мне не попадалось больше нигде! Каждое устройство имело рчяд регистров, совершенно типичных, например, регистр состояния и управления, регистр данных... Самое интересное. что эти регистры имели реальные адреса на адресной шине... Таким образхом не было нужды в отдельных командах ввода-вывода... Ввод вывод выполнялся обычной командой пересылки mov! А если нужно было установить или проверить биты, то это можно было сделать логическими командами or и and. Только в командах нужно было использовать абсолютную адресацию для адресов регистров...
Собственно на х86 такое тоже можно сделать. Видеокарты к примеру так и работают с самого начала. Просто отдельная шина для портов на х86 позволила кардинально упростить аппаратуру — ISA это фактически набор проводов и ничего более. Для подключения к ней достаточно 12-тиразрядного дешивратора и регистра-защелки на данные. Для дековской же архитектуры уже была нужна довольно сложная логика.
IT>И тем не менее... Хотя я тоже отношусь к поколению, которое программировало скальпелем на перфокартах и пишу код уже столько лет, сколько хватит трём программерам вне категорий, но хныканья вашего, господа, не разделяю и по своей первой оконной библиотеке не тоскую. И даже не собираюсь. Не дождётесь! Старому хламу место на помойке, в крайнем случае на чердаке, вместе с доморощенными графическими библиотеками, 2-х килобайтными экзешниками и прочими фортранами, MFC'ями и COM'ами. Не скрою, было, я тоже горевал по всему этому, но в какое-то время научился делать генеральную уборку в своей голове, вытряхивать оттуда пыль, выскабливать по углам паутину и освобождать место для нового. Я даже уже перестал бояться становиться на старт вместе с молодыми, зная, что они неизбежно вырвуться вперёд и помчаться быстрей меня к финишу. Перестал бояться, потому что знаю, что всё равно приду первым, ну как минимум одним из первых, т.к. они будут бежать напролом, а я знаю где срезать углы А потом... опять генеральная уборка, на старт и всё сначала. Такова наша програмистская селяви.
Полностью согласен.
Я конечно скальпелем перфокарты не пробивал, но начинал с программирования под Z80 и I8080. При написании компьютерных игр (общая обработка объектов, событийная модель, алгоритмы сжатия и обработки графики (на лету!!!), ИИ) особенно когда в распоряжении 32-40 кб ОЗУ и максимум 3.5 Khz, то это оставляет несгладимый отпечаток, зато позволяет на лету решать многокритериальные задачи, которые "новому поколению" далеко не под силу.
Кстати сейчас я себя не чувстую сильно скованным при использовании таких технологий как .NET или Java, они мне сильно экономят время и позволяют понимать мой код, даже многими начинающими.
Конечно бывает настольгия, иногда про нее хочется поговорить, но реальная польза от этого -> min.
Здравствуйте, Mamut, Вы писали:
M>>>Можно последующие части называть "Часть-1", "Часть-2" и т.д., а то я их нахожу с трудом — в основном, по большому количеству проставленных оценок LVV>>Хорошо. Вечером продолжу — это будет уже часть 4?
M>Точно, четвертая:
M>Часть Первая
Здравствуйте, dmz, Вы писали:
dmz>А совершенно гениальная по графике Another World — 640x480x16, но как это выглядело...
Ууууххх! Да, клевая игрулина была, че не говори. Ваще последнее время ловлю себя на мысли, что раньше игрухи какие-то более захватывающие были — щазз уже не то... И при том умудрялись же впихивать в такие убогие ящики, что щас просто аж страшно становится. Наверное если бы удалось дать тем разработчикам в какой-нить компании игрульной сегодняшние машины они бы за пояс всех заткнули. "Да, были люди в наше время — не то что нынешнее племя. Богатыри не вы..."
Здравствуйте, Glоbus, Вы писали:
G>Здравствуйте, dmz, Вы писали:
dmz>>А совершенно гениальная по графике Another World — 640x480x16, но как это выглядело...
G>Ууууххх! Да, клевая игрулина была, че не говори. Ваще последнее время ловлю себя на мысли, что раньше игрухи какие-то более захватывающие были — щазз уже не то...
А первая формула-1!!!!!! 640*480, а как ехала, блин!!!!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Glоbus, Вы писали: G>Ууууххх! Да, клевая игрулина была, че не говори. Ваще последнее время ловлю себя на мысли, что раньше игрухи какие-то более захватывающие были — щазз уже не то... И при том умудрялись же впихивать в такие убогие ящики, что щас просто аж страшно становится. Наверное если бы удалось дать тем разработчикам в какой-нить компании игрульной сегодняшние машины они бы за пояс всех заткнули. "Да, были люди в наше время — не то что нынешнее племя. Богатыри не вы..."
Ну, некоторым дали. Вот, к примеру, была такая компания, iD Software. Или там Sierra Online. Как тебе результат?
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Если нам не помогут, то мы тоже никого не пощадим.
Меня AlexEagle в привате как раз пару часов назад разубеждал. Разубедил. А я-то грешный всю жизнь был уверен, что в конце концов все эти ADO/OLE DB/Jet/DAO банально дергают ODBC-драйвер... так дураком и помру... 
можно, но зачем нужен такой большой и страшный тормоз?
