Вывалиться-то еще одно.
Вот увидеть этот самый код — это была задача, да 8)
Тут-то и вступали в дело поки и пееки 8)
А насчет «все кому не лень» — у нас в городе хрен достать было эту заветную книжечку, которая «вечная жизнь в 600 играх».
А из других манов по спектруму была только заводская «инструкция по эксплуатации» с описанием встроенного васика.
А у меня и бип был беепом 8)))
И только Истинные Гуру знали, что если для draw задать угол эдак в 10000, то получится красивая анимация вращающегося «колесика» 8)
Ну и совсем уж немногие умели в Диззи-2 сделать бесконечные жизни(там по дефолту одна всего 8)
Поглядел все 4 части статьи — спасибо, очень познавательно.
Рекомендую, кстати, посмотреть еще вот эту игрушку.
Как лично мне кажется — шедевр.
А может проглядел, и она уже есть? 8)
>Это не противоречит ни одной моей фразе, сказанной выше.
Ну, например, он не совсем «поверх» DOS 8)
Да и речь вроде шла на основе DOS'а а не спецсофте — в самом начале ветки я и писал, что спецжелезо и спецсофт требуются для Hard real-time.
Кроме того, я не спец в архитектуре x86, вполне возможно, что и там есть затыки.
>Это уже другой вопрос, не связанный с «можно ли для DOS сделать realtime-приложение»
Не забывайте, что речь началась с вашего вопроса «для чего это нужно». Я объяснил, что soft real-time системы можно строить и на бытовых осях, при определенном подходе.
Ну чего вы реально под DOS навертите(при разумных затратах), если, например, вам обрабатывать надо гигабайты данных в час, где-то их складировать, куда-то их пересылатьи т.п.? Десятком/сотней станков порулить — это одно, а вот тысячей управляемых источников данных?
>Ниже некуда.
А драйвера? А обработчики прерываний?
Дискуссия, по-моему, переходит в затяжную. Если у вас есть аккаунт в Wave-предлагаю обсудить там. Если нет, могу прислать инвайт — пишите почту в личку.
Во-первых, RTKernel по сути практически заменяет DOS(чего разработчики и не отрицают, допуская установку на комп вообще без оси).
Во-вторых, я же вроде изначально говорил о том, что реальная жизнь вносит коррективы. RTKernel, например, сам по себе стоит 1000 евро. А где вы найдете под него разработчика, если речь не про Москву? Сколько такой разработчик запросит денег? А как вы будете поддерживать свой продукт? А если требуется возможность багфикса через интернет?
В-третьих, даже с RTKernel вы получаете soft real-time, а никак не hard real-time. Т.е. от простой программы под Windows оно будет отличаться только тем, что тайминги будут намного(но все же не бесконечно много) надежнее. Гарантии все равно не будет.
>для управление производственной линией под DOS/4GW
DOS тоже отвечает не всем требованям стандартов Real-time ОС. Геморы с драйверами, отсутствие многозадачности, как следствие — отсутствие вменяемого IPC.
Ну, архитектуру мудрил не я. Разработчикам далеко не всегда дают требуемые сроки и возможность делать «как надо бы по-хорошему», вы не знали? 8)
Я еще раз говорю — вы слишком привязаны к теории. В жизни оно по-разному складывается.
>В чем проблема? Запросто!
AVR-ка, мигающая светодиодами? 8))
Проблем разных много, их сложно охватить в рамках дискуссии в комментариях, да и не силен я в матчасти.
Многовато вопросов задаете, мы уже в сторону ушли 8)
Отвечаю: до индикации время измеряется другой софтиной — эмулятором индикатора, где записываются временные метки значений. Потом достаточно сравнить их с теми, что приходят со счетчика. Ну а время синхронизируется с GPS-приемником.
Неточностей в связи со всем этим — море. Когда я ковырялся с GPS, вскрылись такие бездны «гуляния» системного таймера виндов, что хватались за голову — для обычного процесса там и речи нет даже о точности более чем в 0.1 с. При помощи таких вот статей все эти неточности можно несколько уменьшить. И иногда и это «несколько» может хорошо выручить — будь подобная(только более развернутая и с рассмотрением других вариантов) статья у меня под рукой пару-тройку лет назад — здорово бы сэкономил свое время. Умный, как известно, предпочитает учиться на чужих ошибках.
Real-time систему не на спецжелезе со спецосью не построишь, это факт. Но далеко не всегда требуется настоящий real-time.
1. Ну, БД бывают разные. В данном случае, их несколько, но в данном случае важна лишь одна — ин-мемори, без транзакций. Часть данных являются «высокоприоритетными» — при заполнении их определенными значениями, срабатывают определенные алгоритмы обратной связи(грубо говоря — скакнул ток — сработала защита).
2. Странно, да. Но при сертификации этот фактор не учитывают. Есть отраслевые требования, задокументированные приказом таким-то, хотите получить сертификат — демонстрируйте соответствие.
Или просто не умеете пользоваться мышкой в паре с клавиатурой 8)
Козырнейшие девастаторы и соник-танки, кстати.
Движок, если не ошибаюсь, от C&C
Ну и ролики прикольные там были.
Вот увидеть этот самый код — это была задача, да 8)
Тут-то и вступали в дело поки и пееки 8)
А насчет «все кому не лень» — у нас в городе хрен достать было эту заветную книжечку, которая «вечная жизнь в 600 играх».
А из других манов по спектруму была только заводская «инструкция по эксплуатации» с описанием встроенного васика.
И только Истинные Гуру знали, что если для draw задать угол эдак в 10000, то получится красивая анимация вращающегося «колесика» 8)
Ну и совсем уж немногие умели в Диззи-2 сделать бесконечные жизни(там по дефолту одна всего 8)
А еще «драв», «поке» и «пеек» 8)
Рекомендую, кстати, посмотреть еще вот эту игрушку.
Как лично мне кажется — шедевр.
А может проглядел, и она уже есть? 8)
Ну, например, он не совсем «поверх» DOS 8)
Да и речь вроде шла на основе DOS'а а не спецсофте — в самом начале ветки я и писал, что спецжелезо и спецсофт требуются для Hard real-time.
Кроме того, я не спец в архитектуре x86, вполне возможно, что и там есть затыки.
>Это уже другой вопрос, не связанный с «можно ли для DOS сделать realtime-приложение»
Не забывайте, что речь началась с вашего вопроса «для чего это нужно». Я объяснил, что soft real-time системы можно строить и на бытовых осях, при определенном подходе.
Ну чего вы реально под DOS навертите(при разумных затратах), если, например, вам обрабатывать надо гигабайты данных в час, где-то их складировать, куда-то их пересылатьи т.п.? Десятком/сотней станков порулить — это одно, а вот тысячей управляемых источников данных?
>Ниже некуда.
А драйвера? А обработчики прерываний?
Дискуссия, по-моему, переходит в затяжную. Если у вас есть аккаунт в Wave-предлагаю обсудить там. Если нет, могу прислать инвайт — пишите почту в личку.
Во-вторых, я же вроде изначально говорил о том, что реальная жизнь вносит коррективы. RTKernel, например, сам по себе стоит 1000 евро. А где вы найдете под него разработчика, если речь не про Москву? Сколько такой разработчик запросит денег? А как вы будете поддерживать свой продукт? А если требуется возможность багфикса через интернет?
В-третьих, даже с RTKernel вы получаете soft real-time, а никак не hard real-time. Т.е. от простой программы под Windows оно будет отличаться только тем, что тайминги будут намного(но все же не бесконечно много) надежнее. Гарантии все равно не будет.
С вопросами веры — это к батюшкам в церковь 8)
А если, например, возникнет прерывание?
Или CLI и побежали? Далеко не убежите 8)
Я сам писал — чувствуете разницу?
>для управление производственной линией под DOS/4GW
DOS тоже отвечает не всем требованям стандартов Real-time ОС. Геморы с драйверами, отсутствие многозадачности, как следствие — отсутствие вменяемого IPC.
Я еще раз говорю — вы слишком привязаны к теории. В жизни оно по-разному складывается.
>В чем проблема? Запросто!
AVR-ка, мигающая светодиодами? 8))
Проблем разных много, их сложно охватить в рамках дискуссии в комментариях, да и не силен я в матчасти.
Отвечаю: до индикации время измеряется другой софтиной — эмулятором индикатора, где записываются временные метки значений. Потом достаточно сравнить их с теми, что приходят со счетчика. Ну а время синхронизируется с GPS-приемником.
Неточностей в связи со всем этим — море. Когда я ковырялся с GPS, вскрылись такие бездны «гуляния» системного таймера виндов, что хватались за голову — для обычного процесса там и речи нет даже о точности более чем в 0.1 с. При помощи таких вот статей все эти неточности можно несколько уменьшить. И иногда и это «несколько» может хорошо выручить — будь подобная(только более развернутая и с рассмотрением других вариантов) статья у меня под рукой пару-тройку лет назад — здорово бы сэкономил свое время. Умный, как известно, предпочитает учиться на чужих ошибках.
Real-time систему не на спецжелезе со спецосью не построишь, это факт. Но далеко не всегда требуется настоящий real-time.
2. Странно, да. Но при сертификации этот фактор не учитывают. Есть отраслевые требования, задокументированные приказом таким-то, хотите получить сертификат — демонстрируйте соответствие.