Да вот, расковырял у кое-кого в SPDOS... ;)
- - - Добавлено - - -
LeoN65816, изменения DRQ/INTRQ просто так внезапно не случаются, они являются следствием команд от ПО. Так что этот процесс вполне можно контролировать.
Вид для печати
Имеется в виду следующее. Дали команду и ушли на цикл ожидания. Флопик схавал команду не моментально, а значит по коду мы гарантированно успеем уйти на причинный цикл ожидания. Дальше действительно изменения прилетят "внезапно" по меркам ПО (но мы к этому готовы - причинный цикл ожидания), и после этого события никаких самопроизвольных изменений не будет, стало быть у кода будет возможность полностью отработать без "прерываний посреди дороги".
Denn, я тебя понял. согласен.
Ставим КП11 на переключение одного из адресов ПЗУ, допустим A4. КП11 переключает на вход ПЗУ то A4 от КР580, то бит готовности из ВГ93.Цитата:
Сообщение от LeoN65816
Ставим схему совпадений на область, например FFF0...FFFF, и когда процессор читает из этой области, то формируется сигнал на входе SELECT КП11, что приводит к тому, что на A4 ПЗУ поступает сигнал прямо, с обьединённых диодами 38-мой и 39-той ноги ВГ93.
В ПЗУ по адресу FFF0 стоит команда JMP FFF0, т.е процессор зациклен в бесконечной петле. Процессор выдаёт команду в ВГ93 на чтение сектора и затем делает JMP на FFF0, где и зависает в бесконечной петле. При этом на адрес A4 ПЗУ скоммутирован бит готовности с выхода ВГ93. ВГ93 считав байт с дискеты, выставляет готовность (на ногах 38 или 39), отчего на адресе A4 изменяется сигнал. И процессор читая из адресов FFF0...FFFF реально читает содержимое ПЗУ по адресу FFE0, где стоит процедура чтения очередного байта из ВГ93, засылка его по (HL), увеличение HL и снова JMP на FFF0.
Тут есть нюансы с синхронизацией, уровнями и т.п. но основная концепция такая. Я привёл вариант с ПЗУ, т.к именно коммутация ПЗУ обсуждалась, но эта же идея работает если коммутировать не адреса ПЗУ, а всего один бит читаемый из ПЗУ (как младший адрес).
Но все подобные химические варианты громоздки. Достаточно вторым этажом поставить 1 триггер 155 ТМ2, кинуть пару проводков и заменить кварц 8 МГЦ на 9 МГЦ. Одним выстрелом куча зайцев - и CPU скворчит быстрее, и экран целиком влезает в телевизор и НГМД нормально пишет, причем с более простым типовым контроллером от "Корвета", без доп.микросхем для 38-й ноги.
Во-первых, про доступность ВГ93.Цитата:
Сообщение от makbar
В крупных городах были нелегальные радиорынки, где ВГ93 были доступны еще в 1988, когда начали ставить TR-DOS в ZX-Spectrum. Я без всяких проблем купил ВГ93 в 1989. Но для предприятия выпускающего МИКРОШУ получить поставку ВГ93 возможно было проблемой, т.к продукция МЭП распределялась министерствам и заводам поштучно.
Но дело вовсе не в дефицитности или доступности, а в том, что простым способом, т.е заимствуя программу и контроллер от "Корвета" в РК86 дисковод не поставить, т.к в ней стоит идиотский ПДП, который каждые 8 МКСЕК рвёт прогон программы.
Можно конечно отключать ПДП, гасить экран (как при вводе с МГ) и читать из ВГ93, попутно делая каждые 20 команд POP, чтобы ОЗУ регенерировалось. Но сидеть с погашенным экраном по пол-минуты неприятно. Кроме того на DD скоростей РК86 всё-равно не хватало. А те же 400 кб даёт и РК-КНГМД, причём с большей надёжностью.
Поэтому остаётся только вариант с ПДП, и как я ранее указывал, такой вариант работал на РК86 уже в 1989 (один КООП продавал это, но спроса не имел, т.к дисководы ещё стоили очень дорого, более 500 рублей). В общем, проблема была в том, что для РК не нашлось грамотного программиста и аппаратчика, кто бы смог разработать свой вариант с использованием второго канала ПДП. Это смогли сделать (или где-то достали ИНФО) только инженеры завода, где выпускались ПАРТНЁРЫ. Но и там массового выпуска КНГМД не было.
Поэтому фанаты РК86 до 01.1993 сидели без дисковода. Затем появился Е.Седов и решил разом проблемы дисковода и для РК86 и для СПЕЦИАЛИСТА. Хотя СПЕЦИАЛИСТ к тому времени частично "умер", частично был конвертирован в MX, где дисковод уже был по варианту Л.Афанасьева из Барнаула.
- - - Добавлено - - -
Есть ещё один вариант решения скоростной проблемы СПЕЦИАЛИСТА при работе с дисководом.
Это если кому-то обязательно надо сохранить такт CPU ровно в 2 МГЦ. Тогда кроме выше-упомянутых "химических" способов, остаётся только замена КР580 на 1821ВМ85 (8085). В котором есть однобитовый вход, позволяющий быстрее проверять аппаратный флаг готовности ВГ93.
Неужели 64 такта (MFM 250Кбит/с, тактовая 2МГц) или 80 тактов (тактовая 2.5МГц) не хватает на чтение/запись байта и поллинг запроса данных? В АГАТе 32-х тактов свободно хватает.
На Орионе с тактом 2,5 МГц мне удалось "обмануть физику" так:
Причём счёт буквально на единицы тактов МП! Если вместо "ANA C" ставим "ANI 03H", то не успеваем.Код:; PЕГИСТРЫ УПРАВЛЕНИЯ КОНТРОЛЛЕРОМ:
;RG_CMD:EQU 0F700H; Р-Р КОМАНД/СОСТОЯНИЯ
;RG_TRK:EQU 0F701H; Р-Р ДОРОЖКИ
;RG_SEC:EQU 0F702H; Р-Р СЕКТОРА
;RG_DAT:EQU 0F703H; Р-Р ДАННЫХ
LD_SECT:
; I: [BC] - RG_DAT
; [DE] - RG_CMD
; [HL] - АДР.НАЧ. target
JMP LDCIKL
LDCIK0:
MOV M,A
INX H
LDCIKL:
; ЦИКЛ ЧТЕНИЯ СЕКТОРА
LDAX D ; = IN RG_CMD
ANA C ; = ANI 03H
JPO LDCIKL
LDAX B ; = IN RG_DAT
JNZ LDCIK0
...
Везение тут получилось очень удачное, младшая часть адреса регистра данных как раз содержит значение маски нужных битов 03h, в итоге "долгую" команду "ANI 03H" (7 тактов) удалось заменить на равнозначную "быструю" "ANA C" (4 такта), и "пазл сложился".
Ну и игра с флагом чётности тоже очень в кассу.
Если бы не эти два обстоятельства, то иначе не получилось бы разрулить без аппаратного регистра DRQ/INTRQ.
Имхо, регистр на DRQ/INTRQ проще, чем замена проца.