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 метров в секунду - это просто показатель как мало имеем по сравнению с тем что можно было б.




Темы: Игры, Программное обеспечение, Пресса, Аппаратное обеспечение, Сеть, Демосцена, Люди, Программирование

Похожие статьи:
Злoбa дня - Обрaтнaя cтoрoнa эmyлятoрoв.
Пользователям - программа "сжатия" для сжимания текстовых файлов.
Реклама - Покупка/продажа/обмен progz 4 SPECCY.
Обмен опытом - отчет SerzhSoft'a о региональной олимпиаде 98 года по информатике.
FAQ - описание игры "12 тайных книг".

В этот день...   8 мая