Орион-ПРО. Сборка и наладка.

[Error404]

Имхо, что 4-битный, что 6-битный звук не нужны. В ПРО уже есть AY, и он своей красотой звучания затмит этот "механический скрежет". Думаю, что ПРО'шка вполне потянет нормальный 16-битный звук, если прикрутить соответствующий "взрослый" чип - это может иметь хоть какой-то смысл.

Значит, ставлю ТМ9. Один хрен что так что так: будет ли кто-то пользоваться - большой вопрос.

Что до ценности ковоксов, пожалуй если говорить за синтезированный 8-битный звук - тут без вопросов: AY уделает низкоразрядный DAC вчистую. Но например когда речь о оцифровке (упрощенно, wav), то тут ИМХО уже можно поспорить. Обычный резисторный ЦАП для такого вида звука более прост в программировании (считал байт - вывел в порт), чем AY, "инструменты" (а точнее огибающие) которого нуждаются в более сложном процессинге и большем количестве команд процессора.
Прекрасно помню, как через ковокс на PC (8-бит DAC) играл оцифровки вполне достойно даже на ХТ. Также более смутно помнится как эффекты в WOLF (или это был DOOM?) на ковоксе звучали не хуже новомодного тогда саундбластера.

Кстати, вот вам из моей коллекции архивчик из папочки "если дойдут руки" (во вложении). Программа воспроизведения wav на AY (в варианте от MSX). Пожималка для PC, а плееры разной дискретности - для Z80/AY. Может, найдется энтузиаст, который это заведет на ПРО или 128-м.

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

Значит, ставлю ТМ9.

Итак, сделал все же правку с учетом замены D116 на ТМ9.
Ну и по мелочи - шины, площадки snd (выход ковокс D116) и skd (база VT3) -можно их соединить потом проводником или использовать раздельно.

[Advertiser]

[Denn]

Совершенно нечаянно обнаружилась ещё одна ошибка в Орионе-ПРО. Проблема возникает при включении режима "2,5 МГц". Некоторые программы, собственно ради которых этот режим и реализован, работают некорректно. Вот проги, в которых глюки воспроизводятся 100%-но: REKL$ (эффектная демка для Ориона-128), LINES$, ALMAZ$. В первой, в режиме "2,5 МГц" полностью отсутствуют спецэффекты (мерцающие звёзды, анимация переходов), только меняются статичные картинки/текст. В играх графический мусор, отдалённо напоминающий игровую сцену. Программы при этом работают, не зависают, наблюдаются только артефакты в графике. Также почему-то не работает загрузка файла по RS-232, серверная часть (на IBM-PC) получает ошибочный байт запроса передачи тела файла, в результате чего вываливается с ошибкой протокола, а Орион, соответственно, вываливается по ошибке тайм-аута (сервер не ответил).
В обычном режиме (такт ЦПУ 5 или 10 МГц) всё вышеперечисленное ПО работает нормально.

Попытался обнаружить, какой код вызывает глюки. Изначально грешил на олдскульный звук через INTE (для ВМ80), думал, что на малой скорости в короткие моменты подачи команды EI прерывания успевают "зацепиться" и вызвать непредсказуемое поведение программ.
Для "раскопок" я дизассемблировал небольшую программу REKL$ и стал затыкать NOP'ами потенциально проблеммные участки кода.
В результате, предположение насчёт активизации прерываний не подтвердилось, а выяснилось, что проблему вызывает следующий код:

MVI A,1
STA 0FA00H

Если меняю этот код на такой:

MVI A,1
OUT 0FAH

то программа в режиме "2,5 МГц" работает без глюков, со всеми спецэффектами.

Идеологически оба этих кода совершенно равнозначны, и в дефолтном режиме исполняются одинаково. Почему первый вариант глючит в режиме пониженной тактовой частоты ЦПУ - загадка.

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

У кого какие мысли?


П.С. переключение в режим "2,5 МГц" делается установкой бита D5 порта #0Ah, с помощью утилиты 2,5MHZ$.

[BYTEMAN]

П.С. переключение в режим "2,5 МГц" делается установкой бита D5 порта #0Ah, с помощью утилиты 2,5MHZ$.

Из монитора можно, там вроде бы команда 2.

[Denn]

Из монитора можно, там вроде бы команда 2.

Там хитро. Нужно считать содержимое порта, установить в лог."1" только причинный бит (ORI 20H), записать обратно в порт. Тобишь остальные биты порта не трогать.

[Error404]

С тактированием здесь черт ногу сломит: десяток микросхем обеспечивают какую-то мутную (по сравнению с Орионом-128) логику. Какие-то D-триггеры что-то синхронизируют в полдюжине мест... чума. Зато опять ИЕ5 в делителях, а не синхронные ИЕ7. При этом еще и процу WAIT-ты генерируются - как периодические от тактирования (D28 + D115 и D104 + D14 - этот генератор отключается при включении режима 2.5М), так и при любом обращении как к портам, так и памяти независимо от режима 2.5М (D87 D22), причем для портов по OUT и по LDA проц будет пристанавливаться на время различающееся вдвое.

Это первый лист альбома схем, прям по центру листа. При этом запись в D99 (порты F400..FA00) идет без учета /WAIT, сразу по сигналу /MREQ (из расчета что проц сам отработает накладывающиеся /MREQ/IORQ и /WAIT и просто получится более длинный чипселект для портов). Я бы предложил попробовать переключить выводы 10 и 13 D22 оба на один и тот же выход D87 - на 7 или на 10 (чтобы для начала исключить разницу между OUT и STA). Надо пробовать и длинный и короткий WAIT и выбрать что выгоднее (попробовать все режимы 2.5/5/10 на стабильность и на "стало быстрее или медленнее", т.к. выбрать надо более быстрый вариант если стабильны оба).

Влиять вполне может, т.к. со всех генераторов /WAIT смешивается на диодном "монтажном ИЛИ", я насчитал как минимум 3 диода (и соответственно 3 генератора, два из которых весьма высокочастотные, а третий - единичные "иголки"). Т.е. какой там меандр на входе проца - сами понимаете.

Хотя если честно, нафига делается WAIT для IORQ мне совсем не понятно. Разве что для дисковода на 2,5М? И вообще, смущает такое количество вейтов на каждый чих: не лишку ли их там? В моем понимании, должно бы быть реализовано "прозрачное ОЗУ" проца для 5МГц (т.к. 5МГц это скорость работы ОЗУ), а 10М и 2,5М синхронизировать уже вейтами. Так было сделано в ташкентском Турбо и питерских схемах турбирования Ориона-128 удвоением. Но на ПРО похоже как-то все хитрее, и не получатся ли ПРО-шные 5МГц медленнее честных 5МГц?

[BYTEMAN]

Там хитро. Нужно считать содержимое порта, установить в лог."1" только причинный бит (ORI 20H), записать обратно в порт. Тобишь остальные биты порта не трогать.

В мониторе Ориона-ПРО уже встроены команды переключения частоты) Вроде как команды "2" и "8" без аргументов

[Denn]

Вэйтятся порты скорее всего из-за того, что там ВВ55, которые тупо не смогут на такте выше 2,5 МГц. А на этих ВВ55 там всё, даже конфигурация компа.
Но сабжевая проблема не завязана на ВВ55. Я бы ещё понял, если бы трабл имел место при увеличении частоты, а тут наоборот!

Хочется понять вот что. Если это глобальный идеологический глюк ПРК ОРИОН-ПРО, то и пёс с ним, просто тупо в софте переделываем обращение к портам на "нормальное" (по IN/OUT) и объявляем, что "вот эта версия программы для Ориона-ПРО". Если же это глюк исключительно новодела, а в оригинале его нет, тогда очень желательно раскопать, т.к. возможны ещё и другие его последствия... помнится, не запускалась некая ОРДОС-6 на новоделе, а в симе и (вроде бы?) на "староделе" она работает, может ноги растут из этого же глюка с портами?..

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

В мониторе Ориона-ПРО уже встроены команды переключения частоты) Вроде как команды "2" и "8" без аргументов

Только мне толку от этого никакого, т.к. для загрузки ОС нужно выйти в главное меню, а для этого нужно нажать Reset и настройка скорости скинется на дефолтную
А я хотел написать bat-файл для запуска старинной игрули от Ориона-128, где сначала будет запускаться утилита-тормозилка, а за ней уже сама игруля.

[Error404]

Если же это глюк исключительно новодела, а в оригинале его нет, тогда очень желательно раскопать, т.к. возможны ещё и другие его последствия... помнится, не запускалась некая ОРДОС-6 на новоделе, а в симе и (вроде бы?) на "староделе" она работает, может ноги растут из этого же глюка с портами?..

Как раз BYTEMAN и может это проверить.

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

Вэйтятся порты скорее всего из-за того, что там ВВ55, которые тупо не смогут на такте выше 2,5 МГц. А на этих ВВ55 там всё, даже конфигурация компа.

Пожалуй. Хотя даже 580ВВ55А на 5МГц запускались все (а в схеме ПРО что для 5 что для 10 - одинаково вейтится) Учитывая, что я затарил для ПРО 82с55, пожалуй потом попробую отключить лишние вейты. В особенности вот этот узел, в который явно забыли добавить еще пару гейтов, который включали бы вейты только для ВВ55, а не для всех портов. И только для режима 10М, а не всей памяти на всех частотах.



как раз этот узел и делает два вейта вдвое разной длины - для портов и памяти

[BYTEMAN]

Как раз BYTEMAN и может это проверить.

У меня в орионе были глюки что не работала клавиатура в части старых игр... Но реклама работала стопудово как в медленном так и быстром режиме.

[Denn]

Но реклама работала стопудово как в медленном так и быстром режиме.

Действительно 100-пудово или 99-ти?

Я написал пост о баге после того, как убедился, что как минимум ещё у одного владельца ПРО глюк воспроизводится точно также. А это значит, что оно системное. По крайней мере в новодельном варианте.

Мне теперь интересно понять природу глюка, т.е. ЧТО случается с видеоконтроллером, что он так глючит? Насколько я понимаю, проблема с записью в порт может привести лишь к записи туда по факту какого-то байта, отличного от записываемого. Но что такое нужно записать в порт #FAh, чтобы вообще не работали ни какие эффекты переходов (в рекламной демке) и был мусор вместо полноценной картинки в играх? Попробую на досуге поиграться, позаписывать разные значения, может хоть как-то дело прояснится.

Но есть ведь ещё глюки COM-порта, с ними надо тоже что-то решать...