k001
k001
:...

April 2032
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30

k001 [userpic]
глядя на emerge --update -avD world

Есть какое-то особое очарование в компиляции софта на каком-нибудь Pentium II 266 MHz. Видно, что оно действительно что-то делает. Видно, что configure действительно выполняет какие-то тесты, а не просто печатает строчки. Видно, что gcc -O2 оптимизирует код, а не просто строчит объектники из сишников.

Впрочем, на DX2/80 с 16 Mb памяти всё было куда как более захватывающе — уходя на ночь, я оставлял ядро компилироваться, чтобы с утра обнаружить какую-нибудь ошибку или то, что процесс всё ещё продолжается. Помню, я таким манером неделю боролся, чтобы у меня заработал CD-ROM: штатное ядро 1.0.9 поддержку IDE CD не имело (в то время, когда его выпустили, таких девайсов ещё не было, а были только Sony, Panasonic и Creative CD-ROM интерфейсы), но я был настойчив и нашёл сорцы 1.1.50, в котором IDE CD драйвер уже был. Оставалось только те сорцы скомпилять и забутить новое ядро.

Правда, программирование в кодах на БК-0010.01 было ещё интересней. Там такая удобная система команд, что их легко запомнить и писать прямо в восьмиричных кодах.

Подозреваю, что ещё более захватывающим был процесс отладки микрокода какой-нибудь Электроника-79 с пульта (цифровой дисплейчик, светодиодики, тумблеры, кнопочки).

А нонешняя-то молодёжь только и умеет GUI в IDE рисовать. Эх, чегой-то меня понесло...

Comments

Правда, программирование в кодах на БК-0010.01 было ещё интересней.

Да-да, замечательная была тема...

угумс.

015757 - лучшая программа, изобретённая прогрессивным человечеством. =)

Re: угумс.

MOV -(@PC), -(@PC), что ли? Забыл уже всё нафиг... Возможно, даже и скобки неправильно расставил.

Re: угумс.

что-то типа того, ага.
будучи помещённая в конец видеопамяти и запущеная оттуда ловко и быстро заполняла собой всю память оставляя после себя полосатый экран и зависшую БэКашку. =)

Re: угумс.

кстати наврал я. не 57, а 47

Да не умеют они GUI в IDE рисовать - говно гонят, а не продукт.

А я и сейчас вижу, что g++ -O2 оптимизирует... Вот смотришь на g++ сожравший 1.5 Gb ram и компиляющий уже 6 минут и вспоминаются PII-286. А ведь это Athlon64-3800+!

Меня гораздо больше другое огорчает: я застал компоновку и разводку печатных плат в PCad 4.5 под ДОС, на 286/1mb/40. И визуально помню, плату и схему какого размера можно было разводить с 1 мб, а сколько — с 2.
И даже моделировали в чём-то… Кажется, что-то вроде pc-spice? не помню, этого уже я по лалолетству не делал…

Однако с тех пор объём озу увеличился в 1000 раз, тактовая частота процессора — в 50–70 раз, а вот каких-то качественных скачков размеров проектируемых схем, или, скажем, рывка качества размещения элементов по платам и трассировки — не вижу.

На той же, или следующей (386dx40, 4mb ram) машине я загружал в MultiEdit все исходные тексты TurboVision, и некоторые другие проекты — после чего с большим удобством поиском находил все виды использования функций, переменных, и т.д. Ныне, в VisualStudio, это и близко не так удобно.

Все эти мегагерцы с мегабайтами сжираются на управление этими мегабайтами и мегагерцами. В полезном остатке — только мультимедия и визуальная красота игр.

Кстати о платах, мне это сейчас близко: какого размера дизайн можно было автоматически разводить на 286/1mb/40 и на скольких слоях?

Прошу прощения за слишком грубый ответ — всё же прошло около 15 лет, а мне тогда было 18…

Я размещал и разводил 2 слоя, что-то типа 20х30 см, 60 DIP корпусов — без проблем. Автоматически — не разводилась. Разводили платы для KAMAK, 2 слоя, порядка 150–200 разных корпусов — временами упираясь в какие-то лимиты, используя специально упрощённые графические примитивы для элементов. И из этого же проекта некоторые похожие платы разводили, уже добавив второй мегабайт — с одним не могли. И на этих же платах потом и в 2 мегабайта упирались — но этого я уже вовсе не помню… Кажется в итоге их разводку куда-то зааутсорсили…
Автоматические режимы для них даже не пробовали.
Но главное впечатление от автоматических режимов — они очень часть, проколупавшись сутки, оставляли 10–30 неразведённых связей, а то, что развели — так странно выглядело, что ни одну из этих плат так и не оставили.

Были какие-то аналоговые платы усилителей, плотно набитые рассыпухой — так вот платка типа 10х20 см билась в 1 мб, разводилась на 2.

Я тогда не понимаю, почему качественных скачков не произошло. Или это была шутка?

Сейчас автоматически разводят схемы на сотни тысяч и миллионы элементов. При том, что раньше не думали о том же тайминге вообще, а сейчас это проблема. И тогда не думали о том, чтобы развести с минимальным потреблением энергии, а сейчас это тоже проблема...

Вот как.
Выходит, мои мелкосерийные друзья не в теме.
То, о чём вы пишете — на PC, и по цене не выше 10000 USD?
Что это? Мои знакомые используют, вроде, какой-то виндозный OrCad. Или таки pcad? 5 или 6 летней давности.

Я не столько про разводку плат (понятно, что платы с миллионами элементов это нонсенс), сколько про проктирование чипов (на x86_64, да и i386). Но задача-то почти аналогична, только эффекты лезут всякие страшные на этих нанометрах. Цены, конечно, далеко не 10k$.

3 основных монстра этого рынка: http://www.magma-da.com/, http://www.synopsys.com/, http://www.cadence.com/.

не академик, а водопроводчик, не Нобелевкую премию, а пять рублей…
нанометры-то даа. Кстати, та же контора тогда разрабатывала какие-то микросхемы и DSP. Для этого было 2 девицы, называвшиеся «топологи», программа «Pult», и всякие автоклавы-микроскопы прикольные :)
Но я к ним не ходил.

А вот есть ли сейчас нечто программное, в чём рисуешь эдак дня за 2 схемку корпусов эдак на 500 (на 2 или 3 больших платы, скажем), ставишь на платки то, что надо разместить руками, а назавтра приходишь — а тебе комплект производственной документации?