ПК8000 - Контроллер дисковода

[DemonId7]

Ну дык я дал листинг инициализации контроллера, где явно запись на адрес 0x7FF7. Если этого мало, то в обработчике таймера есть такой код:

H = INP(0x80)
OUTP(0x80), 0xFF
L = [0x7FF7]
OUTP(0x80), H
[0x7FF7] = 0
OUTP(0x80), 0xFF
[0x7FF7] = L            ; restore [0x7FF7]
OUTP(0x80), H           ; restore map mem

Тоже что-то пишет в 0x7FF7.
Схему еще не глядел, но вполне допускаю, что РТ2 принесет немало сюрпризов

---------- Post added at 17:27 ---------- Previous post was at 16:59 ----------

Кстати, а с чего взяли, что ТМ8 отображается на 0x7FF7? По схеме она защелкивается от ~WR и сигнала с вывода 13 дешифратора РТ2. Начинки то РТ2 нет?

[Advertiser]

[Mifody]

Тут писали. И Тут. И ещё судя по схеме замены РТшки так выходит..

[b2m]

4000-7F?? - ПЗУ
7FF7 - выбор стороны и диска
7FF8-7FFB - порты ВГ93
7FFC-7FFF - 4-х байтовый регистр (запись - как обычно, чтение - по всем 4-м адресам один и тот-же байт, 2 младших бита адреса это DRQ,IRQ ВГ93)

[DemonId7]

Логично. И если же это действительно ТМ8, то инициализация почти понятна:

START_ROM:
  [0xEE1D] = 0
  [0x7FF7] = 0x81 - сброс контроллера
  [0x7FF7] = 0x01 - выбор устройства 0
  WAIT(0x01) - запись команды (init?)
  [0x7FF7] = 0x82 - сброс контроллера
  [0x7FF7] = 0x02 - выбор устройства 0
  WAIT(0x02)
  [0x7FF7] = 0x00

Тогда что читается с адреса 0x7FF7? По схеме с ТМ8 точно ничего не прочтешь, однако программа не только читает, но и судя по всему именно значение в ТМ8... Может ИР26 и предназначена для хранения значение ТМ8?

[b2m]

Тогда что читается с адреса 0x7FF7?

Не помню. Защита записи, индексный маркер или другие сигналы непосредственно с дисковода.

Может ИР26 и предназначена для хранения значение ТМ8?

Для чего предназначена ИР26 (7FFC-7FFF) я уже объяснял, Mifody выше дал ссылки. Это такой аппаратный трюк, позволяющий ожидать готовность байта в цикле, длительность которого всего 4 такта.

[DemonId7]

Не помню. Защита записи, индексный маркер или другие сигналы непосредственно с дисковода.

Непосредственно с дисковода не прочтешь, схемой не предусмотрено. Остается одно объяснение - читают то, что записалось в ОЗУ по тому же адресу, при последней записи в ПЗУ. То есть пользуются особенностью записи ПК. Трюк короче.

Для чего предназначена ИР26 (7FFC-7FFF) я уже объяснял, Mifody выше дал ссылки. Это такой аппаратный трюк, позволяющий ожидать готовность байта в цикле, длительность которого всего 4 такта.

Да, нашел в коде инициализацию этих регистров и ОЗУ с 0x8000.

[DemonId7]

Нужно хотя бы иногда спать ложиться, а то не заметил вчера оченьвидных вещей
Теперь все ясно. Основной блок данных для функций ПЗУ располагаются в адресах 0xEE21-0xEE3D. Это не считая "рабочих" переменных, как например формируемый байт управления дисководом по адресу 0xEE20 (тот самый байт, что засылается в 0x7FF7). Не выяснял полностью, но картина следующая:

      ; логическая адресация по типу CP/M
0xEE21: logDisk:        .db ?   ; номер диска [0-1]
0xEE22: logTrack:       .db ?   ; лог. номер дорожки
0xEE23: logSector:      .db ?   ; лог. номер сектора
0xEE24: dmaBuff:        .dw ?   ; адрес обмена
0xEE26: typeSector:     .db ?   ; тип записываемого сектора:
0xEE26:                         ;    0: обычный сектор
0xEE26:                         ;    1: из области директория
0xEE26:                         ;    2: первый сектор нового блока
      ; здесь пошла физическая адресация
0xEE27: byte_EE27:      .db ?
0xEE28: byte_EE28:      .db ?
0xEE29:                 .db ?
0xEE2A: byte_EE2A:      .db ?
0xEE2B: byte_EE2B:      .db ?
      ; данные о последней операции записи на диск
0xEE2C: _wrDisk:        .db ?
0xEE2D: _wrTrack:       .db ?
0xEE2E: _wrSector:      .db ?
0xEE2F: _wrSide:        .db ?
0xEE30: wr_EE30:        .db ?
      ; данные о последней операции чтения с диска
0xEE31: _rdDisk:        .db ?
0xEE32: _rdTrack:       .db ?
0xEE33: _rdSector:      .db ?
0xEE34: _rdSide:        .db ?
      ; данные о текущей операции чтения/записи
0xEE36: physDisk:       .db ?   ; номер диска
0xEE37: physTrack:      .db ?   ; номер дорожки = (logTrack >> 1) & 0x7F
0xEE38: physSector:     .db ?   ; номер сектора = (((logSector-1) >> 3) & 0x07) + 1
0xEE39: physSide:       .db ?   ; сторона = logTrack & 1
0xEE3A: nSecInBuff:     .dw ?   ; адрес 128-байтного сектора в буфере обмена = (logSector-1) >> 1

0xEE3C: lastTrack:      .db ?   ; номер дорожки в последней операции с диском
                                ; (нужен для операции позиционирования головок)
0xEE3D:                 .db ? ; то же для диска 1

Функции чтения/записи работают с логическими адресами, как в CP/M, самостоятельно переводя их в физические. Операции чтения и записи имеют свой набор данных и адреса буферов. Чтение происходит на адрес 0xE600, а запись с адреса 0xEA00. А уж затем нужный 128-байтный сектор копируется в dmaBuff.

Но это так, мелочи. Что касается чтения регистров. Регистр 0x7FF7 читается исключительно из ОЗУ, а не из контроллера. Регистр 0x7FF8 читается прямо с ПЗУ, так как его значение формируется самой ВГ93 и выставляется на шину данных. Это я просто с недосыпу вчера не сообразил, что на адресах 0x7FF7-0x7FFF нет ПЗУ, а значения туда подставляются ИР26 и ВГ93, то есть с чтением проблем не будет.

В принципе уже можно написать простенькие тесты. Правда придется ПЗУ вытащить. По крайней мере можно проверить работу ТМ8 и ИР26. Есть желание?

[Mifody]

Правда придется ПЗУ вытащить.

От куда? Из компа или контроллера? Если с контроллера, то вобще без проблем. Если с компа, то с небольшими проблемами, но вытащу.. В общем желание есть. Надо же до конца доводить начатое.. Я двумя руками за!

---------- Post added at 12:18 ---------- Previous post was at 12:15 ----------

на адресах 0x7FF7-0x7FFF нет ПЗУ

То есть дешифратор ПЗУ должен перекрывать не 4000h-7FFFh, как сделано сейчас, а 4000h-7FF6h?

[hantarex]

тесты я просил написать еще месяца три назад у самого тяму не хватает

[DemonId7]

От куда?

С контроллера разумеется. Иначе я не представляю как загрузить тест, если ПЗУ зацикливается на чем-то.

То есть дешифратор ПЗУ должен перекрывать не 4000h-7FFFh, как сделано сейчас, а 4000h-7FF6h?

Не, перекрывать он должен именно 4000-7FFF. Просто значения 7FF8-7FFF при чтении берутся не с ПЗУ, а формируются самим контроллером и выдаются вместо ПЗУ. И дешифратор это должен как-то учитывать. Как именно - нужно еще раз схему повнимательнее глянуть. Схему замены РТ2 еще не разглядывал, так что здесь без коментариев.

Для начала попробуем самое простое - включение/выключение мотора и подвигаем головками. Вечером выкрою время. Дальше можно будет подумать как проверить ИР26, а потом и попробовать считать сектор. Это уже в лучшем случае не раньше воскресения (завтра работы много намечается).