Будет ли версия для CP/M?
С заменой модуля с фонтами/цветами/опросами на стандартную STDIO консоль (через регистры ВМ)?
А то и может и с вводом/выводом на привод через BDOS/BIOS (через регистры ВМ)?
- - - Добавлено - - -
Без этого как-то несерьезноДаешь энтерпрайз 70х!
- - - Добавлено - - -
Вообще было бы круто у движка наращивать обслуживаемые регистры внешними модулями пользователя. Захотел нативную сетевуху для uIP - написал модуль
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
В каком смысле? В качестве целевой платформы CP/M был с самого начала (и есть до сих пор), а сам gcc компилирующий в CP/M представляется чем-то совершенно невероятным.Сообщение от Error404
Насколько я вижу в коде, глянув сильно по диагонали, там какой-то самодеятельный кусок кода для вывода на экран с покраской цветом и фонтами. Какое же это CP/M? ORG 100H это еще не CP/M. Либо я что-то недопонял, тогда прошу пояснить
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Надеюсь svofski не будет сильно против, что я лезу.
Там два варианта - или cp/m или голый вектор. Самодеятельная покраска это векторовский вариант.
CP/M не сильно развит, фактически все ограничено консольным вводом-выводом. Работы с файлами, например, нет. Протащить можно что угодно, просто охоты это делать пока ни у кого не было.
Больше игр нет
Ну он хоть в каком-то виде есть как бинарник? Чтоб например запустить какой-то уже скомпилированный простейший пример на Орионе в CP/M? Для ознакомления. Нечто вида
zpu.com hello.zpu
Ведь CP/M на то и CP/M чтобы бинари были совместимы.
Т.к. то что я вижу например в https://gitlab.com/svofski/zpu8080/-/tree/FastIMnoFlip - там только фрагменты вида "ORG 100 / LDIR BEGZPU / JP BEGZPU " с несуществующими иннклюдами и отсутствием упоминаний о последовательности сборки самого ZPU.
- - - Добавлено - - -
А уж дальше думать как собрать сам ZPU нативно в СP/M. Вполне посильная задача для M80, зачем все эти TASM ненашенские
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
В репозитории 7 примеров, из них 5 компилируются в cp/m-овские comы: hellozpu.com, intmand.com, sieve.com, startrek.com, uip.com. Для uip нужна специальная поддержка, а вот остальные можно запустить в любом cp/m (еще насчет startrek уверен не на 100%, но скорее всего), лишь бы памяти хватало. Бинарники (несколько устаревшие на сегодняшний день) есть тут.
- - - Добавлено - - -
Runtime часть можно адаптировать для сборки с использованием любого асма 8080, в т.ч. и M80. Зачем делать это в cp/m мне не очень понятно (это усложнит сборку), zpugсс все равно будет работать в linux (или в win10 в докере или хоть где в виртуальной машине с linux). Компромиссный вариант - использовать что-то вроде адаптации M80 для win b2mа, скорее всего его вариант можно собрать и для linux (если он захочет).
Последний раз редактировалось ivagor; 07.03.2021 в 06:39.
Для оценки деления попробовал расчет пи по формуле Гаусса. Модернизированное деление ускоряет на 34%!
Кажется я понял. Движок ZPU компилируется в каждый COM?
Для оценить сойдет, но надо переделывать на запуск движка ZPU с параметром выполняемого файла а в последствии возможно и посадки движка в теневом ОЗУ как расширения ядра ОС. Т.к. странно выглядит - как например JRE компилировать в каждый jar или BDOS/BIOS CPM включать в каждый COM. Вообще конечно подход имеет право на существование, в UZIX так делали с эмулятором CP/M, но я переделал на отдельный эмулятор и стало удобнее.
М80 мне привычен синтакисом (и вообще сделан более по людски чем тасм, за исключением всякого ненужного типо прочих платформ) и прекрасно работает в консоли винды с локальными файлами винды в правильном эмуляторе CP/M. Т.е. никакого проигрыша по удобству. Используя M80 всегда остается опция нативной сборки на Орионе или использования lib-ов М80 в CPM-овских С и Pascal, чего не будет в TASM.
gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно). Называя вещи своими именами, Linux по отношению к 8бит весьма неудобен (и никогда удобен не будет). Т.е. можно попробовать сделать полный тулчейн на винде.
Да уж. Вот так начнешь и получается такая куча работы на переделывание, что глаза боятся.
Еще опция если движок будет отдельно от байт-кода - можно будет один и тот же байт-код приложений запускать и на 8080 и на Z80 и на 6502 к примеру (просто у у каждого будет свой runtime-движок ZPU)
Последний раз редактировалось Error404; 07.03.2021 в 12:52.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Да
Есть и он даже компилирует. То, что у меня не получилось скомпилировать виндовым вариантом ничего подходящего для zpu8080 - это ладно. Но у svofski тоже не совсем получилось, хотя он всерьез этим не занимался и если бы занялся, то наверняка смог бы. Есть еще один момент - к zpugcc для zpu8080 добавляется несколько патчей, без которых в принципе можно жить, но будет грустновато.
При компиляции отдельные zpuшные бинарники создаются и для них можно написать запускалки для всяких разных процов.
Какие плюсы у текущего подхода (код zpu + runtime zpu8080 в одном флаконе):
1. При компиляции можно задать опции и убрать не нужные для данной программы фичи из runtime части. Или включить все опции и получить программу побыстрее, но и пожирнее.
2. Можно компилировать не только в com для cp/m, но и в rom для запуска на голом векторе.
3. Для человека, который не знает ничего про zpu, но знаком с cp/m проще запустить .com
У отдельной запускалки есть свои плюсы и если кто-нибудь сделает (что сравнительно просто), то это будет здорово.
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
