Ну... мазл тов тогда.
Вид для печати
Ну... мазл тов тогда.
Здесь лучше оставить оригинал, т.е. терминальный ввод/вывод. Используется всего один СОМ-порт и для вывода инфы и для "опроса" клавиатуры (сразу в ASCII-кодах)Цитата:
Сообщение от rw6hrm
Как по мне, S-100 - избыточна. Половиной сигналов никто никогда не воспользуется. Я для своей машинки пока развел кросс-плату с такими сигналамиЦитата:
Сообщение от rw6hrm
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 использовать только в ближайшем слоте от процессора (контроллер прерываний будет устанавливаться только в этот слот), то на остальных слотах эту линию можно использовать для других задач.
Мои разработки клавы и дисплейного блока, на которые давал ссылки ранее, работают по терминальному принципу (даже п/п для СОМ-порта не меняются, за исключением инициализации), так что прокладку в виде тормозного СОМ-порта можно исключить или оставить только для внешнего обмена.Цитата:
Сообщение от Alex_LG
А про избыточность S-100 то ясно, Ваш список вполне оптимальный.
С КР580 ещё может быть, а вот с Z80, который сам регенерирует ОЗУ, и на непредельных частотах их применять вполне оправдано. Да и по энергетике динамические ОЗУ жрут большой ток только в момент когда /CAS равен 0, а без этого они жрут мало. Средний ток потребления при непредельной частоте - на уровне обычных TTL. Если надо оверклочить CPU на 5 МГЦ и выше, то следует применять скоростные SIMM, а не РУ5 или РУ7Цитата:
Сообщение от rw6hrm
Подавляющее большинство CPU в мире не имеют команд IN/OUT. Это извращение от инженеров Intel, - просто ненужное усложнение системы команд, вызывающее бесполезный расход деталей. IN/OUT ввели лишь для того, чтобы убедить клиента, что этот процессор "круче". И если портов меньше, чем пальцев на руке, то так ли уж сильно сократит это адресное пространство. Кроме того команда LD с адресацией через HL вдвое быстрее, чем IN/OUT.Цитата:
Сообщение от rw6hrm
Встречный вопрос. Мы что живём в середине 70-тых, когда ещё никто не слышал о цвете и графике, а нортон и окна на экране ещё не были изобретены. На кой хрен нужна система, к которой Вы не сможете написать свой красивый нортон и будете вынужденно заменять его POWER-ом? Может быть Вы и псевдографику и инверсию знакомест объявите блажью?Цитата:
Сообщение от rw6hrm
Насчёт затраты адресного пространства. Кто мешает, как во "Львове" сделать экран программно включаемый в адресное пространство только когда нужно делать вывод на экран. А для чего не хватит скорости? Да пока Вы передаёте по тормозному последовательному интерфейсу один символ, программно можно вывести на экран 100 символов. Какое тут ускорение?Цитата:
Сообщение от rw6hrm
Вообще идея терминала в компьютере, где хоть что-то говорят о скорости - нонсенс. Вы потому и не хотите иметь графику, потому что в идее терминала по последовательному интерфейсу она фатально тормозит. Терминал в оригинале это АЦПУ (клавиатура плюс принтер). Устройства 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 д.быть автоматическая перекодировка.
Просьба - прочитайте внимательно мои последние посты и найдите, где я там хоть что-то говорил о последовательном интерфейсе применительно к видеовыводу (исключая ссылки на чужие конструкции). Больше повторяться не буду. Мышление - да, терминальное. Но по параллельному интерфейсу. И с частичной поддержкой графики, кстати. Ссылки в предыдущих постах.Цитата:
Сообщение от barsik
Не надо передёргивать. Нет программ - незачем выпендриваться с графикой. Писать новые никто не будет.Цитата:
Сообщение от barsik
Да ради Дога, повторюсь: кому хочется испытать эротику с разводкой восьми (минимум) корпусов - оно пожалуйста. Но что-то никто не горит особым желанием хотя бы один корпус развести (или хотя бы поделиться свежими наработками). Только товарищ Xrust потихоньку проводит программные и аппаратные экзерсисы.Цитата:
Сообщение от barsik
Никаких проблем. В связи с тем, что если какой-либо новодел и будет внезапно собран, то он останется в пользовании самого автора, который сам будет решать, каким образом результаты его работы будут совместимы с чем-либо ещё.Цитата:
Сообщение от barsik
...угу, и это "подавляющее большинство" не работает под СР/М. И список из ныне живущих начинается и оканчивается на 6502 (включая клоны и прародителя).Цитата:
Сообщение от barsik
Ой. Вы, наверное, давно не интересовались существующим для СР/М софтом. Аналог NC уже есть (и не один, кстати), и он прекрасно работает на псевдографике, как и его бессмертный прародитель. Даже в цвете, синеньком таком. И PIP-ом открыто можно больше не пользоваться. Хотя лично мне консоли хватает выше крыши.Цитата:
Сообщение от barsik
...не хочу никого обидеть, но просто давайте положим руки на интимные/нежные части наших тел и признаем: вся эта ветка есть не более чем обычный разговорный шум. Делать СР/М-совместимую машинку если кто и будет, то чисто из-за спортивного интереса, а не для работы, как это было лет тридцать назад. Поэтому обсуждать что надо или не надо можно до бесконечности, в любом случае делаться всё будет только и исключительно исходя из подножного корма/подстольных запасов. А уж про написание программ - извините дважды. Они уже все написаны. Хотя никто не запрещает, также исходя из спортивного интереса, написать что-то свежее.
Я высказался. Спасибо.
Естественно.Цитата:
Сообщение от rw6hrm
Тема-то не о том, что будут сделаны платы для массового потребителя. Топик стартер попросил совета. И как раз это (раздачу советов) все кому не лень и делают. Каждый высказывает своё мнение, исходя из собственного опыта и предпочтений. Лично я высказываюсь о том, как бы сделал для себя. В ходе дискуссии обдумываются идеи. И если они и не полезны топик стартеру, это не важно. Люди читают этот форум в основном, чтобы получить моральную поддержку и почерпнуть идеи, которые они могут в дальнейшем использовать в своём творчестве.
Кстати, меня CP/M уже не интересует. Интереснее и, кстати, не намного сложнее, чем адаптировать CP/M, написать собственную ДОС. Главное тут, - придумать концепцию (уже опробовал для ДОС три концепции).
Как я понимаю, дикое возражение вызывает цвет и графика. Но согласитесь, что хорошие потребительные качества изделия желательны. Даже, если нортон монохромный, но в машине есть цвет, то кто мешает установить жёлтые буквы на синем фоне.
Цвет ничуть не утомляет при разработке ПО и легко встраивается в чужие готовые программы. Ведь с цветом никто не работает по железу. Используются ESC-последовательности. Достаточно их выкинуть на CONOUT и цвет включился или изменился. И последующие буквы выводятся на экран нужным цветом на нужном фоне. Интерфейс с программой остаётся чисто текстовым. Усложнений программирования нет. Просто на другом конце линии в терминале (или в самом компьютере, но в драйвере) работает не простейшая подпрограмма вывода символов (как в ПЗУ РК86), а 12-ти килобайтовый цветной оконный графический драйвер.
Если работать с графикой и цветом по железу, то передача по линии фатально тормознёт. Но при цветном графическом драйвере с управлением ESC-кодами как раз идея терминала оказывается выгодной. Для вывода просто символов терминал не даёт ускорения, а вот для графики и цвета уже иначе. Т.к обслуживание графики и цвета намного более ресурсо-затратно. Потому и разделение на два процессора, основной и графический - выгодно. Для основного CPU интерфейс остаётся простейшим, т.к для графики требуется передавать по линии всего на несколько символов больше, отчего цвет и графика никак не тормозит.
Можно и не писать новое. Можно взять чужие исходники и адаптировать. Но о чём речь? Где применить цвет и графику? Применительно к CP/M - реально речь только о нортоне. Желательно и текстовый редактор, но тут лучше SuperText не сделать при всём желании (и он кстати, в КОИ-8, - на CP-866 его не переделать, что начисто исключает эту кодировку).Цитата:
Сообщение от rw6hrm
Для НЕ-CP/M нужно чуть больше программ - это нортон, текстовый редактор и макроассемблер. Но, если эти программы у Вас один раз написаны, то сделать версию для другой ДОС или другого железа это работа, максимум, на один день.
Насчёт наличия исходников нортона. Тут нужен именно корректный для ДОС (т.е не по железу) и в принципе, у меня такой нортон есть (использует драйвер, но переделать в корректность не сложно). Я видел на немецких сайтах исходники нортонов. Но не стал даже смотреть, во-первых даже, если они корректные, то псевдографика и управляющие коды отличаются. Т.е в любом случае придётся адаптировать. А во-вторых, разбираться в чужих листингах, - противно и неинтересно. Но трудоёмкость адаптации низка. На написание нортона, текстового редактора или новой ДОС на ассемблере с нуля уходит до месяца (а на разработку макроассемблера три месяца). Трудоёмкость адаптации на порядки меньше.
Зачем разводить всё? Выгоднее распилить платы старых компов на фрагменты.. Фрагмент с ОЗУ привинчивается на 4-х винтах M2 (лучше M1.5), трудоёмкость меньше, чем монтаж ОЗУ статики типа w24512. В макетах я не использую МГТФ, хотя имею даже МГТФ-0.03. Ранее был самозалуживающиеся ПЭПЛОТ и ПЭВТКЛ. Теперь, увы, обычный ПЭЛ-0.2. Нет вороха проводов снизу. Макетируемая конструкция свинчивается из кусков готовых плат, что резко сокращает трудоёмкость проводного монтажа. Проблема лишь нехватки маленьких винтов и гаек (чтобы свинтить что-то новое, чтобы их добыть, приходится разбирать старые конструкции).Цитата:
Сообщение от rw6hrm
Видел пяток чужих нортонов. Но все они по железу (некорректные к ДОС). Дайте пожалуйста ссылку хоть на один корректный нортон (можно даже только сами коды, дизассемблировать не проблема).Цитата:
Сообщение от rw6hrm
В этом и заключается задача темы.Цитата:
Сообщение от rw6hrm
На мой взгляд такой компьютер уже есть. Это ОРИОН-128 с Z80 и 512К ОЗУ. Его архитектура позволяет получить CP/M с 60К TPA, цветом и графикой (хотя быстродействие 3.75 МГЦ маловато).Цитата:
Сообщение от rw6hrm
Месье знает толк в извращениях )Цитата:
Сообщение от barsik
А по теме - почему никто не юзает цп/м в плис на девбордах - там и з80 на 100+ МГц и памяти выше крыши ?
Юзают, не особо массово конечно, ибо не канонiчно и исключительно спортивный интерес, да и толку в этом нет особого... Юзабельного софта под такие скорости всё равно нет.
Как по мне - приятное извращение. ))) Расход деталей - такой же как и при адресации УВВ как ячейки памяти.Цитата:
Сообщение от barsik
Встречный вопрос - "На кой хрен нужна система", где я должен еще что-то дописывать, кроме драйверов? Не забывайте, что разговор идет о CP/M. Лично меня устраивает весь набор софта, что есть и переделывать его нет никакого желания. Я сделал CP/M машинку как девборду для опробования программных и схемных решений, т.е. есть основная плата с процессором, памятью, последовательным портом (терминал) и жестким диском к которой подключается кросс-плата, в которую я планирую "тыкать" всякую всячину для исследований. Для всего этого вполне хватает стандартного вида CP/M и ассемблера.Цитата:
Сообщение от barsik
Тут не понял. Отрисовка 100 символов 5х7 в памяти будет быстрее одной "извращенной" команды OUT!?Цитата:
Сообщение от barsik
100%! Как я уже написАл выше, если использовать такую машинку для собственных нужд, то терминала хватает с головой! И никакой графики не нужно, разве что, если очень нужно вывести какой-то график или картинку, можно использовать как внешнее устройство ISA карточку или графический дисплей, коих сейчас в продаже не мерено и на любое разрешение.Цитата:
Сообщение от barsik
---------------
удалил дубль
чет задвоилось сообщение...
Во-первых, по одному символу никто не передаёт и если уж так считать, то вывод одного символа в текстовый экран это тоже одна команда. Во-вторых, речь не о графическом экране, для которого как раз передача по линии и использование второго процессора для видеовывода имеет смысл. Я тоже делал CP/M машины и именно с текстовым адаптером, т.к убедился в нехватке скорости для вывода текста на графической ЭВМ. И процессор при использовании терминала вовсе не освобождается для другой работы. Потому, что по одному символу в час не передают, а передают целую строку. После вывода символа в ВВ51 командой OUT, процессор вовсе не свободен, а занят в цикле опроса готовности. По готовности, процессор выводит очередной символ. Стандартная скорость терминала 9600 бод. С учётом программного обслуживания, старт стоповых битов и пауз, за секунду передаётся ~800 символов. Таким образом, на вывод одного символа расход времени вовсе не 11 тактов команды OUT, а 1/800 секунды, т.е 1.25 МСЕК. При такте CPU в 4 МГЦ один маш.такт длится 0.25 МКСЕК. Итого за 1.25 МСЕК процессор в машине с текстовым адаптером с пользой выполнит 5000 машинных тактов. Если учесть, что все остальные побочные расходы программы текстового вывода одинаковы, то и получается то, что я написал.Цитата:
Сообщение от Alex_LG
А выигрыш терминал даёт вовсе не на командах OUT, а на обслуживании управляющих кодов, т.к их обслуживание выполняет не ЦП, а терминал имеющий свой процессор или в старых системах ~250 TTL-микросхем логики (в терминале СМ-1800 было ~10 плат, на каждой по ~35 корпусов 155-той серии). Но всё-равно система с экранным ОЗУ в адресном пространстве быстрее и гибче, чем терминальная.
Есть IBM PC, где ничего не надо дописывать. Рэтро системы именно потому и ценны, что только для них несложное любительское программирование имеет смысл. Только здесь любой "некомпетэ" может за несколько дней освоить ассемблер и начать писать программы. Именно в этом ценность, а вовсе не в том, чтобы собрать музейный экспонат и поставить на полку. Если я что-то делаю из железа, то только для того, чтобы писать для него программы, потому что писать программы на порядок интереснее, чем трахаться с железом, что дико ненавижу. Цель вовсе не железо и очень неприятно, что без возни с ним не обойтись. С большим психологическим сопротивлением заставляю себя возиться с железом, отчего могу этим заниматься лишь несколько дней, после чего вынужден отдыхать 2-3 недели. Оттого у меня сейчас все аппаратные работы продвигаются крайне медленно. Пытаюсь вспомнить с какой стороны держать паяльник. А какая ДОС, это вообще без разницы. CP/M была удобна 25 лет назад, потому что имеет компиляторы. А сейчас и это не играет роли, т.к удобнее программировать на PC.Цитата:
Сообщение от Alex_LG
Да, знаете-ли, доставляет эстетическое наслаждение уничтожение очень ценных и редких плат старых компьютеров. А если серьёзно, то это было в начале 90-тых и эти платы потеряли тогда всякую ценность. Уж лучше распилить и хоть как-то использовать, чем выбросить. Вот, что удалось тогда распилить. 3 платы ZX-48К, 3 комплекта ИРИШИ, 3 платы СПЕЦИАЛИСТА, 2 платы ОРИОНА, 2 платы КОРВЕТА (обе дохлые), ПРАВЕЦ-16 (дохлый), 3 платы Apple-II с грудой периферии, импортная ЭВМ (на MC6802, ОЗУ 4116+4164), целый СМ-1800 (еще осталось 10 нераспиленных плат со 155-той серией), 10 плат от ЕС ЭВМ, несколько плат от ДВК, не полностью спаянный ПРАВЕЦ-8М, чистые платы ОКЕАН-240.Цитата:
Сообщение от shurik-ua
Именно. Но, немного отвлекусь от текущего обсуждения для описания, почему я взялся за ваяние СР/М-машинки. Некоторые пункты могут быть спорны, но вот как-то так...Цитата:
Сообщение от barsik
1. Шум от писюков. Вентиляторы, приводы,... Ноутбуки не устраивают по тем же причинам. Тишины хочется.
2. Размеры. Для писюка нужно хоть какое-то место. Да, есть форм-фактор мини-ITX, но... В настоящее время моя машинка потихоньку втискивается в корпус от миниатюрного спутникового приёмника.
3. Экран. Для работы с ВГА мне нужны очки. Для работы с ЖКИ-телевизором 15" и 80 символами в строке не нужны.
4. Всё, что мне нужно - это текстовый редактор, СУБД и Бейсик на все остальные случаи жизни. С ФТП и почтой разберёмся позже, для СР/М это не проблема. Т.е. запрограммировал/настроил один раз и всё, только дальнейшая работа.
5. Получение удовольствия. Вроде последний пункт, но как бы основной ;) Расшифровывать не буду.
А для общения достаточно планшета.
А зачем СР/М-машинка вам? ;)
пятница, рыбный день.
Значит я Вас неправильно понял, просто много слов было о графике.Цитата:
Сообщение от barsik
Вот-вот, а не дописывать или "адаптировать" чьи-то программы под свои нужды. Я не собираюсь переделывать ни СР/М ни ассемлеры ни,тем более, писать какие-то цветные коммандеры. Повторюсь. Есть платформа, на ней запущен СР/М - это основа, которая не переделывается, а вот все мои "железные" фантазии и эксперименты - вот здесь пишу софт.Цитата:
Сообщение от barsik
Странная логика - написать программу, что бы под нее сделать железку! Обычно наоборот...Цитата:
Сообщение от barsik
Каждому своё. Я, например, больше люблю с железом ковыряться и это ничуть не мене интересно, чем писать программы под это железо.Цитата:
Сообщение от barsik
А я думаю, исходя из названия темы, как раз наоборот.Цитата:
Сообщение от barsik
:)
Пропаганда религии на сайте запрещена (в православии среда и пятница являются постными днями, в которые запрещается употребление мяса).Цитата:
Сообщение от Шынни
А при социализме рыбным днём был четверг.
Скрытый текст
Цитата:
Сообщение от Wiki
[свернуть]
А придётся, если нет желания иметь всего несколько программ, а точнее, лишь POWER, SuperText и DBase 2.50. Посмотрите на сайтах CP/M, там 90% программ это компиляторы ЯВУ. 10% это улучшенные клоны CP/M, утилиты, крутые текстовые редакторы и игры. Причём, если компиляторы универсальны, то игры и всё остальное надо адаптировать для конкретной ЭВМ. Игры с исходниками адаптировать несложно. А вот графические программы адаптрировать намного сложнее.Цитата:
Сообщение от Alex_LG
Поэтому 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, где вообще нет компиляторов, т.к самое минимальное ПО, что должно входить в ДОС - это текстовый редактор, макроассемблер и отладчик.Цитата:
Сообщение от Alex_LG
Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.
Именно, всегда наоборот.Цитата:
Сообщение от Alex_LG
Точно менее. И намного. Я тоже любил возиться с железом, пока не узнал правды. И из железа хоть какой-то интерес представляет разрабатывать своё, а не повторять чужое (особенно неинтересно повторять чужие конструкции на ПЛИС и МК). А при разработке своего всё-равно без программирования не обойтись.Цитата:
Сообщение от Alex_LG
barsik,Вот с этого момента давайте подробнее. Я хотел бы узнать ваше мнение, совместимость с какой платформой была бы предпочтительна? Интересует в частности реализация графики.Цитата:
Вы упускаете из вида, что существовало более 400 типов CP/M машин. И всё приличное ПО для них писалось по железу. Кому было бы интересно ПО без цвета и графики? Поэтому, то что в литературе указывают на наличие 10 тысяч программ для CP/M, это рекламная ложь. 10 тысяч может и есть, но реально пригодны только внеплатформенные программы, а именно - компиляторы и текстовые редакторы. Общее число доступных программ (считая пакет компилятора ЯВУ за одну программу) не превысит полусотни. Но для конкретной развитой западной CP/M машины (из конца 80-тых) программ будет тысяча.
Вот такие идеи сейчас вертятся в голове по организации памяти. Промежуточный итог, так сказать. Отдельную страницу 64к выделяем системе, отдельную страницу(ы) для приложений, отдельную страницу для обработчиков прерываний (автоматически подключается по сигналу подтверждения прерывания). Ну и как ранее писал, возможен обмен между страницами через ПДП контроллер ВТ37. А он, как я понял из ДШ, может и полностью управление перехватить, а может и по очереди с процессором делать свою работу. Как быть с графикой пока не решил. Т.к. конструкция будет модульная и с открытой архитектурой, то надо предусмотреть установку видеоадаптеров различных конструкций. А значит, скорее всего, им при необходимости будут выделены свои страницы памяти.
Хм… Чет ничего не понял со страницами по 64Кб. А как же склеенный (общий) участок адресуемой памяти. Кто будет этим добром по 64К управлять?
Просто ни разу не встречал для 8-бит ЦПУ таких конфигураций памяти, чтобы страницы целиком по 64Кб щелкались. Кусочек памяти должен быть не переключаемый.
Будет кусочек ПЗУ, который так же можно отключить при желании. Например, предварительно скопировав его в нужные страницы ОЗУ при помощи ПДП.
Хитро. А как же на языке Си писать. Там такие номера не пройдут. У нас ведь не х86.Цитата:
Сообщение от Xrust
Если уж делать страничную организацию памяти. То нужно смотреть в сторону менеджера памяти Z180. Даже у MSX c самым продвинутым движком управления памятью не всегда удобно по 16Кб щелкать. Надо меньше.
Ну как бы поэтому на С никто особо и не пишет на 8-битках ) И для пользовательской программы это прозрачно будет. Все равно ей за пределы одной страницы лезть незачем. Этими делами будут TSR и ОС заниматься.Цитата:
Сообщение от OrionExt
Как не пишет? А как же Uzi, Fuzix, UZIX. Пускай не СP/M;)Цитата:
Сообщение от Xrust
А компиляторам такая модель памяти даже в страшном сне не присниться. ПДП это прекрасно. Но с моделью памяти точно не стоит паровоз изобретать.
Да и TSR написать далеко не тривиальная задача. Это уже высший пилотаж.
А как эта модель памяти связана с компиляторами? Для прикладной программы горизонтом является TPA. Как раз компилятору не надо думать об организации памяти. И для TSR все удобно сделано. По прерыванию автоматически подключается страница с TSR областью и можно особо не мучаясь обрабатывать прерывания и т.п. А можно и не пользоваться этой возможностью. Главное, чтобы эта возможность была и имела хотя бы минимальную программную поддержку на уровне ПЗУ BIOS. И этим практически любой желающий сможет воспользоваться.
Эта модель памяти очень проста и не обязывает программиста подстраиваться под систему. Нет жесткой страничной модели как в Спектруме или Орионе. Можно вызвав стандартную процедуру переместить участок памяти любого размера из любой страницы в любую. Можно один байт переслать, а можно и 64к. А процессор в это время в своей текущей странице будет заниматься своим делом.
Насчёт предпочтительности, т.е с точки зрения выбора платформы для которой было больше всего CP/M программ, ничего сказать не могу. Я немного знаю лишь о тех компьютерах, которые сам имею или имел, а о других компьютерах я знаю не больше любого другого. Понятно, что могу по памяти перечислить с десяток западных 8-ми разрядок, что у всех на слуху и упоминания на которых встречаются на сайтах ретро компьютеров и CP/M. Но не только не знаю сколько у каждого компьютера программ, но даже параметров их железа не знаю.Цитата:
Сообщение от Xrust
Я могу лишь высказать своё мнение о том, какую графику считаю оптимальной для себя. Опыт показал, что графика должна быть такой, чтобы допускать символы шириной в байт (вывод втрое быстрее, чем символы с шириной не кратной байту), а организация цвета такой, чтобы максимально упростить цвет для текста. Смешивать в одной плоскости цвет и графику (как в MDA XT) нет смысла, лучше две плоскости (возможно даже включённые в одном адресном пространстве). Что касается цвета для полноценной цветной графики, т.е возможности задавать цвет попиксельно, то это полезно только для игр.
Из этого получается, что оптимальным будет организация графики 512*256 (размер экранной плоскости 16К) и один режим цвета, позволяющий задавать два цвета в пределах 8-ми экранных точек. Т.о получается расширенный экран ОРИОНА в 16-ти цветном режиме.
На самом деле на СИ для 8-ми биток много писали, но увы, не у нас. Т.к когда наши 8-ми разрядки были популярны, то не было доступа к компиляторам. А когда в 1994-96 такое появилось, то профессионалы (разработчики ПО в КБ заводов выпускающих 8-ми битки) уже исчезли, а любители просто не успели освоить компиляторы ЯВУ. Я думаю, что главным ограничением использования СИ является не архитектура ЭВМ, а объём ОЗУ для компилятора и скорость прогона программы на СИ. ЯВУ не волнует архитектура машины. ЯВУ желательно сплошное ОЗУ максимального размера. А то, используется для интерфейса с драйвером экрана из другой банки некоммутируемый кусок ОЗУ или всегда включённое ПЗУ, - ЯВУ совсем не волнует. Я предлагал отказаться от некоммутируемого участка ОЗУ лишь из экономии, т.к без этого можно обойтись (хотя и за счёт усложнения программы).Цитата:
Сообщение от Xrust
Вообще-то самый продвинутый диспетчер памяти для CPU с 16-ю адресами - в машинах DEC. Такой диспетчер ОЗУ с 8-ю окнами размером по 8К - не удастся использовать. ПК11/16 имеет в DOS многозадачность, т.е одновременно прогоняется много процессов, каждый из которых имеет полученный у DOS свой набор участков ОЗУ, который и включает в 8-ми килобайтовых окнах, в моменты, когда этот процесс активен. Если многозадачной ДОС нет, то бОльший смысл имеет коммутация по 60/64К.Цитата:
Сообщение от OrionExt
Железо в ИРИШЕ позволяет коммутировать ОЗУ целиком по 64К, но так не делают, всегда общий кусок 16К остаётся для связи между картами памяти (из-за чего сокращается объём ОЗУ, т.к число карт памяти всего 4). У ИРИШИ диспетчер похож на MSX (в адресном пространстве коммутируются 4 окна по 16К), но, увы, управление этими окнами сделано не оптимально.Цитата:
Сообщение от OrionExt
Круто.Цитата:
Сообщение от Xrust
Вообще, просто драйвер загружаемый в другую банку (например драйвер принтера или другой клавиатуры), это тоже TSR, но без прерываний. Они грузятся на вектора стандартных входов CP/M-BIOS.
Но раз речь зашла о TSR с прерываниями, т.е о резидентном процессе, то это значит, что речь о многозадачной DOS на прерываниях. Вот тут уж нельзя отказываться от некоммутируемой области. Иначе с прерываниями будут большие проблемы и сложное программирование. Причём в прерывании должна быть возможность считать текущую конфигурацию (чтобы иметь возможность восстановить по выходу из INT). В ОРИОНЕ не предусмотрели возможность считать текущий номер банки, отчего сложно делать многобанковое ПО с прерываниями (т.к надо долго извращаться, чтобы узнать в какой банке нас застало прерывание).
Эмм... Две (как минимум) изолированные магистрали? Или как? Чтоб одновременно, и не прибито гвоздями к растактовке? Мысля интересная и что-то напоминает... из древнего...Цитата:
Сообщение от Xrust
ИМХО не стоит делать специфические "кусочки". Тут ПЗУ там еще что.Цитата:
Сообщение от Xrust
Пусть они все будут равноправные и гомогенные, что ли, однородные. Как в MSX, только действительно, как говорит OrionExt, несколько помельче.
Хотя конечно один придется сделать несколько равноправнее других :) на момент загрузки, по крайней мере.
Вот это интересная идея, надо обмозговать. Тоже что-то из области мини-ЭВМ, наверно...Цитата:
Сообщение от Xrust
- - - Добавлено - - -
У "Ириши" нужно посмотреть вспомнить как сделано. А у MSX точно можно сказать, что MMU (а их там по факту аж два, переключалка слотов и собственно маппер ОЗУ) там "может копать, а может не копать", т.е. как хочешь так и щелкаешь.Цитата:
Сообщение от barsik
Другое дело, что "щелкнув" не подумав можно все "поломать".
Компиляторы пишутся под конкретные модели памяти, а их не так уж и много на 8-битках. А точнее две small и banked (large). Small - это обычная сплошная до 64Кб. Banked (large) – пример на рисунке.Цитата:
Сообщение от Xrust
https://lh3.googleusercontent.com/OD...A=w600-h342-no
Ну, так глубоко не копал. А разве такое возможно для ПДП и ЦПУ? Шина та у них общая. Это надо арбитр для доступа к памяти делать (прозрачный доступ) или дуал-озу использовать.Цитата:
Сообщение от Xrust
Отнюдь. Первое, что в голову приходит, где можно гембель огрести с цветами - это отрисовка собственно графиков. Кривых на сетке координатной.Цитата:
Сообщение от barsik
Похож, да не похож. Даже смотреть не буду.Цитата:
Сообщение от barsik
Штатный MSX диспетчер памяти у не окрепшего 8-ми битного ума (пользователя) может разорвать все шаблоны:D:D:D
Максимальный объем адресуемой памяти 64Мб !!! (4096Kb x 16 slots). И все это тасуй, как хочешь в четырех окнах по 16Кбайт.
- - - Добавлено - - -
Чутка соврал. За вычетом ПЗУ – 56Mб.
И это если использовать только "каноничный" маппер ОЗУ. А если слегка отойти от стандарта (как это сделано напр. в маперах ПЗУ кариков) то...Цитата:
Сообщение от OrionExt
Я не рассматривал прерывания в этом качестве. Меня больше интересуют драйвера устройств. Вряд ли кому то нужна будет многозадачная ОС на подобной машине. Достаточно просто, КМК, реализовать в рамках CP/M переключение между задачами, если каждая из них будет работать в своем сегменте памяти. Например редактор и компилятор и переключаться между ними не загружая каждый раз заново. Можно даже придумать концепцию буфера обмена между задачами. Но создавать настоящую многозадачную систему? Думаю просто не найдется энтузиастов :)Цитата:
Сообщение от barsik
Как я понял из даташита на 8237, там есть режим блочного и одиночного обмена.Цитата:
Сообщение от TomaTLAB
Если я правильно понял, то при одиночном обмене процессор и DMA попеременно занимают шину и при этом длительных затыков не возникает. Поправьте меня, если я что-то не так понял.Цитата:
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.
У меня модель памяти простая. Приложению выделяется сплошная страница. Если ему надо больше - пусть обращается к соответствующим функциям ОСи. В том то и особенность предложенной модели - она максимально совместима с обычными CP/M приложениями и не требует их доработки. Небольшого допиливания потребует только сама система, т.к. ее ядро будет размещено в отдельной странице и при запуске приложения оно (приложение) будет загружено в свою отдельную страницу.Цитата:
Сообщение от OrionExt
Я вообще считаю, что ПЗУ нужно только для загрузки системы. В нем должны размещаться специфичные для конкретного набора аппаратуры драйверы и программа конфигурации оборудования. Функцией этой программы должна быть настройка оборудования и компоновка БСВВ. Затем БСВВ загружается в верхнюю область ОЗУ, драйверы оборудования в страницу TSR, а ПЗУ отключается до следующего включения или перезагрузки.Цитата:
Сообщение от TomaTLAB
Xrust, переубеждать вас не буду. Попробуйте на своей модели памяти, время покажет насколько это удобно. По мне таки нужен общий кусочек памяти. Чет вспомнил и решил найти такую штуку на MSX. Очень неплохой показатель 61K TPA на классической модели памяти.
http://www.z80.eu/cpm3boot.gif
OrionExt, а какие конкретно функции должен выполнять общий участок памяти?
очевидно служить буфером для передачи данных при переключении в другую страницу - имхо.
Ух. Список функций зависит от ОС. На вскидку стек, таблица прерываний, п/п менеджмента страниц памяти, таблицы вызова п/п Биос-а, ... В инете уйма примеров с подробными описаниями что да как и куда.Цитата:
Сообщение от Xrust
Очень удобно и универсально на 3 регистрах, без излишеств, совместимость с 8-бит софтом (ОС, компиляторы и т.д). Никто не мешает сделать эту штуку на рассыпухе, пускай даже в упрощенной реализации.Цитата:
Сообщение от OrionExt
OrionExt, насколько я понимаю, стек приложения никак не будет связан со стеком CP/M. Передача управления осуществляется простым переходом по адресу. Необходимо только скопировать при запуске программы область системных параметров и точки входа драйверов.
Точка вызова функций СРМ из программы одна CALL 5,X.
Не знаю, что ответить на остальное. Но что я знаю точно, работа с памятью выше 64К требует еще тех программных извращений. И этих извращений в разы меньше при использовании общего (не переключаемого) участка памяти.
штоэ?Цитата:
Сообщение от OrionExt
непонятная какаято команда - но имхо лучше использовать одну из команд RST x, где в рег А - номер интересующей ф-ции.Цитата:
Сообщение от OrionExt
Хитро завернул:) Кто в теме тот понял.Цитата:
Сообщение от OrionExt
Код:ld c,func
call 5
Основная закавыка тут в том, что если хочется сделать чтобы система была прозрачной для прерываний (в т.ч. и при вызовах в прочие сегменты) то надо помнить что при наступлении прерывания стек не переставленный в общую область может пропилить память в неожиданных местах. И таблицы векторов прерываний или п/п обработчика тоже может неоказаться в ожидаемом месте (и вообще всё улетит). А раз уж общая область необходима, то с ее помощью реализуемы и более удобные механизмы - например "длинные вызовы" (вызовы в другую страницу когда тамошняя "иностраничная" процедура может возвращать управления в вызывающую страницу просто командой RET, или сама тоже делать вызов в третью страницу, и вся цепочка потом выйдет стеком в нужные страницы просто по RET), межстраничные прересылки без DMA объемов больших чем влезающие в регистры. и т.п.Цитата:
Сообщение от OrionExtНа вскидку стек, таблица прерываний, п/п менеджмента страниц памяти, таблицы вызова п/п Биос-аЦитата:
Сообщение от Xrust
Если же согласны пропускать прерывания, то конечно, тупо ставим DI, делаем что надо в других страницах, потом выполняем EI.