Выложил поправленный образ. Заодно посмотрел в чем была проблема - EOT был незавершен: не хватало двух байтов с нулями.
Выложил поправленный образ. Заодно посмотрел в чем была проблема - EOT был незавершен: не хватало двух байтов с нулями.
PDP-11/83, Электроника МС0511 (УК-НЦ), DECserver 90M
Q-Bus: H9278-A, DLV11-J, DZQ11, DHV11, DELQA-M, LPV11, CQD-420/TM, DRV11
PMI: KDJ11-BF, MSV11-JE
VT220, CM7209
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
.
Появление поддержки ДИАМС в DSK-плагине позволило разобраться с исходниками ДИАМС.
В результате создан набор исходников различных вариантов ядра: DIAMS_Cores_20.11.2017, адаптированных для компиляции ядра ДИАМС в Эмуляторе RT-11 :
В результате создаётся файл: MUMPS3.CIL, который можно скопировать в системный DSK-образ ДИАМС при помощи DSK-плагина.Код:.rt11 @diams .MAC DSM11A .REN DSM11A.OBJ HEART.BIN .RUN DSMCIL .DEL HEART.BIN .
...
В набор включены следующие варианты ядра:
1. Old Core - те исходники ядра, из которых была скомпилирована первая система ДИАМС для ДВК, изменявшаяся впоследствии патчами ядра.
2. Curr Core - результат дизассемблирования текущего ядра с указанием всех мест, где код из Old Core был пропатчен, с наличием исходников обоих вариантов кода: старого ( в виде комментариев ) и нового.
3. Curr Core2 - подчищенный вариант исходников Curr Core, дающий при компиляции то же самое ядро.
4. Clean Core - Функциональный аналог Curr Core, в котором исправлены две ошибки и выброшен мёртвый код.
5. = New Core = - Вариант Clean Core с улучшенной поддержкой русского ввода с терминала.
Нет, на 85-й я хотел потестить TSX. Тот самый, руссифицированный Потёмкинам и его командой, с SL от Сторожевых и пр. Скачать лучше всего здесь
А ДИАМСа для 85-й в природе, вроде-бы, не существует. Вроде-бы, в Воронеже начали его адаптировать под 85-ю, результат частичной адаптации, т.е. со вписанным в него драйвером DW, каким-то образом попал к питерской команде, которая доделала его для ДВК, а ДИАМС для Э-85 так и не состоялся. В том же, который выложил я, нет самой главной 85-й фенечки - обслуживания 85-го дисплея. А если и сделали что-то еще в г. Воронеже, все ушло в даль светлую...
Последний раз редактировалось AFZ; 07.07.2019 в 23:06.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
"Вчера я наткнулся на формат даты MUMPS/Caché "$h", который описывается как:
Этот формат возвращает дату как количество дней с 31 декабря 1840 года, а время как количество секунд после полуночи.
Я размышлял со своим другом о том, почему они выбрали 1841 год, и предположил, что это была какая-то удобная дата (похожая на выбор Mac 1904 года), которая предшествовала дате рождения самого старого человека, которого они могли представить в системе, еще в 1960-х. ,
После обращения к Источнику истины (статья в Википедии о MUMPS) наше предположение оказалось верным. Джеймс Пойтрас объясняет, почему он выбрал эту странную дату:
Я вспомнил, как читал про старейшего (одного из старейших?) гражданина США, ветерана гражданской войны, которому на тот момент был 121 год. Поскольку я хотел иметь возможность представлять даты в юлианском формате, чтобы можно было легко вычислить возраст и иметь возможность представлять любую дату рождения в выбранном числовом диапазоне, я решил, что начало 1840-х годов будет безопасной начальной датой. Поскольку мой алгоритм наиболее логично работал, когда каждый четвертый год был високосным, за первый год был взят 1841 год. Нулевой точкой было 31 декабря 1840 года."
В принципе - можно найти какой-то неиспользуемый нулевой байт в системном блоке файловой системы и писать туда количество десятков лет смещения начальной системной даты от стандартной. Тогда новый ДИАМС можно будет использовать ещё более 1000 лет. При копировании системы можно предусмотреть изменение смещения даты с автоматической конвертацией дат копируемых файлов. При загрузке системы этот байт можно копировать в SYSTAB и использовать при расчётах даты.
В таком случае можно не запрещать запись при работе со сменными носителями с другим смещением даты, если текущая системная дата может быть представлена в варианте со смещением носителя.
Последний раз редактировалось Patron; 13.08.2020 в 16:09.
Вообще-то, дата нигде, кроме ядра, не хранится в двоичном виде - только в виде символьной строки, изображающей десятичное число. То есть, если залезть в ядро должным образом, вполне можно подправить это дело хоть до 72хх (не помню точно год, когда григорианскому календарю тоже понадобится поправка на один день). Найти (или организовать) свободное слово с фиксированным адресом и держать в нем старшие 16 битов первой части системной переменной $HOROLOG ($H), чтобы по +$H возвращалось правильное число большее, чем 65535, и весь хрен до копейки!.. Ну, и подправить системные программы ^%H и ^DAT - первую, может быть и не сильно надо править, а во вторую надо будет добавить размещение старших 16 разрядов даты.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Главная проблема - файловые даты. Там для даты и времени последней модификации файла отведено только 3 байта - два байта для даты и один байт для времени:
Но есть нулевой байт после байта длины имени файла, в котором можно хранить дополнительные биты даты.Код:Блок программных данных -------------------------------------- !Длина имени прогр.! 0 ! 0 -------------------------------------- Поле имени ! Имя программы ! <-- программы -------------------------------------- от 2 до 8 байт ! Дата и время последнего ! -------------------- ! ! ! ZSAVE ! -------------------------------------- <-- Граница слова ! Длина программы ! -------------------------------------- ! . . . ! <-- Текст программы --------------------------------------
Нашел кучку старых дискет, которые еще не выгружены. Среди них оказалось 6 дискет с BACKUP-копией моего основного рабочего ДИАМСа. Только вот беда: третья дискета не читается в самом начале (50-й блок). Я посмотрел, ничего серьезного там нет - какой-то мой исходник от давно забытого коммерческого проекта, испортился, да и хрен с ним. Только вот как скопировать эту дискету с любым произвольным содержимым вместо этого битого сектора? COPY/DEV после этого сбойного сектора вываливается, игнорируя ключик /IGN.
Изучил описание программы DUP, действительно, у нее нет ключика, позволяющего игнорировать ошибки при копировании устройства (то, что делается по COPY/DEV). ИМХО, остается искать средство, которое позволит скопировать это дело на PC. Все осложняется тем, что машинка с дисководом у меня 386-я, у остальных моих машинок нет FDC. То есть, конечно, могу еще попытаться выкопать мамашу с П-2/П-3 и что-нибудь на ней завести, но это в самом крайнем случае. Ну не писать же свою программу под RT-11, которая таки скопирует это дело, игнорируя ошибку в этом самом 50-м блоке?..
Последний раз редактировалось AFZ; 05.11.2020 в 11:40.
Кто мешает тебе выдумать порох непромокаемый? (К.Прутков, мысль № 133)
Не было идей скопировать дискету "сырьем" на устройствах вроде KryoFlux, или на Амиге? и потом уже на PC пытаться разобрать битовый поток.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)