nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 05:03



Reply to topic  [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
FDD-контроллер для NedoPC 
Author Message
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
Ball Bess wrote:
Ну, появись шина, сразу найдётся, что туда воткнуть. Но тогда её эмуляция - это отдельная задача, напрямую с FDD и не связанная. Как она может выглядеть аппаратно - отдельный вопрос (для отдельной темы). Можно обсуждать.
По FDD на 765-м чипе сейчас ближайшая задача, как оно мне представляется - выяснить, можно ли обойтись без DMA, справится ли проц самостоятельно. Хотелось бы "хай денсити" (500 кбит/сек), если не получится, то может с "дабл денсити" справится (250 кбит/с). При этом сохраняется максимальная аппаратная простота. Если он этого не сможет, то тогда ему нужна помощь (то ли DMA-контроллер, то ли MCU, обслуживющий дисковую подсистему, то ли ещё что, вариации разные могут быть, но чем сложнее, тем меньше вероятность, что всё это выйдет из стадии обсуждений на практический уровень).


Специальный микроконтроллер, обслуживающий контроллер дисков, мне кажется вполне разумным решением

_________________
:dj: https://mastodon.social/@Shaos


24 May 2006 19:33
Profile WWW
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
Post 
500Кбит/сек даже старенький MCS51 программно осилит. Тем более что сектора обычно не более 512 байт. Даже FAT12/16 можно поддержать аппаратно. Мне вот интересно, почему разработчики PC так и не сделали полностью буферированный флопоконтроллер... А то как в анекдоте про многозадачность... ;)


24 May 2006 19:46
Profile
Doomed

Joined: 16 Apr 2005 22:35
Posts: 492
Location: Томск
Reply with quote
Post 
Shaos wrote:
По поводу армов у меня пока сложилось предубеждение, что они сугубо антилюбительские девайсы...


Интересно почему ?


24 May 2006 20:53
Profile
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
jdigreze wrote:
500Кбит/сек даже старенький MCS51 программно осилит. Тем более что сектора обычно не более 512 байт.

Между прочим, у Ориона и Специалиста сектора 5х1024 байт, у Спектрума - 16х128 байт, M$ выбрала 9х512 байт. А контроллер поддерживает сетку: 128/256/512/1024 байт. Так что все-таки надо до килобайта держать. Далее, если МК сможет программно перекидывать в/из флоповод/а в свой буфер хотя-бы один сектор (в идеале целую дорожку, чтобы можно было аппаратно форматировать), то все будет пучком, т.к. флаг BUSY есть для этого. Все винты уже давно как так делают. :)


24 May 2006 20:54
Profile
Maniac
User avatar

Joined: 14 Mar 2006 00:20
Posts: 211
Location: Иркутск
Reply with quote
Post 
jdigreze wrote:
500Кбит/сек даже старенький MCS51 программно осилит. Тем более что сектора обычно не более 512 байт.

А на что тут размер секторов влияет? В смысле нагрузки на проц. Главное, чтобы во время обработки сектора темп выдерживать, успевать к очередному байту, а длинный сектор или короткий... :o
Устанет проц, на перекур запросится? :D
Или это уже речь о поддержке посредством MCU? Что, типа, на размер буфера влияет? Так буфер дорожки - самое то.

_________________
Кто мешает тебе выдумать порох непромокаемый?


24 May 2006 21:10
Profile
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
Post 
HardWareMan wrote:
у Спектрума - 16х128 байт

Всегда было 256 байт на сектор.

Quote:
M$ выбрала 9х512 байт.

Фактически в MS-DOS сектор может быть до 2048 байт.

_________________
Extreme Entertainment


24 May 2006 22:18
Profile
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
Post 
HardWareMan wrote:
Между прочим, у Ориона и Специалиста сектора 5х1024 байт, у Спектрума - 16х128 байт, M$ выбрала 9х512 байт. А контроллер поддерживает сетку: 128/256/512/1024 байт. Так что все-таки надо до килобайта держать. Далее, если МК сможет программно перекидывать в/из флоповод/а в свой буфер хотя-бы один сектор (в идеале целую дорожку, чтобы можно было аппаратно форматировать), то все будет пучком, т.к. флаг BUSY есть для этого. Все винты уже давно как так делают.

У iS-DOS тоже 5х1024. Но это не принципиально. Т.е. если делать РАМу в размер трека, то получится не больше 16К. Кстати, для форматирования такого объема и не надо, там данные можно паковать в стиле "байт/кол-во", все влезет и в пару-тройку Кб.
Ball Bess wrote:
А на что тут размер секторов влияет? В смысле нагрузки на проц. Главное, чтобы во время обработки сектора темп выдерживать, успевать к очередному байту, а длинный сектор или короткий...
Устанет проц, на перекур запросится?
Или это уже речь о поддержке посредством MCU? Что, типа, на размер буфера влияет? Так буфер дорожки - самое то

Собственно говоря, размер сектора влияет только на кол-во необходимой оперативки. А темп держать по прерываниям не так и сложно. Тут недалеко я выкладывал исходник программного анализа i2c на at89c2051, при кварце 11059,2кГц скорость была, если не забыл, около 40Кбайт/сек получилась. Так там анализ последовательной шины в реалтайме. Здесь гораздо проще.Если в качестве контроллера использовать mega8515 с внешней РАМой, то обработать поток из Z0765 будет не проблема.


24 May 2006 22:36
Profile
Maniac
User avatar

Joined: 14 Mar 2006 00:20
Posts: 211
Location: Иркутск
Reply with quote
Post 
Фактически, что касается размера сектора - то возможности контроллера - это одно, а то, как этими возможностями пользуются разработчики операционок - это другое.
Названная HWM сетка от 128 до 1024 - это для ВГ93. Создатели ТР-ДОС выбрали 256х16, форматтер IS-DOS форматирует 1024х5 (а можно ли в IS-DOS задать другое значение - я не знаю, не удосужился разобраться с этой системой).
765-й чип даёт разработчикам операционок (или программ форматирования) при MFM набор значений от 256 до 8192. Ну, видно не сочли нужным разработчики MS-DOS включать сектора по 4 или 8 кб (если 8 - то это один на дорожке?).
А вообще-то штатно у микрософта выбрано 512 байтов, факт общеизвестный. Для DD - 9 секторов, а для HD (высокая плотность) - у пятидюймовых 15 секторов, а у самых ходовых сейчас трёхдюймовых 1,44 Мб - 18 секторов.
Quote:
А темп держать по прерываниям не так и сложно

Если есть запас, можно и по прерываниям, а когда всё впритык, то чтобы не тратить время на вызов прерывания (там же сохранение регистров ещё время займёт) можно как в спековском Бета-диске сделать, выход IRQ ВГшки не вызывает прерывания. Там он подключен нештатно, не к системе прерываний, а подведён к доступному для чтения регистру и хост при обработке сектора всё время опрашивает этот бит, ожидая готовности FDC. Ну, если всё впритык, то долго опрашивать не приходится, раз-два и вот он запрос. Если цикл опроса грамотно написан и достаточно короткий, то так экономнее, чем по прерываниям.
P.S. А если речь идёт про вспомогательный MCU, который для поддержки хоста, то какие там ещё у него важные дела могут быть, чтобы он к своему родному и любимому FDC поворачивал взгляд лишь по прерыванием. :D . Да у него и дел то других особо быть не должно, кроме как следить за тем, чем его FDC занят. (Шутка. Как будет конкретно - надо подумать).

_________________
Кто мешает тебе выдумать порох непромокаемый?


24 May 2006 23:33
Profile
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
Post 
На сколько я понял, прерываение нужно "схватить" за 13мкс. MCS51 может успеть это сделать только на пределе возможностей. И то не на прерываниях. Слишком медленные условные переходы у этого процессора. А вот AVRику должно быть не так напряжно.


25 May 2006 00:54
Profile
Maniac
User avatar

Joined: 14 Mar 2006 00:20
Posts: 211
Location: Иркутск
Reply with quote
Post 
jdigreze wrote:
На сколько я понял, прерываение нужно "схватить" за 13мкс. MCS51 может успеть это сделать только на пределе возможностей. И то не на прерываниях. Слишком медленные условные переходы у этого процессора. А вот AVRику должно быть не так напряжно.

Во, вижу, что документ читать начал.
Так вот. Это всё так, если готовые байты, уже в параллельном виде FDC поставляет, а прикинь, если без FDC сам микроконтроллер будет поток с дисковода анализировать! Там MFM кодирование не позволяет всё побитно сразу складывать в байт, описанная мною где-то выше картина, что принимаем бит за битом, собрали байт и отдали хосту - это очень большое упрощение реальной картины, на самом деле смысл очередного перепада не ясен, пока не приняты и другие перепады. Только после того, как их принято несколько, их можно расшифровать все вместе. А расшифровывать надо не прекращая приёма. Вот так. Контроллер - это очень хорошее аппаратное подспорье.

P.S. Это я всё как бы про чтение, ну а при записи, понятно, всё наоборот: надо успеть зашифровать и подать на ножку WR_DATA дисковода, пока нужное место на дорожке дальше не уехало. То есть дёргать вход WR_DATA и одновременно между делом кодированием заниматься.

_________________
Кто мешает тебе выдумать порох непромокаемый?


25 May 2006 01:24
Profile
Maniac
User avatar

Joined: 14 Mar 2006 00:20
Posts: 211
Location: Иркутск
Reply with quote
Post 
Ball Bess wrote:
Если есть запас, можно и по прерываниям, а когда всё впритык, то чтобы не тратить время на вызов прерывания (там же сохранение регистров ещё время займёт) можно как в спековском Бета-диске сделать, выход IRQ ВГшки не вызывает прерывания. Там он подключен нештатно, не к системе прерываний, а подведён к доступному для чтения регистру и хост при обработке сектора всё время опрашивает этот бит, ожидая готовности FDC. Ну, если всё впритык, то долго опрашивать не приходится, раз-два и вот он запрос. Если цикл опроса грамотно написан и достаточно короткий, то так экономнее, чем по прерываниям.

Вот, нарыл в одном амстрадовском мануале. Речь о FDC их компа:
Quote:
The interrupt signal (INT) of the NEC 765 is not connected, therefore interrupt driven data-transfers are not supported.
The signals for DMA transfer (/DACK = data acknowledge, DRQ = data request and TC = terminal count) are not connected, therefore DMA driven data-transfers are not supported.

Ни по прерываниям, ни через DMA. Тогда как же?
Quote:
The "polling" method is used to communicate with the FDC.

For each data transfer, the main status register (MSR) is read to determine:

- the phase of the execution of a command ("COMMAND PHASE", "EXECUTION PHASE" or "RESULT PHASE")
- the direction of data transfer (from CPU to FDC or from FDC to CPU)
- when the FDC is ready for a byte of data to be transfered

Опрашивается главный статусный регистр, чтобы поймать момент, когда FDC готов выдать/принять очередной байтик... Тоже упростили, как могли.

_________________
Кто мешает тебе выдумать порох непромокаемый?


27 May 2006 08:31
Profile
Banned
User avatar

Joined: 20 Mar 2005 13:41
Posts: 2141
Location: От туда
Reply with quote
Post 
Хехе... Ты давно опоздал: такой метод (чистый PIO) у меня был еще на ВГ93 на Орионе.... Причем, для упрощения, опрашивались тока 2 бита: BUSY и DRQ. Делалось так:
Quote:
;-----------------
;Управление Регистром
CTR:LDA 0F700H
ANI 01H
JNZ CTR
MOV A,C
STA 0F700H
RET
;Запись данных с синхронизацией
DAT:LDA 0F700H
ANI 01H
JNZ DAT
MOV A,C
STA 0F703H
RET
;Чтение сектора SEC-СЕКТОР, TRK-ДОРОЖКА
;Длинной в 512B
INS:PUSH H
PUSH D
PUSH B
LDA TRK
ANI 1H
ORI 0EH
STA 0F602H
LDA TRK
ANI 7EH
RRC
MOV C,A
CALL DAT
MVI C,18H
CALL CTR
LDA SEC
INR A
STA 0F702H
CALL RED
MVI C,80H
CALL CTR
LXI H,BUF
LXI D,0F703H
MVI C,82H
IN0:LDA 0F700H
ANA C
JZ IN0

LDAX D
MOV M,A
INR L
JNZ IN0
INR H
IN1:LDA 0F700H
ANA C
JZ IN1

LDAX D
MOV M,A
INR L
JNZ IN1
LDA 0F700H
POP B
POP D
POP H
RET

2 цикла по 256 байт делалось из-за нехватки быстродействия ВМ80@2,5MHz - команда проверки замедляла...
PS Кому интересно: это выдержка из моего старого кода для Ориона, для чтения/записи MS-DOSовских дискет, писал полностью сам и с 0, комментарии практически не делал. %) Вот полный текст, для упрощения он делал только обмен флопа с RAM диском, зато юзал всего 512 байт для буфера данных и 1024 для FAT:
http://www.nedopc.org/nedopc/upload/bdisk.rar


Last edited by HardWareMan on 28 May 2006 03:53, edited 1 time in total.



27 May 2006 12:46
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
SfS wrote:
Shaos wrote:
По поводу армов у меня пока сложилось предубеждение, что они сугубо антилюбительские девайсы...


Интересно почему ?


Слишком много слишком мелких ног - очень сложно определить целостность собранной схемы, да и программирование под сей девайс означает обладание некоторым секретным знанием о построении стартапов и т.д.

_________________
:dj: https://mastodon.social/@Shaos


27 May 2006 14:07
Profile WWW
God

Joined: 02 Jan 2006 02:28
Posts: 1390
Location: Abakan
Reply with quote
По поводу ISA-8.
Если реализовывать полную поддержку ISA-8, то видимо придется реализовывать и базовые механизмы работы с ней, такие как IRQ и DMA. Использовать отдельные м/с контроллеров в данном случае считаю неоправданным, так как достать оные сейчас проблематично (по крайней мере для меня). Тогда встает вопрос о реализации моста между NI-15 и ISA-8, в идеале на доступной CPLD... Нужно ли? Или ограничимся подключением только FDC 765?

Ball Bess, все прикидки я делал для at89s8252 с кварцем на 11059,2кГц, а если взять AVR на 16МГц, то среднее время выполнения команды получается в районе 63нс, так что режим "по прерываниям" вполне реализуем.

P.S. Мануал древний как мамонт. Упоминание 8" дисков улыбнуло :)


28 May 2006 20:06
Profile
Maniac
User avatar

Joined: 14 Mar 2006 00:20
Posts: 211
Location: Иркутск
Reply with quote
jdigreze wrote:
По поводу ISA-8.
Если реализовывать полную поддержку ISA-8, то видимо придется реализовывать и базовые механизмы работы с ней, такие как IRQ и DMA. ]

Мудрое замечание. На то шина и стандартная, чтобы воткнул любое устройство, её поддерживающее, и оно - работает. А устройствам действительно и DMA может захотеться... И если говорить об эмуляции ISA, то тогда и никакого флопоконтроллера не надо выдумывать: есть стандартные, ISA'шные. То есть вообще совершенно другая задача получается.
Я вообще-то не этим собирался заниматься. Мне просто хотелось (и хочется) попробовать поюзать одночиповый FDC, посмотреть, к чему его можно присобачить.
Одночиповый FDC в связке с AVR - это тоже интересная вещь, так как получается универсальный контроллер, но это это несколько другая вещь, а AVR, работающий напрямую с приводом, - это уже третья вещь. Если есть люди, которым интересно и второе , и третье, то кто мешает им поразмышлять над этим. Я не хочу пока ставить никаких сверхзадач, т.к. чем грандиознее замысел, тем меньше вероятность, что он будет осуществлён. Поковыряюсь просто с FDC, если всё будет ОК, подружить его с MCU - следующая задача. А управлять приводом программно, без аппаратной поддержки - у меня слишком мало опыта в области MCU, я один это не сделаю.

_________________
Кто мешает тебе выдумать порох непромокаемый?


Last edited by Ball Bess on 28 May 2006 22:25, edited 1 time in total.



28 May 2006 21:21
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 70 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: No registered users and 30 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.