Просмотр полной версии : Некоторые результаты
Закончил "подключение" CGA к ленинграду.
Что можно сказать...
Монитор на 60Гц можно заставить работать и на 50.
Если не залезать в схему, то увеличением времени задержки
от кадрового импульса до начала отображения на экране.
Но это вызывает заметное мерцание, т.е. вертикальная скорость
луча остаётся как на 60Гц(и соотв.время засветки), а общее время
кадра - 50Гц. Частота строк - никакого влияния не оказывает.
Самым простым решением посчитал установку переключателя
на плате (50/60Гц) и добавил одну ле1, для формирования
кадрового импульса.
Рабочая часть экрана по вертикали 85%, по горизонтали - 75%.
Надо будет ещё проверить переделку на 512 точек в строке.
Собрал и подключил эмулятор пзу - стенд для экспериментов готов.
Начну с простого - попробую прикрутить PS/2 клаву и мышку.
Собрал и подключил эмулятор пзу - стенд для экспериментов готов.
Начну с простого - попробую прикрутить PS/2 клаву и мышку.
Схему сам будешь разрабатывать или Камилевскую использовать?
В полку железячников прибывает - что радует!
mail
В полку железячников прибывает - что радует!
Жалко, только, что программеров убывает:(
"Камилевскую использовать?" - насколько я помню, там PIC?
Попробую на "логике" собрать.
Если и буду исользовать, то наверное AVR1200 или 51, они дешевле.
Да и нагрузить его надо сильнее, а это требует обдумывания :)
насколько я помню, там PIC?
Нет AVR (ATMega8515 или AT90S8515, что будет проще достать).
Попробую на "логике" собрать.
Глупо. Эта AVR тройкой проводов от LPT програмится. Затраты небольшие (~3-4$) и запросто себя окупают. Можно конечно и на AT89C51 (AT89C2051), но оно обойдется по трудозатратам дороже.
Нет AVR (ATMega8515 или AT90S8515, что будет проще достать).
Глупо. Эта AVR тройкой проводов от LPT програмится. Затраты небольшие (~3-4$) и запросто себя окупают. Можно конечно и на AT89C51 (AT89C2051), но оно обойдется по трудозатратам дороже.
Более того - 51ые банально тормознее (по крайней мере те, что дешевле чем 8515ые). А там же ведь ваит даётся ещё...
"Камилевскую использовать?" - насколько я помню, там PIC?
В который раз уже наблюдаю - насколько пикомания разъела наши ряды! =)
Попробую на "логике" собрать.
Эхехе, ну как говорится, флаг в руки =) На самом деле не на МК такое сделать сложновато, мягко говоря.
Собрал и подключил эмулятор пзу - стенд для экспериментов готов.
Начну с простого - попробую прикрутить PS/2 клаву и мышку.Рекомендую собрать схему на ATTiny2313 - легко справляется с обслуживаем и мышки и клавиатуры.
И стоит это все не дорого.
А программируется на любой IBM-ке по LPT-порту.
Рекомендую собрать схему на ATTiny2313
По хорошему, неплохо и прошивку выложить:)
Если и буду использовать, то наверное AVR1200 или 51, они дешевле.AT90S1200 сняты с производства, рекомендуемая замена - ATTiny2313.
AT89C2051 стоит чуть дешевле ATTiny2313, но не сравнима с ней по производительности.
"На самом деле не на МК такое сделать сложновато" - Это не совсем верно.
"AT90S1200 сняты с производства, " - думаю китайцы их продолжают клепать,
и купить легко ...
Если получится на "логике", то потом можно легко будет запихать в плм.
"На самом деле не на МК такое сделать сложновато" - Это не совсем верно.Мне кажется в пределах разумной сложности и в пределах требуемой функциональности это просто не возможно. Учитывая еще и желательность двухстороннего обмена между PS/2 устройством и контроллером.
"AT90S1200 сняты с производства, " - думаю китайцы их продолжают клепать, и купить легко ...Не слышал что бы AVR-ы делал еще кто-нибудь кроме ATMEL.
И не понял логики, если устройство снято с производства и взамен предлагается другое, по близкой цене, но более совершенное - почему его надо искать у китайцев :).
Если получится на "логике", то потом можно легко будет запихать в плм.На ПЛМ есть, могу даже кинуть файлы, если надо.
Ладно, будет результат - обрисую. Пока отлавливаю баги в эмуляторе :)
Вроде уже все отловил :)
Если получится на "логике", то потом можно легко будет запихать в плм.
Преобразователь потока бит, таблица соответствия клавиш и многое другое потребует нереальных затрат. В лучшем случае по объему это выльется в 30-40 корпусов. Если же это сразу пихать в ПЛИС, то это будет более реально.
На ПЛМ есть, могу даже кинуть файлы, если надо.
Если нетрудно, просьба запостить.
Кстати, а прошивку к вышепреведеной схеме где искать?
по поводу "На ПЛМ есть, могу даже кинуть файлы, если надо."
Если нетрудно, просьба запостить.Это часть проекта из: http://c64upgra.de/c-one/
Кстати, а прошивку к вышепреведеной схеме где искать?Чуть позже кину сюда.
Чуть позже кину сюда.
А "позже" в привычных единицах измерения это сколько? :)
Собственно результаты.
При включении любая клава устанавливается в "Set1" - совместимый
с кодами XT. Проверил на простом регистре сдвига - отлично работает.
Минимально - 2 микросхемы :)
С уверенностью утверждаю 30-40 корпусов - бред.
Реально - 7-10 самой мелкой рассыпухи ...
Думаю над реализацией.
Собственно результаты.
При включении любая клава устанавливается в "Set1" - совместимый
с кодами XT. Проверил на простом регистре сдвига - отлично работает.Что то мне не попадались современные AT-клавиатуры,
которые по умолчанию встают в режим Scan Code Set1.
Все по включению питания переходят в режим Scan Code Set2.
Только что специально еще раз проверил.
Более того ни одна из тех, что у меня сейчас есть (5 штук),
не хочет переключатся в режим Scan Code Set 1
командой ALT_SCAN (код команды #F0).
В режим Scan Code Set3 переключаются без проблем.
Кстати именно в этом режиме работают клавиатуры в моем контроллере.
Думаю над реализацией.Честно говоря даже интересно, что получится.
Тем более что режим по включению не имеет значения
если он стабильно постоянный.
Да, блин, точно set2, не XT :)
Но это роли не играет. Главно единообразие кодировки
и возможность обойтись одним регистром.
Проверял на AT(mitsumi), PS/2 (sven и ещё одна китайская :)
Да, блин, точно set2, не XT :)
Но это роли не играет. Главно единообразие кодировки
и возможность обойтись одним регистром.Регистр то один (правда не для всех клавиш), только scan-cod IBM-клавиши надо как то
перекодировать в код матрицы 8*5 спектрумовской клавиатуры.
И как тут можно обойтись 10-ом цифровой рассыпухи хоть убей не пойму :)
В общем заинтриговал - жду дальнейших результатов.
Подобная схема (перекодировщик) работала в ZX-Next. Из минусов: запоминалась только одна нажатая клавиша (разумеется, кроме шифтов) и работала только с XT клавиатурами (однобайтный скан-код).
Разработал я ее как временную, но расширенный варрант на PIC-е так и не был доделан. Если считать по логическим элементам, в ней восемь корпусов, можно ужать до семи.
D2 ЛЕ1
D3 ЛЛ1
D10 ЛИ1
D13 ИВ1
D14 ИР23
D15 АГ3
D16 573РФ2(5)
D17 КП13
Прошивка ПЗУ есть у меня и у CHRV.
Разумеется, сравнивать эту схему с современными контроллерами на однокрисалках (контроллером Камиля) нельзя, в виду значительно большей функциональности последних.
Да, примерно так, но для современных клав....
Немного посмотрел 2-х байтные коды.
Получается такой расклад:
Одиночная кнопка - её код 2 раза ...?
Отпускание - F0, код клавиши.
Две клавиши - код удерживаемой, затем второй ...
Затем - как одиночные.
Может кто подскажет стандат(ы) отображения клавы ZX->PC клава?
Может кто подскажет стандат(ы) отображения клавы ZX->PC клава?
Например, как в унреале по дефолту.
Собрал приёмник ... а одной клавиши хватит?
Нужно ли поддерживать более 1-й нажатой?
Схема приёмника. Можно упростить до 4-5 корпусов.
Нужно ли поддерживать более 1-й нажатой?
в какой-то игре был такой чит, что для включения режима бессмертия надо было нажать одновременно все 40 клавиш, так-то для обеспечения совместимости надо :-))
да и вообще в играх часто встречаются двухклавишные комбинации типа вперед+вверх, вперед+огонь...
в какой-то игре был такой чит, что для включения режима бессмертия надо было нажать одновременно все 40 клавиш, так-то для обеспечения совместимости надо :-))
да и вообще в играх часто встречаются двухклавишные комбинации типа вперед+вверх, вперед+огонь...Контроллеры IBM-ских клавиатур (имеются ввиду встроенные в саму клавиатуру)
принципиально имеют ограничение на число нажатых клавиш.
Обычно поддерживается до 6 одновременно нажатых клавиш.
В большинстве случаев для Спектрума этого за глаза хватает.
В схеме - NOT KB_DATA - на 6
Для себя я сформулировал так:
игры - можно использовать отдельные "игровые" кнопки
остальной софт - использовать только "одиночные нажатия"
...
Прикупил 556рт1(дороговато - по 4р) :)
Можно заменить всю логику, может 2 триггера - приёмник
выйдет на 3-х мс ...
Регистр клавиши*, шифратор, пзу, дешифратор
Всего 7 мс набирается ...
Думаю прикрутить как порт, наверно на адреса interface-I ...
Можно будет мышку подключать :)
Может мыша подключать на свободные биты порта FE?
Будет логично - клава и мышина в одном ...
Может мыша подключать на свободные биты порта FE?
Будет логично - клава и мышина в одном ...
Или может вот как. Мышь отображаем на джойстик, например Sinclair. А чтобы работать сней полноценно стваить бит 7 в порте FEh. Тогда и как бы джойстик и вроде есть расширение.
вы бредите ребята - никто старый софт переделывать не будет как и писать новый под это дело. кемпстон маус и точка.
"Мышь отображаем на джойстик"
Опрос мыши можно производить по прерыванию, например.
А как дальше - определяется софтом ...
вы бредите ребята - никто старый софт переделывать не будет как и писать новый под это дело. кемпстон маус и точка.
В основном ни кто и не говорит о переделки софта. Здесь обсуждается идея совмещения мыши и клавы. Я например не буду городить приблуду, называемую как kempston мышь отдельно. Лучше сделать одно устройство, которое будет и преобразовывать PC клаву и мышь. К тому же если сделать стандартное отобрадение мыши на джойстик - то kemston мышь в ближайшие 100 лет не понадобится :) . И старый софт, который поддерживал джойстики будет работать и от мыши.
"Мышь отображаем на джойстик"
Опрос мыши можно производить по прерыванию, например.
А как дальше - определяется софтом ...
Ну по сути мышь это тот же джойстик - т.е. перемещение мыши влево - то же что ручку джойстика отклоняешь влево. Ну и так далее. Единственное что не удел остаются кнопки, кроме одной (ее же отображаем на Fire) или колесо.
Проблема с софтовым подключением мышки - низкая скорость передачи.
Придётся ещё городить регистр ... Хотя ...
Примерная стоимость переходника PS/2(AT)->ZX
выходит (только детальки) - 20-25р
Ну и получается на 7-10 мс (смотря из чего делать)
Вот.
К тому же если сделать стандартное отобрадение мыши на джойстик
пробовал? я - да. шляпа полная - нету у джойстика такого понятия как скорость
пробовал? я - да. шляпа полная - нету у джойстика такого понятия как скорость
Вот я и собираюсь проверить это на деле. Скорость мыши можно и программно обработать. На то и есть великое множество микроконтроллеров, чтобы им было чем заняться. Эмулировать лучше всего Sinclair джойстик, так он сидит на клаве.
Лучше мне скажите великие знатоки Spectruma стандартую клаву всегда одним битом (0) сканируют или есть индивидумы, которые сканируют двумя и более 0?
Лучше мне скажите великие знатоки Spectruma стандартую клаву всегда одним битом (0) сканируют или есть индивидумы, которые сканируют двумя и более 0?Очень часто сканируют нулями на всей шине адреса.
Так определяется факт нажатия хотя бы одной клавиши.
А расчитывать надо на любой вариант, не только на один или два адреса.
"нулями на всей шине адреса" - это можно ...
Очень часто сканируют нулями на всей шине адреса.
Так определяется факт нажатия хотя бы одной клавиши.
А расчитывать надо на любой вариант, не только на один или два адреса.
Если два или более нуля в принципе это уже не логично. Можно и нужную клаву спутать. В стандартной прошивке BASIC 48 там как сканируют, одним нулем перебирают все линии и этим самым определяют нужные комбинации такие как EDIT, EXTMODE и т.д. или все же не так?
Если два или более нуля в принципе это уже не логично. Можно и нужную клаву спутать.
Потому что у тебя логика какая-то неправильная.
Рассказываю секреты - учись, пока жив:
Надо вот опросить 10 кнопок разных. А неохота сразу нулём двигать. Смотрим, в каких рядах эти кнопки, ставим нули там, 1 разом узнаём, надо ли вообще сканировать.
В стандартной прошивке BASIC 48 там как сканируют, одним нулем перебирают все линии и этим самым определяют нужные комбинации такие как EDIT, EXTMODE и т.д. или все же не так?
Анрил тебе в руки - и копайся... Или неинтересно на самом деле?
Собственно железно - отображение нажатой клавиши на клаву ZX,
плюс поддержка опроса по "все нули"
Получится дёшево и сердито :) Вот только решить, как РТшки прошивать ...
Для мышки - схема немногим сложнее, только первоначальную
инициализацию надо ...
Из этих соображений - как насчёт использования D5,D7 порта #FE?
И попутно - имеет смысл подключать регистр приёмника клавы как порт?
Собственно железно - отображение нажатой клавиши на клаву ZX,
плюс поддержка опроса по "все нули"Я надеюсь про фиксацию SHIFT-клавиш не забыли.
И попутно - имеет смысл подключать регистр приёмника клавы как порт?На это нет никакого стандарта, а вводить новый не имеет смысла.
"про фиксацию SHIFT"
А я ещё и ALT хотел ...
"вводить новый не имеет смысла"
Но это полезно с практической точки зрения ...
И по затратам минимально.
А я ещё и ALT хотел ...Нет такой клавиши в Спектруме
Но это полезно с практической точки зрения ...
И по затратам минимально.Насчет полезности - сомнительно.
Какой смысл иметь два источника информации о клавиатуре.
"полезности - сомнительно"
Например - была темка связи двух ZX ...
Можно передавть хоть 1Мбайт/сек.
Главное НО - нет реальной основы, под этими "темами"
(ещё раз перечитал ...) А соответственно переходник
для клавиатуры - внешнее к ZX ус-во.
Процесс разработок сменил направление :)
Собственно вопрос - бестрансформаторный БП для ZX?
Правильность фазировки обеспечить ...
Какие ещё могут быть камни?
По выводу на телевизор...
Если частота сигнала ограничена 5 МГц, то
получаем 320 точек (вместе с синхроимпульсом).
Если вычесть синхрнизацию - 262.
Может где я не прав?
Косяк нашел :) Надо количество точек удваивать.
Теперь ясно почему кварц на 14 Мгц - частота получается
до 3,5 МГц (и ясно почему выше не поднять)
По выводу на телевизор...
Если частота сигнала ограничена 5 МГц, то
получаем 320 точек (вместе с синхроимпульсом).
Если вычесть синхрнизацию - 262.
Может где я не прав?
Может где и неправы, ибо путаете полосу пропускания и кол-во пикселей. Что бы не отсылать к чтению книг по основам телевидения, предложу следующий наглядный пример: подаем на телевизор меандр (прямоугольные импульсы) с частотой 5 МГц, (разумеется, в местах синхроимпульсов не подаем). Что мы видим на экране? Правильно, поле, где в каждой строке чередуются 262 черные и 262 светлые точки. Надеюсь, «итого» выводить не надо.
P.S. Полоса яркостного сигнала PAL/SECAM B,G,H действительно ограничена 5МГц (SECAM D,K,L – 6МГЦ), а вот частота 6МГц (SECAM D,K,L – 7МГЦ).
P.P.S. Что интересно, в настойках видеоадаптеров, для PAL указывается разрешение 720х576 (или даже 768х576), что также означает верхнюю частоту около 7 МГц.
"Что интересно" Это точно, в некоторых кодерах
стоит фильтр на 5 МГц ...
В «некоторых кодерах» вполне возможно и стоит. Например, для стандартного разрешения ZX Spectrum более 3,5 МГц яркостного сигнала и не нужно. Но что касается верхней границы, то для телестандарта (PAL/SECAM) она явно выше. Если интересно, посмотрите например вот этот учебник (http://www.do.sssu.ru/virt/library/uchebnik/tv/tvindex.html), и в частности эту главу (http://www.do.sssu.ru/virt/library/uchebnik/tv/moderntv.html).
По источнику питания.
Бестрансформаторный - нужен хороший дроссель, что сводит на 0 все плюсы.
Импульсных (готовых) трансф. не нашел ... не возят ...
Из того что есть - обычный транс. на 220 (а их завсегда полно) и
имп. стабилизатор. Это пока самое оптимальное.
Между делом возник вопрос по легальности софта для ZX ...
В каком он статусе?
Процесс разработок сменил направление :)
Собственно вопрос - бестрансформаторный БП для ZX?
Правильность фазировки обеспечить ...
Какие ещё могут быть камни?
По источнику питания.
Бестрансформаторный - нужен хороший дроссель, что сводит на 0 все плюсы.
Импульсных (готовых) трансф. не нашел ... не возят ...
Из того что есть - обычный транс. на 220 (а их завсегда полно) и
имп. стабилизатор. Это пока самое оптимальное.
Ничего не понял. Тебе нужен источник питания для спека? Возьми ПЦшный! ATX какой-нибудь типа power man'a - не самый дешёвый и не самый дорогой полукиловаттный =)
Сам хочешь сделать импульсник? Смотри в сторону tiny (м/сх таких, содержат в себе высоковольтный ключ и контроллер со стабилизацией). Гугли по "top switch", "tiny switch". Сам делал на самой маломощной из tiny'к (правда, не для спека). Схема простая, как 2 копейки, из сложного - только намотать транс (мотал на готовом горшке, под него рассчитал кол-во витков и намотал).
Масса-габариты должны быть адекватны.
Масса-габариты должны быть адекватны.
Кожух можно снять. У тебя мощности будут не требующие вентилятора.
У нас разные концепции ...
А что насчет софта ... кто просветить может?
Оказалось в продаже есть ипульсные источники для встраивания ...
Т.е. собранная плата(без корпуса), интересно ...
По поводу применения контроллеров для ZX.
Сильно смущает то, что применяется контроллер значительно
производительнее цп ... Этакий реактивный костыль :)
Например, атмега. Он может просто софтово эмулировать Z80,
плюс встроить дешифрацию портов и расширение памяти ...
Вооот.
Этакий реактивный костыль
Ничего нет плохого в том, что прогресс идёт вперёд и сейчас можно за довольно разумные деньги покупать производительные и многофункциональные MCU.
Он может просто софтово эмулировать Z80
Вряд ли получиться 1:1, если на Motorolla 68... которые в Palm ставят не получилось.
"Вряд ли получиться 1:1" Только обработку команд, а не формировать
сигналы ...
"Ничего нет плохого в том" Так вопрос в другом. Нужно ли поддерживать
Z80 или полностью переходить к эмуляции.
Лучше переходить на Verilog или VHDL и FPGA. Это более оптимально.
"Лучше переходить " к тому и идет ...
Если посмотреть на последние "усовершенствования",
то производительность цп составит 30%(мах)
На каком проценте Z80 станет не нужен? :)
James DiGreze
19.04.2006, 10:23
На каком проценте Z80 станет не нужен?
Это к вопросу о сохранении совместимости, живой пример - платформа x86.
Здесь, наверно, требуется сравнение с процентом нового софта...
Если нового софта сейчас <50%, то Z80 даже при использовании всего на 1% будет нужен. Но новый софт может появиться только на основе старого, такова идеология Спектрума... Или же это будет не Спектрум...
"живой пример - платформа x86."
Ну да, а софт тут причем? Эмуляторов куча ...
James DiGreze
19.04.2006, 11:31
Я в том ключе упомянул, что прог, написанный для 8086, должен работать и на P-IV... Совместимость, мля! Почти hardware emulation ;)
Сильно смущает то, что применяется контроллер значительно
производительнее цп ... Этакий реактивный костыль
А чего смущаться? Имхо, на ПЦ типичный видеоадаптер имеет мипсов и флопсов по-более чем ЦПУ... А в нашем случае Z80 выполняет функции диспетчера потоков данных. Зачем на него взваливать непосильные задачи? Пусть остается кем есть - ЦПУ ;)
По поводу применения контроллеров для ZX.
Сильно смущает то, что применяется контроллер значительно
производительнее цп ... Этакий реактивный костыль :)
Это ИМХО очень хороший и правильный подход. Для сравнения: твой мозг физически тебя не передвигает, только даёт команды, скажем, специализированым (именно на данной функции) частям твоего тела. А нога сильнее физически, чем твой мозг :)
"видеоадаптер имеет мипсов и флопсов по-более "
Но нет возможности одним заменить другой ...
"очень хороший и правильный подход"
Наоборот.
Можно в пц поставить Z80 и передавть на него команды с пц ...
Будет спектркум со гиговой памятью, SCSI и пр.
"Для сравнения:" сравнение неверное,
контроллер эффективнее Z80 во всем.
"очень хороший и правильный подход"
Наоборот.
Можно в пц поставить Z80 и передавть на него команды с пц ...
Будет спектркум со гиговой памятью, SCSI и пр.
Не будет Спектрума. Хотя Z180 в ПЦ ставили, в модемы.
"Для сравнения:" сравнение неверное,
контроллер эффективнее Z80 во всем.
Ну да, по парку лучше не машине, чем на велосипеде.
"Для сравнения:" сравнение неверное,
контроллер эффективнее Z80 во всем.
Вся фишка в том, что уже много софта написано и заставить работать как можно больший процент на своём железе (будь оно на Z80, CPLD, FPGA, MCU + куча всего покупного и самодельного) - это должно быть целью.
James DiGreze
20.04.2006, 05:44
"очень хороший и правильный подход"
Наоборот.
Почему? Хочу обоснование! Обоснование в студию!!! :)
А что обосновывать? Если одна мс может выполнить функции другой,
плюс ещё 2-х, зачем её использовать на 20%, как довесок?
А что обосновывать? Если одна мс может выполнить функции другой,
плюс ещё 2-х, зачем её использовать на 20%, как довесок?
Затем, что бы каждая мс занималась только своим делом - в этом вся прелесть.
James DiGreze
20.04.2006, 12:25
Точку зрения понял. Но не принял. Больше спорить не буду... :)
Рационализм - весчь хорошая, одно не пойму, зачем тогда прикручивать АТ/ХТ клаву, если есть стандартное кнопочное поле...
"каждая мс занималась только своим "
Так что, вместо одной плисины нужно поставить 10 ...
(но каждая будет заниматься своим делом) :)
"АТ/ХТ клаву, если есть стандартное" Так нет, а этих клав(PS/2) - как грязи ...
Речь о том, что в железе Z80 наверно уже не нужен ...
"АТ/ХТ клаву, если есть стандартное" Так нет, а этих клав(PS/2) - как грязи ...
PS/2 == AT, токо разъем другой.
Это Mini-ITX в корпусе коммодора. А есть и nano-ITX!
Ставим эмулятор - и вперед :)
Вот подумалось ...
Варианты разработки "нового ZX железа":
1) РС эмулятор (miniPC разных видов) под корпус ZX
Здесь всё ясно, без комментариев :)
2) Разработка компьютера-эмулятора ZX(современный процессор)
Возможно, как побочный продукт разработки для других целей.
Иначе - выгоднее п.1
3) "Карманный ZX"
Радикальная минимизация "железа" и потребления.
Представляет интерес при значительно меньшей цене
альтернативных решений (КПК+эмулятор)
4) Новая реализация на логике ("клон")
Интерес представляет как "ретро-инженеринг"?
5) Разработка устройств для существующих "клонов"
6)?
2) Разработка компьютера-эмулятора ZX(современный процессор)
Возможно, как побочный продукт разработки для других целей.
Иначе - выгоднее п.1
я уж давно вынашиваю идею компа на 486 , а выполнять комады Z80 через бивис предевать управление на сопр (Z80)
впринцепе тормож будет жуткий :)
"идею компа на 486 "
Это скорее - 1) РС эмулятор ...
У меня была мысля отрубить пилой от 386-й половину (где слоты).
James DiGreze
25.05.2006, 10:19
У меня была мысля отрубить пилой от 386-й половину (где слоты)А не надежнее достать 386 в PLCC и развести плату самому? ;) Не думаю что там требуется специальный чипсет...
to geners:
ЧЕстно говоря удивляюсь тому абсурду до которого может довести любительство... :v2_jawdr:
В вашем случае самое разумное решение это использовать так называемые СистемОнЧип (SOC) т.е. взять какойнить АРМ/АВР и возложить на него все периферийные функции. АРМ сожно взять например из убитых телефонов, торговых терминалов и прочего.
"самое разумное решение "
Э ... это о чем? Если п.2, то возможно ...
Если п.1 , то речь идет о РС и прочая ...
Собственно против такой классификации возражений нет?
Дополнений?
"самое разумное решение "
Э ... это о чем? Если п.2, то возможно ...
Если п.1 , то речь идет о РС и прочая ...
Собственно против такой классификации возражений нет?
Дополнений?
Сделал комментарий, мое сообщение исключительно для geners...
2) Разработка компьютера-эмулятора ZX(современный процессор)
Возможно, как побочный продукт разработки для других целей.
Иначе - выгоднее п.1
ИМХО - промышленные компы на ARMах уже давно напрашиваются на подобную роль (и цена у них наверное даже дешевле чем у самодельного спека будет ;) ).
Собсно концепция использования софтофой эмуляции мне кажется гораздо более перспективным занятием чем вечное изобретательство железяк на которые ещё нужно как то подсаживать народ , и которые стоят не хилых бабок . В случии эмуляциии , так называемое "новое железо" становится достуупным всем и сразу , а главное ничего не стоит .
Кроме того в нете полно всяческих сырков всяческих девайсов на си . И данная платформа вполне могла бы стать мультиэмуляторной платформе вроде GP32 .
"промышленные компы на ARMах " Можно подробнее?
VIA mini-ITX стоит около 160 уе ...
alexfreed
25.05.2006, 13:02
"промышленные компы на ARMах " Можно подробнее?
VIA mini-ITX стоит около 160 уе ...
Многие раутеры делаются на ARMах. У них у всех как минимум 50 мипс скорости, имеется как минимум один 10 base T интерфейс, а то и 100.
Только экран надо приспособить. Задача выполнимая. Стоят они новые порядка $30 и иногда попадаются на помойке :)
Многочисленные АРМы имеют встроенный контролер дисплея.
А еще был такой смешной прибор WebPal. Кому интересно найдете на гугле. Маленький комп для интернета с ТВ вместо монитора. Их пытались
продавать кажется по $300 но фирма вышла из бизнеса. Остатки продавали по $10! У меня их много :)
20 MIPS, VGA, TV (NTSC). Можно подключать FD, HDD, клавиатуру и мыши. На нем хорошо Linux работает. Спорю на рубль, эмулятор ZX тоже хорошо пойдет.
Знаю. Согласен. Но надо применительно к России :)
"продавали по $10! У меня их много " Это намек ..., на массовые поставки? :)
Мда , чёто в раше с промышленными компами на ARMах не очень , даже ценник никто из производителей не ставит...
Придётся самим велосипед изобретать :\ если конечно кто желает остановиться именно на таком варианте .
Мда , чёто в раше с промышленными компами на ARMах не очень , даже ценник никто из производителей не ставит...
Придётся самим велосипед изобретать :\ если конечно кто желает остановиться именно на таком варианте .
Ну в раше они особо и не используется, а сами АРМы продают много кто...
"Многие раутеры делаются на ARMах"
Если кто исследует эту тему ... Я увы пас ...
"Многие раутеры делаются на ARMах"
Если кто исследует эту тему ... Я увы пас ...
Пас роутеры исследовать или с ARMами возиться ? ;)
"роутеры исследовать " У меня их нет, и покупать не буду ...
Редакция 0.1 :)
Варианты разработки "нового ZX железа":
1) РС эмулятор (miniPC разных видов) под корпус ZX
Здесь всё ясно, без комментариев :)
2) Разработка компьютера-эмулятора ZX(современный процессор)
Вероятно, как побочный продукт разработки для других целей.
Иначе - выгоднее п.1
3) "Карманный ZX"
Радикальная минимизация "железа" и потребления.
Плавно переходит в тему "разработка КПК" и эмулятция ...
4) Новая реализация на логике ("клон")
Интерес представляет как "ретро-инженеринг"?
5) Разработка устройств для существующих "клонов"
Да, по п.5 - может, застандартизировать ZX-256k,
как основу написания софта?
Да, по п.5 - может, застандартизировать ZX-256k,
как основу написания софта?
А разве есть такой стандарт? ДЕло в том что все что выше 128 реализовано на каждом клоне по своему...
Речь о том, что одним из способов расширять память до 256к(минимум).
Т.е. закрыть разнообразие 48-128-up - все новые(?) программы не должны
работать на меньшем ... Но если работать, то на всех? клонах ...
Это надумалось из темы про ОСи ... :)
Речь о том, что одним из способов расширять память до 256к(минимум).
Т.е. закрыть разнообразие 48-128-up - все новые(?) программы не должны
работать на меньшем ... Но если работать, то на всех? клонах ...
Это надумалось из темы про ОСи ... :)
Ну тут разные зрения, например Нэмо считал что программное обеспечение не должно лезть выше чем 128К, а в верхняя память предназанчена для электронного диска. Вторая точка зрения это универсальный драйвер памяти (но всегда найдется клон в который этот драйвер не поддерживается). Третье когда есть стандарт на внешний драйвер памяти/оборудования (например как в ИЗДОС), и тогда ПО вообще не знает где оно запускается, а работает через АПИ оси.
Мне кажется создание драйверной прослойки при доступе к
памяти для ZX есть глупость :)
Итак производительность на нуле :)
Но застолбить - минимум 256к, и несколько распространенных
способов доступа - разумно ...
James DiGreze
29.05.2006, 11:51
Но есть ли в этом какой-либо практический смысл?
Если бы 256К имело бы стандартный способ включения, но ведь это не так...
А драйверная прослойка - далеко не глупость. Другое дело, что нет стандарта и на драйверы... (Исключение составляет iS-DOS)
А застолбить минимум 256К никто не мешает. Есть несколько довольно распространенных клонов: Scorpion/KAY, ATM, Profi & Pentagon. Т.о. программе достаточно определить тем или иным способом (даже с помощью ручного выбора) тип клона, и работать с выбранной "моделью" памяти как угодно душе программиста ;)
А тем, кто сидит за виртуальным Спеком вообще по барабану, так как нужную модель можно выбрать из эмулятора.
А чем тогда объяснить "танцы с бубном" вокруг числа тактов между прерываниями? ...
" Scorpion/KAY, ATM, Profi & Pentagon" Ну вот уже список ... :)
А чем тогда объяснить "танцы с бубном" вокруг числа тактов между прерываниями? ...
"Танцы" обьясняются тем что кое какие клоны имееют не соответствующую телевизионному стандарту развертку. В частности "отличился" Пентагон...
" Scorpion/KAY, ATM, Profi & Pentagon" Ну вот уже список ... :)
Не все так просто:
1) У АТМ первой и второй версии разные стандарты работы с верхней памятью;
2) Пентагон вообщето не имеет верхней памяти, т.е. все так называемые "стандарты" это не более чем доработки, известны доработки по АЛКО, совместимый с ПРОФИ, наверняка еще какие нить... Даже пентагон 1024СЛ в зависимости от версии имеет разный доступ к верхней памяти...
3) А как же такие клоны как Кворум, ZX-NEXT...
Кстати забыл такой метод как patch, когда исходник патчится согласно версии компа, ну это очень не гуд.
Всетаки мне кажеться зашивать в прогу переключение страниц плохо, лучше какойто внешний модуль, чтобы пользователь мог подложить свой "драйвер" под свой клон.
"это не более чем доработки"
АТМ-не трогаем :)
Не так много реального железа осталось ...
И интересует только софтовая совместимость.
И речь именно о доработках, т.е. закрыть вопрос "поддержки" 48/128к
"это не более чем доработки"
АТМ-не трогаем
Гы. Тогда может еще Профи и Пентагон за борт. Только KAY/Scorp?
"Гы. Тогда может еще Профи и Пентагон за борт."
Если уже есть 256к, зачем переделывать?
Я таки не нашел "несчетного" числа вариантов расширения памяти ...
(для тех, у кого есть)
Я таки не нашел "несчетного" числа вариантов расширения памяти ...
Для пентагона только!! (это то только на что я натыкался)
256К - b6/b7
512K - b[7:6]
1024 - b[7:5] / b[7:6] + b7(1FFD)
И еще что то там имеется на порту AFF7 но я не сильно помню
И в чем вопрос? 256к - 1 вариант :)
И это вполне логично ...
Был шаг 48к->128к, дальше 128к->256к ...
Для пентагона только!! (это то только на что я натыкался)
256К - b6/b7
512K - b[7:6]
1024 - b[7:5] / b[7:6] + b7(1FFD)
И еще что то там имеется на порту AFF7 но я не сильно помню
А какие проблемы все это поддержать? Делается драйвер памяти который перебирает все возможные варианты (7ffd - b6,b7; 1ffd - b4,b6,b7; #fff7 - b3,b4,b5; #aff7 - b0,b1; #dffd - b0,b1,b2; #fdfd - b0,b1,b2) и если страница существует помечает ее как используемую и заносит в таблицу ее номер. Получим таблицу страниц которые реально существуют независимо от способа их адресации. Плюс переключение страниц через таблицу будет очень быстрой.
Я даже скажу больше, я такой драйвер давно написал. Используется он в Quick Commander'е начиная с версии 2.7 (последний раз я его модифицировал в 2004г для QC 3.04). Занимает всего 330 байт. Также я его отсылал по почте тем кто просил (это Вячеслав Струнов и Sosyura Igor).
И в чем вопрос? 256к - 1 вариант
256 как раз 2 варианта причем для неполной дешифрации более правелен b7
А какие проблемы все это поддержать?
Как раз для драйверов нет никакой проблемы кроме как нежелательность автодетекта на 1Mb для Пентагона можно в 48 режиме очутиться
Так если до 128к - стандарт, то 256к - это несколько вариантов
переключения 1 бита!
Как раз для драйверов нет никакой проблемы кроме как нежелательность автодетекта на 1Mb для Пентагона можно в 48 режиме очутиться
Для этого везде где я видел (и где сам писал) используется удержание shift при детекте памяти. Если shift держим - определяем 1Мб, иначе только 512К.
OFF: я думаю что уже просто глупо писать что либо без универсального менеджера памяти и оринтироваться при этом более чем на 128К
"просто глупо писать что либо без универсального менеджера памяти "
А кому он вообще нужен? Программы 48к не знают про наличие 128к ...
Программы 128к не знают ... Зачем им драйвер управления 1 битом?
James DiGreze
30.05.2006, 05:50
Кхм... Видимо я не вкупаюсь в контекст. :)
Кол-во тактов между INT'ами никак не зависит от модели памяти. Этот параметр уникален для каждого клона, так как схема "пиксельклока" у всех разная (кстати, Скорп в этом узле почти один в один повторяет Л-1). А если учесть "турбирование", то заморачиваться кол-вом тактов я бы не стал, как говорится: "сколько клонов, столько и значений" ;)
Кстати, модель ОЗУ у Scorpion-256 и KAY-256 одинаковая, чего не скажешь про кол-во тактов между INT'ами.
А реально, если не заморачиваться мультиколорами/бордерколорами, то можно брать за точку проверки самый "тормозной" по этому параметру клон, и писать фреймовый движок под него, зная, что если запустят прогу на более "быстром" клоне, то "рвать" изображение не будет.
"Кол-во тактов между INT'ами " Это о том, что скорость процессора не велика :)
"Видимо я не вкупаюсь в контекст"
Смысл о том, что как средство борьбы с "зоопарком" клонов
"принять стандарт ZX-256", а 48/128к считать требующими доработки.
Это соображение из темы про оси ... Там был вопрос о их поддержке ...
И ситуация будет аналогична переходу 48-128 ...
И собственно это весьма теоретический вопрос :)
James DiGreze
30.05.2006, 07:35
А! Ну, если идет контекст про ОС, то могу сказать от себя следующее: мне, допустим нужен калькулятор... Зачем использовать модель 256К, если мне не нужно больше 48К? Как живой пример, дома у меня Цел-600 и 192 РАМы, и мне не нужно пережимать видео, и в игрушки я не играюсь, зачем мне устанавливать ОС, которой минимум необходимо, допустим 512 РАМы? Но здесь есть идеологическая совместимость на уровне запуска приложений, и я не собираюсь себе ставить ХР, подовольствуюсь менее прожорливой 2К. В нашем случае я буду потерян как пользователь новой ОС, если у меня, допустим, 128К РАМы. А это не есть гуд, так как я буду потерян не только как пользователь, но и как потенциальный разработчик новых программ. А заставить меня сделать апгрейд до 256К никто не может. ;)
ЗЫ: Слава Немо, что у меня KAY-1024! :)
Да не про оси речь ... Для большинства программ ничего не надо ...
Программы для 128к не работают на 48к ...
И что, не использовать 128к?
И только для примера.
Например программа печати экрана,... если запущена
прога для 128к, где должна быть размещена?
Соответсвенно "выше" 128к. Т.е. новые функции
требуют новой памяти.
James DiGreze
30.05.2006, 10:49
Я про то, что есть ли смысл для программы размером в 5К из-за потребностей ОС использовать только 256К и выше... Как бы не получился маразм.
А если у тебя программа требует 100К, то, естественно, она не будет работать в 48К.
Это я именно к контексту ОС. Т.е. ОС должна работать в 48К. А если есть прог под эту ОС, требует 100К, то он должен ругнуться на нехватку памяти и благополучно возвернуться в ОС. Зато, если прогу нужно 5К, он благополучно запустится и будет работать.
А класс программ, требующий максимальных объемов "мозгов" вполне определен - программы работы с видео/звуком. Для остальных должен быть выбор - работаем ли в 48К или в 128К или в 256К и более.
И, если честно, т.е. "положа правую руку на Библию", то я ПРОТИВ универсальных "банкомётов". И считаю, что нужно и должно соблюдать модульность, так как неизвестно заранее, с каким железом столкнется программа у конечного пользователя. Т.е. должна быть возможность маневра.
ЗЫ: Имхо, пора этот трёп перенести в раздел про ОС...
James DiGreze
30.05.2006, 11:09
И только для примера.
Например программа печати экрана,...
если запущена прога для 128к, где должна быть размещена?
Соответсвенно "выше" 128к. Т.е. новые функции требуют новой памяти.
А если абстрагироваться от ОС. Тогда вообще не понимаю, зачем, к примеру, печаталке экрана быть размещенной где-либо, помимо отведенного для нее места... Мысль, на самом деле, мне близка и понятна.
Как я написал уже выше, проблема использования памяти выше 128К целиком и полностью находится в ведении программиста, который пишет ту или иную программу. И если ему позарез нужно 256К, почему бы и не использовать такую возможность?
Если вернуться к железу, то получим несколько типов подключения (организации) памяти выше 128К. Вводить какой-либо стандарт сейчас никто не будет. Из реальных производителей мат.плат сейчас остался только CHRV & NedoPC team, остальных на горизонте не наблюдается, и вряд ли будут. А производимое железо вполне удовлетворяет поставленному вопросу, т.е. имеет память более 256К. И, кстати, использование меньшего объема в нынешних условиях просто экономически необосновано, так как, фактически, не влияет на себестоимость.
Вот теперь, я думаю, вопрос можно смело снимать с повестки дня, так как все бараны подсчитаны, убылей нет, волки сыты. ;)
И для тех, кто собирает себе Спектрум самостоятельно: рекомендуется устанавливать ОЗУ объемом не менее 256К с включением по одной из распространенных схем.
ЗЫ: Уф-ф-ф... Аж запыхался пока писал. Надеюсь инцедент исчерпан, и все всё поняли. ;)
2 jdigreze: нифига не понял :) Ну и аллах с ним :)
сорри что встреваю тут. мимо проходил :)
Т.е. ОС должна работать в 48К
гы ;) ну даже в самом страшном сне ограничение снизу - 128к а не 48 :) может еще 16к вспомним или zx80/81 :D
Из реальных производителей мат.плат сейчас остался только CHRV
вот именно, по сроку службы 90% машин 128к уже померли, выпускаются 1024к а юзаются минимум 256к. все остальные крики про 128к - от "емуляторных правозащитников".
Что например, дает даже 256к с "правильной" прошивкой ПЗУ для ОС - как минимум - эмуляцию куцего диска тр-дос с режимом 128к в верхней RAM - для поддержки винта/флеша - первоочередная необходимость для ОС вообще-то.
зы// пошел себе дальше
Вот. Верно сформулировано. А то мне лениво ... :)
Редакция 0.2 :)
Варианты разработки "нового ZX железа":
1) РС эмулятор (miniPC разных видов) под корпус ZX
2,3) Разработка компьютера-эмулятора ZX(современный процессор)
Вероятно, как побочный продукт разработки для других целей.
Минимизация "железа" и потребления.
Иначе - выгоднее п.1
4) Новая реализация на логике ("клон") - "ретро-инженеринг"
5) Устройства для существующих "клонов"
(Расширение памяти до 256к и пр.)
а мне уже становится лениво на форуме лазить...
от лишних слов ничего не меняется.
"от лишних слов " Ну мал-мала польза есть, для себя ес-но :)
К сожалению (или нет? ;)) все подобные разговоры слабо связаны с реальным программированием на спектруме. Мифические ОС никогда не покинут своего раздела форума zx.pk.ru, потому что нежизнеспособны и никому не нужны. Реальный спектрумский программист имеет монопольный доступ как к процессору, так и к памяти. И если ему будет удобнее использовать минимум 256Кб, то он так и будет делать, поскольку никому ничего не должен (все бесплатно) и чтобы не затягивать сроки написания программы (иначе может не хватит терпения и желания довести до конца).
Отсюда вытекает что способ распространения программ в виде исходников, помогает программистам меньше тратить времени на написание собственных аналогов уже существующих процедур, а значит ускоряет написание программ и увелчивает шансы что программа вообще появится на свет. Поэтому если кому-то действительно нужен драйвер для работы с памятью выше 128Кб я охотно поделюсь и помогу с его использованием. Это будет мой скромный вклад в дело написания новых программ.
p.s. Есть замечательный анекдот про сферического коня в вакууме. Не нужно подгонять теорию под практику.
"Поэтому если кому-то действительно нужен драйвер"
Конечно не нужен :)
"все подобные разговоры слабо связаны "
Как сказать ... Для себя я решил, что и почему делать с тем ленинградом,
что у меня :)
Ну и систему координат, для всяких "прожектов" ...
Легко определить "сферического коня в вакууме" :)
"Поэтому если кому-то действительно нужен драйвер"
Конечно не нужен :)
"все подобные разговоры слабо связаны "
Как сказать ... Для себя я решил, что и почему делать с тем ленинградом,
что у меня :)
Ну и систему координат, для всяких "прожектов" ...
Легко определить "сферического коня в вакууме" :)
Господа, с "конями" завязываем... Давайте продуктивно. А то опять какой-то флейм начинается!
Попутно. Хороший корпус для ZX стоит 100-150р ...
Если источник будет за 150р, то весьма приятно ...
Попутно. Хороший корпус для ZX стоит 100-150р ...
Если источник будет за 150р, то весьма приятно ...
ЧТо за корпус, откуда взяты цены?
G1183 Ес-но он не для пентагонов-атмов ... Тока надо брать китайские.
captain cobalt
14.06.2006, 14:08
Мифические ОС никогда не покинут своего раздела форума zx.pk.ru, потому что нежизнеспособны и никому не нужны. Реальный спектрумский программист имеет монопольный доступ как к процессору, так и к памяти. И если ему будет удобнее использовать минимум 256Кб, то он так и будет делать, поскольку никому ничего не должен (все бесплатно) и чтобы не затягивать сроки написания программы (иначе может не хватит терпения и желания довести до конца). Смысл ОС именно в том, чтобы облегчить разработку софта.
Если в ОС есть средства для работы для 256К, то программист может не задумываться как это делать на данной конкретной машине.
Отсюда вытекает что способ распространения программ в виде исходников, помогает программистам меньше тратить времени на написание собственных аналогов уже существующих процедур, а значит ускоряет написание программ и увелчивает шансы что программа вообще появится на свет. Замечательно.
ОС и есть набор полезных процедур.
Если ОС многозадачная, то все программы могут пользоваться одним экземпляром этих процедур, а не тащить каждая свой вариант. Каждая программа будет меньше. Больше программ можно будет одновременно загрузить в память. :)
В процессе жестокой борьбы с ленинградом подумалось ...
А нафига нужен бордюр? Т.е. его биты в порту.
Если экран расширен, то на его месте информация,
а если нет, то можно почистить страницу расширения ...
Закончил таки переделку ленинграда-1, вроде заработало ...
Для 41256-10 без WAIT.
Полностью синхронной схема не вышла, но как концепт - пойдёт :)
Из расширений видео - атрибут на байт, замена бордюра расширенным
экраном ...
В планах - "железный" адаптер РС клавы, порт карточек :)
Уточни плиз про "порт карточек"
Софтовая поддержка? Порты уже выбраны?
"Софтовая поддержка?" сам не сделаешь, никто не сделает ...
Буду сам :)
"Порты уже выбраны?" Нет.
Вот близкая к "синхронной" схема синхронизации :)
Кто-то скачал схемку ...
Её можно в лог.симуляторе покрутить. Для полной синхронности
надо добавить отдельное от RAS управление мультиплексорами.
Но его по простому не получить ...
Из "особенностей" - регенерация по сси.
А так - подогнал под дш z80 и 41256-10.
Расширение экрана решил отложить. А атрибут на байт приделаю,
слишком это легко :)
И вопросы:
Бордюр - насколько он необходим, и если без дем ... ?
Порт расширения - типа 1ffd, но если для дешифрации
использовать только 2 старших адреса (+А1)?
В схемке были ошибки ... Но вроде всё функционирует ...
Работает даже Z80 считавшийся дохлым :)
Далее - прикрутить сом-порт и зашить бутлодырь ...
На к-ой порт вешать (если кому надо)?
Замечание - мультиплексоры 555 не проходят ... Если не добавлять в схему
элементы.
И ещё момент.
У памяти есть время "Row address hold time", для 41256-10 = 15нс мин.
Ставил мультиплексоры 1531 - работает ...
Если кто разбирался в этом вопросе - прошу отписать.
Думаю развести по времени включения из Z состояния - для исключения
токов ч-з открытые мультиплексоры.
Вроде все виды работают - от 555 до 1531 ... парадокс :)
Добиваю загрузчик с СОМ(порт магнитофона).
Софтово выше 38400 трудно, посему так.
Вот ещё вопрос ... Ведь надо читать порт 7ффд.
Иначе как в прерываниях память использовать ...
Вот ещё вопрос ... Ведь надо читать порт 7ффд.
Иначе как в прерываниях память использовать ...
это почему и к чему вообще?
"это почему и к чему вообще?" Это подумалось
о псевдо-многозадачности :)
hint: чтобы не лепить лишние левые порты, просто заведи необходимые сигналы с 7FFD на внешний порт AYка
"порт AYка"
Так и планировал ... Только нет в магазинах его :)
Зайду ещё в те, что пропустил ...
И ещё темка. Загрузка и связь по софт-СОМу ...
Т.е. РС как ZX-сервер :)
Формат, протокол и т.п.
"порт AYка"
Так и планировал ... Только нет в магазинах его :)
Зайду ещё в те, что пропустил ...
Посмотри раздел "каталог " сайта указанного у меня в подписи.
"раздел "каталог " сайта "
Типа заказать? :) Ну даже не знаю ...
Я стараюсь ориентироваться на то, что лежит в магазинах.
Деньги-товар сразу :)
Медленно вперёд ... :)
По ходу дела возник вопрос - как различать, к магн.входу
подключен СОМ или магнитофон?
Предлагаю так:
стабильно 1 - СОМ,
стабильно 0 - маг.,
переходы - не определен? (магнитофон?)
Старым программам будет ровно ...
Не прокатит там конденсатор разделительный стоит специально что бы избавиться от постоянной состовляющей
"там конденсатор разделительный стоит "
И что? Я о логическом определении.
Как там конденсаторы стоят - пофиг ...
Если программа определяет - СОМ, то она может
прямой доступ к файлам на подключенном ус-ве.
James DiGreze
12.09.2006, 18:16
Медленно вперёд ... :)
По ходу дела возник вопрос - как различать, к магн.входу
подключен СОМ или магнитофон?
Предлагаю так:
стабильно 1 - СОМ,
стабильно 0 - маг.,
переходы - не определен? (магнитофон?)
Старым программам будет ровно ...
Нифига не понял... К порту м/ф должен быть подключен м/ф, а СОМ на этом порту ну никак не смотрится. Тем более для нормального СОМа нужен контроллер, типа ZX_MultiCard.
ASDT, объясни в чем суть идеи... ;)
Нифига не понял... К порту м/ф должен быть подключен м/ф, а СОМ на этом порту ну никак не смотрится. Тем более для нормального СОМа нужен контроллер, типа ZX_MultiCard.
ASDT, объясни в чем суть идеи... ;)
Суть в том, что бы использовать имеющийся магнитофонный порт дополнительно в качестве последовательного порта. При этом режим СОМ определяется постоянным наличием единицы на входе, я так думаю всё остальное - не СОМ, а значит магнитофон. Кстати, зачем для СОМ иметь контроллер?
Например, можно доработать "ZX OPEN ROM" (кажется)
для работы с файлами ч-з СОМ.
И входную схему доработать до определения подключения
достаточно просто ....
"Кстати, зачем для СОМ иметь контроллер?"
Скорость поболее, буферизация ...
Но можно и софтово.
James DiGreze
13.09.2006, 04:38
Ну, если исключить использование м/ф вообще, то достаточно подключить к цифровым входу и выходу, например, max232cpe или простенькой схемки на дискретах. А про автодетект забудь, ибо любое подключенное устройство RS232 может тебе дать "0" на входе ;)
Имхо, все же наверно лучше использовать отдельный порт для СОМ...
А вообще, с контроллером не только быстрее, но и надежнее, плюс там используются линии управления протоколом, и программная поддержка гораздо проще.
"подключенное устройство RS232 может тебе дать "0" "
Т.е. оно само что-то даёт ... без твоего участия ...
ИИ наверное ....
"достаточно подключить к цифровым входу и выходу,"
О том и речь ... Но магнитофон никак не ограничен - или-или ...
James DiGreze
13.09.2006, 09:01
ИИ в том, что в этот момент может что-то идти по линии... Это к тому, что мало ли в какой последовательности пользователь будет обращаться к порту. Тем более если хочешь на том же порту посадить м/ф, который тоже может дать невесть что, да и согласовывать их нуно.
И есть еще один подлодный камень - тактовая частота Спека "турбо/не турбо" (я видел еще и мага турбо на 14МГц... Но это уже оффтоп ;)) Т.е. нужно определиться с задержками в программе для каждого режима.
ЗЫ: Вообще-то это вполне реально, правда скорости большой не получишь. У ИНФОРКОМа была книжица "Периферия своими руками", в ней была схемка "ZX Lprint III" (или что-то типа того). Так вот в этой схеме RS232 реализован программно, только сидит не на порту м/ф.
"этот момент может что-то идти по линии... " Заблуждение ... :)
А если воткнуть в сет.розетку, то может сгореть ...
"да и согласовывать их нуно." Пара диодов спасёт ... :)
"реализован программно, только сидит не на порту м/ф."
Смысл в том, что бы делать минимальные доработки,
а остальное - софтово.
Смысл в том, что бы делать минимальные доработки,
а остальное - софтово.В прошивке ZX Spectrum 128 изначально встроены процедуры работы
с софтовым RS232.
L0121 jp L06d8 ; RS232 input
L0124 jp L07ca ; RS232 output (1)
L0127 jp L08a3 ; RS232 output (2)
Максимальная скорость 9600 бод.
Аппаратно RS232 подключается через порт A(регистр 14)
музыкального сопроцессора.
"В прошивке ZX Spectrum 128 изначально встроены процедуры "
Вот типа того ...
"Максимальная скорость 9600 бод."
Можно спокойно до 19200, кажись ...
"через порт A(регистр 14)
музыкального сопроцессора."
Тока он не везде есть, а порт магнитофона - везде.
В прошивке ZX Spectrum 128 изначально встроены процедуры работы
с софтовым RS232.
Код:
L0121 jp L06d8 ; RS232 input
L0124 jp L07ca ; RS232 output (1)
L0127 jp L08a3 ; RS232 output (2)
Эээ , а где сидят процедуры MIDI выхлопа ?
Эээ , а где сидят процедуры MIDI выхлопа ?
L0118 jp L012d ; Keypad scan
L011b jp L0a05 ; Play music strings
L011e jp L11a3 ; Send to MIDI
Даёшь миди секвенсор на спеке !!! :eek:
Кстате, аксакалы, а сколько сериальных портов способен "прокачать" спек, пусть турбированный (7Mhz), на запись при максимальной скорости в 31,250 ? Скажем если это будут сериалы как на мультекарте ? Это видимо в первую очередь вопрос к Caro, как к разработчику данного девайса.
Человечий MIDI интерфейс уже делает один товарищ , но я чёто не могу на его сайт попасть %( Если кто вкурсах что нового на сайте , то дайте плиз знать .
Собсно вот - http://zx.pk.ru/showthread.php?t=3609
Человечий MIDI интерфейс уже делает один товарищ , но я чёто не могу на его сайт попасть %( Если кто вкурсах что нового на сайте , то дайте плиз знать .
Собсно вот - http://zx.pk.ru/showthread.php?t=3609
Нового там особенно ничего нет.
Тут даже вопрос скорее в ПО. А вообще есть готовые MIDI интерфейсы с RS-232, RS-422, LPT портами. Остаётся только поддержать их на спеке. С LPT например MOTU делали, c сериальными - Opcode, Emagic... Мой OpCode Studio 4 (8 in, 8 out) например подключается по двум RS-422, по одному тоже может. А собран он вообще на 6501 что ли, плюс четыре 40-ногие микрухи UART, точно не помню какие. Тот же спек практически по мощностям.
Нового там особенно ничего нет.
Нет нового ? Юморист ;) И это при том что схемы аппаратного UART MIDI так и не существоволо до недавнего времени :v2_lol:
Нет нового ? Юморист ;) И это при том что схемы аппаратного UART MIDI так и не существоволо до недавнего времени :v2_lol:
Это не Midi UART, а просто UART, обычные сериальные порты и им уже много лет. Миди это же и есть сериальное соединение, тот же COM, только на сколько я помню - токовая петля. Да и моему интерфейсу уже более десяти лет. Такой вот девайс: http://k5000.org/gear/Studio4_front.jpg :)
"схемы аппаратного UART MIDI так и не существоволо до недавнего времени "
UART - это UART(железный/софтовый), MIDI - это MIDI (железо, протокол?)
И попутно, может кто ответит ...
Насколько нужен бордюр, т.е. если его не делать - каковы
потери ... Может на примерах ....
И попутно, может кто ответит ...
Насколько нужен бордюр, т.е. если его не делать - каковы
потери ... Может на примерах ....
Я считаю, что на классическом спековском видеорежиме он должен остатся, единственно, что можно его уменьшить в 2-4 раза по толщине с каждой стороны, если это не сложно конечно. Он всё таки в демках иногда задействуется и это история как никак. А на более высоких разрешениях думаю он не нужен.
Это не Midi UART, а просто UART, обычные сериальные порты и им уже много лет. Миди это же и есть сериальное соединение, тот же COM, только на сколько я помню - токовая петля.
UART MIDI есть не просто UART , а UART передающий данные по мидишному протоколу . Тот товарищь делает именно мидишный интерфейс , а не что то иное (к томуже он использует однокристалку, а не отдельный чип).
James DiGreze
14.09.2006, 07:01
Насколько нужен бордюр, т.е. если его не делать - каковыпотери ... Может на примерах ....
Имхо, нужен. Пример: загрузка с магнитофона... ;)
Я считаю, что на классическом спековском видеорежиме он должен остатся, единственно, что можно его уменьшить в 2-4 раза по толщине с каждой стороны, если это не сложно конечно.
Верхний и нижний убрать вообще проблематично.
А боковые можно, но за счет потери квадратных точек. Т.е. можно сделать точки как черточки, но, думаю, это никого не устроит.
P.S. UART (Universal Asyncronus Receiver Transmiter) - отдельный чип или часть МК, т.е. преобразователь данных "параллельные<->последовательные", а протокол называется RS232C. MIDI - это стандарт подключения муз.инструментов к компутеру. Включает в себя описание как аппаратной части, так и протокола взаимодействия.
По бордюру:
Просто переделывая ленинград, дошел до портов ...
И совсем не хочется делать "ненужную часть" порта ФЕ :)
Область бордюра будет заполнена с доп страниц (свыше 128к).
СОМ:
Сейчас у меня зашит простой загрузчик по СОМ, программу
"подготовки" данных добить и можно отлаживать софт на железе.
Поэтому интересует вопрос с протоколом прямого доступа
к файлам ... Я могу и сам придумать, но если есть готовые решения ...
UART MIDI есть не просто UART , а UART передающий данные по мидишному протоколу . Тот товарищь делает именно мидишный интерфейс , а не что то иное (к томуже он использует однокристалку, а не отдельный чип).
Это СОВЕРШЕННО ОБЫЧНЫЙ UART. И ему всё равно, что передавать/принимать, MIDI-сообщения, с модемом работать или с мышкой. Все отличия миди-интерфейса только электрические и закличаются в соединении по токовой петле. Миди-интерфейс под COM-порт - это пара микрух рассыпухи.
Это СОВЕРШЕННО ОБЫЧНЫЙ UART. И ему всё равно, что передавать/принимать, MIDI-сообщения, с модемом работать или с мышкой. Все отличия миди-интерфейса только электрические и закличаются в соединении по токовой петле. Миди-интерфейс под COM-порт - это пара микрух рассыпухи.
Я уже не понимаю с чего спор пошёл %) Поэтому по пунктам -
На спеке никогда небыло "открытого" аппаратного UART , и темболее UART MIDI (Засекреченные и почившие в бозе вместе с софтом схемы не в счет).
То что к спеку пожно подоткнуть любую микруху , вовсе не значит что это уже было (с тем же успехем можно утверждать о подключении любого железа). Я уже не говорю о туевой хучи разновидностей UART чипов и способов инициализации и и управлении ими (в выборе чипа так некто и не захотел принимать участие , хотя из реально доставаемых он и так всего один + таймер).
Может обычный UART и можно заставить работать с чем угодно , но речь шла о конкретной реализации MIDI интерфейса выше упомянутым товаририщем . (Если у кого есть желание предложить свою конкретную рализацию MIDI интерфейса и писать под неё софт , то флаг в руки ;) , пока я вижу только одного :\ ).
Короче - спор вызван филосовским вопросом "теоритические и практические реализации" %) Практических небыло/почили в бозе , а теоритических я в данном случии не принимаю , ибо давно всё говорят , а до дела только сейчас дошло :( .
" рализацию MIDI интерфейса и писать под неё софт"
Т.е. главное не реализация, софт под неё ... Всё верно. :)
Т.е. главное не реализация, софт под неё ... Всё верно.
Не будет стандартизированого железа , не будет софта :D Именно поэтому я настаиваю прежде всего на конкретной практической реализации , а не теоритической ;)
"прежде всего на конкретной практической реализации "
Поддерживаю! Как только будет реализация - будет "стандарт"
Вообщем так:
На плате Caro есть сериальный порт ? Есть. Можно увеличить их количество до четырёх ? Явно можно. Потянет ли спек 4-е потока по 32.250 ? Не знаю, надеюсь на ответ. Можно ли дать этим портам электрическую совместимость с MIDI ? Даже не вопрос, таких схем полно и они примитивные. Вывод: если у спека хватит быстродействия, а я подозреваю, что хватит, то дело остаётся за софтом и будет обычный секвенсор. Разве это не рулез ? :) Путь он даже будет в трекерном виде.
Далее ещё интерестнее. Так как уже существуют промышленные миди-интерфейсы с подключением по сериальным и параллельным портам, то опять же дело остаётся за софтовой поддержкой.
Вот собственно и вся идея.
На плате Caro есть сериальный порт ?
Там уже "залоченная" однокристалка , и на мидишный протокол можно "переключиться" только путём изменения прошивки (сырков которой кстати нету).
Потянет ли спек 4-е потока по 32.250 ? Не знаю, надеюсь на ответ
калькулятор потерялся наверно :) 32250 бит/с * 4 = 129000 бит/с = 16125 байт/с
3500000 / 16125 = 217 тактов/байт... ну типа потянет еще и не столько :)
Там уже "залоченная" однокристалка , и на мидишный протокол можно "переключиться" только путём изменения прошивки (сырков которой кстати нету).
ух, не читал многапаследнихбукф. я не понял, в чем проблема железная - четыре сериал порта что ли ??? ну сделайте свой_отдельный_крутой_конт� �оллер
зы// а чего не сделать внешний разчетверитель сериал порта. Камилевский контроллер вроде должен 115200 держать - каждому по 28800 достанеца. можно в этот разчетвиритель и всякие мидишные протоколы вшить, а в Спек он будет лить уже понятный только софтине поток (ну самим придумать какой).
Раз уж так ... Про бордюр ещё мнение отпишите ... :)
Раз уж так ... Про бордюр ещё мнение отпишите ...
Это ты не подумавши сказал
Раз уж так ... Про бордюр ещё мнение отпишите ...
ИМХО нужен .
"ИМХО нужен "
Если можно с примером. Т.е. такая прога ....
Если можно с примером. Т.е. такая прога ....
Любая какая только может грузиться с патефона (точнее с любого аудио носителя) , ибо без бордюра трудно будет понять что происходит ;) (особенно когда юзаешь турбо загрузчики x4 ;) ).
Там уже "залоченная" однокристалка , и на мидишный протокол можно "переключиться" только путём изменения прошивки (сырков которой кстати нету).
Мидишный протокол к железу не какого отношения не имеет. Ничего там перепрошивать не надо. Тут только софт нужен.
зы// а чего не сделать внешний разчетверитель сериал порта. Камилевский контроллер вроде должен 115200 держать - каждому по 28800 достанеца. можно в этот разчетвиритель и всякие мидишные протоколы вшить, а в Спек он будет лить уже понятный только софтине поток (ну самим придумать какой).
Вполне разумно. Такой вариант давно уже применяют. Собственно это и есть сериальный миди-интерфейс, как у меня стоит. Единственно, что у меня по двум сериалам на восемь входов и восемь выходов с балансировкой траффика этих двух сериальных потоков. Хотя и на одном сериале тоже работает.
Мидишный протокол к железу не какого отношения не имеет.
Ну да , а скорость передачи сама какнить выстатся :v2_lol:
Ну да , а скорость передачи сама какнить выстатся :v2_lol:
Ну драсте... Как софтина скажет, так будет. Не на амиге, не на писюке порты изначально на миди не кто не расчитывал, однако впослетствии такие вот сериальные миди-коннекты нормально работали на штатных контроллерах.
Как софтина скажет, так будет.
Сэр , вы однако юморист :D У нас (т.е. на мультикарте by Caro) намертво залоченная однокристалка (сменить скорость можно только после изменения прошивки), а не отдельный UART чип которым можно вертеть как угодно .
Southern Bear
16.09.2006, 20:54
сменить скорость можно только после изменения прошивки
Очень сильно сомневаюсь. (#F8EF & #F9EF)
Сэр , вы однако юморист :D У нас (т.е. на мультикарте by Caro) намертво залоченная однокристалка (сменить скорость можно только после изменения прошивки), а не отдельный UART чип которым можно вертеть как угодно .Чип конечно не отдельный, но UARTом можно вертеть как угодно :)
В ZXMC эмулируется подключение к Спектруму
ISA-модема по схеме Кондратьева. Базовый
адрес портов модема со стороны Спектрума = F8EFh.
Скорость работы RS232 устанавливается точно
также, как и в IBM-ке установкой коэффициента
деления (КД) по такой схеме:
КД ---- Скорость
1 ------ 115200
2 ------ 57600
3 ------ 38400
4 ------ 28800
6 ------ 19200
12 ----- 9600
24 ----- 4800
48 ----- 2400
96 ----- 1200
192 ---- 600
и т.д.
Для установка скорости:
1) 7-ой бит порта FBEFh устанавливается в 1 (DLAB=1);
2) В порт F8EFh записывается младший байт КД;
3) в порт F9EFh записывается старший байт КД;
4) бит DLAB сбрасывается в 0.
SER_P equ 0F8EFh
; 1) задать скорость = 19200 бод
ld bc,SER_P+3*100h
ld a,80h ;DLAB=1
out (c),a ;(FBEFh)=80h
ld b,SER_P/100h+1
xor a
out (c),a ;(F9EFh)=00h
dec b
ld a,6 ;Divisor=6(19200)
; 12(9600)
; 24(4800)
; 48(2400)
out (c), a ;(F8EFh)=06h
ld b, SER_P/100h+3
ld a, 0 ;DLAB=0
out (c), a ;(FBEFh)=0
Чип конечно не отдельный, но UARTом можно вертеть как угодно
Здорово :) Не знал %(
Отсюда вопрос - какой либо подобный юзвер мануал ранее на форуме выкладывался ? (Что то я этого не помню/не видел %((( )
Southern Bear
16.09.2006, 23:01
http://www.zx.pk.ru/showpost.php?p=45673&postcount=130
Ё... Я то думал это посто описание стандарта RS232 как такового %(
Southern Bear
17.09.2006, 00:17
В общем то так оно и есть. Если не смотреть на адреса.
А получается это по тому, что по схеме Кондратьева, подключался интернальный мопед (не вин-обрезок) который со стороны ISA и выглядел как COM-порт c подключенным мопедом. По этому и программирование очень похоже. Из отличий ПЦшного программирования, по большому счёту, только адреса и прерывания (их отсутствие).
И опять ...
Теперь насчет бита 5 7ffd.
Чем грозит его отсутствие?
Сэр , вы однако юморист :D У нас (т.е. на мультикарте by Caro) намертво залоченная однокристалка (сменить скорость можно только после изменения прошивки), а не отдельный UART чип которым можно вертеть как угодно .
Ну вот Caro расставил все точки. Ну кто юморист ? :v2_tong2: :v2_devil:
И опять ...
Теперь насчет бита 5 7ffd.
Чем грозит его отсутствие?
Нужен . Но инфу чем грозит его отсутствие найти не смог .
А чё такая дикая экономия :v2_eek: не ужто несчастного вентеля жалко ;)
Ну вот Caro расставил все точки. Ну кто юморист ?
Ага... А чтоб на мидишный протокол зарулить мне нужно ещё и кварц перетыкнуть... а потом обратно... :v2_lol:
"Но инфу чем грозит его отсутствие найти не смог "
Аналогично.
"не ужто несчастного вентеля жалко"
Не то слово ... :)
"и кварц перетыкнуть... а потом обратно..."
Я так делал - ставил панельку, работало нормально.
Ага... А чтоб на мидишный протокол зарулить мне нужно ещё и кварц перетыкнуть... а потом обратно...
я уже советовал вынести весь этот протокол нах во внешний контроллер - тогда девайс получится и более универсальным (пц/амига/спек) и вообще нехрен лезть без повода с паяльником куда не надо :) кому не хватает скорости - берем у caro USB контроллер, учимся программить usb, и делаем этот самый контроллер на usb :D
... А чтоб на мидишный протокол зарулить мне нужно ещё и кварц перетыкнуть... а потом обратно... :v2_lol:Протокол MIDI предусматривает скорость обмена 31250 бод +-1%.
При тактовой частоте 11.0592 МГц, на которой сейчас работает ZXMC
можно установить скорость работы RS232 = 31418 бод, что на 0.5 % больше,
но укладывается в допуск.
Протокол MIDI предусматривает скорость обмена 31250 бод +-1%.
При тактовой частоте 11.0592 МГц, на которой сейчас работает ZXMC
можно установить скорость работы RS232 = 31418 бод, что на 0.5 % больше,
но укладывается в допуск.
Ну вообщем мидя не обидится. :)
Поправочка. Софтово - 38400.
Заменил ботлодырь на программку типа "монитор",
можно теперь ручками порты "щупать" :)
И 256к приделал ...
Дальше - расширение экрана. Атритут на байт и замена бордюра.
Грех не использовать весь экран при таком количестве
"лишней" памяти ...
Если кто может поделиться соображениями - отпишите!
СОМ-порт ... 38400 - работает нормально, надо делать связь с рс ...
И далее - по плану ...
По связи с РС.
По идеологии "сервер" на РС не подходит...
Т.е. связь нужна только для "разовой" пересылки данных.
А соответственно для этого оптимально использовать
отдельную "загружаемую" программу.
Расширение до 256к - бит 5 порта 7ffd(и чтение), это логично ...
Видео расширения.
Атрибут на байт - используются 2-е 8к страниц (проще уж куда ...)
Расширение экрана - 3(6) доп. страниц (вертикальное, горизонтальное,
углы) Тоже просто делается ...
Порт расширения видео - 3ffd(и чтение)
Пока надо попробовать софтовый SPI (на AT45DB081B),
только какой порт применить ... fe?
Докладаю! :)
1) Загрузчик спека с РС - работает, ЕЕР-память заливает
2) Расширение до 256к - бит 5 порта 7ffd(и чтение). Порт можно
считать - изменить - записать
3) Атрибут на байт - используются 2-е 8к страниц ... Делать всем!!!
4) Расширение экрана - 3/6 доп. страниц (вертикальное, горизонтальное,
углы и два раза) ... Приятно.
5) Порт расширения видео - 3ffd(и чтение) Порт можно
считать - изменить - записать
Полное тестирование пока не делал ... А надо? :)
Но атрибут на байт - рулит 100%, сразу вспомнил "цивилизацию" на РС ...
Если кому надо ... Схемки выкладывать? Или не засорять ...?
3) Атрибут на байт - используются 2-е 8к страниц ... Делать всем!!!
Но атрибут на байт - рулит 100%, сразу вспомнил "цивилизацию" на РС ...
Если не сикрет - чем рулит атрибут на байт %) ?
Если кому надо ... Схемки выкладывать? Или не засорять ...?
Создай сайт ! (хоть на тормозном народе , ибо можно по пол года не апдейтить)
"Если не сикрет - чем рулит атрибут на байт %) ?" :)
Можно между линиями делать не монотонный фон, а чередуя
разные цвета - типа "штриховка" ... или как назвать ...
Просто сравнив возможности со стандартными - не откажусь уже точно!
Таки тиснул схемку ... Просто для примера.
Логику можно на переключатель заменить, но делов ...
Да просто нефиг делать!
Да, ещё. на софтовый spi забил - надо делать железный.
Кого интересует?
James DiGreze
22.11.2006, 18:44
Железный SPI есть в мультикарте by Caro. Спроси как у него сделано, чтобы не плодить еще один стандарт. Пусть будут по портам совместимы. ;)
Хотя, вроде бы как SPI там в порты не смотрит, но решается это прошивкой.
Вообще, этот протокольчик весчь нужная, ибо позволяет довольно просто реализовать поддержку SD/MMC flash.
"Железный SPI есть в мультикарте by Caro. "
Это микроконтроллерный, я за чистый "железный" :)
Только логика. Думал про интерфейс-1 ...
Вот интересное решение
/ message
attachments
Миниатюры
*
У меня что-то в роде этого, ток запихано в мини башню.
"У меня что-то в роде этого, ток запихано в мини башню"
Это чего? :)
Вот ещё вопрос - правильный сброс для спека ...
Вопрос по сбросу формулируется так:
Нужен ли сброс по снижению питания (4,75в),
т.к. возможно использование различных карточек ...
Т.е. для защиты от процессора ...
James DiGreze
23.11.2006, 20:03
Это микроконтроллерный, я за чистый "железный"
Только логика. Думал про интерфейс-1 ...
Чистый "железный" дороже выйдет, проще на lpt подвесить tiny2313 или около того - щасте за 50рэ. ;)
Про if-1 не понял... :(
"Чистый "железный" дороже выйдет" - не факт, но зато можно
всё "потрогать руками"
"проще на lpt подвесить tiny2313 " - Для зашить? Это да.
"Про if-1 не понял... " Ну а как на спеке карточку читать\писать?
Нужен порт ...
Вопрос по сбросу решил.
Трехногий супервизор с делителем - самое простое и дешовое ...
Вопрос по сбросу решил.
Трехногий супервизор с делителем - самое простое и дешовое ...А делитель то зачем?
КР1171СП42 - супервизор в корпусе ТО92 на 4.2 вольта.
КР1171СП47 - супервизор в корпусе ТО92 на 4.7 вольта.
Цена порядка 5 р.
Ну а как на спеке карточку читать\писать?
Нужен порт ...А чем тебя LPT порт не устраивает или порты в AY?
OrionSoft уже экспериментирует с SPI, управляя битами портов Музпроцессора:
http://zx.pk.ru/showthread.php?t=4221
"А делитель то зачем?"
Точная подстройка на 4.75* и кнопка сброса - т.е. никаких конденсаторов.
Или что?
"А чем тебя LPT порт не устраивает или порты в AY?"
Это софтовый SPI ... Скорость никакая ... Нафик.
Нужно работать с максимальной для процессора скоростью.
Точная подстройка на 4.75* и кнопка сброса - т.е. никаких конденсаторов.
Или что?Откуда такое точное значение?
Чем не устраивает 4.7 В?
И почему ты так настроен против конденсаторов?
Неужели слишком дорогие :)
Это софтовый SPI ... Скорость никакая ... Нафик.
Нужно работать с максимальной для процессора скоростью.Зато очень дешево и "потрогать руками" можно :)
"Откуда такое точное значение?
Чем не устраивает 4.7 В?"
Дык ... Что было, то и приделал ...
А было на 4.5
"И почему ты так настроен против конденсаторов?"
Он у меня стоял на сбросе - полная фигня это ...
А сейчас и по питанию сброс и по ресету.
"Зато очень дешево и "потрогать руками" можно "
Так и в железе и дешево и можно потрогать, даже паяльником :)
Вот вопрос ... разместить SPI и часы на интерфейсе-1 ...
Может часы другим макаром приделать ...
В смысле - на портах Интерфейса-1? Осторожней - учти что TR-DOS при первом старте засылает 0 в кажется #EF - см. дизассемблер. Так наличие интерфейса-1 проверяется.
Вообще я тут думал об I2C и решил задействовать под него параллельный порт ZX-Lprint. Соединяем одну из линий данных порта с BUSY - это будет Data. Еще одна линия данных - Clock. У меня от Амиги остался термометр на Далласе - на улице под подоконником болтался и в окошке на Workbench температуру показывал. Сначала думал его на Пегас перецепить, ну да на ZX ведь круче. :cool:
"Осторожней - учти что TR-DOS при первом старте "
Его тоже переделывать ...
"Вообще я тут думал об I2C "
SPI - для карт ... Нужна скорость.
Пока так: данные часов - F7, данные SPI - EF
Ну вот и финал ... :)
Минимализм победил.
Порты на плате:
#xxFE - чтение по стандарту,
запись - гудок и магнитофон (магнитофон совмещен с RS-232*)
#7FFD - отличия по записи:
1) бит 4 - ROM0=TRDOS* 2) бит 5 - расширение 256к (3-я страница озу),
чтение - состояние порта
#3FFD - доп. расширения - отключение ROM, альтернативные страницы озу (0-2),
байт на атрибут, второй расширенный экран, 2 цвета на байт*
Чтение и запись.
Все остальные ус-ва (картовод, звук, часы, клав.и мышка, принтер и пр.) -
через блок расшиения (концепт :) )
Дальнейшие железные изменения остановлены,
пора переходить на софт ...
"В "Spectrum 128 +3" это порт регистра данных дисковода"
И зачем мне +3????
Black_Cat
05.12.2006, 18:46
"В "Spectrum 128 +3" это порт регистра данных дисковода"
И зачем мне +3????По логике получается и ни за чем, т.к. в xUSSR ZX-платформе используется TR_DOS. Ихний софт, работающий с их дисковыми системами и так у нас работать без переделки не будет, а как будет работать наш софт у них - это больше их проблема.
Вот надумал ... :)
Не нашел другой темы, куда записать ...
Добавлено через 44 секунды
Что сейчас можно сделать полезного для спека?
(как обоснование личного плана работ) :)
Что есть спек сегодня? - Ретрокомпьютер. В своё время он получил
широкое распространение из-за возможности быть собранным
в "домашних" условиях на нашей элементной базе и мощного потока
"цельнотянутого" софта. В настоящем он не может конкурировать
с современными микроконтроллерами ни в одной из практических
областей применения. Не говоря о компьютерах и игровых приставках ...
Однако есть и плюсы. Это возможность прямого (хоть паяльником :) )
доступа к архитектуре и доступность всего софта ч-з интернет, плюс
спек остается и "игровой приставкой"...
Из такой оценки можно ввести некоторые "ограничения разработчика":
1) Частота ЦПУ - 3.5(7) МГц. Выше нет смысла - софта требующего
более быстрый процессор нет, или им можно пренебречь.
А значительный рост частот шин повышает требования
к качеству сборки, что недопустимо ...
2) Применение современных плис и микроконтроллеров в качестве цп
неприемлемо в ретрокомпьютере. Для любителей "новизны" есть
эмуляторы ...
3) Конструктив должен оставаться традиционным. Не превышающим
"размер оригинала"... И обеспечивающим "узнаваемость" спека ...
4) Любое "новое железо" требует софтовой поддержки, которая в текущей
ситуации не может быть осуществлена ...
На этих основаниях можно считать разработку "нового железа" для
спека бессмысленной. Главным становится поддержка и модернизация.
И если спек с контроллером дисковода сегодня ещё может быть пригоден
для использования, то без него - уже нет... А это означает - путь на свалку.
Решение этого вопроса уже предлагалось - "магнитофон для спека",
но полным решением может стать "TAPE-BUS", т.е. интерфейс
позволяющий подключать к спеку внешние накопители и поддерживающий
работу с файлами (загрузку, запись, просмотр каталога и т.п.)
Минимальная доработка спека будет состоять в смене прошивки и
распайке переходника на СОМ-порт (если РС, как внешний накопитель).
Такая доработка может дать "второе дыхание" любому спеку ...
Вот надумал ... :)
Не нашел другой темы, куда записать ...
Добавлено через 44 секунды
................На этих основаниях можно считать разработку "нового железа" для
спека бессмысленной.
...................
Нужен универсальный контроллер карточек SD понимающий FAT32 для того чтобы можно было безболезненно в картридере на Писи записать ТРД или же СЦЛ файлов и безпроблемное их прочтенее на спеке,с последуещим записью на винчестер спека,работаюсщим в ТРДос среде.
Вот такой вот девайс нужен точно.
Причем унифицированый.
Для всех клонов
"Нужен универсальный контроллер карточек SD понимающий FAT32 "
Сперва надо интерфейс в прошивку встроить,
иначе - пустое ...
"Нужен универсальный контроллер карточек SD понимающий FAT32 "
Сперва надо интерфейс в прошивку встроить,
иначе - пустое ...
Нах?
Софтово решить проблему.
Научились же сиди диски читать.
"Научились же сиди диски читать."
Наверно есть разница, когда поддержка встроена?
"Научились же сиди диски читать."
Наверно есть разница, когда поддержка встроена?
Безусловно!:biggrin:
но написать прогу ( читай драйвер ) - думаю всяко проще,чем переписать тырдос.:v2_wink: :v2_wink2:
"но написать прогу ( читай драйвер ) - думаю всяко проще,чем переписать тырдос."
Но второе - это качественно новый уровень,
что и есть развитие спека ...
"но написать прогу ( читай драйвер ) - думаю всяко проще,чем переписать тырдос."
Но второе - это качественно новый уровень,
что и есть развитие спека ...
несогласен....:v2_wink2:
но давай закончим
ато уже флеймом попахивет....:v2_blush: :v2_wink2:
У буржуинов туча всяких девайсов под +3 (включая SD/MMC), и туча прошивок для их супорта .
На MSX аналогично .
У нас похоже нет такой реальной востребовательности SD/MMC раз программёры не хотят вклинивать их супорт(через аппаратный SPI) вместо HD .
Сам аппаратный SPI можно реализовать на мультикарте (caro вроде планировал это сделать). Или вот такой шаманский вариант http://zx.pk.ru/showthread.php?t=3957&page=13&pp=10 контроллер клавиатуры и магнитофон в одном флаконе . В одном из режимов контроллер впринципе можно заставить работать как аппаратный SPI (если не нужно грузить ленточные файлы). Вобщем достаточно универсально пулучается .
Да всё не о том ...
Смысл в добавлении поддержки интерфейса
накопителя в прошивку спека!
Т.е. доработки программ не будет,
и минимальные переделки железа.
Любой древний клон сможет работать напрямую
с файлами ...
Сам аппаратный SPI можно реализовать на мультикарте (caro вроде планировал это сделать).Он там изначально реализован.
Дело в том, как его теперь программно использовать.
Он там изначально реализован.
Дело в том, как его теперь программно использовать.сколько там свободной програмной памяти? можно прикрутить http://elm-chan.org/fsw/ff/00index_e.html и грузить с фата .z80, .sna, а если взять исходники из соседней темы (спек и магнитофон), то и .tap и .tzx.
Надо за стандартную прошивку браться ...
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot