ПК-6128Ц: Обсуждение

[Павел Рябцов]

Оно и в бумаге такое же качество. У меня несколько экзепляров таких...
Я это уже понял, вот и прошу помощи...

[dk_spb]

Я не справлюсь, слишком большой объем работы.
Как я и писал "и правда слишком много непоняток, надо брать плату и долго ковырятся."

[Павел Рябцов]

Я не справлюсь, слишком большой объем работы.
Как я и писал "и правда слишком много непоняток, надо брать плату и долго ковырятся."

Я когда дорисую схему, напишу от какой и к какой микросхеме и к какому выводу должно ( как я подозреваю) звониться тестером. Надо будешь лишь прозвонить и всё. Но правда есть надписи где они вообще не читаемы, вот с ними засада может быть. А может к тому времени ещё подтянутся реальные владельцы аппарата.
И ещё, Денис, будет время, РТшку считай, Родина этого не забудет!!!

[Павел Рябцов]

Нарисовал схему полностью, теперь вопросов ещё больше, куча выводов почему то осталась в воздухе(((
Без платы не реально думаю восстановить схему.

[ivagor]

Пара вопросов:
1. D10 (155РЕ3) так и не сдампили?
2. Схем лучшего качества (лучше 43.png и 44.png) не появилось?
Если вдруг неожиданно есть положительные ответы на эти вопросы, просьба поделиться с общественностью или ткнуть носом, где это есть.

[crackintosh]

"Бобик сдох?" или как говорят "кина не будет, электричество кончилось"? Жаль...

[ivagor]

Здесь (https://siesit.livejournal.com/27618.html), после заметки о векторе, есть интересный комментарий пользователя 6128 (вроде раньше здесь не обсуждали).
1. "И звук проигрывался через телек, а не пьезоэлектрическую фигнюшку, как у Вектора :))" - тут понятно, что "через телек" можно было и вектор подключить, просто для 6128, в отличие от 06Ц, надо было в любом случае использовать какое-то внешнее устройство звуковоспроизведения. Например звук ленинграда отец подключал к ТВ, а звук 06Ц подавал на усилитель (и слушали через колонки).
2. "Но была и обратная сторона медали - многие игры от Вектора не запускались, что вызывало сильный детский баттхёрт :-))" - вот это очень интересный момент. У меня есть два предположения.
2.1. Из-за процессора могли не запускаться буквально считанные единицы игр: pillars; в какой-то комановской игре была заставка (или распаковщик) использующая недокументированные команды, возможно еще где-то использовались недокументрованные команды в распаковщике. Сейчас есть версии pillars и той комановской игрушки (еще бы вспомнить название), совместимые с любым векторовским процессором.
2.2. Вот с играми, в которых для защиты от копирования тиражаторы использовали свои уникальные форматы хранения на ленте 6128 совсем не совместим, увы. Тогда это могло быть проблемой, но сегодня все магнитофонные игрушки есть в виде rom или r0m.

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

Забыл еще пункт.
2.3. На 6128 не заработали бы дисковые игрушки требующие кваз.

[ivagor]

Сейчас можно найти несколько программ из комплекта 6128. Выложивший их человек есть на форуме, если он захочет, то думаю сам приведет ссылку, если не хочет - его право. Наибольшую ценность представляют родной дос и доработанный для 6128 тест устройств (возможно еще графический редактор, там надо разбираться). Обращу внимание на тест озу - в emu все нормально, а VV спотыкается на банке 0. Дело похоже в использовании значений 55h и 66h для порта 0Eh, которые не входят в список "наиболее рациональных значений" из руководства по эксплуатации.

[KTSerg]

Промелькнуло упоминание, что КД для 6128, вроде "не кошерно", при собственной памяти на борту 128КБ...
А мне почему-то кадется, что при таком количестве памяти, как-раз легко доступный внешний носитель это подспорье.
Понятно, что 256КБ на КД это мизер при ОЗУ в 128КБ, но ОСь на нём ранить для быстрого рестарта лучше чем на дискете... с моей точки зрения...
Хотя с другой стороны... БИОС (начальный загрузчик) известен давно, и его скорее всего уже разобрали по полочкам, и не нашли в нём упоминания про "os.com", и обращению к чему-либо подобному КД. Иначе это обсуждалось-бы... скорее всего.

[Improver]

Понятно, что 256КБ на КД это мизер при ОЗУ в 128КБ, но ОСь на нём ранить для быстрого рестарта лучше чем на дискете... с моей точки зрения...Если организовать аналог КД в памяти (а такое возможно на ПК6128?), то он будет всего-то 48 кб диск + 16 кб подэкранки, вот это и есть мизер... И с моей точки зрения на ПК 6128 кваз на 256 кб тоже не помешает, а если его сделать энергонезависимым, то тем более.

[Improver]

Сделал схему ПК6128 в Протеусе, вот какая грандиозная вещь получилась:

https://s1.hostingkartinok.com/uploads/thumbs/2022/11/641a7f7cb414a528e38ced32f28f10c8.png (https://hostingkartinok.com/show-image.php?id=641a7f7cb414a528e38ced32f28f10c8)

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

Призываю сообщество досконально проверить схему, весь проект с исходниками в протеусе выложил на гитхаб (https://github.com/ImproverX/PK-6128c). В помощь там же есть сканы схем ПК-6128, на которых я выделил шины разными цветами и делал пометки в ходе отрисовки схемы, это существенно облегчает поиск соединений. И, Павел Рябцов, сравните мой вариант со своим, пожалуйста.

Пара замечаний по схеме ПК6128:

В описаниях и тут (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=143852&viewfull=1#post143852) в том числе указана частота процессора 3МГц, но по схеме получается, что он работает на 6МГц.

Строчные синхроимпульсы у него сделаны примерно также, как и на первом Векторе и имеют длительность 10,5мкс, для подключения к современным ТВ требуется их уменьшение до 4мкс, имеющиеся варианты доработки Вектора подойдут.

[Mick]

В описаниях и тут в том числе указана частота процессора 3МГц, но по схеме получается, что он работает на 6МГц.

У ВМ85 внутри частота делится на 2

[Improver]

У ВМ85 внутри частота делится на 2Понятно. Значит там указывается внутренняя частота.

[Improver]

Прикинул содержимое D10 (К155РЕ3), имеем, значит, следующие зависимости:


На микросхеме ПЗУ адрес меняется каждые пол периода частоты 6МГц, всего имеем 16 значений, на 8 тактов.
Для получения ССИ с периодом 64мкс сигнал МХ2 должен иметь частоту 750 кГц, не обязательно его полупериоды будут равны, но 16 значений должно быть поделено на две неразрывные области, единиц и нулей, иначе подсчёт адреса будет неверным.
Обращение к памяти для чтения в сдвиговые регистры графики происходит через каждые 8 тактов частоты 6МГц.
Чтение из памяти в сдвиговые регистры выполняется в два этапа (по 16 бит), разрыв между этапами в 1 такт частоты 6МГц. Получается, за два байта из ПЗУ должен быть подготовлен адрес и считаны данные на вторые 16 бит графики. Жёстко...



Итого, первом прикиде, содержимое РЕ3 может быть примерно такое:

D0(RATO) 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0
D1(RAS) 0 0 0 1 0 0 0 1 0 0 0 1 0 1 0 1
D2(CAS) 1 1 0 1 1 1 0 1 1 1 0 1 1 0 1 0
D3(MX1) 1 0 0 1 1 0 0 1 1 0 0 1 0 1 0 1
D4(MX2) 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1
D5(FR6) 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1
D6(FR7) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0
D7(FR1) X X X X X X X X X X X 0 0 0 1 1
Тут все "Х" принимают значение или 0, или 1, это не влияет на работу.

Получается, три раза по 4 адреса обращение к памяти и один раз чтение графики. Возможно одно из трёх обращений к памяти следует заменить на цикл регенерации памяти, нужно сравнить с работой первого вектора. И, скорее всего, все эти биты следует циклически сместить вправо или влево для выравнивания по циклам работы процессора, в это я ещё не углублялся.

З.Ы. В схеме сделал маленькое исправление, картинку выше (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160605&viewfull=1#post1160605) и исходники на гитхабе обновил.

[ivagor]

разрыв между этапами в 1 такт частоты 6МГц
Если это так, значит используется страничный доступ, только в страничном режиме РУ5 может прочитать новые данные за 166 нс.

Получается, обращение к памяти процессора и чтение графики выполняется по очереди два раза за 8 тактов частоты 6МГц.
За 8 тактов/6 МГц (4 такта/3 МГц) два чтения графики и один доступ процессора (по тесту быстродействия).

[Improver]

Посмотрел я графики работы Вектора, что-то я слишком круто завернул обращение к памяти процессора. :) Если ориентироваться на быстродействие 580ВМ80А, то должно быть что-то ближе к этому:

D0(RATO) 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
D1(RAS) 1 1 0 0 0 0 1 1 0 1 0 1 1 0 0 0
D2(CAS) 1 1 1 1 0 0 0 1 1 0 1 0 1 1 1 1
D3(MX1) 1 1 1 0 0 1 1 1 0 1 0 1 1 1 1 1
D4(MX2) 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
D5(FR6) 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1 1
D6(FR7) 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1
D7(FR1) X X X X X X X 0 0 0 1 1 X X X X
^^^^^^^^^^^^^^^^ ^^^^^^^ ^^^^^^^
ОЗУ Экран Реген.
Т.е. два такта 3МГц на обращение к памяти и два на всё остальное. Опять же, плюс/минус смещение может быть...

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


Если это так, значит используется страничный доступСтраничный доступ? А это идея, надо глянуть, возможно ли это тут сделать...

[Improver]

ivagor, я посмотрел схему, там всё подходит для работы с памятью в страничном режиме, нужное изменение адреса как раз передаётся в cas, но вот только я не смог найти информацию, что к565ру5б поддерживают такой режим. Они точно умеют работать по "ras-cas-cas..."?

[ivagor]

РУ3, РУ5, РУ6 поддерживают страничный режим, РУ7 - слоговый (nibble mode).
А я попробовал сам расписать ras и cas. Прикидочные варианты со страничным доступом (верхний) и без (нижний). Тут я исходил из характеристик 565РУ5Г (можно кое-где подвинуть), без учета работы остальной схемы. Для страничного варианта счетчик адресов видео должен измениться примерно между 3 и 4 тактами, для нестраничного - в 3 такте.

D1(RAS) 1 0 0 0 1 1 1 0 0 0 0 0 0 0 1 1
D2(CAS) 1 1 0 0 1 1 1 1 0 0 1 1 0 0 1 1
D3(MX1) 1 0 0 0 1 1 1 0 0 0 0 0 0 0 1 1
D4(MX2) 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1

D1(RAS) 1 0 0 0 1 1 0 0 0 1 1 0 0 0 1 1
D2(CAS) 1 1 0 0 1 1 1 0 0 1 1 1 0 0 1 1
D3(MX1) 1 0 0 0 1 1 0 0 0 1 1 0 0 0 1 1
D4(MX2) 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1
Повторюсь, можно подвинуть. Ну и очевидно можно ротировать.

[Improver]

РУ3, РУ5, РУ6 поддерживают страничный режимХорошо, спасибо за инфу.

Прикидочные варианты со страничным доступом (верхний) и без (нижний).Проблема в том, что нужно всё уплотнить, т.е.:

D1(RAS) 1 1 0 0 0 0 1 1 0 1 0 1 1 0 0 0
D2(CAS) 1 1 1 1 0 0 0 1 1 0 1 0 1 1 1 1
^ ^
1 2В точке "1" должно быть первое считывание в регистры, а в точке "2" -- второе. Но, основываясь на Ваших и своём вариантах я нарисовал такой:

D0(RATO) 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
D1(RAS) 1 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0
D2(CAS) 1 1 1 1 0 0 0 1 1 1 0 1 0 1 1 1
D3(MX1) 1 1 1 0 0 1 1 1 1 0 0 0 0 0 0 1
D4(MX2) 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
D5(FR6) 1 1 1 1 1 1 1 1 1 1 0 1 1 1 1 1
D6(FR7) 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1
D7(FR1) X X X X X X X X 0 0 0 1 1 X X X
^^^^^^^^^^^^^^^^ ^^^^^^^^^^ ^^^^^
ОЗУ Экран Реген.
И, я думаю, следует пояснить по сигналам с РЕ3:
RATO -- разрешение на доступ к памяти процессора (при =1).
FR6 -- чтение данных в сдвиговые регистры D45 и D47, по положительному фронту.
FR7 -- чтение данных в сдвиговые регистры D44 и D46, по положительному фронту.
FR1 -- тринадцатый бит адреса, передаваемый в память при чтении данных графики.
MX1 -- переключение первой/второй половины адреса на мультиплексорах.
MX2 -- 0 = доступ процессора к ОЗУ, 1 = графика и регенерация.

Проект на гитхабе (https://github.com/ImproverX/PK-6128c) обновил, но схему это не затронуло, теперь в проекте моделируется работа К155РЕ3 с возможностью подключения туда образа прошивки.

[ivagor]

Проблема в том, что нужно всё уплотнить
Понимаю, я расписал несколько отвлеченно, опираясь на характеристики РУ5Г, которые, насколько я знаю, использовались в 6128. Для варианта типа

ras 0 0 0 0
cas 1 0 1 0
строго говоря нужны РУ5Б или РУ7В, хотя на практике скорее всего и РУ5Г будут работать и сравнительно сильно греться. Кстати вспоминаю, что один из пользователей 6128 жаловался, что у него озушки вышли из строя, тут как повезет. Либо все же надо перепроверить.


RATO -- разрешение на доступ к памяти процессора (при =1).
Помню, что это READY процессора, куда еще идет не смотрел.

Ну и мы же вроде уже на ты.

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

Забыл - зачем активный RAS в крайних правых столбцах? Что, у 6128 отдельная от обновления экрана регенерация?

[Improver]

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


Помню, что это READY процессора, куда еще идет не смотрел.На вывод RA (35) процессора и на шину ВУ, где он обозначен, как "RATO".


Забыл - зачем активный RAS в крайних правых столбцах? Что, у 6128 отдельная от обновления экрана регенерация?Не думаю, что это там необходимо, просто мне показалось, что ещё одна регенерация по другим адресам не помешает -- там три адреса всё равно пропадают... Но можно на эту область, например, расширить использование процессором ОЗУ, или просто забить единицами.

Немного инфы по "фаршу" в адресах, по схеме получается у ПК6128 такая раскладка:

RAS A2 A1 A0 A12 A11 A10 A9 A8
CAS A16 A15 A13 A7 A6 A5 A4 A3
A14 -- выбор комплекта микросхем для обращения, A15 и A16 выставляется по значению A15 процессора и записанной в порт 0Eh конфигурации.

[ivagor]

Не думаю, что это там необходимо, просто мне показалось, что ещё одна регенерация по другим адресам не помешает -- там три адреса всё равно пропадают
Т.е. за 4 такта (3 МГц) видеоадрес (часть для ras) меняется несколько раз?

[Improver]

Т.е. за 4 такта (3 МГц) видеоадрес (часть для ras) меняется несколько раз?Нет, смена адреса происходит один раз, по такту МХ2 (750кГц). Если вопрос про вторую, придуманную мной регенерацию, то там по RAS подаётся адрес для CAS, кажется такой финт был на Векторе... Но, повторюсь, что если это всё мои заблуждения, то я совершенно не буду возражать по её удалению.

[ivagor]

смена адреса происходит один раз
Значит чтения видеоданных вполне достаточно для регенерации.
Вобще, если они все же использовали страничное чтение через 166 нс, то могли пойти дальше и прочитать так все 4 байта из одной линейки озу. И еще остается время для одного доступа проца. Вероятно их остановило то, что такой экстремальный для РУ5Г режим приводил к проблемам с надежностью работы.

[Improver]

Вот ещё есть идея, можно немного увеличить длительность CAS, но между двумя CAS так и останется полтакта 6МГц:

D0(RATO) 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
D1(RAS) 1 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0
D2(CAS) 1 1 1 1 0 0 0 0 1 1 1 0 0 1 0 0
D3(MX1) 1 1 1 0 0 1 1 1 1 1 0 0 0 0 0 1
D4(MX2) 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
D5(FR6) 1 1 1 1 1 1 1 1 1 1 1 1 0 1 1 1
D6(FR7) 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1
D7(FR1) 1 1 1 1 1 1 1 1 1 1 0 0 0 1 1 1
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
ОЗУ Экранivagor, как думаешь, такой вариант будет лучше для микросхем памяти?

[ivagor]

Официально (смотрю по МПССиС 1985/3, стр. 93) tCP (длительность интервала между сигналами /cas в страничном режиме) у РУ5Г 120 нс, т.е. формальные требования не выполняются. Но если можно удлинить cas, то почему бы и нет, хуже не станет, скорее наоборот. Насколько я понимаю, cas можно сделать длинным, все равно при чтении данные появятся с определенной задержкой (tCAC) относительно спада /cas. У РУ5Г официально tCAC=120 нс, но на практике меньше, Mick смотрел анализатором.

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

Доступ процессора надо аккуратнее разобрать. Я бы сжал ras и cas примерно до

ras 1 0 0 0 1 1 ...
cas 1 1 0 0 1 1 ...
чтобы выставление адреса и чтение или запись уложились в один такт 3 МГц. Сюда должен попасть T2 процессора.
И с RATO (READY) надо внимательно посмотреть. READY должен быть активен (или неактивен) за некоторое время (tRYS) до начала второго такта проца, чтобы проц его (READY) воспринял. Скорее всего надо сузить активную область READY - примерно от середины первого такта до середины второго.

[Improver]

tCP (длительность интервала между сигналами /cas в страничном режиме) у РУ5Г 120 нсА там как измеряется? Это время от завершения первого CAS до начала второго, или время между началами двух CAS? Если между началами, то там 249нс получается, в последнем варианте, но между сигналами всего 83нс.


при чтении данные появятся с определенной задержкой (tCAC) относительно спада /cas. У РУ5Г официально tCAC=120 нсА вот с этим может быть проблема -- второе чтение в сдвиговый регистр выполняется через 83нс после CAS, и это никак не исправить, надежда только на то, что практически там будет меньше.


Доступ процессора надо аккуратнее разобрать. Я бы сжал ras и cas примерно доВполне возможно. А есть хорошая документация по ВМ85? Я нашёл неплохую, но там картинки не приложили, нет диаграмм работы.

[ivagor]

в последнем варианте, но между сигналами всего 83нс
Речь про это, поэтому и нехорошо.

А вот с этим может быть проблема -- второе чтение в сдвиговый регистр выполняется через 83нс после CAS
Насколько я помню записи анализатора Micka, в реальности данные появлялись примерно через 70-90 нс, в зависимости от варианта озушки. Понятно, что для серийного устройства нехорошо на это рассчитывать.
В принципе это ведь не совсем реплика, можно сделать иначе. Читаем первые 2 байта в промежуточные регистры. Потом читаем вторые 2 байта из озу и переписываем 2 байта из промежуточных регистров. И требования к скорости чтения видеоданных резко ослабляются.

есть хорошая документация по ВМ85?
Например вот (https://zx-pk.ru/threads/32921-quot-zx-8085-quot-daungrejd-kompyutera-quot-leningrad-quot-chast-2.html?p=1105296&viewfull=1#post1105296), там рядом вроде еще есть.

[Improver]

Понятно, что для серийного устройства нехорошо на это рассчитывать.Вот, наверно, поэтому и было так мало выпущено ПК6128...


В принципе это ведь не совсем реплика, можно сделать иначе.В данном случае это ещё не новый проект, не реплика, а попытка восстановления схемы ПК6128, попытка понять, как он работал. Что-то менять в схеме будем на следующем этапе...


Читаем первые 2 байта в промежуточные регистры. Потом читаем вторые 2 байта из озу и переписываем 2 байта из промежуточных регистров. И требования к скорости чтения видеоданных резко ослабляются.Есть такая микруха, 74HCT597, она по функционалу идентична К555ИР10, но в её составе уже есть регистр на входе параллельной загрузки данных, который запоминает 8 бит по отдельному тактовому сигналу, в остальном их работа не отличается. Заменить на неё D45 и D47 и необходимость жёсткой привязки по времени загрузки отпадёт. И даже триггер D49 станет ненужным. Примерно также я и делал в своей графической карте. :)


Например вот, там рядом вроде еще есть.Спасибо, поизучаю.

[Improver]

Вот что получается по выравниванию частот по процессору...

По мануалам, RATO должен начинаться за 100нс (tRYS) до переднего фронта тактовой частоты на такте Т2, и заканчиваться за такое же время до переднего фронта тактовой частоты на цикле ожидания. Тактовая частота отстаёт от фронтов входной частоты на tXKR = 25..120нс, итого, получается, нули в RATO должны начаться до задержки минимум за 2 бита (передний фронт тактовой частоты) + 1 бит (=~83нс), итого за три бита. Тут пока всё просто.

Чтение данных из памяти производится на тактах Т2 и Т3, точнее сказать от начала Т1 в момент tAD=(5/2+N)T - 150, где N -- число циклов ожидания. Получается tAD =~683нс + N*T. В нашем случае это значит, что на Т3 в ШД уже должны быть данные. Возможно стоит сместить чтение графики на 8 бит влево (в предыдущем варианте прошивки (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160874&viewfull=1#post1160874)), совместив его с Т1 и Т2, когда обращения к памяти нет, а чтение данных из памяти выполнить после, получается примерно так:

D0(RATO) 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
D1(RAS) 1 0 0 0 0 0 0 1 1 0 0 0 0 0 0 1
D2(CAS) 1 1 1 0 0 1 0 0 1 1 1 0 0 0 0 0
D3(MX1) 1 1 0 0 0 0 0 1 1 1 0 0 1 1 1 1
D4(MX2) 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
D5(FR6) 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1
D6(FR7) 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1
D7(FR1) 1 1 0 0 0 1 1 1 1 1 1 1 1 1 1 1
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
Экран ОЗУ
Циклы: Т1 Т2 TW T3
Т4 Т1 T2 T3... -- норм

...Т2 ТW TW T3
Т4 Т1 T2 T3... -- норм

... Т1 T2 T3
Т4 Т1 T2 T3... -- норм

... Т1 T2
Т3 ... -- плохоВ общем, если Т2 попадёт на последнюю четвёрку адресов РЕ3, то задержки не будет и на Т3 процессор не получит данные. Такая ситуация возможна? Это я только прикинул по циклам самого простого MOV, а дальше я тут что-то начинаю путаться...

[ivagor]

Когда писал (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160875&viewfull=1#post1160875) про T2 совсем забыл, что в 6128, в отличие от zx8085, нет регистра на чтение данных из памяти и нужно совместить конец чтения из озу и T3 проца.

D0(RATO) 0 0 0 0 0 0 1 1 1 1 0 0 0 0 0 0
D1(RAS) 1 0 0 0 0 0 0 1 1 1 0 0 0 0 0 1
D2(CAS) 1 1 1 0 0 1 0 0 1 1 1 1 0 0 0 0
D3(MX1) 1 1 0 0 0 0 0 1 1 1 1 0 1 1 1 1
D4(MX2) 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0
D5(FR6) 1 1 1 1 0 1 1 1 1 1 1 1 1 1 1 1
D6(FR7) 1 1 1 1 1 1 0 1 1 1 1 1 1 1 1 1
D7(FR1) 1 1 0 0 0 1 1 1 1 1 1 1 1 1 1 1
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
Экран ОЗУ
Циклы: Т1 Т2 TW T3 -- норм

... Т1 T2 T3 -- норм

... ... T1 T2
ТW ТW TW T3... -- норм

... ... ... T1
Т2 ТW TW T3... -- норм

Еще желательно уточнить насчет записи в РУ2. Т.к. 8085 выполняет mov r,r и dcr быстрее, то при сохранении векторовских зон непрограммируемости часть программм столкнулась бы с проблемами. В 6128 решили эту проблему сделав запись в РУ2 с одного OUT. Вероятно для этого надо подать p0Co на /WE РУ2. Ну и по крайней мере текущий /WPL я бы не стал туда подавать.

[Improver]

С учетом этого я бы сделал такХотя меня тут немного смущает практически постоянно активный сигнал RATO, может быть именно так и должно быть. И ещё, RAS/CAS я бы всё-таки сдвинул на один бит влево, по документации хоть и tAD =~683нс, но это указано, как максимальное время, значит данные надо подготовить чуть раньше, возможно даже до начала Т3.


Еще желательно уточнить насчет записи в РУ2Да, похоже, что тут я в схеме напутал. :( Надо будет пересмотреть ещё раз эту часть, в особенности куда тогда был подключён выход D8: D...

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

Логичнее его будет подключить к входу сброса D7:A, там ROM совсем не к месту, хотя номер линии на чертеже стоит "10".

[ivagor]

смущает практически постоянно активный сигнал RATO
Он активен один такт из 4, примерно как и в 06Ц.

RAS/CAS я бы всё-таки сдвинул на один бит влево
Если речь про RAS/CAS для проца, то ограничивающим фактором я считаю наличие сформированного адреса к спаду RAS. Вопрос в том, где реально начнется T2 с учетом всяких задержек и запаздываний.

[Improver]

Если речь про RAS/CAS для проца, то ограничивающим фактором я считаю наличие сформированного адреса к спаду RAS.Ну насчёт этого можно не беспокоится -- адреса А8..А15 готовы в начале цикла Т1, адреса А0..А7 будут захвачены с процессора через TLL = 1/2T-20, т.е. фактически в середине Т1. Схема формирования А15 и А16 на D63 даст задержку максимум 38нс, таким образом адрес уже к началу Т2 будет сформирован и на Т3 можно смело передавать его по RAS/CAS.

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

Исправил в схеме найденную ошибку с портом 0С (запись палитры), картинку в сообщении (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160605&viewfull=1#post1160605) и исходники на гитхабе (https://github.com/ImproverX/PK-6128c) обновил.

[Improver]

Дизассемблировал прошивку ПК-6128ц... Что могу про неё сказать:

Практически вся прошивка -- это бейсик. :) В конце добавлена загрузка с магнитофона (СС+БЛК-ВВОД) и с флопи-диска (УС+БЛК-ВВОД), причём несколько функций там вызываются прямо из бейсика.
Сам бейсик в прошивке расположен на своих адресах, при старте практически весь копируется в память "как есть", после в нём патчатся несколько адресов переходов и выполняется примитивная распаковка шрифтов и некоторых данных.
В бейсике есть больше десятка переходов по неправильным адресам (на аргументы операндов), возможно за этим просто не уследили при сдвиге некоторых блоков, и вполне возможно, что они и являются причиной глюков, перечисленных тут (http://sensi.org/scalar/ware/875/).
Кроме того в бейсике есть вызовы недокументированных функций 08h, 28h и т.д., но я не ислючаю, что просто ошибся при дизассемблировании и это блоки с данными, а не с подпрограммы.
Единственная особенность ПК-6128ц, которая используется в прошивке -- это очистка всех 128кБ памяти. Сам бейсик в работе не использует всю память, хотя мог... Не исключаю вариант, что его можно запускать даже на обычном Векторе, но я это не проверял.

Ассемблерный код прошивки выложил на гитхаб (https://github.com/ImproverX/PK-6128c/blob/main/ROM.asm), если кто заинтересуется, то можно его исправить и улучшить.

[ivagor]

Сам бейсик в работе не использует всю память, хотя мог
Всю память можно использовать для графики с оператором SCREEN1

[Improver]

Всю память можно использовать для графики с оператором SCREEN1Да, я не подумал о таком варианте, это его плюс, однозначно. Выше имел в виду, что память под программы можно было бы расширить сразу, без необходимости использования "40кБ"...

[ivagor]

в бейсике есть вызовы недокументированных функций 08h, 28h
Если после rst 1, то это аргументы

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


память под программы можно было бы расширить сразу, без необходимости использования "40кБ"
Делал я такой бейсик для 6128 (48 килобайт под программу при 16 цветах), и даже где-то выкладывал на форуме, в картотеке похоже нет.

[Improver]

Делал я такой бейсик для 6128Хорошо, можно будет обновить прошивку. :) А другие программы под ПК-6128 сохранились? Видел упоминание "теста устройств", графического редактора, но нашёл только образы дискеток с CPM и MDOS.

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


Если после rst 1, то это аргументыИсправил в исходниках этот момент.

[ivagor]

А другие программы под ПК-6128 сохранились?
Если речь про "старые" программы из начала 90х, то они тут (http://raregame.ru/text/vector.html)

[Improver]

Нашёл одну ошибку в схеме ПК-6128 -- при восстановлении я перепутал выводы 3 и 4 на микросхеме Д81. Схему в сообщении (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=1160605&viewfull=1#post1160605) и на гитхабе (https://github.com/ImproverX/PK-6128c) обновил.

[Improver]

Непонятный момент в схеме ПК-6128, вот тут (моя перерисовка):
78100

И оригинальная схема:
78101

Получается так: если сигнала БЛК нет, то на мультиплексоры адреса памяти передаётся бит А16, а если сигнал БЛК есть, то на ту же линию передаётся инверсный А14, причём выходные мультиплексоры памяти Д43 и Д44 в этот момент будут закрыты тем же БЛК. Есть идеи, зачем это могло быть сделано?

[ivagor]

Предполагаю, что идея была (частично?) заблокировать внутренний диспетчер памяти при активизации внешнего. В деталях реализации не разбирался, тем более что нам неизвестно, как разработчики 6128 сами планировали делать блок внешнего озу (какой там должен был быть диспетчер).

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

Хотя корректнее будет назвать не "частичной блокировкой" внутреннего диспетчера, а коррекцией его работы при подключении внешнего озу, вероятно для согласования с внешним диспетчером.

[Improver]

Может и для согласования с внешним... Там получается так: сигнал по А16 передаётся на память при CAS, а CAS генерируется в РЕ3 постоянно, даже когда есть БЛК, и хоть выход памяти на шину данных и запись блокируются БЛК, но таким образом память читается постоянно, не только во время работы с экраном. Может во время этих фантомных чтений делается подмена адреса для того, чтобы память равномернее изнашивалась? Не делали такого в те годы?

[ivagor]

Если cas во временных слотах проца генерируется даже когда проц не обращается к озу, то возможно это сделано для упрощения схемы. Это немного увеличивает потребление и нагрев озу. На мой взгляд вышеприведенный фрагмент схемы все же служит для согласования диспетчеров. Если внешнее озу вырабатывает БЛК только при обращениях к себе, то "паразитных" обращений "наружу" не будет.

[Improver]

В общем, внимательнее глянул на схему и да -- эта часть сделана именно для передачи адреса на ВУ. На контакты ВУ 25,27,29,31,33,35,37 и 39 выводятся сигналы с мультиплексоров Д21..Д24, и если не подменять бит А16 на А14, то там будет передан неправильный адрес.

[Improver]

Подскажите, какие ещё эмуляторы поддерживают ПК-6128ц, кроме emu от b2m?

[ivagor]

Еще VV Ramirosa

[Improver]

Хорошие новости. В Компьютерном Музее (https://retro-computer.ru/) есть живая кассета от ПК-6128ц:
https://retro-computer.ru/Photo/Vector-6128/Vector-6128-22.jpg
Я списался с ними, и мне выслали содержимое этой кассеты в виде wav-файлов. Кое-что удалось там с ходу обработать "тапиром", а что-то он не смог разобрать, хотя на слух качество записи неплохое, надо ещё поколдовать над ними...

Копировщик COPY там стандартный Векторовский, похоже, Бейсик 1.0 для ПК6128ц, программы для Бейсика считались почти все, но содержимое ещё не проверял.

Интересно было бы взглянуть на монитор-отладчик и ассемблер, они тоже Векторовские, или были доработаны под ПК6128, но их "тапир" не разобрал.

Если кто-то пожелает поковыряться в записях, то вот архив: https://disk.yandex.ru/d/1zxZIPS6e8P7FQ

[dk_spb]

Я же несколько раз выкладывал и диск и вавы от кассеты....

[ivagor]

Кто о чем, а я о бейсике. Два интересных момента:
1. Моя невнимательность (https://zx-pk.ru/threads/835-vektor-06ts-obshchie-voprosy.html?p=1174268&viewfull=1#post1174268) про BASIG.BAS на практике все же обернулась бейсиком на кассете.
2. Кассетный бейсик 1.0 и 1.0 из пзу не совпадают.

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

Кассетный более поздний, там исправлена ошибка PUT, которая есть в пзушном.
Процедуры обмена с магнитофоном сдвинулись на 2 байта, в emu для перехвата чтения/записи CAS надо подкорректировать конфиг:

biproc[2B68-2BB8]=rk
biproc[2B68-2BB8].check="C5D50E0057DB01E610"
boproc[2BC3-2BE7]=sp
boproc[2BC3-2BE7].check="C5D5F5570E087A0757"

[Improver]

Я же несколько раз выкладывал и диск и вавы от кассеты....Оу... А можно ссылочку? А то поиском у меня не получилось, потому и просил Музей...

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


Кто о чем, а я о бейсике.А может стоит и этот Бейсик переработать и улучшить? ;)

[ivagor]

Что касается оптимизации для 8085, то я начинал пилить соответствующую спецверсию 2.98, но потом пришло вдохновение и получилось резко ускорить основную версию для 8080, так что она даже обогнала "устаревший" вариант для 8085. Возможно я вернусь к этой теме и перенесу наработки для 8085 в новый вариант.
А если речь про поддержку дополнительных возможностей бейсика для 6128 (SCREEN1, STICK, STRIG), то тут проблема в отсутствии программ, которые их используют.

Возвращаясь к версиям бейсика и версиям 6128 - возможно имеющийся дамп пзу относится к раннему экземпляру и в последующих уже и в пзу был исправленный бейсик.

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


Копировщик COPY там стандартный Векторовский, похоже, Бейсик 1.0 для ПК6128ц, программы для Бейсика считались почти все, но содержимое ещё не проверял.

Интересно было бы взглянуть на монитор-отладчик и ассемблер, они тоже Векторовские, или были доработаны под ПК6128, но их "тапир" не разобрал.
В COPY 2.1 плохая (действующая в узком диапазоне) хака для подстройки к скорости 8085.
В Мониторе-отладчике поменяли константы обмена с магнитофоном (как в бейсике).
А тест устройств совпадает с вариантом выложенным (https://www.raregame.ru/text/vector.html) Sergi

[Improver]

Возможно я вернусь к этой теме и перенесу наработки для 8085 в новый вариант.Надеюсь, если ПК6128 станет востребованным.


поддержку дополнительных возможностей бейсика для 6128 (SCREEN1, STICK, STRIG)Из этой троицы наиболее интересен, пожалуй, screen1 -- новые возможности для работы с экраном, всё-таки... Плюс больший объём памяти для программы на бейсике.

[ivagor]

SCREEN1 - потенциально мощная штука, но никто не использовал и не использует.

Плюс больший объём памяти для программы на бейсике.
1. BASIC 1.0 для 6128 позволяет использовать дополнительную память для
1.1. Графики
1.2. Хранения данных с доступом через POKE/PEEK
Если сама программа (или переменные) пересечет границу &8000, то переключать экраны по SCREEN1 станет невозможно, т.к. это приведет к зависанию бейсика.
2. С другой стороны basic48k (https://zx-pk.ru/threads/8146-pk-6128ts-obsuzhdenie.html?p=573890&viewfull=1#post573890) позволяет использовать всю память для программы, переключая экран прозрачно для программиста. Туда в принципе можно было добавить SCREEN1 для пары экранов, но все опять упирается в отсутствие программ.

[Improver]

ivagor, отсутствие программ -- не такая уж большая проблема, если дать возможность, то может и желающие её использовать найдутся... А программы на бейсике с кассеты не смотрел? Там используются возможности бейсика для ПК-6128ц?

[ivagor]

отсутствие программ -- не такая уж большая проблема, если дать возможность, то может и желающие её использовать найдутся
Basic 1.0 для 6128 и basic48k доступны много лет и никто ими не пользовался.

А программы на бейсике с кассеты не смотрел? Там используются возможности бейсика для ПК-6128ц?
Программы на бейсике смотрел как раз в поисках использования уникальных фич.
Не прочитались: ним, фифти, охота на лис.
Прочитались: собери квадрат, сокровище, марсианский десант. В них особенности 6128 не используются, более того сокровище и марсианский десант скорее всего с минимальными усилиями перенесены с РК.
Торпедную атаку не пробовал, думаю она как на стандартной кассете 06Ц.

[Improver]

Кассету ПК-6128ц обработал, всё прочиталось, вот итог: https://disk.yandex.ru/d/LghpyNV_-5BfIw

В архиве файлы:
*~.wav -- обработанные данные.
*~~.wav -- переоцифрованные данные (заново сгенерированные).
*.{ROM/BAS/MON} -- содержимое в бинарном виде.

Что могу ещё отметить... Редактор-Ассемблер -- точная копия с Вектора-06ц, даже без патча на русские буквы, в Мониторе-Отладчике не только поправлены коэффициенты чтения/записи, но и присутствует надпись "ПК-6128ц" в заголовке. "Торпедная Атака" является копией Векторовской, там даже надпись на ПК-6128ц не изменили.

А вот сам Бейсик с кассеты интересен -- в нём не только исправили PUT, как заметил ivagor, но и он имеет меньше глюков по сравнению с Бейсиком из ПЗУ, например он нормально отрабатывает горячие клавиши, а ПЗУшный подвисает на полуслове. Есть подозрение, что ПЗУ считали с ошибками...

Ну и выложу отдельно бинарники считанных с кассеты программ: 79236

[ivagor]

например он нормально отрабатывает горячие клавиши
О каких горячих клавишах речь?


Есть подозрение, что ПЗУ считали с ошибками
Возможно пзу сдампили с ошибками, но различия между имеющейся пзушной и кассетной версиями нельзя объяснить только ошибками. В кассетной не просто некоторые байты поменяли значение, а произошел сдвиг частей программы, это 100% целенаправленно сделали люди.

[Improver]

О каких горячих клавишах речь?Подвисает на УС+СС+"<" (CLOAD), и УС+СС+">" (CSAVE), возможно что-то ещё.


Возможно пзу сдампили с ошибками, но различия между имеющейся пзушной и кассетной версиями нельзя объяснить только ошибками.Согласен, тут скорее оба фактора.

[ivagor]

Подвисает на УС+СС+"<" (CLOAD), и УС+СС+">" (CSAVE)
Попробовал в Emu и в VV - и там и там указанные комбинации нормально работают. Возможно дело в компьютере (старинный i5) или в ОС (проверял в win7).

[Improver]

Попробовал в Emu и в VV - и там и там указанные комбинации нормально работают. Возможно дело в компьютере (старинный i5) или в ОС (проверял в win7).Проверил в VV -- и правда работает, глючило только в EMU. Оказалось я там битую прошивку цеплял, перестало глючить после восстановления. :v2_dizzy_facepalm:

[Improver]

Все режимы работы памяти ПК-6128ц:



Значение
Адреса 0000h..7FFFh
Адреса 8000h..FFFFh


0
Банк 0
Банк 1


1
Банк 0
Банк 0


2
Банк 0
Банк 3


3
Банк 0
Банк 2


4
Банк 1
Банк 1


5
Банк 1
Банк 0


6
Банк 1
Банк 3


7
Банк 1
Банк 2


8
Банк 2
Банк 1


9
Банк 2
Банк 0


A
Банк 2
Банк 3


B
Банк 2
Банк 2


C
Банк 3
Банк 1


D
Банк 3
Банк 0


E
Банк 3
Банк 3


F
Банк 3
Банк 2



При записи числа в порт 0Eh значение битов 3..0 определяют конфигурацию банков для чтения, и биты 7..4 -- для записи, итого получается 256 различных вариантов.

Например, после записи в порт числа 20h, при записи в память будут подключены "Банк 0, Банк 3" (см. в таблице строку со значением "2"), а при чтении -- "Банк 0, Банк 1" (строка "0"), при записи числа 55h конфигурация памяти будет "Банк 1, Банк 0" и на чтение, и на запись.

[Ramiros]

Обновил VV_7.13 (https://cloud.mail.ru/public/9s53/noXQQ778d), исправил баг с менеджером памяти, не помню откуда я брал инфу о его работе, но там была какая то ахинея :)

[Improver]

Появилась определённость с прошивкой D10 К155РЕ3 -- Surin Mikhail снял логи с живого ПК-6128ц, вот какая получается там прошивка:

D0(RATO) 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 -- доступ процессора к памяти
D1(RAS) 0 0 1 1 0 0 0 0 0 0 0 0 1 1 0 0
D2(CAS) 0 0 0 1 1 1 0 0 1 1 0 0 1 1 1 1
D3(MX1) 0 0 1 1 1 0 0 0 0 0 0 0 1 1 1 0 -- 0 = адрес по CAS, 1 = адрес по RAS
D4(MX2) 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 -- =750кГц, ОЗУ/Графика
D5(FR6) 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 -- чтение первой пары регистров (по положительному фронту F6M)
D6(FR7) 1 1 1 1 1 1 1 1 1 1 0 0 1 1 1 1 -- чтение второй пары регистров (по положительному фронту F6M)
D7(FR1) 0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0 -- 13-й бит адреса (графика)
^^^ ^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^
ОЗУ Экран ОЗУ
F 6МГц 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 -- тактовая частота генератора
SVNC 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 -- тактовая частота процессора
По сравнению с нашими предположениями, в реале на экран выделяется на полтакта 6МГц больше, есть небольшой сдвиг сигнала RATO, а остальное мы практически угадали. :)
Прошивку поправил в выложенной на гитхабе схеме (https://github.com/ImproverX/PK-6128c).

[Improver]

Неожиданно нашёлся вот такой вот листок:
https://s1.hostingkartinok.com/uploads/thumbs/2025/10/c1492d9273f984ae4e9dc2b085704d95.png (https://hostingkartinok.com/show-image.php?id=c1492d9273f984ae4e9dc2b085704d95)

И содержимое РЕ3 в нём несущественно, но отличается от снятых логов. Не исключено, что прошивка в ПК была доработана без внесения изменений в документацию, либо просто была некоторая погрешность снятия логов.

[Improver]

Проверил оба варианта прошивки на своём ПК-6128ц++, правда из-за особенностей схемы пришлось дополнить прошивку ещё 16 байтами и немного поправить сигнал FR1, но сути не меняет. Второй вариант, с фотографии страницы, не работает, с ним, как минимум, нет изображения, а первый, который снят с работающего ПК -- вполне рабочий. Причина того, что прошивка из документации не работает, думаю, в том, что сигналам FR6 и FR7 (ПЛ1 и ПЛ2) недостаточно одного нуля для захвата данных сдвиговыми регистрами.

Скорее всего и правда в документацию не были внесены некоторые исправления, доверять стоит прошивке, снятой с живого ПК-6128ц.

[ivagor]

Еще возможно прошивка из распечатки работала на 1-2 первых экземплярах (может там ставили некоторые микросхемы побыстрее), а когда стали делать малую серию (и удешевлять) пришлось доработать.

[Improver]

Еще возможно прошивка из распечатки работала на 1-2 первых экземплярах (может там ставили некоторые микросхемы побыстрее), а когда стали делать малую серию (и удешевлять) пришлось доработать.Да, скорее всего так. Там такой момент: если частота 6МГц переходит из 0 в 1 до того момента, как сигналы FR6 и FR7 тоже переключатся с 0 на 1, то сдвиговые регистры смогут "зацепить" данные, а по графикам эти события с прошивкой из доков происходят одновременно, плюс-минус скорость срабатывания элементов. Дополнительный нолик в прошивке спасает от такой ситуации. В первых экземплярах удачно сложились быстродействия элементов, в общем.:)