Просмотр полной версии : Компьютер для CP/M. Формулировка ТЗ.
Долго ходил вокруг и около темы раритетных компьютеров, но всерьез не увлекался. И с ZX, и с РК еще в школьные годы наигрался. Присматривался к ЮТ-88 со смутным желанием повторить, но уж больно он "громоздкий", много лишнего. Душа не лежит. И вот наконец нашел тему, которая зацепила. Захотелось собрать компьютер, специально "заточенный" под CP/M. Осталось только сформулировать требования и либо найти под них уже существующий проект, либо попытаться самому что-то создать.
1. Хотелось бы использовать по возможности только "исторические" компоненты. Но это касается только самого компьютера. Периферия должна быть однозначно современная.
2. Максимально простая схема, как можно меньше "рассыпухи". Использование БИС из микропроцессорных комплектов поощряется. Комплект к580 было бы замечательно использовать, но боюсь, в плане совместимости z80 будет гораздо лучше.
3. Видеоадаптер.
3.1. В качестве дисплея VGA монитор.
3.2. Режимы видеоадаптера должны обеспечить максимальную совместимость. Как минимум монохромный текстовый режим 80х25. Применялись ли и как широко цветные текстовые режимы? Считаю необходимым иметь возможность менять кодовые таблицы знакогенератора, обязательна возможность поддержки русского. На счет графических режимов в CP/M хотел бы узнать, насколько широко они применялись, есть ли достаточное количество софта? Пока думаю, что это слишком сложная задача.
3.3. Идеальным было бы реализовать видеоадаптер на ВГ75.
4. Устройство хранения данных. Думаю, что SD флешки бы хватило.
5. Клавиатура PS/2.
6. COM порт.
Вот пока и все, что пришло в голову.
Жду критики, советов. Если кого тема зацепила, буду рад.
OrionExt
13.04.2017, 01:16
>Максимально простая схема, как можно меньше "рассыпухи"
Дальше не читал. Вы определитесь с требованиями.
Дальше не читал. Вы определитесь с требованиями.
А что здесь вас смутило? Я же написал, что ЮТ-88 меня не вдохновил. Это требование - следствие.
http://searle.hostei.com/grant/cpm/index.html
1. z80, под него весь софт пойдет, к тому же требует минимум обвязки и даже может сделать refresh 64kb DRAM типа 565ру5.
2. cp/m система из 70-х склепанная по образу и подобию rt11 и потому весь системный софт да и другой софт под нее подразумевает интерфейс общения с внешним миром по низкоскоростному каналу (типично это терминал на скорости 300...19200bps). Т.е. в теории в качестве "клавиатуры и дисплея" для cp/m компа сойдет обычный "COM-порт" на 581ва1 или 1002хл1. Графические программы под cp/м бывают 2-х типов, первый это cross-cp/m они работают с графическим терминалом примерно так же как и текстовые с текстовым (т.е. через тот же "COM-порт"), второй тип это работа с нестандартной видеокартой (тут для каждой проги надо либо добавлять спец. железо которое она хочет, либо ее модифицировать под железо которое уже есть, но это все на практике или не реально или очень сложно).
3. z80 не имеет встроенного "монитор"-а как pdp11 потому надо лепить внешнюю схему для начального старта, самое простое это EPROM на 2кб с адреса 0 который на старте "мониторную" часть себя же скопирует в RAM и отключится.
4. DISK - cp/m изначально работает с диском, потому обязательно нужен контроллер внешнего диска или эмулятор... тут есть 99999 решений и все они НЕ СТАНДАРТ изза того что изначально cp/m имел возможность внедрять в себя driver диска НО стандартного драйвера никогда НЕ БЫЛО. Так что надо googl-ить и искать себе подходящее решение (идельно было бы найти что-то типа контроллера MMC склепанного на 8051... идеальность тут в retro-вости контроллера, в малом количестве деталей и в "бесконечном" как для cp/m обьеме).
5. mp/m есть такая штука, но и cp/m3 тоже работает с банками памяти, очень интересная вещь, дает многозадачность и программирование с оверлеями (прямо как на pdp11), требует изначально "заложить" в схему MAPPER-MMU, считаю хорошим (лучшим?) mapper-ом тот что в стандарте MSX!
OFFTOP: хехехе, а вообще-то я склоняюсь к тому что развитие cp/m компов, да и самой системы, было очень ЧЕТКО подхваченно и продолженно M$-ом и ASCII в стандарте MSX/MSX2/MSX2+... так что если уж делать то MSX2+! Взять десяток вот этого:https://www.aliexpress.com/item/1pc-DIY-Prototype-PCB-Universal-Matrix-Circuit-Board-Breadboard-8-5x20cm-85x20mm-Top-Sale/32579073250.html?spm=2114.13010608.0.0.OQha6i повесить туда z80, ay-3-8910, 580ВВ55, v9958, линейку 565ру5, 2 линейки 565ру6, ROM, контроллер ps/2 от caro и простейший fdd контроллер + китайский gotek эмуль дисковода. Все связать мгтф-ом и наслаждаться и cp/m-ом и русским языком и msxdos-ом и symbos-ом (возможно иногда zanac ex и metal gear).
OrionExt
13.04.2017, 03:29
тише)
- - - Добавлено - - -
?. Xrust >> http://rc2014.co.uk/
shurik-ua
13.04.2017, 04:38
вот тут человек переболел примерно такой же "болезнью" )) - http://www.nedopc.org/forum/viewtopic.php?f=89&t=9155
... а я вот болею неспешно и вялотекуще, http://qsl.net/rw6hrm/html/z80.htm
Но это для тех, кому PS/2 и ВГА по барабану.
3.1. В качестве дисплея VGA монитор...
3.3. Идеальным было бы реализовать видеоадаптер на ВГ75.
ВГ75 привлекает тем, что асинхронная отчего её можно питать повышенным тактом, приблизив выходной сигнал до полосы захвата VGA (не обязательно точно стандарт с частотой строк 31 КГЦ и кадров 70 ГЦ, достаточно ~25 КГЦ, чтобы мультисинк VGA монитор начал показывать). Также ВГ75 имеет атрибуты, что даёт инверсию, мигание, подчёркивание, рамки и цвет, что также привлекает потребителей.
Но разумно ли связываться с ВГ75? Все давно знают, что это такое (по РК86). Приличный компьютер должен работать в реальном времени, без всяких ПДП рвущих прогон программы случайным образом. Что уж говорить о кодировке КОИ-7. В CP/M все программы в ASCII, т.е большие и маленькие латинские буквы. Для русских букв в 128-ми поддерживаемых ВГ75 символов, - места уже нет.
В своё время (в конце 80-х начале 90-х) я решал ту же задачу. Но, естественно, вопрос о применении ВГ75 мной даже не рассматривался. Мне нужна была нормальная текстовая машина (в тормозных графических на такте 2 МГЦ для текстообработки я тогда уже разочаровался), что-то типа КОРВЕТА но раза в 3 проще. Я сделал несколько компьютеров с текстовым адаптером (64*25) с одним атрибутом (инверсия знакоместа). Оттого экранное ОЗУ девятибитовое (готовый 9-ти битовый отпилок экранного ОЗУ КОРВЕТА). Это идеальное решение для CP/M компьютера.
Но затем понял, что удобнее модульность и потому сделал отдельный текстовый адаптер (30 ИМС), который работал с платкой ядра Z80 на такте 9 МГЦ (это максимум для Z80B; тогда Z80H, что разгоняется до 12 МГЦ не имел). 62256 при этом работают с одним тактом WAIT (62257-10L без WAIT). По архитектуре это - отключаемый кусок 0...3FFF, в котором до 2000 идёт ROM-BIOS и экран с 2000. В итоге для CP/M-программ есть сплошное ОЗУ 0...FFFF (на F800 по RESET кидался блок стандартных входов, что позволяло использовать ПО от отечественных БК на КР580).
Одна такая ЭВМ с текстовым адаптером была сделана из платы СПЕЦИАЛИСТА, для чего участок платы с РУ5-тыми был аккуратно выпилен лобзиком и на это место был закреплен готовый фрагмент с 8-ю ОЗУ 565РУ2 (1К*1). Это конструктивно проще, чем целиком паять проводками весь компьютер, т.к тут уже имеем готовый видеовыход и процессорное ядро с ПЗУ и ППА клавиатуры. Из работ при этом только перепайка входов у мультиплексоров КП12 и подпайка выводов ОЗУ к буферам и КП12.
Преимущество СПЕЦИАЛИСТА в прозрачном ОЗУ, в то время как в других моих текстовых адаптерах для синхронизации с ОЗУ работал WAIT. В отличие от ВЕКТОРА и ЛЬВОВА, приоритет по обращению к ОЗУ у меня имел не текстовый адаптер, а процессор. В ВЕКТОРЕ и ЛЬВОВЕ на синхронизации с ОЗУ теряется ровно 20% от частоты такта CPU. А при такой синхронизации торможение скорости меньше (по записи вообще без тормозов). Что, впрочем, в данном случае вообще не играет роли, т.к основное ОЗУ на РУ5 никак не тормозится. Хотя, когда в экран идёт обращение процессора, то по экрану бегают блёстки (чтобы это убрать достаточно схемки гашения видео-сигнала при обращении CPU в экран).
Но сейчас более простой текстовый адаптер можно сделать на 6845 или 7220. На 6845 и статике это ~15 корпусов, а на 7220 чуть меньше. Текстовый адаптер на TTL-логике хоть и имеет 30 корпусов, но зато может иметь атрибуты, а эти БИС ровно 8-ми битовые, так что при КОИ-8 придётся от атрибутов отказаться или ограничиться 128-ю символами, зато с одним атрибутом инверсии знакоместа. Можно ввести коммутируемый верхний набор символов (128...255), где будут переключаться два фонта - в первом русские буквы и псевдографика, а во втором тот же стандартный ASCII набор, что и коды 0...127, но в инверсии. Тогда, по крайней мере, в системных программах, что с латинскими буквами, Вы сможете иметь инверсию знакомест. А инверсия или "high-lighting" нужна для фирменных CP/M-программ.
С другой стороны, моно графический адаптер (хотя бы по схеме RFE, 10.1987 с экраном 512*256) обходится в тот же расход деталей, что и текстовый адаптер, но даёт и инверсию и графику. Только при этом уже нельзя ограничиться тактом в типовые 2.5...4 МГЦ, а надо разгонять CPU до 10-12 МГЦ, иначе будет тормозятина.
Ещё один вариант не стоит сбрасывать, это использование готовой CGA-карты, а лучше HERCULES. У меня был на XT вначале CGA, но затем я поменял на Геркулес, намного качественнее шрифт, лишь пришлось перестроить частоту строк в мониторе с 15.6 КГЦ на 19 КГЦ. Причём и по играм потерь не было, т.к большинство фирменных игр работало и на Геркулесе, имитируя цвет плотностью точек (кстати бывают Hercules-Color что дают и цвет). Хотел бы поставить себе Геркулес в РК86 (если смогу достать), это решит все проблемы РК86 (ROM-BIOS при выводе символа будет одновременно писать и в экран 76D0...7FFF и в экран Геркулеса включённый на E000...EFFF). Можно использовать и EGA, - у него частота строк уже 21 КГЦ. Может быть хороший SVGA-монитор сможет синхронизироваться и на столь пониженной частоте.
Для клавиатуры удобно поставить ППА. Тогда выбор клавиатур шире. В качестве клавиатуры удобно использовать аппаратную клавиатуру, которая даёт готовый ASCII код, сопровождаемый нулевым стробом. Тогда годится любая промышленная клавиатура из 70-х, 80-х, например 15ВВВ-97, КОНСУЛ, клавиатура ИРИШИ, клавиатура АГАТА или от APPLE-II. Если такой нет, то простейший контроллер на Z80 (SU880, что жрёт 4 мА и РФ2, а ОЗУ нет) принимает последовательные посылки от PC-клавиатуры и выдает на компьютер готовый ASCII-код. И не нужны никакие контроллеры на ПЛИС, что явно не в духе CP/M.
Советую использовать модульность, тогда можно менять состав блоков. Блок ядра (CPU, ОЗУ, ПЗУ и порт клавиатуры). Блок внешней памяти, это КНГМД или КНЖМД (в крайнем случае, что-то типа новомодных "флэш-накопителей", что не романтично, не в духе времени). И плата внешнего текстового адаптера (что для начала может быть просто параллельный интерфейс ~12 проводков, для связи с IBM PC, что может играть роль комфортабельного терминала, и внешней массовой памяти).
Есть у меня древняя идея, как интегрировать рэтро ЭВМ в IBM PC, чтобы использовать PC в качестве экрана при 100% совместимости со старым ПО. Прошу без насмешек, это форум, - здесь принято высказывать и обсуждать идеи.
Для этого я предполагал использовать СПЕЦИАЛИСТ или ОРИОН, в которых шина (адреса и данные, естественно, после буферов) подключается проводами к платке ППА ВВ55, установленной в 386-тую. Самодельная платка с ВВ55 для разъёма XT, у меня есть. Кстати, позволяет подключать программатор ПЗУ от ОРИОНА к IBM PC и прошивать ПЗУ из эмулятора ОРИОНА, используя программу для прошивки УФ-ПЗУ от ОРИОНА без изменений, т.к все обращения к F600 эмулятор переадресует на реальный ППА в IBM PC).
В схему 8-ми разрядки добавляется ловушка на адреса её экрана. По записи в экран, взводится триггер и 8-ми разрядка стопорится по WAIT. На PC простейшая программа непрерывно сканирует 1 бит в порту ППА, т.е триггер записи в экран (только записи). И как только там будет сигнал, то с ППА считываются адреса и данные с шины 8-ми разрядки, а затем выкидывается строб, сбрасывающий триггер "записи в экран", после чего 8-ми разрядка продолжает прогон своей программы, а IBM PC уходит в процедуру визуализации только что произошедшей записи в экран.
Тут применять апп.прерывания в IBM PC не имеет смысла, т.к 386-тая быстра, - запись в экран тормознёт 8-ми разрядку всего на пару тактов. С программой для PC проблем нет, т.к это подпрограмма из моего эмулятора 1997 года (~100 строчек кода - п/п-мма визуализирующая запись одного байта в экран РК86 или ОРИОНА).
Сложность именно в том, что нужна PC со слотами и шиной XT, т.е 386-тая (или 486-тая, где BIOS-ом можно поставить скорость слота, как у XT). Для ПЕНТИУМА я просто не знаю, как сделать самодельную периферийную платку для его слотов.
"Плюс" такой конструкции в том, что из железа нужно лишь ядро 8-ми разрядки. "Минус" - нужна PC-шная периферийная плата с ППА ВВ55. Возможно где-то можно купить аналогичную промышленную периферийную плату для ПЕНТИУМА. При такой конструкции очень удобно писать и не "отходя от кассы" тут же проверять программы, причём это будет проверка именно в реале, а не на эмуляторе.
Данная идея позволяет получить компьютер совместимый со всеми отечественными 8-ми разрядками (тогда схема упрощается, триггер WAIT взводится по каждой записи в ОЗУ, а оценку попадает эта запись в экран или нет, делает уже IBM PC).
Ну что же, проект Гранта Сирла почти полностью мне подходит. Жалко, что подключение к VGA там не реализовано.
- - - Добавлено - - -
barsik, ВГ75 в моем представлении не должен получать доступ к памяти процессора. Пусть себе работает со своей собственной. А процессор общается с ним как с I/O.
ВГ75 в моем представлении не должен получать доступ к памяти процессора
Я могу представить себе две изолированные шины - одна системная, вторая шина ВГ75 и ПДП.
Но ведь процессор должен как-то писать в экранное ОЗУ. Вы собирались использовать дорогое двухпортовое ОЗУ, чтобы разнести шины? Или же экранное ОЗУ и шина ВГ75 будет лишь временно включаться в системную магистраль? Возможно, при принудительном блокировании на это время сигнала запроса байтов от ВГ75 или отмены его такта, чтобы никаких ПДП за время доступа в экран не возникло.
Хотелось бы использовать, по возможности, только "исторические" компоненты
Для любителя аппаратчика интересно сделать конструкцию на деталях из 70-х и доказать тем самым, что приличную машину можно было сделать в 1979.
Не думаю, что ПЛИС это из 70-х или 80-тых. Да и тупое повторение чужой конструкции, которая к тому-же для того, кто её повторяет, представляет из себя лишь непонятный "чёрный ящик" - это совершенно неинтересно. Тогда уж интереснее спаять РК86 проводочками на слепыше... Для меня, например, интерес в этом хобби, заключён в возможности творчества. А повторение чужого, тем более непонятного - какой в этом интерес?
Да и настроить конструкцию, состоящую из чужих и непонятных "черных ящиков" с чужим ПО на порядок сложнее, чем отладить простейшую, понятную и обезьяне конструкцию на TTL-логике, для которой легко написать (а потом и сопровождать) базовое системное ПО. Да и по цене изделие Сирла обойдётся дороже. К тому же и искать Z80-SIO и другие, непопулярные на местных барахолках, компоненты сложнее. Против Гранта Сирла даже любая конструкция на ВГ75 выглядит гениальной и намного более приемлемой...
Ну что же, проект Гранта Сирла почти полностью мне подходит. Жалко, что подключение к VGA там не реализовано.
В его же версии под ФПГА реализовано VGA, и вполне хорошо работает Конструировать в плис-е не менее увлекательно, чем паять проводочки и писать длиннопосты, вряд ли понятные даже автору оных. кто бы не утверждал обратное. Впрочем там тоже есть к чемуу паяльник приложить.
Конструировать в плис-е не менее увлекательно, чем паять проводочки... кто бы не утверждал обратное
Конструировать может быть, но речь-то идёт о тупом обезьяннем повторении чужой конструкции.
И если уж так хочется "программировать железо", то мне легче и намного быстрее, написать эмулятор конструкции, чем трахаться с железом. А если речь идёт о чисто CP/M машине то вообще просто (не надо эмулировать архитектуру, что составляет 95% сложности). Если есть модуль эмуляции Z80 и обрамление, то остаётся написать только эмуляцию конкретного текстового экрана и клавиатуры плюс интерфейс с внешним миром (эл.диск из ОЗУ или эл.диск в MSDOS-файле). На всё это достаточно пары часов работы.
Но сюжет заключается именно в получении настоящего реала, а не подделки на ПЛИС, в которой времянки никогда не соответствуют реалу.
писать длинные посты, вряд-ли понятные даже автору оных...
Зачем Вы пишете ерунду? Возражайте по существу. Ясно, что если кто-то что-то пишет, то он понимает о чём. Да и написаны такие простые вещи, что всё понятно и ребёнку. Не думал, что на этом сайте найдётся хоть кто-то, кто что-то не поймёт...
ВГ75 интересно заставить работать в нужном режиме без применения современной элементной базы. В любом случае выделять ей адресное пространство не хочется. С другой стороны делать отдельно терминал на ней тоже вариант не самый удобный. Надо это обдумать получше.
Меня другое беспокоит. Получается, что большинство софта под cp/m не умеет нормально работать с русским кодовыми таблицами. Вот это печально.
P.S. Друзья, давайте не будем только холивары устраивать. Я с удовольствием обе позиции выслушаю. Но одно не должно отрицать другое. Я не стремлюсь полностью от новой элемертной базы отказываться. Вот границу провести - это правильно.
Получается, что большинство софта под cp/m не умеет нормально работать с русским кодовыми таблицами
Эм... это откуда такое предположение? Нормально работает, по крайней мере WordStar4 и DBase. Им ж пофиг, что отбражать - псевдографику или кириллицу, они работают с 256 символами из восьмибитной таблицы (хоть в документации и говорится об использовании в системе 7-ми битного ASCII кода - а другого на момент разработки ОСи и не было!) . Всё зависит от того, какую кодовую таблицу будет поддерживать ваш терминал или устройство отображения (и устройство ввода, кстати). Рекомендую Альтернативную кодировку, СР866 которая, чтобы хотя бы с РС была совместимость по текстовым файлам.
Был диалог на Гиктаймсе с Сергеем Поповым, одним из авторов известного радийного компьютера.
Мой вопрос: У меня возник один нескромный вопрос к компьютеру из Вашей публикации geektimes.ru/post/274054 — а какая кодировка кириллицы в нём применялась?
Ответ: Если кратко, то никакая. Все определяет терминал. В моем случае это был Электроника-15ИЭ.
Вот сказать, что нет стандарта для кириллицы в СР/М - это вернее. Посему и ВГ75 в этом вопросе полный отстой, тлен и печаль, ибо поддерживает только семибитную таблицу символов (128 знаков). Хотя, если есть желание извратиться в КОИ-7... xD
Эм... это откуда такое предположение?
Это оттуда, что вторая половина кодовой таблицы, как я понял, использовалась в качестве атрибута инверсии или яркости. Если так, то с русской таблицей часть текста может быть нечитаемой.
Посему и ВГ75 в этом вопросе полный отстой, тлен и печаль
Это не значит, что проблема не решаема. В соседней ветке вон вполне удалось и цвет и русский язык к терминалу на вг75 прикрутить.
может быть - определяющая фраза! ;) И, если возможно, пруф, откуда взято. Не надо париться, атрибуты относятся только и исключительно к устройствам отображения, а не к системе в целом. Ну, разве что, возможно к отдельно взятым программам, но есть же аналоги.
ЗЫ. Сирловская система нормально работает с кириллицей через СОМ-порт, никаких атрибутов не замечено.
Получается, что большинство софта для CP/M не умеет нормально работать с русским кодовыми таблицами
Более того, некоторые программы с 8-ми битовыми символами конфликтуют, не допуская их. Например, используют 8-мой бит, как маркировку или как внутренние команды программы. Только единицы программ, и то только после "крака" удаётся заставить работать с символами в 8 бит. Например, изначально 7-ми битовые BDS-C, AZTEC-C и Turbo-Pascal удалось заставить работать в КОИ-8. Но иногда русификация удаётся лишь с потерями. Так самая ценная из всех CP/M-программ, макро ассемблер М80 в оригинале 7-ми битовый, отчего в строках DEFB нагло сбрасывает 8-й бит (и даже комментарии в КОИ-8 не переносит). Кракерам русификаторам пришлось отыскивать все команды AND 7F и заменять их на NOP. Это и привело к трагедии М80. Из-за этого, хотя после крака тексты в КОИ-8 перестали автоматически конвертироваться в КОИ7-Н2, но зато теперь, если в мнемонике команды или в имени переменной вставить хоть одну русскую букву, то M80 зависает. Что очень неудобно.
Часто в исходнике в 60 килобайт, после написания комментария забудешь назад переключить регистр, то всё, - пипец. Программа перестаёт транслироваться и листинг потерян. Единственный выход конвертировать весь исходник в КОИ-7, отчего все тексты и комменты станут тоже в КОИ-7 - программа будет транслироваться, а тексты в DEFB легко поправить (не так их и много) и работать программа будет. Только дальше сопровождать програму неудобно, т.к все русские комменты стали в латинских буквах, а мнемоники - маленькими латинскими буквами, что непривычно и вредно для зрения. Искать точку дефекта приходится долго и упорно вставляя ровно посередине текста оператор END, что после трансляции позволяет сделать вывод о том, до или после него находится место с русской буквой в мнемонике.
По поводу ВГ75 и её 7-ми битовой кодировки. Если не пожалеть один атрибутный выход (что, увы, сделает цвет неполноценным, там нужны все 4 выхода), то нет проблем иметь КОИ-8. Работать конечно программы будут с текстами на 7 битов, но это не проблема.
В ИРИШЕ, разработанной в 1984 году (кстати, это реально первый приличный компьютер в стране) авторы даже имея возвожность иметь не только 8 битов, но даже 9, всё-равно использовали именно 7 битов. Для этого они использовали стандартные коды для переключения регистра РУС-ЛАТ. Это коды 0E и 0F. Именно такие коды вырабатывают отечественные аппаратные клавиатуры при нажатиях клавиш <РУС> и <ЛАТ>. Драйвер вывода на экран тоже понимает именно эти коды и по ним переключает фонт. Потому тексты ИРИШИ могут быть как 7-ми битовые, так и 8-ми битовые, - этого пользователь никак не замечает (в обоих случаях на экране КОИ-8). Авторы ИРИШИ заранее знали, что 8-ми битовый код непригоден для CP/M, поэтому и применили такой хитрый трюк.
Насчёт WordStar. У меня в 1991 он не работал в КОИ-8. Удивлён, если это не ошибка и есть WоrdStar для КОИ-8. Может речь о WordMaster или FinalWord?
Кстати о регистрах клавиатуры. Извиняюсь за отход от темы.
Есть вопрос к знатокам Windows. Уже 15 лет мечтаю исправить одно неудобство в Windows. А именно, - изменить в ней код клавиши, переключающей РУС-ЛАТ. В LINUX это можно выбрать при инсталляции, а в дурацкой Windows и в её программах это никак не регулируется (по крайней мере до Windows XP). В Windows переключение РУС-ЛАТ приходится делать сочетанием Alt+Shift, что очень неудобно, т.к иногда при быстром наборе в редакторе 'UltraEdit' переключение не срабатывает, а иногда улетаешь в какой-то режим, из которого удаётся выйти только двумя нажатиями на ESC, а это дико бесит. В 90-е (да и сейчас для правильного форматирования текстов) я пользовался "Словом и Делом" А.Гутникова, где переключение в ЛАТ - левый Shift, а в РУС - правый Shift. Очень удобно, да и индикация цветом бордюра не позволяет ошибиться. В русификаторе UNIVGA это переключается правым Shift-ом триггерно, да и многие приличные русификаторы позволяли выбрать клавишу для РУС-ЛАТ. Т.е с MSDOS программами, даже запуская их в Windows, проблем нет. Однако для программиста, ничего удобнее UltraEdit ещё не придумали, поэтому и приходится работать с текстом в Windows, где, увы, идиотическое переключение РУС-ЛАТ.
Один умник мне сказал, что в Windows тоже всё настраивается, что достаточно изменить одну строчку в регистре Windows, что всё исправит. Я пытался найти в регистре что-то похожее, но тщетно, там слишком много строчек и никак не догадаться что менять. Может кто-нибудь знает как настроить Windows на более удобное переключение РУС-ЛАТ, хотя бы пусть будет правый Shift. При одной клавише не ошибёшься да и намного удобнее.
оффтоп.
увы - это жалкое подобие "левой руки". и виндовсе 10 такая же фигня.
Нет, речь не о том, чтобы использовать стандартные установки. Разумеется, все возможности настроек я просмотрел, но не нашёл того, что хотелось. Ведь нет разницы, Alt+Shift или Ctrl+Shift. Это одинаково неудобно. Alt+Shift всё же для пальцев удобнее. Нужно включение РУС-ЛАТ одной клавишей, не двумя.
Большое спасибо. Punto-Switcher решает проблему с переключением РУС-ЛАТ. Жалко только, что в режиме SVGA, что использует Windows, нет бордюра, который в UNIVGA очень удобно индицирует включённый регистр клавиатуры.
Без проблем сделал, чтобы левый Shift включал латинский регистр, а правый Shift - русский, триггерное переключение и использование CapsLock в качестве РУС-ЛАТ запретил (зачем? - у CapsLock своё предназначение, которое тоже нужно). То есть сделал переключение РУС-ЛАТ регистра, так же как это в Слово и Дело А.Гутникова. К сожалению, в Punto-Switcher нет команды 'Ctrl+Забой', что переводит последнее введённое слово в другой регистр, что очень полезно, когда ошибся в регистре при наборе слова или строки. Только надо сразу забыть о переключении РУС-ЛАТ, что использует сама Windows, иначе, если нажать Alt+Shift, то переключение регистра заданное в установках Punto-Switcher перестаёт работать до тех пор, пока снова не нажмешь Alt+Shift.
В Punto-Switcher полно других возможностей. Например, можно сделать так, чтобы твоя кличка использованная на сайтах и пароль для входа всегда вводились в правильном регистре, что избавит от хлопот. Возможно также, что распознавание слов для автоматического переключения регистра РУС-ЛАТ тоже окажется полезным. Да и проверка грамматики не повредит. Кстати, оказывается YandexPuntoSwitcher автоматически грузится при закачке YandexDisk браузера и он оказывается у меня давно был (но я сдуру его не инсталлировал, т.к не понял что это, и не хотел тратить винт и память на что-то неизвестное).
Рекомендую альтернативную кодировку, СР866, чтобы была совместимость с РС по текстовым файлам
Это не есть здравая мысль. Этот вопрос обсуждался в 1991 году, когда на многие отечественные 8-ми разрядки ставили CP/M. КОИ-8 на порядок удобнее для программирования, чем альтернативная кодировка.
Альтернативная кодировка - это была временная вынужденная мера, чтобы импортные MSDOS программы использующие псевдографику можно было использовать на русифицированных PC. Но в CP/M нет ни одной программы, что использовала бы псевдографику IBM PC. И наоборот, полно программ, что используют КОИ-8 и чертят рамки псевдографикой КОИ-8, которая имеет те же граф.символы, что и альтернативная кодировка (коды другие, смотри в книге Фигурнова "IBM PC для пользователя", 1991). Правда редкие программы от бытовых 8-ми разрядок можно заимствовать для "железо-независимой" CP/M, т.к программы глупых любителей обычно привязаны к железу конкретного компьютера. А для использования тех программ в КОИ-8, что сделаны корректно, Вам придётся иметь драйвер консоли совместимый с использованным автором (обычно это не 100% VT52).
Но главные доводы в пользу КОИ-8 не это и даже не то, что в LINUX, в которой кодировку выбирали русские люди для русских людей, а не враги, чтобы сделать нам гадость (как было с кодировками для Windows и MAC), естественно, тоже используется кодировка КОИ-8. Главное в том, что есть соответствие между латинскими буквами и русскими. Можно просматривать текст в дампе отладчиками, которые не знают, что бывают 8-ми битовые символы. А смена регистра символа состоит в изменении одного бита. Не требуется табличная конверсия символов, чтобы пользователь мог вводить ответ как в верхнем регистре (маленькими буковками), так и в нижнем (заглавными буквами). Достаточно команды AND 5F. В фирменных текстовых редакторах команды управления это клавиша с Control. При КОИ-8 это работает, а при альтернативной нет, нужна табличная перекодировка. Потому при альтернативке команды управления работают только в латинском регистре.
Если не загружен драйвер 8-ми битового шрифта, то CP/M сбрасывает старший бит и при альтернативной кодировке текст на экране выглядит "мусором", а текст в КОИ-8 читается. Кроме того, драйвер опроса матричной клавиатуры выдаёт коды в ASCII (0...127), и расположение ЙЦУКЕН, как на руской пишущей машинке. Русские буквы там же, где английские. Потому драйвер клавиатуры априори вводит текст в КОИ-8. Для АЛЬТ-кодировки изначально полученный код в КОИ-8 надо таблично конвертировать в АЛЬТ-кодировку, что бесполезно увеличивает размер драйвера на 300 байтов (2 таблицы). Замечу, что некоторые мои драйверы ОРИОНА и СПЕЦИАЛИСТА поддерживают работу в АЛЬТ, КОИ-8 и КОИ-7 (^L - АЛЬТ/КОИ8/КОИ7, ^G - ввод псевдографики).
Никаких неудобств от отличий кодировок на PC и в CP/M не возникает. Для переноса файла с текстом достаточно перетащить мышью файл на пиктограмму TO_CPM, отчего запустится BAT-файл, который автоматически сделает конверсию, если файл имеет расширение TXT или ASM и перебросит результат в каталог в котором работает программа обмена с CP/M (это или дисководный CHANGER работающий с дискетой, или программа трансфера по проводной линии, или просто каталог, в котором Ваш эмулятор, которым Вы прогоняете программы 8-ми разрядки, хранит файлы дискеты).
При трансляции программ то же самое. Тексты набираем в АЛЬТ-кодировке (дурацкая Windows кодировка не годится, т.к в ней нет псевдографики и получить рамки в программах невозможно), а при старте BAT-файла для трансляции, исходники автоматически перекодируются конвертором в КОИ-8 и только затем транслируются с помощью М80. Естественно, нужен редактор, который может работать в любых кодировках, лучше всего UltraEdit (т.к в нём много других полезных программисту свойств).
По кодировке. Да, я враг ;), я выразил чисто собственное мнение, ибо считаю, что писюков сейчас много и лучше подстроиться к ним, нежели вспоминать бойни 90-х. Ссылки на отладчики и драйвера неинтересны, поскольку самодельный комп под СР/М сейчас нужен в большинстве случаев не для программирования и отладки (для них есть более удобные системы на более мощных машинах), а для обычной работы - тексты, базы, управление чем-нить, максимум Бейсик. Всё. Остается только выбрать подходящий софт, дабы не скакать с бубном и AND'ами в попытках "говорить по-русски" и совместимости.
Если мы сейчас, в текущее время, говорим о старых машинах, то вспоминать о совместимости между ними (старыми) смысла уже нет, таких машин мало, и каждый делает их под свои вкусы, лишь бы быть совместимыми с современным железом и софтом. Чисто ИМХО.
В LINUX, в которой кодировку выбирали русские люди для русских людей, а не враги, чтобы сделать нам гадость (как было с кодировками для Windows и MAC), используется кодировка КОИ-8
Да, я враг
Вы не враг. Разве Вы придумали Windows-кодировку CP1251? Это сделали до Вас настоящие враги народа, которые тогда работали на фирме Microsoft. Это было в 1987, когда вышла Windows 2.0, которая поддерживала кирилицу.
Остаётся только выбрать подходящий софт, дабы не скакать с бубном и AND'ами в попытках "говорить по-русски" и совместимости
Вот именно. Я говорил об удобстве программиста и избавлении его от ненужной головной боли связанной с кодировкой. Хорошо, допустим плевать на интересы программиста. Поговорим об интересах пользователя. В фирменных программах CP/M, управление сделано сочетанием клавиш с клавишей Control (это почти все программы). Если не для текстовых редакторов это не важно, то для текстового редактора это важно.
Если использовать АЛЬТ-кодировку, то одноимённые символы (например A и А) оказываются на разных клавишах, поэтому Вам придётся делать второй HELP для русского регистра и запоминать его для работы. При КОИ-8, например, для удаления строки, в любом регистре надо удерживая <Control> нажать клавишу, где написано 'Y'. При АЛЬТ-кодировке, в латинском регистре то же самое, но при включённом русском регистре надо жать уже не на 'Y', а на что-то совсем другое. Таким образом, с АЛЬТ кодировкой Вам понадобится собственный текстовый редактор (можно адаптировать текстовый редактор от СПЕЦИАЛИСТА, где клавиша <Control> отсутствует как класс, тем самым соответствие клавиш в русском и латинском регистрах не волнует).
Кстати Super Text стоит того, чтобы им пользоваться. Когда я стал набирать тексты на 386-той, то жалел о нём. Даже написал драйвер консоли для фирменного эмулятора, чтобы получить доступ на PC, однако выяснилось, что фирменные CP/M эмуляторы (22NICE, Z80MU и др) неполноценны.
Но допустим плевать и на редактор. А что же тогда остаётся? Из того, для чего нужна 8-ми битовая кодировка. А вообще ничего. Потому, что если откинуть те программы, что кракнуты для 8-ми битовой кодировки (а это как указано выше лишь несколько компиляторов и ассемблер), то остаются чисто 7-ми битовые CP/M-программы, где без разницы какая у Вас кодировка, хоть марсианская. Потому что в этих программах 8-ми битовые символы на экране отсутствуют.
Если не писать программы в CP/M и не пользоваться текстовым редактором CP/M, то остаётся только одна вещь для чего нужна 8-ми битовая кодировка. Это чтобы смотреть HELP-ы для программ. Но Help-ы фирменных программ написаны на латинице, на иностранном языке и АЛЬТ-кодировка здесь не нужна. Остаётся смотреть только HELP-ы тех программ для CP/M, что пользователь такой чисто CP/M-машины сам себе напишет и снабдит их HELP-ом на русском языке в АЛЬТ-кодировке. Но если он сам написал, то HELP ему и даром не нужен (а встроенный краткий HELP в программы выгоднее писать на английском, т.к получается короче, меньше текста, больше информации влезает в окно HELP-а).
Получается, что если текстообработка в CP/M не нужна, то вообще 8-ми битовая кодировка ни за чем не нужна. Чтобы делать краткие заметки можно переключать фонт на КОИ-7, который семи-битовый.
При АЛЬТ-кодировке, в латинском регистре то же самое, но при включённом русском регистре надо жать уже не на 'Y', а на что-то совсем другое.
Вот поэтому в прошивке своей Расширенной ASCII-клавиатуры (http://qsl.net/rw6hrm/html/ascii_kbrd2.htm)я предусмотрел такой финт - если надо нажать <Ctrl>-/что-то_на_латинице/, то можно так и нажимать вне того, в каком режиме стоит клава - латинице или кириллице, прописной или строчной. Результат будет ожидаем.
Потому что в этих программах 8-ми битовые символы на экране отсутствуют.
Не на экране, а в самой обрабатывающей их программе. На экране может быть всё, что угодно, на что прошито отображающее устройство/терминал.
если текстообработка в CP/M не нужна
Это единственное, что действительно нужно на любом компе. Игры не считаем. Иначе нафиг этот комп нужен. А пишут не только программы. Стихи, к примеру, те же хелпы... ;)
Вот поэтому в прошивке своей 'Расширенной ASCII-клавиатуры' я предусмотрел такой финт - если надо нажать <Ctrl>-/что-то_на_латинице/, то можно так и нажимать вне того, в каком режиме стоит клава - латинице или кириллице, прописной или строчной.
Значит при использовании АЛЬТ-кодировки сразу отпадают все известные реализации клавиатур. Как все промышленные типа 15ВВВ-97, так и эмуляции матричной клавиатуры с матрицами РК86, КОРВЕТ, СПЕЦИАЛИСТ на ПЛИС, что сделаны на этом сайте. Придётся сделать собственную реализацию контроллера клавиатуры IBM PC (или другой клавиатуры, какую будет использовать ТС). Стоит ли столько хлопот лишь только для того чтобы не писать BAT-файл (из 2-х строк) запускаемый для переноса текстовых файлов из IBM PC на реал?
Впрочем, все типы клавиатур можно использовать, если они позволяют вывести сигнал <Control> на выход адаптера клавиатуры. Всё остальное можно сделать программно, отчего в фирменных текстовых редакторах не будет проблем. Кстати поэтому, замену прошивки для конверсии кодов от русских букв нажатых одновременно с <Control>, в кoды однозвучных латинских букв за вычетом 40H, в Вашей клавиатуре можно было и не делать.
Достаточно было бы вывести из адаптера клавиатуры бит состояния линии <Control>. Тогда всё остальное делает драйвер кравиатуры в CP/M. Т.е если код получен без помощи <Control>, то драйвер клавиатуры выдаёт CP/M-BIOS-у код без модификации. А если драйвер узнал, что код от адаптера клавиатуры получен с участием клавиши <Control> и этот код русский, то делается табличное преобразование кода.
Вообще зачем клавиатуре выдавать 8-ми битовый код? Клавиш всего 64. Обычно аппаратные клавиатуры выдают 7-ми битовый код ASCII. А фпаг 8-го бита поддерживает драйвер, в КОИ-8 этот бит и называется РУС-ЛАТ. При КОИ-8 удобно этот бит иметь 0 или 80H и делать OR с этим флагом полученного кода. Т.е при КОИ-8 весь расход на поддержку КОИ-8 это одна команда ассемблера, а при альтернативке это или аппаратное преобразование кодов на ПЗУ (что Вы и делаете) или программное табличное преобразование, что грамотнее, т.к программное решение всегда умнее и проще, чем аппаратное
Кстати Ваша клавиатура сложнее, чем более дешёвый вариант того же, что впервые был описан в журнале 'Funkamateur 04.1984', где для экономии логики применены уровни сигналов (подпитка эмиттеров на -0.7 вольта). Согласен, что Ваша клавиатура намного проще, чем обе клавиатуры от ИРИШИ и другие варианты аппаратных клавиатур опубликованных в МПСС в 80-тые.
Я собирал простую, но качественная клавиатуру из книги "Microelectronik in der Amateurpraxis 3" Berlin, Militarverlag DDR,1987 (https://www.tib.eu/en/search/id/tema%3ATEMAE88071489135/Mikroelektronik-in-der-Amateurpraxis-3-2-Aufl-/?tx_tibsearch_search%5Bsearchspace%5D=tn) страница 84 (имеет клавиши Caps Lock, Shift Lock, Ctrl, Shift и даёт автоповтор). В этой же книге описана схема чтобы передавать код не параллельно, а последовательно по 3-м проводам. Другие комп.книги 80-тых из ГДР (http://www.google.ru/url?q=https://www.mikrocontroller.net/topic/348040&sa=U&ved=0ahUKEwi8w7D_paTTAhVIhiwKHVnoDVkQFgggMAI&usg=AFQjCNGIp6BD7BvBZnwP4ksmrlZO62t9fg).
Зря никто не ходит на немецкие сайты и не читает немецкие книги для любителей микропроцессоров. Интересно, что в 80-е годы в крошечной ГДР было больше самодельных компьютеров и их качество было выше, чем у нас, где в те же годы кроме РК86 ничего не было. http://www.robotron-net.de/eigenbau.html
shurik-ua
15.04.2017, 01:26
Вот какие формы может принять "заболевание" (только в хорошем смысле) если нет финансовых и временнЫх ограничений ) -
https://www.youtube.com/watch?v=C8txvmXUIJQ
Во-первых поздравляю всех с праздником. Во вторых благодарю за ваши ответы, которые дали мне богатую пищу для размышлений. Вот некоторые предварительные выводы.
По аппаратной реализации видеоадаптера. Один из вариантов его я вижу как терминал, только доступ просто через i/o порт. При этом не занимается системная память и не приходится процессору простаивать во время ПДП либо гасить экран, когда простой недопустим. Но тут и свои недостатки. Придется как-то управлять терминалом. Может с этим справится, например, i8051? Он с ВТ57 подружится? Это если на ВГ75 делать адаптер. С другой стороны, мне сложно придумать, зачем процессору может понадобится запрет прерываний. Разве что при работе с внешними устройствами? Но это тоже не процессорное дело. Для того и нужен ПДП и прерывания. Вот такие пока мысли. Жду вашей оценки.
Подумав насчет кодировки, уже почти согласен ка КОИ-7 с переключением наборов. Если все равно большинство старого софта поддерживает только 7-бит кодировки. Да, переключение разных наборов решило бы большинство проблем, кроме одновременного отображения русских и латинских символов.
По идее, 8051 не имеет входа приостановки. Поэтому наверное, напрямую не подружится с ВТ57. Нашел старый документ, который видел лет 15 назад - AP-223 8051 Based CRT Terminal Controller. http://www.diakom.ru/el/elfirms/appnotes/INTEL/ap223.pdf
Там используется i8276, увы. Его нигде не купить. Но сам документ весьма интересен и познавателен. Как вариант - пытаться на 8051 эмулировать ПДП, как это сделано в соседней теме http://zx-pk.ru/threads/26455-chto-maksimum-mozhno-vyzhat-iz-kr580vg75-intel-8275-obsuzhdenie.html?p=907867&viewfull=1#post907867, или просто взять ту конструкцию за базу.
Я развожу плату вышеописанной версии.
P.S. P8276 нашелся на EBAY, т.е. купить его в принципе возможно.
PP.S. Стоит только поискать - такое находится 8085 и 8275 без ПДП, по идее, должно смасшабироваться на 8051 - http://www.nedopc.org/forum/viewtopic.php?t=10597
OrionExt
16.04.2017, 22:40
Во-первых поздравляю всех с праздником. Во вторых благодарю за ваши ответы, которые дали мне богатую пищу для размышлений. Вот некоторые предварительные выводы.
По аппаратной реализации видеоадаптера. Один из вариантов его я вижу как терминал, только доступ просто через i/o порт. При этом ...
Xrust, тоже с праздником. А CP/M – видит только стандартный терминал VT52 и т.п.:) КОИ7 и терминал -это уже дело второстепенное (от терминала зависит) и тем более не от ВГ75. О Компьютере для CP/M интересуетесь?)
OrionExt, собственно задача и сводится к созданию компьютера и терминала. Вот только вопрос в реализации. Можно просто к com порту PC подключиться, можно видеокарту сделать. Наверное, идеальным решением будет предусмотреть все варианты. Если будет установлена видеокарта, то из ее пзу загрузится драйвер. Главное заранее предусмотреть совместимость с существующими стандартами cp/m.
OrionExt
16.04.2017, 23:07
Xrust, "СР/М - это просто". Начните с малого. Z80-Rs232 <-> Rs232-PC (терминал). Это стандартов СР/М не затронет. А что дальше, решите по результату…
OrionExt, прихожу к выводу, что так и следует сделать. Вот только хочу пойти дальше. Универсальная архитектура, где можно будет использовать и кр580 и z80. Осталось решить с системной шиной, которая полностью поддерживала бы оба процессора. Может уже какой-то готовый стандарт использовать? Может быть S-100?
Я сделал себе СР/М машинку на основе вот этого http://cpuville.com/Z80_kit.html
Мне не понравилась идея переключать конфигурацию разными портами (в оригинале 0 и 1) - сделал все через один порт 0 на ТМ8. Сделал несколько конфигураций - ROM+RAM1/2, RAM1/2, RAM1, RAM2, все отключено. Плата по размеру винчестера 3,5. Дешифраторы памяти и портов В/В сделаны на РТ4. Скорость обмена 19200. Порт расширения не делал - планирую сделать отдельной платой через разъем процессора. Пробовал старенькие винты Сигейты на 40 и 80Мб - пишет и читает, но СР/М не запускается, с Самсунгом на 10Гб - все ОК.
http://savepic.ru/13658776m.jpg (http://savepic.ru/13658776.htm)
Порылся у себя в шкафу. Нашел вм80а, гф24, вк28. Несколько штук 2764 и одна рр какая-то. Память какую использовать - еще не решил. Но есть целая куча ру5. Грех все это не использовать).
Хочу развернуться по полной и максимально использовать мк 580. В том числе кпдп и кп. В базовом варианте сделаю порт на вв51, а там посмотрим. Так же планирую попробовать сделать шину расширения isa8.
Выложил все материалы https://yadi.sk/d/P2sbcHAq3HQQVF
Обращаю внимание на разъем DB-09 - по схеме это "мама", т.е. этот компик подключается к РС, если использовать его самостоятельно с каким-то терминалом, то нужно ставить "папу" и изменить разводку на зеркальную. Ром_монитор и спм_лоадер изменены под данную схему.
Пробовал старенькие винты Сигейты на 40 и 80Мб - пишет и читает, но СР/М не запускается, с Самсунгом на 10Гб - все ОК.
[/url]
А с CF вместо винта будет работать?
В доке есть фото CF и написано "Here are photos of a solid-state IDE drive and a CF drive in an adapter, with attached power supply wires:" Значит - работает.
TomaTLAB
10.06.2017, 22:00
Господа, как вы думаете, для реализации мапера, что лучше сделать: некое одно большое линейное адресное пространство, страницы из которого можно подставлять в окна (какой кстати оптимальный размер окна?) в пространстве 64к. И где в разных местах можно будет поселить ОЗУ, ПЗУ, экранные буферы и прочий ливер. Или добавить еще деление по "слотам" как в MSX?
Не знаю почему, но вот от идеи с саб-слотами в MSX, я честно говоря не в восторге. Сделал бы от 16 до 256 слотов, но чтоб все одинаковые.
И убедительная просьба на данный момент, при обсуждении данного вопроса, про схемотехнику и уж тем более про количество потребных микросхем забыть от слова совсем.
Я хочу понять принципиальный момент, и не обязательно в привязке к CP/M. Удобство портирования чего нибудь еще тоже интересно.
TomaTLAB, а где можно почитать про маппер MSX? И может кто подскажет как в CP/M и MP/M решалась проблема с барьером 64к?
- - - Добавлено - - -
Вот если мое мнение спросить, то я предложу следующее, пока в самом общем виде. Произвольное количество страниц по 64к. Система (cp/m) при запуске приложения может выделить ему отдельную страницу памяти. Обмен данными между страницами через ПДП. Прсто на чтение одна страница выбирается, а на запись другая. Ну и естественно, не все 64к из страницы могут быть использованы. Часть может быть перекрыта ПЗУ или, например, служить видеобуфером. Я, правда, не знаю, как эта схема согласуется с возможностями самой cp/m, какие там механизмы были предусмотрены. Но мне чисто логически этот путь кажется самым простым. Не столько в смысле аппаратной реализации, сколько именно в адаптации к самой cp/m.
TomaTLAB
19.06.2017, 01:24
Описание Фахрутдинов, Бочаров АРХИТЕКТУРА И УСТРОЙСТВА МИКРОКОМПЬЮТЕРОВ СТАНДАРТА MSX-2 (https://yadi.sk/i/FAMMk9QC3KEyYF) со стр.17
Вот здесь (http://zx-pk.ru/threads/26575-msx-main-ram-up-to-4mb-dlya-kuvt-1-kuvt-2.html) обсуждение платы памяти на 4МБ
Еще одна схема (https://yadi.sk/i/dGI6Iayf3KEyYP)
В общем, все просто до безобразия. Позволяет воткнуть любой из 256 кусков по 16кБ (4МБ) в любое из четырех окон в 64кБ адресном пространстве.
А вообще в MSX систему можно воткнуть при желании чуть менее 64 мегабайт памяти! :) (~ 56 т.к. пару слотов системный ливер занимает)
Я сначала не сразу разобрался как это все работает, потом когда дошло - несколько прифигел и проникся :)
TomaTLAB
19.06.2017, 09:39
СР/М на MSX, вроде как, особого распространения не получила, т.к. там есть вполне годная MSX-DOS от мелкомягких. Хотя в ученических машинках КУВТ MSX2 (YIS503IIIR) CP/M была прошита в ПЗУ. Причем с поддержкой сетевых функций.
И она при запуске с удовольствием отъедала всю доп. память под RAM-диск. Правда более 2МБ, кажется, уже давилась.
http://geoffg.net/terminal.html для желающих иметь терминал для VGA и PS/2. Вот только о кириллице забудьте или патчите прошивку. А у меня просто руки не доходят добить кодировку в своей поделке, http://www.qsl.net/rw6hrm/html/8bitdisp.htm . Базовую кодировку доделал, на болд и двойной ширины ну чтот никак...
Полноценной графики не будет, ибо не нужна.
Проблема переделки любого компьютера на VGA, оказывается совсем не проблема, если сам компьютер тянет двойной такт, т.е допускает замену кварца на удвоенный. Я узнал это потому, что на досуге люблю почитать немецкоязычные сайты аналогичные этому (а также немецкие журналы из середины 80-х).
Так вот оказалось, что для перевода на VGA ГДР-овских самоделок из 1984 года (с текстовым адаптером) достаточно заменить кварц 8 МГЦ на 16 и ещё что-то сделать с формирователями ССИ и КСИ. И всё. Делается за пару минут. Видимо, современные VGA не требуют точного соблюдения стандарта, т.е 31.5 КГЦ частоты строк и 70 ГЦ частоты кадров. Достаточно, чтобы частота строк была достаточно высока, чтобы попасть в полосу захвата, а далее всё в multi-sync VGA подстраивается автоматичеки.
Когда-то у меня один ОРИОН долго работал с кварцем 14.318 МГЦ (тянул и 15 МГЦ). В ближайшее время попробую этот трюк на своём ОРИОНЕ, вдруг получится. Обычно кварц до 12 МГЦ тянет любой ОРИОН, а вот чтобы "выжать" больше, надо потрудиться.
Важно, что данный трюк получится на РК86, особенно если ОЗУ на статике. Потому что в РК86 можно тактировать ВГ75 и CPU разными тактами. Не пролема и одним тактом, если Z80. Да и КР580 допускает оверклок. У меня ядро РК86 (без D14 и периферии) работало при кварце 30 МГЦ (вместо 16). ВГ75 я не тактировал выше 10 МГЦ, но судя по чужим проектам он тянет намного более высокие частоты.
Кто-нибудь знает - ССИ и КСИ для VGA должны быть нулевыми импульсами или единичными ?
Полноценной графики не будет, ибо не нужна
Графика не нужна, а вот псевдографика обязательна.
Иначе придётся рисовать панели в нортонах символами '=', '-', '+' и '|', что выглядит ужасно. Да и в чисто текстовых программах псевдографика нужна чтобы рисовать таблицы в текстах. А в текстовом редакторе горизонтальные линии необходимы, чтобы отделять служебную строку (где указывается текущая строка, столбец и режим вставки/замены) от самого текста. Но главное, рамочки необходимы для программ с окнами, т.к по периметру открытого окна всегда рисуется двойная рамочка.
Иначе придётся рисовать панели в нортонах символами '=', '-', '+' и '|', что выглядит ужасно.
Зато стильно, по кулхакерски. ;)
http://i92.fastpic.ru/big/2017/0619/c8/95cd3142171b6a4430998f4d108743c8.gif
Графика не нужна, а вот псевдографика обязательна.
Эмм.... так вроде бы в любой нормальной восьмибитной кодировке псевдографика присутствует, начиная с B0, заканчивая DF. А про всяческие КОИ-7 давно позабыть надо.
http://searle.hostei.com/grant/MonitorKeyboard/VideoChars.jpg
Error404
20.06.2017, 00:24
если в планах есть работа с консолью ОС по rs232 да с позиционированием курсора (нортоны), то про псевдографику лучше сразу забыть и делать рамочки по кулхацкерски плюсиками, палочками и тп. Ибо отображать все это будет не собственная видеокарта, а хрен пойми какой заведомо неизвестный терминал, который ещё поподбираешь.
отображать все это будет не собственная видеокарта, а хрен пойми какой неизвестный терминал
С чего это вдруг топик стартер станет использовать "хрен пойми какой неизвестный терминал", к тому же не умеющий даже позиционировать курсор. Он что идиот и в качестве терминала будет подключать АЦПУ выпуска 1974 года, где действительно нельзя позиционировать курсор?
К СМ-1800 тоже подключался внешний терминал (дисплей с клавиатурой) связанный с ЭВМ по последовательному интерфейсу. И там прекрасно работал экранный редактор, хотя и без псевдографики (т.к кодировка была 7-ми битовая).
Какой бы ни был терминал, даже если в нём управляющие коды не совместимы с VT52 или VT100, в нём всё-равно должно быть позиционирование курсора. Разве Вы знаете хоть один терминал, где этого нет? А если в терминале кодировка 8-ми битовая, то кто мешает иметь псевдографику ?
Скорости передачи 2400 хватит для экранного редактора, хотя, естественно лучше стандартные 9600 бод. И совершенно не обязательно паять терминал на ПЛИС или ещё какой. В качестве терминала можно использовать любую 8-ми разрядку. А удобнее всего в качестве терминала использовать IBM PC. Там есть удобная клавиатура и красивый шрифт. Особенно удобно будет делать PRINT SCREEN.
Почитывая немецкие журналы середины 80-тых в журнале 'MC' натолкнулся на такую любительскую конструкцию. В IBM PC XT ставится плата с процессором 68000 (или Z80) и ОЗУ 64К на двух 62256. Для 68000 используется ДОС CP/M-68К. Клавиатура, экран и дисководы есть в PC (драйвером служит процессор IBM PC). Даже ПЗУ в системе нет. Процессор PC закачивает в ОЗУ программу и освобождает RESET.
К сожалению, в современные PC такое не сделать, а вот если сохранилась 386-тая, 486-тая или ранний ПЕНТИУМ с EISA-слотами (у которых шаг не мизерный, а 2.54 мм), то сделать такую конструкцию можно, получив полноценный CP/M-компьютер с мощной и удобной периферией.
К тому же такая плата может работать эмулятором любого компьютера, например ZX-Spectrum. Процессор IBM PC несколько раз в секунду может захватывать шину Z80, считывать экран и визуализировать его на VGA. По деталям такая конструкция втрое дешевле, чем отдельное МП-ядро с подключенным внешним терминалом и дисководом.
Мне понравилась не конструкция, а идея закачки программ. Суть такова. В плату 386SX33 устанавливаем платку с ВВ55 (у меня уже есть, сделал ещё в середине 90-тых для УФ-программатора). И с помощью длинной косы соединяем выходы ППА с РК86 (естественно не напрямую к шине, а через буфера АП6). Выдаём для КР580 сигнал HOLD или RESET (по нему выходы CPU в Z-состоянии). И далее имеем полный доступ к ОЗУ РК86. При статике проблем нет, но при РУ5-тых надо успеть загрузить программу за 2 МСЕК (этого хватает), т.к иначе динамическое ОЗУ разрушится.
По научному такая идея называется "внутрисхемный эмулятор" и реально использовалась для отладки микроконтроллеров с помощью ЭВМ. На таком же принципе устроены "эмуляторы ПЗУ", также служащие для целей отладки МК.
TomaTLAB
20.06.2017, 08:36
Кто-нибудь знает - ССИ и КСИ для VGA должны быть нулевыми импульсами или единичными ?
Вот только недавно кто-то писал, что большинству современных ЖК по барабану на "полярность" синхроимпульсов.
Стеклянные по ней определяли диапазоны частот разверток. На многих было слышно как релешки щелкают.
Если в теме появляется упоминание о РС/ХТ/386/Пентиумах, то смысла далее вести речь о СР/М-планах на отдельно взятой машинке нет. На писюках мы можем спроектировать машинку, сварганить ей прошивку и подготовить загружаемый софт. Всё. Машинка должна быть самодостаточной, со встроенным "терминалом" или внешним; максимум, что она может делать с писюком - это связываться по последовательному порту/USB для обмена данными/результатами работы. Использовать писюк в качестве терминала - аналогично прикручиванию трёхспального дивана к велосипеду. А что, это же удобнее, мягче и места больше (ака клавиатура удобная и принтскрин).
Подключить АТ/PS/2 клаву к восьмибитке, кстати, это всего три чипа 155-й серии, http://zx-pk.ru/threads/26406-podklyuchenie-at-klaviatury-k-8-bitkam.html
Говорить о совместимости СР/М-машин по носителям также уже не имеет смысла. Такие машины ныне делаются в единичных экземплярах, исключительно для себя, аналогичных машин не будет наблюдаться рядом в радиусе как минимум 500 км, для связи с писюком/внешним миром хватает стандартного последовательного порта/USB или преобразователя COM/Ethernet. Диск для машинки вообще может быть мёртво встроен в корпус, наиболее удобная для этого кмк CF-карта, поскольку дрова для работы с ней под Z80 уже есть и подключение к машинке простейшее. Костыли для работы СР/М с FATхх на SD/MMC замедлят работу машинки, да и дрова для прикручивания драйва, скажем, от Vinxru, что-то не попадались.
Интересным направлением может быть возможность подключения USB-драйвов к восьмибиткам, используя чип USB хоста CH375D, https://vk.com/doc-72949118_437014204 , но опять же, дров для СР/М для него пока никто не написал. Хотя есть дико интересный вариант - указанный чип может быть подключен как по параллельному интерфейсу, так и к UART'у. Так вот, если в схеме машинки есть уарт, то USB-драйв можно подключить через него, что даёт возможность повысить юзабельность машинок вплоть до 80-х годов изготовления.
И да, делать дополнительную машину, аналогичную по мощности, используя те же или аналогичные процессоры только для отображения и внешней загрузки - ну вот раньше был смысл делать интеллектуальные терминалы, бо иной элементной базы не было. Сейчас есть та же Атмега, на которой и терминал можно сделать, и внешний диск, если надо, всего один чип.
И последнее, раз было упомянуто USB - надо забыть о МАХ232 навсегда и похоронить его с почестями. Использовать вместо него только и исключительно конвертер COM-USB, не помню уж какая там PLххх с розеткой USB-B. Удобнее и проще.
Всё сказанное - чистое имхо, не более.
Error404
20.06.2017, 13:04
С чего это вдруг топик стартер станет использовать "хрен пойми какой неизвестный терминал", к тому же не умеющий даже позиционировать курсор. Он что идиот и в качестве терминала будет подключать АЦПУ выпуска 1974 года, где действительно нельзя позиционировать курсор?
он ни в коем случае ни это слово, просто пока тут об этом теоретизируют, я уже на практике набил шишек подбирая к Ориону где в CPM консоль RS-232 есть, терминалы с RS-232 + ASCII8bit + 80х25 + VT-52(позиционирование), причем чтобы это понятно было не четыре разных терминала, а один. Так вот, за разумное время (гуглил примерно дня три), мне не удалось найти такого терминального клиента для Windows или Linux (а понятно, что как минимум при начальной отладке это должен быть терминал для PC просто потому что это удобно). Как ни странно, из кучи разнообразия терминалок, где всегда не хватало то одного то другого, наиболее близким оказался стандартный Hyperterm от ВиндовсХР (в болеее новых Виндузах эти уроды его зачем-то выпилили из дистрибутива) - там хотя бы было RS-232 + ASCII + VT-52. К сожалению, экран там 80х24 и не настраивается. В итоге, из примерно десятка различных Орионовских CPM-овских "нортонов с рамочками" нормально не заработало ничего - всегда что-то да отобразится некорректно (хотя проги - чернобелый примитив через штатный CONOUT) и пришлось написать собственную минималистическую оболочку которая на Hyperterm отображалась нормально (да думаю где угодно на VT-52 т.к. использует от него самый минимум плюс некоторые коды отличающиеся в реализациях дублирует).
- - - Добавлено - - -
А, еще важна деталь: я ставил цель (чего и достиг), чтобы этот "нортон" корректно отображался не только по RS-232 сторонним драйвером/терминалом, но и в самой Орионовской CPM или в Ордос через Монитор-2 при выводе на телевизор (т.е. хотя и при работе через CONOUT, но через Монитор2 или клон драйвера 480С который как оказалось в части расширений далек от стандартов VT52). Вот тут его исходники (http://zx-pk.ru/threads/20546-vosstanovlenie-spetsialistov.html?p=581388&viewfull=1#post581388), там в файле screen.c есть таблица соответствия кодов VT-52 между Орионовским Монитором-2, Орионовским 480С, консолью эмулятора MyZ80 (в режиме VT-52) и правильными стандартными кодами VT-52. Из чего и был выведен минимум и некоторые "runtime" коррекции двойным выполнением одного и того же действия (чтобы код без настройки работал на разных терминалах). Тот командер хотя и делался для специфической цели - копирования между CP/M, FAT12/16/32 и Ордос, но в части GUI это готовый MC а-ля Linux (все порывался я его на Uzix портировать, но чего-то остыл): с оконными функциями и "подкладным" оконным буфером, квази-объектным программированием с иерархией и с обработкой по событиям (кто кодил под VCL Borland С-builder - оценит). И все это собирается нативным C-компилятором CP/M (HitechC v3.09).
- - - Добавлено - - -
Использовать писюк в качестве терминала - аналогично прикручиванию трёхспального дивана к велосипеду. А что, это же удобнее, мягче и места больше (ака клавиатура удобная и принтскрин).
Ну как бы оно во всем мире так и делается: к копеечному контроллеру по RS-232 ходят с ноута(PC) из терминалки. И не только к копеечному, а и к Hi-End серверам зачастую аналогично - по RS-232 с ноута из терминалки. И даже если на микрокомпе есть вывод на TV (не обязательно наши 8-битки, а например разные Orange/Raspberri-PI), запиливание туда ОС всегда начинается с PC в терминале по RS-232, и только на финальной стадии когда дистриб отлажен, "диван" становится ненужен. :) Просто это красиво и удобно (ноут есть у всех, а терминал DEC или Robotron c VT-52 - нет), потому и прижилось. Кроме того, удаленный доступ по RS-232 это еще и удобный концепт, которые буде он реализован, позволяет перейти на удаленный доступ поверх других сред, например используя разного вида локальные сети.
если в планах есть работа с консолью ОС по rs232 да с позиционированием курсора (нортоны), то про псевдографику лучше сразу забыть и делать рамочки по кулхацкерски плюсиками, палочками и тп. Ибо отображать все это будет не собственная видеокарта, а хрен пойми какой заведомо неизвестный терминал, который ещё поподбираешь.
Я бы предложил при написании подобных программ сразу предусмотреть возможность смены "шкурки". Чтобы и плюсики и рамочки можно было использовать. Кому что доступно и нравится.
За дня три мне не удалось найти подходящего терминального клиента для Windows или Linux (а понятно, что как минимум при начальной отладке это должен быть терминал для PC просто потому что это удобно)
Это другая история, речь же об реальном железном терминале, а не о эмуляторе терминала. А если всё-же в качестве терминала использовать PC или 8-ми разрядку, так легко написать простейший эмулятор VT52 с опорой на ROM-BIOS или загруженный драйвер. В котором, естественно, можно сделать всё так как надо. Не понимаю, зачем цепляться за терминальные программы для Windows или LINUX, они созданы для других целей. Что жалко потратить час труда, чтобы сделать эмулятор терминала по вкусу ?
Странно, что за три дня поисков не удалось найти железный проект терминала для CP/M удовлетворяющего требованиям. Ну а кто заставляет повторять чужие конструкции "один в один" без модификаций. Можно же взять примерно подходящую конструкцию и изменить её по потребностям. Вот тут как-раз ужасные "чёрные ящики", т.е конструкции на МК или ПЛИС, в которые изменения может вносить только разработчик, оказываются негодными. Для модернизаций удобны лишь нормальные радиолюбительские разработки на низкоинтегральных деталях, где всё ясно до последнего резистора и программа понятна и доступна для коррекций.
Я бы предложил при написании подобных программ сразу предусмотреть возможность смены "шкурки". Чтобы и плюсики и рамочки можно было использовать...
В книжках пишут, что CP/M использовали более 400 компьютеров, у каждого из которых были свои управляющие коды экрана и коды клавиш и, увы, большая часть программ работала по железу. Но те программы, что рассчитаны на универсальность имеют инсталляторы. Хороший пример - инсталлятор Турбо-Паскаля. Делая только для себя можно делать как угодно. Но если надо сделать корректную CP/M-программу, пригодную для любого железа, то можно сделать и инсталлятор.
Проще всего в начале кода вставить блок настройки, чтобы не делать инсталлятор. Когда-то у меня не было цветного монитора, отчего в программах цвета получались неверными. Тогда я стал в начале программ вставлять блок цветов. Каждый мог отладчиком меняя байты настроить нужные цвета.
Кстати, как насчёт цвета? Текстовые адаптеры в большинстве своём имеют цвет. Да и программы в цвете намного приятнее. А если уж и цвета нет, то инверсия знакомест в терминале должна быть обязательно.
ужасные "чёрные ящики", т.е конструкции на МК или ПЛИС, в которые изменения может вносить только разработчик
Плохо искали. Как минимум три конструкции с приложенными исходниками могу назвать сразу. А могу и не называть, поскольку активно использовал их для себя и ссылки на них есть в моих постах.
Кстати, как насчёт цвета?
Не надо. Это лишнее и не канонiчное. Не игровой же аппарат планируется, верно? Плюс лишнее усложнение видеовывода. Хотя решать делающему...
TomaTLAB
21.06.2017, 09:32
Вот тут как-раз ужасные "чёрные ящики", т.е конструкции на МК или ПЛИС...
Да нет в них ничего ужасного. МК ну ниразу не сложнее того же минимального компа на 8080 или Z80. Просто все, что нужно в один кристалл упаковано.
Прошивку для их, на мой взгляд, писать даже проще. По крайней мере, для 51-го и AVR. Нужно пересилить свой страх перед ними, просто взять и попробовать один раз. Уверяю, Вам понравится :)
Про ПЛИС я могу сказать то же самое. Там правда нужно несколько "мосх вывихнуть" т.к. HDL - это совсем другая парадигма. Это, грубо говоря, принципиальная схема, только "словами" описанная.
Немного отойду от темы. Меня иногда удивляет другое. Зачем сейчас все норовят взять МК помельче и потом героически пытаются туда "впихнуть невпихуемое"?
Ну ведь, как правило, все делается в единичных экземплярах, не миллионными же партиями, где каждая копейка себестоимости на счету.
Почему нельзя взять чип пожирнее на 100...200р дороже, оно что - погоду сделает? Или это такой спортивный мазохизм?
Можно ведь даже поставить в одно устройство два, три МК - пусть каждый свой кусок задачи выполняет.
OrionExt
21.06.2017, 18:10
Ретро терминалов на современной элементной базе в инете валом. За микроконтроллеры не скажу, а вот на FPGA любой терминал можно допилить под свой вкус и цвет за пару вечеров (неделю). Если серьезно не потрошить исходный код (а это и не потребуется), то допиливание под себя не потребует супер знаний в области FPGA (как Бейсик).
Да что тут говорить собрал вот эту штуку (http://searle.hostei.com/grant/Multicomp/index.html) за неделю с нулевыми знаниями по теме. Вот мой вариант (http://zx-pk.ru/threads/12701-orion-2010-na-plis.html?p=888594&viewfull=1#post888594).
Погонял недельку, разогнал Z80 до 50 МГц (и терминал встроенный). Прикольно, все просто летало. Но, не зашло.
Потом решил сделать на девборде Орион, не потянул (тут задача требовала более глубокое погружение в тему). А может слишком высокую планку себе поставил, хотел сразу всего и побольше:)
- - - Добавлено - - -
А мы о терминалах. Берем оттуда исходники терминала, и выкидываем наружу три сигнала /CS, /RD и /WR. Достаточно просто платки с FPGA (встроенная память в чип). На какой скорости CPU с этим добром общаться, думаю вопросов не возникнет.
Прошивку для МК, на мой взгляд, писать даже проще. По крайней мере, для 51-го... Нужно пересилить свой страх перед ними, просто взять и попробовать
Дело не в страхе, а в принципах. Также в лени и отсутствии желания утомлять мозг. Надо прочитать море литературы, разобраться в куче программ, приобрести груду аппаратной оснастки и т.п. Читать и разбираться нет желания, как в анекдоте - "чукча - не читатель, чукча - писатель". Это интересно лишь аппаратчикам. С МК 8048 я имел дело в начале 90-х. Не впечатлило, Z80 намного удобнее.
Как я понял, топик стартер собирается делать терминал на ВГ75. Глупо использовать 7-ми битовый кристалл и надрываться в попытках улучшить его свойства нетрадиционной схемой. Результат - громоздкость, неудобство подключения, программирования и убогие возможности.
Значительно бОльшие возможности даёт графический дисплейный процессор 1809ВГ4 (NEC 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220)). Даёт графический и текстовый терминал одновременно. Включается как порт, не занимая основное ОЗУ под экран и не требуя никаких диспетчеров памяти. Стоит 300 руб на барахолке этого сайта. Их производство было налажено также в ГДР - применили в BIC (Bildungs computer) и PC клоне EC-1834.
У нас их "разработали" в 1987 (РТМ в ж.МПСС) и выпускали с 1989 (завод "Светлана", Ленинград), но в компьютерах применить не успели. Неудобство в том, что экранная память 16-ти разрядная (надо ставить две 6264 и, соответственно, на видео выход два регистра ИР24). В середине 80-тых выпускалась видеокарта для PC на 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220), но успеха не имела. Работу графического процессора в МК или ПЛИС не с'эмулировать.
Простой граф.адаптер на 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220) с дампом CP/M-BIOS описан здесь: M.Kramer, K.Thielecke: Der Sprung zum PC: Floppy-Laufwerk und hochauflosende Grafik am Z1013. Teil 2. Funkamateur, Heft 8, 1990, Seite 381. Найти можно здесь (http://mail.apparaturnaya.ru/jurnal/jurnal_elektronika/143168-funkamateur-8-1990-zhurnal-besplatno.html) и тут (http://fr-lib.ru/magazines/elektronika/funkamateur-8-1990-download753424)
Это плата расширения для компьютера (аналога РК86) Z1013 (http://hc-ddr.hucki.net/wiki/doku.php/z1013) (подробнее тут (https://www.google.ru/search?client=opera&rls=ru&q=z1013&sourceid=opera&ie=utf-8&oe=utf-8&channel=suggest&gws_rd=ssl)). Плата даёт графику 640*200 (тестовый вывод 80*25 программно).
Адаптер на 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220) промышленно выпускался для другого бытового текстового компьютера из ГДР Z9001 (см.фото). Он даёт лишь текст 80*25 и псевдо графику 256*256 (ОЗУ всего 2К). Последующие любительские доработки этой платки ввели графику и цвет.
Кстати, аналог РК86 - текстовый компьютер Z1013.16 (см.фото) на советских 565РУ3 выпускался с 1985 года (с 1984 выпускался Z1013 с 2 кб ОЗУ, с конца 1986 вариант Z1013.64 уже на РУ5). Он сделан гораздо умнее, чем идиотский РК86 с его ВГ75 и ВТ57. Всего на 6 дешёвых TTL-микросхем больше и никаких дефицитных БИС-ов. Догадайтесь, что было бы дешевле и доступней для повторения. И догадайтесь, где порты не стоят посередине адресного пространства, мешая расширять ОЗУ. Обидно, что братья по соц.лагерю не поделились разработками с авторами РК86. Кстати, по цене (набор для сборки, всё кроме корпуса) был доступен, стоил всего половину средней зарплаты.
Вот такой компьютер и нужен для использования CP/M. Текстовый экран с размером всего в 2 кб прямо в адресном пространстве удобнее для программирования, чем тормозной внешний терминал на RS232. Работу с таким экраном поддерживают даже ЯВУ CP/M.
OrionExt
21.06.2017, 18:59
Вот такой компьютер и нужен для использования CP/M. Текстовый экран с размером всего в 2 кб прямо в адресном пространстве удобнее для программирования, чем тормозной внешний терминал на RS232. Работу с таким экраном поддерживают даже ЯВУ CP/M.
Можно и такой. FPGA вариант не далеко- ушел (правда там VT100 на уровне железки). По времени – одинаково делать.
А RS232 с чего тормозной? 8-битки уже умеют работать на скорости выше 2кбод=)
Error404
21.06.2017, 19:47
Я бы предложил при написании подобных программ сразу предусмотреть возможность смены "шкурки". Чтобы и плюсики и рамочки можно было использовать. Кому что доступно и нравится.
Забавно как сходятся мысли - я там так и делал. Была определена табличка с элементами псевдографики для окон (прямые, уголки, пересечения), и просто заменив эту таблицу можно было из моих плюсиков и палочек получить слитные рамки (если бы вдруг нашелся терминал их отрисовывающий).
- - - Добавлено - - -
Это другая история, речь же об реальном железном терминале, а не о эмуляторе терминала. А если всё-же в качестве терминала использовать PC или 8-ми разрядку, так легко написать простейший эмулятор VT52 с опорой на ROM-BIOS или загруженный драйвер. В котором, естественно, можно сделать всё так как надо. Не понимаю, зачем цепляться за терминальные программы для Windows или LINUX, они созданы для других целей. Что жалко потратить час труда, чтобы сделать эмулятор терминала по вкусу ?
Я конечно понимаю, что час труда - это фирменная фигура речи. Там будет не час труда даже если просто сделать маппер вывода символов для текстового режима. А уж для нормального оконного приложения (даже не консольника - кому они интересны? putty не переплюнешь, а оно далеко не самое удобное), с возможностью выбора шрифтов и кодировок, экранным буфером (смотреть что там "уехало за экран" - без этого никакой эмулятор терминала в принципе не интересен, т.к. CPM2.2 не умеет перенаправлять вывод в файл, а значит многостраничный высер ошибок компилятора АСМ или С придется лихорадочно ловить по ^S) - все это готовые терминалы имеют из коробки, на все это уйдет куда больше трех дней (и даже трех недель) если как у любого работающего на основной работе человека, есть максимум по паре часов в день для хобби (да и то в моменты творческого угара).
- - - Добавлено - - -
Можно и такой. FPGA вариант не далеко- ушел (правда там VT100 на уровне железки). По времени – одинаково делать.
А RS232 с чего тормозной? 8-битки уже умеют работать на скорости выше 2кбод=)
Сервера IBM Power (лидер по выч. можности в бизнес-сегменте, 1024 ядра по ~3..4Ггц) до сих пор штатную RS-232 консоль имеют на 19200 (это крайние 10лет), а до того 30 лет прекрасно жили на 9600. И ничо, всем хватает (VT100 и xterm).
OrionExt
21.06.2017, 20:24
..., т.к. CPM2.2 не умеет перенаправлять вывод в файл, а значит..
Ух. Ни фега себе. Это правда?)
Сервера IBM Power (лидер по выч. можности в бизнес-сегменте, 1024 ядра по ~3..4Ггц) до сих пор штатную RS-232 консоль имеют на 19200 (это крайние 10лет), а до того 30 лет прекрасно жили на 9600. И ничо, всем хватает (VT100 и xterm).
Начитались тут журналов 80г. ближе к земле – товарищи.
Вы чего-то путаете. И я сказал, что адекватная скорость на частоте допустим 2,5 Мгц CPU с терминалом более чем возможна.
- - - Добавлено - - -
Error404, я понял Cи не умеет в файл писать ошибки?) Так?
- - - Добавлено - - -
Кстати hitech с я плотно пытался разобрать. main там на чистом Си, можно и пропатчить) Если интересно?
TomaTLAB
21.06.2017, 20:38
С МК 8048 я имел дело в начале 90-х. Не впечатлило, Z80 намного удобнее. Аааа... :v2_ohmy: тогда все ясно. Не с того боку зашли, это пожалуй наихудший МК для первого ознакомления, действительно может вызвать стойкое отвращение. :v2_sick:
Работу графического процессора в МК или ПЛИС не с'эмулировать. Да ладно...
Значительно бОльшие возможности даёт графический дисплейный процессор 1809ВГ4 (NEC 7220)
А VGA он потащит?
OrionExt
21.06.2017, 21:59
По мне забудте о ВГА на 8-битах. 555 не тащат 28Мгц=) И 20 не тащат. Сколько не читал (не тут, тут фантазеров хватает) 10 Мгц – это финал. Это касается только +5В, и всяких штук с 80г. А это львиная доля всего (форума).
- - - Добавлено - - -
Вот зачем вам ВГА – умерло для меня 15 лет назад (HDIM пришло на смену). А SCART – жив.
Я понимаю, что "час труда" - это фигура речи... на все это уйдет куда больше трех дней (и даже трех недель)
Нет, я имел ввиду буквально. На самом деле часа слишком много, достаточно нескольких минут. Но видимо, мы имеем ввиду разные вещи. Итак, сколько же времени надо, чтобы написать эмулятор VT52? Один час или "куда больше трёх недель".
Речь о том, чтобы на 8-ми разрядном компьютере или на PC обеспечить визуализацию символов поступающих из линии. Вопросы связанные с линией передачи не рассматриваем. Итак, есть скоростное ядро Z80B на такте 8 МГЦ с ОЗУ 62 кб на w24512 и ПЗУ РФ2 (там только BOOT), выдающее символы в линию. Какая же программа мне нужна когда в качестве терминала я хочу использовать ОРИОН-128 (процессор Z80, реальный такт 4 МГЦ, экран 384*256, кстати не плющенный).
Для получения терминала VT52 я загружаю в ОЗУ ОРИОНА драйвер, например, D6$, который работает в банке 0, грузится на векторы ПЗУ F800, даёт 64 символа в строке на 25 или 32 строки и обслуживает все основные управляющие коды VT52 (кстати, в том числе и вставка и удаление строки, т.е ролики вверх-вниз, что ускоряет работу редактора SuperText и Турбо-Паскаля). Дополнительно драйвер обслуживает управляющие коды для работы с окнами, в частности, открытие цветного окна, закрытие окна и вывод рамки окна с заголовком и без, и, естественно, поддерживает цвет.
Такой драйвер резко упрощает создание оконных программ. Так что всё что остаётся мне сделать, это написать программу, которая в цикле ждёт очередного символа с линии, после чего делает CALL F809. Итого, если считать, что приём с линии тут не рассматривается, то вся программа состоит лишь из одной команды Z80. Вопрос на засыпку, сколько времени мне надо чтобы набрать в текстовом редакторе одну строку и странслировать ?
Теперь расмотрим вариант, когда в качестве терминала я вдруг захочу использовать IBM PC. У меня есть рабочая 386-тая и 486-тая. Есть и несколько неиспользуемых VGA дисплеев. Т.е надо написать программу в MSDOS или в древних LINUX (например REDHAT 5.0 из 1998). Для MSDOS ещё с середины 90-тых у меня есть мой цветной драйвер 64 символа в строке для VGA для всех режимов до 16*640*480 (а вот SVGA режимов, т.е 800*600 и выше - уже нет). В нём обрабатываются основные упр.коды VT52. Итого, ситуация аналогичная - вся программа это одна команда CALL CONOUT.
А вот для LINUX придётся писать программку на Турбо-Паскале. Удобно написать и отладить именно на Турбо Паскале в MSDOS (Windows), а после отладки уже странслировать LINUX транслятором Паскаля, который совместим с Турбо-Паскалем (но не имеет IDE, поэтому отлаживать удобнее в Турбо-Паскале). Что так трудно написать на ЯВУ программу, которая выводит символ в текущую позицию экрана 80*25 (для позиционирования есть оператор GOTOXY)? Можно управлять и цветом. Т.к управляющих кодов VT52 довольно много, поэтому я и указал, что на разработку может уйти целый час. А если вдруг "приспичит" использовать в качестве терминала более современную IBM PC, где Windows изуродована до того, что уже не может запускать программы MSDOS, то кто мешает взять Турбо Паскаль для Windows или Delphi и странслировать эту же программу в консольное приложение.
возможностью выбора шрифтов и кодировок, экранным буфером (смотреть что там "уехало за экран" - без этого никакой эмулятор терминала в принципе не интересен, т.к. CP/M не умеет перенаправлять вывод в файл, а значит многостраничный вывод ошибок компилятора ASM или С придется лихорадочно ловить по ^S)
Что за ерунда ? Даже примитивный ASM.COM Digital Research 1977 года создаёт PRN-файл, где отмечены ошибки трансляции. Это только в UNIX ошибки идут в отдельный канал. А что это за дурное СИ, если оно так неудобно. Бесконечный экранный буфер с возможностью прокрутки, это не из CP/M. Вы хотите, чтобы в Вашем терминале были возможности, которых в CP/M отродясь не было и не будет. Да и как можно в ДОС в которой всего 64К тратить ОЗУ на подобную ерунду? Если даже функцию 10 (ввод строки) за 40 лет не удосужились доработать, чтобы был тимплет символов (т.е память на ранее введённые строки) и удобное редактирование, рассчитанное уже на экран, а не на АЦПУ. Получается, что Вы сами себе придумали проблему, отчего пришлось изуродовать свои программы плюсиками вместо нормальной псевдографики и цвета.
Кстати, не понимаю зачем терминалу надо совмещаться лишь по управляющим кодам с М-2 ОРИОНА, где обслуживается всего лишь несколько управляющих кодов от VT52. У Вас же нормальная CP/M, а не CP/M ОРИОНА из 1990 года, где нет драйвера, а весь CP/M-вывод переадресован напрямую на п/п-мму F809 ПЗУ ОРИОНА.
TomaTLAB
21.06.2017, 22:50
Ну свет на них клином... LS - самая тормозная серия (после 133/155).
Нифигасе умерло... из каждого телека и монитора торчит. А вот SCART (причем настоящий RGB, а не огрызок) поди поищи еще.
И VGA2HDMI конвертеров как говна за баней по три копейки за пучок.
графический дисплейный процессор 1809ВГ4 (NEC 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220))
А VGA он потащит?
Вопрос д.быть таким: будет ли достаточная для VGA частота строк при желаемом числе точек в строке. Ведь можно получить VGA при низком пиксель клоке и всего 256 точках в строке, но кому это надо. В монохроме хватит (т.к зараз читается 16 бит), а вот в цвете с трудом. Готовую схему для VGA найти не удастся, т.к БИС была в моде, когда VGA еще не было. Но скорее всего достаточно в схеме для CGA просто поднять такт покуда тянет и получится VGA.
GDC выпускаются на такт 2.5, 5, 6, 7 и 8 МГЦ. Но это не пиксель клок, а такт процессора. Связь между пиксель клоком, тактом GDC и частотой обращения к ОЗУ зависит от схемы. У меня 2 схемы моно адаптеров с GDC и ещё 2 словесных описания цветных схем. В схемотехнике я не разбирался, т.к рассчитывал лишь тупо повторить готовую конструкцию. В одной цветной конструкции пиксель клок 10 МГЦ (416 точек) частота обращения к ОЗУ в 8 раз меньше - 1.25 МГЦ. А в монохроме частота ОЗУ д.быть в 16 раз ниже пиксель клока. В [Литературе] описан GDC 1984 года с пиксель клоком в 20 МГЦ. Это почти VGA, т.к в РК86 с выводом на VGA по схеме Alex_LG стоит кварц 24 МГЦ.
Это не не проста шалабушка без мозгов типа ВГ75, 1809ВГ3, 6845 или V9938, что только и умеет отображать. А это процессор, он не только отображает, но и выполняет команды (попиксельное панорамирование во все 8 сторон, ZOOM, масштабирование, рисование линий, квадратов, кругов, эллипсов, работа с окнами и т.п). Но программирование очень сложное. На немецких форумах ругались, что ИНФО из даташита недостаточно. Похоже, никто и не использовал процессорные возможности GDC в радиолюбительских машинах, кроме как для обычного вывода текста и вывода статических картинок.
Кстати, и одна 7220 (https://en.wikipedia.org/wiki/NEC_µPD7220) может работать с цветом. В журнале RFE 04/1988 и 04.1989 описаны цветные адаптеры GDC-1 и GDC-2 (2 банки РУ7, 4 плоскости), предназначенные для любой 8/16-ти разрядной ЭВМ. Эта БИС рассчитана для работы с графикой на машинах невысокого класса (первой половины 80-тых), для пакетов деловой графики (конструкторская документация, чертежи, принципиальные схемы, разводка печ.плат), но когда появились 386-тые и SVGA у которых мощности и плоскостей намного больше, то БИС стала не нужна. А для игр эта штука не подходит. Использовать её для вывода текста удобно, т.к деталей мало, но по сути это как из пушки по воробьям. Скорость вывода текста даже в графике быстрая, т.к можно использовать команду OTIR или DMA в РК86. Для вывода символов используется просто пересылка блоков.
Возможно, можно ещё больше упростить схему из FA 08/1990, использовав экранное ОЗУ на 8 бит (выбросив одну 62256 и один регистр ИР24). Хотя понадобится скоростная GDC (у меня как раз есть скоростная), т.к при том же такте получится экран только 320*200.
У меня есть русскоязычный ДОК на 1809ВГ4 (~100 листов), но я не собираюсь её программировать и разрабатывать для неё программы для работы с конструкторскими чертежами или принципиальными схемами. Достаточно дизассемблировать чужой BIOS, что поддерживает текст 80*25 и адаптировать это для своей ДОС.
[Литература]
Electronic Design, New York. 07/1984, Seite 135.
H.Assarpour. Graphic controller chip raises video data rate, is simpler to program.
'MC', Muenchen. 04/1985, Seite 136.
F.Oettle, T.Reichler. Die mc-Farbgrafik-Karte.
Radio Fernsehen Elektronk, Berlin. 04/1988, Seite 253.
T.Wolf, M.Fisher. Farbgrafikmodul mit Grafik-Display-Controller U 82720.
Microprocessors and Microsystems, GuildFord. Volume 8, Issue 6, July–August 1984, Pages 284-289
S.Manohar, N.Murali, L.Patnaik. Design of a Multibus-compatible colour graphics subsystem.
Купить даже не журнал, а лишь PDF-файл статьи за $35.95 (http://www.sciencedirect.com/science/article/pii/0141933184901807)
barsik, малое разрешение не подходит. В текстовом режиме 640х200 минимум. Ну и самое главное, 7220 труднодоступна и из-за этого дорога, а ВГ75 продаются на вес.
...в общем, тема ушла к обсуждению вторичной периферии, а о самом СР/М- компьютере ни слова...
rw6hrm, а что еще можно обсуждать? Периферия - это как раз то, что обслуживает ОС. Предложите, на что еще следует обратить внимание.
Ещё раз хочу пояснить суть темы: обеспечить максимальную совместимость с cp/m. Чтобы не пришлось потом мучиться, как с РК, например.
P.S. Проект сейчас развивается. Собираю отдельные узлы на макетных платах. Раньше работ такого уровня сложности делать не приходилось. Да и то, что делал, было ..дцать лет назад. Сейчас нахожу спустя годы некоторые свои поделки, и удивляюсь: неужели это мое? Так что мелкими шажками...
Пока что собрал узел на вм80а + гф24 + вк38 + ру10 + 2764 + мелочевка. Далее подключу вв51 и нужно будет что-то прошивать в ПЗУшку...
Не будем забывать, что ОС СР/М обслуживает себя через биос, который пишется для каждой отдельно взятой машинки в соответствии с применённым железом. Однозначно, все вопросы по периферии необходимо решать в свете подключения оной как устройств ввода/вывода. Мапировать периферию на общее поле памяти полный отстой (почему не стоит брать "Специалист" за базовую схему, к примеру). Далее, периферия не должна занимать ресурсов основного процессора и, соответственно, не отсвечивать в биосе. Иначе говоря, она должна "эмулировать терминал" - машинка выкинула байт в порт, далее этим байтом самостоятельно занимается периферия, и наоборот. Иначе мы получаем тормозную машинку, которая только и делает, что обслуживает периферию, а на собственно работу времени остаётся с гулькин нос. Поэтому считаю, что периферия вторична и заслуживает отдельного обсуждения по каждой железке. А как она будет подключена - по параллельной шине или последовательной - не важно. Главное - "стандартное", с точки зрения ОС, подключение к базовой системе. Расписали порты, что к чему подключать, и придерживаемся этого.
Что интересно лично мне, и в чём я до сих пор не разобрался - страничная адресация памяти. В идеале базовый вариант машинки должен содержать 64К ОЗУ с отключаемым загрузочным ПЗУ, вся память отдаётся ОС. Экран, как упомянуто ранее, должен сидеть в области адресации УВВ и иметь собственную память, не пересекающуюся с основным ОЗУ (как бы нам не хотелось сократить кол-во чипов). Далее, если юзверь вырос технически и организационно, он может добавить себе основного ОЗУ со своим управляющим блоком. Программно это уже должно быть стандартизировано в средствах ОС (вот только где, и какие базовые адреса под это зарезервированы в стандартной СР/М? Просветите плз). Причём надо предусмотреть различные варианты такого расширения - кто-то тащится от кучи РУ3/5/7, которых, как раз и просто "страничить", а у кого-то ( у меня, к примеру) есть куча статических ОЗУ по 32/64К каждая (из кэшей 486-х машин). Значит схема управления страницами должна быть разная, но одинаково выглядящая для софта.
Продолжаем разговор. В ТЗ до сих пор не определено, какой должна быть машинка, её базовый вариант и возможности расширения. По какой шине это должно быть соединено. ТЗ разрабатывается для одноплатной системы или многоплатной... Если для многоплатной, то всё уже сделано до нас - шина S-100 (http://www.s100computers.com/)и полностью развязанные руки, максимальная совместимость, дело только за низкоуровневым софтом. Если одноплатный вариант, то обсуждать что-то канонiчное невозможно, каждый исходит из наличия комплектухи (см. разговор про м/с ОЗУ выше или Ваше, Xrust, сообщение). Для одноплатного варианта более чем подходит разработка Гранта Сирла, следует только заменить двойной SIO на удобоваримый ВВ51, хотя бы на один. Второй порт сделать параллельным как раз на дисплей/клаву, но программно он должен работать как терминал (выше описано). Кого припрёт - поставит шинные буферы. У кого есть время и возможности - сделает динамическое ОЗУ (подключаемое как статическое или отдельной платой в шину).
...а вы говорите - не на что обратить внимание...
По мне забудте о ВГА на 8-битах. 555 не тащат 28Мгц=) И 20 не тащат.
27МГц там только регистр сдвига должен тащить, КМК.
- - - Добавлено - - -
Иначе мы получаем тормозную машинку, которая только и делает, что обслуживает периферию, а на собственно работу времени остаётся с гулькин нос.
А чем она, собственно, должна заниматься? Это же всё-таки ПК, как ни крути. А его основная задача - обслуживание периферии, опять-таки.
TomaTLAB
22.06.2017, 10:57
27МГц там только регистр сдвига должен тащить, КМК.
Ну плюс еще один каскад делителя для получения частотной сетки и осциллятор (если готовый не брать).
Итого 2...3 корпуса скоростных. Остальное будет работать максимум с половиной пиксельклока. Т.е. даже тормозная 555(LS) должна справится.
Даже гф24 такую частоту тянет штатно.
OrionExt
23.06.2017, 14:57
Нифигасе умерло... из каждого телека и монитора торчит. А вот SCART (причем настоящий RGB, а не огрызок) поди поищи еще.
Уже не торчит VGA в новых. Если еще что-то торчит - SCART значит не все потеряно.
Решил я новый телик (ЛСД, все дела. 22 дюйма) купленный 15 лет назад подключить к компу через VGA. Но не огрызком кабеля, а 5 метровым. И что я увидел. И был поставлен крест на VGA. А кабелек этот VGA порезал на SCART (уже в наше время) – качество супер.
Ладно, ладно я палку перегнул. На 555 строили первые ВГА терминалы. А то, как бы оно работало (без S, AS).
Но отойду от ВГА, и вернусь к сериям микросхем. Для ретро компьютера СР/М.
По мне так 155 серия самая адекватная (хотя жрет дофига). А 555 со странностями своими. Новая КМОС пришла на смену. Вот за нее и надо держаться (если это возможно).
61447
Вот что имею на сегодня. Сверху панелька под ру10, в середине под ПЗУ, справа под вв51. Попробую поработать с асинхронным портом. Еще осталось делитель частоты распаять.
OrionExt
23.06.2017, 15:28
Ого, свершилось. Это интересней в разы чем ВГА терминал косточки мыть).
Даже ГФ24 частоту 27 МГЦ тянет штатно
Это не так. Я испытывал десяток ГФ24, пытясь разогнать РК86. По "штатной" схеме выше 20 МГЦ не заводятся. Но оказалось, что если последовательно с кварцем включить мизерную емкость, всего в 3...5 пф, то без проблем работают даже с кварцем 32 МГЦ.
Вот что имею на сегодня
По тусклому фото вижу, что Вы фатально ошиблись. С КР580 Вы же не сможете использовать CP/M 3.0, т.к она требует Z80. С КР580 работает только CP/M 2.2, а значит не удастся поиметь имён для подкаталогов, даты файлов и MSDOS-подобие, что даёт ZCPR. А ещё более печально с КР580, что его не разогнать выше 3.5 МГЦ. Для текстового адаптера это достаточно, но если захочется подключить графический адаптер, то будет тормоз. Минимально комфортный такт это 4 МГЦ и более.
Если так необходима совместимость с КР580, то разумно применять 8085, а ещё лучше V20. V20 менее дефицитен, чем 8085, более скоростной и кроме КР580 даёт и 8088. Они выпускались в модификации 5 МГЦ и 10 МГЦ, причём 10-ти мегагерцовые более распространены, т.к применялись во второй половине 80-тых для апгрейда PC XT, без хлопот ускоряя прогон программ на XT в 2.6 раза. Стоят 300 рублей или ~5 USD.
Кстати, если уж речь о CP/M, то есть её версии на CPU 6502 и 68008. Поэтому разумно поставить на плату разъём (можно от винчестера) вместо панельки для КР580. Можно иметь на плате Z80 или КР580 (но без ВК28) на панельке, но предусмотреть отдельный разъём для замены CPU, причём одновременно этот разъём может служить и для подключения периферии.
фатально ошиблись
Да ладно пессимизм разводить... Для попробовать вполне достаточно, и на 1,7МГц. Особого ничего в 3.0 нет полезного, разве что работы с метками времени, остальное баловство. Графических программ чтот маловато попадалось, поэтому обращать на них внимания не стоит. Версия 2.2 самое то, все равно для какого процессора.
Однако минус в применении ВМ80 есть, поскольку большинство реально нужных и продвинутых программ писаны под Z80, в том числе и дрова под различную периферию, в том числе и современную. Поэтому свой проект СР/М машинки на базе ВМ80 я благополучно похоронил.
А вот про
предусмотреть отдельный разъём для
отвечу так: S-100, S-100 и еще раз S-100. Причем не менять процессоры, а менять процессорные платы (обвязка-то различная).
то есть её версии на CPU 6502
А вот про это подробнее плз. Платы на 6502 встречались только как slave в многопроцессорной конструкции, не более, напрямую в СР/М не поддержаные. Можно в личку ссылку кинуть, чтоб тут не расписывать.
А вот про это подробнее, please
Я тут последние 3 недели "шарился" по немецким сайтам для любителей рэтро-компьютеров с архивами. Скачал ~90 мб сжатых ZIP-архивов. Конечно большая часть - это полные дубли того, что лежит на англоязычных сайтах. Но зато документация по CP/M и ЯВУ переведена на немецкий, а для меня это как на русском (английский я знаю, читал на нём даже классиков XIX века, чего не могут сами англичане, но ненавижу английский, т.к не чувствую комфорта при чтении, также как и на французском). Но скачал и небольшое число пакетов, что отсутствуют на англоязычных сайтах, сделанные немецкими любителями программирования в 80-тые годы. Интерес представляют лишь некоторые компиляторы СИ, бейсика и ассемблера и несколько самодельных DOS. В частности, скачал какой-то архив CP/M 3.0 переделанной кем-то в начале 80-тых так, чтобы работало на КР580. Но пока не разбирался с этим.
Про CP/M на 6502. Понятно, что CP/M на 6502, даже если её переписать на 6502, работать не сможет, просто потому что не хватит регистров CPU в которых передаются параметры (нужны 16-ти разрядные регистры, а в 6502 таких нет). Но где-то прочитал описание какой-то ДОС для 6502 в которой формат файлов на диске сделан совместимым с CP/M, отчего возможен прямой обмен. Увы, это я не скачал и не запомнил на каком сайте видел. Я примерно представляю где искать, т.е на каких сайтах я это видел, так что попробую в ближайшие дни найти что-нибудь на эту тему.
Насчёт того, что функции там совпадают или близки к CP/M, - не знаю. Но это и не важно, т.к всё-равно программы для КР580 на 6502 не работают и конвертировать сложно, даже имея исходник, просто потому, что внутри 6502 слишком мало регистров (именно поэтому в 1976 он стоил $28, в то время как КР580 стоил $400). Благодаря своей дешевизне 6502 и отвоевал существенный кусок рынка бытовых компьютеров у КР580 и Z80. Сам 6502 меня интересует, а вот CP/M для 6502 нет, это бессмысленно. Т.к для CP/M-6502 просто нет программ.
Зато существует море программ для Apple-DOS 3.3 (в книгах пишут, что для Apple-II есть 20.000 программ, но это рекламное враньё, думаю, как минимум, на порядок меньше). Естественно, интересуют только компиляторы макроассемблера (например BIG MAC, LISA), паскаля и бейсика. Они не работают по "железу", отчего их смогли заимствовать для других компьютеров на 6502. Потому в машину на 6502 надо ставить ДОС для 6502, а не для КР580. Впрочем даже это не надо, интереснее написать свою ДОС для 6502 (и это отнюдь не сложнее, чем адаптировать чужое). Ассемблер для 6502 не проблема, в качестве ЯВУ можно использользовать кросс-платформенный Hisoft-C, а с другими ЯВУ для 6502 - облом.
По тусклому фото вижу, что Вы фатально ошиблись.
Вы наверное по диагонали мои сообщения читаете. Я же писал (http://zx-pk.ru/threads/27613-kompyuter-dlya-cp-m-formulirovka-tz.html?p=917302&viewfull=1#post917302), что это макетка просто чтобы руку набить. Я не имел опыта построения микропроцессорных систем ранее. На этом макете я хочу просто опробовать вв51. Лучше посоветуйте методику отладки подобной платы.
6145261453
Это плата на текущий момент и схема "адресного дешифратора" для ОЗУ. Естественно, в таком виде cp/m она не потянет :) Но мне этого пока и не надо. Я просто хочу пока прошить какую-нибудь тестовую прошивку и убедиться, что схема функционирует. Затем попробовать связаться с ней через терминал. Посоветуйте, как лучше это сделать.
описание какой-то ДОС для 6502 в которой формат файлов на диске сделан совместимым с CP/M
A/65 скорее всего. Неплохая система, но написана одним человеком (за что ему респект) и функциональности минимум. Кое-кто из моих знакомых её себе запустил.
программы для КР580 на 6502 не работают
Напрямую - нет, но есть же симулятор 8080 для 6502, я писал об этом на форуме, http://zx-pk.ru/threads/23276-quot-ayusha-quot-kontroller-na-6502.html?p=805353&viewfull=1#post805353 , ну и в личных сообщениях. Оно работает, с приличной скоростью. Кстати, и для второяблока был порт, Apple-80 звался.
попробовать связаться с ней через терминал. Посоветуйте, как лучше это сделать.
В теме "Самодельный компьютер на Z80 и не только" (http://zx-pk.ru/threads/25682-samodelnyj-kompyuter-na-z80-i-ne-tolko.html) форумчанин Ewgeny7 (http://zx-pk.ru/members/549-ewgeny7.html) тоже "пробовал" ВВ51. Обратитесь к нему, думаю, что он поделится своими мыслями. А самый простой вариант может быть:
- инициируем ВВ51, задаем ему скорость работы;
- слушаем порт;
- при поступлении символа с терминала возвращаем его обратно, приплюсовывая какой-нибудь дополнительный знак, точку к примеру, чтобы было понятно, что символ принят и обработан;
- возвращаемся на п.2.
Даже ОЗУ не нужно, можно обойтись регистрами.
Вы невнимательно читаете мои сообщения. Я же писал, что это макетка просто чтобы руку набить
Извиняюсь, но всё-же не упомнишь. Я подумал, что это конечная плата для CP/M, к которой остаётся лишь добавить массовую память (привод из НГМД, винта или CF-флэш-диска) и подключить по линии внешний терминал на 9600. Зря поставили панельку для статики на 2 кб, лучше бы панельку на 28 ног (чтобы после поставить две 62256 в 2 этажа) или ОЗУ w24257/w24512. Теперь я понял, что Вы делаете просто контроллер, а это тоже полезная вещь, если его грамотно использовать.
посоветуйте методику отладки подобной платы
Методика отладки всех устройств с микропроцессорами одинаковая. Отлаживать маленькие контроллеры проще, чем компьютеры. А для экспериментов лучше бы применили Z80, к нему гораздо меньшая "обвязка" (фактически лишь ЛН1 и ИД7). Первый контроллер спаял на КР580 в 1989. И ещё два контроллера спаял в 90-тые используя SU800 (это Z80 жрущий очень мало тока). Это просто Z80 ядро с ПЗУ РФ2 и ОЗУ 1 кб на КМОП 6514 (купил их 20 штук в начале 90-тых, удобны для МК). Общее число ИМС в контроллере на Z80 смехотворно мало. ЛН1 - генератор с кварцем 3.548 МГЦ, ИД7 - дешифратор для ОЗУ, ПЗУ и КМОП ППА 82С55. Т.к все детали маложрущие, то такой контроллер жрёт менее 20 мА и от автомобильного акумулятора на 6 вольт работает месяц.
Обычно столь простые контроллеры работают сразу. Ещё от отладки ИРИШИ в 80-тые у меня сохранился отладочный стенд (это удобный пошагиватель с HEX-индикаторами на шину адреса и данных), - схема есть в красной книге. Таким пошагивателем было удобно отлаживать платы СПЕЦИАЛИСТА и ОРИОНА. После спайки контроллера я делал так. Прошиваю тестовое ПЗУ, которое издает BEEP на динамик, тестирует ОЗУ и также индицирует его исправность звуком (это особенно удобно, если стоит ВИ53). Если тест в ПЗУ у Вас не запустился, то придётся применить пошагиватель для ОРИОНА (ж.РАДИО 05.1990).
Кстати, где Вы возъмёте такт для ВВ51, если не поставили ВИ53. Он идёт в комплекте с ВВ51, т.к иначе не получить совместимый стандартный протокол. А вот насчёт ВВ51 я ничего не могу посоветовать. Я их никогда не использовал, т.к слишком ленив, потому всегда использовал программную последовательную передачу.
Последовательная передача прекрасно эмулируется программно. Есть у меня свой фазовый протокол, который даёт скорость более 10 кб в секунду. Но последние 15 лет я использовал другой протокол - короткий нулевой импульс это 0, а втрое более длинный импульс это 1. Это сделано для машин, что не работают в реальном времени из-за прерываний (в частности IBM PC).
Вначале передаем пилотон из длинных импульсов (по ним приёмная строна автоматически настраивается, определяет константу). Далее в линию идёт традиционный синхробайт E6 и далее уже передаваемые байты. На двух мегагерцовой машине (без WAIT и ПДП) достигается скорость передачи 4 кб в секунду, что соответствует 4*1024*8= 32768 бод. Если же у Вас Z80 на 3.75 МГЦ, то скорость передачи вдвое быстрее - 65 Кбод. Ну и скажите, какой смысл тогда в использовании ВВ51, если он рассчитан на скорость передачи лишь в 9600 бод (при оверклоке может и 19200). Только пайки намного больше, расход деталей больше, программирования больше, а выигрыша никакого. К сожалению, такой протокол передачи прекрасно и быстро работает на нормальных машинах без прерываний, а вот с IBM PC проблема.
IBM PC не может программно формировать короткие импульсы нужной длительности (и программно замерять длительность коротких импульсов при приёме). Если лень добавлять аппаратуру, то приходится фатально снижать скорость передачи до жалких 150 байт в секунду (это скорость обмена с магнитофоном). Но добавив два одновибратора на 1533ТМ2 (можно и АГ3, но это хуже), это проблема частично (на передачу) решается. Тогда из параллельного интерфейса принтера IBM PC выводятся два сигнала, по переднему фронту которых стартуют одновибраторы. Тогда прерывания в IBM PC не вредят длительности импульсов (даже если прерывание в IBM PC захватит CPU на час, передача не исказится). Скорость передачи от IBM PC достигает 1 кб в секунду, а вот в обратную сторону скорость приёма 150 байт в секунду. Эти протоколы я использовал для обмена между ОРИОНОМ и IBM PC. Недавно я применил более скоростной протокол (отдельная линия для 0 и для 1 и линия готовности), на котором достигается скорость передачи до 4 кб/сек (32 Кбод), без аппаратуры, весь расход деталей только провода. Однако, если на Вашей PC нет выхода на параллельный принтер, то придётся использовать стандартный RS232.
Параллельный принтер, позволяет расширить возможности IBM PC. В современный PC не поставишь самодельную платку с ППА (слишком мизерный шаг в слоте и слишком быстрая скорость в шине). Тогда ставим на выходе параллельного интерфейса (разъём 25 контактов) простейший контроллер на Z80, который описан выше. Тогда IBM PC по однопроводному интерфейсу (описанному выше) выдает команды этому контроллеру, например, - вывести такой-то байт в конкретный порт ППА. И Z80 это выполняет. В результате УФ-программатор можно подключать к IBM PC, причём без всяких вторжений в IBM PC.
Кстати, вот для этого и нужен простейший контроллер на Z80. И именно на Z80, т.к загружая в него из IBM PC программу мы получаем универсальный контроллер, который может делать всё что угодно в рамках своего быстродействия. Например, когда этот контроллер не используется, он работает как обычные часы (в Z80 контроллер загружается программа часов).
PS. А ВВ51 нужен в системе. Но не для создания линии связи, а для подключения мыши. Тут без этого не обойтись. Хотя для текстовой машины обычно мышь не используют.
Smalovsky
24.06.2017, 01:30
Это только в UNIX ошибки идут в отдельный канал. А что это за дурное СИ, если оно так неудобно.
БАРСИК, ты рубишь фишку.
barsik, Z80 тоже своей очереди дождется. Просто всегда хотелось с 580 повозиться. Нереализованная мечта детства, если хотите. Рационально это объяснить невозможно :)
Панельку под ОЗУ, при необходимости, тоже можно переделать. Место под еще 4 контакта там есть. Тем более, это не цельная панелька, а обломки от линейки на 40 контактов. Но я не планирую ставить конкретно на эту плату много памяти. Я уже писал, что в перспективе хочу сделать максимально универсальную систему, чтобы можно было воткнуть как минимум 8080, 8085, z80. Если хватит терпения, то и 8088 и возможно даже что-то еще. Вопрос в том, как обеспечить совместимость всему этому хозяйству. Придется как-то приводить весь этот зоопарк к "общему знаменателю". Как по мне, то задача очень интересная. А эта плата чисто промежуточный этап.
Теперь по вв51 и ви53. Чтобы не усложнять, решил взять такт для вв51 поделив такт процессора на 16. Для этого кварц использую на 22.1184МГц. А ви53 меня пока что пугает, хотя место под нее и осталось.
Error404
24.06.2017, 11:37
Сообщение от barsik Посмотреть сообщение
Это только в UNIX ошибки идут в отдельный канал. А что это за дурное СИ, если оно так неудобно.
БАРСИК, ты рубишь фишку.
Какая разница как оно реализовано в Unix? Unix на Z80 из всех участников благородного собрания есть только у меня, и с моей стороны было не честно добавлять это в сравнение. Да, там я могу перенаправлять вывод куда угодно. Что до вывода разного рода информации в файлы, используемые мной компиляторы выводят в файлы разного рода информацию на этапе отладки являющуюся лишней - разного рода таблицы символьных меток, хексы, промежуточные ассемблерные выхлопы (в случае С) и прочее. Возможно туда же попадут и ошибки (первое что интересует), но сортировать эту помойку дополнительно запуская редакторы/просмотрщики (да не дай бог на тормозном реале под CP/M)... зачем? Когда для этого же мне достаточно на РС шевельнуть колесом прокрутки мыши пролистав экранный буфер терминала где только ошибки (из которых вообще интересует обычно несколько первых из всей простыни). Ох, опять я ввязался в дебаты с теоретиками, погонят за офтоп ссаными тряпками. :)
- - - Добавлено - - -
Кстати, просто в порядке hint - ЕМНИП microshell2 (http://www.z80.eu/microshell.html) даже в версии для CP/M 2.2 помимо прочих вкусностей, умеет перенаправлять ввод-вывод и можно получить файл с только ошибками без прочего лишнего. Но она уменьшает TPA на размер своей "присадки", что плохо для компиляторов (в особенности для C).
И вот ещё вопрос. Подключу я, допустим CF в качестве внешней памяти. Какие-нибудь стандарты на формат записи на этот носитель есть? FAT16, я чую, будет слишком громоздким. Я так понимаю, в "то время" на винт писали кто во что горазд? А сейчас как лучше сделать?
OrionExt
24.06.2017, 14:08
Ну не знаю, у htc сp/m по умолчанию определены три канала (файла).
struct fcb _fcb[MAXFILE] =
{
{ FILL, U_CON }, /* stdin */
{ FILL, U_CON }, /* stdout */
{ FILL, U_CON }, /* stderr */
};
Эти же каналы использует сам компилятор. Другой вопрос что с этим делать самой сp/m.
И вот ещё вопрос. Подключу я, допустим CF в качестве внешней памяти. Какие-нибудь стандарты на формат записи на этот носитель есть? FAT16, я чую, будет слишком громоздким. Я так понимаю, в "то время" на винт писали кто во что горазд? А сейчас как лучше сделать?
Тут с файловой системой каждый определяется сам. Можно использовать файловую систему СP/M, MSX(MS)-DOS или что то третье. FAT16 тяжеловата для i8080 (z80), много математики. Хотя и FAT16 с тормозами будет работать. А вот FAT12 в самый раз.
Видимо файловую систему определяет операционная система. Вряд ли вы возьметесь на старте писать свою ОС.
- - - Добавлено - - -
I8080 сильно ограничивает варианты для выбора. Основная масса примеров в инете рассчитана на Z80. Вот пример (http://www.s100computers.com/My%20System%20Pages/IDE%20Board/My%20IDE%20Card.htm) для i8080.
Какие-нибудь стандарты на формат записи на CF-флэш есть?
Вообще-то флэш носители, такие как 'microSD' и 'CF-флэш' в промышленности используют в формате FAT16/32. Для CF это вполне объяснимо, т.к они используют интерфейс винчестера (и служат для их замены). Но как ни странно, и в телефонах, в которых ОС вообще не MSDOS/Windows, для 'microSD', почему-то тоже стали использовать формат FAT16/32.
Очевидно, из-за этого, все конструкции применяющие флэш-диски для рэтро-ЭВМ используют файлы в формате FAT. Хотя, по крайней мере, в тех в флэш, где есть побайтовый доступ, можно отформатировать его в любой формат. Т.е при желании можно использовать любой формат. Причём не обязательно иметь какую-то ОС, что умеет управлять диском размером в гигабайты, достаточно программно разбить флэш на диски такого размера, что пригодны для конкретной 8-ми разрядной ДОС, и позаботиться, чтобы не было "пересечений".
Я не имел дела с флэш - CF-карты у меня нет, 'microSD' я не умею программировать (чужие устройства на базе МК не годятся для ДОС, они лишь хранят программы 8-ми разрядки в формате FAT16). Имею некоторый опыт использования винчестера в CP/M. Я даже не рассматривал вопрос о совместимости с FAT. Взял винт и написал простейшие подпрограммы чтения и записи сектора 512 байт. Убедился что они работают. В LINUX разбил винт на одну партицию так, чтобы остались неиспользованные цилиндры. Затем в CP/M встроил работу с винчестером, встроив подпрограммы чтения/записи сектора винта. Естественно, в CP/M нумерация треков идёт с нуля, поэтому в п/п-мму "установить трек по заданному в BC номеру трека" я добавил OFFSET. Например, если текущий CP/M-диск начинается с 700-го цилиндра, то к номеру трека добавляем OFFSET=700. Затем я загрузился в CP/M и POWER-ом командой WRITE заполнил цилиндр где находится каталог (т.е есть цилиндр 700) байтами E5 (переформатировать остальные сектора винта нужды нет) . После этого диск на винчестере стал доступен из CP/M. Одновременно этот винчестер имел в начале партицию MSDOS. Можно было грузиться с этого винта на 486-той и хранить там файлы MSDOS. Собирался написать MSDOS программу для обмена с CP/M дисками.
Преимущество такого подхода в том, что можно использовать дохлый винт, который уже не работает на PC. А главное, - не требуется иметь блок кодов, что поддерживает FAT16 (тратить на это 4 кб ОЗУ в CP/M-BIOS глупо). Формат на винте соответствует конкретной DOS. Но сейчас мне доступны только винты гораздо большего размера (десятки и сотни гигабайт). Проблема в том, что для 8-ми разрядки нужны диски маленького размера (более 4 мб неудобно). Отчего на винте умещаются сотни тысяч дисков. Как их адресовать? Например, CP/M допускает только 16 дисков. Это значит, что винт можно использовать на 0.01 процента. Поэтому я собираюсь организовать на винте несколько сотен дисков единого размера в 4 мб. И адресовать их по номерам. При старте в CONFIG.SYS командами типа ASSIGN A 500 (диск 500 назначается приводом A) выбираются стартовые 16 дисков. В нортон естественно тоже надо встроить подобную процедуру.
FAT16, я предполагаю, будет слишком громоздким
Вы имеете ввиду случай, когда "слепок" CP/M-диска замаскирован под файл FAT16 и с ним напрямую (побайтово) работает CP/M-BIOS ? Это не будет громоздко, если этот "файл-слепок CP/M-диска" - недефрагментированный, т.е сплошной массив секторов. Т.е с единственным диском громоздко не будет, а вот если надо менять диски, тут уже нужен блок кодов поддерживающий FAT16.
Я так понимаю, в "то время" на винт писали кто во что горазд?
Эту мысль не понял. В "то время" не делали "кто во что горазд", а использовали диски в формате CP/M. Этот формат определяет CP/M. Но число треков и секторов на треке, размер каталога, число системных дорожек в CP/M (и тем более низкоуровневый физический формат носителя) для каждой машины, естественно, свои. CP/M это без разницы, она считывает БПД, блок параметров диска и узнаёт как устроен конкретный диск.
А сейчас как лучше сделать?
Я знаю, как могу сделать я. А как будет лучше я не знаю. Тут, видимо, сколько людей столько и мнений.
barsik, понятно. Я рассматривал совместимость с FAT только в контексте обмена информацией с PC. Собственно, большой необходимости в этом я не вижу. Так, некоторое удобство. Но если с этим никто не заморачивался раньше, не стоит и пытаться.
- - - Добавлено - - -
Эту мысль не понял
Да я сам еще как следует не понимал, когда задавал вопрос, каша была в голове. Сейчас почитал, понятнее стало как это все устроено.
OrionExt
24.06.2017, 18:46
FAT имеет смысл, если ОС (MSX-DOS) поддерживает изначально файловую систему, если между ОС и диском существует некая прокладка (эмулятор чего-то там), если это самописная ОС. Можете изучить реальный проект с CF-картой (и не только) Альтаир ДОС v3.x (http://zx-pk.ru/threads/18451-altair-dos-v3-x.html) от уважаемого Error404. Правда, там Z80, но общие принципы никто не отменял.
61458
Осталось завтра кварц купить на 22.1, конденсаторы для max232 и можно пробовать прошивку.
Выше упомянул что, кажется, видел CP/M 3.0 для КР580. Это актуально в теме, т.к у топик стартера процессор КР580, а он хочет использовать CP/M 3.0. И для других владельцев отечественных ЭВМ это м.быть любопытно.
Потому скачал этот архив, якобы с версией CP/M 3.0 переделанной для КР580. Но увы, судя по сопроводительному файлу архив оказался для LINUX, и к тому же в непонятном DSK-формате для эмулятора 'cpmsim'. Может кто-то имеющий LINUX, может подсказать как вытащить CP/M-файлы из таких DSK-файлов для их использования в реале или в эмуляторах CP/M в MSDOS или Windows. И вот ещё странный, якобы, исходник CP/M 3.0. Но всем известно, что CP/M 3.0 написана для Z80. А тут почему-то всё в мнемониках КР580, т.е должно работать и на КР580.
http://www.phantom.sannata.ru/konkurs/2008/kt0812.shtml
http://www.autometer.de/unix4fun/z80pack/
http://cpuville.com/cpm_on_new_computer.html
http://www.cpm.z80.de/manuals/archive/cpm22htm/
http://www.z80.info/#BASICS_INST
http://www.seasip.info/Cpm/rsxcalls.html
; ПРОГРАММА НАСТРОЙКИ И ПРОВЕРКИ УСАПП ВВ51А
;
;_______УСТАНОВКА_УСАПП_В_ИСХ._ ОСТОЯНИЕ________
MVI A,01H
OUT CW51
OUT CW51
MVI A,IR
OUT CW51
;_______ЗАПИСЫВАЕМ_ИНСТРУКЦИЮ_ РЕЖИМА____________
MVI A,4EH
OUT CW51
;_______ЗАПИСЫВАЕМ ИНСТРУКЦИЮ КОМАНДЫ___________
MVI A,TXEN+DTR+RXE+RTS
OUT CW51
LOOP:
;_______ЧИТАЕМ БАЙТ ИЗ ПОРТА____________________
CALL RXD
;_______ВОЗВРАЩАЕМ ПРОЧИТАННЫЙ БАЙТ В ПОРТ______
MOV C,A
CALL TXD
;_______ОТПРАВЛЯЕМ ПРИЗНАК ОТВЕТА (!)___________
MVI C,21H
CALL TXD
JMP LOOP
; ПОДПРОГРАММА ПЕРЕДАЧИ БАЙТА ИЗ РЕГИСТРА С
;
TXD: PUSH PSW
;_______ЖДЕМ_ГОТОВНОСТИ_____________ ____________
TX1: IN CW51
ANI TXRDY+DSR
CPI TXRDY+DSR
JNZ TX1
;_______ПЕРЕДАЕМ_БАЙТ_________________ __________
MOV A,C
OUT DAT51
POP PSW
RET
;
; ПОДПРОГРАММА ПРИЕМА БАЙТА В АККУМУЛЯТОР
RXD:
;_______ПРОВЕРЯЕМ_ГОТОВНОСТЬ___ _________________
IN CW51
ANI RXRDY
;_______ВОЗВРАТ_С_ФЛАГОМ_ПЕРЕН СА,______________
;_______ЕСЛИ_ПРИЕМНИК_НЕ_ГОТОВ_ _________________
STC
RZ
;_______ЧИТАЕМ_ПРИНЯТЫЙ_БАЙТ____ ________________
IN DAT51
CMC
RET
;
; ВНЕШНИЕ МЕТКИ И КОНСТАНТЫ
;
;___АДРЕСА_РЕГИСТРОВ_УСАПП____ __________________
DAT51: EQU 00H ; РЕГИСТР ДАННЫХ
CW51: EQU 01H ; РЕГИСТР КОМАНД
;
;___КОМАНДЫ ВВ51________________________________
TXEN: EQU 01H ; ПЕРЕДАТЧИК ВКЛЮЧЕН
DTR: EQU 02H ; УСТРОЙСТВО ГОТОВО
RXE: EQU 04H ; ПРИЕМНИК ВКЛЮЧЕН
SBRK: EQU 08H ; ПРЕРЫВАНИЕ ПЕРЕДАЧИ
ER: EQU 10H ; СБРОС ОШИБОК ПРИЕМА
RTS: EQU 20H ; ПЕРЕДАЧА РАЗРЕШЕНА
IR: EQU 40H ; ПРОГР. СБРОС УСАПП
EH: EQU 80H ; РАЗРЕШЕНИЕ ПОИСКА СИНХРОСИМВОЛА
;
;__РЕГИСТР СОСТОЯНИЯ ВВ51_______________________
TXRDY: EQU 01H ; ПЕРЕДАТЧИК ГОТОВ
RXRDY: EQU 02H ; ПРИЕМНИК ГОТОВ
TXE: EQU 04H ; ПЕРЕДАЧА ЗАКОНЧЕНА
PE: EQU 08H ; ОШИБКА ЧЕТНОСТИ
OE: EQU 10H ; ПЕРЕПОЛНЕНИЕ ПРИЕМНИКА
FE: EQU 20H ; ОШИБКА ФОРМАТА
SYNDET: EQU 40H ; СИНХРОСИМВОЛ НАЙДЕН
DSR: EQU 80H ; ПЕРЕДАТЧИК ДАННЫХ ГОТОВ
;
END
Вот почти цельнотянутая прога из методички.
Black Cat / Era CG
25.06.2017, 18:12
Потому скачал этот архив, якобы с версией CP/M 3.0 переделанной для КР580. Но увы, судя по сопроводительному файлу архив оказался для LINUX, и к тому же в непонятном DSK-формате для эмулятора 'cpmsim'. Может кто-то имеющий LINUX, может подсказать как вытащить CP/M-файлы из таких DSK-файлов для их использовании в реале или в эмуляторах CP/M в MSDOS или Windows.
barsik, смените их расширение на xdi. и откройте в SteinBlume с помощью конфига Cp-M_8Inch.ini из комплекта утилиты - это стандартный для 8-дюймовых CP/M-дисков формат.
[main]
skew_factor=6 ;sector skew factor or sector order
date_stamp=1 ;date stamps format. (0=>none, 1=>CP/M standart, 2=>non standart (used in Z80DOS and DOS+ for example))
ver=0 ;version of ini-file format
[xdi]
len=00 ;Sector length = 80h shl len. (0=>128, 1=>256, 2=>512, 3=>1024)
den=00 ;Heads number - 1
sec=001A ;Sectors per Track
trk=004D ;Tracks number
spt=001A ;logical Sectors (128-byte records) per track. (Not used in SteinBlume)
bsh=03 ;Block shift. Block size = 80h shl bsh. (3=>1k, 4=>2k, 5=>4k...). (Not used in SteinBlume)
blm=07 ;Block mask. Block size = 80h * (blm + 1). (7=>1k, 0Fh=>2k, 1Fh=>4k...)
exm=00 ;Extent mask. Extent size = 4000h * (exm + 1). (0=>16k, 1=>32k, 3=>64k, 7=>128k)
dsm=00F2 ;Blocks number (without) directory. dsm = (tracks_number - off) * spt * 80h / block_size - 1. (dsm = (tracks_number - off) * spt * 80h - (drm + 1) * 20h) / block_size). (Not used in SteinBlume)
drm=003F ;(no. of directory entries)-1
al=00C0 ;Directory allocation bitmap. (Not used in SteinBlume)
cks=0010 ;Directory size in 128-bytes records
off=0002 ;Offset, number of reserved tracks
Ссылку на его описание я вам как-то уже кидал (есть также перевод на http://emuverse.ru)
- - - Добавлено - - -
Вот перевод: http://emuverse.ru/wiki/Формат_дисков_CP/M_1.4
откройте в SteinBlume с помощью конфига CP-M_8Inch.ini из комплекта утилиты
У меня ничего не получилось. Потому что одной вышеприведённой короткой строки инструкции недостаточно. Требуется объяснить подробный порядок действий. А от того, что стало известно какой формат диска в прототипе, тоже нет никакой пользы, кроме познавательной.
Переименовал файпы DSK с размерм в 251 кбайт в XDI. Сначала попробовал перетаскивать XDI-файл на пиктограмму для запуска SteinBlume, естественно, облом. Выдалось сообщение типа того, что размер файла "слишком мал". Запустил DiskAnalyzer и стал перетаскивать файл образа XDI на него. Тот же печальный результат с сообщением, что формат незнаком. Тогда скопировал текст, что был в "спойлере" и записал его в файл *8_inch.ini". Снова запустил SteinBlume, на этот раз без файла образа. Выбрал пункт "открыть образ как xdi". В окне выбора файла выбрал XDI-файл. Появилось окно "параметры .xdi". В нём кликнул на пункт "Загрузить". Появилось окно для загрузки файла "*.ini". Выбрал созданный ранее файл "8_inch.ini". В 'time format' отметил пункт "None". Нажал "открыть" и снова обломился с сообщением "Неверная версия файла настроек". Тогда в окне "параметры .xdi" нажал "ОК" и снова получил сообщение "Файл образа слишком мал. Продолжить?". Кликнул на "ОК" и увидел каталог диска, где все файлы без имён (пробелы) и без размеров с контрольными суммами 00000000. Тогда подумал, что версия SteinBlume не та. Посмотрел в начале темы SteinBlume - у меня та же актуальная версия от 08.03.2017.
Black Cat / Era CG
25.06.2017, 20:03
Тогда скопировал текст, что был в "спойлере" и записал его в файл *8_inch.ini". Снова запустил SteinBlume, на этот раз без файла образа. Выбрал пункт "открыть образ как xdi". В окне выбора файла выбрал XDI-файл. Появилось окно "параметры .xdi". В нём кликнул на пункт "Загрузить". Появилось окно для загрузки файла "*.ini". Выбрал созданный ранее файл "8_inch.ini". Отметил пункт "CP/M-standard". Нажал "открыть" и снова обломился с сообщением "Неверная версия файла настроек".
Вот так и надо.
Только как-то в спойлер ошибочка закралась. Исправлю сейчас.
- - - Добавлено - - -
Enter куда-то пропал.
Пробуйте.
OrionExt
25.06.2017, 20:06
Держите! Усе фурычит в SteinBlume:)
Black Cat / Era CG
25.06.2017, 20:09
Держите! Усе фурычит в SteinBlume
Да это понятно :) Просто хочу объяснить, как оно работает :)
Держите! Всё прекрасно работает в SteinBlume
У меня не работает. Снова скопировал текст из спойлера в файл 8_inch.ini. Открываю XDI-файл, в окне параметров XDI загружаю ini-файл. Кликаю на "загрузить". И снова появляется сообщение "Ошибка. Неверная версия файла настроек". Отмечаю "Формат хранения дат" на NONE и выбираю "Прямое заполнение DPH и DPB". И делаю клик на "ОК". Видимо, т.к теперь я выбираю пункт "Прямое заполнение DPH и DPB", то уже не появляется окно с сообщением о маленьком размере образа. Но результат всё-равно тот же. Непонятно, также как записать полученный формат, чтобы он потом выводился в списке выбора форматов. И что такое "Id строка формата", как им пользоваться, он в этом поле не вводится (думаю, только читается из ini-файла). Может быть это байты сигнатуры для автоматического опознавания формата, что стоят в BOOT-секторе?
OrionExt, спасибо за извлечение файлов, но мне бы хотелось это сделать самому, потому что есть еще пара сотен файлов DSK, из которых хотелось бы тоже извлечь файлы. А Вы точно с помощью SteinBlume эти файлы извлекли? А может всё-же другой программой, например, из комплекта эмулятора Altair808. Не думаю, что проблема из-за Windows XP.
OrionExt
25.06.2017, 22:39
А Вы точно с помощью SteinBlume эти файлы извлекли? А может всё-же другой программой, например, из комплекта эмулятора Altair808. Не думаю, что дело из-за Windows XP.
Точнее не бывает.
Загружал *.xdi файл образа с параметрами как на рисунке. Параметры загружал из файла Cp-M_8Inch.ini. Уже готовый файл Cp-M_8Inch.ini лежит в папке xdi_settings. Ничего не редактировал, просто прокликал несколько раз по кнопкам.
готовый файл Cp-M_8Inch.ini лежит в папке "xdi_settings"
А где находится сама эта папка "xdi_settings" ?
В папке "SteinBlume" только папка "language", а папки "xdi_settings" нет. Я подумал, что было дополнение в дистрибутив и деинсталлировал пакет. Затем скачал заново из поста (http://zx-pk.ru/newreply.php?p=917648&noquote=1) файлы steinblume_install_full.exe и steinblume_install_utils.exe. И снова проинсталлировал их. И ни хрена не изменилось, каталог "xdi_settings" не появился.
Тогда подумал, что эта папка создаётся в какой-нибудь системной папке Windows и запустил в Windows "поиск файлов и папок". Искал как папку "xdi_settings", так и файл "Cp-M_8Inch.ini". И получил печальное сообщение "Поиск не дал результатов". Тогда я провёл поиск файла "Cp-M_8Inch.ini" в Интернете с помощью Google и Yandex. Результат был такой же.
Так и не нашёл искомого файла "Cp-M_8Inch.ini".
OrionExt
26.06.2017, 05:56
Barsik, мы наверное разными источниками пользовались. SteinBlume брал здесь (http://zx-pk.ru/threads/26454-steinblume-cp-m-disk-image-explorer-(ex-atm-cp-m-explorer).html), а именно (http://era-cg.su/download.php?file=steinblume_install_full.zip) (смотри рисунок).
https://lh3.googleusercontent.com/ulyeT4pfaSAOcToCab7JWlIOdVCTTGRP_GNghf_iDL4Icra7F8 LcHTVUjEVFGTDbb1hfvSQ9pg90mHxX8sZOeq_Ik_m8D4Kipwu7 CHypLm0KnqAIGWO_MWc3osyuc8LAPQyPCxwlMIGt_twK7iW-293qNlFDb8SnaVoAjydCGKUqsE32evlgL_4SjADJOk9p2Z8ncK oQuQTMxrHBCU1h7VovgVx2REvtU3_aoJwGUKfePjbM0oUIieSa w9zlS5evDcb9CuifCZpNdCWSygALxFCveal4GcRsQrqdVqae2t 2JVGDAH7Sr6trL8S8nZ3o7_gRAvR8TeVmUj2kv4bMNeSPXuGza doVJq0T0jczRL0Y7iWyYltsxJWK1Ewa4FSiNOTvuFXJXlGCjoj hVm8Kg1m-QlGRSvNCmTLi0E7RJZt6q4Rrpz6FHAivNrw3G5HcOkr38kZsWQ r_quLM9509wfJ3p30MQx8So-Q7h7PS9h3tRHpU6SQZ3U6mIRFNTnMvXaZCPBITmB0T4WBPoPZd XGuH6KQOnYowRKgB3zt0D6B7b2WdNK-Kczq-q2-1smhFx6AAUoELRqkdcR9OnabifrLtbpG9Ag8tB0k-jmwyqLo0c3ICHrnScsZdZ89eScF8vZDaUZDCSOPB6S3lJ4Ich9 YqK4zEWEAJnOojIJkvJkA=w507-h199-no
Black Cat / Era CG
26.06.2017, 11:42
OrionExt, спасибо за извлечение файлов, но мне бы хотелось это сделать самому, потому что есть еще пара сотен файлов DSK, из которых хотелось бы тоже извлечь файлы.
Должен предупредить DSK - это не какой-то определенный формат, это просто оооочень популярное расширение. А что конкретно под ним скрывается, определить как-то автоматом выходит далеко не всегда. Например, расширение используется для Amstrad'овских образов, однако там далеко не просто дамп, это скорее похоже на образ типа Теледиска, то есть с описанием структуры и т. д. Альтаировские DSK - это дампы, но с весьма странным нестандартным размером сектора. А вот именно эти два образа - это дампы с полностью аналогичным стандартному для CP/M (если не ошибаюсь) 1.2 форматом. Как я об этом догадался? Посмотрел размер образа, он показался мне знакомым, убедился в том, что он такой же, как у образа 8-дюймого CP/M диска, который я уже открывал, на всякий случай заглянул внутрь образа с помощью Hex-редактора, убедился в наличии достаточно характерного смещения (перемешивания) данных (т.н. software skewed sectors). Ни и в финале попробовал открыть образ, используя уже готовый (ну мной же раньше созданный) инишник. Должен уточнить, что в конечном результате я абсолютно не был уверен - формат мог оказаться и другим, просто похожим. Но в итоге образ был открыт успешно.
Тут в чем суть. Утилита работает только с дампами (под этим словом я подразумеваю образа, содержащие только информацию с секторов без какой-либо служебной). Но и это не гарантирует простой результат. Возможности для автодетекта 99% форматов дисков просто нет (ну не принято было тогда хранить на дисках какие-то однозначные сигнатуры). Поэтому с каждым отдельным форматом приходится разбираться отдельно, либо знать, какой именно формат имеет образ.
Не думаю, что дело из-за Windows XP
Точно не из-за XP. Утилита под ней пишется (по крайней мере писалась до недавнего времени).
А где находится сама эта папка "xdi_settings" ?
Тут два варианта. Если SteinBlume установлен с помощью инсталлятора, то искать xdi_settings надо в служебной папке вроде c:\Users\BlackCat\AppData\Roaming\SteinBlume\xdi_s ettings\ Дело в том, что с некоторых пор винда не любит, когда программы пытаются делать что-то с файлами, лежащими в папках типа Program Files, поэтому все служебные файлики теперь принято хранить в таких вот служебных папках отдельно от самой программы.
Если же скачать SteinBlume (полную версию), как zip-архив и распаковать куда-то, кроме Program Files, то xdi_settinLaбудет лежать в той же папке, где и упомянутая папка language, то есть в папке SteinBlume.
Вот 61473 на всякий случай набор инишников отдельных архивом. Только распакуйте его в какую-нибудь нормальную папку со всеми необходимыми правами.
- - - Добавлено - - -
Непонятно, также как записать полученный формат, чтобы он потом выводился в списке выбора форматов.
Вы имеете в виду, чтобы можно было создавать новые образа с этим форматом?
И что такое "Id строка формата", как им пользоваться, он в этом поле не вводится (думаю, только читается из ini-файла).
Эта строка обычно пустая, введена и используется (весьма редко), чтобы не плодить всякие дополнительных строки в инишниках, позволяет однозначно задетектить некоторые тонкости (например PLUS3DOS, сообщает SteinBlume, о том, что речь идет о образах именно этой системы и позволяет редактировать заголовки файлов, которые имеются у +3DOS и другие фичи свойственные именно ей). С помощью id можно в будущем (если это будет нужно) ввести поддержку особенностей, например, того же Альтаира с его странными секторами и заставить утилиту обрабатывать образа, учитывая эти особенности. Эти строки (id) - константы жестко мной прописываемые в утилите. Никакого отношения к сигнатурам хранящимся на дисках они не имеют, просто и самих сигнатур как таковых практически нет...
Как-то так.
- - - Добавлено - - -
Написал небольшой туториал на тему открытия .xdi. Раз уж вопросы возникают.
Так как это оффтоп, прячу под спойлером (и продублирую у себя в теме).
Краткая инструкция "Как можно открыть xdi-образ, не имея ini-файла, но четко зная подробности формата" (на примере формата 8-дюймовых дисков CP/M 1.4)
I. Вариант номер РАЗ.
1. Открываем SteinBlume;
2. Перетаскиваем образ в Утилиту (либо открываем через меню, с помощью пункта "Открыть образ...");
3. В появившемся окне "Параметры .xdi":
3.1 Текущий файл настроек - информационное поле, не редактируется.
3.2 Id-строка формата - константа, позволяющая однозначно задать некоторые тонкости формата, если не знаем, что сюда писать, оставляем пустым. В данном случае оставляем пустым.
3.3 Смещение секторов - параметр, задающий порядок чтения секторов для образов дисков с программным смещением секторов (sofware skewed sectors). Либо одно десятичное число (задающее фиксированное смещение), либо порядок чтения всех секторов единым списком через запятую, без пробелов. Для CP/M 1.4 skew factor = 6
3.4 Формат хранения дат - на данный момент временные записи в директории игнорируются. Но все равно желательно задать этот параметр. Для CP/M 1.4 выбираем CP/M стандарт (1 - в ини-файле).
3.5 Выбираем "Прямое заполнение DPH и DPB". С Простым попроще, но если есть все необходимые данные, то лучше задать все в точности (Тем более в простом есть баг).
3.6 И задаем параметры:
len=0
den=0
sec=1A
trk=4D
bsh=3
drm=3F
off=2
Остальные параметры утилита поменять не даст.
3.7 Полученные настройки можно:
[*=1]Сохранить в виде ini-файла, нажав кнопку "Сохранить",
[*=1]Запомнить как Настройки по умолчанию, чтобы не вводить эти параметры каждый раз при открытии образов одинакового формата. (Настройки по умолчанию можно всегда задать/изменить в настройках утилиты).
3.8 Жмем "ОК"
4. Профит.
II. Вариант не требующий смену расширения у файла образа на ".xdi".
1. Открываем SteinBlume;
2. Открываем образ с помощью пункта меню "Открыть образ как .xdi...". С помощью этого пункта можно попытаться открыть как .xdi образ с любым расширением.
3. Выполняем описанное выше в пункте 3;
4. Профит.
III. Открытие с помощью "Простого заполнения".
А вот его лучше б не использовать - есть баг. Ниже опишу, как с ним бороться.
1. Открываем SteinBlume;
2. Открываем образ любым понравившимся из вышеописанных способов;
3. В появившемся окне "Параметры .xdi":
3.1 Выполняем описанное выше в пунктах 3.1-3.4;
3.2 Выбираем "Простое заполнение параметров диска". Стоит обратить, что здесь все параметры вводятся в десятичной форме (Простое же).
3.3 И задаем параметры:
Число сторон диска. В нашем случае - 1;
Число цилиндров. В нашем случае - 77;
Число секторов на дорожке. В нашем случае - 26;
Размер сектора (байт). В нашем случае - 128;
Размер блока (байт). В нашем случае - 1024;
Число записей в директории. В нашем случае - 64;
Число системных дорожек. В нашем случае - 2.
3.4 ВАЖНО. Имеет место быть баг (введенные настройки игнорятся). Чтобы баг обойти, после ввода всех параметров потыкайте туда-сюда по пунктам "Прямое заполнение DPH и DPB" и "Простое заполнение параметров диска" - настройки перестанут игнорироваться.
3.5 Жмем "ОК";
4. Профит.
OrionExt
26.06.2017, 19:56
Осталось завтра кварц купить на 22.1, конденсаторы для max232 и можно пробовать прошивку.
А вы не думали, вместо MAX232 типа такой платки (FTDI232) применить? На выходе USB, а по факту для консоли PC RS232. Просто ее можно подключить сейчас к любому современному ПК.
https://im0-tub-ua.yandex.net/i?id=9e24130d2e4c8b56d8dc733f2e07047c&n=33&h=215&w=215
А вы не думали, вместо MAX232
Уже в этой ветке было предложено ( http://zx-pk.ru/threads/27613-kompyuter-dlya-cp-m-formulirovka-tz.html?p=917128&viewfull=1#post917128 ). И давно пользую, только сделал выход USB-B, чтобы принтерным шнуром подключать. Так кошернее, чем микриком.
А вы не думали, вместо MAX232 типа такой платки (FTDI232) применить? На выходе USB, а по факту для консоли PC RS232. Просто ее можно подключить сейчас к любому современному ПК.
Да, такой вариант я тоже рассматривал. Но хотел заодно порт на материнке проверить.
OrionExt
26.06.2017, 20:14
Уже в этой ветке было предложено
Значит, мысли сходятся:)
Ну, разъем USB – это дело такое. Тут есть выбор, просто у меня эти шнурки уже девать некуда, а тут им применение нашлось.
Короче, прошил я в ПЗУшку вот этот быдлокод. Вроде заработало, но не так как ожидалось. Включаю железку, подключаюсь к ней через Terminal 1.9b. Посылаю байты. В ответ тишина. Включаю Request To Send ручками и тут начинают сыпаться в ответ нули и восклицательные знаки (21h - отзыв железки). Если при этом я жму клавиши, то в ответ приходит символ с тем же "!". Подозреваю, что я где-то ошибся, но где? В программе или в проводах? Схему постараюсь наконец-то нарисовать и выложить.
; ПРОГРАММА НАСТРОЙКИ И ПРОВЕРКИ УСАПП ВВ51А
;
;_______УСТАНОВКА СТЕКА____________________________
LXI SP,RAMTOP
;_______УСТАНОВКА_УСАПП_В_ИСХ._ ОСТОЯНИЕ________
MVI A,01H
OUT CW51
OUT CW51
MVI A,IR
OUT CW51
;_______ЗАПИСЫВАЕМ_ИНСТРУКЦИЮ_ РЕЖИМА____________
MVI A,4EH
OUT CW51
;_______ЗАПИСЫВАЕМ ИНСТРУКЦИЮ КОМАНДЫ___________
MVI A,TXEN+DTR+RXE+RTS
OUT CW51
LOOP:
;_______ЧИТАЕМ БАЙТ ИЗ ПОРТА____________________
CALL RXD
;_______ВОЗВРАЩАЕМ ПРОЧИТАННЫЙ БАЙТ В ПОРТ______
MOV C,A
CALL TXD
;_______ОТПРАВЛЯЕМ ПРИЗНАК ОТВЕТА (!)___________
MVI C,21H
CALL TXD
JMP LOOP
; ПОДПРОГРАММА ПЕРЕДАЧИ БАЙТА ИЗ РЕГИСТРА С
;
TXD: PUSH PSW
;_______ЖДЕМ_ГОТОВНОСТИ_____________ ____________
TX1: IN CW51
ANI TXRDY+DSR
CPI TXRDY+DSR
JNZ TX1
;_______ПЕРЕДАЕМ_БАЙТ_________________ __________
MOV A,C
OUT DAT51
POP PSW
RET
;
; ПОДПРОГРАММА ПРИЕМА БАЙТА В АККУМУЛЯТОР
RXD:
;_______ПРОВЕРЯЕМ_ГОТОВНОСТЬ___ _________________
IN CW51
ANI RXRDY
;_______ВОЗВРАТ_С_ФЛАГОМ_ПЕРЕН СА,______________
;_______ЕСЛИ_ПРИЕМНИК_НЕ_ГОТОВ_ _________________
STC
RZ
;_______ЧИТАЕМ_ПРИНЯТЫЙ_БАЙТ____ ________________
IN DAT51
CMC
RET
;
; ВНЕШНИЕ МЕТКИ И КОНСТАНТЫ
;
RAMTOP: EQU 87FFH ;
;___АДРЕСА_РЕГИСТРОВ_УСАПП____ __________________
DAT51: EQU 00H ; РЕГИСТР ДАННЫХ
CW51: EQU 01H ; РЕГИСТР КОМАНД
;
;___КОМАНДЫ ВВ51________________________________
TXEN: EQU 01H ; ПЕРЕДАТЧИК ВКЛЮЧЕН
DTR: EQU 02H ; УСТРОЙСТВО ГОТОВО
RXE: EQU 04H ; ПРИЕМНИК ВКЛЮЧЕН
SBRK: EQU 08H ; ПРЕРЫВАНИЕ ПЕРЕДАЧИ
ER: EQU 10H ; СБРОС ОШИБОК ПРИЕМА
RTS: EQU 20H ; ПЕРЕДАЧА РАЗРЕШЕНА
IR: EQU 40H ; ПРОГР. СБРОС УСАПП
EH: EQU 80H ; РАЗРЕШЕНИЕ ПОИСКА СИНХРОСИМВОЛА
;
;__РЕГИСТР СОСТОЯНИЯ ВВ51_______________________
TXRDY: EQU 01H ; ПЕРЕДАТЧИК ГОТОВ
RXRDY: EQU 02H ; ПРИЕМНИК ГОТОВ
TXE: EQU 04H ; ПЕРЕДАЧА ЗАКОНЧЕНА
PE: EQU 08H ; ОШИБКА ЧЕТНОСТИ
OE: EQU 10H ; ПЕРЕПОЛНЕНИЕ ПРИЕМНИКА
FE: EQU 20H ; ОШИБКА ФОРМАТА
SYNDET: EQU 40H ; СИНХРОСИМВОЛ НАЙДЕН
DSR: EQU 80H ; ПЕРЕДАТЧИК ДАННЫХ ГОТОВ
;
END
Включаю Request To Send ручками и тут начинают сыпаться в ответ нули и восклицательные знаки
Судя по коду так и должно работать. Ты же не ждёшь готовности в RXD, а возвращаешься с нулём в А и флагом переноса, если буфер пуст. Либо сделай ожидание в RXD, либо поставь JC LOOP после CALL RXD
поставь JC LOOP после CALL RXD
Точно, оно самое. Теперь работает как надо.
Возник следующий вопрос: если на процессор приходит сигнал прерывания, а шина данных к +5 не подтянута и контроллера прерываний нет, то следовательно процессор выполнит nop и продолжит исполнение основной программы?
шина данных к +5 не подтянута и контроллера прерываний нет, то следовательно процессор выполнит nop
Не обязательно. Кто его знает, что там будет на шине данных...
Ну так-то все должно быть в высокоомном состоянии. Нечему там кроме проца шину данных дергать. А сам с собой то он не будет же конфликтовать.
OrionExt
29.06.2017, 18:53
Ну так-то все должно быть в высокоомном состоянии.
Ну, вот процессор и считает вместо команды - "мусор" с шины данных.
Не кому ведь процессору подсунуть команду, после сигнала запроса прерывания.
OrionExt, понятно. В таком случае, надо значит к земле подтягивать.
Подтяни к подтверждению прерывания - будет тебе этакий псевдо-контроллер прерываний :)
TomaTLAB
30.06.2017, 10:38
будет тебе этакий псевдо-контроллер прерываний Пару-тройку корпусов мелочи - и можно соорудить вполне себе. :)
Хочу вв51 на прерываниях сделать и думаю, достаточно ли одного будет?
OrionExt
30.06.2017, 15:35
Как показывает практика тех лет, одного прерывания на RST7 хватало на несколько задач. Со схемой ОК по INT. Правда, это требовало анализа в коде. А так сложно сказать. Смотря, какие задачи вы будете ставить в будущем.
Ну, для начала хочу просто попарсить, что там с порта приходит. Простенький мониторчик на пяток команд.
подключаюсь через Terminal 1.9b и посылаю байты...
... теперь последовательная передача работает как надо
Расскажите о схеме подключения вашего устройства с ВВ51 к IBM PC. Как согласовали уровни (+5В и +/- 12В) и есть ли гальваническая развязка? К чему вообще подключали провода на IBM PC и по какой схеме? К разъёму последовательного интерфейса? Что за 'Terminal 1.9b' и где его брать? На какую стандартную скорость передачи программировали 8250?
Как программировать 8250 стоящую в IBM PC ясно. Но не знаю как в Windows получить доступ к этой 8250. Т.к Windows, начиная с версии Windows ME не допускает из программ доступ к портам. Мне приходится грузиться в MSDOS (или в Win 98), - только так я имею доступ к портам. При запуске в Windows эмулятора, написанного для MSDOS, нет доступа ни к параллельному интерфейсу, ни к последовательному интерфейсу.
Имею кучу ВВ51, 6850, Z80-SIO, Z80-DART, UB 8560D, UB 8561 и не могу понять какой из них лучше применить с точки зрения удобства программирования и получения максимальной скорости. Для получения такта SIO думаю выгоднее использовать UB 857 (Z80CTC), т.к в нём 4 канала (вместо 3-х каналов ВИ53) и он высокочастотнее, что в итоге даёт большую точность (т.е соответствие стандартной скорости).
Хочу работу с ВВ51 на прерываниях сделать
А зачем это надо?
Кажется, что это надо только для обслуживания клавиатуры или мыши (где передаётся всего один байт в час). А для максимально скоростной передачи массива - скоростей КР580 и так едва хватает. Что применение прерываний ускоряет скорость передачи?
Расскажите о схеме подключения вашего устройства с ВВ51 к IBM PC
Подключение через MAX232 к COM порту компьютера.
Что за 'Terminal 1.9b' и где его брать?
тыц (https://sites.google.com/site/terminalbpp/).
А зачем это надо?
Просто хочу поковырять прерывания.
Ну вот, долго ли коротко ли, запилил новый вариант с прерываниями и новыми непонятками. Подключил RxRDY от ВВ51 к INT процессора и прошил EEPROM.
include "8085.inc"
;| ПРОГРАММА НАСТРОЙКИ И ПРОВЕРКИ УСАПП ВВ51А
;
INIT: DI
LXI SP,RAMTOP
MVI A,01H; УСТАНОВКА_УСАПП_В_ИСХ._СОСТ ЯНИЕ
OUT CW51
OUT CW51
MVI A,IR
OUT CW51
MVI A,4FH; ЗАПИСЫВАЕМ_ИНСТРУКЦИЮ_РЕЖИ МА
OUT CW51
MVI A,TXEN+DTR+RXE+RTS;27H; ЗАПИСЫВАЕМ ИНСТРУКЦИЮ КОМАНДЫ
OUT CW51
EI
HLT
;____ПОДПРОГРАММА ПЕРЕДАЧИ БАЙТА ИЗ РЕГИСТРА С_
;
TXD: PUSH PSW
;_______ЖДЕМ_ГОТОВНОСТИ_____________ ____________
TX1: IN CW51
ANI TXRDY+DSR
CPI TXRDY+DSR
JNZ TX1
;_______ПЕРЕДАЕМ_БАЙТ_________________ __________
MOV A,C
OUT DAT51
POP PSW
RET
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
RST 7
;__________ПОДПРОГРАММА ОБРАБОТКИ ПРЕРЫВАНИЙ____
INT: DI
IN DAT51; ЧИТАЕМ БАЙТ ИЗ ПОРТА
MOV C,A
CALL TXD; ВОЗВРАЩАЕМ ПРОЧИТАННЫЙ БАЙТ В ПОРТ
MVI C,40H
CALL TXD; ОТПРАВЛЯЕМ ПРИЗНАК ОТВЕТА (@)
EI
RET
;
;_____________ВНЕШНИЕ МЕТКИ И КОНСТАНТЫ_______
RAMTOP=87FFH ;
;
;___АДРЕСА_РЕГИСТРОВ_УСАПП____ __________________
DAT51=00H ; РЕГИСТР ДАННЫХ
CW51=01H ; РЕГИСТР КОМАНД
;
;___КОМАНДЫ ВВ51________________________________
TXEN=01H ; ПЕРЕДАТЧИК ВКЛЮЧЕН
DTR=02H ; УСТРОЙСТВО ГОТОВО
RXE=04H ; ПРИЕМНИК ВКЛЮЧЕН
SBRK=08H ; ПРЕРЫВАНИЕ ПЕРЕДАЧИ
ER=10H ; СБРОС ОШИБОК ПРИЕМА
RTS=20H ; ПЕРЕДАЧА РАЗРЕШЕНА
IR=40H ; ПРОГР. СБРОС УСАПП
EH=80H ; РАЗРЕШЕНИЕ ПОИСКА СИНХРОСИМВОЛА
;
;__РЕГИСТР СОСТОЯНИЯ ВВ51_______________________
TXRDY=01H ; ПЕРЕДАТЧИК ГОТОВ
RXRDY=02H ; ПРИЕМНИК ГОТОВ
TXE=04H ; ПЕРЕДАЧА ЗАКОНЧЕНА
PE=08H ; ОШИБКА ЧЕТНОСТИ
OE=10H ; ПЕРЕПОЛНЕНИЕ ПРИЕМНИКА
FE=20H ; ОШИБКА ФОРМАТА
SYNDET=40H ; СИНХРОСИМВОЛ НАЙДЕН
DSR=80H ; ПЕРЕДАТЧИК ДАННЫХ ГОТОВ
;
FASMG я для себя открыл только сегодня :) , поэтому еще не разобрался как обработчик прерываний штатно прикрутить к 38H, просто напихал нужное количество RST 7. Прошил, заработало. Прием данных идет по прерываниям. Только не понимаю, откуда взялась "очередь" из двух байтов? Вот пример: ввожу последовательно "ASDFG "(3 пробела в конце), а железка отвечает такой последовательностью (в шестнадцатеричном виде) "4B 40 4B 40 41 40 53 40 44 40 46 40 47 40 20 40". Откуда взялись первые два байта? Я не догоняю.
Что-то никто не ответил на мой прошлый пост, повторю с вариациями...
Ткните носом в стандарт СР/М по организации страниц в ОЗУ. В каких адресах это должно делаться, размер страниц, порт для переключалки/маппера... Если это делалось в отечественных компах (тот же Орион), то насколько совместимо с большинством зарубежных программ получилось (чтот я сомневаюсь, что было что-то отечественное, заслуживающее внимания, если вообще что-то было),.. ну и какой может быть вменяемый оптимум памяти, чтобы можно было работать с базами данных.
Насколько я понимаю, страницы должны располагаться между адресами 100Н и С400Н, но как и где... Просто не хочу ваять заранее нерабочую отсебятину.
Всем пасиб и печенек.
OrionExt
06.07.2017, 22:28
А не было никакого стандарта. Если кто и делал под себя на уровне ОС, то это было сугубо индивидуальное. И программ стандартных для СР/М работающих со страничной организацией тоже не встречал. СР/М 3 позволяла свой код хранить выше 64КБайт на этом и все.
Если не прав поправьте.
- - - Добавлено - - -
Для менеджмента памяти на уровне ОС, нужны хотя бы наличие соответствующих функций в ней. В СР/М 3 я такого не припомню.
Да о каком стандарте может идти речь, когда каждый компьютер содержащий более 64 Кб имел сугубо свою организацию памяти.
На вскидку в Орионе есть такая допиленная СР/М - Альтаир ДОС v3.x. MSX тоже такой системой обзавелся - MSX-DOS 2.2. Но опять софта для этих ОС с гулькин нос. Померло так и не успев родиться.
Хм... т.е. смысла делать машинку с памятью свыше 64К нет? Выше версии 2.2 не хочу лезть...
OrionExt
06.07.2017, 22:54
Может и есть смысл делать свыше 64Кбайт. В то время вся эта расширенная память уходила под рам-диск, что значительно ускоряло работу в ОС.
Что-то никто не ответил на мой вопрос о стандарте СР/М по организации страниц в ОЗУ
Вам не ответили, потому что никто не знает ответа. В СССР и СНГ никто не имел CP/M 3.0, тем более в банковом варианте. И всё-же раз CP/M 3.0 поддерживает многобанковость, то значит какой-то механизм управления памятью там был. ЕМНИП помню, что читал, что там был какой-то RSX (http://www.seasip.info/Cpm/rsxcalls.html) (возможно расшифровывается, как Resident System eXtension).
Чтобы разобраться, Вам придётся самому читать документацию по CP/M 3.0 вот здесь (http://www.seasip.info/Cpm/bdos.html#60). И по-прежнему остаётся вопросом, есть ли компиляторы хоть каких-то ЯВУ, позволяющие писать программы использующие многобанковость (неважно, управляя ей стандартно, т.е функциями ДОС или по железу конкретной машины). Если ни компиляторов, ни программ для многобанковости нет, то зачем она?
OrionExt
07.07.2017, 00:19
И по-прежнему остаётся вопросом, есть ли компиляторы хоть каких-то ЯВУ, позволяющие писать программы использующие многобанковость (неважно, управляя ей стандартно, т.е функциями ДОС или по железу конкретной машины).
Существует HI-TECH Z80 C Compiler 7.80PL2 c поддержкой менеджера памяти Z180 (и не только) и еще были. Только какой в них прок для ОС которая не видит больше 64 Кбайт. Другое дело применять эти компиляторы для различных специализированных систем, но это уже другая история.
никто не имел CP/M 3.0
эм... банки только к третьей версии относятся? Я имел в виду вообще, ибо как сказано выше
Выше версии 2.2 не хочу лезть...
Понятно, значит "64 килобайт хватит всем" и поддерживающих банки программ не существует. А RAM-диск ныне вещь бесполезная...
Всем спасибо.
rw6hrm, если и подключать дополнительно банки, то страницами по 64к. Только таким образом можно хоть как-то адаптировать систему под расширение памяти. Можно хотя бы выделить системе и приложению(ям) разные страницы. Этот принцип и с z180 должен быть совместим.
OrionExt
07.07.2017, 08:39
если и подключать дополнительно банки, то страницами по 64к.
Страницы по 64 кбайт не очень удобно. Надо бы иметь общий участок памяти.
Вот модель памяти для Z180 с настраиваемым менеджером в нем. Неплохо ложится на компиляторы Си с поддержкой банковой модели памяти.
ffffh
4 кбайт min - common
---
.
. 4 кбайт
. ... - bank
. 56кбайт
.
---
4 кбайт min - common
0000h
Нижний и верхний общий участок можно убрать в настройках менеджера.
Надо бы иметь общий участок памяти.
А зачем? Софта никакого нет с поддержкой этой модели. Проще RAM-диск сделать и через него обмен осуществлять. Например, как в ЮТ-88.
OrionExt
07.07.2017, 10:01
А зачем?
Ну, хотя бы указатель стека хранить. А то щелкните 64 Кбайтами, а там пустота;)
Не совсем понял про указатель стека. Если стек хранить - другое дело. Но я не зря упомянул про ЮТ-88 ;)
OrionExt
07.07.2017, 11:15
А что рам-диск, он в адресном пространстве ЦПУ не лежит. Как я понял обмен с ним идет через стек и порт 40H. Для хранения данных оригинальное решение, но программу в нем не запустить. Если мы об одном и том же рам-диске говорим.
Речь ведь шла о страницах памяти в адресном пространстве ЦПУ.
За то, через него можно организовать обмен данными. А программу все равно не запустишь в нескольких страницах.
TomaTLAB
07.07.2017, 14:03
Ну как не запустишь... Цельным куском, конечно, проблематично.
Но делать вызовы процедур (функций) размещенных на разных страницах вполне возможно.
В MSX есть такое понятие как "межслотовый вызов", а "слот" там та-же страница памяти суть и есть.
Другое дело как скрестить ежа с ужом.
маленький оффтоп: а есть ли владельцы компа Altair?
OrionExt
07.07.2017, 17:57
А программу все равно не запустишь в нескольких страницах.
Можно еще поверху ОС такую штуку (http://map.grauw.nl/resources/tsrdev_en.php) накатать (это для MSX). Так сказать такой вариант менеджера памяти TSR. Есть готовая графическая библиотека для Турбо Паскаля 3.0, как некий модуль, загружаемый выше 64кб в среде TSR. Пишешь программку на Паскале в обычной ОС (макс 64 кб) и вызываешь графические функции из памяти выше 64 кб. Красота:)
Так что и для CP/M (MSX-DOS1) память выше 64кб полезна.
Чего только не придумывали, чтобы обойти ограничение в 64кб:v2_dizzy_roll:
- - - Добавлено - - -
Да MSX-DOS1 - это по сути CP/M-2.2. Честно спионерили одни, а потом другие еще раз продали спионеренное:biggrin: известной компании (не ASCII).
И первому пионеру, вторые трубу и барабан вручили за "работу":smile: Исторический факт таки.
OrionExt
07.07.2017, 20:25
маленький оффтоп: а есть ли владельцы компа Altair?
Долго думал, что ответить, вы видимо темой ошиблись.
маленький оффтоп: а есть ли владельцы компа Altair?
Долго думал, что ответить, вы видимо темой ошиблись.
Да не, не ошибся. Для Альтаира тоже есть СР/М. Вот только пользователей Альтаира тут походу никогда не было...
OrionExt
07.07.2017, 21:27
Все ноги растут из СР/М:D
Из CP/M Били стартонул (смотрим чуть выше) и программил он бейсик на Altair (а может и нет).
Да и основа всего линейка логарифмическая (это мой видимо старт. Двигал двигал ребенком и поломал. Значит, был интерес).
Уходим от темы друзья.
если и подключать дополнительно банки, то только страницами по 64 кб
Речь идёт о выборе наиболее удобного аппаратного диспетчера памяти.
В чистом виде цельнобанковая коммутация по 64 кб невозможна, даже если для переключения использовать команду OUT. Потому что тогда нет никакого способа как программе или данным попасть из основной банки в дополнительные. Коммутацию можно делать только если дополнительные банки имеют хоть немного ПЗУ или некоммутируемый фрагмент ОЗУ (или хотя-бы имитацию некоммутируемости участка ОЗУ, путём загрузки в банки одинаковых кодов).
Чтобы всё-же получить диспетчер с коммутацией в 64К, необходимо разбить 64К на несколько коммутируемых окон, что позволяет одновременно включить в адресное пространство фрагмент основной банки памяти и фрагмент дополнительной банки. После загрузки в дополнительные банки подпрограммы для коммутации (для имитации некоммутируемого участа) в дальнейшем можно коммутировать ОЗУ уже не в окне, а целыми банками по 64К. Кстати, первый в СССР диспетчер памяти был применён в ИРИШЕ (1984) и он был именно такого типа. В нём коммутировалось всё адресное пространство в 64К, но оно было разбито на 4 независимо коммутируемых окна по 16К, что позволяет осуществить начальную произвольную загрузку доп.банок, и после загрузки в доп.банку небольшого куска кода (программы коммутации) можно использовать и цельнобанковую коммутацию по 64К.
Таким образом без некоммутируемого ПЗУ (или имитацией этого в ОЗУ) невозможно переключать банки целиком. В то же время наличие некоммутируемого фрагмента ОЗУ, как это сделано в ОРИОНЕ, совершенно не является обязательным, хотя и упрощает жизнь программисту (освобождает от необходимости переставлять стек при включении очередной банки). Исходя из этого, а также установившихся в бытовых ЭВМ стандартов на входы в ПЗУ и по принципу, что "чем проще, тем лучше", самой удобной будет коммутация с окном в 62 кб, оставляя окно F800...FFFF некоммутируемым в виде ПЗУ. Особенно это справедливо, если доп.банки используются только как VDISK, а не как полноценное ОЗУ для хранения программ или данных.
Что касается того, чтобы установить границу окна коммутации на уровне C400, CC00 или D000 (т.е на уровне BDOS CP/M), чтобы при переключениях памяти сам код CP/M не изменялся, отчего вызов функций CP/M был бы возможен из любой банки, то это также совершенно не требуется. Во-первых, уровень BDOS в разных версиях ДОС меняется, а во-вторых, даже если это и требуется, то легко скопировать в доп.банки весь код CP/M BDOS+BIOS, с'имитировав тем самым некоммутируемость.
Ещё одной идеей для коммутируемости может быть некоммутируемость ZERO-page CP/M, т.е 256 байт ОЗУ 0000...00FF. Это позволяет получить, как максимально высокий TPA до FF00 (перегрузив исполняемый код CP/M 2.2 в доп.банки), так и позволяет использовать в каждой банке максимум, а именно - 63.75 килобайт памяти.
barsik, есть еще возможность перемещать данные между банками при помощи ПДП или одновременная запись в несколько банков.
есть ещё возможность перемещать данные между банками за счёт одновременной записи сразу в несколько банок
Это свежая идея.
Хорошую экономию деталей и удобство программирования эта идея даёт, если иметь ПЗУ F800 только в основной банке 0, т.е имея в банке 1 FULL RAM, и заносить туда "программу коммутации" путём записи байтов в адреса F800...FFFF нулевой банки (т.к в этой области в банке 0 ПЗУ, так что запись сюда ничего не испортит). Это позволяет тратить на "интерфейс" в каждой дополнительной банке только 16 байтов (FFF0...FFFF), оставляя для полезного использования всё основное пространство каждой доп.банки.
Тогда исполнительные части подпрограммы RDBYTE (FFF0) и WRBYTE (FFF8) для чтения и записи байтов в доп.банках, удобно сделать аналогично подпрограммам ПЗУ ОРИОНА F836/39, но только с учётом их фатальной ошибки (не позволяющей вызывать эти п/п-ммы из других банок кроме нулевой). Для этого достаточно в регистре 'B' передавать номер банки, откуда был вызов и куда надо сделать возврат.
есть ещё возможность перемещать данные между банками при помощи ПДП
А вот идея использовать ПДП для межбанкового обмена не годится.
Определитесь какого грамматического рода у Вас банки памяти. Женского или мужского? То есть "банка памяти" или "банк памяти". Я всегда применяю термин женского рода - банка (потому что слово "банк" в предложении менее информативно, т.к хуже склоняется).
А вот идея использовать ПДП для межбанкового обмена не годится.
Почему?
Опрелитесь какого грамматического рода у Вас банки памяти.
Я вроде в последнее время двусмысленных трактовок не допускал.
потому что слово "банк" в предложении менее информативно, т.к не склоняетс
Это что-то новенькое.
Black Cat / Era CG
08.07.2017, 15:35
потому что слово "банк" в предложении менее информативно, т.к не склоняется
Странно. Вроде как мужской род, II склонение: банк, банка, банку, банк, банком, о банке; банки, банков, банкам, банки, банками, о банках.
Вроде так.
Почему не годится идея использовать ПДП для межбанкового обмена ?
Нет смысла ставить БИС ПДП и кучу микросхем обрамления для реализации логики, что к тому же бесполезно нагружает шину, если ту же задачу решает просто наличие общего ПЗУ в банках. Это ПЗУ в доп.банке может быть размером не в 2 кб, а всего в 16 байт, где и располагаются всего две п/п-ммы RDBYTE и WRBYTE, похожие на п/п-ммы ОРИОНА F836/39.
Это что-то новенькое
Банк - от итал. 'banco' — скамья, лавка, стол, на которых ростовщики раскладывали монеты
Согласен, что причину я придумал неудачную. Т.к речь идёт о пересылках, имелось ввиду, что слово банк в ответе на вопрос куда, звучит точно также как в именительном падеже, т.е не склоняется. Тогда вот другая причина, - чтобы не путать с финансовым понятием банк. А что общего у микросхем памяти со скамейками?
Black Cat / Era CG
08.07.2017, 16:39
Тогда вот другая причина, - чтобы не путать с финансовым понятием банк. А что общего у микросхем памяти со скамейками?
А словосочетание "банк данных"? Имхо здесь используется примерно такое лексическое значение как: хранилище чего-либо однородного.
Долго думал, что ответить, вы видимо темой ошиблись.
ой, ну надо же - потратить массу времени на ответ.
- - - Добавлено - - -
Вот только пользователей Альтаира тут походу никогда не было...
собссна, собрать готовый Альтаир - это куча гимора похоже.
TomaTLAB
08.07.2017, 17:20
хранилище чего-либо однородного. Этому удовлетворяет и банка и банк :)
А вообще было бы не плохо свести куда нибудь в одно место "словарик" терминов и зафиксировать хотя бы в рамках данной темы такие понятия как "банк" (банка), "страница", "окно" и т.п.
А то в разных контекстах они порой перемешиваются между собой.
Вот в этих книжках (раз (https://yadi.sk/d/xufw6V453Ks9Nk), два (https://yadi.sk/d/a4xjbfiW3Ks9Xb)) есть множество интересных идей вообще и по управлению памятью в частности.
Нет смысла ставить БИС ПДП и кучу микросхем обрамления для реализации логики, что к тому же бесполезно нагружает шину
Вот бездельники из Интел, придумали бесполезную вещь. А мне теперь придется мучиться и паять сороконожку и кучу логики.
А нагрузка на шину при чем? Выводы с третьим состоянием разьве что в результате конфликта шину грузят.
Вот бездельники из INTEL, придумали бесполезную вещь (имеется ввиду КР580ВТ57)
Ну не скажите. Эта микросхема ПДП тратит на пересылку одного байта всего 4 такта, причём, т.к когда активна ПДП, то CPU находится в "захвате шины", то такт ПДП может быть иным, чем такт CPU. Т.е может быть выше, чем такт CPU (т.е столько, сколько ПДП физически тянет при максимальном оверклоке), что ещё более ускоряет пересылку. Если мне не изменяет память (ЕМНИП), то КР580 при программной петле пересылки блока тратит 56 тактов на байт, что в 14 раз медленнее. А Z80 ЕМНИП в командах типа LDIR тратит 26 тактов на байт, т.е вдвое быстрее КР580, но всё-равно намного медленнее, чем ПДП.
Но для применения ПДП для загрузки блока в 16 байтов из основной банки в дополнительную скорость вообще не играет роли. Тем более, что такая процедура выполняется всего один раз по сбросу. И ставить только для этого ПДП глупо. Кроме того придётся использовать микросхему Z80-DMA (не факт, что она удобна для КР580) или же ПДП типа 8237. Потому что ставить для этого ВТ57 бесполезно, т.к она не умеет качать данные из памяти в память, а делает обмен только с портами.
А нагрузка на шину при чём? Выводы с третьим состоянием разве что в результате конфликта шину грузят
Может быть доп.корпуса (особенно КМОП) и не особо грузят выходы током, т.е в статике. Но в динамике важен не только ток нагрузки, а ёмкость входа. Каждый доп.вход любой микросхемы грузит шину паразитной ёмкостью порядка 20 пф.
Убедился в этом на практике. В РК86 слабая шина. РК86 с извлечённой из панельки доп.ППА D14 без сбоев "скворчит" с кварцем 30 МГЦ (такт КР580 ~3.1 МГЦ), а если поставить назад ППА, то уже тянет только кварц 26...27 МГЦ, а если добавить ещё и РК-КНГМД, где нагрузка шины также всего в один вход ППА (потерь на ёмкость соединит.проводов нет, т.к РК-КНГМД вставляют в слот, а с длинными косами идущими к КНГМД ситуация будет ещё хуже), приходится снижать кварц ещё ниже до ~22...24 МГЦ. Тут тоже два ППА всегда в 3-ем состоянии, т.к КНГМД используется только когда работает RK-DOS, а доп.ППА D14 только когда работает программа прошивателя УФ-ПЗУ или идёт печать на принтер.
Нагрузка на шины при том, что чем она больше, тем меньший оверклокинг удастся выжать.
barsik, учитывая все перечисленные вами плюшки, я и собирался пощупать 8237, в том числе и для межбанкового обмена.
Каждый доп.вход любой микросхемы грузит шину паразитной ёмкостью порядка 20 пф.
Да, это я не учел. Но я в любом случае собирался буферизовать шины, а не экономить на спичках, как в РК. Все-таки не те времена. Сейчас БИС из МК кр580 продают на вес.
И да, почему ПДП обмен должен происходить только при сбросе? Им можно постоянно самые разные задачи решать.
Немного отвлекусь от железа: на сборнике Walnut Creek CPM CD-ROM (November 1994) нашел интересную прогу, позволяющую запускать код для 6502 на процессорах 8080/Z80. http://www.retroarchive.org/cpm/cdrom/CPM/6502/6502SIM.LBR если кому интересно. Да и вообще сборник полезный. http://www.retroarchive.org/cpm/cdrom/ и https://archive.org/download/cdrom-1994-11-walnutcreek-cpm/November_1994_Walnut_Creek_cpm_cdrom.iso
Error404
13.07.2017, 11:58
barsik, есть еще возможность перемещать данные между банками при помощи ПДП или одновременная запись в несколько банков.
Тоже понравилась идея одновременной записи в несколько банков. Но вопрос как реализовать это аппаратно, если используются ОЗУ-шки размером более 64к (например когда в компе всего одна SRAM или планка DIMM) на 512кб или более, и страницы памяти все в ней (выбираются по 64к старшими адресными ножками ОЗУ)?
- - - Добавлено - - -
Немного отвлекусь от железа: на сборнике Walnut Creek CPM CD-ROM (November 1994) нашел интересную прогу, позволяющую запускать код для 6502 на процессорах 8080/Z80. http://www.retroarchive.org/cpm/cdrom/CPM/6502/6502SIM.LBR если кому интересно.
А что можно было бы в нем запустить? как там с терминалом и т.п.? Если кто-то пробовал, поделитесь - никогда не имел дела с 6502.
Но вопрос как реализовать это аппаратно, если используются ОЗУ-шки размером более 64к
Ну только если несколько корпусов использовать. Редко может потребоваться писать одновременно больше, чем в 2 страницы. Еще вариант для основной памяти использовать объемы не более 64к, а для рамдиска любые подойдут. Но мне милее всего режим, когда ПДП будет перебрасывать данные между страницами: чтение из одного банка, а запись в другой. В этом случае объем чипа не важен.
нашёл программу, позволяющую запускать код для 6502 на процессорах 8080/Z80
Напрямую это невозможно, т.к разная система команд. А значит используется принцип эмуляции, когда программа анализирует код команды (естественно таблично) и для каждой команды выполняет подпрограмму имитирующую работу команды 6502. Конечно, благодаря тому, что у 6502 очень мало регистров такая эмуляция проста (а вот эмулировать наоборот 8080, не говоря уже о Z80, на 6502 очень сложно, т.к 6502 вообще не поддерживает 16-ти разрядность). Но любая эмуляция фатально тормозит, и минимум в 25-30 раз. Поэтому для использования на Z80 программ (или просто участков кода) написанных для 6502, желательно иметь такт Z80 в 20 МГЦ. Что уж говорить о КР580 с тактом 2.5 МГЦ. При таком такте программа 6502 эмулируется с эквивалентым тактом в 100 КГЦ.
Кстати, есть C8080A с тактом в 4 МГЦ, которые очень удобны для турбирования СПЕЦИАЛИСТА, в котором базовый такт 2 МГЦ. Тогда СПЕЦИАЛИСТ легко турбировать на 200% (когда ОЗУ тоже на 4 МГЦ) или на 142% (по схеме с WAIT, когда ОЗУ остаётся на низком такте).
Разработчики 6800 не стремились увеличивать число регистров, введя вместо этого адресацию ZERO-page, потому, что затем они выпустили 6802 в котором 128 ячеек ZERO-page включено внутрь микропроцессора, т.е получился микропроцессор с реальными 128+3 регистрами (что ускорило работу), а 6502 в итоге так и остался со своими всего 3-мя регистрами.
Впрочем, это не трагедия, т.к благодаря адресации в ZERO-page в 6502 есть как бы 256 регистров, т.е реально программист для 6502 не особо страдает от малого числа регистров непосредственно внутри CPU (потеря только на том, что команды для ZERO-page не однобайтовые, а двухбайтовые, т.е реально лишь вдвое медленнее, чем регистровые команды). Но 6502 неудобен от того, что он вообще не поддерживает 16-ти разрядность и нет адресации к ОЗУ через (HL) или (IX), (IY).
OrionExt
13.07.2017, 14:53
Напрямую это невозможно, т.к разная система команд. А значит используется принцип эмуляции, когда программа анализирует код команды (естественно таблично) и для каждой команды выполняет подпрограмму имитирующую работу команды 6502 ...
Да все возможно. Другой вопрос как это работает и кому это интересно в 21 веке.
У меня тоже жил на Орионе, маленький ZX-Basic:v2_dizzy_punk:
https://www.youtube.com/watch?v=D4Oc9zyedwo
- - - Добавлено - - -
А, Enterprise 128 при своей жизни аппаратно-программной эмуляции продвинулся дальше всех.
- - - Добавлено - - -
А, вот пример Franky projects SMS<>MSX. Из нашей жизни.
https://www.youtube.com/watch?v=sNyKAOKoFUI&feature=youtu.be
- - - Добавлено - - -
Эмуляция это отлично. Тема то не про это:D
Напрямую невозможно прогнать код для 6502 на 8080
Да всё возможно. Другой вопрос как это работает
Нет невозможно. Не говорите ерунды. Код неродного процессора можно только эмулировать. А адаптация программы от другого компьютера с тем же процессором - это совсем из другой оперы. Речь о разных процессорах и не модифицированном оригинальном коде.
Не надо вставлять видео, это неудобно смотреть, если скорость Интернета не 100 мбод, а лишь 3.6 мбод, вставляйте скрин-шоты. И вставка видео загромождает и тормозит просмотр страницы.
OrionExt
13.07.2017, 15:29
Нет невозможно. Не говорите ерунды. Код неродного процессора можно только эмулировать. А адаптация программы от другого компьютера с тем же процессором - это совсем из другой оперы. Речь о разных процессорах и не модифицированном оригинальном коде.
Код можно эмулировать, экран можно эмулировать. Можно аппаратных штук добавить. Все в наших руках.
Не надо вставлять видео, это крайне неудобно смотреть, если скорость не 100 мбод, а лишь 3.6 мбод, вставляйте скрин-шоты. И вставка видео загромождает и тормозит просмотр страницы.
Видео как видео. Меняйте свое корыто. Моему компу 10 лет (после апгрейда до SSHD винта, жизнь в Win качественно улучшилась).
barsik, хватит, я прошу)
а где такая программа эмуляции 6502? не видел ни разу.
на Apple][ было проще - плата с z80 на борту.
OrionExt
13.07.2017, 16:03
Шынни, ох, тут тонкий троллинг. Сделай эмуляцию.
Читал твою статью "MSX-C: мое разочарование" – это экспертное заключение. Люди не один год пилили софт. Писали мануаналы. А тут – вдруг эксперт, вот так родился и пропал.
Люди не один год пилили софт. Писали мануаналы. А тут – вдруг эксперт, вот так родился и пропал.
Да да, ещё там один деятель начал обзор языков программирования под CP/M... Опомнился. Эмули которые у меня более 20 лет есть как, он нашёл с трудом, разобраться тоже было ему трудно. Языки позапускал, покомпилил и выдал своё "экспертное заключение". Я только посмеялся над такими "обзорами". Это называется тихий ужас. Полный непрофессионализм.
Шынни, ох, тут тонкий троллинг. Сделай эмуляцию.
оно мне надо?
Читал твою статью "MSX-C: мое разочарование" – это экспертное заключение.
ну хоть кто-то читает(:
HardWareMan
13.07.2017, 17:37
Но 6502 неудобен от того, что он вообще не поддерживает 16-ти разрядность и нет адресации к ОЗУ через (HL) или (IX), (IY).
Потому, что там нет этих самых HL, IX и IY. Зато там есть, как вы сказали, 256 псевдорегистров (Zero Page) и работают такие команды:
LDA ($10),Y
STA ($20),X
Что дает нам EA как ($0010)+Y и ($0020)+X соответственно. Это аналогично IX+d/IY+d, только этих самых IX/IY получается может быть 128. Так-то!
Зато там есть, как вы сказали, 256 псевдорегистров (Zero Page)
это не псевдорегистры, а адреса 0-255, другая адресация и выполнение побыстрее.
Это аналогично IX+d/IY+d, только этих самых IX/IY получается может быть 128. Так-то!
ничо подобного. если Y=255, то сложение будет с 255 а не с -1.
HardWareMan
13.07.2017, 18:06
это не псевдорегистры, а адреса 0-255, другая адресация и выполнение побыстрее.
Поэтому и псевдо, потому как ОЗУ но с укороченным циклом доступа.
ничо подобного. если Y=255, то сложение будет с 255 а не с -1.
Что даже лучше, ведь можно указывать на начало массива в 256 элементов, а не на его середину.
shurik-ua
13.07.2017, 18:24
выходит 6502 скорее RISC чем CISC ?
Error404
13.07.2017, 18:35
выходит 6502 скорее RISC чем CISC ?
Если брать самое общее определение RISC, то и 6502, и 8080 - оба RISC. А вот Z80 - уже скорее CISC чем RISC. :) ИМХО.
HardWareMan
13.07.2017, 19:51
Error404, 6502 вообще RISC. У него каждый такт активность на шине. А вот 8080 если и натягивать на RISC, то только очень медленный. Активность шины каждые 3-4 такта.
shurik-ua
13.07.2017, 20:20
и 8080 - RISC
https://www.youtube.com/watch?v=j978pwMZjmE
В 6502 нет нет адресации через (HL), зато есть команды:
LDA ($10),Y
STA ($20),X
Что дает нам EA равный $0010+Y и $0020+X соответственно. Это аналогично IX+d...
Хотя я ориентируюсь на 6800, где всего 6 методов адресации, а не 13, как в 6502 (т.к вообще не понимаю зачем нужны некоторые извращённые адресации имеющиеся в 6502), но даже мне ясно, что это совсем не одно и то же. Точнее пример неудачный. Это же адресация в пределах ZERO-page 0000...00FF, т.е в массиве всего в 256 байт, причём половина ZERO-page во всех 6502-машинах уже занята на системные ячейки ROM-BIOS (а выше 100H лезть бесполезно, там стек). Есть команда дающая нечто похожее на адресацию через (HL), - абсолютная адресация с индексированием через X или Y. Но она медленная (т.к трехбайтовая) и к тому же только в пределах 256 байт. А на практике часто надо просматривать большие массивы, например в Allocation Table (VTOC) или FAT больших дисков. Адресация через (HL) с последующим INC HL это делает без проблем, а с убогим 6502 нечто подобное (но дико тормозное) можно сделать только используя самомодификацию кода. Лучше бы разработчики 6502 вместо извращённых методов адресации добавили бы адресацию с автоинкрементом, как это сделано в грамотных процессорах.
Впрочем, может быть именно такие "заморочки и извращения" и привлекают любителей 6502. Кроме того, для устранения таких недоработок системы команд 6502 давно написаны стандартные процедуры. Например, как команду 16-ричного сложения (DAD у КР580) заменить подрограммой 6502. При разработке 6502, для ускорения работы, уделяли внимание лишь сокращению числа тактов на команду (хотя это всё-равно не RISK). Поэтому у 6502 было много фанатов и, например, первые мобильные телефоны имели систему команд 65C02.
HardWareMan
14.07.2017, 11:27
Точнее пример неудачный. Это же адресация в пределах ZERO-page 0000...00FF, т.е в массиве всего в 256 байт, причём половина ZERO-page во всех 6502-машинах уже занята на системные ячейки ROM-BIOS (а выше 100H лезть бесполезно, там стек).
http://img0.reactor.cc/pics/comment/Anime-Anime-%D0%93%D0%B8%D1%84%D0%BA%D0%B8-Tonari-no-Seki-kun-1202594.jpeg
Господин теоретик, который никогда не писал ни под что, кроме этого вашего Z80! Я вам дал команду с Indirect Indexing Addressing:
http://savepic.ru/14824067.png
Zero Page хранит адрес базы, а не сами данные. Индексный регистр - быстрое смещение в пределах 0...255. Но и базовый адрес легко корректируется через RMW команду с Zero Page. RMW команда с Zero Page на 6502 работает практически так же как и у i8080, если у них одинаковая тактовая частота (например 1,7МГц). Хватит уже лезть туда, где не только не знаете, но и не собираетесь даже учиться/принимать как есть, примеряя все на свой этот Z80. Запомните, есть в этом мире много процессоров кроме Z80.
- - - Добавлено - - -
И еще, оригинальный пост (http://zx-pk.ru/threads/27613-kompyuter-dlya-cp-m-formulirovka-tz.html?p=919576&viewfull=1#post919576):
http://savepic.ru/14862981.png
Ваша цитата:
http://savepic.ru/14848645.png
Куда делись скобки? И не надо меня лечить за "да ты же изменил пост!!!111". Я изменил вчера в 20:45, вы ответили сегодня в 03:11. Я понимаю, что многие слоупочат, но не на 7 часов же! Вы опять взялись за старое, править цитаты людей под себя?
shurik-ua
14.07.2017, 12:04
думаю видосик разрешит ваш спор
https://www.youtube.com/watch?v=fWqBmmPQP40
с 9:20 про адрессацию
Эксперты набижали(:
$0000-$00FF - Zero Page и никакие "косвенные регистры"
$0100-$01FF - занято стеком.
адресация ZeroPage позволит избежать самомодифицирующегося кода, например, LDA ($CB),Y, $CB/$CC- мл./ст. байты адреса
HardWareMan
14.07.2017, 12:28
Шынни, именно это я ему и привел в пример, но он такой "ZP и так мала, чтобы хранить там 128 байт массива, когда остальные 128 уже заняты системой". :)
ZP называем "псевдорегистрами" не только за быстрый (скорее сокращенный) доступ, но и за RMW.
лапаморда.джпег
Система иногда использует нулевую страницу, например OS Atari, Apple, Oric.
уехали не в туда, речь пошла об цпм.
Error404
14.07.2017, 14:28
Error404, 6502 вообще RISC. У него каждый такт активность на шине. А вот 8080 если и натягивать на RISC, то только очень медленный. Активность шины каждые 3-4 такта.
В первых (самых базовых) определениях RISC (что я и подчеркнул особо в своем предыдущем посте) не было требования выполнения инструкций за 1 такт. А было сокращение команд за счет сокращения способов адресации и отказа от сложной математики (целью было упрощение под распараллеливание/конвейеризацию), и отказ от инструкций выражающихся в микроциклы/микрокод процессора (опять же сложная математика или например LDIR у Z80), тоже потому что сложно конвейеризируется.
- - - Добавлено - - -
Поэтому в сравнении с Z80, i8080 вполне себе недо-RISC (отсутствие конвейера этого не отменяет).
- - - Добавлено - - -
Другое дело, что i8080 не имеет преимуществ перед Z80, это - да. Но мы же их просто на попадание в определение меряем, i8080 и 6502 туда укладываются, а Z80-нет.
HardWareMan
14.07.2017, 16:38
Error404, достаточно знать аббревиатуру: Reduced Instruction Set Computer и Complex Instrucion Set Computer. И сразу все встанет на свои места. Но потом этого стало не хватать и придумали новое определение:
На самом деле, термин «сокращённый» в названии описывает тот факт, что сокращён объём (и время) работы, выполняемый каждой отдельной инструкцией — как максимум один цикл доступа к памяти, — тогда как сложные инструкции CISC-процессоров могут требовать сотен циклов доступа к памяти для своего выполнения.
Господин теоретик, который никогда не писал ни под что, кроме этого вашего Z80
Это не так. Хотя методы адресации 6502 и мнемоники давно забыл, отчего и не понял какой метод адресации в этих командах. Т.к сейчас читаю книгу "L.Leventhal, 6800 Assembly Programming Language", где просто нет такого метода адресации, оттого и ошибся.
И для 6502 я программировал. Но было это давно (в конце 80-тых, начале 90-тых). И в памяти ничего не сохранилось, кроме впечатления, что на Z80 программировать на порядок проще. Я программировал в мини-ассемблере и на простом ассемблере LISA, т.к изучал ассемблер по книге Морера, где именно LISA и требуется. Макро ассемблер освоить не смог, потому что ДОК-ов было не найти (Интернета не было). Читал и красного Мымрина и "Программирование 6502 для ПРАВЕЦ-82" (на болгарском) и уроки по программированию в болгарских журналах и разобрался в исходнике ROM-BIOS Apple-II с комментариями (в Apple-II Refrence Manual). И сам спаял плату Apple-II (их выпустили в одном местном НИИ). Я даже написал двухпроходный кросс-ассемблер 6502 для Z80 на ОРИОНЕ и эмулятор 6502 на Z80. А чтобы написать эмулятор надо знать ассемблер получше, чем просто для программирования на нём.
Но Вы тоже не знаток 6502, т.к тоже ошиблись. Потому что EA для указанных команд вычисляются по разному. У Мымрина эти команды названы индексно-косвенной адресацией по X и косвенно-индексной адресацией по Y, а вот в болгарской литературе это называется понятнее - косвенная адресация с предварительной индексацией по X и косвенная адресация с последующим индексированием по Y. И сразу всё ясно, когда и к чему прибавляется индекс. В первом случае EA это (X + 2-й_байт) а во втором случае это: (Y) + 2-й_байт. Здесь скобки имеют смысл как в мнемонике Z80, т.е говорят о том, что операнд берётся из ячейки заданным даннным адресом.
И даже используя такую адресацию программа на 6502 будет тормознее, т.к модернизация адреса в ZERO-page не намного быстрее, чем модификации кода самой команды с абсолютной адресацией. Точно также это не одна команда INC HL, а сначала увеличение одной ячейки памяти, затем проверка флага CY, и если надо увеличение и старшего байта. Просто команды адресуемые в ZERO-page не трёхбайтовые, а двухбайтовые, что немного быстрее.
Литература:
У.Морер. Язык Ассемблера для персонального компьютера Apple-II. — М.: Мир, 1987.
М.П.Мымрин. Конструкция, применение, программирование ПЭВМ "Агат". - М.: Машиностроение, 1990
PS. Прекратите выкладывать видео. С браузером 2-3-х летней давности это не посмотреть, так что я это не вижу. Это текстовый форум, а не видео конференция. Администрации сайта следует срочно запретить выкладывать видео.
PPS. HardWareMan, у Вас время опережает московское на 2 часа.
barsik, зачем Вы заблуждаете молодежь?(:
HardWareMan
14.07.2017, 20:14
Литература:
У.Морер. Язык Ассемблера для персонального компьютера Apple-II. — М.: Мир, 1987.
М.П.Мымрин. Конструкция, применение, программирование ПЭВМ "Агат". - М.: Машиностроение, 1990
Учитесь использовать первоисточник:
http://savepic.ru/14813939.png
PPS. HardWareMan, у Вас время опережает московское на 2 часа.
На 3, но как это повлияет на сказанное? Оба времени я назвал по местному и разница между ними практически 7 часов.
зачем Вы заблуждаете молодежь?
Да тут вроде и нет особо молодых и неопытных. Да и не было у меня такой цели. А если случайно и ввёл читателей в заблуждение, то надеюсь, что Вы как раз и сможете меня поправить.
Оба времени я назвал по местному
Учитесь использовать первоисточник
Удивился потому, что думал, что Ваш город не в Сибири, а в московском часовом поясе где-то на юге. В 1989-94 была доступна только отечественная литература, т.к Интернета не было и для изучения нужно читать учебники для начинающих, а не РТМ.
Что-то обсуждение от темы уходит. Казалось бы, причем тут 6502?
Что-то обсуждение от темы уходит
Извините, если считаете, что уходит. А rw6hrm знает, что это не так, т.к он использует CP/M-80 (для КР580) на своём компьютере с 65C02 (спросите у него как).
на своём компьютере с 65C02 (спросите у него как)
кстатида
http://forum.6502.org/viewtopic.php?f=1&t=4376
не слышал, что для AppleIIgs был cp/m
Подтверждаю, работает. Про скорость не скажу, ибо не в курсе, как медленно должна работать СР/М на 8080 xD. Но мне с 5 МГц 65С02 вполне нормально. Упоминал я о программной прокладке тут, http://zx-pk.ru/threads/23276-quot-ayusha-quot-kontroller-na-6502.html?p=805353&viewfull=1#post805353. Прога для 8080 думает, что она работает с нулевого адреса, реально она располагается с 200Н. Пока недостаток системы один - 64К минус 512 байт с начала, минус ПЗУ в верхних адресах, минус УВВ, итого для работы доступно максимум 36-42К, что слегонца некомфортно...
Просто своим постом я хотел сказать, что уже в те времена можно было взаимно эмулировать процессоры 8080 vs. 6502, но это была инфа на любителя. Мои извинения, раз это вызвало нехилый холивар ;)
Про скорость не скажу, ибо не в курсе
Зато я скажу.
5 МГЦ 65C02 эквивалентны, как минимум, 10 МГЦ Z80. С учётом того, что это не полноценный эмулятор и экран и порты эмулировать не надо, то эмуляция тормозит в ~20 раз. Итого имеем CP/M-систему с тактом ~500 КГЦ. Для работы файловой системы и использования системных программ типа компиляторов этого достаточно (но игры будут тормозить). Например, эмулятор CP/M Z80MU для PC (написанный Joan Riff, 1987) на PC XT давал эквивалентный такт в 250 КГЦ и ничего, всем хватало, даже для текстовых редакторов. Эмулятор РК86 на ОРИОНЕ-Z80 имеет такт в 100 КГЦ и тоже нормально, даже большинство игр прекрасно играются. Вы легко получите скорость CP/M в 1 МГЦ, если замените 65C02 на 65C802 (он внутреннее 65C816 кроме адресации лишь в 64К, вместо 16 мб), вставляется прямо в панельку взамен 65C02 и он более скоростной.
Т.к ДОС для 6502 (с исходником) найти трудно, то использовать ДОС для неродного процессора оправдано, особенно если ДОС используется только как файловая система, позволяющая запускать программы для родного процессора. Но можно было решить ту же задачу аппаратно, поставив как сопроцессор Z80. Сделав так, чтобы он работал только для прогона кода CP/M, а прикладные программы - по-прежнему, для основного процессора 65C02.
http://i93.fastpic.ru/big/2017/0715/ed/341944fb08b7b4072c366fb2ca8a5aed.jpg
поставив как сопроцессор Z80. Сделав так, чтобы он работал только для прогона кода CP/M, а прикладные программы - по-прежнему, для основного процессора 65C02.
Не требуется. Если внимательно читали описание эмулятора, то позволяется выполнять коды обоих процессоров. Поэтому у меня драйвера УВВ писаны на коде 6502 дабы убыстрить работу.
эмуляция тормозит в ~20 раз
...ну не знаю, как код размером менее килобайта может так тормозить. Медленнее - оно да, но не настолько же...
ДОС для 6502 (с исходником) найти трудно
GekOS, A/65 - это подобия СР/М, но не более, ибо прикладного софта кот нарыдал.
Есть и второй недостаток, о котором я говорил - большинство нормального софта для СР/М писано для Z80. Так что если мы говорим о более-менее юзабельной машинке, то в базе должен стоять именно этот процессор. О 8080 можно забыть, растереть и развеять по миру. Ну, разве что, потренироваться на создание периферии, чем вполне удачно занимается Xrust.
у меня драйвера УВВ писаны на коде 6502 дабы убыстрить работу
Понятно, что CP/M-BIOS нет смысла писать на КР580, ведь его пишет сам пользователь (тот кто адаптирует CP/M под конкретное железо).
эмуляция тормозит в ~20 разну не знаю, как код размером менее килобайта может так тормозить. Да, медленнее, но не настолько же !
Скорость 0.5 МГЦ это вполне быстро. Тормозит обычно не ДОС, а вывод на графический экран. Речь об эмуляции, а она просто не может быть быстрой. Правда мои данные относятся к эмуляции КР580 на Z80. Полная эмуляция тут тормозит в 24 раза, И это ещё без эмуляции флага Parity (а с этим тормоз ещё больше). Если не отлавливать экран и порты (т.е если в коде нет к ним обращения, что как раз и имеет место в коде ДОС), то будет быстрее, - ~15-20 раз. Число торможения 20 реально означает, что в среднем каждая команда КР580 имитируется 20-тью командами Z80. Возможно, благодаря ZERO-page достигается чуть более быстрая эмуляция, но не в разы.
Вообще, всё очень подозрительно. Эмулятор должен иметь бОльший объём. Считайте сами. 244 команды, в среднем надо по 10-15 команд на эмуляцию каждой. Даже если считать, что команд 78 (т.е тот же код используется для разных операндов), то всё-равно получится, как минимум, 2 килобайта. Как программа размером менее одного килобайта может делать такие чудеса, как прогонять на процессоре неродной код. Мне так и хочется сказать, что такое невозможно. Сообщите идею на которой работает Ваш код. Вы разбирались в программе? Понятно, что это эмуляция, но какой принцип?
Каким образом программа определяет, что следующий фрагмент надо прогонять, как родной код 6502? Думаю в этом месте вставляется какой-то код, что в КР580 работает, как NOP или недокументированная команда КР580 (одна из 12).
А что Вы скажете о замене 65C02 на более скоростной 65C802?
Этот процессор редкий, т.к не пользовался популярностью. Хотя и был специально разработан для апгрейда систем на 65C02. Но в реальности ускорение делали не заменой процессора, а установкой в панельку CPU целой платки, т.к увеличив в 2...5 раз такт CPU, но оставив ОЗУ и В/У на старом такте, выигрыш получался всего в ~25%, а надо было в разы. Поэтому и приходилось на платке Турбо-акселератора ставить 64 кб скоростного ОЗУ, а раз есть платка, то тут не проблема применить полноценный 65C816, т.к тогда несовпадение цоколёвки роли не играет. Хотя 65C802 выпускали не менее 7 лет, но тираж был маленький. Поэтому, т.к достать 65C802 намного труднее, то апгрейд 65C02 обычно делают с помощью несовместимого по ногам 65C816.
А что Вы скажете о замене 65C02 на 65C802?
Что есть под руками, то и ставил. Что проще достать, то и применял. Зачем ориентироваться на мифические чипы?
Каким образом программа определяет, что следующий фрагмент надо прогонять, как родной код 6502?
Правильно думаете. Если читали документ, то на странице 8 есть раздел THE "CALL6502" OR "C65" OP-CODE. Вызов п/п для 6502 осуществляется командой СВхххх.
Тормозит обычно не ДОС, а вывод на графический экран.
Вооооо! Фтопку графику!, для СР/М она не нужна от слова абсолютно! У меня вывод осуществляется в порт - кинул комп туда байт и более о нём не беспокоится. Потому тормоза и незаметны (хотя графика в ограниченных объёмах присутствует).
всё очень подозрительно. Эмулятор должен иметь бОльший объём.
Читайте документ (хоть и на аглицком, но со словарём-то можно). Оптимизация кода там божественная. Современным программерам поучиться надобно. Кстати, обратный симулятор весит 48К, что показательно ;)
У меня вывод осуществляется в порт - кинул комп туда байт и более о нём не беспокоится.
ANSI поддерживаются хоть?
ANSI поддерживаются хоть?
Уже ж давал ссылку, http://www.qsl.net/rw6hrm/html/8bitdisp.htm . Полностью поддерживается оригинал, http://searle.hostei.com/grant/MonitorKeyboard/index.html , только на восьмибитной шине.
Ладно, я тут кратенько набросал своё видение ТЗ компа для СР/М. Личное имхо, можете не соглашаться. Потихоньку и неспешно часть из описанного реализую тут, http://www.qsl.net/rw6hrm/html/z80.htm
1. Процессор. Четыре варианта, на выбор.
1.1. 8080. Базовая версия, под которую возможен запуск по меньшей мере половины наработанного ПО. Медленный (хотя кому как), разгон невозможен.
1.2. 8085. Такая же базовая программная версия (ПО только для 8080), но поскоростнее предшественника.
1.3. Z80. Всё наработанное ПО может быть запущено (с учётом остального железа ессно). Такт до 20 МГц (также с оглядкой на железо). Много готовых драйверов для стандартного железа. Самый оптимальный выбор для новоделов.
1.4. 6502 в симуляции 8080. На любителя. Программная модель 8080 (плюс ПО для 6502), скорость работы примерно аналогичная. Для попробовать и и для модернизации готовых контроллеров, если нет желание ваять что-то новое. Недостаток - порты в/в, отображённые на память и зарезервированные ячейки в верхних адресах, что уменьшает доступную память. Хотя есть грязный хак, позволяющий использовать адресацию портов в/в и неиспользуемых ячеек в ПЗУ.
1.5. Более старшие контроллеры на базе описанных выше пп 1.1 - 1.3. Нужно сверяться с даташитом, могут вылезти проблемы недостатка памяти.
2. ОЗУ/ПЗУ.
2.1. В ПЗУ только загрузчик в начальных адресах, отключается после загрузки ОС, отдавая всю доступную память. Возможно динамическое питание.
2.2. ОЗУ 64К минимум. Лучший по энергетике вариант - одним чипом 64К (кэш древних материнок) или два чипа по 32К. Делать страницы/банки - смысла нет, поскольку мало использующих это программ. Конечно, если кто-то использует базы данных, то дополнительные 512К один чипом не помешают в качестве РАМ-диска для увеличения скорости работы; для удобства из лучше переключать страницами по 16К. Но, поскольку таких извращенцев мало, доп. страницы или РАМ-диск есть блажь. Использование динамического ОЗУ возможно, но по энергетике и обвязке неинтересно, разве что готовый блок от чего-либо использовать.
3. Ввод/вывод.
3.1 Только и исключительно как порты ввода/вывода для увеличения доступного ОЗУ. По той же причине отдавать ОЗУ под экранную область нет никакого смысла - это и уменьшение ОЗУ, и уменьшение скорости работы устройства.
3.2. В продолжение разговора о выводе на экран. Графический экран также блажь. Программ под графику минимум, соответственно ориентироваться на них нет смысла, для графики есть другие машины. Процессор должен выкинуть инфу в порт, а что происходит далее его не должно интересовать. Чтение из области экрана также мало кому нужно, поэтому можно пренебречь. Железо: на настоящее время оптимальным является не сборка на рассыпухе, а применение однокристальных чипов типа Атмеги. Разработок на любой вкус, как чисто текстовых, так и с ограниченной поддержкой графики, достаточно. Подключение может быть как терминальное (через СОМ-порт для простых машин или в процессе наладки), так и встроенное, но с терминальной программной моделью. Как особое имхо оговорю, что для начала лучше использовать композитный вывод, чем на ВГА. Оно как-то проще и чаще встречается.
3.3. СОМ-порт обязателен, чисто для связи с внешним миром. Можем подключить модем, старшую машину или такой же простой контроллер для обмена информацией. Если экранный вывод не встроенный, то наличие второго СОМ-порта также возможно. Достаточно использовать одну стандартную скорость, к примеру, 9600; хотя выбор скоростей будет только приветствоваться.
3.4. Носители. В настоящее время делать совместимость по носителям нет никакого смысла, поскольку обмен информацией через носители между машинками такого класса никогда осуществляться не будет, для обмена инфой есть СОМ-порт. Тут, конечно, каждый может применить то, что у него есть: дисководы (есть много программных драйверов под известные чипы и железо целиком), флеш-карты любого типа. Для меня оптимумом оказался выбор CF-карт, поскольку и подключается просто, и заменяется на HDD, и готовые драйвера под Z80 есть. Хотя кому-то проще использовать SD/ММC, но драйвера под них ещё писать надо. Есть вариант чипа с восьмибитной шины на носители USB, но опять же, программных драйверов нет. Для желающих иметь копии длительного хранения можно посоветовать наличие магнитофонного узла. Он может быть как программный (легко слизать из ЮТ-88 как железо, так и п/п в/в), так и железный, как довесок к СОМ-порту. В последнем случае возможна запись на ленту как в преобразованном аналоговом виде (канзасский стандарт, NRZ, скорость до 2400), так и в прямом цифровом (direct saturation, скорость до 9600).
РОМ-диск с системными программами также возможен, ибо ПЗУ необходимого объёма (512К и выше) легко доступны из трупов современных машин.
3.5. Клавиатура. Идеальный вариант - ASCII-ввод. Можно сделать ASCII-клаву полность самостоятельно, либо использовать Apple][-переходник с PS/2. Почему идеальный - процессор особо не занимается, по прерыванию он просто считывает введённый байт и продолжает заниматься своим делом. Можно использовать и программную модель, подключая PS/2-клаву через УАРТ с внешней синхронизацией (надеюсь, что товарищ Xrust поделится с нами результатами своиз опытов), либо через небольшой переходник на рассыпухе (используйте поиск в "Разном"). Тут уж процессору придётся чуток поработать для определения кода нажатой клавиши, а также программно определять, на каком языке мы пытаемся с ним разговаривать.
Кстати о "языке", то бишь о кодировке. Базовый вариант СР/М общается с нами только латиницей и кириллицу не розумиет. Нам повезло, что наличие кириллицы важно только в устройствах ввода/вывода, соответственно можно прошить нужный нам знакогенератор в терминале и нужную таблицу для клавиатуры. Для текстовой совместимости со старшими машинами предлагаю (уже не в первый раз) кодировку СР866 (альтернативную). Про всякие КОИ-хх забыть как о страшном сне. Обращу внимание - речь идёт о новоделах, а не реанимировании трупов типа "Специалиста" к новым реалиям.
3.6. Звук. Вот тут фиг его знает, вроде бы как на начальном уровне и не нужен.
3.7. Прочие порты, в т.ч. параллельный. В начальной конфигурации не обязателен, если только не подключаем к нему SD/ММC или картридж в виде РОМ-диска. Наличие ВИ53 в виде отдельного порта будет полезным как для реализации переключения скоростей п. 3.3, так и для звука п.3.6.
4. Конструктив. Тут на любителя однозначно. Можно сразу забульбенить одноплатную машинку, но это в том случае, если мы однозначно гарантируем её полную работоспособность после сборки и мы не будем эту плату в последующем раширять. Для остальных можно рекомендовать использование шины S-100. Это позволит раскидать машинку на отдельные блоки, в последующем из модернизировать или расширять конфиг на все случаи жизни, в том числе делать много процессорные системы.
Это кратко.
shurik-ua
15.07.2017, 12:48
в том числе делать много процессорные системы.
а система разве многозадачная ?
Лучший по энергетике вариант - одним чипом 64К (кэш древних материнок) или два чипа по 32К
ойвэй. у Enterprise128 и у Амстрада 4 по 16К. Все подключаются по-разному и никому это не мешает.
- - - Добавлено - - -
3.2. В продолжение разговора о выводе на экран. Графический экран также блажь.
терминальное мышление. Не проще ли сделать текстовый режим и простой режим? у Amstrad PCW все через графический режим, тормозно и ужасно.
- - - Добавлено - - -
либо использовать Apple][-переходник с PS/2
к чему такие сложности?
- - - Добавлено - - -
Базовый вариант СР/М общается с нами только латиницей и кириллицу не розумиет.
все зависит от ПО.
а система разве многозадачная ?
Ну МР/М мы запускать не будем, а вообще обычная связка мастер-слейв, о чём нам говорил barsik, более чем привычная народу из начала 90-х.
текстовый режим и простой режим?
Эм... а чем они различаются? ;)
к чему такие сложности?
Один ПИК, какие там сложности, http://knzl.de/ps2-keyboard-for-apple-ii/
все зависит от ПО.
От ПО тоже ничего не зависит. Хотите сказать, что есть что-то русскоязычное, на что следует обратить внимание? Все наши проги есть адаптации зарубежных к конкретному железу. Общались мы с автором Микро-80/Р-86 товарищем Поповым, с его слов, какая кодировка есть в терминале, такая будет и в СР/М-машине.
Кстати о ПО - большинство зарубежного ПО рассчитано на работу с семибитной таблицей символов. В некоторых программах (редко, но есть) восьмой бит является служебным. Поэтому я и ратую за наличие зачатков кодировки именно в УВВ, а не в ПО. Это более универсально, даёт нам возможность не кромсать и не "адаптировать" имеющийся софт для работы, а просто выбрать нужный и не особо требовательный к железу.
у Enterprise128 и у Амстрада 4 по 16К
Да я же и говорю, что
разве что готовый блок от чего-либо использовать.
или то, что есть в волшебных ящичках под столом. Или кому хочется траходрома с разводкой кучи м/с памяти вместо одной-единственной. Хотя если использовать шину S100, то ОЗУ всё равно желательно ставить на отдельную плату и разновесёло с ней забавляться.
Кароч говоря, каждый, при наличии желания, может собрать свою машинку. У кого амбиции преобладают над желаниями, должны думать и о других на тему лёгкости повторения (разводки платы, доставания комплектухи). У кого амбиции и желания зашкаливают, могут сделать сразу максимально возможный вариант ;) , но, кмк, надо сначала делать минимальный рабочий вариант, только после этого фаршируя его дополнениями.
- - - Добавлено - - -
терминальное мышление.
Не спорю. Чем проще в реализации (программной и железной), тем лучше. Я ленив ;)
Эм... а чем они различаются?
текстовый и графический. для Tandy TRS-80 есть CP/M и семиграфика - хватает по уши.
Чем проще в реализации (программной и железной), тем лучше. Я ленив
вооот. Страшно представить, что из ТЗ вырастет.
Страшно представить, что из ТЗ вырастет.
Да пусть хотя бы какая-нить пуська для начала будет. Остальное прикрутим. А то так и останется исключительно интерес, без реализации...
3. Ввод/вывод.
Здесь лучше оставить оригинал, т.е. терминальный ввод/вывод. Используется всего один СОМ-порт и для вывода инфы и для "опроса" клавиатуры (сразу в ASCII-кодах)
Для остальных можно рекомендовать использование шины S-100.
Как по мне, S-100 - избыточна. Половиной сигналов никто никогда не воспользуется. Я для своей машинки пока развел кросс-плату с такими сигналами
D0-D7 - процессор (буфер)
A0-A15 - процессор (буфер)
#WAIT - процессор
#BUSREQ - процессор
#BUSACK - процессор
#INT - контроллера прерываний -> процессор
#RESET - процессор
#HALT - процессор
#WR - процессор
#RD - процессор
#MREQ - процессор
#IORQ - процессор
#DRQ0-#DRQ2 - устройства ввода/вывода -> контроллер ПДП
#DACK0-#DACK2 - контроллер ПДП -> устройства ввода/вывода
#INT0-#INT7 - устройства ввода/вывода -> контроллер прерываний
CPU_CLK - процессор
#M1 - процессор
+5В
Общ.
По идее, должно хватить на все обозримые домашние поделки. Питание только +5В, +12В для дисководов и т.п. - подается внешне, остальные напряжения (типа -5В) сейчас проще реализовать прямо на плате DC-DC преобразователями. Если сигнал #INT использовать только в ближайшем слоте от процессора (контроллер прерываний будет устанавливаться только в этот слот), то на остальных слотах эту линию можно использовать для других задач.
Здесь лучше оставить оригинал, т.е. терминальный ввод/вывод.
Мои разработки клавы и дисплейного блока, на которые давал ссылки ранее, работают по терминальному принципу (даже п/п для СОМ-порта не меняются, за исключением инициализации), так что прокладку в виде тормозного СОМ-порта можно исключить или оставить только для внешнего обмена.
А про избыточность S-100 то ясно, Ваш список вполне оптимальный.
Использование динамического ОЗУ возможно, но по энергетике и обвязке неинтересно
С КР580 ещё может быть, а вот с Z80, который сам регенерирует ОЗУ, и на непредельных частотах их применять вполне оправдано. Да и по энергетике динамические ОЗУ жрут большой ток только в момент когда /CAS равен 0, а без этого они жрут мало. Средний ток потребления при непредельной частоте - на уровне обычных TTL. Если надо оверклочить CPU на 5 МГЦ и выше, то следует применять скоростные SIMM, а не РУ5 или РУ7
Только и исключительно как порты ввода/вывода для увеличения доступного ОЗУ
Подавляющее большинство CPU в мире не имеют команд IN/OUT. Это извращение от инженеров Intel, - просто ненужное усложнение системы команд, вызывающее бесполезный расход деталей. IN/OUT ввели лишь для того, чтобы убедить клиента, что этот процессор "круче". И если портов меньше, чем пальцев на руке, то так ли уж сильно сократит это адресное пространство. Кроме того команда LD с адресацией через HL вдвое быстрее, чем IN/OUT.
Графический экран также блажь. Программ под графику минимум, соответственно ориентироваться на них нет смысла
Встречный вопрос. Мы что живём в середине 70-тых, когда ещё никто не слышал о цвете и графике, а нортон и окна на экране ещё не были изобретены. На кой хрен нужна система, к которой Вы не сможете написать свой красивый нортон и будете вынужденно заменять его POWER-ом? Может быть Вы и псевдографику и инверсию знакомест объявите блажью?
отдавать ОЗУ под экранную область нет никакого смысла - это и уменьшение ОЗУ, и уменьшение скорости работы устройства
Насчёт затраты адресного пространства. Кто мешает, как во "Львове" сделать экран программно включаемый в адресное пространство только когда нужно делать вывод на экран. А для чего не хватит скорости? Да пока Вы передаёте по тормозному последовательному интерфейсу один символ, программно можно вывести на экран 100 символов. Какое тут ускорение?
Вообще идея терминала в компьютере, где хоть что-то говорят о скорости - нонсенс. Вы потому и не хотите иметь графику, потому что в идее терминала по последовательному интерфейсу она фатально тормозит. Терминал в оригинале это АЦПУ (клавиатура плюс принтер). Устройства TTY применяли в 50-тые и 60-тые и там скорость передачи была 75-110 бод. А в начале 70-х в моду вошли терминалы с текстовым дисплеем, отчего скорость подняли аж до 300 бод (а это целых 40 символов в секунду). И всем этого хватало. Даже тем, кто работал из дома по телефонной линии с майн-фреймом. Цитата: "In 1975, the 110 Bods ASR33 Teletype®, with automatic reader and punch options, was the most frequently used terminal". И только когда, уже в начале 80-тых, появились первые телефонные сети и BBS, и понадобилась скорость, то скорость последовательного интерфейса довели до физического предела модема для ТЛФ-линии в 2400 бод (это предел при тональном кодировании, многочастотные методы уже в 90-тые подняли этот предел до 14.400 и выше).
И кроме того к ЭВМ подключался не один терминал, а десятки и сотни. Так к VAX подключалось несколько компьютерных залов, в каждом из которых было по 25-30 машин. Вот откуда взялись и почему использовались терминалы. А сколько терминалов будет подключаться к Вашей машине?
Когда пришли микропроцессоры в 1974-ом, то по инерции поначалу также применяли терминалы. Т.к они уже просто имелись в наличии. Но когда Стив Возняк в начале 1976 показал, что гораздо удобнее иметь экран встроенный внутрь компьютера, то идея терминала в применении к ПК умерла в одночасье. Ни одного народного компьютера с терминалом после 1976 не появилось. Терминал удобен лишь как вспомогательное средство (его оставили даже в MSDOS).
Насчёт альтернативной кодировки я высказался в начале темы. При желании можно сделать плавающую кодировку. Для этого достаточно ввести флаг кодировки. Тогда вывод производится в соответствии с включённой кодировкой, а в п/п-мме CONIN д.быть автоматическая перекодировка.
Вы потому и не хотите иметь графику, потому что в идее терминала по последовательному интерфейсу она фатально тормозит.
Просьба - прочитайте внимательно мои последние посты и найдите, где я там хоть что-то говорил о последовательном интерфейсе применительно к видеовыводу (исключая ссылки на чужие конструкции). Больше повторяться не буду. Мышление - да, терминальное. Но по параллельному интерфейсу. И с частичной поддержкой графики, кстати. Ссылки в предыдущих постах.
Может быть Вы и псевдографику и инверсию знакомест объявите блажью?
Не надо передёргивать. Нет программ - незачем выпендриваться с графикой. Писать новые никто не будет.
Если надо оверклочить CPU на 5 МГЦ и выше, то следует применять скоростные SIMM, а не РУ5 или РУ7
Да ради Дога, повторюсь: кому хочется испытать эротику с разводкой восьми (минимум) корпусов - оно пожалуйста. Но что-то никто не горит особым желанием хотя бы один корпус развести (или хотя бы поделиться свежими наработками). Только товарищ Xrust потихоньку проводит программные и аппаратные экзерсисы.
При желании можно сделать плавающую кодировку.
Никаких проблем. В связи с тем, что если какой-либо новодел и будет внезапно собран, то он останется в пользовании самого автора, который сам будет решать, каким образом результаты его работы будут совместимы с чем-либо ещё.
Подавляющее большинство CPU в мире не имеют команд IN/OUT.
...угу, и это "подавляющее большинство" не работает под СР/М. И список из ныне живущих начинается и оканчивается на 6502 (включая клоны и прародителя).
На кой хрен нужна система, к которой Вы не сможете написать свой красивый нортон и будете вынужденно заменять его POWER-ом?
Ой. Вы, наверное, давно не интересовались существующим для СР/М софтом. Аналог NC уже есть (и не один, кстати), и он прекрасно работает на псевдографике, как и его бессмертный прародитель. Даже в цвете, синеньком таком. И PIP-ом открыто можно больше не пользоваться. Хотя лично мне консоли хватает выше крыши.
...не хочу никого обидеть, но просто давайте положим руки на интимные/нежные части наших тел и признаем: вся эта ветка есть не более чем обычный разговорный шум. Делать СР/М-совместимую машинку если кто и будет, то чисто из-за спортивного интереса, а не для работы, как это было лет тридцать назад. Поэтому обсуждать что надо или не надо можно до бесконечности, в любом случае делаться всё будет только и исключительно исходя из подножного корма/подстольных запасов. А уж про написание программ - извините дважды. Они уже все написаны. Хотя никто не запрещает, также исходя из спортивного интереса, написать что-то свежее.
Я высказался. Спасибо.
давайте положим руки на интимные части наших тел и признаем: вся эта ветка есть не более чем обычный разговорный шум
Естественно.
Тема-то не о том, что будут сделаны платы для массового потребителя. Топик стартер попросил совета. И как раз это (раздачу советов) все кому не лень и делают. Каждый высказывает своё мнение, исходя из собственного опыта и предпочтений. Лично я высказываюсь о том, как бы сделал для себя. В ходе дискуссии обдумываются идеи. И если они и не полезны топик стартеру, это не важно. Люди читают этот форум в основном, чтобы получить моральную поддержку и почерпнуть идеи, которые они могут в дальнейшем использовать в своём творчестве.
Кстати, меня CP/M уже не интересует. Интереснее и, кстати, не намного сложнее, чем адаптировать CP/M, написать собственную ДОС. Главное тут, - придумать концепцию (уже опробовал для ДОС три концепции).
Как я понимаю, дикое возражение вызывает цвет и графика. Но согласитесь, что хорошие потребительные качества изделия желательны. Даже, если нортон монохромный, но в машине есть цвет, то кто мешает установить жёлтые буквы на синем фоне.
Цвет ничуть не утомляет при разработке ПО и легко встраивается в чужие готовые программы. Ведь с цветом никто не работает по железу. Используются ESC-последовательности. Достаточно их выкинуть на CONOUT и цвет включился или изменился. И последующие буквы выводятся на экран нужным цветом на нужном фоне. Интерфейс с программой остаётся чисто текстовым. Усложнений программирования нет. Просто на другом конце линии в терминале (или в самом компьютере, но в драйвере) работает не простейшая подпрограмма вывода символов (как в ПЗУ РК86), а 12-ти килобайтовый цветной оконный графический драйвер.
Если работать с графикой и цветом по железу, то передача по линии фатально тормознёт. Но при цветном графическом драйвере с управлением ESC-кодами как раз идея терминала оказывается выгодной. Для вывода просто символов терминал не даёт ускорения, а вот для графики и цвета уже иначе. Т.к обслуживание графики и цвета намного более ресурсо-затратно. Потому и разделение на два процессора, основной и графический - выгодно. Для основного CPU интерфейс остаётся простейшим, т.к для графики требуется передавать по линии всего на несколько символов больше, отчего цвет и графика никак не тормозит.
Писать новые программы никто не будет
Можно и не писать новое. Можно взять чужие исходники и адаптировать. Но о чём речь? Где применить цвет и графику? Применительно к CP/M - реально речь только о нортоне. Желательно и текстовый редактор, но тут лучше SuperText не сделать при всём желании (и он кстати, в КОИ-8, - на CP-866 его не переделать, что начисто исключает эту кодировку).
Для НЕ-CP/M нужно чуть больше программ - это нортон, текстовый редактор и макроассемблер. Но, если эти программы у Вас один раз написаны, то сделать версию для другой ДОС или другого железа это работа, максимум, на один день.
Насчёт наличия исходников нортона. Тут нужен именно корректный для ДОС (т.е не по железу) и в принципе, у меня такой нортон есть (использует драйвер, но переделать в корректность не сложно). Я видел на немецких сайтах исходники нортонов. Но не стал даже смотреть, во-первых даже, если они корректные, то псевдографика и управляющие коды отличаются. Т.е в любом случае придётся адаптировать. А во-вторых, разбираться в чужих листингах, - противно и неинтересно. Но трудоёмкость адаптации низка. На написание нортона, текстового редактора или новой ДОС на ассемблере с нуля уходит до месяца (а на разработку макроассемблера три месяца). Трудоёмкость адаптации на порядки меньше.
кому хочется испытать эротику с разводкой, минимум, восьми корпусов ОЗУ - пожалуйста трахайтесь
Зачем разводить всё? Выгоднее распилить платы старых компов на фрагменты.. Фрагмент с ОЗУ привинчивается на 4-х винтах M2 (лучше M1.5), трудоёмкость меньше, чем монтаж ОЗУ статики типа w24512. В макетах я не использую МГТФ, хотя имею даже МГТФ-0.03. Ранее был самозалуживающиеся ПЭПЛОТ и ПЭВТКЛ. Теперь, увы, обычный ПЭЛ-0.2. Нет вороха проводов снизу. Макетируемая конструкция свинчивается из кусков готовых плат, что резко сокращает трудоёмкость проводного монтажа. Проблема лишь нехватки маленьких винтов и гаек (чтобы свинтить что-то новое, чтобы их добыть, приходится разбирать старые конструкции).
Аналог NC уже есть (и не один, кстати), и он прекрасно работает на псевдографике, как и его бессмертный прародитель. Даже в цвете, в синем
Видел пяток чужих нортонов. Но все они по железу (некорректные к ДОС). Дайте пожалуйста ссылку хоть на один корректный нортон (можно даже только сами коды, дизассемблировать не проблема).
Поэтому обсуждать что надо или не надо можно до бесконечности
В этом и заключается задача темы.
Делать СР/М-совместимую машинку если кто и будет, то чисто из-за спортивного интереса, а не для работы, как это было лет тридцать назад
На мой взгляд такой компьютер уже есть. Это ОРИОН-128 с Z80 и 512К ОЗУ. Его архитектура позволяет получить CP/M с 60К TPA, цветом и графикой (хотя быстродействие 3.75 МГЦ маловато).
shurik-ua
19.07.2017, 01:02
Выгоднее распилить платы старых компов на фрагменты.
Месье знает толк в извращениях )
А по теме - почему никто не юзает цп/м в плис на девбордах - там и з80 на 100+ МГц и памяти выше крыши ?
Юзают, не особо массово конечно, ибо не канонiчно и исключительно спортивный интерес, да и толку в этом нет особого... Юзабельного софта под такие скорости всё равно нет.
Это извращение от инженеров Intel, - просто ненужное усложнение системы команд, вызывающее бесполезный расход деталей.
Как по мне - приятное извращение. ))) Расход деталей - такой же как и при адресации УВВ как ячейки памяти.
Встречный вопрос. ... На кой хрен нужна система, к которой Вы не сможете написать свой красивый нортон и будете вынужденно заменять его POWER-ом?
Встречный вопрос - "На кой хрен нужна система", где я должен еще что-то дописывать, кроме драйверов? Не забывайте, что разговор идет о CP/M. Лично меня устраивает весь набор софта, что есть и переделывать его нет никакого желания. Я сделал CP/M машинку как девборду для опробования программных и схемных решений, т.е. есть основная плата с процессором, памятью, последовательным портом (терминал) и жестким диском к которой подключается кросс-плата, в которую я планирую "тыкать" всякую всячину для исследований. Для всего этого вполне хватает стандартного вида CP/M и ассемблера.
А для чего не хватит скорости? Да пока Вы передаёте по тормозному последовательному интерфейсу один символ, программно можно вывести на экран 100 символов. Какое тут ускорение?
Тут не понял. Отрисовка 100 символов 5х7 в памяти будет быстрее одной "извращенной" команды OUT!?
Терминал удобен лишь как вспомогательное средство (его оставили даже в MSDOS).
100%! Как я уже написАл выше, если использовать такую машинку для собственных нужд, то терминала хватает с головой! И никакой графики не нужно, разве что, если очень нужно вывести какой-то график или картинку, можно использовать как внешнее устройство ISA карточку или графический дисплей, коих сейчас в продаже не мерено и на любое разрешение.
---------------
удалил дубль
чет задвоилось сообщение...
Отрисовка 100 символов 5х7 в памяти будет быстрее одной "извращенной" команды OUT!?
Во-первых, по одному символу никто не передаёт и если уж так считать, то вывод одного символа в текстовый экран это тоже одна команда. Во-вторых, речь не о графическом экране, для которого как раз передача по линии и использование второго процессора для видеовывода имеет смысл. Я тоже делал CP/M машины и именно с текстовым адаптером, т.к убедился в нехватке скорости для вывода текста на графической ЭВМ. И процессор при использовании терминала вовсе не освобождается для другой работы. Потому, что по одному символу в час не передают, а передают целую строку. После вывода символа в ВВ51 командой OUT, процессор вовсе не свободен, а занят в цикле опроса готовности. По готовности, процессор выводит очередной символ. Стандартная скорость терминала 9600 бод. С учётом программного обслуживания, старт стоповых битов и пауз, за секунду передаётся ~800 символов. Таким образом, на вывод одного символа расход времени вовсе не 11 тактов команды OUT, а 1/800 секунды, т.е 1.25 МСЕК. При такте CPU в 4 МГЦ один маш.такт длится 0.25 МКСЕК. Итого за 1.25 МСЕК процессор в машине с текстовым адаптером с пользой выполнит 5000 машинных тактов. Если учесть, что все остальные побочные расходы программы текстового вывода одинаковы, то и получается то, что я написал.
А выигрыш терминал даёт вовсе не на командах OUT, а на обслуживании управляющих кодов, т.к их обслуживание выполняет не ЦП, а терминал имеющий свой процессор или в старых системах ~250 TTL-микросхем логики (в терминале СМ-1800 было ~10 плат, на каждой по ~35 корпусов 155-той серии). Но всё-равно система с экранным ОЗУ в адресном пространстве быстрее и гибче, чем терминальная.
На кой хрен нужна система, где я должен еще что-то дописывать, кроме драйверов? Не забывайте, что разговор идет о CP/M
Есть IBM PC, где ничего не надо дописывать. Рэтро системы именно потому и ценны, что только для них несложное любительское программирование имеет смысл. Только здесь любой "некомпетэ" может за несколько дней освоить ассемблер и начать писать программы. Именно в этом ценность, а вовсе не в том, чтобы собрать музейный экспонат и поставить на полку. Если я что-то делаю из железа, то только для того, чтобы писать для него программы, потому что писать программы на порядок интереснее, чем трахаться с железом, что дико ненавижу. Цель вовсе не железо и очень неприятно, что без возни с ним не обойтись. С большим психологическим сопротивлением заставляю себя возиться с железом, отчего могу этим заниматься лишь несколько дней, после чего вынужден отдыхать 2-3 недели. Оттого у меня сейчас все аппаратные работы продвигаются крайне медленно. Пытаюсь вспомнить с какой стороны держать паяльник. А какая ДОС, это вообще без разницы. CP/M была удобна 25 лет назад, потому что имеет компиляторы. А сейчас и это не играет роли, т.к удобнее программировать на PC.
Выгоднее распилить платы старых компов на фрагменты Месье знает толк в извращениях
Да, знаете-ли, доставляет эстетическое наслаждение уничтожение очень ценных и редких плат старых компьютеров. А если серьёзно, то это было в начале 90-тых и эти платы потеряли тогда всякую ценность. Уж лучше распилить и хоть как-то использовать, чем выбросить. Вот, что удалось тогда распилить. 3 платы ZX-48К, 3 комплекта ИРИШИ, 3 платы СПЕЦИАЛИСТА, 2 платы ОРИОНА, 2 платы КОРВЕТА (обе дохлые), ПРАВЕЦ-16 (дохлый), 3 платы Apple-II с грудой периферии, импортная ЭВМ (на MC6802, ОЗУ 4116+4164), целый СМ-1800 (еще осталось 10 нераспиленных плат со 155-той серией), 10 плат от ЕС ЭВМ, несколько плат от ДВК, не полностью спаянный ПРАВЕЦ-8М, чистые платы ОКЕАН-240.
CP/M была удобна 25 лет назад, потому что имеет компиляторы. А сейчас и это не играет роли, т.к удобнее программировать на PC.
Именно. Но, немного отвлекусь от текущего обсуждения для описания, почему я взялся за ваяние СР/М-машинки. Некоторые пункты могут быть спорны, но вот как-то так...
1. Шум от писюков. Вентиляторы, приводы,... Ноутбуки не устраивают по тем же причинам. Тишины хочется.
2. Размеры. Для писюка нужно хоть какое-то место. Да, есть форм-фактор мини-ITX, но... В настоящее время моя машинка потихоньку втискивается в корпус от миниатюрного спутникового приёмника.
3. Экран. Для работы с ВГА мне нужны очки. Для работы с ЖКИ-телевизором 15" и 80 символами в строке не нужны.
4. Всё, что мне нужно - это текстовый редактор, СУБД и Бейсик на все остальные случаи жизни. С ФТП и почтой разберёмся позже, для СР/М это не проблема. Т.е. запрограммировал/настроил один раз и всё, только дальнейшая работа.
5. Получение удовольствия. Вроде последний пункт, но как бы основной ;) Расшифровывать не буду.
А для общения достаточно планшета.
А зачем СР/М-машинка вам? ;)
...речь не о графическом экране...
Значит я Вас неправильно понял, просто много слов было о графике.
Только здесь любой "некомпетэ" может за несколько дней освоить ассемблер и начать писать программы.
Вот-вот, а не дописывать или "адаптировать" чьи-то программы под свои нужды. Я не собираюсь переделывать ни СР/М ни ассемлеры ни,тем более, писать какие-то цветные коммандеры. Повторюсь. Есть платформа, на ней запущен СР/М - это основа, которая не переделывается, а вот все мои "железные" фантазии и эксперименты - вот здесь пишу софт.
Если я что-то делаю из железа, то только для того, чтобы писать для него программы...
Странная логика - написать программу, что бы под нее сделать железку! Обычно наоборот...
... писать программы на порядок интереснее, чем трахаться с железом...
Каждому своё. Я, например, больше люблю с железом ковыряться и это ничуть не мене интересно, чем писать программы под это железо.
Цель вовсе не железо
А я думаю, исходя из названия темы, как раз наоборот.
пятница, рыбный день
Пропаганда религии на сайте запрещена (в православии среда и пятница являются постными днями, в которые запрещается употребление мяса).
А при социализме рыбным днём был четверг.
Автором «рыбного дня», введённого 12 сентября 1932 года постановлением Наркомснаба СССР «О введении рыбного дня на предприятиях общественного питания», был А. И. Микоян. Позднее, 26 октября 1976 года, ЦК КПСС издал повторное постановление о введении «рыбного дня». За рыбным днём был закреплён постоянный день недели — четверг. Многие предприятия общественного питания в этот день не включали в меню никаких мясных блюд, что вызывало недовольство у рабочих и служащих. Тому, что рыбный день был назначен именно на четверг, было дано чёткое обоснование, подкреплённое статистикой и расчётами, сводящимися к тому, что реализация рыбы именно в этот день будет максимальной.
не собираюсь дописывать или "адаптировать" чьи-то программы под свои нужды
А придётся, если нет желания иметь всего несколько программ, а точнее, лишь POWER, SuperText и DBase 2.50. Посмотрите на сайтах CP/M, там 90% программ это компиляторы ЯВУ. 10% это улучшенные клоны CP/M, утилиты, крутые текстовые редакторы и игры. Причём, если компиляторы универсальны, то игры и всё остальное надо адаптировать для конкретной ЭВМ. Игры с исходниками адаптировать несложно. А вот графические программы адаптрировать намного сложнее.
Поэтому CP/M вообще имеет смысл только для использования компиляторов. Или для использования от неё лишь только самой файловой системы для хранения и запуска программ конкретного компьютера. Поэтому, строго говоря, делать CP/M компьютер с нуля несовместимый с какой-нибудь платформой, где есть программы и при этом не имея задачи писать свои программы, - вобще бессмысленно. С пользой на таком компьютере можно будет использовать только вышеперечисленные программы. А узко специальные SuperCalc, MultiPlan и т.п - вообще бесполезны. CP/M игр в кодах - всего 20-25 и и-то их надо адаптировать. Даже бейсик игр во много раз больше.
Я не собираюсь переделывать ни СР/М ни ассемлеры ни, тем более, писать какие-то цветные коммандеры. Повторюсь. Есть платформа, на ней запущен СР/М - это основа, которая не переделывается. А вот все мои "железные" фантазии и эксперименты - вот здесь и пишу свой софт.
Ну переделывать CP/M уже не надо. На немецких сайтах я нашёл, как минимум, три заменителя BDOS (все для Z80), которые просто заменяют модуль BDOS в обычной CP/M 2.2, что даёт даты у файлов и ещё какие-то плюсы. Ассемблеры переделывать тоже бессмысленно. Во-первых, есть M80, лучше которого даже сейчас ничего нет, а во-вторых, я скачал более десятка самодельных ассемблеров CP/M (их делали бедные люди, кто не мог потратить 180...400 USD на покупку Microsoft M80). Свой макроассемблер нужен только для других ДОС, не CP/M, где вообще нет компиляторов, т.к самое минимальное ПО, что должно входить в ДОС - это текстовый редактор, макроассемблер и отладчик.
Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.
Странная логика - написать программу, что бы под нее сделать железку! Обычно наоборот...
Именно, всегда наоборот.
Я, например, больше люблю с железом ковыряться и это ничуть не менее интересно
Точно менее. И намного. Я тоже любил возиться с железом, пока не узнал правды. И из железа хоть какой-то интерес представляет разрабатывать своё, а не повторять чужое (особенно неинтересно повторять чужие конструкции на ПЛИС и МК). А при разработке своего всё-равно без программирования не обойтись.
barsik,
Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.
Вот с этого момента давайте подробнее. Я хотел бы узнать ваше мнение, совместимость с какой платформой была бы предпочтительна? Интересует в частности реализация графики.
Вот такие идеи сейчас вертятся в голове по организации памяти. Промежуточный итог, так сказать. Отдельную страницу 64к выделяем системе, отдельную страницу(ы) для приложений, отдельную страницу для обработчиков прерываний (автоматически подключается по сигналу подтверждения прерывания). Ну и как ранее писал, возможен обмен между страницами через ПДП контроллер ВТ37. А он, как я понял из ДШ, может и полностью управление перехватить, а может и по очереди с процессором делать свою работу. Как быть с графикой пока не решил. Т.к. конструкция будет модульная и с открытой архитектурой, то надо предусмотреть установку видеоадаптеров различных конструкций. А значит, скорее всего, им при необходимости будут выделены свои страницы памяти.
OrionExt
24.07.2017, 21:52
Хм… Чет ничего не понял со страницами по 64Кб. А как же склеенный (общий) участок адресуемой памяти. Кто будет этим добром по 64К управлять?
Просто ни разу не встречал для 8-бит ЦПУ таких конфигураций памяти, чтобы страницы целиком по 64Кб щелкались. Кусочек памяти должен быть не переключаемый.
Будет кусочек ПЗУ, который так же можно отключить при желании. Например, предварительно скопировав его в нужные страницы ОЗУ при помощи ПДП.
OrionExt
24.07.2017, 22:21
Будет кусочек ПЗУ, который так же можно отключить при желании. Например, предварительно скопировав его в нужные страницы ОЗУ при помощи ПДП.
Хитро. А как же на языке Си писать. Там такие номера не пройдут. У нас ведь не х86.
Если уж делать страничную организацию памяти. То нужно смотреть в сторону менеджера памяти Z180. Даже у MSX c самым продвинутым движком управления памятью не всегда удобно по 16Кб щелкать. Надо меньше.
У нас ведь не х86.
Ну как бы поэтому на С никто особо и не пишет на 8-битках ) И для пользовательской программы это прозрачно будет. Все равно ей за пределы одной страницы лезть незачем. Этими делами будут TSR и ОС заниматься.
OrionExt
24.07.2017, 23:10
Ну как бы поэтому на С никто особо и не пишет на 8-битках )
Как не пишет? А как же Uzi, Fuzix, UZIX. Пускай не СP/M;)
А компиляторам такая модель памяти даже в страшном сне не присниться. ПДП это прекрасно. Но с моделью памяти точно не стоит паровоз изобретать.
Да и TSR написать далеко не тривиальная задача. Это уже высший пилотаж.
А как эта модель памяти связана с компиляторами? Для прикладной программы горизонтом является TPA. Как раз компилятору не надо думать об организации памяти. И для TSR все удобно сделано. По прерыванию автоматически подключается страница с TSR областью и можно особо не мучаясь обрабатывать прерывания и т.п. А можно и не пользоваться этой возможностью. Главное, чтобы эта возможность была и имела хотя бы минимальную программную поддержку на уровне ПЗУ BIOS. И этим практически любой желающий сможет воспользоваться.
Эта модель памяти очень проста и не обязывает программиста подстраиваться под систему. Нет жесткой страничной модели как в Спектруме или Орионе. Можно вызвав стандартную процедуру переместить участок памяти любого размера из любой страницы в любую. Можно один байт переслать, а можно и 64к. А процессор в это время в своей текущей странице будет заниматься своим делом.
Я хотел бы узнать ваше мнение, совместимость с какой платформой была бы предпочтительна? Интересует в частности реализация графики
Насчёт предпочтительности, т.е с точки зрения выбора платформы для которой было больше всего CP/M программ, ничего сказать не могу. Я немного знаю лишь о тех компьютерах, которые сам имею или имел, а о других компьютерах я знаю не больше любого другого. Понятно, что могу по памяти перечислить с десяток западных 8-ми разрядок, что у всех на слуху и упоминания на которых встречаются на сайтах ретро компьютеров и CP/M. Но не только не знаю сколько у каждого компьютера программ, но даже параметров их железа не знаю.
Я могу лишь высказать своё мнение о том, какую графику считаю оптимальной для себя. Опыт показал, что графика должна быть такой, чтобы допускать символы шириной в байт (вывод втрое быстрее, чем символы с шириной не кратной байту), а организация цвета такой, чтобы максимально упростить цвет для текста. Смешивать в одной плоскости цвет и графику (как в MDA XT) нет смысла, лучше две плоскости (возможно даже включённые в одном адресном пространстве). Что касается цвета для полноценной цветной графики, т.е возможности задавать цвет попиксельно, то это полезно только для игр.
Из этого получается, что оптимальным будет организация графики 512*256 (размер экранной плоскости 16К) и один режим цвета, позволяющий задавать два цвета в пределах 8-ми экранных точек. Т.о получается расширенный экран ОРИОНА в 16-ти цветном режиме.
поэтому на С никто особо и не пишет на 8-битках
На самом деле на СИ для 8-ми биток много писали, но увы, не у нас. Т.к когда наши 8-ми разрядки были популярны, то не было доступа к компиляторам. А когда в 1994-96 такое появилось, то профессионалы (разработчики ПО в КБ заводов выпускающих 8-ми битки) уже исчезли, а любители просто не успели освоить компиляторы ЯВУ. Я думаю, что главным ограничением использования СИ является не архитектура ЭВМ, а объём ОЗУ для компилятора и скорость прогона программы на СИ. ЯВУ не волнует архитектура машины. ЯВУ желательно сплошное ОЗУ максимального размера. А то, используется для интерфейса с драйвером экрана из другой банки некоммутируемый кусок ОЗУ или всегда включённое ПЗУ, - ЯВУ совсем не волнует. Я предлагал отказаться от некоммутируемого участка ОЗУ лишь из экономии, т.к без этого можно обойтись (хотя и за счёт усложнения программы).
Даже у MSX c самым продвинутым движком управления памятью не всегда удобно по 16Кб щелкать. Надо меньше
Вообще-то самый продвинутый диспетчер памяти для CPU с 16-ю адресами - в машинах DEC. Такой диспетчер ОЗУ с 8-ю окнами размером по 8К - не удастся использовать. ПК11/16 имеет в DOS многозадачность, т.е одновременно прогоняется много процессов, каждый из которых имеет полученный у DOS свой набор участков ОЗУ, который и включает в 8-ми килобайтовых окнах, в моменты, когда этот процесс активен. Если многозадачной ДОС нет, то бОльший смысл имеет коммутация по 60/64К.
Просто ни разу не встречал для 8-битных ЭВМ таких конфигураций памяти, чтобы переключались страницы целиком по 64 кб
Железо в ИРИШЕ позволяет коммутировать ОЗУ целиком по 64К, но так не делают, всегда общий кусок 16К остаётся для связи между картами памяти (из-за чего сокращается объём ОЗУ, т.к число карт памяти всего 4). У ИРИШИ диспетчер похож на MSX (в адресном пространстве коммутируются 4 окна по 16К), но, увы, управление этими окнами сделано не оптимально.
По прерыванию автоматически подключается страница с TSR областью
Круто.
Вообще, просто драйвер загружаемый в другую банку (например драйвер принтера или другой клавиатуры), это тоже TSR, но без прерываний. Они грузятся на вектора стандартных входов CP/M-BIOS.
Но раз речь зашла о TSR с прерываниями, т.е о резидентном процессе, то это значит, что речь о многозадачной DOS на прерываниях. Вот тут уж нельзя отказываться от некоммутируемой области. Иначе с прерываниями будут большие проблемы и сложное программирование. Причём в прерывании должна быть возможность считать текущую конфигурацию (чтобы иметь возможность восстановить по выходу из INT). В ОРИОНЕ не предусмотрели возможность считать текущий номер банки, отчего сложно делать многобанковое ПО с прерываниями (т.к надо долго извращаться, чтобы узнать в какой банке нас застало прерывание).
TomaTLAB
25.07.2017, 00:21
Можно один байт переслать, а можно и 64к. А процессор в это время в своей текущей странице будет заниматься своим делом.
Эмм... Две (как минимум) изолированные магистрали? Или как? Чтоб одновременно, и не прибито гвоздями к растактовке? Мысля интересная и что-то напоминает... из древнего...
Будет кусочек ПЗУ, который так же можно отключить при желании. ИМХО не стоит делать специфические "кусочки". Тут ПЗУ там еще что.
Пусть они все будут равноправные и гомогенные, что ли, однородные. Как в MSX, только действительно, как говорит OrionExt, несколько помельче.
Хотя конечно один придется сделать несколько равноправнее других :) на момент загрузки, по крайней мере.
автоматически подключается по сигналу подтверждения прерывания Вот это интересная идея, надо обмозговать. Тоже что-то из области мини-ЭВМ, наверно...
- - - Добавлено - - -
И ещё надо выяснить у ИРИШИ или у MSX более грамотно в адресном пространстве коммутируются 4 окна по 16К.
У "Ириши" нужно посмотреть вспомнить как сделано. А у MSX точно можно сказать, что MMU (а их там по факту аж два, переключалка слотов и собственно маппер ОЗУ) там "может копать, а может не копать", т.е. как хочешь так и щелкаешь.
Другое дело, что "щелкнув" не подумав можно все "поломать".
OrionExt
25.07.2017, 00:27
А как эта модель памяти связана с компиляторами?
Компиляторы пишутся под конкретные модели памяти, а их не так уж и много на 8-битках. А точнее две small и banked (large). Small - это обычная сплошная до 64Кб. Banked (large) – пример на рисунке.
https://lh3.googleusercontent.com/ODUkbsz77wxAbiTe8RHuflBcenLRim8V_zTwRNadSyCoVX71Ux C6lTg3FO2cIr074qN9BaEw8mJVnp4ha5DgMBovoKoduEmXrlWp IXoKQ9QyVvPZNDPHPoImGXBbNS0lPX4qAd74ewdrXuD2M-Pe1yhxMQuL55yDOT-j4XknqfOeqRw4rmLTb4heOR8TEo5sfUIJjl0LRFdXZmRV7a65z ZldVWWodrC1AMrWJw3uuK_WZbS17pTD4Qb--AEOROC3NdX0opt6S6Sgq0Y18XDv-LvTLrGgvYiadq1XKtyQpUax59XgTMNwBx7x7vndwwRuqmjGYAg pj6YO596UQwh1coYHMapjBvpbxqOC8-EZ7ttzcrm8-e4VEjTFvonjTl_r1xesBUaWsoUU1IApJO62lEIc0KhEILjHtwK AOPYEJUnW3PtMFun1WrZ07egw94aLav1ARkaglNXL9CTP9_RQ7 9yIlboZcO7Ycef6OxeLJ8ycctXRJbKw0YYd8CrmnkYgHkAxbqd xc2iWdNnMo1dKlEJOONLQ7pJ5v5R5eDuKFOFl66JCroitiaRBW nRWgvKd62iVDpqoCXWxi_9jbzxtt9dYYPclAjAI6luEU6DVSaw 8XfcVw197dW2U3wWwaDbJdrcJt-39Vdn9sSPuYexhXzsLm1VnUzO57dyA-mPiF_6QOA=w600-h342-no
А процессор в это время в своей текущей странице будет заниматься своим делом.
Ну, так глубоко не копал. А разве такое возможно для ПДП и ЦПУ? Шина та у них общая. Это надо арбитр для доступа к памяти делать (прозрачный доступ) или дуал-озу использовать.
TomaTLAB
25.07.2017, 00:31
т.е возможности задавать цвет попиксельно, то это полезно только для игр. Отнюдь. Первое, что в голову приходит, где можно гембель огрести с цветами - это отрисовка собственно графиков. Кривых на сетке координатной.
OrionExt
25.07.2017, 01:52
У ИРИШИ диспетчер похож на MSX (в адресном пространстве коммутируются 4 окна по 16К), но, увы, управление этими окнами сделано не оптимально.
Похож, да не похож. Даже смотреть не буду.
Штатный MSX диспетчер памяти у не окрепшего 8-ми битного ума (пользователя) может разорвать все шаблоны:D:D:D
Максимальный объем адресуемой памяти 64Мб !!! (4096Kb x 16 slots). И все это тасуй, как хочешь в четырех окнах по 16Кбайт.
- - - Добавлено - - -
Чутка соврал. За вычетом ПЗУ – 56Mб.
TomaTLAB
25.07.2017, 10:01
Чутка соврал. За вычетом ПЗУ – 56Mб.
И это если использовать только "каноничный" маппер ОЗУ. А если слегка отойти от стандарта (как это сделано напр. в маперах ПЗУ кариков) то...
Но раз речь зашла о TSR с прерываниями, т.е о резидентном процессе, то это значит, что речь о многозадачной DOS на прерываниях.
Я не рассматривал прерывания в этом качестве. Меня больше интересуют драйвера устройств. Вряд ли кому то нужна будет многозадачная ОС на подобной машине. Достаточно просто, КМК, реализовать в рамках CP/M переключение между задачами, если каждая из них будет работать в своем сегменте памяти. Например редактор и компилятор и переключаться между ними не загружая каждый раз заново. Можно даже придумать концепцию буфера обмена между задачами. Но создавать настоящую многозадачную систему? Думаю просто не найдется энтузиастов :)
Эмм... Две (как минимум) изолированные магистрали? Или как? Чтоб одновременно, и не прибито гвоздями к растактовке? Мысля интересная и что-то напоминает... из древнего...
Как я понял из даташита на 8237, там есть режим блочного и одиночного обмена.
Single Transfer Mode
In Single Transfer mode
the device is programmed to make one transfer only.
The word count will be decremented and the address
decremented or incremented following each
transfer. When the word count ‘‘rolls over’’ from zero
to FFFFH, a Terminal Count (TC) will cause an Autoinitialize
if the channel has been programmed to do
so.
DREQ must be held active until DACK becomes active
in order to be recognized. If DREQ is held active
throughout the single transfer, HRQ will go inactive
and release the bus to the system. It will again go
active and, upon receipt of a new HLDA, another
single transfer will be performed. In 8080A, 8085AH,
8088, or 8086 system, this will ensure one full machine
cycle execution between DMA transfers. Details
of timing between the 8237A and other bus
control protocols will depend upon the characteristics
of the microprocessor involved.
Block Transfer Mode
In Block Transfer mode the
device is activated by DREQ to continue making
transfers during the service until a TC, caused by
word count going to FFFFH, or an external End of
Process (EOP) is encountered. DREQ need only be
held active until DACK becomes active. Again, an
Autoinitialization will occur at the end of the service
if the channel has been programmed for it.
Если я правильно понял, то при одиночном обмене процессор и DMA попеременно занимают шину и при этом длительных затыков не возникает. Поправьте меня, если я что-то не так понял.
Компиляторы пишутся под конкретные модели памяти, а их не так уж и много на 8-битках. А точнее две small и banked (large). Small - это обычная сплошная до 64Кб. Banked (large) – пример на рисунке.
У меня модель памяти простая. Приложению выделяется сплошная страница. Если ему надо больше - пусть обращается к соответствующим функциям ОСи. В том то и особенность предложенной модели - она максимально совместима с обычными CP/M приложениями и не требует их доработки. Небольшого допиливания потребует только сама система, т.к. ее ядро будет размещено в отдельной странице и при запуске приложения оно (приложение) будет загружено в свою отдельную страницу.
ИМХО не стоит делать специфические "кусочки". Тут ПЗУ там еще что.
Пусть они все будут равноправные и гомогенные, что ли, однородные.
Я вообще считаю, что ПЗУ нужно только для загрузки системы. В нем должны размещаться специфичные для конкретного набора аппаратуры драйверы и программа конфигурации оборудования. Функцией этой программы должна быть настройка оборудования и компоновка БСВВ. Затем БСВВ загружается в верхнюю область ОЗУ, драйверы оборудования в страницу TSR, а ПЗУ отключается до следующего включения или перезагрузки.
OrionExt
25.07.2017, 18:42
Xrust, переубеждать вас не буду. Попробуйте на своей модели памяти, время покажет насколько это удобно. По мне таки нужен общий кусочек памяти. Чет вспомнил и решил найти такую штуку на MSX. Очень неплохой показатель 61K TPA на классической модели памяти.
http://www.z80.eu/cpm3boot.gif
OrionExt, а какие конкретно функции должен выполнять общий участок памяти?
balu_dark
25.07.2017, 20:30
очевидно служить буфером для передачи данных при переключении в другую страницу - имхо.
OrionExt
25.07.2017, 20:32
OrionExt, а какие конкретно функции должен выполнять общий участок памяти?
Ух. Список функций зависит от ОС. На вскидку стек, таблица прерываний, п/п менеджмента страниц памяти, таблицы вызова п/п Биос-а, ... В инете уйма примеров с подробными описаниями что да как и куда.
нужно смотреть в сторону менеджера памяти Z180.
Очень удобно и универсально на 3 регистрах, без излишеств, совместимость с 8-бит софтом (ОС, компиляторы и т.д). Никто не мешает сделать эту штуку на рассыпухе, пускай даже в упрощенной реализации.
OrionExt, насколько я понимаю, стек приложения никак не будет связан со стеком CP/M. Передача управления осуществляется простым переходом по адресу. Необходимо только скопировать при запуске программы область системных параметров и точки входа драйверов.
OrionExt
25.07.2017, 21:51
Точка вызова функций СРМ из программы одна CALL 5,X.
Не знаю, что ответить на остальное. Но что я знаю точно, работа с памятью выше 64К требует еще тех программных извращений. И этих извращений в разы меньше при использовании общего (не переключаемого) участка памяти.
Точка вызова функций СРМ из программы одна CALL 5,X
штоэ?
shurik-ua
26.07.2017, 11:12
CALL 5,X.
непонятная какаято команда - но имхо лучше использовать одну из команд RST x, где в рег А - номер интересующей ф-ции.
OrionExt
26.07.2017, 11:28
Точка вызова функций СРМ из программы одна CALL 5,X.
Хитро завернул:) Кто в теме тот понял.
ld c,func
call 5
Error404
26.07.2017, 12:16
OrionExt, а какие конкретно функции должен выполнять общий участок памяти?
На вскидку стек, таблица прерываний, п/п менеджмента страниц памяти, таблицы вызова п/п Биос-а
Основная закавыка тут в том, что если хочется сделать чтобы система была прозрачной для прерываний (в т.ч. и при вызовах в прочие сегменты) то надо помнить что при наступлении прерывания стек не переставленный в общую область может пропилить память в неожиданных местах. И таблицы векторов прерываний или п/п обработчика тоже может неоказаться в ожидаемом месте (и вообще всё улетит). А раз уж общая область необходима, то с ее помощью реализуемы и более удобные механизмы - например "длинные вызовы" (вызовы в другую страницу когда тамошняя "иностраничная" процедура может возвращать управления в вызывающую страницу просто командой RET, или сама тоже делать вызов в третью страницу, и вся цепочка потом выйдет стеком в нужные страницы просто по RET), межстраничные прересылки без DMA объемов больших чем влезающие в регистры. и т.п.
Если же согласны пропускать прерывания, то конечно, тупо ставим DI, делаем что надо в других страницах, потом выполняем EI.
CP/M BDOS system calls (http://www.seasip.info/Cpm/bdos.html)
Error404, как я уже говорил выше, хочу попытаться реализовать все обработчики прерываний в отдельной странице. Например, по сигналу "подтверждение прерывания" переключать специальную страницу памяти, где и будут расположены все обработчики прерываний. Выход из процедуры прерывания можно осуществить через специальный вектор, одинаковый на всех страницах и содержащий команду RET. Как-то так. Подробно этот механизм я еще не обдумывал, это пока просто идея, которую выношу на общее обсуждение. То же самое касается и наличия/отсутствия общего участка памяти. Его присутствие может дать как определенные преимущества, так и быть недостатком. Недостаток в том, что если он будет задан жестко, то он может стать помехой в плане совместимости, а если его положение и размер сделать программируемым, то это приведет к усложнению схемы. Так что если те же задачи можно будет решить при помощи копирования участков памяти между сегментами при помощи ПДП, я предпочту этот вариант, как более универсальный.
Еще одну проблему предвижу. При переходе по прерыванию в сегмент TSR все отлично, но вот где хранить информацию, из какого сегмента было передано управление? Наверное, придется это аппаратно в какой-то регистр записывать при переключении страниц. Как обрабатывать NMI - другая загадка. Например, подключать для обработки ПЗУ, которое и должно будет разруливать все вопросы. Хотя, если по RESET будет происходить то же самое, то и NMI вроде как и ненужно.
Error404
27.07.2017, 16:12
То же самое касается и наличия/отсутствия общего участка памяти. Его присутствие может дать как определенные преимущества, так и быть недостатком. Недостаток в том, что если он будет задан жестко, то он может стать помехой в плане совместимости, а если его положение и размер сделать программируемым, то это приведет к усложнению схемы.
По этой теме у меня была идея использовать чип ОЗУ в качестве программируемого маппера памяти. Например быстродействующие ОЗУ из кэша старых материнок наиболее распространенные 8кб/32кб/64кб дают программируемый дешифратор "13/15/16 в 8". С помощью одной такой ОЗУ можно маппить старшие адреса шины адреса ЦП, адресные ноги выбора страничек памяти, выходы каких-нибудь регистров. При старте компьютера ЦПУ работает в ПЗУ и непереключаемом участке ОЗУ для стека и переменных, считывает с носителя (чтобы карты памяти были сменными) карту для заливки в маппер (в эту ОЗУ=дешифратор), и хоп - мы в любимом маппере. Хоть MSX, хоть в Z180, хоть в Орионовском, каком угодно, хоть в кошмарном от RK-86. :)
Тоже думал на эту тему. Лучше всего использовать ОЗУ с раздельными входами и выходами.
Error404
27.07.2017, 17:02
Тоже думал на эту тему. Лучше всего использовать ОЗУ с раздельными входами и выходами.
Да, с раздельными будет удобнее, если есть такая статика со словом нужной разрядности.
Или же из обычной (где DI и DO - одни и те же выводы) с добавлением двух буферов АП5 (для 8-битной ОЗУ) - первая АП5 активна когда идеть запись маппера процессором (ОЗУ маппера на запись), вторая при работе маппера в прочую схему (ОЗУ маппера на чтение).
Наличие общего участка памяти может дать как определенные преимущества, так и быть недостатком. Недостаток в том, что если он будет задан жестко, то он может стать помехой в плане совместимости
Это вряд-ли. Если некоммутируемый участок выше кода BDOS, то туда вообще никто из CP/M не "лазиит". В качестве недостатка можно считать только, что на некоммутируемый участок расходуется TPA, поэтому не надо увлекаться размером этого некоммутируемого участка. 256 байт вполне достаточно для стека и для простейших подпрограмм чтения/записи байта и вызова п/п-ммы в соседней банке. Можно 256 самых старших адресов (FF00) отдать на порты (они тоже не коммутируются), а ниже (FE00) - 256 байт некоммутируемого ОЗУ из нулевой банки. ПЗУ 0...7FFF ставится в банке 0 и работает только при старте. Из него загружается ROM-BIOS и ПЗУ навсегда отключается. Такая архитектура идеально отвечает Вашим задачам, проще всех в реализации (и к тому же уже была применена 30 лет назад в самодельном ГДР-овском компьютере Bernd Hubler-а).
самодельном ГДР-овском компьютере Bernd Hubler-а
Ну так ссылку же на него сразу давать надобно ;), https://hc-ddr.hucki.net/wiki/lib/exe/fetch.php/einplatinenrechner:huebler_buch.pdf
...а "дополнительный" килобайт в верхних адресах мне понравился, очень умно. Клаву, как у него, я испытывал, но в результате сделал проще... Неплохой комп, хотя можно кучу узлов заменить другими м/с, с упрощением...
Лучше всего использовать ОЗУ с раздельными входами и выходами.
Две 155РУ2 не подойдут? Правда всего 16 байт и инверсия на выходе, но хоть что-то...
Ну так ссылку же на него сразу давать надобно
Я имел ввиду совсем другой (графический, а не текстовый) компьютер Huebler-a, описанный в книжке "Mikroelectronik in der Amateurpraxis 3", Militaer Verlag DDR, 1986, которую я купил в магазинчике "Книги соц.стран" (на Литейном) в 1987 году. И приплёл я его только потому, что там используется идея стартового ПЗУ 0...7FFF, отключаемого после загрузки и режим FULL RAM (вся память ОЗУ), хотя как прототип для CP/M-компьютера это не годится, т.к это игрушка типа Синклера, разработанная в 1985. Там всего 1 банка ОЗУ, такт всего 1.5 МГЦ, экранчик мизерный 256*256, к тому же графический и без цвета и ОЗУ непрозрачное (т.е с WAIT, в отличие от СПЕЦИАЛИСТА). Единственное, что там ценного, это хороший бейсик. Книга не оцифрована, так что ссылки дать не мог.
А про компьютер, описанный в PDF-файле из Вашей ссылки, я знал только из списка литературы. Это комп ещё из 1984 года, описанный в книге B.Huebler, K.Evert. Ausbaufaehiger Mikrocomputer mit dem U880. Berlin, 1985. Не знал также, что Вы хорошо читаете по немецки. Клавиатура в моей книге о которой речь, использует 155ИД3 и матрицу 16*4, а какая клавиатура в компьютере из Вашей ссылки, я пока не разбирался.
Две 155РУ2 не подойдут?Подойдут. Грамотные люди утверждали, что для таких целей нет ничего лучше, чем 555ИР26 и 8-ми окон с размером 8 кб каждый. Но ведь топик стартер решил, что цельнобанковая коммутация лучше, чем изощрённый диспетчер памяти, т.к его не поддержать программно, а использование создаёт лишние программные хлопоты.
Я еще ничего не решил. В процессе. Прежде чем браться решительно за дело, я собираюсь промоделировать несколько узлов, пощупать их. И в зависимости от результатов и буду выбирать вариант схемы.
Хотя насчет цельнобанковой схемы пока альтернатив не вижу.
Вот еще подумал и решил, что пока банк системы и TSR лучше объединить. Так проще разрулить, куда возвращаться после завершения обработки прерывания.
Error404
28.07.2017, 12:18
Вот еще подумал и решил, что пока банк системы и TSR лучше объединить. Так проще разрулить, куда возвращаться после завершения обработки прерывания.
И все же, я пока не понимаю, как в системе со страницей TSR, включающейся поверх рабочего кода по аппаратному прерыванию, будет обрабатываться случай, когда TSR накрывает стек - его же ставит пользовательская программа (и как самый запущенный случай - накрывает частично: один байт накрыт, второй нет). Предполагается включать TSR по INTA, но это событие наступает раньше, чем процессор пишет на стек адрес возврата из прерывания. Он или пропилит включившийся код TSR в непредсказуемом месте (если TSR это ОЗУ) и вероятен последующий "улёт", или же потеряется (не запишется) адрес возврата если страница TSR в ПЗУ.
Powered by vBulletin® Version 4.2.5 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot