Вид для печати
Вы, видимо, понимаете программирование как кодирование на определённом языке, тогда как я смотрю на это шире. Обучающимся нужно прививать алгоритмическое мышление и системный подход. В этом свете фраза "засирать мозги Паскалем" для меня звучит как "дать обучающемуся стабильную хорошую базу для алгоритмирования, притом чистую и не перегруженную". Помните как изобретали разные Кумиры и Рапиры? Вот примерно для того же. А потом человек после небольшого изучения тонкостей синтаксиса легко овладеет любым средством.Цитата:
Сообщение от AFZ
Что же до того, что везде доминирует Си. Ну как сказать. Пока что как бы да, да и то везде это громко сказано. Даже в плане натива его уже потесняет Rust и, отчасти, Go. Другие языки, работающие через LLVM.
Я нашёл своё решение в виде Ofront+: синтаксис Оберона, трансляция в Си. Дёшево и сердито.
я потому и задал вопрос специалистам - "подскажите какие именно задачи удобнее/эффективнее решать на паскале сейчас ? те где он лучше других ЯП ?"Цитата:
Сообщение от AFZ
но так и не получил ответа.
видимо реально нет смысла на него тратить время.
на андроидах есть выбор - С++ (Android NDK) или Java (Android SDK) (баловался простенькими приложениями)Цитата:
Сообщение от Titus
на айфонах вроде тоже можно на С++, тк это тоже linux по-сути, но вопрос не изучал
собственно ожидаемо. с другой стороны надо понимать что Паскаль это язык высокого уровня со всеми вытекающими.Цитата:
Сообщение от MM
- - - Добавлено - - -
ну так можно сделать это сразу на C++ или Java (которая в чем-то является потомком Оберона)Цитата:
Сообщение от Oleg N. Cher
программирование не должно быть абстрактным программированием ради красивой программы/структуры/концепции, оно должно решать задачи.
надо понимать что Rust потенциально конкурирует с C++ а не с чистым Си.Цитата:
Что же до того, что везде доминирует Си. Ну как сказать. Пока что как бы да, да и то везде это громко сказано. Даже в плане натива его уже потесняет Rust и, отчасти, Go. Другие языки, работающие через LLVM.
про "потесняет"
https://habr.com/ru/post/309968/
https://eax.me/cpp-will-never-die/
итд
иначе говоря он еще немного поживет но перспективы не радуют.
Go - проприетарный язык, который будет жить пока его прокачивает гугл.
те использовать его стратегически опасно.
а чистый Си остается для быстродействующих задач.
В чистом виде подход конъюнктурщика: "а что я буду иметь с этого сейчас?". SuperMax, такие люди, как Вы, губят планету ради получения максимальной прибыли сегодня. А я думаю про отдалённые перспективы, во что надо инвестировать свои силы, чтобы получить достойный инструмент, за который не будет стыдно.
Да, сейчас Паскаль в самой интересной своей инкарнации - Free Pascal - отстаёт от разных прочих средств. Там сравнительно небольшая команда. Но всё-таки.
Си остаётся опасным языком, полным хаков. И сложность его растёт с появлением новых редакций.
- - - Добавлено - - -
И давайте прекратим спор, мы из разных миров. Это как сытый голодного не поймёт.
а давайте без хамства и грязных инсинуаций ? оскорбления собеседника не делают Вам чести.Цитата:
Сообщение от Oleg N. Cher
и если уж на самом говорить о спасении планеты, то программы на более высокоуровневом языке потребляют больше ресурсов и является злом в чистом виде, ибо требует гигабайтов оперативной памяти там, где задача на чистом СИ обойдется мегабайтами, не говоря о потребление процессорных ресурсов.
Одни люди выбирают адекватный инструмент под задачу. Другие любимым инструментом решают "любую" задачу.
совершенно верно!Цитата:
Сообщение от yu.zxpk
не надо бояться изучать новые системы и языки
ибо язык это инструмент (всего лишь, а не предмет поклонения) со своими особенностями и предназначением
Зачем хамство. Вы же выразили сами свою точку зрения, а я Вам в ответ свою. Просто обменялись видением вопроса.
Вот именно. Значит нам нужен ЯВУ, который берёт из Си самое лучшее, но при этом позволяет избежать большинства его недостатков. Ибо Си архаичен, а люди любят решать задачи быстро, и пофиг на ресурсы железа.Цитата:
Сообщение от SuperMax
Или вот, допустим, выкатывают разработчики нового супер-Андроида новый язык, на котором предлагается всё писать под него. Язык этот ничем не примечательный, но позволяет очень круто дёргать фишки этого самого супер-Андроида. Сообщество получает плюс один язык, на котором обязательно будут писать. Вот так и плодится современный треш. Потом вокруг него образуется движняк, начинают на нём обучать, постепенно вылизывают и делают из него что-то более или менее юзабельное. Но этого всего могло бы и не быть на самом деле. Если язык ничем особо не хорош, просто делает получше что-то одно, то имеет ли он право на жизнь?
Впрочем, я вижу точку зрения: "я начинал на Васике, потом кодил на Си и Яве. Значит Васик, Си и Ява подойдут всем". И понятно, что в этой схеме Паскаля нет и быть не может. А вот я начинал с асма, а Паскаль мне нравился на всех платформах, начиная со Спека и УКНЦ.
- - - Добавлено - - -
Кстати, программа на чистом Си, занимающая мегабайты, может упасть из-за утечек памяти или обращения по неверно инициализированному указателю. И убить людей, например. Или чего-то взорвать. А на более тяжёлом, но более безопасном языке - нет. Так что тут не так всё однозначно, как Вы пытаетесь показать.
я не являюсь сторонником/или противником явы, я просто умею работать и с этим инструментом тоже.Цитата:
Сообщение от Oleg N. Cher
это рынок.Цитата:
Или вот, допустим, выкатывают разработчики нового супер-Андроида новый язык, на котором предлагается всё писать под него. Язык этот ничем не примечательный, но позволяет очень круто дёргать фишки этого самого супер-Андроида. Сообщество получает плюс один язык, на котором обязательно будут писать. Вот так и плодится современный треш. Потом вокруг него образуется движняк, начинают на нём обучать, постепенно вылизывают и делают из него что-то более или менее юзабельное. Но этого всего могло бы и не быть на самом деле. Если язык ничем особо не хорош, просто делает получше что-то одно, то имеет ли он право на жизнь?
есть задача - разработка мобильного приложения
и тут выигрывает тот кто решит эту задачу за меньшие время/деньги
я в свое время очень полюбил Clarion, ибо он позволял решать теже задачи, что решали люди на FoxPro, но значительно быстрее, функциональнее и качественнее - те мои программы летали даже на 286х (!)
а для моего магазина хватало 386й SX, причем количество наименований товара превышало 10тыс (1С на таком количестве на такой же машине очень жестко тупила). ну и поддержка сети появилась раньше.
так и сейчас - "надо быстро" и тут придется делать на яве и свифте
а потом, когда приложение "взлетит" будут деньги сделать тоже самое но более качественно.
я же просил - не надо инсинуацийЦитата:
Впрочем, я вижу точку зрения: "я начинал на Васике, потом кодил на Си и Яве. Значит Васик, Си и Ява подойдут всем". И понятно, что в этой схеме Паскаля нет и быть не может. А вот я начинал с асма, а Паскаль мне нравился на всех платформах, начиная со Спека и УКНЦ.
и если уж говорить о моем стеке, то он сейчас
C / C++ начиная от PDP11 кончая Linux-ом и микроконтроллерами
Java
Oracle SQL / Oracle Java / Oracle PL/SQL
PHP
Javascript
Verilog HDL
HTML /CSS/HTML5
а вообще опыт шире
Basic
Focal
ассемблер PDP11
ассемблер х86
ассемблер C51
ассемблер Atmel 8bit
Pascal / Delphi
Fortran
всякие скриптовые языки
Clarion начиная CPD кончая 10-кой
FoxPro /Visual FoxPro
MSSQL SQL/T-SQL
ЯП тут совсем не причем - речь идет о кривости рук программиста, я к тому, что надо выпрямлять руки, а не пенять на инструмент. те же утечки памяти или прочее это кривые руки в чистом виде.Цитата:
Кстати, программа на чистом Си, занимающая мегабайты, может упасть из-за утечек памяти или обращения по неверно инициализированному указателю. И убить людей, например. Или чего-то взорвать. А на более тяжёлом, но более безопасном языке - нет. Так что тут не так всё однозначно, как Вы пытаетесь показать.
и языки с автоматизированными сборщиками мусора не застрахованы от утечек.
Ну, мой опыт говорит, что есть языки, которые позволяют делать меньше ошибок, чем другие прочие языки.
Ваш стек не включает Паскаля, а значит у Вас не может к нему быть добрых чувств. Мы тут все собрались из ностальгии по старому, часто первому компьютеру. Такая же привязка идёт и к языку программирования.
Что до "рыночек всё порешает, надо бабло делать" - тут, как говорится, рыночек решает, каким странам умереть. Или те, кто за этим рыночком стоят и за ниточки дёргают. Ваше дело насколько Вы сможете приспособиться. Я лично жду, когда эта система мировой финансово-кредитной кабалы рухнет. И продолжаю оберонить, паскалить просто потому, что мне это нравится.
А как же функциональные языки? Ведь учится программировать нужно начинать именно с фунциональной парадигмы, дабы сходу не извратить мышление всякими ООП и прочим :v2_dizzy_punk:
К тому же, хотя бы даже Haskell - используют в проде. Не говоря уже о Clojure(Lisp) и прочих.
Функциональные языки по-прежнему имеют очень небольшую применимость, так что не соглашусь.
Но расширять кругозор конечно не помешает. Haskell в проде? Не слышал. Erlang в проде ещё куда ни шло. Ну немного Clojure. Наверное.
Просто это за пределами круга интересов. Haskell - Biocad я их запомнил просто потому что у меня их мерч на работе лежит. Примеров хватает, стоит лишь побывать на конференции или митапах по функциональному программированию. Мнение точно изменится.Цитата:
Сообщение от Oleg N. Cher
Сам же в прод на Elixir писал.
Эта ситуация не исключена и в "безопасных языках", к примеру для систем реального времени слишком поздно вычисленный результат является бесполезным, поскольку окружающая ситуация могла очень сильно измениться и запоздалая реакция уже не будет правильной. Тут проблемы могут быть не только со сборщиком мусора, есть много задач которые решаются итеративно, и если для некоторого сочетания параметров задача будет решаться существенно дольше чем обычно, медленный но безопасный язык может стать очень опасным.Цитата:
Сообщение от Oleg N. Cher
Угу. Вирт сочинил свой Паскаль именно для обучения. И все эти разговоры о базе для алгоритмирования и пр. - это мнение Вирта, и его последователей. А вот Кнут для первичного обучения сочинил свою ЭВМ "MIX" и начинал обучать студентов с программирования в кодах и на асме. Можно, конечно поспорить, кто круче: Вирт или Кнут, но должен заметить, что подход Кнута, скажем так, реальнее. Студент сразу понимает, что компьютер исполняет достаточно мелкие операции с ограниченным набором объектов, что какое-то серьезное действие требует большого количества этих элементарных операций, и, учитывая, что всё в этой модели конечное, нельзя безрассудно накручивать и код, и память, и пр.. Подход Вирта наоборот, все скрывает за абстракцией и потом, когда вдруг находится что-то невыполнимое в рамках этой абстракции и возникает необходимость перейти на уровень асма, многие студенты банально впадают в ступор...Цитата:
Сообщение от Oleg N. Cher
Да-да. Только вот есть еще обыкновенная лень. Выучил студент Паскаль, и хватит. А потом сочинил он какую-то программу, потом утратил к ней интерес, выложил ее в открытый доступ и забыл. Кто-то ее находит, но под современными виндами она не идет. Надо бы подправить, а она на давно забытом диалекте Паскаля, которого под современные винды тоже нет...Цитата:
Сообщение от Oleg N. Cher
А чем это принципиально отличается от того, что старая программа на давно забытом диалекте Турбо Си, которого под современные винды тоже нет?
Но вообще обвинять Вирта в том, что он обучает не на асме, а "сочинил Паскаль" и бедные ленивые студенты оболванены и не могут перейти на уровень асма - это смешно. Поглядите на другие сочинённые языки - C#, Java, это их в большей степени касается.
- - - Добавлено - - -
Как показала практика Оберона - между словами "медленный" и "безопасный" не надо ставить знак равенства. Бывает и иначе.Цитата:
Сообщение от blackmirror
Здесь вопрос в том, насколько дорого будут стоить абстракции, которые считаются крутыми и современными, что современный прогер не будет рассматривать средство без оных. Вот они стоят всё дороже.
Кстати, Паскаль- и Оберон-языки как раз очень близки к железу, притом к разному. Им обычно не требуется ВМ или интерпретация.
- - - Добавлено - - -
Коллеги, давайте ближе к теме. Почему наше с Хоботом желание покодить на Паскале вызывает столько обсуждения о том, кто какие языки предпочитает? Какая здесь связь? Ну хочется нам так, и что?
Вот и чудно. Поделитесь, пожалуйста, с нами опытом использования Си для PDP-11. Мне действительно интересно какие есть компиляторы и как их использовать.Цитата:
Сообщение от SuperMax
В эмуле Патрона я не смог запустить Си, который прислал мне Хобот. Там требуется назначить диск C, но я не разобрался как это сделать одним вызовом с компилятором. Поделитесь как это надо делать правильно?
Читать (Ctrl+F "assign hd1: c:"):
https://www.phantom.sannata.org/viewtopic.php?t=31098
То есть, мне нужно из батника при вызове эмуля Патрона подать сразу две команды внутрь:
rt11.exe assign hd1: c:
и
rt11.exe run cc файл.c
Вторая команда без первой не работает. Если подать их двумя вызовами, то второй вызов уже не будет помнить ассигн первого. Две команды в строку написать нельзя. Или можно?
Сделйте батник на RT-11, называется любым именем с расширением .COM, например NAME.COM, внутри каждая строка это одна команда на терминале RT-11.Цитата:
Сообщение от Oleg N. Cher
Затем вызываете из RT-11 как @NAME
Сейчас любой алгоритмический язык крайне далёк от железа, там давно уже многоядерность, выполнение инструкций пачкой и миллионы параллельных процессов, а программисты всё еще думают последовательно.Цитата:
Сообщение от Oleg N. Cher
Ну, Оберон и на это ложится. См. Active Oberon, диалект для параллелизма, на активных объектах.
Я назову те несколько достоинств Оберон-языков, которые вы все, вероятно, даже не посчитаете достоинствами.
1. Возможность развивать маленькими силами. Например, Ofront+ сейчас развиваю в основном я один.
2. Языковое конструирование, подобное железячному. Железо для любителей паять, а это для любителей покодить.
3. Независимость от трендов и современных тенденций.
4. Стабильность и проверенность временем. Сбалансированный языковой минимум. Академическая основа. Не разменивается на модные рюшики.
Так что и такой вот взгляд возможен. В противовес иметь средство от сторонней фирмы, запакованное в коробке. В котором уже всё для бедного ленивого программиста предусмотрено.
Тем, что я, зная Си, могу загрузить этот исходник в современнфй визуальный Си и портировать его, особо не вникая в детали. А переписывать на Си паскальную программу - бррр!Цитата:
Сообщение от Oleg N. Cher
Главная вина Вирта в том, что он сочинил пригодный к использованию учебный язык. И ленивые студенты, выучив этот язык, считают, что этого достаточно. Вон, наш коллега Хобот - типичный пример. В то время, как студент, обученный по методике Кнута, будет вынужден выучить что-то реальное.Цитата:
Сообщение от Oleg N. Cher
Меня, в общем-то, так и учили. Начали с программирования в машинных кодах (восьмеричных) ЭВМ "Минск-22", потом был Автокод "Инженер" этой же машинки, далее я обучался сам. Потом была Минск-32 с ее Системой Символического Кодирования (ССК - Минск-32, так назывался ее ассемблер) и Фортраном, потом наши клоны Системы-360/370, ЕС ЭВМ, потом Э-60, потом, совсем немного, писюк, после чего я сменил род деятельности. И только несколько лет назад, уже будучи пенсионером, в порядке хобби, решил вспомнить программирование и занялся микроконтроллерами. Ну, и, из ностальгических соображений, тусуюсь здесь...
Та ладно? Ну так а я, зная Паскаль, загружу исходник на ТурбоПасе в Дельфи или ФриПаскаль и очень легко заставлю его работать. Между Паскалем, Модулой и Обероном портировать значительно проще, чем между MS Visual C и Borland C. А уж если пошли плюсы, то это брррр.Цитата:
Сообщение от AFZ
Кстати, Оберон есть в проде. Сам внедрял, знаю людей, которые внедряют. Хотите плеваться - плюйтесь. Но он там себя неплохо чувствует.
- - - Добавлено - - -
Мне Наташа Зотова из Zosya Entertainment сказала, что их главный кодер, разработчик игр Valley of Rains и Drift, обучался на Паскале и не знает никаких других ЯВУ, кроме Паскаля. Только Паскаль и асм. Так что не надо, ладно?)
- - - Добавлено - - -
http://i.piccy_.info/i9/ef665383555d...0134/Zosya.png
https://github.com/yshestakov/pdp11-...lo-gcc/hello.cЦитата:
Сообщение от Oleg N. Cher
Пример выполнения (на Linux или MacOS):
Код:me@mac hello-gcc> make run
simh-pdp11 simh.ini
PDP-11 simulator V3.9-0
Disabling CR
Disabling XQ
CPU, 11/05, idle enabled, stability wait = 20s, autoconfiguration enabled, 64KB
PC: 001000
1000: MOV #10000,SP
1004: MOV #0,-(SP)
1010: MOV #1312,-(SP)
1014: MOV #1,-(SP)
1020: JSR PC,1034
1024: ADD #6,SP
1030: HALT
1032: NOP
1034: MOV R5,-(SP)
1036: MOV SP,R5
1040: ADD #177774,SP
1044: MOV #1316,177776(R5)
1052: MOV 177776(R5),R0
1056: MOV R0,R1
1060: INC R1
1062: MOV R1,177776(R5)
1066: MOVB (R0),R0
1070: MOVB R0,R0
1072: MOV R0,177774(R5)
1076: BR 1142
1100: MOV 177774(R5),R0
Hello, GCC world!
HALT instruction, PC: 001032 (NOP)
SP: 010000
Goodbye
Крутится у меня в голове, что одна из первых версий Oracle, после того, как его переписали на С, компилировалась компилятором C не от DECUS-а (варианты которого для PDP-11 под RT и RSX, собственно, и бродят по инету), а от как бы не WATCOM-а. Но - от WATCOM - это абсолютно не точно, точно только то, что у меня тогда был (может и сейчас живой где то) какой-то компилятор С под RSX, с помощью которого я с пяток модулей из Oracle восстановил до исходников на С, причём (опять по памяти) этот компилятор делал сразу .obj файлы.
Oleg N. Cher, А тебе ведь надо на макро-11 лишь вывод спрайтов сделать? Причем рисовать должен ПП (ибо только он умеет во все три плана рисовать).
Всей памятью ПП можно будет пожертвовать если допустить что из игры в систему RT-11 выходить будет не нужно (ну как на спектруме мол загрузил игру и все, выход через reset).
Для той карточной игры может быть видимо лишь проблема в том что в колоде 36 карт. Каждая карта если полностью хранить с 8-ю цветами это три байта на 8 пикселей. Пусть одна карта будет 48 х 60 это 6*60*3 = 1080 байт. Если так все карты делать то это скушает вместе с кодом игры все адресное пространство ЦП. А в ПП память влезет только 32 килобайта. Видимо надо будет уменьшить цвета до 4-х.
Плюс придумать как грузить данные и код в память ПП. Ведь паскаль будет компилять в .sav который разумеется ни в какое адресное пространство ПП лезть и не должен. То-есть надо будет графику отдельно подгрузить.
- - - Добавлено - - -
С паскалем под RT-11 совершенно дел не имел. Даже не знаю какой он код там генерирует. А так игрушка видится в таком плане - код паскаля как-то должен загрузить в память ПП свой код (спрайты и данные). Основная логика игры сидит в памяти ЦП, а ПП только принимает команды мол нарисовать спрайт, зажужжать там динамичком и т.д. Там придется на макро-11 все сделать, это не прям мегасложно. Я такое даже напишу для вас. Но как паскуаль этот грузит данные с диска - тут я даже и не знаю.
Я решил ограничиться двумя планами, как это сделали Вы и Никита Зимин. Думаю, доступ к ПП слишком сложен, да и жертвовать выходом в RT-11 не хочется. Карты будут отрисоваться по частям двухцветными тайлами, которые можно хранить в виде пары цветов - фон и цвет рисовки - и битовой маски, где каждый бит отвечает за то, фон это или цвет. Так сэкономится память. Памяти ведь у УКНЦ больше, чем у Спектрума 48Кб, да и подгрузки есть, на крайний случай.
Да, я тоже склоняюсь к тому, что надо ЦП сделать диспетчером, который просто отсылает в ПП команды типа: нарисуй спрайт, линию и т.д. Только я не знал, что ПП умеет обращаться ко всем битпланам. Я думал, что к двум первым - только ЦП. Вообще пока смутно представляю как распределена память в УКНЦ и как там может исполняться .sav размером > 64 Кб.
То есть, нужен графический движок, который будет работать через ЦП и ПП, где ЦП будет диспетчером, а ПП выполнит роль видеокарты. Видимо, примерно так.
Из Паскаля загружать файлы с диска несложно встроенными средствами. Я это проверил написанием на коленке простого вьювера BMP. Но думаю обойтись без подгрузок. Их только на самый крайний случай.
Кстати, было бы интересно увидеть сравнение качества кодогенерации OMSI Pascal, нативного Си для RT-11 - CC и GCC из pdp11-toolchain Юрия Шестакова. Какой вариант лучше прорабатывать?
Для ЦП всё не фонтан.Цитата:
Сообщение от Oleg N. Cher
1. Фундаментальное ограничение простых М-ЭВМ 56 Кбайт прямо адресуемой ОЗУ - адреса 000000-157776 ( 8 ). ( 0-55.99 Кбайт ).
2. Из них священные адреса :
000000 - 000376 - не стоит и думать о них, если софт работает под RT-11 .
Подробнее о этой области - в КД на систему от НЦ - довольно точный перевод от DEC, поставлялся с БК11 без "М" и с ДВК-2 МС0501 и МС0502.
3. Ядро ОС , для SJ ( однозадачника ) - адреса ориентировочно с 134000 и выше - см. КД на ОС, в зависимости от ревизии и версии ОС могут малость меняться.
4. Добавочный оверлей ОС, для работы с файлами - еще ~8 Кбайт, итого адреса порядка свыше 114000 - заняты ОС. Но ОС содержит команды, позволяющие этот компонент выгружать и загружать по ходу исполнения программы .
5. Библиотечка Паскаля - она не есть равна 000000, и даже не 1 Кбайт - еще досадный минус ОЗУ.
Итого - язык в мусорку, пишите на MACRO сразу.
Рисунки карточек рисуйте ( на экране ) по ходу вывода ( из малых графических форм ), не храните сканы натуральных карт , особенно если не работаете с винчестера/ЭД.
Если надо временно выгружать ядро ОС ( например, в ЭД ) - перед его удалением ( из ОЗУ ЦП ) не забудте запретить прерывания, а после восстановления ядра - можно и разрешить прерывания.
Спасибо за инфу! :-)
Собираюсь заморочиться именно разработкой на ЯВУ, вставки на асме конечно неизбежны, но хотелось бы свести их к минимуму.
Поэтому не собираюсь юзать оверлеев, резидентов и всего такого прочего. Если кто-то заинтересуется помочь с обменом с ПП, будет здорово. Но постараемся это скомпоновать как библиотеку для вызова из ЯВУ.
Сколько у нас есть доступной линейно адресуемой (без фрагментации) памяти для ЦП? Килобайт 30-35 на игру, по идее, должно хватить. Может даже меньше.
OMSI Pascal даёт компактный размер, т.е. потери на весь рантайм - 2-3 блока. Это не так уж и плохо. Насчёт Си не знаю, надо пробовать.
Можно сделать шаблон 3х карт с картинками, пустой карты и спрайты мастей. На пустой шаблон выводить масти согласно закодированного порядка в списке. Для карт с картинками планами "играть" чтобы они цветами отличались. Сэкономишь памяти почти на порядок.Цитата:
Сообщение от BlaireCas
- - - Добавлено - - -
Спрайты мастей сделать однобитными - черные BICом выводить, а красные во 2й план.
рекомендую изучить темуЦитата:
Сообщение от Oleg N. Cher
https://zx-pk.ru/threads/29643-porti...ts/page27.html
https://zx-pk.ru/threads/29643-porti...ts/page30.html
а именно идею как использовать ЦП на полную:
в случае с применением контроллера AZ, который подключен на шину ЦП, можно использовать _всю_ память ПП под игру
что важно - в таком режиме легко реализовать и возврат в RT11
и подгрузку информации в диска во время загрузки новых уровней
Про AZ подробнее описано в этой теме: УКНЦ + AZ - вариант контроллера псевдодисков на микро-SD для УКНЦ.
Основная страничка поддержки проекта [инструкции, техническое описание, обновления фирмвари]
Контроллер псевдодиска на MicroSD
Контроллер псевдодиска на MicroSD на шину МПИ: особенности версии для УКНЦ
Контроллер псевдодиска на MicroSD для УКНЦ: сборка и наладка конструктора контроллера
Вот более-менее настроенный комплект. HD_SYS_51.DSK монтируем на HD2, папку CTST на HD1, загружаемся с HD2 и вперед! Исходники в папке CTST правим любимым писюшным редактором, затем в эмуляторе запускаем командный файл, и вперед. Там есть две тестовых задачки - TST1 - обычный Hello, world и TST2 - чуть посложнее. Командный файл для своих задач делать по образу и подобию. Если вдруг захочется поработать на реальном железе, раскомментировать вызов редактора EDK (или заменить его вызов на свой любимый редактор для RT-11).Цитата:
Сообщение от Oleg N. Cher
Если вдруг захочется разбить исходник на несколько .C файлов, из которых получится несколько объектных файлов, то, когда их много, я делал объектную библиотеку для этого проекта, тогда командные файлы будут посложнее. Если надо - подскажу. У меня (тогда) необходимость разбить исходник на несколько файлов возникла когда он (исходник) перестал влезать в оперативку редактора EDK. Под эмулятором этот вопрос, скорее всего, не возникнет.
Да, эмулятор Патрона иногда не замечает, что кто-то из посторонних (в смысле, редактор из-под винды) что-то изменил в папке для HD1. В таком случае помогает команда SQ HD1:.
За Паскаль не скажу. Но в случае с GCC для pdp-11 платформы не поставляется стандартная LibC. Есть только кросс-компилятор + binutils (линкер, дебагер, все такое). Потому программа на C может быть достаточно компактной.Цитата:
Сообщение от MM
Другое дело -- поддержка процессоров 1801ВМ1/ВМ2 в GCC в части EIS инструкций. Я этим начал заниматься год тому, разобрался что к чему и как писать тесты на генератор кода. Но забросил это хобби, переключился на IDA, соотв. модуль декомпиляции для ВМ1 на Python (кросс-платформенный), и декомпилил им ПЗУ-шки. Листинги из-под IDA конвертил в синтаксис GNU AS, компилировал обратно в бинарный код и сравнивал с оригинальным бинарником.
У меня 5 цветов в игре считая белый и черный. Немного больше чем 2 плана. Но конечно не прям все 8.Цитата:
Сообщение от Oleg N. Cher
- - - Добавлено - - -
Нет, он как-раз не сложен на асме. Но я-ж сказал что самая проблема будет туда отправить код с паскаля. Тут уж я этого не знаю как такое забацать. И потом уже скорей-всего нельзя будет нативно что-то читать с дисковода или с винчестера если всю его память там закушать. Так-то там при разработке самой УКНЦ он и задумывался как нечто такое что не мешает ЦП и рисует всякие символы, графоний, работает с диском и пищит пищалкой.Цитата:
Сообщение от Oleg N. Cher
- - - Добавлено - - -
Надо будет все-ж запустить паскаль под RT-11, тут верно говорят что написать что-то можно только на ассемблере ибо ну не запихать во второй процессор что-то по-дефолту. Не компиляет небось паскаль всякие .asect .1000. Сначала надо бы сделать загрузку бинарника на паскале.
- - - Добавлено - - -
Нет же, машинка наша - почему все адреса не заюзать? Система сразу идет лесом после загрузки игрушки. Я так и делал в своей. Выхода в систему нету ну что-ж поделать.Цитата:
Сообщение от MM
?!Цитата:
Сообщение от BlaireCas
А Паскаль вслед за ядром ОС разве не идет ?
*
Для прояснения ситуации с Паскаль-котом берется файл игры .SAV и смотрится в DESS.SAV - какие вызовы ЕМТ он использует.
Если хоть один в наличии - ядро удалять нельзя.
:-) Установка палитры для каждой строки?Цитата:
Сообщение от BlaireCas
Кстати, было бы интересно посмотреть как это делается. Вообще было бы интересно увидеть разные мелкие штучки, реализованные на ассемблере. Вот как есть рубрика Этюды для Спека. Для УКНЦ или БК такого особо не встречал, а жаль.
Прикинул, что мне понадобится 32-битная целочисленная арифметика. Или на PDP-11 оптимальнее использовать плавучку? Кстати, сопроцессора ведь там нет, всё делается подпрограммами в целых числах?
Если привязаться к конкретным адресам, то просто перебросить массив из Паскаля в память ПП. Он конечно будет занимать и основную память, т.е. продублируется. Но тут уже ничего не поделаешь. Можно после переноса кода в ПП использовать эту память в ЦП для других целей.Цитата:
Сообщение от BlaireCas
Можно даже предусмотреть переносимый код. Или код с автонастройкой адресов. Ну если понадобится.
Но можно же и не всю. Можно этот графический драйвер для ПП снабдить только нужными функциями. Можно их собрать в виде объектников и линковать в бинарь, чтобы адреса настроил сам линкер.Цитата:
Сообщение от BlaireCas
Драйвер графики для ПП я конечно не предлагаю писать на Паскале.
Ну тоже вариант конечно. Для игры вполне годится, это ж не системная программа.Цитата:
Сообщение от BlaireCas
- - - Добавлено - - -
Юрий, есть ли интерес попробовать скрестить Ofront+ и GCC для PDP-11? Чтобы разрабатывать на Обероне для PDP-11 машинок. Библиотечин разных наработать, для графики и прочих вещей. Я когда-то ковырял этот GCC, хотел сделать подсистему UkncDev, но он слегка не похож на более новые версии, где-то там я споткнулся и не смог разрулить. Деталей, впрочем, уже не помню.Цитата:
Сообщение от yu.zxpk
Если согласитесь и интерес есть, это будет мощный стимул для меня. Если же нет, скорее всего, я ограничусь OMSI Pascal + Macro-11.
Я ничего не знаю про Ofront+, кроме того, что это препроцессор из языка Oberon в C код. И в GCC я разбираюсь на уровне "потратил неделю-две на изучить устройтво генерации в pdp-11 бакенде". Не думаю, что у меня будет время что-то сделать в GCC кроме обещанного Vslav в части поддержки ВМ1 и ВМ2 CPU.Цитата:
Сообщение от Oleg N. Cher
Аппаратная плавучка есть только у 1801ВМ4 - это арифметический сопроцессор для 1801ВМ3. ДВК с этой парочкой (ВМ3+ВМ4) выпустить не успели, можно считать, что плавучки нет ни в одном из серийных изделий на 1801-х микропроцессорах. Да, та плавучка (FIS), которая есть у ВМ2, это программная эмуляция FIS, программой, расположенной в теневом ПЗУ. Или, в случае УКНЦ, в теневом ОЗУ ЦП.Цитата:
Сообщение от Oleg N. Cher
А 32-битная арифметика на PDP-11 - это несложно и быстро.
Да по-хорошему он их и не должен будет использовать. Вот в плане того как он компиляет я нубас и ничего не скажу. Но не надо с него такие вызовы делать. Можно сделать так чтоб на нем только логика висела. А остальное ПП сделает через запись в ячейки памяти мол "нарисуй бубнового короля там-то".Цитата:
Сообщение от MM
- - - Добавлено - - -
Да, ее можно установить и для каждой строки, но ИМХО дело не в ней. Просто ЦП не умеет физически добраться до третьего плана видеопамяти. Ну не знаю почему так сделано, поэтому если более 4-х цветов (вместе с черным) то увы - только в периферийный проц лезть. Пока не думай об этом. Считай что он будет обрабатывать команды и рисовать. Делай логику игрушки, можно пока прям через вывод TTYOUT - потом переделаетсяЦитата:
Сообщение от Oleg N. Cher
Нужно не забывать, что ПП достаточно тормозной и доверять ему всю обработку графики неразумно, у него и без нее забот хватает.Цитата:
Сообщение от BlaireCas
Оптимально через ПП выводить статичную графику (фон, интерфейс, заставки полноцветные).
Не поленился, проверил этот Си под RT-11 V05.07, той выборки из нее, которая представлена на HD0 Патрона. RT-11 V05.07 расходует на себя заметно больше памяти, чем 5.1 и я побаивался, что памяти для СС будет маловато. Оказалост, памяти хватает.Цитата:
Сообщение от AFZ
Действия такие. Надо поместить на какой-то отдельный диск содержимое моего CC.DSK, расположенного на файл-образе HD_SYS_51.DSK и назначить туда логическое устройство C:. Я, по-простому, смонтировал его на LD2, но можно и скопировать его в файловую систему хоста и смонтировать полученный файл-образ на какой-то HDn. Ну, и DK назначаем на HD1, и можно программировать. Не знаю, правда, как компилятор будет понимать современные даты..
Итак, действия. (1) Средствами эмулятора монтируем на HD1 папку CTST. (2) Этими же средствами монтируем на HD2 файл-образ HD_SYS_51.DSK. Далее работаем из RT-11.Последняя команда - это проверочное действие. Должны нормально пройти компиляция, линковка и запуск сишной программы TST2.Код:MO LD2 HD2:CC
AS LD2 C
AS HD1 DK
@TST2
Да, сведения о том, что смонтировано на HDn запомнит эмулятор, сведения о LD2 запомнит драйвер LD, а вот сведения о назначениях запоминать некому. Поэтому при повторном запуске эмулятора их придется повторить. Ну, или собрать в отдельный командный файл. Как вариант - добавить в стартовый командный файл RT-11.
Наткнулся на прикольную игу (прадедушку LIMBO).
https://www.old-games.ru/game/2450.html
https://pic.maxiol.com/thumbs2/15844...37c70879db.png
Если на УКНЦ фон вывести допустим в планы 1,2 и заблокировать их, а синий цвет в палитре поменять на черный и рисовать в 3м плане, возможно ли добиться подобного эффекта?