Компьютер для CP/M. Формулировка ТЗ.

[Shiny]

CP/M BDOS system calls

[Advertiser]

[Xrust]

Error404, как я уже говорил выше, хочу попытаться реализовать все обработчики прерываний в отдельной странице. Например, по сигналу "подтверждение прерывания" переключать специальную страницу памяти, где и будут расположены все обработчики прерываний. Выход из процедуры прерывания можно осуществить через специальный вектор, одинаковый на всех страницах и содержащий команду RET. Как-то так. Подробно этот механизм я еще не обдумывал, это пока просто идея, которую выношу на общее обсуждение. То же самое касается и наличия/отсутствия общего участка памяти. Его присутствие может дать как определенные преимущества, так и быть недостатком. Недостаток в том, что если он будет задан жестко, то он может стать помехой в плане совместимости, а если его положение и размер сделать программируемым, то это приведет к усложнению схемы. Так что если те же задачи можно будет решить при помощи копирования участков памяти между сегментами при помощи ПДП, я предпочту этот вариант, как более универсальный.
Еще одну проблему предвижу. При переходе по прерыванию в сегмент TSR все отлично, но вот где хранить информацию, из какого сегмента было передано управление? Наверное, придется это аппаратно в какой-то регистр записывать при переключении страниц. Как обрабатывать NMI - другая загадка. Например, подключать для обработки ПЗУ, которое и должно будет разруливать все вопросы. Хотя, если по RESET будет происходить то же самое, то и NMI вроде как и ненужно.

[Error404]

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

По этой теме у меня была идея использовать чип ОЗУ в качестве программируемого маппера памяти. Например быстродействующие ОЗУ из кэша старых материнок наиболее распространенные 8кб/32кб/64кб дают программируемый дешифратор "13/15/16 в 8". С помощью одной такой ОЗУ можно маппить старшие адреса шины адреса ЦП, адресные ноги выбора страничек памяти, выходы каких-нибудь регистров. При старте компьютера ЦПУ работает в ПЗУ и непереключаемом участке ОЗУ для стека и переменных, считывает с носителя (чтобы карты памяти были сменными) карту для заливки в маппер (в эту ОЗУ=дешифратор), и хоп - мы в любимом маппере. Хоть MSX, хоть в Z180, хоть в Орионовском, каком угодно, хоть в кошмарном от RK-86.

[Xrust]

Тоже думал на эту тему. Лучше всего использовать ОЗУ с раздельными входами и выходами.

[Error404]

Тоже думал на эту тему. Лучше всего использовать ОЗУ с раздельными входами и выходами.

Да, с раздельными будет удобнее, если есть такая статика со словом нужной разрядности.
Или же из обычной (где DI и DO - одни и те же выводы) с добавлением двух буферов АП5 (для 8-битной ОЗУ) - первая АП5 активна когда идеть запись маппера процессором (ОЗУ маппера на запись), вторая при работе маппера в прочую схему (ОЗУ маппера на чтение).

[barsik]

Наличие общего участка памяти может дать как определенные преимущества, так и быть недостатком. Недостаток в том, что если он будет задан жестко, то он может стать помехой в плане совместимости

Это вряд-ли. Если некоммутируемый участок выше кода BDOS, то туда вообще никто из CP/M не "лазиит". В качестве недостатка можно считать только, что на некоммутируемый участок расходуется TPA, поэтому не надо увлекаться размером этого некоммутируемого участка. 256 байт вполне достаточно для стека и для простейших подпрограмм чтения/записи байта и вызова п/п-ммы в соседней банке. Можно 256 самых старших адресов (FF00) отдать на порты (они тоже не коммутируются), а ниже (FE00) - 256 байт некоммутируемого ОЗУ из нулевой банки. ПЗУ 0...7FFF ставится в банке 0 и работает только при старте. Из него загружается ROM-BIOS и ПЗУ навсегда отключается. Такая архитектура идеально отвечает Вашим задачам, проще всех в реализации (и к тому же уже была применена 30 лет назад в самодельном ГДР-овском компьютере Bernd Hubler-а).

[rw6hrm]

самодельном ГДР-овском компьютере Bernd Hubler-а

Ну так ссылку же на него сразу давать надобно , https://hc-ddr.hucki.net/wiki/lib/ex...ebler_buch.pdf
...а "дополнительный" килобайт в верхних адресах мне понравился, очень умно. Клаву, как у него, я испытывал, но в результате сделал проще... Неплохой комп, хотя можно кучу узлов заменить другими м/с, с упрощением...

Лучше всего использовать ОЗУ с раздельными входами и выходами.

Две 155РУ2 не подойдут? Правда всего 16 байт и инверсия на выходе, но хоть что-то...

[barsik]

Ну так ссылку же на него сразу давать надобно

Я имел ввиду совсем другой (графический, а не текстовый) компьютер 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 кб каждый. Но ведь топик стартер решил, что цельнобанковая коммутация лучше, чем изощрённый диспетчер памяти, т.к его не поддержать программно, а использование создаёт лишние программные хлопоты.

[Xrust]

Я еще ничего не решил. В процессе. Прежде чем браться решительно за дело, я собираюсь промоделировать несколько узлов, пощупать их. И в зависимости от результатов и буду выбирать вариант схемы.
Хотя насчет цельнобанковой схемы пока альтернатив не вижу.
Вот еще подумал и решил, что пока банк системы и TSR лучше объединить. Так проще разрулить, куда возвращаться после завершения обработки прерывания.

[Error404]

Вот еще подумал и решил, что пока банк системы и TSR лучше объединить. Так проще разрулить, куда возвращаться после завершения обработки прерывания.

И все же, я пока не понимаю, как в системе со страницей TSR, включающейся поверх рабочего кода по аппаратному прерыванию, будет обрабатываться случай, когда TSR накрывает стек - его же ставит пользовательская программа (и как самый запущенный случай - накрывает частично: один байт накрыт, второй нет). Предполагается включать TSR по INTA, но это событие наступает раньше, чем процессор пишет на стек адрес возврата из прерывания. Он или пропилит включившийся код TSR в непредсказуемом месте (если TSR это ОЗУ) и вероятен последующий "улёт", или же потеряется (не запишется) адрес возврата если страница TSR в ПЗУ.