Просмотр полной версии : Использование PIC в качестве логики
ILoveSpeccy
25.03.2007, 03:03
Изучал схему Ленинграда 48 со страницы FANа
Если я правильно понимаю то первая часть схемы (причем полностью) это генератор импульсов для процессора, памяти, видео и т.д.
Кто нибудь пробовал для этих целей истользовать микроконтроллер (PIC 18F2320 например или ATMega)??
Если да, то каковы результаты??
thx
Был такой зверь как ZX-NEXT (через поик найдётся пара тем), но внём юзался Z80 для этих целей . Прошивку я так понимаю ещё никто не крякнул , посему не актуально :(
ИМХО как краний вариант любви к странному дальше ПЗУ с времянками заходить не стоит . Мелкоконтроллеры всёравно потребуют тонну лома , лучше тогда сразу матрицу юзать .
KingOfEvil
25.03.2007, 20:51
Изучал схему Ленинграда 48 со страницы FANа
Если я правильно понимаю то первая часть схемы (причем полностью) это генератор импульсов для процессора, памяти, видео и т.д.
Кто нибудь пробовал для этих целей истользовать микроконтроллер (PIC 18F2320 например или ATMega)??
Если да, то каковы результаты??
thx
а cpld не судьба?
ILoveSpeccy
25.03.2007, 21:38
Могу достать XC 9536XL VQ44 и M4A5 32/32-10 VC.
Только я никогда с ними не работал.
Где можно найти хорошую доку?
как и чем их шить?
...сегодня буду заказывать IC's. :)
thx
Могу достать XC 9536XL VQ44 и M4A5 32/32-10 VC.
Только я никогда с ними не работал.
Где можно найти хорошую доку?
как и чем их шить?
...сегодня буду заказывать IC's. :)
thx
Лучше начни с софта и книг по HDL. До железяк успеешь ещё. Если немецкий не пугает, могу заслать довольно объёмистую книгу по VHDL (я с неё начинал). А что касается камней - у Xilinx ног не хватит + она на 3,3В (по памяти не помню, держит TTL или нет), а вот для Latice (которая вторая) ничего конкретного сказать не могу. А вообще пошарься на www.mikrocontroller.net, там немцы жгут хорошо.
ILoveSpeccy
26.03.2007, 15:10
to icebear
с немецким проблем, слава богу, нет.
За книгу буду очень благодарен.
MfG
to icebear
с немецким проблем, слава богу, нет.
За книгу буду очень благодарен.
MfG
Книгу зашлю, в ebay за камнями не спеши. А мыло отсюда убери, а то заспамят (хотя наверное уже поздно :)) Кстати, VHDL сложен в плане понимания всего до конца, лучше (понятнее и быстрее в использовании) Verilog.
а cpld не судьба?
А мне например CPLD и FPGA пользовать мешает религиозная убеждённость в положительности открытых решений и в отрицательности закрытых ;)
Так что я к примеру буду думать над железом в PIC и SX с некоторыми добавлениями GAL-ов для всякой быстрой мелочи
А мне например CPLD и FPGA пользовать мешает религиозная убеждённость в положительности открытых решений и в отрицательности закрытых ;)
Переведи... Что тебе мешает сделать открытой корку?
ILoveSpeccy
26.03.2007, 21:05
спасибо всем за полезную информацию.
Буду начинать изучать HDL.
Уже скачал софт от Altera и Xilinx :)
Но всетаки, возможна ли реализация, покрайней мере, синхрогенератора на PIC?
thx
KingOfEvil
27.03.2007, 00:04
А мне например CPLD и FPGA пользовать мешает религиозная убеждённость в положительности открытых решений и в отрицательности закрытых ;)
Решение открыто, если открыты исходники.
По поводу открытости вообще - я на своем опыте убедился, что чем меньше документации открыто, тем меньше головной боли у разработчика.
Black_Cat
27.03.2007, 00:11
чем меньше документации открыто, тем меньше головной боли у разработчикаа в чём головная боль? поделись
Решение открыто, если открыты исходники.
Покажи мне открытые исходники CPLD или FPGA - или хотя бы просто архитектуру чего-нибудь современного с точным объяснением назначения каждого бита в данных для прошивки. Нету... Поэтому остаются только микроконтроллеры, разжёванные вдоль и поперёк, мелкая логика и PAL/GAL-ы
Могу достать XC 9536XL VQ44 и M4A5 32/32-10 VC.
Лучше нарой ALTERA EPM7128SLC84-15 (или более быструю), это можно сказать любительский девелоперский стандарт ;) и не только в области спектрумо строения .
Маяться с HDL вовсе не обязательно , вполне можно обойтись и схемным вводом .
Как наименне жудкий вариант HDL могу отсоветовать AHDL , т.к. он мало чем отличается от схемного ввода :D
Лучше нарой ALTERA EPM7128SLC84-15 (или более быструю), это можно сказать любительский девелоперский стандарт ;) и не только в области спектрумо строения .
Это у вас "там" стандарт, а у нас "здесь" Xilinx :) Потому как на Альтеру здесь мало чего найдёшь. Сравни сам, я в de могу купить Спартан-3 на 200К вентелей за 15 евро, а второй циклон на 100К вентелей за 25 евро. Вывод?
Маяться с HDL вовсе не обязательно , вполне можно обойтись и схемным вводом .
Как наименне жудкий вариант HDL могу отсоветовать AHDL , т.к. он мало чем отличается от схемного ввода :D
AHDL - это жуть :) Схемный ввод - лично мне (т.е. моё большое ИМХО) не позволяет охватить всё, что можно написать на том же VHDL. Да и корки везде валяются именно в виде HDL листингов. Плюс используя схемный ввод мало-мальски завязываешься на кристал. Но это всё сугубо личное мнение.
Добавлено через 2 минуты
Но всетаки, возможна ли реализация, покрайней мере, синхрогенератора на PIC?
thx
Конечно можно. В сети куча подобных схем. Например вот http://www.diylive.net/index.php/2006/01/22/video-signal-generation-with-pic-chip/
Де-факто точка отправления для таких потуг здесь http://www.rickard.gunee.com/projects/
Конечно можно. В сети куча подобных схем. Например вот http://www.diylive.net/index.php/2006/01/22/video-signal-generation-with-pic-chip/
Де-факто точка отправления для таких потуг здесь http://www.rickard.gunee.com/projects/
Вот мои пара ссылок ;)
http://www.nedopc.org/forum/viewtopic.php?t=7533 (видео на PIC16F781)
http://www.nedopc.org/forum/viewtopic.php?t=8553 (видео на SX-28)
KingOfEvil
27.03.2007, 22:38
а в чём головная боль? поделись
Когда над твоим изделием начинают кулибинское творчество, потом появляются непонятные глюки, а виноват всегда ты, т.к. ты автор.
Покажи мне открытые исходники CPLD или FPGA - или хотя бы просто архитектуру чего-нибудь современного с точным объяснением назначения каждого бита в данных для прошивки.
Так речь о прошивке или ее исходниках? Не понял.
Исходный текст прошивки является истиной в последней инстанции и полностью описывает ее поведение и состояние в любой момент времени. Что может быть недодокументированным?
Нету...
Чего нету? Исходников?
Поэтому остаются только микроконтроллеры, разжёванные вдоль и поперёк, мелкая логика и PAL/GAL-ы
Если ты разжевал только микроконтроллеры, то это еще не значит, что и все остальные тоже.
Проблема в том ,что на микроконтроллерах нельзя делать всего того, что можно в ПЛИС. Микроконтроллеры имеют сравнительно небольшое быстродейсвие, работают исключительно в заранее определенной дискретной временной сетке, не умеют обрабатывать много сигналов параллельно, их трудно синхронизировать с внешними сигналами.
Black_Cat
28.03.2007, 02:34
Когда над твоим изделием начинают кулибинское творчество, потом появляются непонятные глюки, а виноват всегда ты, т.к. ты автор.Когда-то об этом и Nemo говорил, только в контексте тиражирования этого кулибинства в виде "доработок". :)
Так речь о прошивке или ее исходниках? Не понял. Исходный текст прошивки является истиной в последней инстанции и полностью описывает ее поведение и состояние в любой момент времени. Что может быть недодокументированным? Чего нету? Исходников? Если ты разжевал только микроконтроллеры, то это еще не значит, что и все остальные тоже.
Ты не понял... Прошивая микроконтроллер, ROM или скажем PAL я точно знаю за что отвечает каждый бит того, что я прошиваю - в соответствующих спеках всё описано. Прошивая CPLD или FPGA я не знаю ничего... Ну разве что знаю что подал на вход "компилятора", но никогда не узнаю во что это превратилось ибо архитектура девайсов засекречена. И я сильно сомневаюсь что как ты говоришь "исходный текст прошивки является истиной в последней инстанции и полностью описывает ее поведение" т.к. постоянно слышу как народ, отладив прошивку на одном чипе, никак не может заставить тоже самое работать на другом. Одним словом закрытые технологии - не наш путь...
KingOfEvil
28.03.2007, 11:04
Ты не понял... Прошивая микроконтроллер, ROM или скажем PAL я точно знаю за что отвечает каждый бит того, что я прошиваю - в соответствующих спеках всё описано. Прошивая CPLD или FPGA я не знаю ничего... Ну разве что знаю что подал на вход "компилятора", но никогда не узнаю во что это превратилось ибо архитектура девайсов засекречена. И я сильно сомневаюсь что как ты говоришь "исходный текст прошивки является истиной в последней инстанции и полностью описывает ее поведение" т.к. постоянно слышу как народ, отладив прошивку на одном чипе, никак не может заставить тоже самое работать на другом.
Внутренняя структура ПЛИС открыта (см. datasheet-ы).
В принципе, quartus позволяет докапаться до элементарных ячеек ПЛИС, поэтому ничего особо не засекречено, другое дело что этими возможностями никто не пользуется.
Одним словом закрытые технологии - не наш путь...
Разрабатывать конкурентноспособные изделия, не прибегая к помощи cpld/fpga сейчас уже невозможно.
Когда над твоим изделием начинают кулибинское творчество, потом появляются непонятные глюки, а виноват всегда ты, т.к. ты автор.
Ну это легко поправимо. В гарантиях писать что автор не несет ответственности в случае изменения прошивок и прочего.
И ремонт естественно платный в таком случае!
Ты не понял... Прошивая микроконтроллер, ROM или скажем PAL я точно знаю за что отвечает каждый бит того, что я прошиваю - в соответствующих спеках всё описано. Прошивая CPLD или FPGA я не знаю ничего... Ну разве что знаю что подал на вход "компилятора", но никогда не узнаю во что это превратилось ибо архитектура девайсов засекречена.
А зачем тебе это знать? Ты в состоянии проследить связь между тысячами логических эелемнтов? Тогда смотри RTL schematic, там всё есть. Только вот зачем оно в большинстве случаев, когда есть behavioural simulatioin и post-fit simulation.
И я сильно сомневаюсь что как ты говоришь "исходный текст прошивки является истиной в последней инстанции и полностью описывает ее поведение" т.к. постоянно слышу как народ, отладив прошивку на одном чипе, никак не может заставить тоже самое работать на другом.
Народ должен учитывать специфику другого и исходного камня. Вот как раз здесь очень хороши особености VHDL.
KingOfEvil
28.03.2007, 12:30
Ну это легко поправимо. В гарантиях писать что автор не несет ответственности в случае изменения прошивок и прочего.
И ремонт естественно платный в таком случае!
Мне проще закрыть исходники и вообще никаких проблем.
Мне проще закрыть исходники и вообще никаких проблем.
Кулибины всеравно полезут и тогда виноват будешь ты :v2_lol:
Внутренняя структура ПЛИС открыта (см. datasheet-ы).
Внутрення структура, но не точное соотношение бит->ячейка
Копание наугад не считается - всё должно быть задокументировано
ILoveSpeccy
28.03.2007, 21:42
Все! Решил!
для начала возьму XC 9572-15 PC44.
Одну для синхрогенератора (ног должно хватить).
Вторую для клавы, ввода с мафона и вывода на экран.
ПРОЦ, ПЗУ и ОЗУ пока оставлю как есть.
Кстати, можно ли заменить 2764 на 28C256???
Кстати, можно ли заменить 2764 на 28C256???
Можешь, только две адресных линии на что нибудь зацепи( 0 или 1);
Можешь испльзовать 28С64, если есть - тогда все линии совпадут.
KingOfEvil
28.03.2007, 22:46
Внутрення структура, но не точное соотношение бит->ячейка
Копание наугад не считается - всё должно быть задокументировано
А зачем тебе это надо?
А зачем тебе это надо?
т.е. надо довериться разработчикам секретных железяк и не пикать? ;)
Это всё равно что к примеру фирма Intel сказала бы - зачем вам ребята знать систему команд наших процессоров - пишите всё на высокоуровневом языке Intel C и не возникайте - всё равно ничего не поймете :)
deathsoft
29.03.2007, 20:43
Прошивая микроконтроллер, ROM или скажем PAL я точно знаю за что отвечает каждый бит того, что я прошиваю - в соответствующих спеках всё описано.
Скажем так, что для GAL ты тоже ничего не знаешь, кроме логической схемы GAL, которая нарисована внутри даташита, те номера битов, что проставлены в документации фирмы Lattice являются чисто условными. Физически GAL устроен совершенно по другому (что подтверждается текстами патентов (в этих патентах изложена конфиденциальная информация, но в силу особенностей американского законодательства, эта информация должна быть общедоступной, иначе нельзя запатентовать) фирмы Lattice и исходными текстами программаторов, которые программируют GAL).
KingOfEvil
29.03.2007, 21:30
т.е. надо довериться разработчикам секретных железяк и не пикать? ;)
Это всё равно что к примеру фирма Intel сказала бы - зачем вам ребята знать систему команд наших процессоров - пишите всё на высокоуровневом языке Intel C и не возникайте - всё равно ничего не поймете :)
Интерес представляет логическая схема, а не то, какие биты прошивки за что отвечают. Меня это совсем не волнует. А вообще, если не устраивает имеющееся железо можно разработатьт свое - т.е. свою плис, которую по твоему индивидуальному заказу за 5-6 десятков килобаксов изготовят в уникальном исполнении.
Кулибины всеравно полезут и тогда виноват будешь ты :v2_lol:
А мне на это будет уже наплевать. :v2_clap2:
Скажем так, что для GAL ты тоже ничего не знаешь, кроме логической схемы GAL, которая нарисована внутри даташита, те номера битов, что проставлены в документации фирмы Lattice являются чисто условными.
Как раз не условными, а вполне конкретными - файл прошивки можно составлять вручную. А как там всё внутри на самом деле устроено это и не важно - никто ведь не разбирает микрокод процессоров, однако всё что идёт снаружи должно быть разжёвано с точностью до каждого битика.
Добавлено через 3 минуты
Интерес представляет логическая схема, а не то, какие биты прошивки за что отвечают. Меня это совсем не волнует. А вообще, если не устраивает имеющееся железо можно разработатьт свое - т.е. свою плис, которую по твоему индивидуальному заказу за 5-6 десятков килобаксов изготовят в уникальном исполнении.
Для большинства обычных программистов тоже интерес представляет лишь исходник на C/C++, а вовсе не то в какие операции процессора это всё превратится после компиляции, однако по каждому процессору всё описано вполне детально - если следовать твоей логике то зря? ;)
KingOfEvil
30.03.2007, 19:26
Для большинства обычных программистов тоже интерес представляет лишь исходник на C/C++, а вовсе не то в какие операции процессора это всё превратится после компиляции, однако по каждому процессору всё описано вполне детально - если следовать твоей логике то зря? ;)
Здесь речь не об этом. Когда я описываю логическое устройство, я получаю 100%-е соответсвие между описанной логикой в исходнике и структурой взаимоствязей между ячейками внутри ПЛИС. Каким путем это соответствие достигается меня мало интересует, т.к. я занимаюсь разработкой реального железа, а не изучением внутренностей конкретной микросхемы, которое не несет практической пользы.
При написании программ на C мы после компиляции получаем хз что. Никто тоже на 100% не документирует процесс компиляции, а также каким кускам программы на высоком уровне ставятся в соответствие какие куски машинного кода.
Полное описание внутренностей процессора жизненно необходимо, т.к. если планируется использовать его ресурсы на полную катушку оптимальным способом да еще и в реальном времени, то про С можно забыть.
Здесь речь не об этом. Когда я описываю логическое устройство, я получаю 100%-е соответсвие между описанной логикой в исходнике и структурой взаимоствязей между ячейками внутри ПЛИС. Каким путем это соответствие достигается меня мало интересует, т.к. я занимаюсь разработкой реального железа, а не изучением внутренностей конкретной микросхемы, которое не несет практической пользы.
При написании программ на C мы после компиляции получаем хз что. Никто тоже на 100% не документирует процесс компиляции, а также каким кускам программы на высоком уровне ставятся в соответствие какие куски машинного кода.
Полное описание внутренностей процессора жизненно необходимо, т.к. если планируется использовать его ресурсы на полную катушку оптимальным способом да еще и в реальном времени, то про С можно забыть.
В ПЛИС 100% соответствия нет и быть не может - не зря же народ синхронизирует всё что можно и суёт регистры-защёлки где не попадя - иначе многобитные сигналы буду прибегать в разнобой. А по поводу Си - скомпилированный код работает точно в соответствии с той программой что программист написал - почти 100% соответствие, никаких гонок сигналов и т.д. Да и на самом деле всё задокументировано и для компиляторов. Засекреченно-закрытыми решениями в программировании пользуются всё меньше и меньше - так вот я и задаюсь вопросом почему в железной компиляции до сих пор всё засекречено и закрыто? То ли дело в 80-х было раздолье - поячеечные форматы PAL-ов всем известны, а в книжке про них листинг программы PALASM на фортране и бейсике...
KingOfEvil
31.03.2007, 09:49
В ПЛИС 100% соответствия нет
Откуда такая уверенность в том, что на деле неверно? Ты сам что-то делал на плис и проверял на соответсвие? Вплоть до элементарных ячеек? Приведи в качестве доказательсва проект, в котором в исходнике описана одна логика работы, а на деле (т.е. внутри ПЛИС) логика не такая.
и быть не может
Дубль 2. Известны на 100% все взаимосвязи между ячейками в ПЛИС. Известны на 100% параметры конфигурируемых логических блоков, программируемых мультиплексоров и т.д. Вплоть до каждой элементарной макроячейки. Чего еще нужно?
- не зря же народ синхронизирует всё что можно и суёт регистры-защёлки где не попадя - иначе многобитные сигналы буду прибегать в разнобой.
То, что нужно вводить синхронизацию - это нормально. В любых громоздких асинхронных логических схемах (не только в ПЛИС) возникает эффект гонок, который не существует в синхронных схемах. Идеология ПЛИС предполагает построение именно синхронных схем. Кстати, у меня тагих глюков не возникало.
Дубль 2. Известны на 100% все взаимосвязи между ячейками в ПЛИС. Известны на 100% параметры конфигурируемых логических блоков, программируемых мультиплексоров и т.д. Вплоть до каждой элементарной макроячейки. Чего еще нужно?
"Известны на 100%" это когда можно залезть в файл прошивки и вручную поправить битики...
deathsoft
31.03.2007, 15:35
То ли дело в 80-х было раздолье - поячеечные форматы PAL-ов всем известны, а в книжке про них листинг программы PALASM на фортране и бейсике...
В 80х может и было, а щас все засекречено Atmel для своих ATF22V10 даже нумерацию битов не приводит, алгоритм прошивки с точность противоположный алгоритму фирмы Lattice (биты задом наперед в микросхему при программировании передаются). Про то как самому сделать программатор для PAL/GAL как не было информации так и нет (эта информация выдается только фирмам разработчикам программаторов под NDA). Нету информации даже про древней микросхеме 85c220 (ep220) (нету ни описания соответствия битов файле с логической схемой, ни тем более как их читать и программировать) которая представляет собой усовершенствованный GAL22V10
KingOfEvil
31.03.2007, 16:13
"Известны на 100%" это когда можно залезть в файл прошивки и вручную поправить битики...
"Известны" значит, что известны, а не то, что их можно ковырять и портить. Если надо что-то изменить, то изменения вносятся в исходнике.
"Известны" значит, что известны, а не то, что их можно ковырять и портить. Если надо что-то изменить, то изменения вносятся в исходнике.
Опять двадцать пять... Многие программисты точно также думают, однако разработчики процов печатают все спецификации и выкладывают в открытый доступ - тупят? ;)
Добавлено через 2 минуты
В 80х может и было, а щас все засекречено Atmel для своих ATF22V10 даже нумерацию битов не приводит, алгоритм прошивки с точность противоположный алгоритму фирмы Lattice (биты задом наперед в микросхему при программировании передаются). Про то как самому сделать программатор для PAL/GAL как не было информации так и нет (эта информация выдается только фирмам разработчикам программаторов под NDA). Нету информации даже про древней микросхеме 85c220 (ep220) (нету ни описания соответствия битов файле с логической схемой, ни тем более как их читать и программировать) которая представляет собой усовершенствованный GAL22V10
Да уж - напридумывали секретов вокруг старых технологий... Приглянулись мне ispGAL22V10 с возможностью последовательного программирования цепочки девайсов прямо в схеме, однако при ближайшем рассмотрении оказалось, что прошивать можно только с помощью их утилиты под винды по засекреченному протоколу...
deathsoft
31.03.2007, 20:28
Приглянулись мне ispGAL22V10 с возможностью последовательного программирования цепочки девайсов прямо в схеме, однако при ближайшем рассмотрении оказалось, что прошивать можно только с помощью их утилиты под винды по засекреченному протоколу...
Вот ответ на твой вопрос http://www.totalisp.com/forums/forum/messageview.cfm?FTVAR_FORUMVIEWTMP=Threaded&catid=107&threadid=4585, т.ч. возможно не все потеряно
Вот ответ на твой вопрос http://www.totalisp.com/forums/forum/messageview.cfm?FTVAR_FORUMVIEWTMP=Threaded&catid=107&threadid=4585, т.ч. возможно не все потеряно
In general, Lattice's company policy provides programming algorithm to the approved third party vendors and through the ISP embedded code...
т.е. ничего в открытом доступе нет и не будет
deathsoft
31.03.2007, 23:18
n general, Lattice's company policy provides programming algorithm to the approved third party vendors and through the ISP embedded code...
т.е. ничего в открытом доступе нет и не будет
токо там ниже было написано, напишите на емэйл такой то и мы вышлем вам код для программирования. Более того мужик вначале на какую то латисовскую книжку ссылался где описан алгоритм программирования обычных GAL.
токо там ниже было написано, напишите на емэйл такой то и мы вышлем вам код для программирования. Более того мужик вначале на какую то латисовскую книжку ссылался где описан алгоритм программирования обычных GAL.
ну им надо ещё доказать что ты "approved third party vendor" - и к тому же такой код будет нелегально вставлять в свою программу, предполагаемую к коммерческому или свободному распространению
KingOfEvil
01.04.2007, 00:55
Опять двадцать пять... Многие программисты точно также думают, однако разработчики процов печатают все спецификации и выкладывают в открытый доступ - тупят? ;)
Читай внимательнее предыдущий(ие) пост(ы).
Читай внимательнее предыдущий(ие) пост(ы).
А что читать? Я твою позицию по данному вопросу понял, а именно: разработчик железа должен свято верить в непогрешимость и идеальность компилятора от его любимого производителя ПЛИСов и даже в страшном сне не должен думать на уровне ячеек - это ведь никому не нужно, поэтому производители всё держат в секрете - чтобы разработчики спали спокойно. В случае же разработчиков софта для микроконтроллеров и микропроцессоров - там всё документировано, что привело к возникновению массы несовместимых между собой компиляторов, которые настоящим пацанам нафиг ненужны ибо настоящие пацаны пишут только на голом ассемблере ибо хотят заюзать все так тщательно задокументированные возможности процессора...
Моя точка зрения, которую почему-то я ни до кого не могу донести - разработка железа и разработка софта уже сейчас практически слились в экстазе в одну гибридную хардверно-софтверную разработку - процессоры используют быстрые распараллеленные вычисления, а FPGA на самом деле являются набором разнообразных простых программируемых вычислителей, и лично мне кажется странным, что в области софта всё открыто, а в области железа закрыто - ведь это всё суть одно и тоже...
KingOfEvil
01.04.2007, 10:33
А что читать? Я твою позицию по данному вопросу понял, а именно: разработчик железа должен свято верить в непогрешимость и идеальность компилятора от его любимого производителя ПЛИСов и даже в страшном сне не должен думать на уровне ячеек - это ведь никому не нужно, поэтому производители всё держат в секрете - чтобы разработчики спали спокойно. В случае же разработчиков софта для микроконтроллеров и микропроцессоров - там всё документировано, что привело к возникновению массы несовместимых между собой компиляторов, которые настоящим пацанам нафиг ненужны ибо настоящие пацаны пишут только на голом ассемблере ибо хотят заюзать все так тщательно задокументированные возможности процессора...
Моя точка зрения, которую почему-то я ни до кого не могу донести - разработка железа и разработка софта уже сейчас практически слились в экстазе в одну гибридную хардверно-софтверную разработку - процессоры используют быстрые распараллеленные вычисления, а FPGA на самом деле являются набором разнообразных простых программируемых вычислителей, и лично мне кажется странным, что в области софта всё открыто, а в области железа закрыто - ведь это всё суть одно и тоже...
Если и с 3-го дубля человек меня не понимает, значит не судьба.
deathsoft
01.04.2007, 13:27
и к тому же такой код будет нелегально вставлять в свою программу, предполагаемую к коммерческому или свободному распространению
Этот код можно дизасемблировать и понять как работает алгоритм программирования, а потом написать свой код, который реализует этот алгоритм.
Если и с 3-го дубля человек меня не понимает, значит не судьба.
Мы как будто на разных языках разговариваем...
Добавлено через 57 минут
Этот код можно дизасемблировать и понять как работает алгоритм программирования, а потом написать свой код, который реализует этот алгоритм.
Да он вроде в исходниках на Си идёт - там проблема в том, что шьёт он некий специальный файл, приготовленный в ихней программе, т.е. чтобы мои прошивки в формате 22v10 так прошить, их ещё сконвертить надо - а хотелось бы иметь возможность готовить их полностью автоматически
Опять двадцать пять... Многие программисты точно также думают, однако разработчики процов печатают все спецификации и выкладывают в открытый доступ - тупят? ;)
Ну сам подумай, зачем прикладному программисту такого рода инфа? Он юзает дельфи или с, разработчики компиляторов этих "дельфи и с" юзали именно тобой упомянутую инфу для разработки компиляторов.
Шурик хотел по моему сказать следующее, что используя неполностью документированные плисы, мы заранее подсаживаем себя на среду разработки от производителя. И невозможно создать систему которая будет видоизменять сама себя (так как необходимо всеравно использовать некий тулкит от разработчика).
В случае с полностью открытой системой мы этого избегаем.
Но в данном конкретном случае (разработка клона), нам действительно не принципиально есть тулкит или нет.
Шурик хотел по моему сказать следующее, что используя неполностью документированные плисы, мы заранее подсаживаем себя на среду разработки от производителя. И невозможно создать систему которая будет видоизменять сама себя (так как необходимо всеравно использовать некий тулкит от разработчика).
В случае с полностью открытой системой мы этого избегаем.
Но в данном конкретном случае (разработка клона), нам действительно не принципиально есть тулкит или нет.
Ага - примерно так ;)
А вообще моя мечта идиота применительно к ZX-клонам состоит в следующем - (1) подготовка прошивки плисин(ы) клона на самом клоне и (2) перепрошивка самоё себя без участия PC - в случае Спринтера пункт 2 имелся в наличии, а вот пункт 1 в настоящее время физически невозможен (на сколько нибудь приемлемом уровне сложности выше простейшего, коим являются PAL/GAL-ы) по вышеобозначенным мною причинам...
Ага - примерно так ;)
А вообще моя мечта идиота применительно к ZX-клонам состоит в следующем - (1) подготовка прошивки плисин(ы) клона на самом клоне и (2) перепрошивка самоё себя без участия PC - в случае Спринтера пункт 2 имелся в наличии, а вот пункт 1 в настоящее время физически невозможен (на сколько нибудь приемлемом уровне сложности выше простейшего, коим являются PAL/GAL-ы) по вышеобозначенным мною причинам...
Ну первое можно в любом клоне приципиально. Где-же я читал-то, вроде Xilinx запустил серию (или будет запускать) с внутренним flash rom, который используется для прошивки плис при старте и с которым можно работать как с обычным флешем.
Ну первое можно в любом клоне приципиально. Где-же я читал-то, вроде Xilinx запустил серию (или будет запускать) с внутренним flash rom, который используется для прошивки плис при старте и с которым можно работать как с обычным флешем.
Под подготовкой прошивки я имел ввиду компиляцию из какого-то визуального представления в непосредственно код для прошивки - щас это без пакета программ для PC от разработчиков конкретных железяк не сделать.
Под подготовкой прошивки я имел ввиду компиляцию из какого-то визуального представления в непосредственно код для прошивки - щас это без пакета программ для PC от разработчиков конкретных железяк не сделать.
Это я прогнал, имелся в виду пункт 2 :v2_blush:
Это я прогнал, имелся в виду пункт 2 :v2_blush:
Пункт 2 реализован в Спринтере - имея готовый файл прошивки на дискете (склеенной вместе с образом биоса) её можно загнать во флеш с помощью специальной программки, а после ребута FPGA засосёт эту прошивку из флеши и будет по ней работать. Как-то так...
Пункт 2 реализован в Спринтере - имея готовый файл прошивки на дискете (склеенной вместе с образом биоса) её можно загнать во флеш с помощью специальной программки, а после ребута FPGA засосёт эту прошивку из флеши и будет по ней работать. Как-то так...
Это всё понятно. Ничего не мешает по идее писать тем же Z80 в турбе (3,5МГц маловато) или АВРом например в parallel slave mode в том же Respect, буде он на FPGA.
Это всё понятно. Ничего не мешает по идее писать тем же Z80 в турбе (3,5МГц маловато) или АВРом например в parallel slave mode в том же Respect, буде он на FPGA.
А хотелось бы ещё этот образ на том же клоне и готовить...
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot