Замена ВГ93

[AlexBel]

Я хочу сделать эмулятор ВГ93 со стороны компа как минимум, а как максимум и со стороны флопа... Странно делать эмулятор флопа ибо не обойти существующие ограничения ВГ93. Чисто програмно в Спекке тоже не сэмулируешь. И я хочу "ВГ93" использовать в качестве интерфейса с TCP/IP стэком! Хоть кому-то это кажеться смешным.

О нет, я ни в коем случае не хочу высмеять идею IP-стеком. Наверное, я в этом плане неправильно выразился. Правильнее сказать - лично я не вижу в этом никакого практического смысла, разве что эксперимент "заработает/не заработает". Повторюсь - это исключительно мое мнение и, в общем-то, наверное даже не стоило его высказывать.
По самому эмулятору, получается, что у нас разные позиции: для меня спектрум - старый игровой компьютер, на котором мне нравятся некоторые старые игры. И при разработке эмулятора дисковода я ставил перед собой задачу тольько запускать игры. Даже функции записи не собирался делать...

[ZEK]

ВГ93 изучал по докам WD.

К сожалению дока отнють не исчерпывающая, и очень многого из неё не ясно, многие неясности можно из тоже US вытянуть, так как по максимуму для проца создает реальную ВГшку.

[fan]

Ктонить скажите плиз ху из WD & US ? %)

[Black_Cat]

ху из WD & US ?

WD - производитель микросхемы контроллера флопа WD1793
US - unreal spectrum - эмуль

[caro]

WD - производитель микросхемы контроллера флопа WD1793

Фирма называется Western Digital.

[homeness]

Увы, PIC18 без дополнительно буферизации не пригоден для этой цели, AlexBel был прав Прерывание от PSP приходит по положительному фронту ~WR/~RD и на чтение адреса остается 30-40 нс. Если не пользоваться PSP, а работать сразу по ~CS, то тоже не получается. Всю процедуру обработки шины за 200 нс не сделать

[Advertiser]

[ZEK]

По мне так самый реальный вариант

Патч тырдос + CPLD + внешная рама + микроконтролер

CPLD - для эмуляции из обычной рамы двухпортовки и эмуляцию регистра данных WD1793
RAM - для MFM образа дорожки
Мелкоконтролер для обработки команд ВГшки, работы с FAT32, MMC, и записью образа дорожки во внешную раму.

Патч тырдоса, хотябы для того что бы не резать машинки к примеру перехват записи чтения порта FF который опять же для исключения задержек может быть в CPLD, так же как и текищие номера дорожек, секторов и т.д. тобиш для безваитовости

[AlexBel]

По мне так самый реальный вариант

Патч тырдос + CPLD + внешная рама + микроконтролер

CPLD - для эмуляции из обычной рамы двухпортовки и эмуляцию регистра данных WD1793
RAM - для MFM образа дорожки
Мелкоконтролер для обработки команд ВГшки, работы с FAT32, MMC, и записью образа дорожки во внешную раму.

Патч тырдоса, хотябы для того что бы не резать машинки к примеру перехват записи чтения порта FF который опять же для исключения задержек может быть в CPLD, так же как и текищие номера дорожек, секторов и т.д. тобиш для безваитовости

Именно подобные мысли меня привели к использованию PIC24FJ64GA004. У него 8 килобайт на борту (хватит и для работы FAT и для кэширования всего трека), и адресуемый PSP (избавляет от необходимости софтверно эмулировать 4 регистра ВГ93) и производительность 16МИПС (совместно с адресуемым PSP избавляет от необходимости использовать WAIT и патчить тырдос). Я не говорю, что нужно использовать именно PIC24FJ64GA004 - пойдет любой контроллер с подходящими характеристиками и необходимой периферией на борту.
Зачем же патчить тырдос (теряется универсальность устройства - кроме обычной установки эмулятора в панельку нужно еще и ПЗУ перепрошивать. Всем ли это доступно?), зачем использовать CPLD и врешнюю раму (зачем лишние корпуса и лишняя работа, если можно обойтись одним контроллером?)???

Добавлено через 2 минуты

Увы, PIC18 без дополнительно буферизации не пригоден для этой цели, AlexBel был прав Прерывание от PSP приходит по положительному фронту ~WR/~RD и на чтение адреса остается 30-40 нс. Если не пользоваться PSP, а работать сразу по ~CS, то тоже не получается. Всю процедуру обработки шины за 200 нс не сделать

Во время экспериментов я пробовал переписать процедуру обмена на асме (используя команды PIC18, например MOVFF, существенно экономящие тики). В принципе уложиться можно, но "только-только". после этого решил использовать WAIT...
Спроси у ILoveSpeccy, он пошел по подобному пути - использует AVR и задействовал WAIT. Насколько я знаю, он уже добился определнного успеха
То ILoveSpeccy: Дим, ничего, что я тебя так сдаю?

[ZEK]

Попробую конструктивно

У него 8 килобайт на борту (хватит и для работы FAT и для кэширования всего трека)

Память внутрення и что бы к ней ломиться нада прерывать мелкоконтролер, а ваще по минимуму хватило бы 1Кб (512буфер скетора, 480 байт-номера класеров по которым размещены дорожки)
Для полного MFM образа дорожки нада 6 с гэком килобайт. В случае работы на уровне TRD файлов нужно только 256байт.

и производительность 16МИПС (совместно с адресуемым PSP избавляет от необходимости использовать WAIT и патчить тырдос).

Да не в мипсах дело а в латентности, потому как для многих относительно больших по коду кусков очтводиться оч. мало времени.

Зачем же патчить тырдос (теряется универсальность устройства - кроме обычной установки эмулятора в панельку нужно еще и ПЗУ перепрошивать. Всем ли это доступно?),

А каким образом ты будеш отлавливать к примкру выбраную сторону диска, номер дисковерта (сидеть с паяльником и напаивать,напаивать, напаивать соплей ?)
А как насчет опрашивать с достаточно часто сигнал индекса от флоповода, который тырдос дергает к примеру для того что бы остановить диск, и тому подобные нюансы

зачем использовать CPLD и врешнюю раму (зачем лишние корпуса и лишняя работа, если можно обойтись одним контроллером?)???

А затем что не нада тогда дергать и прерывать мелкоконтролер только ради того что бы он выдал байтик из внутреней памяти. К томуже на 99% уверен что мелкоконтролер без вайта жуткого просто напросто неуспеет, а еще во внешней раме можно несколько дорожек хранить.

[AlexBel]

heroy, я без цитирования отвечу, много места тратится.

1. Для того, чтобы удобно было работать с образами TRD, на SD-карте нужно использовать файловую систему FAT. В этом случае можно будет просто записывать образы на карту в виде файлов. Для работы с FAT контроллеру требуется ОЗУ. Ориентировочно - 1 килобайт и выше. Для работы с TR-DOS можно использовать и не 256 байт - во время первых экспериментов я использовал для кэширования дорожки всего 16 байт, постоянно подгружая данные сектора. Это неудобно. Гораздо удобнее закэшировать сразу всю дорожку. Да, вся дорожка, включая служебную информацию, занимает более 6 килобайт. Ну и что? В чем проблема? Как я уже писал - возьми контроллер, у которого достаточно памяти на борту. Есть современные контроллеры, которые ее имеют, зачем жадничать? Мы что, в каменном веке живем?
2. Вообще-то я писал про "МИПСы + адресуемый PSP". И раз уж я писал про это вместе, так и ты в ответе не разрывай. Лишняя производительность контроллера еще никому во вред не пошла. А насчет больших кусков... У меня один знакомый жаловался, что у него "прерывания тормозят". Я посмотрел его исходник - более килобайта тяжелого кода в прерывании! Так что при корректном построении программы проблем не возникнет.
3. Насчет "отлавливания выбранной стороны диска". Если для тебя подпаять один проводок к сигналу SIDE - это "напаивать, напаивать, напаивать соплей", то... даже не знаю, что сказать... Ну, не пишет тырдос номер стороны в индексное поле, что поделать... Насчет формирования индексного импульса не вижу никаких проблем. Уже делал, правда, без особого соблюдения периодичности. Какие еще есть нюансы?
4. А почему это не дергать и не прерывать процессор? Чем это ненормально? Ну и пусть дергается и прерывается - у него работа такая. Или изнашиваться будет быстрее от прерываний и дерганий? И позволь вопрос - ЧТО ИМЕННО не успеет контроллер без вайта жуткого? Ответь, пожалуйста, на этот вопрос, памятуя об АППАРАТНОМ АДРЕСУЕМОМ PSP.
5. Конечно, в внешней памяти можно хранить несколько дорожек. Даже не несколько, а все. Только зачем? Сколько времени требуется дисководу на перемещение головки на нужную дорожку? Сколько времени отводится на успокоение головки? И после успокоения когда фактически начнут читаться/писаться данные? Сложи все три временных промежутка и подумай, сколько времени потребуется контроллеру на чтение дорожки из образа на SD-карте и размещение ее в своей памяти? И тут, кстати, очень не лишними окажутся хорошие МИПСы.

И последний вопрос - разработка любого проекта на микроконтроллере должна начинаться с подбора самого контроллера. Для этого нужно хорошо представлять себе, какие ресурсы могут потребоваться для выполнения поставленной задачи. И с учетом этого выбирать контроллер, желательно с запасом по ресурсам. Так почему ты торгуешься "здесь 256 байт, там килобайт..." вместо того, чтобы просто выбрать контроллер, которому проблема будет "по зубам"?