Потроха CP/M 2.2

[svofski]

Error404, а спортированного под CP/M vi случайно не завалялось? vi с jcuken изотрет моск в порошок, но в эмуляторе, или с подключенной PS/2 клавиатурой, могло бы получиться недурно.

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

Хм, сказал и тут же вот что нашел:
https://github.com/udo-munk/s
Правда, разумеется, проверено только под HITECH C для Z-80.

[tnt23]

Error404, а спортированного под CP/M vi случайно не завалялось? vi с jcuken изотрет моск в порошок, но в эмуляторе, или с подключенной PS/2 клавиатурой, могло бы получиться недурно.

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

Хм, сказал и тут же вот что нашел:
https://github.com/udo-munk/s
Правда, разумеется, проверено только под HITECH C для Z-80.

Найти PS/2 клавиатуру с JCUKEN тоже надо постараться. Но VI вполне себе может быть тема!

Применительно к "Океану", however, есть некоторая проблема: неизвестны в точности команды управления курсором в нем.

[svofski]

tnt23, если конкурс по спидкодингу будет проводиться на Векторе-06ц, то vi будет с jcuken и это будет брутальный гандикап. Причем людям, которые обычно vi боятся, будет проще.

[Error404]

Вот тока как и все VI (в т.ч. и для "больших машин" - я и там искал), оно открывает только что влезает в ОЗУ, у меня при TPA=58к оно не смогло открыть даже файл размером в 15к - сругалось на "out of memory". В-общем, грусть-печаль с этими VI.
Еще для CP/M есть хороший редактор VEDIT - файлы любого размера, есть инсталлятор, меню, VI-like однобуквенные команды. В инсталляторе можно прописать практически всё: я лично делал для ESC-последовательностей (для скроллингов) и клавиатуры (переназначаются любые управляющие комбинации кнопок). Почему не стал им пользоваться: для CP/M у меня уже есть SED, а для ЮЗИКС (мысль была в том чтобы запускать VEDIT под эмуляцией CP/M) мне при всем богатстве настроек не хватило у VEDIT возможности включить обработку строк по UNIX-коду конца строки. Оно хотя в отличии от прочего CP/M-овского и не перекашивалось при недостающем LF, но бесит в редакторе такой вид строк:
строка1[CR]
строка2[CR]
строка3[CR]

А сохраняет оно при том по-прежднему с CR+LF как принято в CP/M. Так что если кто знает CP/M-редактор под файлы любого размера, при этом умеющий в строки оканчивающиеся CR (как в Ордос на Орионе), прошу поделиться.

[svofski]

у меня при TPA=58к оно не смогло открыть даже файл размером в 15к - сругалось на "out of memory". В-общем, грусть-печаль с этими VI

Да, не фонтан. С другой стороны вряд ли сишные компиляторы под CP/M способны переварить файлы большего размера.

[tnt23]

Что-то мне казалось, что дисковые компиляторы тех лет (ASM80, C80 и кто там еще был) умели жрать с диска исходники сильно больше TPA и складывать результаты компиляции опять же на диск. Но это неточно.

[svofski]

Вот нашел кое-что, чего раньше как-то ускользало от моего внимания: David Dunfield Services Micro C compiler for 8085:
http://www.classiccmp.org/dunfield/dos/mc323d85.zip
Запускается из-под досбокса. Есть примеры и даже библиотека с printf(). Цепляется монитору-отладчику на таргете, который имеет 8051 на порту $80. Там есть даже IDE. В общем офонарительная вещь.

Один недостаток - это что эта вещь ничего не знает про CP/M и часть библиотеки придется писать самому.

[Error404]

А такие команды есть на 8080 (это из выхлопа компилера):
SUI IMM
SBI IMM
ACI IMM
Или это от 8085?
Совершенно не ради старого холивара, но понимать по мнемонике что оно могло бы делать нормальный человек не должен.

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

Т.е. вопрос в том насколько оно совместимо с 8080?

Вообще, учитывая что у David Dunfield Services Micro C compiler for 8085 из типов только самые примитивные, то его преимущество перед классическим BDS C от Борландов нативно работающим на 8080 (от которого кстати есть исходники) только в отладчике (что кстати не мало, но мне нужен long нормальный а не через строки char[])

[svofski]

А такие команды есть на 8080 (это из выхлопа компилера):
SUI IMM
SBI IMM
ACI IMM

Это обычный 8080, SUbtract Immediate, Subtract with Borrow Immediate и Add with Carry Immediate.

Вообще, учитывая что у David Dunfield Services Micro C compiler for 8085 из типов только самые примитивные, то его преимущество перед классическим BDS C от Борландов нативно работающим на 8080 (от которого кстати есть исходники) только в отладчике (что кстати не мало, но мне нужен long нормальный а не через строки char[])

У этого C есть структуры, что по идее возвышает его над BDS C. Но они, похоже, жутко захачены. Я уже напоролся на совершенно непробиваемую стену, пытаясь их использовать. Собственно, повторяется история как и со всеми предыдущими компиляторами как бы Си для 8080: они годятся как вещь в себе, но для переноса кода толку с них в конечном счете оказывается немного.

(Несущественно, но BDS C к Борланду не имеет отношения, его автор Leor Zolman).

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

Ох ну и упоротая вещь. Структуры там -- одно название.

С грехом/2 скомпилил pack.c из rogue, получилось 4912 байт.

Дальше пришлось помучиться, чтобы тот же файл сделать компилябельным для SDCC. SDCC ест совершенно здоровый Си, но не k&r, пришлось дописывать все прототипы (че-то не нашлось под рукой protoize). SDCC для Z80 дал 4478 байт.

Мучительно, но в общем неплохо, для 8080 то. Интересно было б сравнить с Ацтеком, но сил больше нет.

[tnt23]

svofski, ацтека поддерживает структуры. Давай пример попроще, попробую собрать.