PC-01 Lviv

It is currently 29 Mar 2024, 03:13

Forum Games WEB Tape Loader Twitter RSS

All times are UTC+03:00




Post new topic  Reply to topic  [ 11 posts ] 
Author Message
 Post subject: P_EMUL2021
PostPosted: 03 Jun 2021, 16:24 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
P_EMUL2021.
Attachment:
Черновик.7z [322.26 KiB]
Downloaded 724 times
Давным давно мною была создана такая штуковина как P_EMUL. Почему назвал именно так, я уже и не вспомню, но менять названия уже не хочу, чтобы самому не запутаться в названиях своих же всевозможный проб-разработках. :-)

Что из себя представляет P_EMUL2021.
Скажем так. Она дает возможность писать программы в среде Дельфи, используя при этом возможности ПК-01 и команды КР580. Проще выражаясь такая себе «крутилка» программ написанных в среде Дельфи, опрашивая клавиатуру и вводя на экран по принципу ПК-01 и т.д.

Применение.
Когда я писал «Лабиринт», фактически он был написан в среде Дельфи используя ввод с клавиатуры вывод на экран через модули P_EMUL. Поскольку, не было потребности доводить «Лабиринт» до полной готовности с помощью P_EMUL, я забросил это дело в P_EMUL, и стал портировать его в МАДЛ. Пример могу лишь предоставить корявый черновик и то в виде готового екзешника (см. LabirintD.exe).

Были и другие всевозможные пробы. Например «стрелялка» из игрушки «TETRIS 9999 in 1” поскольку она там была названа как «H”, я так и назвал пробу «TETRISH» Тоже могу показать лишь екзешник (см. TETRISH.exe (подождать несколько секунд после запуска), вырезка из кода, - uTETRIS.pas).

Также было сделал пробу игры «Пьяный лифтер» под P_EMUL
(см. TETRISH.exe, вырезка из кода, - PL.dpr)

Некоторые более простые пробы, я вообще не сохранял.

В общем суть использования P_EMUL заключается в следующем. Создаются процедуры, например ReadKey и DrawSprite командами КР-580 которые позволяют использовать опрос клавиатуры и вывод спрайта на экран ПК-01. Далее используя возможности Дельфи пишется проба или же целая программа которая «завязывается» на использование этих
процедур. После того как это все проверено, можно постепенно процедуры и конструкции Дельфи, заменять на команды КР-580, походу запуском проверяя работоспособность и правильность работы пробы или программы. Ну и последний этап это портирование в МАДЛ
и компиляция кода. Все это выглядит очень «заморочливо», но как по мне даёт полную
гарантию написания программы для ПК-01. Естественно используя P_EMUL из среды Дельфи доступны очень удобные средства , такие как StepOver(F8) и TraceInfo(F7), что очень удобно при проверке работоспособности программы. P_EMUL , годам был и есть в таком состоянии, что им может пользоваться может только автор (это Я), т.е. он не готов к выложить_его_на_люди!
Может он и далее таким бы оставался, но ситуация меняется и вот думаю пришло время, как говорится довести его до ума!

Оберон и XDev.
С появлением информации на форуме про Оберон, XDev и автора Zоrko :-)
у меня появились мысли от том, что P_EMUL можно очень эффективно использовать при подготовке программы для последующей компиляции через XDev. Дело в том, что использование XDev «напрямую» для мене например не то слово, что «неудобно», а неприемлемо вообще! Хотя мощные возможности XDev очень привлекательны! И если автор Zоrko доведет до совершенства XDev, (имеется ввиду для написания программ для ПК-01) то я бы «подточил» свой P_EMUL для возможности написания и проверки программ и последующей переброске в XDev для окончательной компиляции. Вот даже были пробы на эту тему.
Создаётся модуль Lvov.pas, в котором будут реализованы процедуры аналогичные ПК-01-процедурам- XDev, вот так вот:
(см. Lvovcut.pas, Lvov.pas)
Code:
unit Lvov;
interface
uses _uMain;
procedure CLS(border:Byte);
procedure PSET(x,y,color:byte);
procedure PRESET(x,y:byte);
procedure LINE(x1,y1,x2,y2,color:byte);
procedure BOX(x1,y1,x2,y2,color:byte);
procedure FIL_BOX(x1,y1,x2,y2,color:byte);
procedure PAINT(x,y,grf_color,brd_color:byte);
procedure COLOR(ground,palette:byte);
implementation

procedure CLS(border:Byte);
begin MVIA(border);STA($BE38);CallInMemLV($F836);end;

procedure PSET(x,y,color:byte);
begin
MVIA(x);STA($BE50);
MVIA(y);STA($BE51);
MVIA(color);STA($BE52);
CallInMemLV($F821);
end;

procedure PRESET(x,y:byte);
begin
MVIA(x);STA($BE50);
MVIA(y);STA($BE51);
CallInMemLV($F020);
end;

procedure LINE(x1,y1,x2,y2,color:byte);
begin
MVIA(x1);STA($BE50);
MVIA(y1);STA($BE51);
MVIA(x2);STA($BE57);
MVIA(y2);STA($BE58);
MVIA(color);STA($BE52);
CallInMemLV($F824);
end;

procedure BOX(x1,y1,x2,y2,color:byte);
begin
MVIA(x1);STA($BE50);
MVIA(y1);STA($BE51);
MVIA(x2);STA($BE57);
MVIA(y2);STA($BE58);
MVIA(color);STA($BE52);
CallInMemLV($F827);
end;

procedure FIL_BOX(x1,y1,x2,y2,color:byte);
begin
MVIA(x1);STA($BE50);
MVIA(y1);STA($BE51);
MVIA(x2);STA($BE57);
MVIA(y2);STA($BE58);
MVIA(color);STA($BE52);
CallInMemLV($F82A);
end;

procedure PAINT(x,y,grf_color,brd_color:byte);
begin
MVIA(x);STA($BE50);
MVIA(y);STA($BE51);
MVIA(grf_color);STA($BE52);
MVIA(brd_color);STA($BEA3);
CallInMemLV($F830);
end;

procedure COLOR(ground,palette:byte);
begin
MVIA(ground);STA($BEC0);
MVIA(palette);STA($BEC1);
CallInMemLV($F833);
end;
end.
И тогда в коде программы можно будет использовать эти процедуры
вот так вот:
(см. uOberon.pas)
Code:
begin
  Lvov.CLS(255);
  Lvov.PSET(0, 32, 3);
  Lvov.PRESET(10, 33);
  Lvov.LINE(0, 0, 128, 128, 2);
  Lvov.LINE(0, 10, 128, 138, 1);
  Lvov.BOX(50, 50, 75, 75, 3);
  Lvov.FIL_BOX(150, 150, 75, 75, 3);
  Lvov.COLOR(5, 0);
  Lvov.PAINT(130, 30, 2, 3);
end;
Что соответствует их написанию в XDev. Так же много, чего можно будет
“подточить” под XDev , например «type INT8=Byte;” и прочее.
И вот хотелось бы, чтобы автор XDev который Zorko :-) помог мне это реализовать!
Я думаю, это будет большой «плюс» для XDev и автору в карму! :-)
Ведь писать программу в среде Дельфи с её возможностями StepOver(F8), TraceInfo(F7), Run To Cursor(F4), Watch (Ctrl+F5), BreakPoint и.д. Куда веселее и эффективнее чем на прямую в редакторе XDev. Да и компиляция-запуск моментальная! А портировать потом из Дельфи в XDev, готовую Дельфи-программу, УЖЕ «заточенную» под портирование для XDev, УЖ Я ТО НАПРИМЕР, НЕ ПОЛЕНЮСЬ! :-)
Я думаю, что не одного меня подобное заинтересует!
Интересно, что скажет на это автор XDev? :-)


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 06 Jun 2021, 05:28 
Offline

Joined: 20 Apr 2021, 05:09
Posts: 100
Ну, полной эмуляции Дельфи на Обероне нам всё равно не добиться.
Я думаю, мы можем куда-то двигаться в этом направлении, однако всё-таки сильная сторона Оберона - это переносимость между платформами. Я не хочу засорять твою тему по P_EMUL2021, да и понял, что другие, кроме Львова, платформы тебя не интересуют. Поэтому я конечно готов отвечать на твои вопросы по разработке в XDev, но не думаю, что XDev даст какие-то преимущества твоему подходу.

Я бы сделал несколько вещей:

1. Пошёл бы к разрабам zcc и попросил бы их реализовать конструкции __asm/__endasm (наряду с #asm/#endasm), что уже позволит нам встраивать команды ассемблера в виде вызова процедур Оберона, таким образом, можно получить MADL прямо в Обероне, хотя конечно придётся освоить разработку для Windows, но она принципиально не очень отличается, в виду того, что язык тот же.

2. Поскольку у нас "зависла тема" с ORG, я предлагаю пока что такой подход (и то, если нет желания сделать программу из двух блоков): процедуры и данные, которые должны работать выше адреса #8000 оформить в виде отдельного модуля. А которые могут работать и ниже - в виде остальных модулей. Оберон это позволяет, там модульность в духе Дельфи, но чутка другая синтаксически - квалифицированный импорт обязателен, но в ИмяМодуля.Процедура имя модуля можно сокращать хоть до одной буквы, что добавляет немного краткости/выразительности (видно из какого модуля пришла сущность) и убирает неоднозначности, когда из разных модулей пришли одноимённые процедуры). В Дельфи это узкое место присутствует.

Далее мы перечисляем имена модулей в списке трансляции таким образом, чтобы наш модуль после #8000 шёл последним. И подбираем такой стартовый адрес, чтобы он оказался выше #8000.

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

Соединить и обощить столь разные ретро-платформы не так-то просто. Оберон тут не поможет, как и любой другой язык. Если в NES/SegaMD даже нет аналога текстового режима, приходится его эмулировать через тайлы, то о каком универсальном модуле для вывода текста может идти речь? Я думаю, мы не можем требовать от языка, чтобы он решал эту неразрешимую задачу. Вообще стыковать разные ретро-платформы - задача очень сомнительная. Я пробую это делать, но я уже сломал об это зубы, поэтому я остановился на том, что можно соединять через сам язык Оберон. То есть, просто упрощается перенос, но слишком различные программные особенности никто не отменял, посему я просто рад, что можно брать код с одной платформы на другую и переносить кусками, что намного приятнее, чем переписывать с одного ассемблера на другой. Так что я не то чтобы очень уж рад этим проседаниям производительности и прочим ограничениям, но я с этим просто мирюсь, чтобы развивать данный подход в надежде когда-то получить супер-компилятор хотя бы того же Си. Но это так, лирика.

Сейчас очень сильно не хватает утилиты для кодирования графики под Львов. Даже редактор бы не помешал.

Теперь по P_EMUL2021. Я не очень понимаю как именно XDev поможет тебе в этом деле. Но бог с ним. Если как-то поможет - милости прошу. Я видел уже разные странные подходы, почему бы нет.


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 06 Jun 2021, 11:15 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Quote:
Я не хочу засорять твою тему по P_EMUL2021, да и понял, что другие, кроме Львова, платформы тебя не интересуют.
Нет, не интересуют другие платформы! И сомневаюсь, что когда-то это может изменится! Скорее всего я быстрее могу потерять какой-то интерес к ПК-01, но не на пользу другой ретро-машины это уж точно!
Quote:
Поэтому я конечно готов отвечать на твои вопросы по разработке в XDev, но не думаю, что XDev даст какие-то преимущества твоему подходу.
Ну давай не будет забегать вперед по поводу моего подхода... :-) Время покажет и расставит всё на места. А на мои вопросы можна будет особо и не отвечать :-) при условии, что будет документация XDev по написанию програм для ПК-01. И согласись такое должно быть! В моём понимании, это должен быть обычный текстовый файлик с коротким и ясным пояснением всех модулей и процедур тех модулей, что касаемо написания для ПК-01. Ну приблизительно такое как у меня к МАДЛу - "ОПИСАНИЕ ПРОЦЕДУР И ФУНКЦИЙ КОМПИЛЯТОРА (MD00).txt". Вот только не нужно делать его PDF, DJVU или еще каким-то подобным форматом, ну не нужно такое никому! Просто обычным текстовым форматом, в кодировка АНСИ1251. Твой архив документации по оберону, это не совсем то! Так как он является общим (общирным). А человека заинтересовавшегося программированием для ПК-01 в первую очередь будет интересовать возможности которые предоставляет XDev именно касаемых той конкретной платформы (ПК-01).
По примеру МАДЛа, я же не призываю для начала читать "вагон" документации по Дельфи или ФриПаскалю! Я создал документацию исключительно по возможностям МАДЛа. Что и тебе настоятельно рекомендую.

Quote:
1. Пошёл бы к разрабам zcc и попросил бы их реализовать конструкции __asm/__endasm (наряду с #asm/#endasm), что уже позволит нам встраивать команды ассемблера в виде вызова процедур Оберона, таким образом, можно получить MADL прямо в Обероне, хотя конечно придётся освоить разработку для Windows, но она принципиально не очень отличается, в виду того, что язык тот же.
Слушай, ну это разговор из серии "кабы дабы", ну по факту это ж нету ?! ну значит и разговаривать вроде как не о чём! Во всяком случае сейчас!
Quote:
2. Поскольку у нас "зависла тема" с ORG, я предлагаю пока что такой подход (и то, если нет желания сделать программу из двух блоков): процедуры и данные, которые должны работать выше адреса #8000 оформить в виде отдельного модуля. А которые могут работать и ниже - в виде остальных модулей. Оберон это позволяет, там модульность в духе Дельфи, но чутка другая синтаксически - квалифицированный импорт обязателен, но в ИмяМодуля.Процедура имя модуля можно сокращать хоть до одной буквы, что добавляет немного краткости/выразительности (видно из какого модуля пришла сущность) и убирает неоднозначности, когда из разных модулей пришли одноимённые процедуры). В Дельфи это узкое место присутствует.
Далее мы перечисляем имена модулей в списке трансляции таким образом, чтобы наш модуль после #8000 шёл последним. И подбираем такой стартовый адрес, чтобы он оказался выше #8000.
Ну опять же... это всё надо "видеть", пробовать чтобы что-то об этом говорить! Ну а сейчас что можна сказать то ?!
Quote:
Мой подход выглядит корявым?
Не знаю! Я его не видел и не пробовал! :-)
Quote:
Дело в том, что я использую платформенные особенности по необходимости, тем более, изучить весь парк ретро-машин в тонкостях это непосильная для меня задача. Да, я люблю расширять кругозор, но охватить всё не так уж и легко. Мне приходится брать платформу, разбираться как устроен инструментарий и её исполняемые файлы. Я часто пользуюсь сторонними инструментами и компиляторами, что тоже накладывает свои ограничения. Я к тому, что вопрос с ORG конечно интересный, но я всё же сконцентрировался бы больше на высокоуровневых особенностях и переносимости.
Ну ты понимаешь, что к примеру вывод спрайта, т.е. та процедура которую я "нарисовал" это не единственный способ вывода спрайта! То как говорится самый простой способ "слева-направо-сверху-вниз", не всегда и не везде он подойдёт! Сколько еще всевозможных выводов спрайтов существует если комбинировать "лево", "право". "верх", вних" ?! Да еще если учесть, что кому-то понадобится по принципу "через-строку" в два захода. А наложение спрайтов и т.д. Ты всего не учтёшь и не напишешь! Поэтому АСМ точно должен быть! На котором пишут то что невозможно написать на обероне! По опросу клавиатуры, - то же самое! И сколько еще такого всякого ?! И вот если окажется 18 разновидностей процедур которые выводят спрайт, а той что мне надо нету, то не убедишь ты разработчиков для ПК-01 (да и других наверно тоже), чтобы они выбирали из того что есть! Поэтому, не стремись набахкать самостоятельно DrawSprite, ReadKey и т.д. потому, что таким как я, - да хоть вообще пусть пусто будет без всяких там готовых DrawSprite, ReadKey, такое я и сам набахкать могу. Вот только есть ли возможность (АСМ) чтобы это сделать! А подход "полезь в какой-то там си-файлик и туда добавь то что ты хочешь на языке си" это не очень-то и правильный подход! Я желающий использовать XDev, хочу, чтобы все можна было вписать в проект-оберона и без всяких "свистоплясок".
В МАДЛа сам понимаешь такое возможно! Так же МАДЛ дальше каждому самому можна дорабатывать в какою сторону хочешь, ну и такого нагородить... :-) (я уже писал об этом в теме "МАДЛ").
Почему XDev должен быть другим ?! "зарубанным" под то, что задумали автор XDev и zcc ?!
Среда программировани должна не "зарубывать" возможности, а предоставлять их!
Есть возможность реализовать в обероне ASM, ORG, MADL, управление СИ из оберона или сомой компиляцией - ну реализуй! Надо оно или не надо, - зачем тебе думать об этом ?! Пусть думают, те хто захочет пользоваться XDev, что им надо а чего не надо! Если ты читал описание процедур МАДЛа, то сколько там по твоему нафиг не нужного ?! Ну это ж только по твоему оно так, а у других другие предпочнения!
Quote:
Соединить и обощить столь разные ретро-платформы не так-то просто. Оберон тут не поможет, как и любой другой язык. Если в NES/SegaMD даже нет аналога текстового режима, приходится его эмулировать через тайлы, то о каком универсальном модуле для вывода текста может идти речь? Я думаю, мы не можем требовать от языка, чтобы он решал эту неразрешимую задачу. Вообще стыковать разные ретро-платформы - задача очень сомнительная. Я пробую это делать, но я уже сломал об это зубы, поэтому я остановился на том, что можно соединять через сам язык Оберон. То есть, просто упрощается перенос, но слишком различные программные особенности никто не отменял, посему я просто рад, что можно брать код с одной платформы на другую и переносить кусками, что намного приятнее, чем переписывать с одного ассемблера на другой.
А вот и ответ на твой вопрос по поводу P_EMUL2021. Я просто хочу её подточить так, чтобы можна было переносить на оберон!... что намного приятнее, чем писать напрямую в обероне без возможностей пошаговых проверок, Watch и т.д.
Quote:
Сейчас очень сильно не хватает утилиты для кодирования графики под Львов. Даже редактор бы не помешал.
Та мне влом такое писать было раньше та и сейчас тем более. Видишь какой а путь выбрал в МАДЛ меня то вполне устраивает! Да и нарисуешь в редакторе, потом потом готовый код вставлять надо и т.д. А так прямо в МАДЛе взял на "нарисовал". Вот прикрути ту процедуру что я тебе дал к оберону и не мучайся со всякими редакторами графики! Кстати, а может они и есть, - чёрт его знает!
Хочешь вот это рассмотри
viewtopic.php?f=3&t=347&p=5187&hilit=DaDither#p5180
Quote:
Теперь по P_EMUL2021. Я не очень понимаю как именно XDev поможет тебе в этом деле. Но бог с ним. Если как-то поможет - милости прошу. Я видел уже разные странные подходы, почему бы нет.
Ну попробую, посмотрим, что из этого выйдет!
Конечно правильно бы было, чтобы XDev уже готов был для ПК-01 достаточно хорошо! Да и пример булдер и прочее ДЛЯ ПК-01 примеры были черновые какие-то были, вот тогда можна было бы P_EMUL2021 испытывать не вылкадывая_на_люди! А то выложу одно, а потом переделуй его. Хотя он вообщем-то не пропадёт! Он мне помогал и помогает для МАДЛа. Но всё равно, - если я хочу его использовать для XDev, то надо бы чтобы XDev готов был! Да и понятное дело у меня без "коныков" работать должен! :)


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 06 Jun 2021, 17:28 
Offline

Joined: 20 Apr 2021, 05:09
Posts: 100
Quote:
А на мои вопросы можна будет особо и не отвечать :-) при условии, что будет документация XDev по написанию програм для ПК-01. И согласись такое должно быть!
Дела-дела. Я в том смысле, что тебе ли, знатоку Львова, нужна ли такая документация? Да ты сам всё знаешь наперечёт.

И выглядит так, как будто толпы страждущих разрабатывать под Львов ждут документации. Тогда как на пустом форуме, такое впечатление, что нет никого, кроме нас.

Нет, увы, но никакой особой документации не планируется. Потому что документацией будет документация по Львову и его особенностям, а я в этом не шибко силён.
Quote:
В моём понимании, это должен быть обычный текстовый файлик с коротким и ясным пояснением всех модулей и процедур тех модулей, что касаемо написания для ПК-01.
Такое в XDev может быть - выделяешь имя модуля мышкой и выбираешь XDev -> Show Definition. И видишь список всех реализованных процедур. Кстати, вот чего бы реально стоило бы сделать (много лет уже собираюсь), так это возможность экспортировать комментарии на уровень интерфейса. Как видишь, всё руки не доходят. Но так можно было бы самодокументировать интерфейсы по ходу разработки модулей.
Quote:
Quote:
1. Пошёл бы к разрабам zcc и попросил бы их реализовать конструкции __asm/__endasm (наряду с #asm/#endasm), что уже позволит нам встраивать команды ассемблера в виде вызова процедур Оберона, таким образом, можно получить MADL прямо в Обероне, хотя конечно придётся освоить разработку для Windows, но она принципиально не очень отличается, в виду того, что язык тот же.
Слушай, ну это разговор из серии "кабы дабы", ну по факту это ж нету ?! ну значит и разговаривать вроде как не о чём! Во всяком случае сейчас!
Ну вот до сих - не было, а теперь будет.


Попой надо двигать, а не Олега пинать. Олег-то не такой уж и двухжильный. Я разбираюсь с каждой платформой, как могу. Но если кто-то сделает норм документацию по Львову, то это только ты. При моей помощи. Но, опять же, аудитория у ней будет, я так смотрю, пара человек: ты да я да мы с тобой.
Quote:
Quote:
Далее мы перечисляем имена модулей в списке трансляции таким образом, чтобы наш модуль после #8000 шёл последним. И подбираем такой стартовый адрес, чтобы он оказался выше #8000.
Ну опять же... это всё надо "видеть", пробовать чтобы что-то об этом говорить! Ну а сейчас что можна сказать то ?!
Ну, так точно получится.

По поводу ORG - надо спросить разрабов zcc как они вообще видят использование ORG внутри Си. Предусмотрено ли у них это вообще или они всё-таки полагаются на линкер. Надо решать задачу на своём уровне. Но мне ORG пока не нужен.
Quote:
"туда добавь то что ты хочешь на языке си" это не очень-то и правильный подход!
Если ты внимательно рассмотрел сишные файлы, то там из языка Си только прототипы функций, всё остальное асм. Ну вот не могу я к Оберону прилепить кучу сишных директив, да и смысла в этом нет. Я же развиваю подход с высоким уровнем, превращать Оберон в ассемблер нет никакого резона. Поэтому преодолей свою боязнь сишных файлов, прими, что так реально гибче, и нет нужды плодить сущности без необходимости. Можешь помаленьку вставить в Оберон-код чего-то там на асме, это у нас есть. Но если ты хочешь использовать передачу параметров в регистре и разные модели вызова - придётся делать это через Си, потому что эти модели - сишные. В Обероне их нет. Оберон вообще абстрагируется от способа передачи параметров или вызова. Есть просто передача параметров или вызов, а как оно устроено - пусть болит другая, не оберонская голова. Мы это спрятали под коврик и сделали вид, что этого вообще нет. Вот такой подход. Сконцентрироваться на самом важном - на алгоритмах. А не на низкоуровневых особенностях. Но у нас есть уровень асма, просто чуть-чуть обёрнутый в Си. Кстати и директивы эти, и модели - они нестандартные даже для Си. Так что тащить всё это в Оберон... я уже думал над этим, но не вижу особого смысла, правда. Не хочется углубляться в Си - это твоё дело. Да это и не нужно. Просто пойми как работают разные модели вызова и особенно передача параметров в регистре. Это важно, т.к. платформа у нас слабенькая.

По поводу подготовки графики - нужна утилита, чтобы нарезать спрайты. Делать это руками - свихнуться можно. Zelya, ау?!!


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 06 Jun 2021, 19:42 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Quote:
Дела-дела. Я в том смысле, что тебе ли, знатоку Львова, нужна ли такая документация? Да ты сам всё знаешь наперечёт.
Да ты что ?! :-) Откуда мне знать то чего ты там понаписывал и как это всё вызывать, - название процедуры, с каким входящими параметрами и т.д. ?
Я представляю, если бы я выложил свой МАДЛ без документации, мотивируя кому-то знания ПК-01 и паскаля! :-) Ну да... Я то что я нагородил в самом МАДЛе, но откуда знать то названия тех процедур и значения передаваемых в них параметров не посвященным людям ?!
Zorko, тут ты не прав! Тебя просят то, что писано именно тобою, оформить это все для понимание всех модулей туда вхожих и процедур!
Quote:
И выглядит так, как будто толпы страждущих разрабатывать под Львов ждут документации. Тогда как на пустом форуме, такое впечатление, что нет никого, кроме нас.
Оно то вроде и так. Вот только вопрос - а почему все что мы не выкладываем (файлы) на форум скачано не 1-2 раза а по 5, 7, 10 и более раз? Кто то всё качает ?! Видимо "молчуны" всё таки есть на форуме!
Quote:
Нет, увы, но никакой особой документации не планируется. Потому что документацией будет документация по Львову и его особенностям, а я в этом не шибко силён.
Тебя просят документацию именно по тому что "нагродил" ИМЕННО ТЫ! Т.е. "нагородил" модуль LVOV, - опиши, что за модуль то такой. (Что еще за модули для ПК-01 есть, названия их и т.д.). "Нагородил" в нем процедуры с параметрами - опиши что за процедура такая! Откуда мне знать что делает процедура RDTKM(e1,r1,e2,r2:cardinal), которая находится в модуле LVOV ? Смотреть код и догадываться ? ну-ну! :-) У меня уже есть такая "игра" - смотреть код ПЗУ-львов и догадываться, что то за код, зачем он и что он делает!
Quote:
Такое в XDev может быть - выделяешь имя модуля мышкой и выбираешь XDev -> Show Definition. И видишь список всех реализованных процедур.
нда! Вот только чтобы что-то выделить надо знать а что за модули существуют (названия их) чтобы вписать те названия и выделить! :-) Как то так.
Quote:
Попой надо двигать, а не Олега пинать. Олег-то не такой уж и двухжильный.
Та я попой могу двигать и в сторону МАДЛ, P_EMUL и т.д. Во первых я знаю как там попой двигать!
Quote:
Я разбираюсь с каждой платформой, как могу. Но если кто-то сделает норм документацию по Львову, то это только ты. При моей помощи. Но, опять же, аудитория у ней будет, я так смотрю, пара человек: ты да я да мы с тобой.
Ну так может вообще не брался бы за поддержку ПК-01, если тебе нужна аудитория, а её не предвидится ?! Это ж не я, что мне похрену, создал МАДЛ, а пусть хоть кто пользуются им, хоть нет! Тоже самое и со всем остальным мною созданным или еще не созданным!
Quote:
Но мне ORG пока не нужен.
Ну а ПК-01 он нужен и мне тоже! Точнее не сам ORG а RAM2. которая в моём еще не выложенном МАДЛе, означает, - если адрес для компиляции меньше $8000, то установить его в $8000!
Как-то так.
Quote:
Если ты внимательно рассмотрел СИшные файлы, то там из языка Си только прототипы функций, всё остальное асм. Ну вот не могу я к Оберону прилепить кучу СИшных директив, да и смысла в этом нет.
Что ты мне только, что сказал, а?! Ты мне сказал, что для использования оберона, нужно еще знать СИ как и куда писать прототипы функций в какие-то СИшные файлы и еще знать как они компилируются!
Слушай, а ты подумал о том, что когда пользователь что-то напишет на обероне, то просто написанный исходник выложить будет недостаточно, а надо еще выкладывать какие-то СИшные файлы которые он "ковырял", а иначе его исходник просто бессмыслен! И к тому же те кто захочеш воспользоваться исходником, должны знать как и куда "прикручивать" эти СИшные файлы, как компилировать их и т.д.
А вот что делать то, если каждый пользователь "понаковыривал" те СИшные файлы своими личными функциями, по своему, - как пользователям использовать исходники друг друга и делать "слияние" СИшных "ковыряний" других со своими СИшными ковыряниями ?!
НЕ НАХОДИШЬ МАРАЗМА В ЭТОМ ВСЁМ ?!

Вот возьмём МАДЛ. Там всё завязывается на файл uMD01u.pas где прописаны процедуры ДЛЛ-модулей. И вот я выкладываю исходник и при этом говорю, чтобы он работал, то там в uMD01u.pas, нужно убрать "то", добавить "это". А если вы его "ковыряли" уже по своему, то еще и "согласовать" надо как-то те ковыряния ваши и мои. Хороше если процедуры которые дописывали и вы и я, в тот файл, имеют разные названия, а если по чистой случайности нет, то будет работать или ваше или моё! :-)
Как тебе лично такое бы понравилось ? :-)
Quote:
Я же развиваю подход с высоким уровнем, превращать Оберон в ассемблер нет никакого резона.
Та ты молодец! Вот только мне его использовать нет никакого резона для ПК-01. Потому, что если, чего-то коснуться, чего нету в обероне, то дописать самому не преставляеться возможным, либо нужны еще какие-то знания СИ и их файлы которые имеют прототипы функций и т.д. Меня такое явно не устраивает! Уж не знаю как остальных, которые однажды захотят воспользоваться твоим XDev.
Quote:
Поэтому преодолей свою боязнь сишных файлов, прими, что так реально гибче, и нет нужды плодить сущности без необходимости. Можешь помаленьку вставить в Оберон-код чего-то там на асме, это у нас есть. Но если ты хочешь использовать передачу параметров в регистре и разные модели вызова - придётся делать это через Си, потому что эти модели - СИшные.
ОЙ! Как же я преодолею боязнь то, если ты меня таким текстами пугаешь ?! :)
Ну мне проще тебе по булдеру помогти и вернуться опять в МАДЛу там мне все понятно и преодолевать ничего не нужно (боязнь) и без СИ как-то живётся мне не плохо и т.д.

Слушай, давай наверное прекращать полемику на эту тему, тем более мы уже повторяемся!
Увижу готовый булер, его исходник, XDev который у меня работать будет и компилить булдер, - вот тогда что-то и думать буду! Или не буду!
Quote:
По поводу подготовки графики - нужна утилита, чтобы нарезать спрайты. Делать это руками - свихнуться можно. Zelya, ау?!!
Да чем тебе моя процедура VarSprite не устраивает ? Что тебе нарезать то та из чего ?!
Ты сейчас мне как начнёшь про полу-тайлы чертверти-тайлы с ума сойти!
Ну может и правильно оно что к Zelya обращаешься! :-)


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 06 Jun 2021, 22:49 
Offline

Joined: 20 Apr 2021, 05:09
Posts: 100
Смотри что у нас получается. Я наивно полагал, что XDev будут дополнять любители платформ. А ты у меня требуешь не только всех процедур и полного комплекта под ключ, который потом не будет меняться, но и вообще документации.

Подсистема XDev для реализации конкретной платформы - вещь открытая. Изменений в трансляторе или в среде по большому счёту не требует. То есть, все процедуры пользователи могут добавлять самостоятельно. На что и был расчёт. Что каждый сделает свою поддержку, свой любимый модуль и свою любимую процедуру. Но увы, так это не работает.

Я нигде не писал про то, что требуется знание Си. Или ты что-то не так понял. Наоборот, я писал, что есть примеры удачной разработки от людей, которые не знают ни Си, ни асма.

Так вот. Чтобы узнать, какие есть модули в любой подсистеме - надо просто зайти в папку Lib/Mod и увидеть их интерфейсы. В этих интерфейсах могут быть сколь угодно обширные комментарии. Реализацию тоже можно полностью увидеть в сишниках. Если тебе это непривычно и не нравится, то я точно также могу выковырять кучу недостатков в МАДЛе, ну да бог с ним. Например, фигли оно идёт в DLL? А вдруг там вирус? ;-)

Чтобы узнать какие процедуры есть в любом модуле - опять же, открываешь любой модуль и видишь там заголовки, прототипы. Можно всё это документировать. Но мне заниматься этим для одного человека, поверь, не так уж и хочется. Мне особо не важно, сколько пользователей Львова будет у XDev.

Возможно, скоро у меня вообще не будет времени на ретро-платформы. Как пойдёт. Жизнь круто меняется, новая работа, новые перспективы. Так что документировать платформу, которой интересуется один человек - вот реально нет желания.

Боулдер постараюсь закончить. Есть продвижки. Сделал утилитку для кодирования графики. Чуть позже опубликую. Результатов конкурса пока нет, жду сам.


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 07 Jun 2021, 02:57 
Offline

Joined: 20 Apr 2021, 05:09
Posts: 100
Кстати, друг. По поводу документации. Ты подсистему K580Dev вообще смотрел? Чем вот это тебе не документация?

Image


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 07 Jun 2021, 08:51 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Слушай, друг. Я наверное возьму себе за основную позицию по XDev, позицию подобную твоей к "МАДЛ"-у. Как там она, твоя позиция "звучит" - "Меня не устраивает сам подход в твоём МАДЛе!..." Все ведь! И дальше вроде как и разговаривать не о чём! Вот и у меня такая позиция к XDev! А ты хочешь пиши XDev, хочеш не пиши, выкладывай новые версии или не выкладывай, с документацией или без, зачем оно мне ?! Ну я ж не заказчик, чтобы что-то там требовать от тебя! И то,что меня не устраивает, тебя не очень то должно и волновать! Будут ведь другие пользователи, которые наверное достойно оценят твою разработку!
Я буду себе разрабатывать свой МАДЛ, P_EMUL2021 еще чего-то там. А по поводу XDev, ну если будешь, что-то выкладывать, - скачаю, посмотрю, что-то мне будет не приемлемо, - молча удалю! И не будет мне никакого головняка! И не нужно мне писать и читать целые как ты там выражается, - "простыни". Действительно, зачем это все ?! Уже много "простыней" понаписано и тобою и мной! Уже "кругами ходим"!
По поводу твоего желания булдер портирировать, - ну я ж не против, того, чтобы появилась новая игра для ПК-01 как наверное и другие пользователи (учасники форума, владельцы ПК-01 "железного" или эмуляторов и т.д.). Вот только мне, как видимо и другим учасникам, без разницы как она писана, с помощью XDev или МАДЛа или АСМа или вообще комбинировано. Я тебе помогаю как могу (или помогал как мог) по поводу булдера, я так бы и другим помогал, даже если бы разработка была бы не паскалеподобная, т.е. явно мне не приемлемая! По поводу помощи в булдер связанной с полу-тайлами и четверь-тайлами или чем-то подобным, - ну я далёк от того как устроена булдер, - при разработке булдер я ведь не участвовал. Поэтому выше головы пытаться прыгать не буду, все равно не получится! Да и интереса, желания у меня, себе "мозги компосировать" на тему как бы тебе именно с этими полу-тайлами помочь, - у меня нету! Все как говориться по ходу! Или знаю как помочь, - помогаю, или если явно не знаю, - не помогаю!
Ну вот как-то так!


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 14 Jun 2021, 16:10 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Описание P_EMUL2021.

P_EMUL2021 предназначен для использования его из среды Delphi, Lazarus,
FPC и прочих подобных сред программирования в качестве помощника написания
и проверки кода для ПК-01, который в последствии может быть использован
в МАДЛ и возможно в XDev.
Рассмотрите внимательно предоставленные примеры и вы поймёте как можно
использовать данную программу (модуль). Если же всё таки не поймёте, нет
смысла объяснять. :-)

Далее читаем
"ОПИСАНИЕ ОСНОВНЫХ ПРОЦЕДУР И ФУНКЦИЙ КОМПИЛЯТОРА (PE00).txt"
"ОПИСАНИЕ ПРОЦЕДУР И ФУНКЦИЙ КОМПИЛЯТОРА (PE00).txt"
и другие файлы документации Описание P_EMUL2021.

Attachment:
P_EMUL2021.7Z [267.27 KiB]
Downloaded 744 times


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 14 Jun 2021, 20:21 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Пример Scroll. (MADL P_EMUL)
Оригинал
viewtopic.php?f=20&t=399&p=5582#p5581
Attachment:
Scrol.7z [8.49 KiB]
Downloaded 777 times


Top
   
 Post subject: Re: P_EMUL2021
PostPosted: 23 Oct 2022, 13:54 
Offline

Joined: 18 May 2016, 19:55
Posts: 425
Тема “P_EMUL2021”, як і розробка “P_EMUL2021”, - закриті!
Надалі переходжу на розробку “P_EMUL2023”, який буде розроблятись наряду з “MADL2023”, в темі “MADL2023” починаючи з повідомлення -
viewtopic.php?f=20&t=405&start=15#p5681


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 11 posts ] 

Forum Games WEB Tape Loader Twitter RSS

All times are UTC+03:00


Who is online

Users browsing this forum: Google [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
cron
Powered by phpBB® Forum Software © phpBB Limited