Подскажите пожалуйста, можно ли Pascal загрузить без запуска WINDOWS? и если можно, то какую версию лучше использовать? и можно ли запустить его с флешки?

А если не Windows, то что?

Linux + School Pak для Linux, например, подойдёт?

Если действительно DOS, то всё тот же School Pak, если из него взять pak, вполне готов для настоящего DOS и отлаживался, например, на bochs.

я наверно двигаюсь задом наперёд), но что поделать если сначала всё осваиваешь через винду
наверно надо уточнить по вопросу, программа написана и отлажена в досовском окне под виндой, но проблема в следующем: возникла необходимость чтобы запустить её только в чистом dos, поскольку для программы важно чтобы она работала в реальном времени, а как оказалось, винда накладывает в ходе выполнения свои (непредсказуемые) ограничения, поскольку время в винде понятие относительное))

Может быть, у вас такая проблема только из-за модуля Crt? В оригинале там был пустой цикл со счётчиком, потом на мощных машинах из-за такого подхода деление на 0 получилось, потом эту проблему как бы «починили», но общий подход остался прежним, задержки всё так же пустым циклом делаются, а реальные интервалы времени стали меньше.

Версий модуля Crt было несколько, и та, что в School Pak, ориентируется по системным часам, не ест CPU и делает задержку без уменьшений. Программы, собранные этой версией модуля, проверялись в NTVDM тоже. Попробуйте просто пересобрать и сравнить.

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

Сейчас уже не существует старого форума wasm.ru, на котором обсуждалась тема, что DOS не является ОС реального времени. Причина - на материнской плате много устройств и периодически (несколько раз в секунду) возникают прерывания ACPI (кажется, так было написано), которые нарушают ход времени выполнения программы пользователя.

Но в плане формирования программным способом временнОй диаграммы на контактах LPT (или COM) порта, осциллограмма будет меньше искажена в DOS, чем в Windows.

Полгода-год назад на другом форуме я советовал взять другой инструмент для решения задачи. А именно, обратить внимание на ПЛК (свободно программируемые промышленные контроллеры) и ПР (программируемые реле).
ПЛК и ПР - это не Arduino и не отдельные микросхемы, а законченные изделия. Разница между ПЛК и ПР лишь в количестве входов/выходов и количеством поддерживаемых языков программирования - у ПР все проще.

Время программного цикла у ПЛК сравнительно не высоко - 5-20мс, т.е. с частотой 200-50Гц. Но больше и не требуется, т.к. предназначение ПЛК - управление через промежуточные реле (время сработки которых - 10-20мс) разными электроприводами.

У ПР не замерял, но думаю, что сопоставимо.

Причина, толкающая на отказ от DOS. Из-за проблем с драйверами к разному оборудованию, вы фактически превращаете компьютер за 1000 USD в ПЛК или ПР. В случае поломки компьютера будет трудно найти ему замену - на современных материнках нет LPT и COM. Также, оборудование, подключаемое к компьютеру будет подключено без гальванической развязки, что приведёт к быстрой, в течение года, поломке оборудования у заказчика.

А ПЛК и ПР уже предназначены для работы в неблагоприятных условиях помех и имеют индивидуальные или групповые изоляторы входов.

Примеры ПР - Siemens !Logo, ОВЕН ПР114, ОВЕН ПР200, Zelie.
Примеры ПЛК - найдёте в сети по фирмам Siemens, Omron, Beckoff, ОВЕН, Segnetic и многих других.

В том то и дело что очень даже требуется) программа не очень то похожа на модуль управления каким нибудь устройством, вернее ничего общего с ним не имеет...
но всё равно огромное Спасибо за подробный ответ! радует то что в DOS влияние на скорость выполнения программы (пока предположительно) всё же меньше... и сейчас меня интересует можно ли pascal загрузить с флешки под dos, как это раньше делалось с дискеты в 3,5 дюйма???

Насколько мне известно, BIOS/EFI умеют эмулировать флеш либо как HDD, либо как CD-ROM. Для первого сценария можно

• установить VirtualBox или bochs
• создать новый виртуальный компьютер, образ жёсткого диска не создавать
• скачать и подключить как загрузочный образ дискеты PC-DOS (моё предпочтение) или MS-DOS или DOS'овской дискеты Windows 95/98/Millenium; крайне не советую FreeDOS, там какие-то глюки, файлы пропадают, перезагрузишься в нормальный DOS — снова есть, но с ошибками в файловой системе.
• подключить в виртуальный компьютер флеш как HDD (возможно, потребуется вручную отмонтировать разделы из «Мой компьютер » Управление » Управление дисками», не отключая флешку как устройство)
• включить виртуальный компьютер
• если C: не виден, разбить этот HDD из виртуальной машины с помощью FDISK (данные потеряются).
• если C: виден, но не читается (в частности, после FDISK), отформатировать раздел C: (данные потеряются) при помощи FORMAT C:
• сделать загрузочным при помощи SYSTEM C:
• выключить виртуальный компьютер
• отключить флеш как устройство через значок в трее и подключить обратно
• дописать на флеш файлы программы
• пробовать перезагрузиться с флеш

bochs может потребоваться запускать с правами администратора, чтобы он мог получить низкоуровневый доступ к флеш.

Также полезно иметь под рукой dd для Windows, например, чтобы узнать, под каким именем нужно монтировать флеш как диск в bochs.

Интересный вопрос, с какой геометрией будет монтироваться диск BIOS'ом. Скорее всего, два из трёх параматеров максимальные, а третий определяется объёмом флеш, но это не точно. Для DOS, Windows 9x и Windows NT это критично. По крайней мере, Windows 2003 переносил с HP RAID в Xen снятым dd образом, и она не грузилась именно из-за отличий в геометрии. На загрузочных секторах пишутся не линейные смещения, как у Линукса и БСД, а трёхмерные координаты. Помог их пересчитать только TestDisk.

Для второго сценария (флеш как CD-ROM) нужно отмонтировать разделы из «Мой компьютер » Управление » Управление дисками», не отключая флешку как устройство, и записать образ ISO на флеш средствами dd.

dd — опасная штука, не зря её шутливо называют disk destroyer. На сайте советуют переименовать dd.exe в dd-removable.exe , чтобы запретить запись по ошибке в обычный жёсткий диск.

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

FreeDOS раньше загружалась с CD-ROM. Если всё прям серьёзно, то выделяйте компьютер и устанавливайте на него FreeDOS. Когда 5 лет назад FreeDOS была моей основной ОС ставил достаточно много драйверов для ускорения работы с жёсткими дисками - иначе скорость обмена снижалась в 10 раз по сравнению с Windows на этом же компьютере. Работал с USB-Flash, но скорость обмена была очень медленной.
Кроме того, для комфортной работы в DOS устанавливал и настраивал дополнительные программы.

Мой совет, если никогда не работали в DOS - не лезьте. Настройка займёт много времени, а выигрыш - будет незначительный, а главное - бесполезно потраченное время.

Если всё же будете работать в DOS - попробуйте сравнить скорости работы разных компиляторов Pascal:
- Turbo Pascal x16 (real mode)
- Borland Pascal x16 (protected mode)
- Free Pascal for DOS (real mode)
- Free Pascal for DOS (protected mode)
- Virtual Pascal for DOS (protected mode)

Больше расположен к Free Pascal из-за развитых библиотек. А там смотрите.
--------------------------------------------
По опыту знаю, что все, кто пытается ускорить выполнение программы, после DOS лезут в ассемблер. Так что вы лишь в самом начале пагубного пути.

И еще раз. Я уже предупреждал: не лезьте - потеряете время, решение нужно искать другими средствами.

Я работал только с FreeDOS 1.0 и 1.1. Для возможности кириллицы патчил ядро (не понимаю, что делал - по бумажке заменял одни файлы на другие).
Т.к. работал в чистом DOS, не в виртуальной машине, то никаких пропаданий файлов не замечал. Это нормальная ОС. Работал во FreeDOS на протяжении нескольких лет с утра до вечера.

Для русификатора ещё подбирал шрифты - т.к. большинство шрифтов рассчитаны на VGA дисплеи и на LCD смотрятся нечитабельно.

Для попытки знакомства с DOS вполне подойдёт DOSBox. Её тоже нужно настраивать, но в интернете много материалов.
Работа с DOS через VirtualBox очень неудобна - нет связи с DOS, т.е. затруднительно обмениваться файлами.

работа с жёстким диском только открыть файл вначале работы и записать в конце
на этом этапе главное максимальная синхронизация скорости обработки и реального времени
на что точно не хотелось бы тратить время так это перебирать различные варианты программ и варианты загрузок, поэтому и вопрос в этой теме, хорошо что уже появились варианты решения проблемы

А что подразумевается под «реальным временем»? По моему опыту основная проблема с программами для DOS — это то, что они приучены есть CPU в циклах, а планировщик этого не любит, он даёт большие кванты, но если этот квант полностью съесть, то потом ставит в очередь на подождать. Если отдавать процессор регулярно через прерывание IDLE (оно где-то на мультиплексе висит), то NTVDM даёт работать вполне нормально. Раз на 18 в секунду пробуждений, я думаю, можно полагаться.

Что-то цены какие-то заоблачные. У меня все пять компьютеров дома, наверное, столько не стоят в сумме на момент покупки.

Вот новый Compute Stick за 4500руб., а б/у нетбук без матрицы я брал за 2000руб. года 4 назад, сейчас, может, чуть подороже будет. Обычно б/у нетбук с матрицей раза в два дешевле нового, а без матрицы это же типа катастрофа, цена на б/у нетбук уменьшается на цену новой матрицы, и получается интересно.

Это, конечно, не относится к теме. Но новый компьютер в сборе (системник, монитор, клавиатура, мышь) всегда стоил примерно 1000 USD.

Добрый день, спасибо огромное за советы, что то я уже попробовал, что то ещё нет, но столкнулся с такой проблемой:
1. не могу в паскале создать массив более 65Кбайт... может это как то возможно побороть, может какую конкретную версию установить?
2. пишет что что в программе слишком много переменных (в программе 12 массивов по 1Мбайту, может это тоже от версии зависит?
Программа под DEPHI переделана под PASCAL. Весит примерно 40Кбайт.
Может с такими входными данными PASCAL вообще не заточен работать???

В Turbo Pascal — действительно такие ограничения. Модель программы такова, что в программе один сегмент данных на всё (в 16-разрядной программе сегмент — это максимум 64Кб) и несколько сегментов кода (то есть, разными юнитами и BINOBJ можно напихать больше, чем 64Кб). Дополнительно к этому в реальном режиме без ухищрений вроде XMS доступно для адресации только 640Кб. В защищённом режиме Turbo Pascal должно быть возможно выделить больше, чем 640Кб, если делать по несколько сегментов.


Разумно тут 32-разрядный компилятор для защищённого режима взять. Таким программам, чтобы работать в DOS, требуется окружение DPMI. Поскольку 32-разрядные компиляторы на поверку компилируют для Windows как правило, а DOS быстро ушёл, то такой DPMI, скорее всего, будет поддерживать бинарники для Windows. Например, я работал с WDOSX, а ещё есть HX DOS Extender и DosWin32.

Я бы попробовал скомбинировать Delphi или Ada с одним из них.

Возвращайтесь в Windows.

Другой вариант - 32-разрядный компилятор под DOS
- Free Pascal for DOS
- Watcom C for DOS
- DJ Delorie C for DOS (порт gcc)
Но не жалуйтесь на скорость работы - прерывания остаются в реальном режиме, а программа работает в защищённом. При возникновении аппаратного прерывания производится переключение в реальный режим, а потом - в защищённый.
В целом - программа будет шустро работать, но тогда и выгоды от миграции с Windows нет. Но тут я не на 100% уверен - посмотрю на ваши результаты.

Ещё есть смысл пересмотреть алгоритм и структуры данных.
-------------------
Пробовал HX DOS Extender в чистом FreeDOS. Запускал консольные программы с FreePascal, GUI - не получалось. А потом изменилась версия FPC и программы, скомпилированные в этой новой версии перестали запускаться под HX DOS Extender.

В Windows программа работает, но работает некорректно
добавлю некоторые пояснения: программа постоянно опрашивает буфер клавиатуры (должна опрашивать через равные минимально возможные промежутки времени), так вот под DELPHI это происходит рывками. То что я могу оценить по выходным данным девиация составляет от 10 до 20 раз, а это для конечного результата вряд ли можно назвать реальным временем. Ну хотя бы 1-2%. Что на это влияет могу только догадываться, если посмотреть диспетчер там всегда какое ни будь движение, что нибудь отключается, что нибудь включается, что нибудь контролируется...Если бы все потоки можно было замкнуть на программе, и из прерываний исключить всё кроме клавиатуры... тогда возможно и в винде можно было бы запускать программу
Очень хорошее предложение с использование ПЛК... но не в моём случае. i7-4770, 3.40х3.4 0, 32ГБ в существующем железе раскачивают программу на 1-2% от необходимого, а дальше о реальном времени вообще говорить не приходится)
Мне бы ваши знания и опыт по программированию... тогда может я что нибудь и наваял)... а так я программист почти никакой (очень узкая область задач и изучение материала только в этой узкой части, на более глубокое изучение просто физически нет времени)

С DWPL было довольно интересно. Версию Delphi не помню, это, наверное 2005-2007 ещё была. Там прямо матёрая реализация VCL. Рисуешь формочки в Delphi, пишешь обработчики. В настройках проекта задаёшь такое соответствие модулей, чтоб вместо обычных графических компоновались текстовые для ДОС, и нарисованные формочки работают в текстовом (консольном) режиме. Позиции элементов в пикселах делятся на 8 и 16, и это становится координатами в текстовом режиме. Какой-то клон Turbo Vision с API, идентичному VCL.


Ещё могу предложить такой реалистичный вариант для Turbo Pascal. Берёте драйвер RAMDISK, размещаете там все ваши массивы в виде файлов и работаете через ввод/вывод произвольного доступа (file of). Есть шанс, что издержки на RAMDISK окажутся достаточно незаметными.

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

Поэтому, думаю, что решение в пересмотре алгоритмов и структур данных. Как вариант - распараллеливание вычислений. Работа в нескольких потоках. Но тут моего опыта очень мало.

Для меня тема совсем не странная, и многое что вы мне подсказали, да и OCTAGRAM тоже, очень многое объясняет и хотя положительного результата пока нет жизненный опыт подсказывает, что раньше или позже выход найдётся, например сейчас я пытаюсь применить RamDisk (интересно что лет 20 я уже применял его для других задач) так что большое спасибо за подсказку, возможно это позволит устранить некоторые ограничения...

Можете объяснить более подробно что вы имели ввиду под:
... не решается задача управления внешним устройством?
... неготовность к реализации?
... распараллеливание вычислений?
... Работа в нескольких потоках?
... или отправить меня... к первоисточникам)

Имеются в виду многопроцессорные или многоядерные системы, где можно параллельно делать несколько вычислений и успевать то, что не успевается в одном потоке. Если вы работаете в DOS, это вам едва ли под силу. Планировщики, переключающие потоки на одном ядре, ещё можно встретить, но вот чтоб именно параллельно выполнялось — едва ли. В принципе, конечно, осуществимо. Несколько лет назад Дмитрий Константинович Завалишин написал с нуля Фантом ОС, а, значит, в том числе разобрался, как посылать межпроцессорное прерывание (IPI, Inter-Processor Interrupt), чтоб запускать потоки планировщика на других ядрах и как реализовать стандартные примитивы синхронизации, и написал в Хабрахабр.

Для параллельности на голых досках сейчас, на мой взгляд самое доступное решение — это GNAT (но архитектура ARM). Там адский рантайм становится одновременно и как бы операционной системой. Языковые возможности многозадачности полностью поддерживаются сопутствующим планировщиком, и по сравнению с Делфи на порядок удобнее даже для не сильно владеющего теорией человека.

Видел однажды, как бывший коллега в наследнике TThread понаобъявлял публичных методов и ходил в них как изнутри задачи, так и снаружи без синхронизации, и, конечно, всё это регулярно глючило. Корректно реализованные мониторы вообще очень долго не были доступны для разработчиков на Делфи (Windows Event не является корректной заменой условной переменной). Это только Gurock переписал на Delphi, а потом ещё, как в Windows Vista мониторы появились в API, это стало встроенной возможностью в Delphi (кажется, это была 2009). Соответственно, опыта корректной многозадачной разработки в Делфи-сообществе просто нет.

Адским инструментарием task/protected несколько сложнее делать ошибки. Вход/выход из секций чтения/записи, пульсации условных переменных и прочее создаются транслятором автоматически.

...самое доступное решение — это GNAT...

Сразу вопросы по модулю CRT:
как в GNAT реализуется считывание буфера клавиатуры?
и есть ли возможность использования символов кириллицы?

А это смотря какой. Если для голых досок, но с многозадачностью — тогда эту клавиатуру нужно ещё подключить суметь. Я так понимаю, там датчики всякие и порты ввода/вывода под рукой, а клавиатуру, например, через USB придётся читать.

Если GNAT для Windows, запущенный под DOS одним из расширителей, то расширитель сводит WinAPI к DOS API. Как там через несколько слоёв (в Windows даже и без эмуляции юникодный ввод/вывод весёлый) всё будет проходить, не знаю, и именно поэтому я бы взял Win32Ada и делал прямые вызовы к консольному WinAPI. А дальше ответ на ваш вопрос зависит от реализации расширителя DOS. Какие-то вроде бы умеют в Юникоде давать ответ на ReadConsoleW.

В принципе, есть возможность стандартные текстовые потоки ввода/вывода читать/писать как бинарные. Для этого берётся Ada.Text_IO.Standard_Input и подаётся на вход Ada.Text_IO.Text_Streams.Stream, а дальше с ним идёт работа как с потоком.



Есть ещё довольно старый GNAT 3.15p для DOS (не WinAPI), можно найти, если видновый на расширителях не будет работать. Но там по API я не знаю, как. По крайней мере, ассемблерным шаблоном прерывания-то можно вызывать из защищённого режима, и наверняка в библиотеке GNAT найдётся высокоуровневая обёртка для вызова прерываний. Соответственно, и опрашивать через прерывания DOS.


Ещё такой вариант. В расширителях DOS (как с эмуляцией WinAPI, так и без), я так понимаю, нет страничной адресации, и буфер клавиатуры можно читать напрямую из памяти, а он где-то в первых байтах. Тогда можно под него record объявить с его структурой, переменную объявить с pragma Import и указать адрес в физической памяти.

Какого-то единого модуля Crt для GNAT мне неизвестно. GNATCOLL.Terminal умеет цвета в консолях Windows и Linux переключать, а опросить клавиатуру — не может, там вообще нет ввода. Ближайший аналог TextTools разрабатывается, главным образом, на Linux. Если у них там действительно ncurses в основании, то гипотетически можно на Windows взять pdcurses, у которого такой же API, и тогда функцией KeyPress узнавать, нажата ли какая-то клавиша. Но понятно, что проще взять Win32Ada и делать вызовы напрямую, чем портировать TextTools.

Почитал руководство по ADA)... пока мне сложно оценить будет ли от него польза, более 400 страниц не одолеть за один вечер... и даже за 10.
отсюда вопрос могу ли я вас попросить (поскольку как я понял хорошо знаете тему) запустить на ADA кусочек программы (Pascal строк 10) связанный с опросом буфера клавиатуры и работающий в реальном времени?
Если о результате невозможно будет сказать какая программа его выводит, значит в принципе можно двигаться дальше, т.е. добавить в него кусочек кода для определения девиации времени (ещё строк 20) и если результат будет в пределах 1-2% можно пробовать перебивать весь код целиком.

Могу проверить в DOSBox расширители.


Я тут ещё повспоминал, и довспомался до прерываний.

Во-первых, есть аппаратное прерывание клавиатуры, но его нетривиально обрабатывать. В принципе, я писал обработчик на Turbo Pascal, это было нужно, чтоб одновременно нажатые клавиши в танках знать. Массив Boolean был. Но там нужно с портами ввода/вывода аккуратно работать, на прерывания маску ставить и снимать, иначе клавиатура отваливается. Из защищённого режима такое перехватить — дополнительные сложности.

А вот есть другое прерывание, которое вызывается ДОСовским обработчиком прерывания клавиатуры после трансляции кода клавиши в символ (то есть, уже русифицированный). Вот можно это прерывание перехватить, и узнавать о нажатии мгновенно.

Из защищённого режима DOS можно взаимодействовать с реальным режимом. Там в DPMI есть всякие вызовы. Есть вызов кода в реальном режиме по известному адресу. Можно, наоборот, попросить DPMI выделить в реальном режиме процедуру, вызов которой будет транслироваться в вызов процедуры в защищённом режиме. Но для прерывания это вроде бы маловато, потому что при вызове прерывания в стек кладётся не только адрес следующей инструкции после возврата, но и состояние флагов, и возврат делается инструкцией iret (Interrupt RETurn) или инструкциями popf, retf. Это решаемо, можно после выделения в реальном режиме процедуры попросить ещё DPMI выделить память в реальном режиме, и вписать туда по шаблону инструкции, которые вызовут ранее выделенную процедуру в реальном режиме. И адрес этой последней памяти записать в таблицу прерываний, сохранив прошлое значение. В прошлое значение, как я понимаю, тоже просто так перейти не получится из-за того, что прошлый обработчик будет пытаться освободить флаги со стека, а обычные процедуры так не делают. Тут тоже можно коменсировать это перемычкой в реальном режиме. И так получается, что программа защищённого режима вклинивается в цепочку обработчиков прерываний в реальном режиме.

Возможно, в DPMI уже есть поддержка замены обработчиков прерываний, и получится обойтись без перемычек.