Ну да. По шёлку. А сейчас не видно где чего. Блин, как я запарился мелочёвку тулить! Но, вроде ничё, работает.
Вид для печати
Проще всего - игрушками с этого диска. Надеюсь, какие-то из них запустятся и на ПРО. :) На этом же диске есть резидентный плеер для трекерных SND,ASM,ST,STM форматов файлов - USER_15\unipl2.com, но нет самих файлов - их надо взять с других дисков, например из архива во вложении. В архиве есть плеер PLAY.COM (нерезидентный), он для Альтаир-ДОС или ACPM т.к. использует ESC-коды стандарта 480С (в ПРОДОС почему-то не играет, не говоря о том, что в ПРОДОС искейпы драйвера экрана внедрены по принципу "сделано не нами"), проигрывает только ST,STM.
Не знаю куда лучше запостить, оставлю здесь. Проигрыватель unipl2.com для тех, кто не будет собирать доработку для спектрумовской дешифрации.
Решил еще раз вернуться к контроллеру IDE-RTC. Надо все-таки настраивать платку. Имеющиеся тесты она не проходит. На этот раз решил посмотреть, что все-таки читается в память с жесткого диска. Для этого у нас на прошке есть режим загрузки системы с жесткого диска. В моем случае, в качестве диска использовал компакт флеш карту с записанным образом Альтаир-ДОС. Так вот, информация с диска читается, но как-то странно. Считанные контроллером с диска младший и старший байты повторяются два раза подряд. Может у кого из схемотехников будут какие-нибудь предположения почему так может происходить? А еще лучше, чтобы кто-нибудь из спецов проанализировал схему, может в схеме остались ошибки?
Также нашел исходник, в котором есть участок кода работы с жестким диском. Хорошо бы программист еще посмотрел бы этот код, может чего в нем намудрили, и возможно платка у нас рабочая, а проблема в «корявом» софте?
Сдается мне, надо в низовых подпрограммах чтения и записи блока с IDE тупо забить nop-ами одно лишнее чтение/запись и один лишний инкремент адреса по буферу. Разбираться - дольше. Остальное похоже работает, прочие блоки (кроме первого) же читаются?
- - - Добавлено - - -
Кстати, по исходнику с HDD читается 512 байт. Не понятно с чего бы там читаться задвоенному. Разве только железка по обращению к DATAL/DATAH (58H/57H) где-то не формирует целый импульс, а только половинку (и происходит двойное чтение того же слова, что и на предыдущей итерации). А после второй половинки управляющего импульса (когда мы уже второй раз читанули оттуда слово), HDD выдает из регистра следующее слово сектора.
Интересненнько. Читать одинаковые 8-bit. С портов 2-х)
Насколько я помню, конвертер 8-16 сделан обычно на 1 двухстороннем регистре и шинном формирователе. Регистр доступен всегда. По направлению к HDD данные записываются в любое время процессором, по направлению от HDD считываются в любое время. При обращении к шинному формирователю, формируется однократное обращение к регистру данных 16 бит, используя данные из вышеупомянутого регистра (для D8-D15) и шины через шинный формирователь (для D0-D7). Таким образом, при записи в HDD, сначала заполняются данные для D8-D15 в регистре расширения, потом пишутся в D0-D7. А при чтении следует делать наоборот: сначала считывать D0-D7, а потом забирать данные D8-D15 из регистра. Нарушение порядка приводит к дублированию байт. а теперь скажите мне, прав ли я конкретно в вашем случае?
Я тоже.
http://savepic.ru/10857547.png
Как я и думал. Более того, буфер младших данный не отключается! И при чтении он потенциально может создавать конфликт шины. Я понимаю экономисты, но должна быть мера во всем. Кто проектировал эту ересь?