Также добавлю оптимизма: то что "компилируемость" приходится подбирать это нормально. И связано с тем, что до сих пор нет нормального компилятора для Z80 для сборки кода серьезнее HelloWorld. Тот же FUZIX полностью собирается только sdcc определенной версии с определенными немейстримовскими патчами (далеко не самой новой версией и далеко не всеми патчами, новые при сборке глючат каждая по-своему). Это просто надо преодолеть буквально "курочка по зернышку" - где-то подбирая опции компилера, где-то перетасовывая код (вынесешь крупную процедуру выше по модулю или в другой модуль, и опа - всё начинает собираться, какие-то структуры в памяти при компиляции по-другому легли и всё поместилось). У HitechC есть в этом смысле недостаток - оно если упрётся во что-то, то в 50% случаев тупо виснет, в 50% выдает "не хватило того-то". Вот зависы конечно нервируют. Но оно хотя бы работает в 64к, а вот когда глючит SDCC, работающий в 64Gb - вот это бесит дико.
- - - Добавлено - - -
У меня дома нативная Винда7 64бит и на работе нативная Винда7 64бит. И там и там компилируется. Хотя последний апдейт я не загружал, компилирую то что у меня уже лежит локально. Но оно вроде же должно 100% соответствовать, git типа гарантирует.
- - - Добавлено - - -
Попробовал "начисто" качнуть с GIT С-компилятор (HITECH C 3.09 + cpm.exe Мураками) и UZIX - собралось всё.
Так что у меня зависы конкретно этого компилятора/эмулятора c конкретно этими исходниками не воcпроизводятся.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
В эмуляторе CP/M добавил небольшую фичу: если в параметрах командной строки указать юниксовый путь (определяется тупо по наличию слешей), то он во-первых вырезается из параметров, передаваемых CP/M программе (т.к. в CP/M программе пути не обрабатываются), и во вторых перед передачей управления СОМ-файлу осуществляется переход по вырезанному пути. Эффект в результате получается такой: можно находясь в каталоге ААА обработать CP/M-программой файлы из каталога BBB через параметры командной строки (например так: sed.com /home/guest/test.txt ).
И кстати, вопрос. Шикарные редакторы от CP/M хотят файлы с концами строк CR+LF, а в Юниксах только CR. Поэтому нормально ими текстовое редактирование ими не сделаешь. как выкрутиться?
PS. Сообщения про компиляторы отцепил в эту тему:
http://zx-pk.ru/threads/29581-dialog...troitelya.html
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Не знай как в старых, но современные редакторы этого не замечают толком. NANO только показывает доп. символ на каждой строке и всё. Kate и прочие автоматом распознают перевод строки и используют его для каждого документа индивидуально. Notepad++ под Вин так же универсален.
Надо будет покопать старые редакторы, что есть. А пока на работе забит очень сильно
"Байт-48"
При помощи того же Hitech C и такой то матери скомпилировал редактор VI (в его реинкарниции LEVEE сдернутой из репов FUZIX). Как-то оно уже работает (я даже набрал HelloWorld, I am VI !!! и сохранил это в файл). Однако в связи с тем, что VT-52 на Орионе это немного отличающийся подвид VT-52, то неожиданно ведет себя например движение курсора от сканкодов считываемых с клавиатуры. И возможно еще надо что-то донастроить в globals.c где хранятся ESC-последовательности (и еще много чего). Короче, надо чуть отладить, но уже нет сил. Поэтому желающие помочь с этим - велком.
Вот как описывают правильный VT-52: https://en.wikipedia.org/wiki/VT52#VT52
А какой он в Орионе - см. в zip во вложении.
Cам VI с исходниками выложил на GIT.
Последний раз редактировалось Error404; 14.10.2018 в 13:29.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
Решил пока добивать VI. Правда не понял редактирует ли он файлы размером более доступного ОЗУ, тупо не смотрел пока. Написано там все заумно, пока интерфейс бы победить. Ну, почти победил, кстати, пользоваться вполне можно, кнопки все настроил (все как в оригинальном VI + управление курсором как в WordStar/TurboPascal - курсорные ctrl+S,E,D,X {они в орионовском драйвере замаплены на курсорные стрелки} ; PgUp=ctrl+R ; PgDn=ctrl+C). Работает всё примерно как vi на AIX, где редактирование (переход туда по кнопке I - от Insert) слегка чудное - например в режиме редактирования клавиша "забой"(BS) стирает символ слева от курсора в буфере, но не на экране (где просто сдвигает курсор влево), а 'x' в командном режиме стирает символ под курсором и в буфере и на экране.
А вот в vi на Linux кнопкой "забой"(BS) символ стирается и на экране и в буфере, и 'x' тоже стирает и там и там.
В общем пользоваться вполне можно. Надо допилить по мелочи - вот эти вот стирания символов, расширить отображение строки состояния (добавить отображение текущего режима cmd/edit - пока не понял откуда его взять: такой явной переменной не нашел пока) .
Все правки залил на GIT, и тут тоже положу.
Последний раз редактировалось Error404; 14.10.2018 в 16:45.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
В-общем, большие файлы оно не открывает. Пишет overflow. И строки более 80 символов не обрабатывает. Стыд-позор, ведь такое умеет почти любой редактор от CP/M размером в 10кб и менее (а не 39кб как вышел vi=leevee у меня или over 40к у FUZIX-оидов). Я несколько реализаций попроще vi видел до этого (в т.ч. и для PC) - там из исходника было видно что редактор берет "только что полезло в ОЗУ". Тут накручено было более заумно, где-то оно даже lseek по файлу зачем-то делало, и я понадеялся что может сделали нормально, но на выходе увы, опять туфта (в сущности как и почти все что смотрел в репах FUZIX, но зато накрутят мильон дефайнов, прям как у больших дядей - вот нафига тащить туда такое г.? лучше бы подобрали нормальный редактор от CP/M в исходниках чтобы добавить пути файлов и поправить обработку конца строк, зла не хватает).
Последний раз редактировалось Error404; 14.10.2018 в 21:31.
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
ВНЕЗАПНО! Нашёл ещё одно стороннее ядро аля uzix - umzix доя sharp mz800.
https://sourceforge.net/p/umzix/code/HEAD/tree/trunk/
Прикольно. Они там на безрыбье даже SDCC осилили. Не понятно правда оно рабочее или нет?
Приложений правда мало, нечего сдернуть - всё из этого уже есть в моем дистре.
А я тут запилил плагин для TotalCommander/DoubleCommander/Far для работы с образами дисков UZIX. Надо кому? В GIT пока не выкладывал т.к. еще есть мысли что допилить в дополнение к базовым операциям.
- - - Добавлено - - -
Я тут глянул в сорцы cpm32_04.zip, тамошний эмулятор легко заменится на любой другой написанный на С т.к. никак не зависит от C-кода. Выполнение идет по одной команде, всё управляется из корневого C-кода со связью через единственную структуру с регистрами процессора да массив 64к с "ОЗУ Z80". Задачка - начать да кончить. Когда займешься, andreil, завод запустили уже?
Лучше сделать и жалеть, чем не сделать и жалеть.
Некоторые из моих поделок тут: https://github.com/serge-404
там есть образ с собранной системой, датируется аж 2012 годом. скачал эмулятор Шарпа. оно работает. Но команд там не хватает, конечно. Написано, прототип. Последние правки датируются 2014 годом. Мануала по сборке нет. по make файлу видно, что не хватает ещё тулз для сборки. ну, вероятно это всё должно собираться под линухом?! ну я скачал для истории и осмотра...
дай (голосом чайки из Немо)) )?!
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)