|
nedoPC.orgCommunity for electronics hobbyists, established in 2002 |
|
[SDK] Старая тема про nedoPC SDK (август 2004)
Author |
Message |
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Это же просто INCBIN бинаря со спрайтами надо сделать в сгенерённый ассемблерный исходник программы по заранее известному отступу (скажем 48 байт) - осталось мой RASM научить делать INCBIN (а zmac это уже умеет с 2005 года усилиями Василия Иванова)... P.S. На самом деле файл TILES.SPR уже является ассемберным файлом (за исключением комментариев, которые записаны как ; а не \ как того хочет RASM), но при компиляции бинарника спрайтов SPR_COMP делает кое-какие манипуляции с атрибутами в соответствии с выбранной платформой, а также может инвертировать саму картинку, если в комментариях есть символ ! - по идее можно просто поправить SPR_COMP, чтобы он генерировал новый ассемблерный исходник описывающий спрайты вместо придумывания как воткнуть INCBIN в RASM...
|
22 Jul 2024 18:59 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Короче суть придумки - в списке слов в самом начале блока кода появится слово в котором будет храниться адрес шрифта 8x8 для графических систем и ноль (или FFFF?) для текстовых систем (или систем где используется встроенный в целевую систему шрифт типа speccy с выводом текста через подпрограммы бейсика). Подпрограмма PUTCH пока останется в системных ассемблерных файлах, однако при вызове она будет проверять состояние этой переменной и если там что-то необычное типа #0000 или #FFFF, то ничего не будет печататься. Соответственно пользователь получит возможность через встроенный ассемблер подменить адрес в этой переменной на свой, если он захочет задействовать свой шрифт вместо шрифта nedoPC 8x8 (который я на днях перевёл в категорию PUBLIC DOMAIN чтобы всё содержимое LIB в итоге стало PUBLIC DOMAIN). При старте в этой переменной будет ноль и адрес встроенного шрифта там появится только при первом вызове команды SAY (или PUTCH?), которая будет проверять что там ноль и если да, то будет записывать туда адрес FONT8X8 (а для текстовых систем по видимому туда надо записать что-то ненулевое, но заведомо не являющееся шрифтом, например #FFFF).
|
22 Jul 2024 22:45 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Вроде сделал: https://gitlab.com/nedopc/sdk/-/commit/01efab674c8d64e001fee2bc4e5530fbbe4e8290Заодно новые сдвиги в LIB/I8080/_SHIFTS.A добавились P.S. Не - всё таки надо инициализацию _L_FONT в SAY как-то воткнуть - без SAY ошибка компиляции опять получается... P.P.S. И проект RANDOM чото сломался - рисует только красные квадраты........ P.P.P.S. Нашёл косяк в новой реализации !=
|
23 Jul 2024 23:59 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Фуф - всё исправил Иницализацию _L_FONT всё таки вставил в SAY, но в RADIO.A и SPECCY.A пришлось вписать заглушку FONT8X8 DB 0 (теперь без -I_FONT оно не соберётся из-за двух меток FONT8X8): https://gitlab.com/nedopc/sdk/-/commit/eaaac8bea2a97a98fd0f7adaba8312260760cf13Надо чтоли тест 0002 на != расширить, а то он не поймал сравнение одинаковых маленьких ненулевых чисел... P.S. Заодно подготовил плацдарм для переноса простых тайлов внутрь бинаря по смещению #0030: и когда появится перемещаемость, то слово BIN в заголовке заменится на OBJ, а BITMAP-таблицы для перемещаемости кода и данных будут добавлены в конце после ключевого слова [BITMAPS] плюс я наверное буду такие объектники сжимать своим пакером SHAFF, а то там в области битмапов, которые будут иметь размер в четверть кода, предполагается много нулей... P.P.S. Вот например как сжимается MAPGEN.BIN для РК даже без битмапов:
|
24 Jul 2024 01:28 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Добавил в скрипт DEFAULT.N таргет i8080obj для сборки кода не привязанного ни к одной системе (и без картинок), которому можно передать 2 параметра - адрес кода и адрес переменных: https://gitlab.com/nedopc/sdk/-/commit/04126b8fc269abfccea72b29c96b9783d5a28e86Для получения перемещаемого объектника сначала запускаем сборку без параметров - оно будет 0 и 0 по умолчанию Потом смещаем код на сколько-то кратное 256, например собирая с параметрами 0x100 и 0 Потом возвращаем код обратно и смещаем переменные - например собирая с параметрами 0 и 0x100 После этого генерим программно 2 BITMAP таблицы и приклеиваем их сзади к бинарнику собранному с 0 и 0 - эту программу ещё надо написать P.S. Интересным свойством таких объектных файлов будет то, что их можно линковать как статически, добавляя в общий бинарник по нужным адресам, так и динамически - подгружая на лету и храня независимо от вызывающей их программы! т.е. это будут эдакие LIB и DLL в одном флаконе P.P.S. Заодно отключил очистку области переменных и регистров для таких объектников, чтобы их можно было запускать многократно - т.е. такие робото-объекты смогут переиспользовать свои переменные в разных запусках и помнить своё состояние между запусками... P.P.P.S. Также это означает, что вызывающая программа должна сама очистить память переменных такого объекта перед первым его вызовом (это будет сделано автоматически, если эта память переменных будет располагаться в памяти переменных вызывающей программы)…
|
25 Jul 2024 00:32 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Статистика репы https://gitlab.com/nedopc/sdk с конца 2006 года (т.е. ещё с SourceForge времён CVS): Весной 2018 года был пик это я накидал туда исходников RW1P2 все какие были друг на друга когда переехал на GitHub (а может git отдельными коммитами из CVS добавлял файлы при конверсии в итоге вышел как бы пик), а потом очень скоро (летом 2018) репа переехала на GitLab, где до сих пор и обитает...
|
26 Jul 2024 00:56 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Наверное в копилку софта для nedoPC SDK надо добавить RW1_EDIT, который для меня написал младший брат моей бывшей жены в 1999 году когда он ещё в универе учился - это именно тот редактор, что входил в состав Sprinter SDK by nedoPC (2003), который я называю RW1P2 v1.5: До этого редактор использовался в моей шареварной игре для программистов Robot Warfare 1 v2.x (виндовая версия): Редактор написан на C++ только под Windows и его исходники никогда не публиковались (но они у меня есть т.к. я в 2003 году уже сам этот редактор расширял без помощи первоначального автора, превратив его по сути в IDE для RW1P2) - надо будет его переписать на чистых сях под DOS, а потом уже можно и на Robby портировать... P.S. Либо переписать его на wxWidgets, чтобы могло работать в современной винде, в линухе и в макос?
|
26 Jul 2024 18:41 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Хорошо, что какое-то время назад меня осенило вписать в описание старого проекта на SourceForge линк на новое местоположение репы - теперь все сайты, которые автоматом тянут проекты с SF показывают этот линк
|
27 Jul 2024 11:29 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Самый старый файл в репе с точки зрения гита
|
27 Jul 2024 12:17 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Вот думаю может системе Специалист в SDK вернуть историческое название spec вместо spets? И соответственно specmx вместо spetsmx? Я в своё время решил переименовать spec в spets, чтобы буржуи не путали spec со speccy, однако до мая 2018 года оно таки называлось spec: https://gitlab.com/nedopc/sdk/-/commit/e4fb7feda6b6317dccf87ef09e5ccfaabf99937b
|
28 Jul 2024 03:13 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Гляжу в _VARS.A и там используется в __RULES, но вызов этой подпрограммы можно выкинуть совсем, вставив в __RULES вместо неё LXI_B, @BASE (что суть тоже самое) нигде не используется пока нигде не используется, но может понадобиться в будущем (см. ниже) используется только в _VARS.A используется в __RULES, но вызов этой подпрограммы можно заменить на LXI_B, @BASE и CALL _V_GET используется в __RULES (см.ниже) используется в _VARS.A и __RULES, но вызов этой подпрограммы можно заменить на LXI_B, @REGS и CALL _V_GET с предварительным обнулением регистра H используется в __RULES (см.ниже) используется в __RULES используется в __RULES используется в __RULES используется в __RULES Причём самый часто используемый в сгенерённом коде кусок из __RULES выглядит вот так: Это дело надо упростить, чтобы было как-то так: Соответственно в _VARS.A надо будет добавить "вумную" подпрограмму _X_GET, которая сама будет определять чего от неё хотят - регистр (HL==#FFxx), переменную (HL>=0) или слово из буфера обмена с системой ввода-вывода (#8000...#FEFF) - последнего пока нету, но будет (буфер будет виртуальный - вместо обращения к памяти в данном случае будет вызываться подпрограмма из SYSTEM_.A которая будет возвращать слово по специфическому для системы алгоритму). Аналогичное надо будет проделать вот с этим: Добавив "вумную" подпрограмму _X_SET (устанавливающую регистр или память в зависимости от адреса), а подпрограммы _R_SET и _B_SET выкинуть за ненадобностью. Либо надо написать код прямо по месту т.к. SAVE это редкая операция, которая происходит один раз на выражение, и обращений к буферу файловой подсистемы на запись у нас не предвидится поэтому можно обойтись только вызовом _V_SET с разной базой для регистров и переменных: Единственное тут нету никакой проверки на выход за пределы области переменных (или регистров, коих у нас не более 32), но если компилятор ROBBYC работает корректно, то все смещения должны быть в нужных пределах (ну разве что бинарник будет попорчен при передаче или чтении с диска, тогда конечно да)... P.S. Инициализация регистров Robby (а именно A,B,C и L) у меня сейчас компилируется в относительно компактный код целевой платформы, как и копирование из памяти переменных в регистр и из регистра в память переменных - вот думаю, а не сделать ли в случае платформы 2 (RW1P2) все регистры read/write? И накидать ещё регистров до 32-х, как планировал ранее - тогда простые подпрограммы можно будет писать только на регистрах (для пользователя они будут выглядеть просто как однобуквенные переменные) и они будут работать заметно быстрее...
|
28 Jul 2024 04:01 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Вот вроде сделал _X_GET: Даже удалось воспользоваться тем, что подпрограмма _V_GET идёт следом https://gitlab.com/nedopc/sdk/-/commit/f879a3e3e4e3e7f21a875903f8ca13bdf3f66bb2
|
28 Jul 2024 21:51 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
| | | | Shaos wrote: Добавил в скрипт DEFAULT.N таргет i8080obj для сборки кода не привязанного ни к одной системе (и без картинок), которому можно передать 2 параметра - адрес кода и адрес переменных: https://gitlab.com/nedopc/sdk/-/commit/04126b8fc269abfccea72b29c96b9783d5a28e86Для получения перемещаемого объектника сначала запускаем сборку без параметров - оно будет 0 и 0 по умолчанию Потом смещаем код на сколько-то кратное 256, например собирая с параметрами 0x100 и 0 Потом возвращаем код обратно и смещаем переменные - например собирая с параметрами 0 и 0x100 После этого генерим программно 2 BITMAP таблицы и приклеиваем их сзади к бинарнику собранному с 0 и 0 - эту программу ещё надо написать P.S. Интересным свойством таких объектных файлов будет то, что их можно линковать как статически, добавляя в общий бинарник по нужным адресам, так и динамически - подгружая на лету и храня независимо от вызывающей их программы! т.е. это будут эдакие LIB и DLL в одном флаконе P.P.S. Заодно отключил очистку области переменных и регистров для таких объектников, чтобы их можно было запускать многократно - т.е. такие робото-объекты смогут переиспользовать свои переменные в разных запусках и помнить своё состояние между запусками... P.P.P.S. Также это означает, что вызывающая программа должна сама очистить память переменных такого объекта перед первым его вызовом (это будет сделано автоматически, если эта память переменных будет располагаться в памяти переменных вызывающей программы)… | | | | |
Кстати аргументы (и результаты) можно ведь не только через область переменных передавать, но и через стек Тогда я для объектников ещё и стек не буду переставлять на внутренний - пусть крутятся в стеке вызывающей программы... P.S. Сделал. Заодно унифицировал SAY - теперь он единообразен в Z80 и i8080:
https://gitlab.com/nedopc/sdk/-/commit/a8d2b374b2373de4229ef1d1dd42d9276e8bc7da
P.P.S. Печать 16-битных слов в десятичном виде перекочевала в RW1P2 из моей недоделанной операционки ShaOS (т.е. написано мною "из головы" ещё в 1997 году), но оно там было беззнаковым, а знак я добавил сильно позже - Z80 SAY научился печатать отрицательные десятичные числа ещё в 2006 году (т.е. уже после всех релизов RW1P2), а i8080 SAY - вот только сейчас
|
29 Jul 2024 19:24 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
Ещё надо добавить следующие утилиты: - NEW_PRJ - для создания пустого проекта в поддиректрии PRJ
- OBJMAKER - для сборки перемещаемого объектного файла .O
- OBJINFO - для распечатки информации о файле .O (декодирование хедеров)
А вообще первым делом хорошо бы BIN2TAP научить делать RK и RKS файлы... P.S. В мелких утилитах вижу пару мест, которые на big-endian машинах будут неправильно работать - если буду переносить весь пакет на PowerPC G3/G4, то надо будет подчистить (большие проги там вроде всегда работали типа rasm или robbyc)...
|
30 Jul 2024 09:13 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 23399 Location: Silicon Valley
|
На первой странице этого топика я почти 10 лет назад писал следующее: | | | | Shaos wrote: Ещё одна проблема с RW1P2 была в том, что все переменные и операции 2-байтовые, даже если надо хранить и оперировать однобайтовыми величинами. Есть мысль как это победить (т.е. не кодогенерить лишнего кода если работа идёт с однобайтовыми величинами) - для начала заведём макросы для работы с половинками слов: lobyte и hibyte будут вытаскивать соответствующий байт из слова, а setlobyte и sethibyte будут устанавливать соответствующий байт слова - тогда при интерпретации оно будет работать как написано, а при кодогенерации можно детектировать соответствующие последовательности байткодов и заменять на более простой код целевой платформы: // lobyte(var) #F5 PUSH #?? #?? #F3 LOAD #F5 PUSH 255 #FF #00 #C0 & // прочитать байт по адресу ???? // hibyte(var) #F5 PUSH #?? #?? #F3 LOAD #F5 PUSH 8 #08 #00 #D0 >> #F5 PUSH 255 #FF #00 #C0 & // прочитать байт по адресу ????+1 // setlobyte(var,expression) #F5 PUSH #?? #?? #F5 PUSH #?? #?? #F3 LOAD #F5 PUSH #FF00 #00 #FF #C0 & ....... #F5 PUSH #00FF #FF #00 #C0 & #C1 | #F4 SAVE // произвести вычисления и сохранить однобайтный результат по адресу ???? // sethibyte(var,expression) #F5 PUSH #?? #?? #F5 PUSH #?? #?? #F3 LOAD #F5 PUSH #00FF #FF #00 #C0 & ....... #F5 PUSH 8 #08 #00 #D1 << #C1 | #F4 SAVE // произвести вычисления и сохранить однобайтный результат по адресу ????+1 P.S. Причём вычисления внутри setlobyte/sethibyte можно делать однобайтовыми (и беззнаковыми?) - как минимум сложение, вычитание и логические операции... | | | | |
А можно пойти по пути, по которому пошли другие продвинутые компиляторы сей для 8080 - пробегание специальным оптимизатором по сгенерённому ассемблерному исходнику с заменой распознанных последовательностей инструкций на более оптимальные эквиваленты (см. https://en.wikipedia.org/wiki/Peephole_optimization) - например xm=@hibyte(xm) сейчас скомпилируется вот в такой исходный код Robby: который через Robby-байткод скомпилируется вот в такой 8080 код: | | | | Code: \ *0x40 _j0024: \ 0xF5 PUSH_H LXI_H, #0000 \ 0xF5 PUSH_H LXI_H, #0000 \ 0xF3 CALL _X_GET \ 0xF5 PUSH_H LXI_H, #0008 \ 0xD0 POP_D CALL SHIFTR \ 0xF5 PUSH_H LXI_H, #00FF \ 0xC0 POP_D MOV_A,D ANA_H MOV_H,A MOV_A,E ANA_L MOV_L,A \ 0xF4 POP_D XCHG LXI_B, @BASE MVI_A, #FF SUB_H JNZ _l0004 MOV_H,A LXI_B, @REGS _l0004: CALL _V_SET POP_H
| | | | |
тут например сразу же видно, что вот тут: можно опустить второй LXI_H, #0000 т.к. в HL уже 0 и далее: можно заменить на Первый PUSH_H и последний POP_H тоже можно убрать т.к. они бессмысленны... P.S. Также можно опционально делать оптимизацию по размеру в ущерб скорости (скажем если надо утолкать большую программу Robby в небольшую память микрокомпьютера и на быстродействие наплевать), когда устойчивые конструкции типа: будут заменяться на вызов подпрограмм типа CALL HL_AND_DE P.P.S. Хотя наверное будет проще научить ROBBYCC распознавать паттерны в длинных выражениях (коды операций не совпадают с кодами команд поэтому теоретически их можно отнести к одному классу и работать с ними единообразно), а для опциональной оптимизации по размеру добавить в __RULES условную компиляцию, чтобы для каждой команды одновременно описывались бы быстрая версия и компактная версия...
|
01 Aug 2024 00:05 |
|
|
Who is online |
Users browsing this forum: GPT [Bot] and 2 guests |
|
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
|
|