Программирование на УКНЦ как? [Архив] - Страница 7 - Speccy

Alex

22.12.2020, 09:18

Программа "Smirnow commander" и прочие, потому так долго экран перерисовывали, так как использовали КЦГД как терминал, единственно что грузилось - фонт. Возможно, фонт грузился и для того, чтобы КЦГД шустрее работал, не 8 пикселов ли в высоту фонт был?? ;)
Если красиво рамки рисовать, то используется VT100 мода, а там длинные ESC-последовательности :( . Тот же "Smirnow commander" в моде VT52 вполне шустро работал. Я его вспомнил, но у меня была версия под VT52.

Когда программа сидит внутри КЦГД - не надо её постоянно грузить и не надо пересылать кучу ESC-последовательностей. По этому всё сильно быстрее происходит :)

Ещё со мной автор поделился, что у него проблема была с определением завершилась ли программа на ЦП или нет. Его коммандер вылавливал точку с ВК и ПС. Но были программы, кои слали подобное :) и патченные мониторы со своим промптом....

AFZ

22.12.2020, 15:29

Если красиво рамки рисовать, то используется VT100 мода, а там длинные ESC-последовательности.Длина самой ESC-последовательности - ерунда. Тормозит сам КЦГД, особенно в режиме VT240. Полетаев рассказывал, что первоначально пытались сочинить отдельную ВП1 которая будет передавать байты параллельным кодом, потом посмотрели, что и на 56К загрузка этих двух -065-х не превышает 50%, да и плюнули на это дело...

Когда программа сидит внутри КЦГД - не надо её постоянно грузить и не надо пересылать кучу ESC-последовательностей. По этому всё сильно быстрее происходитВообще-то, как раз, это - мелочи. Загрузить этого самого командира и один раз отрисовать экран - можно и подождать. А вот когда на диске несколько тысяч файлов, а командир способен показать, максимум, 60 файлов, попробуй добраться до конца списка. Это когда на диске 100=200 файлов, еще как-то терпимо...

form

22.12.2020, 15:32

Это когда на диске 100=200 файлов, еще как-то терпимо...
А есть диски с таким количеством файлов, что команда COP *.* DDN: оборвется по ошибке :)
К примеру V5.7 source kit.

Alex

22.12.2020, 15:55

Ведь товарищ этот ушёл от PIP, свою утилиту написал... Справилась бы его утилита - не ведаю. V5.7 source kit тогда ещё не было ;)
Тормоза КЦГД в режиме VT240 - это особенность реализации. У меня не было КЦГД в режиме VT240, только VT100. В режиме VT52 КЦГД работал быстрее.
У него своя загрузка была в моде VT240 на тот момент не работавшая.

Из проблем - автор ещё жаловался, что памяти мало в КЦГД и задумывался над алгоритмами сжатия. Я ему тогда присоветовал свою простенькую утилиту вместо DIR накатать, коя бы чисто каталог как есть, физическими блоками в КЦГД отправляла для последующего разбора и отображения. Там и так сжатие хорошее, если пустых мест от удалённых файлов нет. RADIX-50 в именах и всё компактно :) Но скорее всего он это не сделал :(. Ушёл на PC.

form

22.12.2020, 16:02

Справилась бы его утилита - не ведаю. V5.7 source kit тогда ещё не было
Зависит от того как она работает.
Если просто копирует файлы - не справилась бы.
Там проблема в алгоритме заполнения сегментов - просто происходит переполнение.
Вариант копирования без ошибок - SQ/OUT:DDN :)

Alex

22.12.2020, 16:13

То есть глюк в PIP?

form

22.12.2020, 16:15

То есть глюк в PIP?
Нет.
Просто при штатном создании файлов алгоритм такой в RT-11: как заполняется половина сегмента каталога - открывается следующий и начинает заполняться он.
Если файлов очень много - наступает момент когда новый файл воткнуть некуда, хотя промежуточные сегменты заполнены только наполовину.
Приходится делать SQ и повторно копировать без перезаписи.
Это вобщем-то документировано.

Alex

22.12.2020, 16:34

Я помню, что под файл при открытии может получить либо столько места, сколько просит, либо если не ведом конечный объём - половину от наибольшей свободной области, либо вторую по размеру. Но при копировании вроде всегда конечный размер файла известен. И насколько помню, всё ложилось без зазоров. Я правда на RT-11 V5.02 в основном работал. RT-11 V5.04 у меня в конце моей работы на ДВК появилась, я с ней только опыты проводил :)
И вроде как сегменты дополнительные в каталоге приходилось создавать, так как файлов было много. Хотя скорее всего не достиг того количества файлов.
Винчестеры на моих ДВК были в 10 мегабайт.... Знаю, что были в 5 и 20 мегабайт...

form

22.12.2020, 16:49

Я помню, что под файл при открытии может получить либо столько места, сколько просит, либо если не ведом конечный объём - половину от наибольшей свободной области, либо вторую по размеру.
#0 - половина, #-1 - максимальная дырка

Еще в RMON есть смещение, отвечающее за реальный максимум.
Посмотрел в VKMON - настройку такую не сделал.
Хотя вроде собирался :)

AFZ

22.12.2020, 16:59

Это расход дискового пространства. Но, кроме того, штатный алгоритм программы USR для выделения памяти в сегментах оглавления тоже хромает. И когда файлов сильно много, спотыкается, в результате чего всю память оглавления за один проход (одну перезапись большого количества файлов) не займешь - USR не умеет сжимать оглавление. Чтобы записать стандартным образом (.ENTER - .WRITx - .CLOSE, как делает и PIP) нужно записать, сколько получится, затем сжать диск и затем продолжить запись (COP/NOREP). И, может быть, не один раз. То есть, файловая система RT-11 хорошо работает, когда диск заполнен не более, чем на 50% - и оглавление, и пространство для данных. Можно натолкать и больше, но появятся неудобства, вроде перечисленных. Диск, который не требует частых перезаписей (например, системный) можно натолкать "до упора", а вот рабочие диски лучше всего ведут себя, будучи занятыми процентов на 20-30. Хотя, опять же, многое зависит от того, какие программы работают...

Alex

22.12.2020, 17:49

Очень много файлов может быть, если LD не использовать... А так обычно туда всё убиралось :)
Базы данных обычно работали внутри одного или нескольких файлов. Возможно причина глюки USR с файловой системы.

form

22.12.2020, 17:50

Возможно причина глюки USR с файловой системы.
Тут не столько глюки сколько попытка найти компромисный вариант который пригоден при заполнении каталога в условиях когда файлы непрерывны и лежат друг за другом и никак иначе :)

Alex

22.12.2020, 17:56

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

form

22.12.2020, 18:02

Проще файл базы данных создать большой, а потом рулить в нём самому, как хочется
Была когда-то мысль сделать файловую систему частично совместимую с RT-11 с возможностью создания прерывистых файлов за счет использования дополнительных слов каталога.
Но потом обнаружилось что рядовой RT-11 при работе с таким каталогом порушит всю структуру - в процессе работы дополнительные слова могут потеряться/переместиться - проще тогда плюнуть на совместимость :)

Alex

22.12.2020, 18:30

Есть ещё один способ. В коде драйвера ставим битик, что у устройства специальная файловая структура. И все операции по работе с файлами проводит драйвер. По этому драйвера магнитных лент такие большие по размеру. Я думал в своё время прикрутить таким образом RT-11 возможность работать с FAT(с некоторыми ограничениями) но не успел :(

form

22.12.2020, 18:37

В коде драйвера ставим битик, что у устройства специальная файловая структура.
Только с таким устройством бьше ничего и нельзя сделать кроме как работать с отдельными файлами, а идея была чтобы с него можно было загрузить RT-11, а потмо перекрыть его новой системой если надо :)

Кстати, родные принтеры в RT-11 именно такие устройства - с файловой системой :)

- - - Добавлено - - -

райвера магнитных лент такие большие по размеру
При генерации предлагается выбрать вариант с файловой системой и без.
Для BUP к примеру файловая система не нужна, а использовать ленту как ANSI - расточительство.
В TSX у меня лента с файловой системой просто не влезала в рамки - пришлось урезать.
Это DHV11, зараза, громадный :)

Hunta

22.12.2020, 18:41

Alex, попробуй ответить на вопрос - кто это (расширение ФС, файловый командер, другое системное ПО) а) сможет и б) захочет сделать? ;)
Учитывая, что народ больше интересует игрушки, да и те ПИШУТ на постоянной основе сколько - два, три, четыре человека?

Alex

22.12.2020, 18:49

Ну я таковых не встречал :(
Обычный LP: - параллельный, народ с ним изгалялся как только мог ;)

Был ещё последовательный LS: там была опция поддержки протокола X-on/X-off(^S/^Q)
Хотя можно было обойтись многотерминальной поддержкой по моему мнению :)

- - - Добавлено - - -

Боюсь, что скорее всего никто... :(
Смысла малою, на текущий момент если честно. Если файлик перекинуть надо - есть HX. Хочется стабильную файловую систему - ставь RSX-11M+.
Народ не только к игрушкам интерес проявляют :)
Реверс процессоров - великое дело. Написаны эмуляторы. Сделаны системы на основе FPGA. Это очень серьёзно и есть в этом смысл.

hobot

23.12.2020, 03:00

затем сжать диск и затем продолжить запись
максимальное свободное место рекомендуется иметь в самом конце каталога,
сжимать рабочий каталог желательно (как минимум) после каждого перезаписываемого прогона,
например, скомпилировали исходник, удалили промежуточные файлы, сжали \утрамбовали, запустили текущую сборку.
Но на практике (когда УК-НЦ на самом раннем этапе комплектовались дерьмом вроде НГМД 6022) надёжность и износ носителей сильно страдает. Сейчас ИМХО всё это вообще не актуально, главное не связываться с битыми версиями мониторов и утилит про которые точно известно, что там что-то не так.

- - - Добавлено - - -

AFZ, под словами "не актуально" я подразумеваю, что А). никто сегодня никакие БД крутить на отечественных машинках и под RT-11 не будет, для написания программ любого размера и сложности без сбоев всё будет работать (проверено) и Б). сегодня мало кто использует носители, которые реально изнашиваются (ну в смысле дискет и что ещё хуже всякие MZ40,
DX, MX - и прочие тупиковые сюжеты).

- - - Добавлено - - -

А вот когда на диске несколько тысяч файлов,
да вы о чём? какие тысячи под RT-11 столько софта нет )))
Ладно допустим я и сам столкнулся с этим, но уже в процессе собирания архива,
но в целом - просто надо признать избыточность файлового менеджера в среде RT-11,
ПКМ по образу двухколоночного Нортона никаких разумных оснований для такой программы нет,
кроме стереотипа - Нортон это круто хочу как на MS-DOS )))
Что мешает с тем же успехом работать с человеческими моноэкранным софтом только в определённых задачах?
Только личная предубеждённость некоторых граждан - кои считают это "не удобным" - или они просто в голове
не могут удержать что твориться на исходном устройстве или это просто капризность )))

- - - Добавлено - - -

свою простенькую утилиту вместо DIR накатать
вы бы GUI ему ещё посоветовали бы ))) И мы бы сейчас марсианкой кликали бы окошки и система называлась бы
GUI BOXES for RSX\RT-11 и всех подобных... )))

- - - Добавлено - - -

б) захочет сделать?
вот можно попробовать прямой ответ получить (я без наездов если что!),
ув. form есть ли шанс, что ты когда нибудь проявишь повторный интерес к своей "заготовке" FC под RT-11 ?

Hunta

23.12.2020, 08:10

И мы бы сейчас марсианкой кликали бы окошки и
Оконный интерфейс (если что, оконный - не означает графически) под RSX есть

система называлась бы
И редактор, созданный на основе этого интерфейса называется MIM. Более того - он же и файловый менеджер.

hobot

23.12.2020, 09:09

И редактор, созданный на основе этого интерфейса называется MIM.
я не знал, то есть - это терминальные окошки, но там видимо совсем другая схема взаимодействий нежели в современных GUI само собой. Эх! Говорил мне form - осваивай RSX )))

form

23.12.2020, 09:11

есть ли шанс, что ты когда нибудь проявишь повторный интерес к своей "заготовке" FC под RT-11 ?
Кто знеает?
Сейчас все заготовки в 2000км от меня находятся :)

Alex

23.12.2020, 09:11

Моя идея утилитки вместо DIR была проста, Прочитать блоки каталога как есть и отправить в КЦГД. И увсё.
Ну можно ещё немного оптимизировать - пустые сектора каталога не отправлять.
Объём и скорость работы - явно быстрее штатного DIR будет.

Графический интерфейс под КЦГД? Да легко :) Ну может и не легко, но вкорячили бы... Что-то в стиле Windows 1.0 :)
В КЦГД даже мышка есть :) В реальности не было конечно, только интерфейс :( Но помечтать-то можно ;) И я программ таких не знаю, кои её использовали.
Места в памяти мало, но то, что конфигурация всегда постоянная у КЦГД задачу упрощает.

Весь прикол в том, что тогда в Windows мало кто работал, большая часть народа в DOS. Подсмотреть сильно чаще Нортона могли.
Расцвет Windows пошёл на 90-е годы начиная с версии 3.11. Когда 386 в массы пошли.
Хотя тогда Windows была далеко не единственной графической оболочкой.
Был, например, забытый GEM. Там запускалась известная Ventura.

Hunta

23.12.2020, 09:59

там видимо совсем другая схема взаимодействий
MIM вышел в свет (я познакомился с ним в 86 году) примерно на полтора-два года раньше, чем NC и многие идеи файлового менеджера в нём реализованы. Основное отличие NC - два окна и если работать с файлами - это действительно удобней, чем в MIM-е. Но MIM позиционировался в первую очередь как среда редактирования и/или разработке - и здесь он не уступает и местами превосходит NC. В своё время, когда работал на СМ1420, я познакомил несколько человек отдела (в первую очередь тех, кто занимался разработкой) с MIM-ом - результат был одинаков - практически всегда человек входил в систему, вызывал MIM и дальше выходил из него только что бы выйти из системы :)

- - - Добавлено - - -

Графический интерфейс под КЦГД? Да легко Ну может и не легко, но вкорячили бы... Что-то в стиле Windows 1.0
Сильно сомневаюсь - скорость обмена слишком маленькая

Alex

23.12.2020, 10:30

MIM под RSX-11 - ВЕЩЬ :) Мечта пользователя и администратора в действии ;)
К сожалению под RT-11 он ... :(

Вопрос стоит не в том, что медленно обмен идёт... Проблема скорее в малом объёме свободной памяти в КЦГД и в малой производительности графической системы :(. Отсутствует рисование векторов и аппаратное копирование блочной графики. :(
Но это преодолимо жёсткой экономией памяти или записи графического менеджера в ПЗУ.
На мой взгляд, тот автор вполне, с минимальными издержками, переписать свой коммандер в проводник а ля Windows ;)
Достаточно было бы немного изменить отображение на экране. А так добавить часы, блокнот и пару игрушек и вот оно ;)
Вполне мог и поддержку мыши организовать. :) Только для работы с мышью - нужна была сама мышь :(
Весь фокус для ДВК в том, что КЦГД надо рассматривать, не как чисто терминал, а как второй процессор в системе и задачи нужно правильно делить на выполняемое на ЦП и выполняемое на процессоре КЦГД. Так, чтобы минимум обмена был между ними. Это для большинства сложнее, чем писать на одном процессоре ...

Интересно, существовала ли графическая среда под P/OS??? Мыши вполне в PRO-серию вполне втыкались, даже мышь от мелкомягких ;)
Список из нескольких штук видел ...
Правда не знаю какой софт и как их пользовал. Видеоадаптер там вектора вполне рисует.

form

23.12.2020, 10:38

Интересно, существовала ли графическая среда под P/OS???
Существовала (http://pdp-11.online/~form/files/pics/pro/)

Hunta

23.12.2020, 10:45

К сожалению под RT-11 он
Под RT-11 у меня только как заготовка - в той версии, которая у меня есть. Технически, можно попробовать допилить, но много вопросов по поводу команды Выполнить - то, что в RSX решается на раз-два, в RT, в силу её однозадачности (речь про фоновое, а не оперативные задания) - требует изворотов. Хотя я и от функций редактора под RT не откажусь - часто бывает нужным по быстрому отредактировать, а имеющиеся редакторы - уровень не очень впечатляют, что бы я на них время согласился потратить. Да и привычка к действиям в MIM-е - оказывается и через десяток лет пальцами вспомнилась на раз два :)

Достаточно было бы немного изменить отображение на экране.
А теперь на вскидку вопрос - а что делать с перекрывающимися графическим окнами? А если окно пользователь схватил мышкой и тащит?

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

Кстати, с перекрытием окон в Windows всё достаточно тупо - в нужные окна посылается запрос на перерисовку. И если так же тупо в лоб делать на КЦГД - ну вы поняли, да, кто будет узким местом системы? ;)

- - - Добавлено - - -

Существовала
По картинкам больше выглядит как оконная, но совсем не факт что графическая среда. Нарисованное можно и символами (в том числе - псевдографикой) нарисовать

form

23.12.2020, 10:48

Нарисованное можно и символами (в том числе - псевдографикой) нарисовать
На прошнике это одно и то же - там все делается через видеопамять - полноценной консоли в стиле DL нету.
Есть урезанная эмуляция в maintenance mode на принтерном порту - только регистры, без прерываний :)

Hunta

23.12.2020, 10:52

На прошнике это одно и то же - там все делается через видеопамять - полноценной консоли в стиле DL нету
Я это прекрасно знаю. Но вопрос был

существовала ли графическая среда под P/OS???
А на картинках по ссылке - оконная среда без каких либо следов возможности рисования чего то графического.

form

23.12.2020, 10:54

А на картинках по ссылке - оконная среда без каких либо следов возможности рисования чего то графического.
Ну Windows 1.0 такой же был :)

Hunta

23.12.2020, 11:00

Ну Windows 1.0 такой же был
Вот прям такой, как на картинках выше?

https://ru.wikipedia.org/wiki/Windows_1.0x#/media/%D0%A4%D0%B0%D0%B9%D0%BB:Microsoft_Windows_1.0_scr eenshot.png

Или всё таки с выводом графики?

form

23.12.2020, 11:01

Вот прям такой, как на картинках выше?
Да (http://pdp-11.online/~form/files/pics/win1.gif).
DOSSHELL который позже появился был сделан в этом стиле.
Могу дистриб дать побаловаться :)

Alex

23.12.2020, 11:07

Под RT-11 у меня только как заготовка - в той версии, которая у меня есть. Технически, можно попробовать допилить, но много вопросов по поводу команды Выполнить - то, что в RSX решается на раз-два, в RT, в силу её однозадачности (речь про фоновое, а не оперативные задания) - требует изворотов. Хотя я и от функций редактора под RT не откажусь - часто бывает нужным по быстрому отредактировать, а имеющиеся редакторы - уровень не очень впечатляют, что бы я на них время согласился потратить. Да и привычка к действиям в MIM-е - оказывается и через десяток лет пальцами вспомнилась на раз два :)

А теперь на вскидку вопрос - а что делать с перекрывающимися графическим окнами? А если окно пользователь схватил мышкой и тащит?

Отрисовка векторов - это хорошо для векторной графики. А окошки - это, в первую очередь, битмап графика. И основная операция там - копирование прямоугольников - как между основной и графический памятью (и тут КЦГД просядет), так и между участками графической памяти (тут немного получше, но опять же - как быть с перекрытием окон)

Кстати, с перекрытием окон в Windows всё достаточно тупо - в нужные окна посылается запрос на перерисовку. И если так же тупо в лоб делать на КЦГД - ну вы поняли, да, кто будет узким местом системы? ;)

- - - Добавлено - - -

По картинкам больше выглядит как оконная, но совсем не факт что графическая среда. Нарисованное можно и символами (в том числе - псевдографикой) нарисовать

Насчёт МIM в RT-11, надо его либо в XM, выполнение внешних программ по образу и подобию VBGEXE... Либо в TSX-11. В мониторах без расширенной памяти, в принципе тоже можно, но будут тормоза :( В RT-11 есть возможность передать управление другой программе или командному файлу.
В TSX-11 разделяемый был редактор USED(под РАФОС-TS). Но в чистой RT-11 он успеха не снискал. Самым популярным в RT-11 был ЕDIK(мог с 8 бит кодировкой текст, рус/лат переключал по ^N без ^O) Хотя с ним тоже проблем хватало(большие файлы неудобно). Большая проблема была с русским, так чтобы большие и малые буквы были. При только больших русских и маленьких проблем было менее.

Если тащишь окно мышкой, то программа на ЦП получит информацию об этом, только тогда, когда перетаскивание завершится :) или вообще не получит ;)
Заниматься этим будет оконный менеджер на процессоре в КЦГД :)

Единственное место, на этих картинках, где я увидел графику - электронные таблицы, там графическое окно для диаграммы. Всё остальное текстовый режим. Окна делает эмулятор P/OS.

Hunta

23.12.2020, 11:09

Я показал пример вывода графики в оболочке Win 1.x. Пример вывода графики в оболочке на PRO?

- - - Добавлено - - -

DOSSHELL который позже появился
Появился где - на PC или PRO?

form

23.12.2020, 11:13

выполнение внешних программ по образу и подобию VBGEXE...
VBGEXE накладный вариант, сделан чтобы запускать изначально неприспособленные к XM программы.
Специально написанные под XM программы удобнее и экономичнее, их можно запускать параллельно BG (ну VBGEXE конечно тоже можно).

- - - Добавлено - - -

Появился где - на PC или PRO?
На PC.
Входил в комплект DOS V5.0 и позже.

- - - Добавлено - - -

Пример вывода графики в оболочке на PRO?
Это к любителям прошки.
Я его ненавистник :)

- - - Добавлено - - -

Я показал пример вывода графики в оболочке Win 1.x.
Не вижу там ничего такого чего не было бы тут (http://pdp-11.online/~form/files/pics/pro/pos-spread2.gif) например. Все то же - легко делается псевдографикой.
К слову, NU для DOSа начиная с версии 6 рисовали и посерьезнее вещи в чистой псевдографике :)

Hunta

23.12.2020, 11:18

В RT-11 есть возможность передать управление другой программе или командному файлу
Тут важно не возможность как таковая (уж это у меня проблем не вызывает), а восстановление среды MIM-а после её окончания. В том числе - редактируемого файла. То, что под RSX вообще не вызывает проблем.

Заниматься этим будет оконный менеджер на процессоре в КЦГД
Конкретный пример. У нас отрисовано на КЦГД два окна, которые по размеру - ну путь будет две трети от размера экрана. Первое под вторым - часть первого окна видна, часть скрыта под вторым. Я перетаскиваю второю - открываются новые части первого - откуда мой код будет брать содержимое открывающихся областей первого окна? Из буфера? Где этот буфер? В памяти ЦП - см про скорость обмена. В памяти КЦГД - вспоминаем, что окно размеров 800*240*1 - это примерно 23 кб (вроде не ошибся), а памяти в КЦГД (не видео) - 32 кб. И? Где будем хранить скрытое?

- - - Добавлено - - -

Входил в комплект DOS V5.0 и позже.
Речь идёт про графическую оболочку на Pro.
- - - Добавлено - - -

Это к любителям прошки.
Я его ненавистник
То есть ответа на вопрос - была ли графическая оболочка под Pro - по прежнему нет

Не вижу там ничего такого чего не было бы тут например
Часы наверху, иконки внизу - не, не видно?

form

23.12.2020, 11:22

Часы наверху, иконки внизу - не, не видно?
Иконки - даже не смешно - они точно такие же в NU и DOSSHELL которые работают в чистой текстовой моде.
А что до часов - открою по секрету - они там именно фрагментами нарисованы, а не расчитаны по формуле окружности и вырисованы точками ;)
В то время чисто графические приложения вроде граф редакторов - была привилегия доса.

Hunta

23.12.2020, 11:25

Тем не менее - графика, а не псевдографика. На картинках с Pro этого нет

- - - Добавлено - - -

они точно такие же в NU и DOSSHELL которые работают в чистой текстовой моде.
Картинку в студию

form

23.12.2020, 11:29

Тем не менее - графика, а не псевдографика. На картинках с Pro этого нет
В чем отличие "графики" нарисованной заготовленными квадратиками от точно такого же способа вывода даже голого текста в прошнике?

Hunta

23.12.2020, 11:35

Иконки внизу - тоже заготовленными квадратиками псевдосимволов?

- - - Добавлено - - -

они точно такие же в NU и DOSSHELL которые работают в чистой текстовой моде.
Картинку в студию

form

23.12.2020, 11:40

Картинку в студию
Будет под рукой дос - будут картинки.

Alex

23.12.2020, 11:42

Если хранить по тупому bit to bit Конечно памяти не хватит... Ещё там память занята под вектора и таблицей адресов строк ;(
Но если применить очумелые ручки ;)

На P/OS могло быть графическое отдельное окошко, но формировала его программа, не система .

Hunta

23.12.2020, 11:48

Но если применить очумелые ручки
Боюсь, там придётся делать очень очумелыми ручками...

На P/OS могло быть графическое отдельное окошко, но формировала его программа, не система
Учитывая, что там напрямую (или почти напрямую) проге доступна видеопамять - понятно, что программа могла хоть чёрта лысого изобразить. Но по программе-программной оболочке типа Windows - ответа так и нет.

form

23.12.2020, 11:52

Но по программе-программной оболочке типа Windows - ответа так и нет.
Сомневаюсь что там была оболочка в понимании некоего унифицированного интерфейса через который можно было универсально рисовать окошки. Скорее всего если такое есть, то реализовано через разделяемую библиотеку и регион видеопамяти, а там - каждая прога воротит сама что хочет.

Alex

23.12.2020, 13:32

Ну а для ускорения перемещения окна можно поучиться у тех же мелкомягких ;)
Там до сих пор есть галочка в разделе быстродействия что-то вроде - "перемещать окна не показывая содержимое"

Файловый менеджер по типу эксплорера нарисовать - проблем не вижу. :)
На одном процессоре это проще...
Действительно можно сделать библиотеки для таких дел. Наделать приложений.
А если это будет ещё Pro-380 на J-11 ;)

Но вопрос в том, было ли такое или нет ???
Хотя было бы прикольно типа:"MS Windows for DEC PRO" ;)

Вообще-то были X-windows для UNIX... Может быть в эту сторону порыть???
Я просто не компетентен в этом вопросе :(

Hunta

23.12.2020, 14:16

перемещать окна не показывая содержимое
Перемещать то как раз без проблем - но вот восстанавливать открывшееся...

А если это будет ещё Pro-380 на J-11
На Pro прямой доступ к видеопамяти и прилично - оперативной :)

Вообще-то были X-windows для UNIX... Может быть в эту сторону порыть???
Я просто не компетентен в этом вопросе
Тоже не скажу, хотя исходники есть. Ещё бы посмотреть на X-windows на старых компах. Оно, кстати, реализовано на принципах - клиент-серверный подход и не важно - работают ли клиентская часть и серверная на одном компе или на разных компах в сети. Да, ещё один прикол - у них реверсные понятия сервера и клиента - сервер - этот то, кто занимается отрисовкой (работает на компе пользователя), клиент - тот, кто заказывает отрисовку (и он будет работать на том компе, где запущено приложение, использующее X Windows для отрисовки графики) :)

Alex

23.12.2020, 16:01

Ну окно восстановить как - над этом и надо мозгом поработать :)
Исходные данные если сохранены, то в принципе отрисовать окно - проблем нет.
И ещё, в КЦГД видеопамяти на два экрана, на сколько я помню.
В принципе есть чересстрочный режим(тогда памяти на один экран), но у меня в таком режиме на мониторе картинка дрожала :(

form

23.12.2020, 20:20

Разбавим тему немного, а то ушла она от темы :)

Я тут упоминал про Y2K патч на лету.
Как перевезу свое барахло - может на досуге допилю, а пока немного теории о патчах налету - вдруг кому пригодится.

Идея состоит в том, чтобы как только система прочитала к примеру KMON (или его оверлей), тут же его подправить. Но в принципе данную процедуру можно применить вообще к чему угодно (предотвратить возможный SQUEEZE системного диска довольно легко - надо только следить чтобы 7 бит по смещению 300 от начала RMON был всегда установлен).

На самом деле все довольно просто: из смещения RMON+270 ($QCOMP) сохраняем старое значение в драйвере, подставляем точку входа в драйвер.
В результате по завершению любого I/O управление будет получать наш драйвер, а в @R4 при этом будет находиться адрес элемента очереди драйвера.

Как добыть из элемента очереди блок, адрес буфера, количество прочитанных слов - думаю понятно. Количество слов скорее всего не понадобится вовсе: все запуски программ/подгрузки оверлеев читают сразу все что нужно в память и мы вполне можем на это положиться.

Однако надо отсечь посторонний ввод-вывод, а это сделать тоже просто: в элементе очереди драйвера по смещению -2 находится адрес слова состояния канала (CSW). Если этот адрес совпадает с RMON+244 ($SYSCH) - мы имеем перед собой системный I/O - именно по этому каналу грузится KMON, его оверлеи и сам KMON использует этот канал.

Все что нам остается - убедиться что читается нужный блок по системному каналу, достать адрес буфера и подправить в нем содержимое, после чего отправить I/O на завершение системой (по сохраненному ранее адресу).

Определить начальный блок загруженного монитора тоже легко: достаем его имя из смещений 406/410 RMON ($MONAM), открываем файл на канале 0 (для простоты), по смещению 6 от начала RMON получаем начальный блок на системном диске.

По смещению 42 файла монитора лежит базовый адрес KMON (внутри файла).
По смещению 4736 - размер KMON (корневой сегмент)+USR+RMON.

Примерно так :)

hobot

24.12.2020, 03:49

Я тут упоминал про Y2K патч на лету.
такой драйвер не выход ИМХО:
во первых он сожрёт памяти кусок - а самое важное отличие старых мониторов от 5.7 и даже от 5.4 - это лёгкость.
Допустим мы победим на ругань по системной команде DATE, подсуним DIR нужный, а остальной софт?
Я просто к тому, что поддержка требуется целой группе приложений , то есть всему окружению - рабочая среда.
Вот к примеру ADOSSJ - ни за что не кушает утилиты PIP, DUP и даже DIR - от других систем ? Там полностью Русифицированная RT-11, но даты старше 99 не держит, или моя любимая MFP - на все даты современные пишет -??-88
Обидно!!! ))) Но сам факт описанной тобой возможности - не перестаёт быть как вполне рабочий вариант.

→ ЛAТ
RT-11SJ (S) V05.00
Bpeмя Дaтa
00:00:13 24-Нoя-2020, Bтopник

LD7>DATE
?KMON-F-Invalid date

LD7>

form

24.12.2020, 05:12

а остальной софт?
Так можно патчить на лету что угодно.
Размеры драйвера тоже могут быть маленькими (даже если ты собираешься патчить сотни программ) - можно добавить некий сваппинг.

shattered

25.04.2024, 15:19

Круто. Осталось понять, какие api у разнообразных ОС на БК :)

Да никакие :) Всё делается через Монитор (bios). EMT 20 - вывод текстовой строки, EMT 36 - чтение или запись файла, всё в таком духе. Это понимают все ОС.

насколько я понял, у ANDOS таки есть API (https://forum.maxiol.com/index.php?showtopic=5558), но чтение-запись произвольного места в файле надо лепить самому, включя обход цепочки кластеров в FAT?

gid

25.04.2024, 20:17

у ANDOS таки есть API
Как бы да, и этого зачаточного АПИ было вполне достаточно для 90% задач.

чтение-запись произвольного места в файле надо лепить самому
Верно.

включя обход цепочки кластеров в FAT
А для этого есть какое-никакое АПИ.
Если нужно, вот пример, как я это сделал 80707. Там исходник отдельно, и исходник в составе реальной проги, как пример использования. Главный недостаток - почти нет комментариев, из-за чего мне теперь даже самому непонятно, что там сделано и как работает. Потому что писалось это на самой БКшке, и у меня были проблемы со свободными дискетами. Компилировалось на ней же, а там было ещё и с ОЗУ не очень, поэтому, чем меньше комментариев, тем больше полезного кода можно было поместить в исходник.

shattered

01.05.2024, 00:54

Продолжаю изучать API на БК:

API Монитора (ROM BIOS):
БК11 похож на БК10 по номерам EMT, но способ вызова некоторых из них отличается (20, 34...)
БК11М не похож на оба, вместо EMT можно обращаться по CALL.
Управление режимами терминала (подчеркивание итп) везде разное -- в БК10 одиночные символы с кодами 2xx, в БК11 -- с кодами 0xx, в БК11М -- напоминает VT52.
Терминал БК11(м) умеет 80 символов в строке, в дополнение к 32 и 64.
Перевод строки в БК10 -- достаточно 012 (LF), в БК11(м) -- нужно 015 012 (CR LF).
Возврат в Монитор -- БК10: RTS PC, БК11: EMT 0, БК11М: EMT 1.

API оболочки ANDOS (не самой ANDOS) сделан через резервные команды 107xxx, 007xxx и 070xxx, а также IOT.

API самых ранних контроллеров альтпро (только IDE) -- https://forum.pk-fpga.ru/viewtopic.php?f=39&t=5401 и ПК БК 5/95
API = ячейки памяти 17xxxx и вызовы 1600xx

API управления памятью контроллеров альтпро -- https://forum.pk-fpga.ru/viewtopic.php?f=39&t=5410 (тексты ALTBIOS1.EDP ... ALTBIOS3.EDP) и https://forum.maxiol.com/index.php?showtopic=5563
Рассказано про RAM-BIOS; инсталлятор RAM-BIOS есть на диске Воланда (http://www.forum.pk-fpga.ru/viewtopic.php?f=23&t=1555) в M:\LastNovakDo

p.s. пожалуй, дальше в форуме БК...