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

[s_kosorev]

Ну не совсем 50% в расход, а + 256 байт

один буфер выводится, второй в это время заполняется на каждый надо по 512байт, если сразу в буфере mfm держать

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

причем затраты +- одинаковые на преобразования 256 байт данных в 512 mfm, разница только где это время будет потрачено в ISR или главном цикла, что по мне все равно, а вот расход памяти сразу виден, причем без веской причины

[EvgenRU]

У меня тут мысль появилась, а зачем нам вообще эти 512байт? Можно же читать не весь сектор, а скажем по 64 или 128 байт, наверное лучше 128, чтобы получилось как раз 256 в MFM, из считанных данных гнать в MFM по кольцу через 2 указателя. Основная проблема будет с подсчетом последнего бита и с CRC. При переключении на дургую сторону можно один оборот прогнать то что заполняется

Ктати, SWAP, ROL и AND 0x1F экономит нам 224 байт под MFM_tab_h, т.к. таблица там такая

0x55,0x55,0x55,0x55,0x55,0x55,0x55,0x55,
0x54,0x54,0x54,0x54,0x54,0x54,0x54,0x54,
0x52,0x52,0x52,0x52,0x52,0x52,0x52,0x52,
0x52,0x52,0x52,0x52,0x52,0x52,0x52,0x52,
0x49,0x49,0x49,0x49,0x49,0x49,0x49,0x49,
0x48,0x48,0x48,0x48,0x48,0x48,0x48,0x48,
0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,
0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,0x4A,
0x25,0x25,0x25,0x25,0x25,0x25,0x25,0x25,
0x24,0x24,0x24,0x24,0x24,0x24,0x24,0x24,
0x22,0x22,0x22,0x22,0x22,0x22,0x22,0x22,
0x22,0x22,0x22,0x22,0x22,0x22,0x22,0x22,
0x29,0x29,0x29,0x29,0x29,0x29,0x29,0x29,
0x28,0x28,0x28,0x28,0x28,0x28,0x28,0x28,
0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,
0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,0x2A,
0x95,0x95,0x95,0x95,0x95,0x95,0x95,0x95,
0x94,0x94,0x94,0x94,0x94,0x94,0x94,0x94,
0x92,0x92,0x92,0x92,0x92,0x92,0x92,0x92,
0x92,0x92,0x92,0x92,0x92,0x92,0x92,0x92,
0x89,0x89,0x89,0x89,0x89,0x89,0x89,0x89,
0x88,0x88,0x88,0x88,0x88,0x88,0x88,0x88,
0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,
0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,0x8A,
0xA5,0xA5,0xA5,0xA5,0xA5,0xA5,0xA5,0xA5,
0xA4,0xA4,0xA4,0xA4,0xA4,0xA4,0xA4,0xA4,
0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,
0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,0xA2,
0xA9,0xA9,0xA9,0xA9,0xA9,0xA9,0xA9,0xA9,
0xA8,0xA8,0xA8,0xA8,0xA8,0xA8,0xA8,0xA8,
0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,
0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,0xAA,

MFM_tab_l, думаю аналогично, тут даже меньше, всего 16 значений, хватит одного AND 0x0F

0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,
0x55,0x52,0x49,0x4A,0x25,0x22,0x29,0x2A,
0x95,0x92,0x89,0x8A,0xA5,0xA2,0xA9,0xAA,

[tnt23]

И еще там есть DMA, что для циклически повторяющихся задач (к которым и относится проигрывание дорожки) вообще идеально подходит.

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

итого при 120 инструкций на байт MFM, ISR в 20-30 тактов, оставляет уйму времени для подкачки данных с SDCARD, 20-25% времени ядра на ISR это ниочем, зачем тут ARM с кучей не нужной для задачи перефирии?

Кстати в ARM почти весь профит от частоты съест вход в ISR, возможно даже будет не хватать

Не очень понятно, откуда оценка в 20-30 тактов на ISR (и что ISR делает?). Далее, с SD данные подкачивать нужно, видимо, с файловой системой (FatFS/TinyFS/PicoFS/etc), что совсем не быстро, если предполагается это делать периодически ввиду отсутствия буфера на дорожку.

Опять же, с какого перепугу в ARM профит будет съедать вход в ISR? мне немножечко приходилось работать с тем и с другим, уверяю, это достаточно быстро даже на 48МГц.

Если у вас идиосинкразия на ARM, тогда другое дело. Наличие ненужной периферии огорчает? Возьмите Z80, будет благолепно. Просто я не понимаю, отчего не взять современный дешевый (84р, да?) МК с кучей возможностей уже включенных в эти 84р, если нужно решить задачу, а не потрахаться

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

На ассемблере есть смысл писать критичные к скорости выполнения куски кода в конечном приложении. Это позволить немного ускорить код. Сейчас же речь о прототипе, который только формирует сигнал и ничего при этом не делает, с картой не работает. Эти 10% выигрыша быстродействия тут не должны играть решающую роль. Когда добавится работа с картой требования к процессорному времени, затрачиваемому на формирования сигнала могут возрасти.

PS. использование 48МГц МК для эмуляции флопа для компьютеров, частота которых измеряется единицами МГц - как-то неприлично, имхо

Дисковод от ленты немножечко отличается. Скажем, у дисковода есть определенные требования к скорости позиционирования головок (читай - к загрузке/отдаче новой дорожки) - допустим, 3мс на шаг и 15мс на стабилизацию после последнего шага. Для достоверной эмуляции хорошо бы эти требования выдерживать. Есть платформы, под которые существует ненулевое количество софта, смертельно обижающегося на "неуспеваемость" эмуляции.

Про неприличность 48МГц - ну вы же наверняка пользуетесь часами в смартфоне, без особых угрызений совести

[Trol73]

У меня тут мысль появилась, а зачем нам вообще эти 512байт? Можно же читать не весь сектор, а скажем по 64 или 128 байт...

512 байт - размер сектора SD-карты, читать блоками меньшего размера будет, скорее всего, неудобно, если использовать готовые библиотеки.

Если у вас идиосинкразия на ARM, тогда другое дело. Наличие ненужной периферии огорчает? Возьмите Z80, будет благолепно. Просто я не понимаю, отчего не взять современный дешевый (84р, да?) МК с кучей возможностей уже включенных в эти 84р, если нужно решить задачу, а не потрахаться

Так интерес, насколько понимаю, как раз в том, чтобы сделать самому, и не палить при этом из пушки по воробьям Ну и да, потрахаться, но сделать ретро-железку на почти-ретро-микроконтроллере
Кстати, в случае использования STM придётся же конвертер 3.3В <-> 5.0В ставить?

Про неприличность 48МГц - ну вы же наверняка пользуетесь часами в смартфоне, без особых угрызений совести

Так то телефон, я же с него не только время смотрю, а еще звоню и всякими там интернетами пользуюсь Но если бы делал простые часы, то точно взял бы AVR-ку, а не ARM 48МГц

[EvgenRU]

Ну, давайте еще вспомним STM8... та же атмега8...

PS: alignas ардуина не понимает, а вот регистры мапить дает, уже плюс!

Вот такая штука в ардуинке отлично работает

.........устаревший код удален, см. код на следующей странице.........

PS: вариант с размещением таблиц во флеше отпадает, т.к. скорость считывания очень медленная, только SRAM.

[dosikus]

Ну, давайте еще вспомним STM8... та же атмега8

вы настолько неосведомлены. В стм8 периферия на порядок круче авр. Хотя о покойниках лучше молча.

[Advertiser]

[s_kosorev]

Не очень понятно, откуда оценка в 20-30 тактов на ISR (и что ISR делает?).

код выше, выводит через SPI MFM

Далее, с SD данные подкачивать нужно, видимо, с файловой системой (FatFS/TinyFS/PicoFS/etc), что совсем не быстро, если предполагается это делать периодически ввиду отсутствия буфера на дорожку.

можно при открытии файла получить список всех кластеров и расчитать координаты всех секторов образа, тогда в основном цикле будет тупо чтение с SD карты по известным номерам

пять же, с какого перепугу в ARM профит будет съедать вход в ISR? мне немножечко приходилось работать с тем и с другим, уверяю, это достаточно быстро даже на 48МГц.

ну смотре, мега 20мгц 4такта вход, арм 48 мгц, 12тактов вход, + NVIC

Если у вас идиосинкразия на ARM, тогда другое дело.

тут другое, avr достаточно по ресурсам + доступность dip корпуса (берборды беспаечные) + ардруина (цена в несколько раз доступнее того же дискавери), человек судя по сайту с Avr знаком

Наличие ненужной периферии огорчает?

был аргумент что там круче перефирия, он то так, только какая разница если не юзается

Просто я не понимаю, отчего не взять современный дешевый (84р, да?)

дискавери дороже, ардуина у каждого 3 имеется (наличие usb-com + мега в дипе + бердборда, считай у тебя есть ардуина)

мс на шаг и 15мс на стабилизацию после последнего шага.

решается вообще без напрягов

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

PS: задрали проповедники ARM, в каждую ветку с AVR лезут, чешется что ли?

[tnt23]

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

[s_kosorev]

>>PS: alignas ардуина не понимает, а вот регистры мапить дает, уже плюс!

Alidnas это нужно компилятору сказать что нужно ждать c11 или gnu-c99

[EvgenRU]

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

Если есть опыт реализации на AVR, так поделитесь опытом реализации на AVR :-D

А то, как пример, я бы спросил, на каком транзисторе лучше сделать усилитель для пищалки, а мне бы стали советовать какую TDA выбрать... всё, на этом умолкаю насчет AVR, STM, PIC и т.д. Проект будет на AVR, кому хочется сделать на другом - делайте, выкладывайте, думаю, все будут рады.


PS: просьба к спецам, проинспектируйте код на предыдущей странице на предмет оптимизации и сохранения регистров. Код 100% рабочий, сигналы генерируются корректно, проверил лог анализатором.

При такой реализации получается кодирование данных в коде ISR, т.е. буфер под данные остается размером с сами данные! Ну и под заголовки дорожки/сектора нужно будет что-то придумать. С CRC пока что не знаю, то ли при переключении дорожек генерить, то ли еще как, но все не войдут в память при монтировании, получается 2.5кб данных. Еще вариант сгенерить CRC во временный файл при монтировании.