Полигон-2

Geners  Когда прога видит строчный синхроимпульс она должна начать выводить на экран биты яркости в одну строку. И до наступления следующего синхроимпульса есть всего 64 микросекунды! За это время прога должна опросить порт 320 раз! И сделать это должна точно! То есть если бы у нас были такты каждого пиксела...  
Появилась проблемма: На входах порта в режиме input напряжение равно 1! И чтобы записать туда 0 надо закорачивать их на землю! А в схеме моего АЦП подразумевалось что на входах всегда 0... Сегодня попробую пошунтировать каждый вход резюком.  Может смогу сделать там 0.  Это чтобы ты знал!!! То есть если к этим входам подрубить TTL выход, не факт, что при 0 удастся перевести вход в 0.
Кстати почти все траблы с софтом решил.. Прога почти готова... Загвоздка тока в том, что надо организовать точную задержку перед выводом следующего пиксела, и в том, что цикл у меня пока организован ПАСКАЛЕМ! Пока на асме цикл сделать не хватает мануалов...
Остаётся ещё   трабла, не главная пока... Как видео сохранить на винт?!
Geners  Поделись своими соображениями по поводу АЦП?
Если будешь делать вариант на шине, можно вообще юзать VESA... Ну или если ISA 8 или 16 бит, то можно обойтись вообще без преобразования... Раскладываешь сигнал на уровни, и подаёшь каждый на бит данных... Там скорость хорошая и можно декодировать сигнал процом. Можно даже на плату прототипа  запихать 512 метровый модуль памяти от флешки и микроконтроллер... Вариантов куча... Но не забывай : Собранный на кп350 логический элепент или триггер будет работать спокойно на частоте до 800 мегагерц!!! А вот микросхемы дохнут намного раньше!!! При наличии у меня сотни резисторов на 1 кОм я лучше собрал бы свой АЦП на дискретных элементах. А щас сижу и гадаю, справится ли ЛП5 с частотой 4,5 мегагерца... Или нет...

fmulder007
Звук сжимали с 16 бит до 4 бит упрощенно говоря путем вычисления разницы между уровнями соседних остчетов (добавлялось по 4 бит за отсчет, поскольку синусоиды наростают чаще всего плавно, а общий диапазон оставался 16 бит), но на участках с резким изменением уровня не хватало 4 бит для передачи фронта импульса без искажений, но поток сжимался в 4 раза без сильной загрузки процессора. Формат ADPCM использовался до появления mp3

[q]

А вообще вчера посчитал скорость потока для полосы в 4 мегагерца при 25 кадрах в секунду(качество vhs) и получилось около 1015 килобит в секунду.

[/q]

И как это расчитывалось? У меня получается расчет без сжатия при четверти полного кадра - 384х288х25х5бит=13824 килобит в секунду (это средний, а реально ещё в 2 раза выше в момент захвата полукадра, а потом пауза на следующий полукадр)

[q]

(0 соответствует чёрному, 10000 соответствует белому)

[/q]

А почему не 11111?

[q]

в pal и secam длительность одной строки равна 64 микросекунды!

[/q]

60 мкс изображение + 4 мкс синхроимпульс
Ещё надо обдумывать моменты:
Как 288 строк полукадра PAL выводить на 200 сторк монитора

Teodor  Размер по горизонтали - не так важен... А вот по вертикали, можно кропить... Бегущую строку видно не будет!!!! Она так раздражает! Это пока не важно...
mb Просто распаять 4 корпуса lm339 намного прощще, а второе - для совместимости со старыми LPT портами.. В них только 4 вывода работают на вход.  Да и в палитре цветов режима 19(dec) цвета с 16 идут градиентом серого (кажется вплоть до 80) Поэтому переназначать палитру не придётся...
Кстати ! Вчера разработал алгоритм архивации. Черезвычайно прост в аппаратной реализации и черезвычайно удобно выполняется восстановление в ассемблере.
Teodor  По горизонтали будем не кропить! Незачем! В строке видео нет жёстко ограниченных элементов. Дискретны только строки по отдельности! А вот по горизонтали можно растягивать сроку хоть на десять, хоть на 10000 элементов... Вопрос в удобстве восприятия.
По вертикали можно в конце концов взять другой видеорежим Тока по моему в биосе нет поддержки 640х480х256 цветов из 256к Надо видюху напрямую заставлять работать в таком режиме... А для старых компов (386 и так с трудом даёт 15 раз в секунду перерисовать видеопамять!)

mb  Я пишу напрямую в видеопамять с адреса A0000h. Видеокарта сама сканирует память и выводит на экран её содержимое... Почитай описалово любой видеокарты ega/VGA.
Так что так называемый оверлей был на видеокартах ИЗНАЧАЛЬНО!!! Тока он так не назывался...
И я передаю сразу из порта в видеопамять... Всё работает довольно быстро...  

mb

[q]

Но всё равно же надо будет хранить в видеопамяти полностью предыдущий кадр, выдавать его на экран и запоминать в это время последующий кадр?

[/q]

Технология использования нескольких страниц видеопамяти и переключения между ними была ещё на ЕГА реализована (я сам на асме лабал это дело), и она - не совсем тот оверлей, что подразумевается на современных видеокартах при просмотре видео.