Планирую сделать FDD эмулятор на Atmega8

[barsik]

В споре рождается срачь

В споре рождается срач, только если в форум сра... гадить.

И никакого спора нет. Все давно поняли мою правоту. Похоже, Вы единственный, до кого еще не дошло. Кроме того, как указали в предыдущих постах, данную идею уже давно реализовали. Так что, о чём тут спорить и что доказывать ?

не ввязывайтесь в спор о материях, в которых ничего не понимаете

В качестве примера я рассматриваю реализацию МК на обычном МП ядре с обычным CPU. Здесь речь идёт об идее, о алгоритме работы и его реализуемости. Сложности реализации на AVR или другом прогрессивном кристалле вне данного вопроса. Чтобы обсуждать алгоритм не нужны знания о данных "материях". Достаточно посмотреть в исходном тексте программы как CPU работает с контроллером дисковода или винта. Тут вообще не требуется никаких знаний даже аппаратуры этих контроллеров. Исходный текст даёт знание алгоритма и этого достаточно, чтобы разработать эмулятор, хоть на прогрессивном МК, хоть на самом древнем CPU со своим ОЗУ, ПЗУ и интерфейсом с шиной основного процессора.

В контроллере адрес регистра статуса либо регистр данных выбирается аппаратно (то есть на уровне быстродействия логики), а любой МК должен проанализировать управляющие сигналы и выдать в порт нужные данные, на что, как ни странно, тратится время.

Регистр данных и регистр статуса находятся внутри ВГ93, а в эмуляторе контроллера НГМД и винта эти регистры тоже есть аппаратно (хотя задействовав WAIT можно сократить железо и обойтись всего одним регистром на вывод). Что Вы оспариваете ? Процесор читает данные из регистра данных, когда они уже готовы и скорость с какой он это делает ни на что не влияет. Также и при записи, процессор не будет писать в регистр данных ничего, пока не будет готовности. Все операции выполняются только по готовности. И процессор готов ждать этого часами.

есть регистр #FF, у него 2 старших бита это сигналы DRQ и INTRQ

Это 38-я и 39-я ноги ВГ93. Они в КНГМД большинства ЭВМ не используются (т.к для их чтения тратится лишний буфер) и используются только в ZX. Но эти выходы ВГ93 позволяют сделать опрос готовности аппаратным. Например, в КНГМД разработанным Л.Афанасьевым для СПЕЦИАЛИСТА, где такт КР580 всего 2 МГЦ, для ускорения работы эти выходы используются для вывода КР580 из захвата шины. Когда КР580 хочет считать байт из ВГ93, он переводит себя в HOLD и зависает. По сигналу на выводе DRQ ВГ93 процессор выходит их HOLD и сразу же читает или пишет байт данных, не теряя время на цикл и анализ готовности. Я встречал аналогичную схему, где CPU с этой же целью переводится в WAIT, что по-моему традиционнее.

[TomaTLAB]

Записал, не сомневайтесь, только шина-то одна...
В контроллере адрес регистра статуса либо регистр данных выбирается аппаратно (то есть на уровне быстродействия логики), а любой МК должен проанализировать управляющие сигналы и выдать в порт нужные данные, на что, как ни странно, тратится время.

Если микроконтроллер успевает по сигналу чтения отдать на шину слово состояния, то по какой такой причине он не успеет таким же макаром отдать байт данных? Ну а если не успевает, то и говорить не о чем, городим внешние защелки, так же как и в случае если у нас не МК со встроенными портами ВВ, а голый процессор этим занимается. Или берем МК пошустрее, или вообще какой нибудь 8042 у которого встроенный интерфейс с шиной.

[omercury]

Если микроконтроллер успевает по сигналу чтения отдать на шину слово состояния, то по какой такой причине он не успеет таким же макаром отдать байт данных?

Люди говорят: "не успевает" - значит не успевает.
Наверное потому, что статус уже лежит в буфере порта.

Ну а если не успевает, то и говорить не о чем, городим внешние защелки

Вот и я про это.
Мы тут с котом тиаритезируем, вот я базу под это и подвёл.

Вы единственный, до кого еще не дошло.

Убейте - не понимаю - зачем делать то же самое, но хуже?

[TomaTLAB]

Наверное потому, что статус уже лежит в буфере порта.

А с чего это он вдруг там уже лежит? Кто сказал, что вот прям щас там нужен именно статус а не данные?
Чем же они так кардинально различаются с точки зрения чтения с шины?

[EvgenRU]

+ еще нужно учитывать тот факт, что после чтения сектора мы спокойно можем делать задержку, на любое время перед чтением следующего

UPD: меня вот что интересует, команда ВГ 100xxxxx чтение сектора, куда она его читает? в буфер и потом из буфера читается портом #7F или она сразу в память читает?

[barsik]

Если микроконтроллер успевает по сигналу чтения отдать на шину слово состояния, то по какой причине он не успеет отдать байт данных?

Да зачем микроконтроллеру успевать отдавать данные ?

Похоже, что мы говорим о разных схемах эмулятора. Зачем микроконтроллеру заменять программным путем регистр данных или статуса ? Проще иметь эти регистры аппаратно, ведь все регистры размещаются по разным адресам. Это может быть часть ППА или просто ИР22/23. Если помните, в ИР23 сигнал /OE не мешает защелкивать данные в регистр. Процессор 8008 записал в ИР23 байт, который якобы считался из дисковода (а на самом деле из очень большого ОЗУ), а затем записал в регистр статуса или в 2-х разрядный регистр имитирующий ноги 38,39 ВГ93 (что зависит от схемы КНГМД) признак готовности. И всё. Дальше от отдыхает. Ждёт когда произойдёт чтение регистра данных основным процессором, по которому автоматически (аппаратно, т.е без участия процессора 8008) бит в регистре статуса сам сбросится. Узнав об этом, процессор эмулятора, не торопясь, проверит, что в счётчике пакета (BC, где изначально число байтов в секторе) не 0, а после чего снова считает очередной байт: LD A,(HL) : LD (DATA),A : INC HL : LD (READY),A и на петлю контроля флага в регистре статуса.

А Вы, похоже, говорите о схеме, в которой в качестве интерфейса с ЦП на чтение c контроллера есть всего один ИР22. Тогда нужен триггер формирующий сигнал WAIT шины ЦП. Как только ЦП попытается считать что-то с регистра данных или статуса, то он зависнет по WAIT и будет ждать данных. Тогда 8008 должен выяснять какой адрес стоит на шине, чтобы понять читается регистр данных или регистр статуса и соответственно записать в ИР23 нужное число, а потом сбросить триггер WAIT для ЦП. Это тоже не станет проблемой скорости, т.к не важно с какой скоростью ЦП читает данные из регистра данных и переносит их в своё ОЗУ.

меня вот что интересует, команда ВГ93 чтение сектора, куда она его читает? В буфер и потом из буфера читается портом #7F или она сразу в память читает?

Вопрос неточный, но суть вопроса ясна. Это зависит от типа носителя. В старых microSD до 2 Гб была байтовая адресация (32 разряда адреса хватает лишь на 2 Гб). Также в обычном ОЗУ адресация побайтовая. Зачем же эмулятору читать в какой-то промежуточный буфер целый сектор и только потом выдавать его на интерфейс? Это только тормознёт. Но в новых 'microSD' в которых адресация посекторная, а также, возможно для ускорения, можно считывать целый сектор в промежуточный буфер.

В отличие от прогрессивных МК, древний CPU может адресоваться только к 64К (а 8008 вообще лишь 16К). Поэтому для адресации большого ОЗУ следует применять HD64180ZP8, с встроенным MMU или же нужен регистр, играющий роль менеджера памяти. Удобно сделать окно доступа к большому ОЗУ в 32К, отчего и от 8008 придётся отказаться (т.к он адресуется лишь к 16К) и применить КМОП Z80 (SU880) на такте, например, 2 МГЦ. Тогда по числам, что ЦП записал в регистр трека и регистр сектора, получив команду чтения сектора, Z80 эмулятора вычисляет номер полу-банки и записывает это в регистр выбора полубанки. Отчего в адресном пространстве Z80 возникает фрагмент большой памяти, где находятся нужные данные. Далее по числу в регистре сектора вычисляется адрес начала нужных данных в ОЗУ и загружается в HL, а в BC размер сектора и начинается передача байта за байтом данных (якобы считанных из сектора).

У меня возник другой вопрос. Если Вы в качестве носителя используете флэш память у которой очень ограниченное число перезаписей, то раз в сколько дней надо менять карточку 'microSD' на новую. Это обычное ОЗУ может работать по 40 лет и скорость их выхода из строя не зависит от числа перезаписей. А на 'microSD' и других флэш носителях можно делать только устройства типа ROM. Вот почему в новомодные цифровые магнитофоны на базе флеш-памяти не вводят запись.

[TomaTLAB]

А Вы, похоже, говорите о схеме, в которой в качестве интерфейса с ЦП на чтение c контроллера есть всего один ИР22.

В которой вообще нет ни ИР22, ни ИР23
Владимир, я Вашу идею прекрасно понимаю. И не вижу в ней никаких противоречий.
Здесь скорее в другом вопрос, успеет или нет голая AVR-ка обмен на шине переварить или нет. Не могу я навскидку сказать. Говорят вот, что нет.
Но если она успеет дернуть WAIT по своему прерыванию от /RD, то уже никуда не денется. Ну накрайняк, я думаю, половинки ТМ2 должно хватить на это все безобразие.

[ALS]

Я вообще не понимаю смысла разводить антимонии здесь, на 39-й странице темы.
Вроде, определились уже со всем.
И тут раздается пионерский клич...

Барсик ! Можно по-другому ? Сделайте ! Но нехрен теоретизировать и поучать, ни пальца не приложив к воплощению ваших мечт в реальность.

[barsik]

Я вообще не понимаю смысла разводить антимонии.
Можно по-другому ? Сделайте ! Но нехрен теоретизировать и поучать

Разве я поучал кого-то ? Я высказал своё мнение, что можно получить тот же результат дешевле и проще, а дальше лишь отвечал на реплики. Невежливо было бы отмолчаться.

Форум в первую очередь хорош для обмена идеями и моральной поддержки друг друга. Может быть высказанные идеи кому-то пригодятся. А вот грубости и непонятное раздражение на кого-либо портят форум. Ну а если что-то и написал не так, так для того и предназначены модераторы. Отредактируйте как надо мои посты или просто удалите их, как нарушающие правила форума.

А делать я не стану, хотя и не вижу препятствий для этого. Нет смысла, т.к у меня есть исходники всех ДОС, которые я использую. Да и вообще встроить в любую ДОС винчестер IDE это не проблема. Причём часто годится даже дохлый винчестер, который уже не работает на PC. Не надо цепляться за FAT16/32. Проще работать с физическими секторами носителя средствами конкретной ДОС. Поддержка FAT16/32 конечно удобна для загрузки файлов, используя телефон или планшет, но тогда нужны расходы на интерфейс между ДОС и FAT16/32. Судите сами, проще спаять контроллер IDE на нескольких TTL-корпусах и потратить пару часов на дизассемблирование и перетрансляцию ДОС, чем раздобыть платку "сабжа", детали, спаять и настроить.

И даже при реализации, имея исходник ДОС и зная программный интерфейс, нет смысла эмулировать систему команд реального контроллера. Контроллер должен выполнять всего 2 процедуры - считать и записать сектор. ДОС всё-равно как это делается, поэтому при использовании электронного носителя нет никакого смысла эмулировать интерфейс реального дискового устройства, хотя ATA-интерфейс и прост. Тогда на флеш или большом статическом ОЗУ просто реализуется энергонезависимый VDISK. И для флеш-карт это сделано уже лет 20 назад.

Нет сомнения, что данный проект великолепный, выручит очень многих пользователей не желающих и не могущих возиться с реальным дисководом (т.к дискеты уже невозможно купить, а старые, несмотря на пожизненную гарантию, почти все сдохли). Единственно, что у меня по-прежнему остаются сомнения относительно долговечности девайса. Т.е если интенсивно использовать его для работы, перезаписывая флеш-память тысячи раз в день (что и происходит с областью каталога, если работать в ДОС хотя-бы час в день), то на сколько дней хватит ресурса перезаписей флеш памяти ? Но если нужно только запускать игры, то никаких проблем не будет.

[s_kosorev]

Поддержка FAT16/32 конечно удобна для загрузки файлов, используя телефон или планшет, но тогда нужны расходы на интерфейс между ДОС и FAT16/32. Судите сами, проще спаять контроллер IDE на нескольких TTL-корпусах и потратить пару часов на дизассемблирование и перетрансляцию ДОС, чем раздобыть платку "сабжа", детали, спаять и настроить.

И внезапно заработают все нестандартные загрузчики?, которые даже wait может поломать, который не ожидают, чуть ли не потактово рассчитанные выкрутасы

- - - Добавлено - - -

Если эмулировать на уровне контролера, то есть смысл на уровне микросхемы контролера, которая всегда в панельке так как дохнули достаточно активно. Из плюсов ничего не нужно изменять в компьютере, какие то лишние сопли итд, вставил в панель и профит.