ZXNet эхоконференция «code.zx»
тема: Каким образом осуществляется опрос
от: Konstantin Sviridov
кому: All
дата: 28 Nov 2005
Hello, GriV
Если говорить о HDD (ATA), то в далеком 94-м проблему ускорения передачи данных
в конроллере IDE для ZX-Next я решил, расположив порты (для старшей и младшей
половинок слова данных) в адресном пространстве так, что бы при выполнении
команды INI (OUTI) они перебирались последовательно.
В результате на запись слова (16 бит) тратилось 44, а на чтение 32 такта (более
200К в секунду). В турборежиме еще быстрее.
Разумеется, если порт один (или расположены "вразнобой"), то особо не
разгонишься...
от: Valery Grigoriev
кому: All
дата: 28 Nov 2005
Hello, All
внешних "быстрых" устройств?
Hапример, жёсткого диска??
Если брать стандартные
lab1:in a,(c)
rra
jr nz,lab1
in a,(c)
ld (hl),a
inc hl
jp lab1
в этом тексте даже проверки отсутствуют как таковые, но примерно получается
12+4+7+12+7+6+10 = 58 тактов, что даёт теоретическую скорость :D до 60 кб в
секунду :D (именно потому слово "быстрые" в кавычках), или это делается как то
иначе?
от: Чунин Роман
кому: All
дата: 28 Nov 2005
Hello, Conan
Con> Если говорить о HDD (ATA), то в далеком 94-м проблему ускорения
Con> передачи данных в конроллере IDE для ZX-Next я решил, расположив
Con> порты (для старшей и младшей половинок слова данных) в адресном
Con> пространстве так, что бы при выполнении команды INI (OUTI) они
Con> перебирались последовательно.
Con> В результате на запись слова (16 бит) тратилось 44, а на чтение 32
Con> такта (более 200К в секунду). В турборежиме еще быстрее.
Con> Разумеется, если порт один (или расположены "вразнобой"), то особо не
Con> разгонишься...
Ага в АТМ так же сделано.
от: Konstantin Sviridov
кому: All
дата: 29 Nov 2005
Hello, GriV
Gri> Hе понял, в смысле из-за уменьшения регистра B так?
Да, именно так.
Gri> т.е. если B=1F
Gri> C=FD
Gri> то первый outi шёл в 1ffd
Gri> а второй в 20fd
Gri> ?
Все верно, только адреса портов были другие.
Gri> и затем каждая команда чтения соответвтующего порта создаёт
Gri> автоматическое распознавание как готовность принять и соответственно
Gri> контроллер выдаёт все данные сам??
Hичего там не надо городить: последовательное расположение портов, это
банальная дешифрация, в которой задействован A8 (он выбирает старший/младший
разряды слова данных для IDE). Адреса старше A8 - не используем.
Gri> А можно и так
Gri> взять 256 команд
Gri> INI
Gri> а перед ними та же строчка инициализации - получается 16 тактов на
Gri> байт (быстрее программно нельзя - ограничение аппаратуры), итого
Gri> порядка 200 кб для обыкновенного режима, 400 кб для турбы!!!
Так и было сделано. 32 такта на слово это и есть 16 тактов на байт. Только не
надо обольщаться насчет турборежима: скорость будет зависеть от конкретной
реализации, ибо есть еще и торможение при работе с ОЗУ, а для некоторых клонов
и при операциях ввода/вывода.
от: Valery Grigoriev
кому: All
дата: 29 Nov 2005
Hello, Conan
Con> Если говорить о HDD (ATA), то в далеком 94-м проблему ускорения
Con> передачи данных в конроллере IDE для ZX-Next я решил, расположив
Con> порты (для старшей и младшей половинок слова данных) в адресном
Con> пространстве так, что бы при выполнении команды INI (OUTI) они
Con> перебирались последовательно.
Con> В результате на запись слова (16 бит) тратилось 44, а на чтение 32
Con> такта (более 200К в секунду). В турборежиме еще быстрее.
Con> Разумеется, если порт один (или расположены "вразнобой"), то особо не
Con> разгонишься...
Hе понял, в смысле из-за уменьшения регистра B так?
т.е. если B=1F
C=FD
то первый outi шёл в 1ffd
а второй в 20fd
?
А нельзя как то повесть полублоковую обработку - т.е. скажем проц выдаёт на
порт ожидание чтения
и затем каждая команда чтения соответвтующего порта создаёт автоматическое
распознавание как готовность принять и соответственно контроллер выдаёт все
данные сам??
Т.е. просто делает INIR на 256 значений
а перед ним идёт команда выбора сектора например ld bc,#fefe ld a,1 (команда
чтения) out (с),a
и далее
ld hl,mem_addr
ld bc,#00fd
inir
тогда (псевдоблоковый обмен) скокрость бы была очень приличная.
При чтении портов формируется IORQ - вместе с адресом чисто теоретически можно
вроде сделать такой контроллер?
Просто логика в том, что от жёсткого диска в таком случае прирост не столь
очевидный (кроме конечно же объяма и надёжности) - в лучшем случае в 10 раз
быстрее по сравнению с бетой.
А вот если использовать представленную схему получается условно 21 такт на один
байт - уже скорость получается приличная, а для турбы так вообще.
А можно и так
взять 256 команд
INI
а перед ними та же строчка инициализации - получается 16 тактов на байт
(быстрее программно нельзя - ограничение аппаратуры), итого порядка 200 кб для
обыкновенного режима, 400 кб для турбы!!!
от: jtn
кому: All
дата: 29 Nov 2005
Hello, Conan
Ага! ну начнем-с по порядку:
1) никаких ожиданий делать не нужно - сектор (512б) из хдд/цдд читается и
пишется и так на мах без задержек и проверок.
2) реализация контроллеров бывает разная. в худшем случае это полсотни тыщ байт
в секунду (хуже только флоповод уж будет=), а лучшая это 200кб в сек без турбо
и 400кб с турбо (в пзу/теневом озу 200%). именно так было сделано в моем
контроллере и контроллере спринтера, т.е. чтение - 512 команд ini (или 2 inir)
и запись 512 штук outi (два otir). причем спринтеровский вариант несколько
проще =)
3) в очередной раз напоминаю - в командах outi,otir,outd,otdr сначала
декрементируется рег.B и только потом пишется в порт.
не стоит заново поднимать этот вопрос, на форуме он уже активно обсуждался =)
от: Valery Grigoriev
кому: All
дата: 29 Nov 2005
Hello, jtn
jtn> не стоит заново поднимать этот вопрос, на форуме он уже активно
jtn> обсуждался =)
ух ты а где обсуждался?
от: jtn
кому: All
дата: 29 Nov 2005
Hello, jtn
jtn> не стоит заново поднимать этот вопрос, на форуме он уже активно
jtn> обсуждался =)
я про третий пункт
http://www.zx.pk.ru/showthread.php?t=1360&page=9&pp=10
от: SMT
кому: All
дата: 10 Dec 2005
Hello, GriV
Gri> Я бы даже более сказал - самый захудалый винт даёт скорость 10 метров
Gri> в сек
какие РУ5 потянут 10 м/с, с одновременным обслуживанием видео и процессора :)
даже с контроллером DMA (тогда что уж, можно и контроллер прерываний
одновременно вешать, чтобы 1 раз комп курочить) 1.75 м/с для винта маловато, и
это будет уже не спектрум
от: SMT
кому: All
дата: 10 Dec 2005
Hello, SMT
а самое главное, в каких это спековских задачах не хватает 400 kb/s?
от: Valery Grigoriev
кому: All
дата: 10 Dec 2005
Hello, SMT
SMT> а самое главное, в каких это спековских задачах не хватает 400 kb/s?
400 километров в секунду (для турбы и для хорошего контроллера и для хорошей
программы, оптимизированной) - это просто образная цифра, на самом деле
скорость то поменьше будет. А что 400 кб в секунду - это быстро???
Хотя наверное я загнался, на самом деле у жёлтого скорпиона у моего всего то
256 кб памяти, 1,5-2 секунды условно на загрузку всей памяти - не так уж и
плохо.
от: Valery Grigoriev
кому: All
дата: 10 Dec 2005
Hello, SMT
SMT> какие РУ5 потянут 10 м/с, с одновременным обслуживанием видео и
SMT> процессора :) даже с контроллером DMA (тогда что уж, можно и
SMT> контроллер прерываний одновременно вешать, чтобы 1 раз комп курочить)
SMT> 1.75 м/с для винта маловато, и это будет уже не спектрум
Контроллер DMA уже есть, правда в малых количествах - DMA USC.
А 10 метров в секунду - это просто показатель как мало имеем по сравнению с тем
что можно было б.
|