nedoPC.org

Это же просто INCBIN бинаря со спрайтами надо сделать в сгенерённый ассемблерный исходник программы по заранее известному отступу (скажем 48 байт) - осталось мой RASM научить делать INCBIN (а zmac это уже умеет с 2005 года усилиями Василия Иванова)...

P.S. На самом деле файл TILES.SPR уже является ассемберным файлом (за исключением комментариев, которые записаны как ; а не \ как того хочет RASM), но при компиляции бинарника спрайтов SPR_COMP делает кое-какие манипуляции с атрибутами в соответствии с выбранной платформой, а также может инвертировать саму картинку, если в комментариях есть символ ! - по идее можно просто поправить SPR_COMP, чтобы он генерировал новый ассемблерный исходник описывающий спрайты вместо придумывания как воткнуть INCBIN в RASM...

Короче суть придумки - в списке слов в самом начале блока кода появится слово в котором будет храниться адрес шрифта 8x8 для графических систем и ноль (или FFFF?) для текстовых систем (или систем где используется встроенный в целевую систему шрифт типа speccy с выводом текста через подпрограммы бейсика). Подпрограмма PUTCH пока останется в системных ассемблерных файлах, однако при вызове она будет проверять состояние этой переменной и если там что-то необычное типа #0000 или #FFFF, то ничего не будет печататься. Соответственно пользователь получит возможность через встроенный ассемблер подменить адрес в этой переменной на свой, если он захочет задействовать свой шрифт вместо шрифта nedoPC 8x8 (который я на днях перевёл в категорию PUBLIC DOMAIN чтобы всё содержимое LIB в итоге стало PUBLIC DOMAIN). При старте в этой переменной будет ноль и адрес встроенного шрифта там появится только при первом вызове команды SAY (или PUTCH?), которая будет проверять что там ноль и если да, то будет записывать туда адрес FONT8X8 (а для текстовых систем по видимому туда надо записать что-то ненулевое, но заведомо не являющееся шрифтом, например #FFFF).

Вроде сделал: 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. Нашёл косяк в новой реализации !=

Фуф - всё исправил

Иницализацию _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 для РК даже без битмапов:

	Code: -rw-r--r-- 1 shaos shaos 5004 Aug  4 13:26 MAPGEN.BIN -rw-r--r-- 1 shaos shaos 2924 Aug 11 21:48 MAPGEN.BINFF0 -rw-r--r-- 1 shaos shaos 2381 Aug 11 21:49 MAPGEN.BINFF1

Добавил в скрипт 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. Также это означает, что вызывающая программа должна сама очистить память переменных такого объекта перед первым его вызовом (это будет сделано автоматически, если эта память переменных будет располагаться в памяти переменных вызывающей программы)…

Статистика репы https://gitlab.com/nedopc/sdk с конца 2006 года (т.е. ещё с SourceForge времён CVS):


Весной 2018 года был пик это я накидал туда исходников RW1P2 все какие были друг на друга когда переехал на GitHub (а может git отдельными коммитами из CVS добавлял файлы при конверсии в итоге вышел как бы пик), а потом очень скоро (летом 2018) репа переехала на GitLab, где до сих пор и обитает...

Наверное в копилку софта для 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, чтобы могло работать в современной винде, в линухе и в макос?

Хорошо, что какое-то время назад меня осенило вписать в описание старого проекта на SourceForge линк на новое местоположение репы - теперь все сайты, которые автоматом тянут проекты с SF показывают этот линк

Самый старый файл в репе с точки зрения гита

Вот думаю может системе Специалист в SDK вернуть историческое название spec вместо spets? И соответственно specmx вместо spetsmx? Я в своё время решил переименовать spec в spets, чтобы буржуи не путали spec со speccy, однако до мая 2018 года оно таки называлось spec:

https://gitlab.com/nedopc/sdk/-/commit/e4fb7feda6b6317dccf87ef09e5ccfaabf99937b

Гляжу в _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-х, как планировал ранее - тогда простые подпрограммы можно будет писать только на регистрах (для пользователя они будут выглядеть просто как однобуквенные переменные) и они будут работать заметно быстрее...

Вот вроде сделал _X_GET:
Даже удалось воспользоваться тем, что подпрограмма _V_GET идёт следом

https://gitlab.com/nedopc/sdk/-/commit/f879a3e3e4e3e7f21a875903f8ca13bdf3f66bb2

Кстати аргументы (и результаты) можно ведь не только через область переменных передавать, но и через стек
Тогда я для объектников ещё и стек не буду переставлять на внутренний - пусть крутятся в стеке вызывающей программы...

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 - вот только сейчас

Ещё надо добавить следующие утилиты:

• NEW_PRJ - для создания пустого проекта в поддиректрии PRJ
• OBJMAKER - для сборки перемещаемого объектного файла .O
• OBJINFO - для распечатки информации о файле .O (декодирование хедеров)

А вообще первым делом хорошо бы BIN2TAP научить делать RK и RKS файлы...

P.S. В мелких утилитах вижу пару мест, которые на big-endian машинах будут неправильно работать - если буду переносить весь пакет на PowerPC G3/G4, то надо будет подчистить (большие проги там вроде всегда работали типа rasm или robbyc)...

На первой странице этого топика я почти 10 лет назад писал следующее:
А можно пойти по пути, по которому пошли другие продвинутые компиляторы сей для 8080 - пробегание специальным оптимизатором по сгенерённому ассемблерному исходнику с заменой распознанных последовательностей инструкций на более оптимальные эквиваленты (см. https://en.wikipedia.org/wiki/Peephole_optimization) - например xm=@hibyte(xm) сейчас скомпилируется вот в такой исходный код Robby:
который через Robby-байткод скомпилируется вот в такой 8080 код:
тут например сразу же видно, что вот тут:
можно опустить второй LXI_H, #0000 т.к. в HL уже 0 и далее:
можно заменить на

Первый PUSH_H и последний POP_H тоже можно убрать т.к. они бессмысленны...

P.S. Также можно опционально делать оптимизацию по размеру в ущерб скорости (скажем если надо утолкать большую программу Robby в небольшую память микрокомпьютера и на быстродействие наплевать), когда устойчивые конструкции типа:
будут заменяться на вызов подпрограмм типа CALL HL_AND_DE

P.P.S. Хотя наверное будет проще научить ROBBYCC распознавать паттерны в длинных выражениях (коды операций не совпадают с кодами команд поэтому теоретически их можно отнести к одному классу и работать с ними единообразно), а для опциональной оптимизации по размеру добавить в __RULES условную компиляцию, чтобы для каждой команды одновременно описывались бы быстрая версия и компактная версия...