Периферия "ОрионПро"

[ksanf(138)]

Ты же пишешь что уже собрал ее?

Ну да. По шёлку. А сейчас не видно где чего. Блин, как я запарился мелочёвку тулить! Но, вроде ничё, работает.

[АлександрПП]

музыка запела , в плеере AYPLAY$

Добрался наконец-то до паяльника. Поставил собранную ранее новую плату COM-AY.Работает этот же плеер, программа авторов demo$. Тест по-прежнему пишет, что нет микросхемы. Ну и хрен с ним.

чего бы заюзать для проверки Спектрумовской дешифрации?

Аналогичный вопрос.

[Error404]

Сообщение от ksanf(138) Посмотреть сообщение
чего бы заюзать для проверки Спектрумовской дешифрации?

Аналогичный вопрос.

Проще всего - игрушками с этого диска. Надеюсь, какие-то из них запустятся и на ПРО. На этом же диске есть резидентный плеер для трекерных SND,ASM,ST,STM форматов файлов - USER_15\unipl2.com, но нет самих файлов - их надо взять с других дисков, например из архива во вложении. В архиве есть плеер PLAY.COM (нерезидентный), он для Альтаир-ДОС или ACPM т.к. использует ESC-коды стандарта 480С (в ПРОДОС почему-то не играет, не говоря о том, что в ПРОДОС искейпы драйвера экрана внедрены по принципу "сделано не нами"), проигрывает только ST,STM.

[Дмитрий2012]

Не знаю куда лучше запостить, оставлю здесь. Проигрыватель unipl2.com для тех, кто не будет собирать доработку для спектрумовской дешифрации.

[Дмитрий2012]

Решил еще раз вернуться к контроллеру IDE-RTC. Надо все-таки настраивать платку. Имеющиеся тесты она не проходит. На этот раз решил посмотреть, что все-таки читается в память с жесткого диска. Для этого у нас на прошке есть режим загрузки системы с жесткого диска. В моем случае, в качестве диска использовал компакт флеш карту с записанным образом Альтаир-ДОС. Так вот, информация с диска читается, но как-то странно. Считанные контроллером с диска младший и старший байты повторяются два раза подряд. Может у кого из схемотехников будут какие-нибудь предположения почему так может происходить? А еще лучше, чтобы кто-нибудь из спецов проанализировал схему, может в схеме остались ошибки?

Также нашел исходник, в котором есть участок кода работы с жестким диском. Хорошо бы программист еще посмотрел бы этот код, может чего в нем намудрили, и возможно платка у нас рабочая, а проблема в «корявом» софте?

[Error404]

Так вот, информация с диска читается, но как-то странно. Считанные контроллером с диска младший и старший байты повторяются два раза подряд. Может у кого из схемотехников будут какие-нибудь предположения почему так может происходить? А еще лучше, чтобы кто-нибудь из спецов проанализировал схему, может в схеме остались ошибки?

Также нашел исходник, в котором есть участок кода работы с жестким диском. Хорошо бы программист еще посмотрел бы этот код, может чего в нем намудрили, и возможно платка у нас рабочая, а проблема в «корявом» софте?

Сдается мне, надо в низовых подпрограммах чтения и записи блока с IDE тупо забить nop-ами одно лишнее чтение/запись и один лишний инкремент адреса по буферу. Разбираться - дольше. Остальное похоже работает, прочие блоки (кроме первого) же читаются?

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

Кстати, по исходнику с HDD читается 512 байт. Не понятно с чего бы там читаться задвоенному. Разве только железка по обращению к DATAL/DATAH (58H/57H) где-то не формирует целый импульс, а только половинку (и происходит двойное чтение того же слова, что и на предыдущей итерации). А после второй половинки управляющего импульса (когда мы уже второй раз читанули оттуда слово), HDD выдает из регистра следующее слово сектора.

[Advertiser]

[OrionExt]

Интересненнько. Читать одинаковые 8-bit. С портов 2-х)

[HardWareMan]

Насколько я помню, конвертер 8-16 сделан обычно на 1 двухстороннем регистре и шинном формирователе. Регистр доступен всегда. По направлению к HDD данные записываются в любое время процессором, по направлению от HDD считываются в любое время. При обращении к шинному формирователю, формируется однократное обращение к регистру данных 16 бит, используя данные из вышеупомянутого регистра (для D8-D15) и шины через шинный формирователь (для D0-D7). Таким образом, при записи в HDD, сначала заполняются данные для D8-D15 в регистре расширения, потом пишутся в D0-D7. А при чтении следует делать наоборот: сначала считывать D0-D7, а потом забирать данные D8-D15 из регистра. Нарушение порядка приводит к дублированию байт. а теперь скажите мне, прав ли я конкретно в вашем случае?

[Error404]

а теперь скажите мне, прав ли я конкретно в вашем случае?

Так посмотри, схема в первом посте
Я эти "англофильские" схемы с круглыми элементами где только ножки подписаны, читать не могу на физиологическом уровне.

[HardWareMan]

Я эти "англофильские" схемы с круглыми элементами где только ножки подписаны, читать не могу на физиологическом уровне.

Я тоже.

Как я и думал. Более того, буфер младших данный не отключается! И при чтении он потенциально может создавать конфликт шины. Я понимаю экономисты, но должна быть мера во всем. Кто проектировал эту ересь?