https://bitbucket.org/djdron/unrealspeccyp/downloads/
SDL 2 эмуль несёт с собой.
Пример DemoRus работает на процедуре LITERY из пакета New Supercode. Я конечно самую малость её адаптировал для работы с ZXDev, но ничего принципиального я не дорабатывал. Где же тогда баг? В New Supercode?
Делаем это так! (очищаем эти переменные для нашей копии окружения, не трогая внешних):Цитата:
Сообщение от andrews
Вложение 78450
Это в каком файле?
XDev/Mod/ZXDev.odc и Cmd.odc
как оказалось в sdcc. У Вас в архиве( ссылку давали на скачивание была версия март 2022года), а в других архивах ноябрьская 2022г( 07.11.2022г). Взял перекопировал весь h:\XDevLite\ZXDev\Bin поверх того, что скачивал по вашей ссылке. Теперь демки почти все строятся, запускаются даже в моих эмуляторах. Уточняю, остались ли какие-то неработающие.Цитата:
Сообщение от Oleg N. Cher
- - - Добавлено - - -
это видимо нужно исходники пересобирать. Пока оставил ту времянку(сломаные батники), которая у меня была. С ней тоже работает.Цитата:
Сообщение от Oleg N. Cher
Да просто скачайте новый XDevLite, который я для Вас сделал.
Билд SDCC может быть нестабильный. Если качаете промежуточные билды - обратите внимание на птички, что билд прошёл все тесты.
Возможно, надо пересобрать библиотеки новой версией SDCC.
- - - Добавлено - - -
В том архиве с ZXDev такая версия SDCC, которую я до сих пор считаю самой стабильной, а я собираю достаточно сложный код. Более новые версии на Ваш страх и риск. Просто не торопитесь писать как всё плохо с Обероном, а то все читают и делают выводы.Цитата:
Сообщение от andrews
Я не пишу что плохо с Обероном. Моя компетенция в нем, как языке программирования в данный момент нулевая!
И следовательно и о его конкретной реализации судить не могу.
Просто я привожу результаты тестирования на моей Windows7 32 бит. Причем еще ни строчки не изменив в примерах. Кажется это логично, имея исходники .mod и их же .tap на выходе, для начала их просто пересобрать и убедиться в работоспособности и идентичности результатов прежде чем приступать к написанию собственного кода.
Я всегда так делаю на протяжении вот уже 40 с лишним лет. А то, что ж буду убивать свое время на изучение Оберона, если у меня цель что-то сделать для Спектрума, если у меня в руках нет работоспособного инструмента?
( У меня куча проектов из-за этого провалилась( да вот тот же НФСП), да и чисто программистских тоже пару раз в двух фирмах. Было все в руках для успешной реализации кроме малюсенького звена из-за которого "все накрылось медным тазом"!
Вспоминаем из детства переведенные с английского стихи Маршака про подкову.
"Враг вступает в город,
Пленных не щадя,
Оттого, что в кузнице
Не было гвоздя"
Так что в этом смысле я стрелянный воробей!)
У меня все они успешно пересобрались и работоспособны при наличии в h:\XDevLite\ZXDev\Bin sdcc ver 3.9.3 #11378(MINGW32)
а версия 4.2.0 этого не обеспечивала. То есть она .tap-ы собирала, но другие! Сравнивал файлы побайтно, видел различия, ну и работали они в одном и том же эмуляторе совершенно по другому. Но однако работали, что удивительно.
А почему более свежая версия имела датой файлов март 2022г., а более ранняя ноябрь 2022г это вопрос не ко мне.
Видимо кто-то взял более свежую версию sdcc и убедился в том же, что и я. А что там такое изменили, что изменилась генерация выходного кода...я точно не разберусь. Просто об этом бы надо в READ.ME написать. Это никак не умаление крутости IMHO. А просто забота о пользователе, чтобы он с ума не сходил, почему у людей все работает, а у него дурака не работает.
А то будет как в рассказе Остапа Вишни про охоту на медведя( где медведь сам себе сломал голову).
Ну, если пользователь подменил SDCC, который идёт в комплекте, на другую версию, то пусть пеняет на себя.
Прикольно было бы иметь такую среду ретро-разработки, чтобы входные языки были разные и чтобы пристёгивались как плагины. Потом какой-то промежуточный язык типа байт-кода. И кодогенераторы в разные платформы. Над всем этим крутая IDE с контекстным хелпом. И отладчик.
И чтобы платформы пристёгивались как плагины. А библиотеки были под конкретно одну платформу или с заявленной поддержкой нескольких, допустим, эта спрайтовая графическая библиотека - под C64 и ZX Spectrum. А эта под NES и SEGA MegaDrive. И если игра базируется на этой библиотеке, то её можно собрать и для NES, и для MegaDrive.
Или - есть библиотека звука на бипер под Вектор и Корвет.
Или - библиотека поддержки джойстика с настройкой свойств, притом некоторые настраиваются статически (т.е. условными символами макропроцессора). Берёшь библиотеку, добавляешь к своему проекту. Открываешь диспетчер свойств и настраиваешь её.
Или - библиотека: консоль 32x24 15 цветов. Совместима со Спектрумом, но может эмулироваться и на других платформах.
Я понимаю о куче условностей и проблем. Но такой подход с мультиплатформенными библиотеками мог бы помочь сгладить различия между платформами. В конце концов, примерно к этому набору идей я стремился при разработке XDev.
Был такой компилер Странник, русский. Входные языки Си-Паскаль-Модула. И единый бэкэнд.
В общем, что-то такое, чем бы мог стать этот Rascal, но не станет, по кр. мере для меня.
В общем, всё ж на поверхности.
Такой проект мог бы быть на LLVM, но там всё плохо с восьмибитными платформами. Нужен свой супер-кодогенератор для мира 8 бит. Ну и не только 8 конечно, но и 16. И куча входных языков. Паскаль уж обязательно. Это чтобы не было холиваров какой язык лучше (хотя всё равно будут).
Хэйтерам: да, шоб писать крестики-нолики. Но вы не догоняете, что этот подход может иметь намного более широкое применение, чем вам кажется.
Чудеса. В SDCC появилась поддержка проца MOS 6502:
И, как оказалось, есть бэк-энд в 6502 для LLVM:
- - - Добавлено - - -
Искал LLVM для PDP-11, но нашёл только это: