Мега гонднота подъехала! Энтузиасты сделали браузерный эмулятор телефонов Nokia 3310/3410/3350/3330/5110/5210/7110. Это полноценный эмулятор этих телефонов прямо в браузере, всё работает как в оригиналах. Также можно погонять в Space Impact и змейку
Всем отличного времяпровождения!
Разработчик Михаил Шероносов (известный под ником @ramfactory) опубликовал на «Хабре» подробный разбор своего нового хардкорного ретро-проекта. Он смог запустить полноценный эмулятор компьютера ZX Spectrum внутри 16-битной игровой приставки SEGA Mega Drive.
Для реализации идеи автор использовал кастомный флеш-картридж на базе современной программируемой логической интегральной схемы (ПЛИС/FPGA) Altera Cyclone IV. Несмотря на то, что внутри Mega Drive установлен процессор Z80, использовать его напрямую оказалось невозможно из-за специфической обвязки и жестких таймингов консоли. Единственным выходом стало развёртывание полноценного ядра Z80 с нуля прямо внутри кристалла FPGA.
Столкновение двух миров и аппаратные тупики
Проект, который изначально казался лёгкой трёхдневной прогулкой, едва не утонул в суровых аппаратных ограничениях видеоконтроллера SEGA VDP. Главная сложность заключалась в принципиальной разнице вывода графики: ZX Spectrum использует попиксельный метод (bitmap), тогда как Mega Drive умеет работать только с готовыми тайлами (сеткой 8x8 пикселей).Чтобы спроецировать экран «Спектрума» на Сегу, автору потребовалось заполнять рабочую область из 768 уникальных тайлов. Это привело к трём критическим проблемам:
Лимит шины данных: Массив тайлов весит 24 КБ, а DMA-контроллер консоли SEGA в режиме NTSC за время обратного хода луча (VBLANK) физически способен прокачать лишь около 7.3 КБ. При нехватке скорости картинка разрывалась на куски.
Эффект бордюра (HBLANK): Фирменные полосы загрузки требуют мгновенной подмены цветов палитры во время обратного хода строки, на что у консоли просто не хватало времени.
Экранная клавиатура: Для управления играми Spectrum необходим оверлей с клавиатурой, который создаёт дополнительную огромную нагрузку на видеопамять.
Как была обманута система
Разработчик решил проблему радикально — спроектировал кастомный сопроцессор ZX_SEGA_VIDEO прямо внутри FPGA. Вместо того чтобы гонять «сырые» тяжёлые данные через медленную шину консоли, это ядро «на лету» перехватывает обращения к памяти, вычисляет изменения атрибутов и подсовывает видеоконтроллеру Сежки нужные данные ровно в те микросекунды, когда это необходимо.
Дополнительно в кристалл ПЛИС внедрили звуковое ядро YM2149 с безопасной схемой стерео-микширования ABC, что исключило цифровой хрип и обеспечило чистый легендарный AY-звук.
Ламповая загрузка с кассет
Эмулятор отлично работает с ромами (.SNA и .Z80). Но для истинных ценителей ретро-атмосферы автор реализовал аппаратный «магнитофон» на FIFO-буфере.
Теперь на консоли можно запустить оригинальные файлы .TZX. На экране под легендарный цифровой скрежет EAR-звука начинают честно бежать сине-красные и желто-синие полосы загрузки по бордюру Сеги. Проект, подробнее о котором, технических деталях и разработке вы сможете подробнее прочитать в оригинальной статье автора на «Хабре», стал впечатляющим гибридным трибьютом двум культовым платформам прошлого.
Добрый день. Возможно у кого нибудь есть удачный опыт этого действа
В муму вроде бы есть штатный клонер приложений, но склонированная игра дальше заставки не идет, даже если запущена только она одна.
Пробовал сторонние приложения, вроде апп клонер, блэк чего то там. Тоже самое.
Хотя не, апп клонер попросил денег, за то что пытался склонировать игру, юзающую ODBC.
Я понимаю что есть вариант запускать несколько окон например bluestack. Но оно прожорливое очень. Муму гораздо лучше, но работает только на домашнем компе. На рабочем у него HAPP квн клиент не пашет почему то. Вылетает при попытке создания квн-канала.
Когда-то давно решил помочь своей конторе с сайтом (тем более, что мне нравится это всё). Т.к. я довольно жадный, то решил, что платить 160р в месяц хостеру это дофига. Тем более, что это просто место на диске. Тем более, что его всего ничего 2гб, а не 160 как у меня. Внешний статический ip имелся в наличии и я полез изучать тему.
В интернете писали о том, что хорошо подходит для таких дел freebsd (на тот момент 9 версии). Поставил эмулятор операционной системы в винде и приступил к процессу.
С Линуксом я немного имел опыта до этого, а вот с Юниксом нет и было очень интересно чем это закончится. По инструкции и интернета и видео уроков от Беши (так вроде звали этого картавого) мне удалось установить ось, поднять на ней php, mysql, ftp и т.п. штуки для успешного развёртывания сайта. В процессе я ощутил всю прелесть командной строки: удобство установки программ одной командой из портов, всяких обновлений и т.д. Всё это происходило не без проблем и ошибок, но в итоге я с гордостью наблюдал "хеллоу ворд" по адресу 192.168....
Но этого мне было мало. Я, как виндузятник со стажем, не желал топтать клаву, а хотел мышью окна закрывать. Что ж... есть же удобная консоль, куда можно ввести команду, оно установится и заработает. Ведь установится и заработает? *Падме.жпг*
Правдой из этого была только первая часть. Дальше начинался секис. Эта штука зависала при запуске либо сыпала ошибки из эмулированного рога изобилия на чёрном экране. Что я только не делал. Ещё и информации было очень мало об этом. Терзал я это дело очень долго. Уже и не помню сколько. Может месяц, может дольше. В итоге удалось победить этот чёртов чёрный экран и я увидел то, ради чего началась эта сексуальная драма: графический интерфейс, мышка, иконки, обои на рабочем столе. Радость была выше крыши. Тепрь-то мы всё как надо сделаем, теперь-то оно заработает как я хочу. Погнали!
И вот тут снова появляется эта *Падме.жпг*. Тогда ещё небыло этого мема, но был он очень в тему. Как говорится всё познаётся в сравнении. Я быстро понял, что намного проще и быстрее набрать make&install, чем что-то качать, пытаться запустить. Плюс все было засунуто хрен пойми куда. Чтоб найти какую-то настройку нужно долго искать где это вообще находится. И не факт, что найдёшь.
В общем я понял, что графика в данном случае зло и вернул всё как было в начале.
Ну и в процессе узнал, что сделать сайт на своём компе можно и даже открыть доступ к нему всем, но как быть с безопасностью? Пока я мучался с графикой, на сайте появились первые посетители и какие-то гомосекиенсы начали самозабвенно брутфорсить админку. Узнал я об этом из гневного письма хостера о сильном превышении нагрузки. Полез изучать логи и ахренел от количества запросов post. Заставив этого пидрика кушать ошибку 403 вместо "неверное имя или пароль", я задумался. Стоят ли эти жалкие 160р всего того, с чем я могу столкнуться? Может и стоят, но, прикинув количество киловатт, которые будут к оплате в конце месяца, моя жаба убрала одну лапу с шеи и поток свежего кислорода в мозг позволил понять, что разница будет уже не столь велика.
В общем бросил я это гиблое дело. Однако мне очень понравилась эта операционная система. Я никогда не думал, что может быть настолько удобно пользоваться консолью. Но применения этому я так и не нашёл. Сайт всё так же крутится у того же хостера уже много лет.
P.S. Хостер на сообщение о том, что меня ломают и не хотел бы он слегка прибить гада ответил, что проблемы индейцев всегда были и будут проблемами индейцев.
Который был оживлен и запущен в эмуляторе, спустя 40 лет после банкротства компании‑создателя. Самая редкая операционная система и самое редкое железо из всего что автор когда‑либо видел за жизнь.
Ни один житель СССР и РФ не мог видеть эти строчки запуска, поскольку машины Plexus были редкостью даже в самих США и абсолютно точно их продукция никогда не попадала в наши края.
Всего было создано около 2500 таких машин, производила их с 1980 по 1988 небольшая калифорнийская компания Plexus Computers:
3833 North First Street San Jose, California, 95134, United States (408)943-9433
В 1989 году компания обанкротилась и производство было остановлено навсегда. Вот тут выложен интересный PDF-документ с отсканированной брошюрой, описывающей их продукцию:
Еще кто-то выложил в сеть отсканированное руководство администратора для одной из последних моделей Plexus P/90:
Вот так выглядит один из последних сохранившихся образцов, Plexus P/75:
Кнопка запуска вблизи:
Обратите внимание на бежевые панели - это не пластик а самое настоящее железо.
Как видите предки понимали в капитальных решениях, примерно такой кнопкой у нас запускают стратегические ракеты.
Вот так выглядит еще один из доживших образцов попроще — Plexus P/35:
Эта же модель на брошюре с описанием возможностей, в свои лучшие годы:
Еще один отсканированный обзор:
В 2024м году одному компьютерному энтузиасту из Калифорнии удалось заполучить Plexus P/20 в свои лапы и вернуть его к жизни. Весь процесс оживления, а также детальный обзор этой машины он записал в серию видео, которые затем выложил на Ютуб.
Но это еще не все, поскольку довольно быстро в комментариях под видео появились живые свидетели, заставшие эти удивительные машины:
About Plexus Computer, Inc. : It started operating in 1981 and in 1988 sold its Unix and hardware side of their business to Motorola. By this time they 've already gone up to the 68020 processor with up to 48 MB of RAM and adopted the VMEbus in their P/95 product. They kept on developing their expensive and niche software imaging products under chapter 11 protection (bankruptcy) until 1989 when they finally sold the remaining software assets to "Recognition Equipment".
Сочетание фраз up to 48 MB of RAM и 1988 год думаю заставит дернуться не один читательский глаз.
Как видите, если создать действительно неубиваемый сервер — им будут пользоваться и через 20 лет после банкротства производителя:
So cool to see one of those again! I worked for a Circuit City location years ago that in the 2000s was still running serial terminals over a PLEXUS server. I do know it was based on 68030 CPUs, with a pair of 160MB SCSI drives in mirror. But it so happened that I was the only non-corporate person who had root level login on the command line. The rest of the store was based on a locked menu for sales, inventory management, etc. I had just quit consulting and as the ONLY person on site with Unix certificates, I got saddled with emergency on-call. It never happened, but oh that brings back memories!
Обратите внимание на объемы: диски по 160 мегабайт в 1988м году (!), времена ленточных накопителей и дискет на 360 килобайт.
В 2024м году команда энтузиастов смогла реализовать полноценный эмулятор этой редкой машины:
This emulator emulates most aspects of a Plexus P/20 system: you can boot from a hard disk image, log into UNIX and play around. The things currently unsupported are the tape drive, floppy drive, and any Multibus cards.
Если вы простой обыватель, далекий от UNIX и программирования, но каким‑то удивительным образом дочитали до этого места — у эмулятора существует веб‑версия, которая позволит увидеть UNIX System 5.2 в работе без описанных ниже приседаний со сборкой из исходников и запуском.
Мы же пойдем как обычно путем хардкора — соберем и запустим все собственными руками. Проект эмулятора свежий, поэтому спокойно и без ошибок собирается самым обычным штатным clang на FreeBSD:
cc -v
FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67)
Target: x86_64-unknown-freebsd14.2
Thread model: posix
InstalledDir: /usr/bin
Поэтому проблем со сборкой в линуксе не будет.
Но в Windows/Mac так просто проект не соберется — соответствующих ветвлений в исходниках нет.
Забираем проект, внутри всего одна ветка — текущая:
Собираем:
cd plexus_20_emu
gmake
Эмулятор маленький, собирается очень быстро, после сборки появится готовый бинарник emu:
Для работы эмулятора необходимы два ROM-файла и образ диска, все три находятся в соседнем репозитории с информацией по Plexus P/20.
Вот так выглядит вся последовательность действий:
git clone https://github.com/misterblack1/plexus-p20.git
cd plexus-p20
cp ROMs/U1*-MERGED.BIN ../plexus_20_emu/
cp disk/plexus-sanitized.img.gz ../plexus_20_emu/
gunzip ../plexus_20_emu/plexus-sanitized.img.gz
В результате в корневом каталоге эмулятора у вас должно появиться три файла: два.BIN и один.img. Их имена зашиты в код эмулятора, поэтому переименовывать нельзя.
Запускаем эмулятор:
./emu
После прохождения тестов оборудования появится стадия single mode:
Для продолжения загрузки в многопользовательский режим, введите:
init 2
Появится диалог задания даты и времени, думаю очевидно что тут есть проблема 2000 и задать можно только дату до 1996го года.
Затем пойдут проверки файловой системы:
И наконец появится приглашение авторизации:
Введите root, затем вместо ввода пароля нажмите <Enter>, появится приглашение командной строки от суперпользователя, с полным доступом:
Добро пожаловать в самый редкий UNIX на свете:
Вот так выглядит список процессов:
Вывод корневых каталогов:
Поскольку образ диска был снят с реальной машины, в системе есть пользователь adrian (тот самый энтузиаст), в домашнем каталоге которого есть кое‑что интересное, в частности инструкции по работе в этой системе.
Для попадания можно использовать.. стандартный su:
su adrian
Или же зайти под ним из приглашения (пароля нет):
В системе есть cat и работают пайпы:
И даже есть вот такой артефакт:
Вывод содержимого классического /etc/passwd, до сих пор присутствующего во всех UNIX-системах:
Как видите в системе используется C shell (csh), расположенный в весьма нестандартном месте:
/usr/plx/csh
К сожалению man-ы (системные руководства и справка по командам) повреждены:
Вот так выглядят переменные окружения:
Есть vi, grep, find, bison и компилятор Си:
Удивительная система из далекого прошлого, о которой я абсолютно ничего не знал пока не наткнулся на видео от Адриана.
Статья была опубликована на Хабре, оригинал статьи как обычно в нашем блоге.
Если вам успели надоесть и азиатки и знойные африканки и даже развратные животные, рассказываю про одну редкую UNIX-систему из далекого прошлого, которая был возвращена из небытия и выведена в интернет.
Так это выглядит в работе.
OSF/1 это еще одна редкая UNIX-система из далекого прошлого, которую вы врядли могли наблюдать в живую:
OSF/1 is a variant of the Unix operating system developed by the Open Software Foundation during the late 1980s and early 1990s. OSF/1 is one of the first operating systems to have used the Mach kernel developed at Carnegie Mellon University, and is probably best known as the native Unix operating system for DEC Alpha architecture systems.
Прямой участник корпоративных Unix‑разборок 90х известных как Unix Wars, но в отличие от A/UX (которую автор оживил и запустил в прошлом выпуске) OSF/1 не канула в лету в бурные 90е а будучи переименованной в TRUE64 UNIX поддерживалась аж до 2012го года.
Вот вам и «динозавр», внезапно отказавшийся умирать.
Еще из интересных фактов стоит упомянуть использование этой ОС для суперкомпьютеров:
IBM used OSF/1 as the basis of the AIX/ESA operating system for System/370 and System/390 mainframes.[12] Intel Paragon supercomputers used a version of OSF/1 featuring the Mach 3.0 kernel.[13] OSF/1 was also ported by Kendall Square Research to its proprietary microarchitecture used in the KSR1 supercomputer.
Суперкомпьютер KSR1 Единственное фото в приличном разрешении этой редкой машины.
А также попытку адаптации компанией Apple в качестве замены A/UX:
Apple Computer intended to base A/UX 4.0 for its PowerPC-based Macintoshes upon OSF/1,[11] but the project was cancelled and PowerOpen deprecated.
Которая была отменена вместе с самой A/UX.
OpenBSD/luna88k running inside GXemul, on an emulated SGI O2 running OpenBSD/sgi (on a FreeBSD/amd64 host). Теперь попробуйте осознать прочитанное.
Полностью оно называется Gavare's eXperimental Emulator за авторством Anders Gavare и согласно официальному описанию с сайта проекта, считает себя фреймворком для виртуализации:
GXemul is a framework for full-system computer architecture emulation, mostly written in 2003-2005. Several real machines were implemented within the framework, consisting of processors (ARM, MIPS, Motorola 88K, PowerPC, and SuperH) and surrounding hardware components such as framebuffers, interrupt controllers, busses, disk controllers, and serial controllers. The emulation is working well enough to allow several unmodified "guest" operating systems to run.
По сути это такой сильно разросшийся «pet project», созданный одним энтузиастом ради эмуляции особо редких систем:
ARM
MIPS
DECstation 5000/200 (NetBSD/pmax, OpenBSD/pmax, Ultrix, Linux/DECstation, Sprite, Mach), DECstation 5000/1xx (raw PROM)
Motorola 88K
PowerPC
SuperH
Простым обывателям из этого списка знакомы наверное только игровые платформы, в лучшем случае еще «малинка» (Rastberri Pi) а про некоторые особо редкие не знал даже автор, так что будут еще изыскания и эксперименты, посвященные этому удивительному проекту.
К сожалению эмулятор достаточно давно не развивается, его последняя релизная версия 0.7.0 была выпущена в далеком уже 2021м году и содержала лишь мелкие исправления. Поэтому есть определенные проблемы со сборкой в современном окружении, которые опять придется исправлять вручную.
В этот раз все действия производились на обычном Mageia Linux, без BSD и прочих изысков, с использованием стандартного GCC:
Несмотря на строчку из документации по сборке:
This should work on most Unix-like systems, with few or no modifications to the source code. The basic requirement is a reasonably modern C compiler (C99).
Эмулятор написан все же на C++ а не на чистом С, поэтому для сборки требуется компилятор C++, который ныне устанавливается отдельным пакетом.
Но в остальном автор не врет:
GXemul does not require any additional third-party libraries to build.
И проект действительно не использует никаких внешних библиотек. Кроме X11, ради эмуляции графического экрана:
X11 headers and libraries: for graphical framebuffer emulation.
Так что ничего дополнительно устанавливать не придется.
С версии 0.6 разработка переехала на Github, откуда мы и заберем последние правки исходников (ветка master):
git clone https://github.com/BitEdits/gxe.git
Главная проблема с этим эмулятором — неправильная работа с некоторыми эмулируемыми ОС без специального ключа сборки --debug:
When compiling on Linux via a modern GCC please bear in mind that the emulator wont work correctly if compiled with -O optimization flags. Please use -debug configure option to disable such optimization
Что выяснилось далеко не с первой попытки.
Изучаемая OSF/1 как раз из числа проблемных, поэтому попытка запуска в версии эмулятора, собранного без этого волшебного ключа выдает kernel panic:
Теперь вы тоже видели как выглядел kernel panic в 1992м, поздравляю.
Согласно официальному описанию, ключ --debug всего лишь отвечает за отладочную сборку:
configure for a debug build (turn off optimizations)
На практике все несколько сложнее и этим ключом помимо отключения оптимизаций, еще собирается отдельный оконный отладчик. Чтобы не вводить параметр каждый раз, я прописал в начале скрипта configure вот такой параметр:
DEBUG=YES
Скрипт кстати не из известного пакета autotools а полностью собственной разработки. После каждой правки configure скрипта или шаблонов Makefile.skel (см. ниже) необходимо перезапускать настройку вызовом:
./configure
Теперь запускаем make для запуска сборки и ждем приключений.
Первая ошибка не заставит себя ждать:
Связана она с изменениями в спецификации самого языка C++ и по-хорошему стоило бы эту логику переделать. Но поскольку это не мой личный проект, пошел по пути упрощения — просто переключив используемую версию спецификации при сборке.
Файл, в котором появляется эта ошибка, включается в сборку только при ключе --debug , так что без него вы эту ошибку вообще не увидите.
В файле src/main/Makefile.skel в конец значения параметра CXXFLAGS необходимо дописать указание на версию спецификации --std=c++14:
CXXFLAGS=$(CWARNINGS) $(COPTIM) $(DINCLUDE) -std=c++14
Заново запускаем configure и сборку:
./configure
make
Следующая ошибка также связана с изменением в поведении компилятора:
И да, эта ошибка также обоснована и по хорошему код стоит отрефакторить. Когда-нибудь потом.
А на сейчас я просто отключил предупреждение, добавив в файл src/main/promemul/Makefile.skel параметр -Wno-narrowing:
CXXFLAGS=$(CWARNINGS) $(COPTIM) $(DINCLUDE) -Wno-narrowing
Повторно запускаем configure и сборку:
./configure
make
В этот раз сборка должна завершиться успешно и в корне проекта появится бинарник gxemul:
К сожалению не удалось найти установочный диск OSF/1, поэтому я использовал готовый образ диска, в котором ОС уже была развернута.
Взят он был отсюда, также продублирован в нашем Телеграм-канале, если владелец сайта вдруг решит заблокировать доступ.
Команда запуска выглядит так:
./gxemul -e 3max -X -d osf1_mips.img -j vmunix
Где -e 3max указание на тип эмулируемой машины, 3max это например DECstation 5000/200 (3MAX):
Ключ -X указывает использовать графический фреймбуфер, без него вы не увидите графического приглашения. Ключ -d указывает на путь к образу диска (в архиве по ссылке выше) а вот -j это уже особая уличная магия:
-j name set the name of the kernel;
for DECstation emulation, this passes the name to the bootloader, for example: --j netbsd (NetBSD/pmax)
-j bsd (OpenBSD/pmax)
-j vmsprite (Sprite/pmax)
-j vmunix (Ultrix/RISC)
Войти в систему можно под учетной записью root с паролем Jaguar64.
Новый пользователь создается в терминале xterm, с помощью команды adduser:
Изменить пароль можно стандартной командой passwd.
Разумеется без поддержки сети толку от такой эмуляции было бы немного. К счастью эмулятор сделает за вас большую часть работы по пробросу сети в эмулируемую систему (сторону хоста) — сам поднимет виртуальный интерфейс, назначит IP‑адрес и даже выставит DNS.
Вам остается только вторая половина — настроить сеть в системе 1992 года.
Как уже описал выше, эмулятор сам создает виртуальный сетевой адаптер, который со стороны гостевой OSF/1 называется ln0.
Должна отрабатывать команда:
ifconfig ln0
В выводе должно быть видно текущее состояние адаптера.
Также эмулятор самостоятельно создает исходящий адаптер с IP-адресом 10.0.0.254, который также является маршрутизатором.
Эти детали отображаются в консоли при запуске эмулятора:
simulated network: 10.0.0.0/8 (max outgoing: TCP=100, UDP=100) simulated gateway+nameserver: 10.0.0.254 (60:50:40:30:20:10) simulated nameserver uses real nameserver 192.168.1.1
Так выглядит запрос состояния устройства со стороны гостевой OSF/1:
Как только назначим IP-адрес 10.0.0.2 виртуальному адаптеру, должна отрабатывать команда pingк хосту:
Таким образом обеспечен сетевой доступ к хосту из гостевой ОС.
Но чтобы заработал доступ еще и наружу — в интернет, необходимо включить маршрутизацию в гостевой ОС (со стороны хоста это NAT):
В этот момент автор наткнулся на свежую статью 2024го года от Kevin Read, где случились два важных открытия:
в интернете есть более современная версия OSF/1 2.0 (да оно официально так называется),
существует и подробно описана стандартная настройка сети.
Шаги настройки описанные выше в правильной версии закрываются командой netsetup:
Так вы получите базовую настройку сети и маршрутизацию, но вот с DNS все несколько сложнее. Отвечает за настройку работы резолвера команда bindsetup:
Вся последовательность выглядит как-то так:
Enter the default BIND domain name []: localdomain
Enter your choice [c]: c
Enter the host name of a BIND server: vigor
Enter the Internet address for 10.0.0.254. []: 10.0.0.254
# affected: /etc/rc.config, /etc/hosts
Would you like to run svcsetup now to edit the /etc/svc.conf file (y/n) [y] ?
Enter your choice(s).
For example "0 3 5" [no default] : 2 "hosts" database [2]: 3
# affected: /etc/svc.conf
# hosts: local,bind
Главное это задать IP-адрес хоста, который отвечает за DNS.
В результате всех этих манипуляций должен отрабатывать ping из гостевой OSF/1 и с использованием доменного имени:
С помощью образов дисков, взятых отсюда, удалось запустить и версию 2.0 этой системы:
Отличить можно по качеству картинки - в 2.0 версии больше цветов. Учетная запись в этой копии: root/test123
Команда запуска также несколько отличается:
./gxemul -X -e 3max -d osf1-2.0-root-full.img -d osf1-2.0-opt.img -M 128 -j genvmunix
Еще тут в каталоге /usr/local/src находится куча полезного софта в виде исходников, для примера удалось запустить сборку bash:
К сожалению не до конца:
Хотя Kevin пишет что should compile fine:
The installed MIPS C compiler is good enough to compile some basic things, and gcc 2.9.5 should compile fine. Apparently binutils is broken, but ld is installed anyway.
Думаю реальная проблема в лицензиях, которые в те времена выдавались на компиляторы в коммерческих UNIX-системах.
Вот вам занятие на выходные) Добавил в раздел PSP полный сет из 293 игр серии PlayStation minis (PS minis), там теперь есть соответствующая вкладка Minis. Это игры от независимых разработчиков распространявшиеся через PS Store. Там можно найти крутые игры различных жанров - аркады, казуалки, битемапы, стратегии и многое другое.
Производительность отличная!
![Эмулятор PSP в браузере [БОЛЬШОЕ игровое обновление]](https://cs20.pikabu.ru/s/2026/06/19/17/xmfspqdh.jpg)
Всем отличного времяпровождения!
Конец ноября в Питере — крайне мрачное время года, на улице лишь холод, сырость и уныние. Что определенно влияет на психику местных обитателей, порождая в головах самые нездоровые желания и идеи, которые затем попадают в криминальную хронику.
Видимо по этой причине, одним мрачным осенним днем мне захотелось создать графическое приложение на современном C++ под.. классический Mac из 90х.
В действии.
Честно не знаю что вам сказать, на этот раз у меня нет оправданий или логических объяснений для того что я опять сотворил.
Cпишем на плохую погоду и рептилоидов с Нибиру:
рассказываю и показываю как создавать приложения на современном C++ для классического Apple Macintosh начала 90х.
Примерно такого:
Macintosh Quadra 700. Компьютер как компьютер.
The Macintosh Quadra 700 is a personal computer designed, manufactured and sold by Apple Computer from October 1991 to March 1993.
Сам я никогда не видел такие машины в живую, поскольку в годы когда они выпускались был совсем зеленой школотой и жил в далеких сибирских пердях. Хотя даже живи я посреди Нью-Йорка в 90е — врядли бы смог позволить компьютер за почти шесть штук баксов:
The Quadra 700 originally had a list price of US$5,700
Такое и сегодня далеко не для всех.
Однако времена славы Макинтошей давно прошли, ныне все эти некогда «звездные» компьютеры — те что еще остались в рабочем состоянии, являются музейными экспонатами и предметами коллекционирования.
Поэтому, то что опишу ниже — точно не имеет никакого практического применения:
все это лишь эталонная, дистиллированная дичь, без примесей и добавок.
Это на тот случай, если вы вдруг ожидаете от статьи чего-то большего.
Весь сетап целиком.
Все началось, когда были выкованы мегакольц.. ээ нет, это из немного другой эпической сказки. В нашей все было проще — автор самым банальным образом набрел в сети на один интересный репозиторий, обещающий экзотическое путешествие в мир ужаса неведомые дали:
A GCC-based cross-compilation environment for 68K and PowerPC Macs. Why? Because there is no decent C++17 Compiler targeting Apple's System 6. If that's not a sufficient reason for you, I'm sure you will find something more useful elsewhere.
Разве можно было пройти мимо столь вдохновляющего описания?
Я тоже не удержался, убив в итоге несколько лишних дней на оживление и запуск этого чудовища чуда. Но прежде чем пойдем дальше, стоит рассказать читателям немного старой доброй матчасти:
почему автор так возбудился на какой-то неведомый набор консольных программ
без картинок с голыми женщинами, еще и делающий с точки зрения обывателя не пойми что.
Представьте, что на вашем столе лежит вот такой кусок текстолита с железом, для которого надо написать программу:
Хотя именно этот девайс на самом деле весьма мощный.
Да, на фото выше самый настоящий компьютер:
c процессором, памятью и портами ввода-вывода — все как положено.
Но только слишком слабый для развертывания полноценной среды разработки непосредственно на нем.
Поэтому если вы не маньяк-психопат LISP-разработчик — будет откровенно сложно вести какую-либо разработку на такой хне без кросс-компиляции.
Кросс-компиляция это когда на обычном офисном компьютере без отрыва от игор cобирается приложение, предназначенное для запуска на принципиально другом устройстве:
смартфоне, роутере, соковыжималке, встраиваемой платформе умного дома, коптере или еще каком боевом роботе.
Или на другой операционной системе — сборка на линуксе под Windows это тоже вполне себе кросс-компиляция.
Тулчейн для кросс-компиляции обычно устанавливается (и даже собирается) отдельно, часто бывая очень сложным. Еще он содержит компиляторы, линкеры, ассемблеры для «вражеской» архитектуры и многое другое, не менее интересное.
В некоторых случаях тулчейн включает и части целевой системы:
заголовочные файлы, ресурсы и даже готовые библиотеки для линковки.
Без которых создавать что-то сложнее «Hello, world» с помощью кросс-компиляции было бы проблематично.
Так выглядит тот самый "Hello,world", собранный через кросс-компиляцию и запущенный в эмуляторе с MacOS 7.
Теперь, после раскрытия матчасти можно переходить к этому замечательному проекту, чтобы оценить по достоинству масштаб проделанной работы и ее важность:
a gcc-based cross-compiler for classic 68K and PPC Macintoshes
Во-первых «gcc-based», что означает определенную совместимость с нормальными и современными компиляторами, а также отсутствие экзотических проблем, характерных для редких и/или устаревших компиляторов, вроде bcc.
Во-вторых тут две разных целевых архитектуры: 68k и PowerPC.
А значит можно собирать софт для всей линейки Маков с начала 90х и до начала 2000х — до MacOS X Tiger, последней поддерживающей архитектуру PowerPC.
Но пожалуй самое важное это поддержка трех разных UI-фреймворков на целевых системах:
Что означает возможность создавать приложения с графическим интерфейсом для всего зоопарка винтажных маков.
Типа такого:
Так выглядит демо с диалогом, созданное при помощи кросс-компиляции.
И все это без доступа к самому физическому устройству и пыток разработкой непосредственно в эмуляторе. Кстати процесс переноса собранного приложения (в примерах) в целевую систему также максимально упрощен:
сразу собирается готовый образ диска, который затем можно записать на носитель, либо подсунуть эмулятору.
Когда только начинал собирать материал для этой статьи, узнал что в первых MacOS (внезапно) не было консоли и абсолютно все приложения были только и исключительно графическими:
Консоль появилась только в MacOS X, в 2001м году.
Поэтому тот факт, что классическое консольное приложение на С:
#include <stdio.h>
int main(int argc, char** argv)
{
printf("Hello, world.\n");
printf("\n(Press Return)\n");
getchar();
return 0;
}
возможно собрать в графическое, с таким псевдо-терминалом в комплекте:
Тоже является заслугой тулчейна Retro68 и ключем линковки при сборке:
LDFLAGS=-lRetroConsole
Тулчейн официально поддерживает несколько популярных операционных систем:
Linux, Mac OS X or Windows (via Cygwin)
И действительно совершенно спокойно, без каких-либо проблем и нюансов собирается на линуксе.
Что мне показалось слишком скучным, поэтому
ради гусарской забавыпортировал этот проект на FreeBSD.
Всегда так делаю.
Если вам такие забавы не близки, сообщаю что для линукса достаточно по шагам выполнить инструкцию в README. И все сразу будет хорошо, только не у вас.
Ну а мы как обычно пойдем путем хардкора — соберем весь тулчейн на FreeeBSD с нуля.
Кстати форк Retro68 с поддержкой сборки на FreeBSD выложен в отдельном репозитории. Первым делом надо установить ряд инструментов для разработки и системных библиотек:
pkg install cmake gmp mpfr mpc boost-all bison flex texinfo ruby
Забираем исходники и поскольку репозиторий большой — выгружаем без истории коммитов (ключ depth):
git clone --depth 1 https://github.com/autc04/Retro68.git
Выкачиваем зависимые репозитории:
git submodule update --init
git pull
git submodule update
Теперь надо немного изменить скрипт сборки, для учета особенностей FreeBSD.
Первым делом заменяем вызовы make на gmake, поскольку FreeBSD использует свою версию утилиты make, несовместимую с GNU-версией. Которая конечно также присутствует в пакетах, но только называется gmake.
Дальше необходимо переделать вызовы configure для вложенных проектов из скрипта сборки, суть правок:
пробросить указание на использование библиотек из каталога /usr/local, куда устанавливаются все внешние с точки зрения системы библиотеки в FreeBSD.
Например для строки:
$SRC/binutils/configure --target=m68k-apple-macos --prefix=$PREFIX --disable-doc
необходимо дописать в конец:
CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
Таким образом переменные CFLAGS и LDFLAGS будут переданы скрипту configure в качестве аргумента при вызове.
Чуть сложнее со сборкой GCC (да, мы тут собираем компилятор из исходников), строка:
$SRC/gcc/configure --target=m68k-apple-macos --prefix=$PREFIX \
--enable-languages=c,c++ --with-arch=m68k --with-cpu=m68000 \
--disable-libssp MAKEINFO=missing
Тут уже нельзя использовать переменные окружения CFLAGS и LDFLAGS из-за особенностей сборки GCC и необходимо передавать пути для ключевых библиотек специальными аргументами:
--with-mpc=/usr/local --with-mpfr=/usr/local --with-gmp=/usr/local --with-isl=/usr/local --with-libiconv-prefix=/usr/local
Дописав их в конец вызова configure.
После чего можно запускать сборку.
Запускается она из отдельного каталога:
mkdir ../Retro68-build
cd ../Retro68-build
../Retro68/build-toolchain.bash
После весьма продолжительной (даже на мощном компьютере) и жутко выглядящей сборки, по накалу страстей на экране напоминающей знаменитый make buildworld из FreeBSD:
..все упадет на вот такой «страшной» ошибке:
Для исправления ситуации, надо всего лишь изменить один import в файле portable_endian.h , в этом месте:
#elif defined(__NetBSD__) || defined(__FreeBSD__) || defined(__DragonFly__)
# include <sys/endian.h>
Суть проблемы в том что расположение заголовка endian.h поменялось и теперь его необходимо включать без указания каталога sys:
# include <endian.h>
Исправляем импорт и перезапускаем сборку.
Однако через какое-то время напряженной работы и в очередной раз напугав обывателя простыней текста, сборка.. опять упадет.
На этот раз падение произойдет на стадии сборки из cmake:
Несмотря на весь внешний ужас, исправляется эта ошибка очень просто (если знать где копать разумеется):
удалением импорта этого заголовка из файла PEFTools/MakePEF.cc
Поскольку его содержимое в последних версиях FreeBSD добавили в stdlib. Так что смело удаляем импорт и перезапускаем сборку.
Следующее падение сборки и следующая проблема заключается в пересечении заголовков — системного, из самой FreeBSD и локального — из библиотеки libelf:
Тут к сожалению я не нашел изящного решения, достойного быть упомянутым в летописях, поэтому сделал «колхоз»:
скопировал файл gelf.h из libelf/include в каталог Elf2Mac, и поменял ссылки на этот заголовок из глобального на локальный.
Было:
#include <gelf.h>
Стало:
#include "gelf.h"
Поменять ссылки необходимо во всех файлах проекта Elf2Mac где встречается данный импорт. Наконец последняя ошибка сборки, связанная с особенностями FreeBSD:
Связана эта ошибка с тем, что часть необходимых структур для работы с сетью на FreeBSD вынесена в отдельный заголовок.
Для исправления достаточно добавить:
#include <netinet/in.h>
в файл LaunchAPPL/Client/TCP.cc
Так выглядит успешное завершение сборкиRetro68:
Готовый к использованию тулчейн будет находиться в каталоге toolchain, который стоит добавить в переменную окружения PATH.
Теперь переходим к эмулятору, поскольку живого Mac тех лет, на котором возможно запустить результат сборки у меня нет.
Вообще эмуляторов винтажных Mac довольно много, поскольку маководы это сектанты очень увлеченные люди и многие из них используют и устаревшие компьютеры Apple и устаревший софт до сих пор, всячески отвергая прогресс и здравый смысл.
Такова сила бренда, созданного Стивом Джобсом.
Я буду использовать один из самых популярных и известных эмуляторов классических Macintosh:
Basilisk II is an Open Source 68k Macintosh emulator.
Разработан он был еще в начале 2000х, немецким инженером Christian Bauer, ныне активная разработка уже не ведется. Поэтому вместо нее я использовал более современный форк, в котором решены вопросы совместимости с современным же окружением и обновлены используемые библиотеки.
И внезапно добавлен JIT (Just-In-Time Compiler).
Еще форкнутая версия немного стабильнее, с более адекватным поведением перехвата курсора.
Эмулятор использует следующие библиотеки, которые необходимо установить до попыток сборки:
pkg install sdl2 autoconf automake mpfr gmp
Теперь забираем исходники:
Собираем:
cd macemu/BasiliskII/src/Unix
$ ./autogen.sh
$ gmake
В результате в текущем каталоге появится бинарник BasiliskII, которым и запускается эмулятор:
Для того чтобы запускать MacOS7 в эмуляторе, нужен загружаемый образ диска с установленной системой (или ее инсталлятор) и ROM-файл.
Образ диска можно взять например тут или тут, ROM-файл например отсюда или отсюда. Еще пара вариантов.
Еще вот тут находится крайне интересная табличка, с описанием практически каждого доступного ROM, его особенностей и работоспособности.
Напомню, что для этой статьи я эмулировал модель Quadra 600:
Для эмулятора использовался вот такой ROM-файл:
Указав в разделе «Volumes» путь к образу диска с MacOS7, затем в разделе «Memory/Misc» путь к ROM-файлу, можно наконец запускать эмулятор:
Теперь переходим к самому веселому — к разработке.
Собственно после сборки Retro68, у вас будет все что нужно для разработки конечного софта, поскольку в каталоге build-target/Samples будут собранные примеры приложений:
Эти примеры собираются автоматически, во время сборки самого тулчейна Retro68, в качестве дополнительных тестов работоспособности.
Для сборки во всех случаях используется cmake, исходники находятся в каталоге Retro68/Samples.
Чтобы собрать проект с HelloWorld отдельно, выполняем:
сd /opt/src/Retro68/Samples/HelloWorld
mkdir build
cd build
cmake .. -DCMAKE_TOOLCHAIN_FILE=/opt/src/Retro68-build/toolchain/m68k-apple-macos/cmake/retro68.toolchain.cmake
gmake
Результат сборки:
Каждый пример при сборке генерирует образ диска, который можно сразу подключить к эмулятору:
Достаточно указать путь к dsk-файлу, который находится в каталоге build и запустить эмулятор:
На рабочем столе появится иконка с названием, совпадающим с названием примера:
После двойного клика по этой иконке, раскроется окно с содержимым этого виртуального диска в виде единственного запускаемого файла:
Двойной клик по файлу HelloWorld запустит наше приложение.
Как уже упоминал, в составе Retro68 есть довольно много демонстрационных приложений.
Каждый пример раскрывает аспект разработки и создан так, чтобы его можно было использовать в качестве основы для собственных проектов.
Автор тулчейна постарался, поэтому все примеры логичны, просты и понятны.
Retro68/Samples/Raytracer
Трассировщик лучей, реализующий генерацию псевдотрехмерной картинки в реальном времени. Собственно процесс отрисовки в этом приложении как раз показан на заглавной картинке к статье.
В проекте на самом деле присутствуют сразу две реализации, одна на С, другая на C++, видимо для сравнения во время работы.
Так выглядит финальный результат рендеринга:
Проект ценен в первую очередь как демонстрация расчетной логики и операций с числами с плавающей точкой.
Retro68/Samples/Dialog
Демонстрация работы с модальными диалогами — как задавать размеры и расположение элементов, как создавать формы ввода, как получать вводимые данные и так далее.
В работе:
Retro68/Samples/WDEF
Демонстрация работы с многооконными интерфейсами (MDI), создание окна с кастомным оформлением и работа с ресурсами окон.
Так это выглядит в действии:
Кратко по остальным примерам, реализующим какую-то специфическую логику.
Retro68/Samples/MPWTool
Реализует расширение для MPW (Macintosh Programmer's Workshop), точнее для MPWShell, с обработкой запуска оттуда и корректного возвращения в консоль.
Retro68/Samples/SharedLibrary
Реализует разделяемую библиотеку и приложение, его использующее в рантайме.
Retro68/Samples/SystemExtension
Пример простейшего расширения для самой операционной системы MacOS 7, в данном случае вся видимая логика заключается в показе новой иконки при запуске ОС.
Retro68/Samples/Launcher
Реализует запуск сторонних приложений через перетаскивание (Drag&Drop).
"Masters of Hardcore" - вбейте в поиск если не жалко уши и соседей.
Вы же не думали, что я успокоюсь на банальной сборке тулчейна с эмулятором под FreeBSD и запуске пары тестов?
Праздник должен продолжаться:
Clapkit (CLassic APplication KIT) is a framework for developing applications for Classic Mac OS (System 7.x - Mac OS 9.x), basically a C++/object-oriented wrapper for Macintosh Toolbox functions.
Да, глаза вас не подводят, это самый настоящий современный графический фреймворк для компьютеров начала 90х.
Так это выглядит:
Картина неизвестного питерского художника "Мак под маком".
Так выглядит код:
#include <ckApp.h>
int main() {
CKApp* app = CKNew CKApp();
app->CKNewMsgBoxNote("Hello world!", nullptr, "OK",
nullptr, [app](int button) {
app->CKQuit();
});
// Run loop: without this, your app will quit as soon as it launches.
while (!app->CKLoop(5));
delete app;
return 0;
}
Так выглядит мое тестовое приложение на современном C++, собранное с помощью cmake на FreeBSD и запущенное на MacOS 7 из 90х:
Поддержки юникода тогда еще не было, как и локализации на русский, поэтому "великий и могучий" есть лишь в комментариях.
Ну что дорогие читатели, ударим шизой по осенней летней хандре?
Конечно ударим, но прежде стоит рассказать про нормальную разработку для продукции Apple, как это происходило у нормальных людей.
Разумеется на маках всегда была собственная среда разработки:
Macintosh Programmer's Workshop (MPW) is a software development environment for the Classic Mac OS operating system, written by Apple Computer.
Ее вполне можно использовать до сих пор, благо образов дисков в сети хватает. Именно так я и советую поступать (т.е. использовать MPW) в случае любого более-менее серьезного проекта, поскольку где и когда закончатся возможности кросс-компиляции и вы опустите руки — предсказать не берусь.
Как-то так MPW выглядит в эмуляторе:
Тут находится отличная статья по созданию «Hello, world» на MPW в эмуляторе, которой вполне хватит для начала приключений. Но в этот раз нам нужен не MPW а только его часть — системные заголовки, которые мы будем использовать для злодейства сборки.
В Retro68, в каталоге InterfacesAndLibraries находится файл Readme.md, содержимое которого явно намекает на дальнейшие действия:
Find a copy of Apple's Universal Interfaces 3.x (preferrably 3.4) and put them here.
Вообще «Find a copy» это такой толерантный и социально приемлемый синоним старого доброго «скачать варез», прямо из 90х. Потому как купить официально старое ПО уже не представляется возможным, если подобное вдруг придет в голову. Даже если компания-разработчик существует (как в случае Apple), старые версии своих продуктов она так просто не продаст.
Потому что есть поддержка, гарантии и защита прав потребителей.
И репутация компании.
Поэтому сообщаю по секрету, что «найти» эти самые универсальные интерфейсы можно например тут:
wget https://henlin.net/images/Interfaces\&Libraries.zip
unzip "Interfaces&Libraries.zip" -d /opt/src/Retro68/InterfacesAndLibraries
Ссылка кстати взята из другой интересной статьи, в которой автор реализует слой рендера для фреймворка Nuklear, о котором я уже внезапно писал.
Так это демо выглядит в работе, порт эмулятора на Javascript внезапно оказался встроен в статью:
JS-версия загружается довольно долго, браузер может подвисать.
Хотя этот проект успешно собрался из исходников, при попытке запуска в эмуляторе программа на базе Nuklear вылетала.
Разгадка оказалась в необходимости использовать другой эмулятор и собственно полностью другую эмулируемую систему.
Так что расскажу про связку из Nuklear, QuickDraw и Retro68 в другой раз, чтобы не раздувать эту статью до совсем уж космических размеров.
А пока для затравки, показываю эту связку в действии:
Не пугайтесь размеров элементов интерфейса в эмуляторе - игрался с зумом, проиграл.
Но вернемся к фреймворку ClapKit, благо история с ним еще не закончена.
После распаковки заголовков из MPW, необходимо перезапустить сборку самого тулчейна Retro68:
cd Retro68-build
../Retro68/build-toolchain.bash
И наконец можно приступать к половым утехам с самим ClapKit. Забираем исходники:
git clone https://github.com/macinlink/clapkit.git
Сборка построена на cmake, но перед тем как собирать Clapkit, необходимо указать путь к Retro68 в скрипте сборки:
# Ensure Retro68 toolchain is set BEFORE defining project
set(CMAKE_TOOLCHAIN_FILE "/opt/src/Retro68-build/toolchain/m68k-apple-macos/cmake/retro68.toolchain.cmake")
и чуть ниже:
# Define Retro68 path properly
set(RETRO68_PATH /opt/src/Retro68-build/toolchain/m68k-apple-macos)
К сожалению в проекте есть небольшой баг с пропущенными заголовками, из-за которых он не собирается.
Для исправления достаточно добавить в include/ckTypes.h два импорта:
#include <Quickdraw.h>
#include <Events.h>
В репозитории проекта находится готовый Showcase с демонстрацией возможностей фреймворка, на базе которого я и делал свое тестовое приложение (см. ниже).
Так выглядит сам Showcase в работе:
Напоминаю, что все это создано с помощью кросс-компиляции и затем запущено в целевой MacOS 7.
Выглядит заметно веселее, чем примеры из самого Retro68, согласитесь.
Я не хотел сразу пускаться во все тяжкие и портировать Doom/Quake/Cyberpunk 2077 под винтажные Маки из 90х — надо же оставить место воображению, поэтому мой тестовый образец для этой статьи это в первую очередь пример автономного, отделяемого приложения с минимальной логикой.
Которое собирается без привязки к иерархии каталогов Clapkit или Retro68.
Проект выложен в отдельном репозитории на Github.
Так мое приложение выглядит в работе на MacOS 7:
Все что оно делает:
отображает меню «Yo» в Finder, с единственным пунктом «Run me», по клику на который вызывается модальный диалог с двумя кнопками. По нажатию на «Quit» произойдет завершение работы программы.
Фигня-фигней, но только разработано и собрано оно полностью и целиком вне инфраструктуры MacOS и без средств разработки от Apple, даже без техники Apple.
На современном С++, под FreeBSD темной питерской ночью.
Так выглядит основной код на C++, файл main.cpp:
#include "main.h"
#include <ckMenu.h>
CKTestAlexs* app;
int main() {
// класс переименован ради тестов
app = CKNew CKTestAlexs();
// false - не использовать стандартные пункты меню
CKMenuBar* menuBar = CKNew CKMenuBar(false);
// добавляем свой пункт меню в Finder
CKMenu* menuTests = CKNew CKMenu("Yo");
menuBar->AddMenu(menuTests);
// затем элемент в выпадающем списке
CKMenuItem* item = CKNew CKMenuItem("Run me", 'R', [&item](CKEvent e) {
// по клику произойдет отображение стандартного
// модального диалога
app->CKNewMsgBoxNote("Welcome to old school!",
"Hello world", "Mkay", "Quit", [](int button) {
// если нажали Quit - завершить работу приложения.
if (button == 0) {
app->CKQuit();
}
});
});
// связывание элемента с пунктом меню
menuTests->AddItem(item);
// связывание меню с приложением
app->CKSetMenu(menuBar);
// бесконечный цикл ожидания для отрисовки,
// без которого приложение сразу завершится
while (!app->CKLoop(5));
delete app;
return 0;
}
Класс описан в заголовке main.h, декларации методов я убрал за ненадобностью:
#include <ckApp.h>
class CKTestAlexs : public CKApp {
};
Так выглядит скрипт сборки для cmake, как можно заметить тут происходит автоматическое скачивание родительского фреймворка Clapkit и наложение патча с пропущенными импортами (описаны выше):
cmake_minimum_required(VERSION 3.16)
# Ensure Retro68 toolchain is set BEFORE defining project
set(RETRO68_PATH "/opt/src/Retro68-build/toolchain/m68k-apple-macos")
set(CMAKE_TOOLCHAIN_FILE "${RETRO68_PATH}/cmake/retro68.toolchain.cmake")
project(clapkit VERSION 1.0)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED True)
# Include Retro68 headers
include_directories(${RETRO68_PATH}/include)
# Set default build type to Release if not specified
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE Release CACHE STRING "Build type (Debug or Release)" FORCE)
endif()
set(CLAPKIT_LOCAL_PATH "${CMAKE_SOURCE_DIR}/../../")
option(USE_LOCAL_CLAPKIT "Use local checkout of clapkit instead of fetching from Git" ON)
if(USE_LOCAL_CLAPKIT AND EXISTS "${CLAPKIT_LOCAL_PATH}/CMakeLists.txt")
message(STATUS "Using local clapkit at ${CLAPKIT_LOCAL_PATH}")
add_subdirectory(${CLAPKIT_LOCAL_PATH} clapkit)
set(USE_LOCAL_CLAPKIT ON)
else()
set(cktypes_patch git apply ${CMAKE_SOURCE_DIR}/patches/cktypes.patch)
message(STATUS "Fetching clapkit from GitHub...")
include(FetchContent)
FetchContent_Declare(
clapkit
GIT_REPOSITORY https://github.com/macinlink/clapkit.git
GIT_TAG main
PATCH_COMMAND ${cktypes_patch}
UPDATE_DISCONNECTED 1
)
FetchContent_MakeAvailable(clapkit)
set(USE_LOCAL_CLAPKIT OFF)
endif()
# Add application
add_application(CKTestAlexs
TYPE "APPL"
CREATOR "CKTS"
main.cpp
cktest.r
)
# Debug vs Release settings
if(CMAKE_BUILD_TYPE STREQUAL "Debug")
message(STATUS "Configuring Debug Build")
target_compile_definitions(CKTestAlexs PRIVATE kCKAPPDEBUG=1)
target_compile_definitions(clapkit PRIVATE kCKAPPDEBUG=1)
set_target_properties(CKTestAlexs PROPERTIES
COMPILE_FLAGS "-O0 -Wall -g -fdata-sections -ffunction-sections"
LINK_FLAGS "-Wl,--mac-single"
)
elseif(CMAKE_BUILD_TYPE STREQUAL "Release")
message(STATUS "Configuring Release Build")
target_compile_definitions(CKTestAlexs PRIVATE NDEBUG) # Disable debugging in Release
target_compile_definitions(clapkit PRIVATE NDEBUG)
set_target_properties(CKTestAlexs PROPERTIES
COMPILE_FLAGS "-s -O1 -Wall -fmerge-all-constants -fmerge-constants -fstrict-aliasing -fomit-frame-pointer -fdata-sections -ffunction-sections -finline-functions"
LINK_FLAGS "-Wl,--mac-single -Wl,--mac-strip-macsbug"
)
endif()
# Link clapkit
target_link_libraries(CKTestAlexs PRIVATE clapkit)
Поскольку пути к Retro68 задаются внутри скрипта сборки, а фреймворк Clapkit автоматически скачивается из Github, сама сборка максимально упрощена:
mkdir build
cd build
cmake ..
gmake
При успешной сборке будет создан образ диска с приложением внутри, который можно легко подцепить в эмулятор:
Ниже несколько интересных (но все еще социально одобряемых) идей, на тему что еще можно сделать с эмулятором винтажного Macintosh.
Для начала, можно довести накал программерского угара до предела — интегрировав Retro68 с полноценным IDE и отладчиком:
Developing vintage 68K Macintosh apps with CodeLite IDE, Retro68 and pce-macplus emulator
С автодополнением из среды разработки:
С запуском собранного приложения в эмуляторе сразу из среды разработки:
И даже с удаленной отладкой через эмуляцию последовательного порта:
Тут можно найти отдельное видео с демонстрацией работы.
Следующая замечательная идея в моем списке это очевидная попытка использовать Rust для кросс-компиляции под старые Mac. Нет, автор не шутит, он действительно это сделал:
Through some luck and a little persistence I have actually managed to get Rust code running on classic Mac OS (I’ve tried Mac OS 7.5 and 8.1)
Репозиторий находится тут, проект достаточно свежий (2023 год) и вполне рабочий.
Но предупреждаю сразу, что от исходного кода может случиться сердечный приступ, если любите классический C — на это лучше не смотреть.
Так оно выглядит в работе:
Кстати приложение сетевое, так что на Rust реализована не только работа с интерфейсом, но и с TCP/IP и даже HTTP протоколом.
Для операционной системы из 1994 года.
Статья была опубликована на Хабре, более вольный оригинал как обычно в нашем блоге, форк Retro68 с поддержкой сборки на FreeBSD выложен в отдельном репозитории на Github.
