ZPU на Векторе

[ivagor]

Ну он хоть в каком-то виде есть как бинарник? Чтоб например запустить какой-то уже скомпилированный простейший пример на Орионе в CP/M?

В репозитории 7 примеров, из них 5 компилируются в cp/m-овские comы: hellozpu.com, intmand.com, sieve.com, startrek.com, uip.com. Для uip нужна специальная поддержка, а вот остальные можно запустить в любом cp/m (еще насчет startrek уверен не на 100%, но скорее всего), лишь бы памяти хватало. Бинарники (несколько устаревшие на сегодняшний день) есть тут.

- - - Добавлено - - -

А уж дальше думать как собрать сам ZPU нативно в СP/M. Вполне посильная задача для M80, зачем все эти TASM ненашенские

Runtime часть можно адаптировать для сборки с использованием любого асма 8080, в т.ч. и M80. Зачем делать это в cp/m мне не очень понятно (это усложнит сборку), zpugсс все равно будет работать в linux (или в win10 в докере или хоть где в виртуальной машине с linux). Компромиссный вариант - использовать что-то вроде адаптации M80 для win b2mа, скорее всего его вариант можно собрать и для linux (если он захочет).

[Advertiser]

[Error404]

В репозитории 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 (если он захочет).

Кажется я понял. Движок 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)

[ivagor]

Движок ZPU компилируется в каждый COM?

Да

gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно).

Есть и он даже компилирует. То, что у меня не получилось скомпилировать виндовым вариантом ничего подходящего для zpu8080 - это ладно. Но у svofski тоже не совсем получилось, хотя он всерьез этим не занимался и если бы занялся, то наверняка смог бы. Есть еще один момент - к zpugcc для zpu8080 добавляется несколько патчей, без которых в принципе можно жить, но будет грустновато.

Еще опция если движок будет отдельно от байт-кода - можно будет один и тот же байт-код приложений запускать и на 8080 и на Z80 и на 6502 к примеру

При компиляции отдельные zpuшные бинарники создаются и для них можно написать запускалки для всяких разных процов.
Какие плюсы у текущего подхода (код zpu + runtime zpu8080 в одном флаконе):
1. При компиляции можно задать опции и убрать не нужные для данной программы фичи из runtime части. Или включить все опции и получить программу побыстрее, но и пожирнее.
2. Можно компилировать не только в com для cp/m, но и в rom для запуска на голом векторе.
3. Для человека, который не знает ничего про zpu, но знаком с cp/m проще запустить .com
У отдельной запускалки есть свои плюсы и если кто-нибудь сделает (что сравнительно просто), то это будет здорово.

[svofski]

gcc тоже есть под виндой в cygwin и подобных mingw. Зачем его тащить в контейнеры - сходу тоже не понятно (кроме желания сделать стильномодномолодежно). Называя вещи своими именами, Linux по отношению к 8бит весьма неудобен (и никогда удобен не будет). Т.е. можно попробовать сделать полный тулчейн на винде.

Потому что так мне проще. Я живу под линуксом. ivagor, который заинтересовался проектом и сразу принял в нем очень активное участие, под виндой. Dockerfile это рецепт, который на любой машине позволяет развернуть все зависимости по простому и понятному рецепту так, что оно будет повторяемо независимо от хоста. Так у нас получилось работать над одним проектом под разными системами, не тратя время на треш типа gcc под виндой. Вот зачем мне тратить неделю времени на то, чтобы собрать zpugcc под виндой? Нету у меня этого времени и удовольствия я от этого не получу.

Про то, что сборка через make — это стильномодномолодежно, я думаю про это было бы приятно послушать дедушкам—изобретателям юниксового тулчейна. Жаль не все из них уже живы.

Но вообще я ничего против сборки под виндой не имею. Так же как и против еще многих вещей, которых "не хватает" — та же работа с файлами. Сорцы открыты специально для того, чтобы можно было доделать то, чего нет. Вот ворчать и доказывать мне, что Линукс — это почему-то неудобно по отношению к 8бит, смысла нет никакого.

Что до отдельной запускалки байткода — это можно, но требует усилий в той области, которая никому пока не была интересна. Сейчас сборка каждого индивидуального примера затачивает рантайм под себя через дефайны. Например куча всякой ерунды сделана для uIP, но она совершенно не нужна Стар Треку. И от этого зависит распределение памяти. Получается, что если делать хорошо, надо угрохать уйму времени на то, чтобы сделать рантайм конфигурируемым в рантайме. На это просто не хватает ни желания ни времени. А проект вообще задумывался скорее как шутка.