SIMM30 у меня не заработали на варианте "128.3". Регенерировались лишь частично...
Вид для печати
SIMM30 у меня не заработали на варианте "128.3". Регенерировались лишь частично...
Но Владимир то пишет что у него работает, вот и надо схему посмотреть. У Павла Рябцева стоят СИММы в Орионе под УКНЦ, но не уверен тоже в рабочести той схемы, да и в выложенных им схемах ничего не разглядеть и не разобраться :(Цитата:
Сообщение от aviator
Как я выяснил, использовались микросхемы памяти с 2-мя схемами регенерации. У меня есть модули на 1 Мб и на 4 Мб, причём с одинаковыми микросхемами. Различается только количество. А есть модули объёмом до 1 Мб включительно, с более старыми микросхемами. Видимо они и работают. Но у меня их не было, чтобы проверить.Цитата:
Сообщение от gdv2002
У меня как раз несколько штук по 256кб :)
Естественно, что для SIMM 256 кб, как и для РУ7-мых, чтобы была регенерация всего объёма, а не только 64К в банках 0 и 1, надо переставить один адрес (а вот в СПЕЦИАЛИСТЕ приходится переставлять 2 адреса, т.к там исходно регенерация 7-ми битовая).
Надо чтобы по /RAS шли самые высокочастотные адреса видеогенератора, а в ОРИОНЕ это сигналы H0...H5,V0,V1. После добавления нового мультиплексора на 9-й адресный вход РУ7-мых, туда надо заводить следующий по высокочастотности сигнал, а это V2 (52 цепь). Для этого эта 52 цепь отрезается от D23/4 и подаётся на дополнительный мультиплексор на ногу 3, а соответствующий адрес CPU (A2) цепь 12 идёт на ногу 5. А на место отрезанной от D23/4 цепи 52 подаём сигнал B1 (для РУ7 это A17). Также необходимо отрезать вход D29/3 и подать туда 1.
Это уже всё "проходили" в 1992 году, когда делали расширение ОЗУ на РУ7-мых. Думаю тут таких схем выложено полно (вариаций много), и естественно, можно посмотреть, как 512К сделано в схеме rev.512. В 1999 году в каталоге В.Пушкова была схема расширения ОЗУ на 512К на двух банках РУ7-мых.
Какой вектор регенерации, столько ОЗУ и регенерируется. Для 256-ти килобайтовых 9-ти битовый адрес и такой же должен быть вектор регенерации. А у одно-мегабайтовых уже 10 адресов и нужен 10-ти байтовый вектор регенерации. Если ОЗУ 1 мб включить как РУ7 или SIMM 256K, то и будут регенерированы только 256К из 1 мб. Для них нужно переставлять уже два наиболее высокочастотных адреса видеогенератора (и соответствующие им адреса процессора). А у 4-х мегабайтовых SIMM 11 адресов. Для них надо не только переставлять 3 адреса, но придётся добавить ещё один мультиплексор. Зато ОЗУ получится аж 8 мб.Цитата:
Сообщение от aviator
Не вижу проблемы при больших SIMM. Сколько адресов не лениво переставлять, столько ОЗУ и будет. Если сил хватает только на перестановку одного адреса, то в каждой планке SIMM на 1 или 4 мб можно будет использовать только 256К (остальные не будут регенерироваться). А если переставить 2 адреса, то и целый мегабайт будет регенерирован.
Чтобы не разориться на установке дополнительного мультиплексора можно 4-х мегабайтовые SIMM использовать с 10-ти бАйтовым вектором регенерации, отчего будет не 8 мб, а только 2 мб. Но по-моему этого достаточно, т.к уже при 2 мб и 32 банках не хватает латинских букв для названий квазидисков ORDOS, так что вообще лучше ограничиться 26-ю квазидисками по числу латинских букв.
Добрый день!
Поясняю по поводу SIMM-ов.
Устанавливал я их по следующей схеме:
Вложение 61027
Схему купил когда-то на барахолке в Кемерово, была там группа любителей Ориона, их разработка.
Карандашные пометки уже мои.
В результате получилось пять страниц(0,1,2,3,4), четвертую VC$, конечно, не видит, но из ORDOSа доступна.
Плашки памяти перепробовал большую кучу и 256 и 1 мБт. Они разделились на три кучки:
Первая прикинулась полностью мертвой.
У второй тест показывал 2-3 бита неисправные.
Заработали вот такие
barsik, вот частичная регенерация и не получалась с этим ОЗУ. А, так как было достаточное количество РУ5, то и сделал 256 кБ и не стал ковырять дальше...
- - - Добавлено - - -
VladimirS, у меня модули с 2-3 микросхемами:
эти я пробовал, не заработали:
2 S514400J-07 (1Mx4 FPM, 70 ns) + 1 81C1000A-70 (1Mx1 FPM, 70 ns)
2 VC51440AJ-6 (1Mx4 FPM, 60 ns) + 1 BJ41C1000-6 (1Mx1 FPM, 60 ns)
2 424400-70 (1Mx4 FPM, 70 ns) + 1 V53C100FK70 (1Mx1 FPM, 70 ns)
а эти у меня появились в результате раскопок гаража, месяц назад:
2 81C4256A-70 (256Kx4 FPM, 70 ns) + 1 HM51256P-8 (256Kx1 FPM, 80 ns)
2 D424256V-70 (256Kx4 FPM, 70 ns) + 1 TC51256Z-70 (256Kx1 FPM, 70 ns)
Вот последние имеют шансы заработать... Но надо разорять уже рабочую машину, либо делать новую.
У меня есть только с чипами 81C4256 - не заработала.
Работают только с девятью мелкими чипами (256 кБт).
То есть, без чётности? Чётность просто остаётся висеть в воздухе, микросхема не используется.Цитата:
Сообщение от VladimirS
А что выводилось на экран? Тест ОЗУ пробовали запускать? Что показывает?
Микросхема четности не используется, это ж девятый бит.
Что показывает тест уже не помню, давно было, отсортировал и сложил многое куда-то.
Посмотрел на Авито, есть продают девяти чиповые, но крупные корпуса - эти я не пробовал (перефразировал Жванецкого - крупные, но сегодня)
У меня было видно, что компьютер шевелится, на экран выводится осмысленная информация, в том числе при тесте ОЗУ. Но, с каждым циклом регенерации память портится, и через несколько секунд - зависание. Это на уже отлаженной плате так было, которая заведомо работала без сбоев с РУ5.
Всё. :) Я программист, на железки с программной точки зрения смотрю, а не с точки зрения сигналов.Цитата:
Сообщение от barsik
Поэтому интересно не как физически устроены разные схемы, а в какие моменты времени тормозит процессор в этой схеме.
А с программистской точки зрения вообще "до лампочки" как работает схема. Для потактового расчёта времянок не важно положение маш.тактов WAIT в машинном цикле команды, а важно только число добавленных тактов WAIT. И это Вы как раз в схеме с WAIT не узнаете. Потому что время прохождения теста зависит от программы самого теста. А о чём это говорит?Цитата:
Сообщение от uart
В итоге, в схеме с WAIT замучаетесь считавши... Заранее нельзя сказать, что вот эта подпрограмма будет работать ровно в 1.41 раза быстрее, ускорение может быть и в 1.35 и 1.50 раза. Для потактовых расчётов придётся забыть стандартные таблицы и составлять новые. Чтобы узнать времянки придётся делать тесты и вычислять число маш.тактов каждой команды.
Гораздо лучше использовать ТУРБО-200%, где все программы ускоряются одинаково, ровно на 200%. Но т.к ОЗУ РУ5 без вентилятора перегреваются в этой схеме, то разумно её делать одновременно с заменой кварца на 9 или 8 МГЦ. Результат получается отличный. Не только качество шрифта улучшается на 25%, экран отплющивается, но и ОЗУ работает без вентилятора (РУ7 вообще чуть тёпленькие, а SIMM, наверно, вообще ледяные).
Чтобы сохранить стандарт TV-сигнала, при кварце 9 МГЦ коэфициент деления счётчика строк меняется с 80-ти до 72-х. А при 8 МГЦ надо делить на 64 (как в СПЕЦИАЛИСТЕ). При пиксель-клоке в 8.25 МГЦ - коэффициент 66. Всё это делается перекидыванием только одного проводка на входе D8/1 и иным формированием ССИ (чтобы отцентровать растр по горизонтали). Если для изменений в формирователе ССИ не хочется резать цепи на входах D14.1 или желательно иметь аналоговую точную юстировку, то достаточно добавить один ТМ2 по схеме, что во вложении.
Если оставить кварц 10 МГЦ, то для достижения максимальной надёжности без использования вентилятора, придётся собирать довольно громоздкую схемку запрета дублирующих обращений видео части (ТМ2, ЛА3, ЛИ1, ЛЛ1). Эта схемка запрещает /CAS при обращениях видеогенератора во время бордюра и вторых, третьих и четвертых считываний видео плоскостей за период строба промежуточного выходного видео регистра D47,D48, благодаря чему, разогрев ОЗУ сокращается вдвое.
Добавив ещё один триггер ТМ2 получаем схему асинхронного Турбо, когда на Z80 подаётся максимально возможный клок (6.5 МГЦ для Z80A, 9 МГЦ для Z80B, 12 МГЦ для Z80H). Это самый простой и дешёвый вариант получить удобный компьютер с эффективным тактом в 6...9 МГЦ.
Эта схема расширения ОЗУ очень похожа на схему М.Домарёва (Adelaide) для установки банки РУ5 + банка РУ7 (как видите, мозги у людей, желающих с'экономить целую банку РУ7-мых работают примерно одинаково). Только М.Домарёв не заморачивался на 5-тую банку, т.к это не поддержано программами. http://zx-pk.ru/threads/27565-256-kb...l=1#post906916Цитата:
Сообщение от VladimirS
Мой вариант схемы 512 кб на двух банках РУ7-мых выложен здесь http://zx-pk.ru/threads/27565-256-kb...l=1#post912935.
Обратите внимание, что этот вариант немного упрощённый. А именно, он не рассчитан на работу программ в банках 4, 5, 6, 7, т.к в в этих банках область F000...F3FF в данной схеме является коммутируемой. Это не фатальный недостаток, т.к программ работающих в банках 4, 5, 6, 7 не существует !
Это объединение схемы ОРИОН-СЕРВИС и схемы Турбо-142% от error404. Это нелогично и наверное не сработает. Почему не применить, как положено, мультиплексор КП12 или КП11? Это же тоже расход в один TTL-корпус. Но кроме того, что в отличие от предложенной схемы это будет работать, но дополнительно, мультиплексор вторым выходом в НЕТУРБО отключает /WAIT. А КП11 вообще позволяет иметь на выбор три частоты: 2.5 МГЦ, 5.0 МГЦ и 10.0 МГЦ.+Цитата:
Сообщение от Stampmaker
Я эмулятор пишу. Сейчас я сделал просто дополнительный wait в каждом цикле, но хотелось бы иметь абсолютно одинаковую скорость.Цитата:
Сообщение от barsik
Тесты лишь должны подтвердить теорию. Как работает Z80 - понятно, осталось лишь понять как его тормозит конкретная схема.Цитата:
Чтобы узнать времянки придётся делать тесты и вычислять число маш.тактов каждой команды.
Да эти микросхемы практически тоже самое, что и 565РУ7. Поэтому и заработало. А для 256Кx4 нужна другая схема регенерации.Цитата:
Сообщение от VladimirS
Как это?...Цитата:
Сообщение от aviator
Да просто писал "на бегу", да ещё и вымотанный. Там 4Mx1 9 штук. Но один хрен, они в орионе не работают.Цитата:
Сообщение от LeoN65816
- - - Добавлено - - -
Вот, кстати, табличка по объёму и типам: http://fthain.github.io/dram/
Я так понимаю, что 1Мx1 имеют шанс заработать. Они аналогичные 256Кx1. А вот более крупные - вряд ли. Они уже архитектурно внутри различаются.
- - - Добавлено - - -
Хотя, можно и 8 штук 1Мx4 организовать в 4 мегабайта... Но это уже форменное извращение.
А мне казалось, что SIMM-ы любых типов должны работать в ОРИОНЕ и в любой другой 8-ми разрядке. Я исходил из того, что принципы у всех динамических ОЗУ одинаковы. Разве SIMM из 1993 года отличаются по принципу регенерации от SIMM из 1991? Разве они не регенерируют весь столбец при обращении лишь в одну ячейку? Разве они регенерируются только по принципу "CAS before RAS"?Цитата:
Сообщение от aviator
Ведь и РУ7 имеют не 8-ми битовый вектор регенерации, а 9-ти битовый, и потому в ОРИОНЕ они работают только, если переставить адреса. Расскажите, пожалуйста, про Вашу схему включения SIMM. Интересует какие адреса идут на входы дополнительного мультиплексора соответствующие выходы которых подключены к входам A8 и A9 SIMM-ов.
Кроме того, на другие компьютеры ранее уже ставили SIMM и проблем не имели. Даже 72-х ногие. А может быть дело в питании, ведь новые ОЗУ обычно трёх вольтовые?
barsik, по идее, 256Kx4 и 1Mx4 имеют 3 типа регенерации, описываемые в документации: RAS-only, CAS-before-RAS и Hidden. CBR, второй режим, настоятельно рекомендуется как основной, так как внутри есть и счётчики, и задающие цепи для регенерации, и потребление меньше. По первому и 3-му достаточно не уложиться во времянки, и память будет сбоить. Но факт, такие микросхемы в "Орионе" не заработали не только у меня...
Схема подключения - расширение ОЗУ по варианту ревизии 512, который есть здесь в обсуждении. И похожий вариант вы рисовали совсем недавно. Пробовал и сдвигать адреса, используя самые старшие, и A8,9 цеплять и на ноль и на единицу. Это при попытках частичного использования. Все микросхемы в этих SIMM30 были 5-вольтовые. Эти модули в принципе были только 5-вольтовые по стандарту. Детально подключение - надо вспоминать. Я тогда и остановился на том, что надо переделывать регенерацию на CBR...
В принципе, попробую ка я разломать на выходных "Орион" и сделать второй заход. У меня сейчас лежит и некоторое количество РУ7...
- - - Добавлено - - -
http://zx-pk.ru/threads/21051-rasshi...na-565ru7.html
вот эта методика. тут как раз до 1 мегабайта.
Против фактов не попрёшь.Цитата:
Сообщение от aviator
А использованная Вами схема грамотная и использует тот же самый сигнал V2 (52) в качестве 9-го адреса регенерации, что и в той схеме, что я использовал в 1992 году (да и то лишь короткий срок, пока вскоре не достал более выгодную схему с установкой только одной банки РУ7). Правда я использовал РУ7-мые только наполовину, т.е только по 128К из каждой РУ7-мой и добавил в эту схему бит D2/F9 теоретически при наборе в граф.редакторе (т.е без опробования на практике). Однако, сравнив свою схему и Вашу, обнаружил, что мой вариант малограмотный, точнее в моём варианте нет ЛИ1 для блокирования переключения банок выше F000 в банках 4, 5, 6, 7. Отчего программы работающие в банках 4, 5, 6, 7 будут иметь проблемы, если используют код работающий из адресов F000...F3FF, включающий банки 4-7.
Для ORDOS и других ДОС в банке 0 это не создаёт проблем. Да и все программы для банки 0 (а это 99% программ ОРИОНА) доступ в доп.банки ОЗУ делают только подпрограммами F836/39. Программ работающих в банках выше 2-рой для ОРИОНА не существует. Но в ДОС для банок 1 и 2, процедура RRAM/WRAM собственная и располагается как раз в ОЗУ выше F000. Отчего эл.диск, если он рассчитан на использование банок 4, 5, 6, 7 работать не будет и вообще при вызове кода на F300, который сам включает банку 4 и выше, произойдёт фатальный улёт. У меня никогда не было ОЗУ более 256К, отчего все мои ДОС для реала имеют эл.диск использующий только банки 0-3. Но есть ДОС для эмулятора, где используются и старшие банки ОЗУ, и теперь ясно, что для их работы на реале придётся ставить ЛИ1.
Таким образом, предложенная мной схема нуждается в установке дополнительного вентиля ЛИ1 или ЛА3, хотя ради экономии разумно применить схему 'монтажного И' (на 2-х диодах и резисторе). Таким образом, сигнал B2 (порт F9/D2) на входе мультиплексора всегда должен приводиться к 0 (или 1, это не важно), если имеется чип селект /F000, что означает, что адрес обращения в память выше, чем F000. Без установки двух диодов, предложенная мной схема 512К может использоваться только для ORDOS.
Теперь по поводу регенерации SIMM. Из-за загадочного нежелания SIMM работать при традиционной регенерации, можно попробовать вариант регенерации 'CAS before RAS'. Не знаю как это делается, но если /RAS при этом не нужен, т.е если достаточно только импульсов по /CAS, то такую регенерацию сделать в ОРИОНЕ просто. Достаточно запрещать /RAS во время бордюра ОРИОНА. Бордюр формируется из сигнала гашения по строкам и гашения по кадрам на триггере на выходе D13/5. Достаточно пропустить /RAS (цепь 57), подаваемый на SIMM, через вентиль ЛЛ1, на второй вход которого подать сигнал с D13/5 (он 1, когда активный). Тогда во время бордюра на ОЗУ будет поступать только /CAS, что и обеспечит регенерацию.
А теперь открываю секрет турбирования ОРИОНА на 200%.
С целью экономии электро энергии для любого ОРИОНА на РУ5/РУ7 (особенно при турбировании 200%, когда ОЗУ перегреваются) желательно использовать ту же идею запрета на время бордюра, только не /RAS, а /CAS. Тогда 531 ЛЛ1 включается в разрыв цепи /CAS ОЗУ (на втором входе сигнал BORDER). Регенерацию это не нарушает, т.к она происходит по /RAS, а вот ненужный разогрев ОЗУ сокращается. По кадрам запрещается 100-100*(256:312)= 18%, а по строкам 100-100*(48:80)= 40% импульсов /CAS. Отчего разогрев существенно падает, почти вдвое.
Именно эта победительная идея позволила С.Караваеву сделать надёжной работу ОЗУ на такте 5 МГЦ в платах СУПЕР-ТУРБО в 1993. И это был большой секрет, т.к в предоставленных С.Караваевым схемах Турбо-200% об этом ни слова. И много людей мучилось отлаживая свой ОРИОН с двойным турбированием, вынужденные применять громоздкие вентиляторы, чтобы сократить перегрев ОЗУ. Я додумался до этой идеи намного позднее (использовал её в 1998, используя ОЗУ на такте 5 МГЦ с Z80H на такте 10 МГЦ). Только я использовал ещё более продвинутую схему запрета /CAS, что запрещает не только /CAS во время бордюра, но и три излишние дублирующие обращения к ОЗУ видео части.
Интересно, авторы ОРИОН-ПРО додумались до этой идеи или нет? А авторы плат новоделов ОРИОНА ?
Обладая этой идеей, теперь вообще нет смысла делать Турбо с WAIT по любому варианту, а следует делать ТУРБО-200% с запретом /CAS во время бордюра (заменять кварц на 9 МГЦ всё-равно желательно, чтобы расширить картинку на весь экран, а также, чтобы Z80B мог работать на такте 9 МГЦ).
для переключения в режим-480 на плате рев.512 используется вторая половинка ТМ7 от расширения для РУ7. стоит под процессором.Цитата:
Сообщение от barsik
собрал я вот сейчас этот режим в 480 точек.
кто знает, есть ли программы под него?
- - - Добавлено - - -
не вопрос рассмотреть и такой вариант сборки.Цитата:
Сообщение от barsik
полная схема "пореза" схемы Ориона и полного подключения всего, что нужно - есть?
в том то и дело (видимо так обстоит). Есть Z80 от орион-сервис, но нет под него программ, есть 480 точек но нет программ, есть звук на ви 53 но ничего его не поддерживает, есть звук на AY но без z80 card2 он не работает? и т.д.Цитата:
Сообщение от Stampmaker
нужны ли эти доработки?
Режим 480 точек поддержан в СP/M, доработка не то что очень нужная. Но для работы с текстом очень полезная.
Орион – радио любительский компьютер. Есть, конечно, основной мейнстрим, но творчество ведь никто не отменял. И это замечательно.Цитата:
Сообщение от tol123
Хотя попыхтеть меня тоже иногда подрывает) От буйства красок (направлений развития);)
Рукалицо.Цитата:
Сообщение от tol123
Парни, вы точно уверены, что Орион это ваше?
Ну, может там Ардуину, или РаспбериПИ пилить попонятнее будет?
Расширение экрана до 400, 512, 480 или 448 нужно только для текстообработки (а экран 256 нужен для другого). Игр на экран 480 или 512, увы, действительно не существует. Ничем не могу в этом помочь. Теоретически игры от Синклера можно переделать на экран в 512 точек (отчего они здорово растянутся по горизонтали).Цитата:
Сообщение от barsik
Вообще каждый из этих размеров экрана был предложен в своё время и для каждого из них были свои драйверы шрифта. Для 400 точек драйверы DR80, 80UN, VT52, для экрана 480 или 512 драйверы 480.COM и 480C.COM (это в цвете, отчего требует архитектуру Z80CARD-II), а для экрана 448 драйвер D7.COM.
Каждый из этих экранов был актуален для своего времени. Т.е это было решение конкретной текущей проблемы. В 1991-92 экран 400 и драйвер микрошрифта был первым решением проблемы 80-ти символов в CP/M, т.к не только текст.редакторы, но и компиляторы языков и другое фирменное ПО CP/M требовало 80 символов в строке. А тогда все считали, что чтобы завалить ОРИОН программами, необходимо иметь компиляторы ЯВУ (однако оказалось, что скоростей ОРИОНА и знания программистами ЯВУ не хватает для этого).
Однако, вскоре выяснилось, что небайтовые шрифты слишком тормознуты, а мизерные буквы шириной в 5 точек слишком неразборчивы. Поэтому был придуман экран 512 точек (впервые опробованный ещё на СПЕЦИАЛИСТЕ). Но оказалось, что для 512 точек надо менять кварц 10 МГЦ на 11 МГЦ, иначе экран 512 не влезал в растр. Кстати, драйверы на 480 точек написали также С.Коровкин и аделаидчики. Но драйвер 480/480C и все чужие драйверы не оконные, т.е они не облегчают разработку программ с графическим интерфейсом (т.е с окнами и меню). Но наиболее выгодны байтовые драйверы, хотя число символов резко падает. Редакторы, в частности, WordMaster удалось перенастроить на 64 символа, SuperText может работать на любом экране, а на WordStar плевать, т.к он 7-ми битовый.
Сам я до 1997 пользовался экраном в 480 точек, хотя был вынужден использовать только свои драйверы D6, D7 и D8, т.к на варианте "голый Z80" старые чужие драйверы не работали. Однако, когда я утратил Z80H, то пришлось использовать Z80B на такте 9 МГЦ. А при этом экран отплющивается и не только 512 точек, но даже и 480 точек никак не влезают в растр. И тут выручил драйвер D7 при экране в 448 точек. Оказалось, что 64 символа приличного качества со шрифтом 7*10 (7*9) как раз влезают в такой экран (64*7=448). Поэтому во всех моих древних эмуляторах до 2000 года поддерживается экран 448 точек (а не 480, как можно было ожидать) и нет архитектуры Z80CARD-II, т.к делалось лишь для личных нужд. Но в более поздних эмуляторах нет и 448 точек, только 384 (это произошло по причине утраты всех исходников при крахе винта и нехватки энтузиазма, чтобы всё позднее восстановить).
Поэтому с 2000 года я использую только экран 384*256 (при кварцах 8-9 МГЦ, чтобы хоть немного улучшить шрифт), отчего с тех пор мечтаю сделать для ОРИОНА текстовый адаптер (схема есть). А не делаю этого потому, что с 1999 уже не набираю и не отлаживаю программы на реальном ОРИОНЕ, т.к оказалось, что при наличии эмулятора, это гораздо удобнее делать в эмуляторе, отчего качество текстообработки перестало иметь значение.
Итак, относительно поддержки разных размеров экрана. Все мои драйверы - оконные, т.е они работают с любым размером экрана (от 256 до 1024 точек по горизонтали), т.к все они используют оконные параметры монитора-2:
Поэтому, чтобы драйвер стал работать на экран в 512 точек достаточно изменить байт ширина окна. Также удобно, что благодаря использованию этих стандартных ячеек мои драйверы без проблем работают с любым из 4-х экранов, что невозможно изменить в чужих драйверах (а все они неоконные и даже не программно настраиваемые). Драйверы до 1999 года рассчитаны на ACP/M 1.65, а позднее я пользовался только CP/M и другими ДОС только для банки 0. К сожалению все драйверы работают на Z80, и например, драйвер D7 крайне тяжело будет перевести на КР580 (т.к там по максимому использованы регистры Z80, в том числе и индексные).Код:.
HISCRN EQU 0F3CFH ; НАЧ.АДРЕС ЭКРАНА
WIDTH EQU 0F3D0H ; ШИРИНА ОКНА В БАЙТАХ
FRSTLN EQU 0F3D4H ; N ПЕРВОЙ СТРОКИ ОКНА
WHIGHT EQU 0F3D5H ; КОЛИЧЕСТВО СТРОК ОКНА
Так, что поддержка текстообработки при экране в 480 точек есть в CP/M для банки 1. Для банки 0 слишком расточительно тратить столько ОЗУ на экран, да и неудобно иметь экран посреди памяти. Ранее у меня были нортоны на экран в 480 точек, но они давно утрачены и с этим помочь не могу (может у кого-то сохранилось). Но драйверы VT52, D64, D6, D7, D8, D32, DRC и KEYALT у меня есть в исходниках для всех ДОС, что я когда-либо использовал на ОРИОНЕ (и даже для ORDOS). Есть также авторские исходники драйверов 480 и 480C (но их я никогда не перетранслировал, не люблю разбираться в чужом коде), а также из интереса дизассемблированные исходники чужих драйверов. Версии драйверов для ACP/M-1.65 годятся и для OS-DOS 3.62 (для версий OS-DOS 4.10 не проверял).
PS: Забыл сообщить зачем на ОРИОНЕ нужен экран в 256 точек.
Дело в том, что до ОРИОНА я пытался сделать компьютер МИНСК-64, у которого экран организован точно также как у ОРИОНА (младший байт - экранная позиция по вертикали, старший по горизонтали). Даже цвета организованы также и даже клавиатура такая-же. Отличие только в адресации портов (там IN/OUT) и адрес экрана другой. http://zx-pk.ru/threads/20927-quot-p...l=1#post898823
Поэтому с изменением в пару байтов годится ПЗУ ОРИОНА (экран шириной в 42 символа) и частично годится системное ПО. Чтобы сделать из ОРИОНА этот компьютер (3 МГЦ) достаточно перекинуть два провода в видеогенераторе и заменить кварц на 12 МГЦ (пиксель-клок 6 МГЦ). Ранее я хотел переделать в такой компьютер СПЕЦИАЛИСТ, но с ОРИОН-ом проще, т.к есть банка для цвета (достаточно заменить РУ5-тые в банке 1 на РУ6).
Оказалось, что и эмулятор для такого компьютера тоже не проблема. У меня заняло всего пару часов на переделку эмулятора ОРИОНА в эмулятор МИНСК-64 (да и то, только потому, что я не трогал его десятки лет и пришлось во всём разбираться заново). К сожалению, в эмуляторе для MSDOS экран 256*256 в режиме SVGA 640*350 отображается не только маленьким, но, или плющенным с боков (256*256), или приплюснутым по вертикали (512*256). При режиме 320*200, экран в 256 точек по вертикали тоже не влезает.
Можно программировать режимы БИС 6845 напрямую и задать любой формат экрана. Однако это высший пилотаж регистрового программирования (регистров очень много), и разобраться в этом не просто. Но похоже, что такой трюк возможен только на реальном SVGA адаптере, а на современных PC адаптер SVGA эмулируется, увы, не полностью, только стандартные режимы PC.
хорошо, а вот такой момент. это только у меня или оно так и есть - при режиме 384 растр сдвинут влево, а при 480 всё по центру. всё правильно?
Ох. Курим доработки Орион-128 рев. 512)
- - - Добавлено - - -
Растр идеально не получится отцентровать. Добавили к началу строки (384) еще точек, особо больше ничего не меняя.
А это как настроено. Если используется схема такая же как в рев512, то там с выходов ИД7 на 2 входа КП2 приходят 2 сигнала, которые как раз и отвечают за центрирования кадра в режимах 384 (один сигнал) и 480 (второй сигнал). На схеме они изображены для примера (т.е. к каким выходам ИД7 они присоединены - это не догма). Перемещая эти соответствующие входы КП2 по выходам ИД7, центрируется растр в каждом из режимов. Если применена ИД7 серии 555, то можно и по нескольку соседних выводов ИД7 соединять, что повышает стабильность кадра. Как то так.Цитата:
Сообщение от Stampmaker
Stampmaker, мы не ванги. Просим фото, что у вас и как. И какую ревизию собираете. Тема то про просто Орион-128)
- - - Добавлено - - -
Или это мутант (в хорошем смысле) - ваш взгляд на Орион;)
да, с этим я разобрался. про 2 сигнала тоже понял, что это как примеры.Цитата:
Сообщение от Error404
да, она, другой не былоЦитата:
Сообщение от Error404
спасибо, попробуюЦитата:
Сообщение от Error404
Начинать не когда не поздно. Ардуину-ардуинам, а распбери-англосаксам. Мне пока важно,чтобы у меня хоть что нибудь работало (по минимуму работает), до остального созреть видимо надо.Цитата:
Сообщение от Error404
Это точно. Хотя эти доработки, еще тот квест). Так лучше разобраться в мейнстриме, а дальше …. Хоть чего захотим.
вот фото.Цитата:
Сообщение от OrionExt
я не знал, как лучше показать, поэтому сделал два снимка и наложил один на другой. "384-ый" экран закрасил, чтобы было видно, как он расположен на телевизоре после доработки.
а справа видно, что показывается, если включить режим "480".
мой вопрос должен был звучать так: разница положения экрана 384 до доработки не должна отличаться от положения его же после доработки до варианта 480?
хотя это уже не важно. я вернул всё как было до доработки. варик 480 оставил как резерв, к которому можно вернуться в будущем и просто перепаять 2 провода.
http://s001.radikal.ru/i193/1705/fb/81320f0f5f83.jpg
У меня 384 "до" и "после" всегда отличался по положению, подбирал выводы ИД7.Цитата:
Сообщение от Stampmaker
Плюс еще телек "интерпретирует" аналоговый по сути кадр, каждый телек по-своему. Мой LCD со SCARTa например масштабировал 480 по ширине всего экрана, и даже 4-5 крайних справа точек не влезало (полсимвола). А на скриншоте видно что все помещается, и картинка 480 занимает от силы 3/4 экрана по ширине.
Error404, значит у меня всё правильно. прекрасно.
Полная схема ОРИОНА со всеми предложенными кем-либо, когда-либо мелкими доработками не существует. Во-первых, это слишком большая работа перечерчивать всю схему ОРИОНА, даже если не вносить в неё изменений. Хочу сказать, что нет даже базовой схемы ОРИОНА без всяких изменений. Тем более перечерченной грамотным образом (хотя бы участок видеогенератора, т.к если его нормально перечертить, то будет понятно, как он работает).Цитата:
Сообщение от Stampmaker
Во-вторых, если все когда-либо предложенные доработки ввести в схему ОРИОНА одновременно, это будет 200 корпусов, где разобраться будет невозможно. И как ввести, например 6 вариантов одной доработки в одну схему. Сюжет доработок, как раз и заключается в том, что это маленькие и независимые доработки, которые делаются на уже работающей базовой плате, что упрощает их выполнение вручную. Потому общая схема с частью доработок нужна только, если кто-то захочет делать новодел, а при ручном исполнении это не надо.
Для начала интересно хотя-бы перечислить какие вообще доработки ОРИОНА были когда-либо предложены. И оценить какая их в настоящий момент актуальность. Актуальность надо оценивать по тому, что эти доработки дают. Я знаю лишь о части доработок с разной степенью их поддержки авторами. И почти все они уже давно не актуальны.
1. Доп.ПЗУ с 0 (по сбросу грузит 2К на B800, затем JMP F800). Удобно если нет ROM-диска.
2. Замена КР580 на Z80. Схема с RC-цепочкой, вполне надёжная. Звук на выход МГ. 1991
3. Установка 62256 в качестве дополнительных банок ОЗУ. 1991
4. Z80CARD-I с окном диспетчера ОЗУ в 32К, расширением ПЗУ F800 до 4 кб и звуком OUT FF.
5. 256 кб ОЗУ путём установки 565РУ5 в два этажа. 1991
6. Расширение экрана до 768 точек. Др-р SuperFont. Красивый шрифт, но медленный. 1991
7. Расширение экрана до 400 точек. Для 80 символов микрошрифтом. 1992
8. 256 кб за счёт установки двух банок 565РУ7. 1992
9. Установка таймера ВИ53 на F740, три канала по 1.25 или 2 МГЦ. 1992
10. Установка AY-8912 на адрес F760. Три канала по 1.75 МГЦ. 1992
11. 256 кб за счёт лишь одной банки РУ7 + банка РУ5 (М.Домарёв). 1993.
12. Z80CARD-II с окном диспетчера ОЗУ в 16К и прерываниями 50 ГЦ. 1993
13. 4 варианта Турбо-142% для Z80. 1993
14. Z80-CARD от ОРИОН-СЕРВИС (такт Z80 2.5, 5 и 10 МГЦ), 1993
15. 2 схемы Турбо-200% для Z80CARD-II (В.Смирнов, С.Караваев), 1993
16. Установка Z80 и 3-я схема Турбо-200%, С.Коровкин (схема есть). 1993
17. Расширение экрана до 480 точек, 1993
18. Подключение клавиатуры от Корвета, С.Коровкин. 1993.
19. 4-х плоскостный цвет и палитры С.Коровкина. 1993
20. Установка теневого ПЗУ 27256 в окне 0...7FFF (расширение ROM-BIOS). 1993
21. Эмулятор ZX-Spectrum, вариант С.Караваева на плате Супер-Турбо-3 (12.1993)
22. 3-х плоскостный цвет (ИР13, ИР82 в 2 этажа), 1994
23. 4 плоскости монохрома из 2-х банок (25 Гц, пониженная яркость, мерцания), 1994
24. Установка на адрес F600 контроллера НГМД от РК86, 1994
25. Эмулятор ZX-Spectrum на базе Z80CARD-II (7 дополнительных корпусов), 1995
26. Установка последовательного интерфеса ВВ51 для подключения мыши, 1995
27. Установка 62256 для получения скоростных участков памяти, 1997
28. Установка Z80H на такте 10-12 МГЦ (ОЗУ 5-6 МГЦ), 1998
29. Запрет части /CAS от видео генератора, снижение разогрева ОЗУ на 5 МГЦ, 1998
30. Установка Z80B на такте 9 МГЦ, ОЗУ на такте 4.5 МГЦ, 1998
31. Подключение рэтро аппаратной клавиатуры типа 15ВВВ-97-06 или "Консул", 1998
32. Расширение экрана до 448 точек, 1999
33. Адаптер винчестера IDE, на базе порта F600 (3 доп корпуса), 1999.
34. Адаптер для подключения IBM клавиатуры в виде Z80-контроллера, 2000.
О доработках после 2000 я не в курсе. Для каждого любителя ОРИОНА интересны разные доработки. Мне лично интересен лишь Z80 (да и то не обязательно), желательно Турбо (до реальных 5...7 МГЦ), ПЗУ F800 в 4 кб, и теневое ПЗУ 27256 в окне 0...3FFF для размешения там хотя-бы драйверов D8 и D7. Вероятно, экран в 400 точек, но с цветом. А также таймер ВИ53 для вывода классической музыки. Также интересен AY-8912.
Вот в этой теме мы обсуждали 3 варианта Турбо 200% (5МГц реального такта) - там и схемы и что-то по методике. Но дело кончилось в-основном только разговорами. :)Цитата:
Сообщение от Stampmaker
Полная схема доработок Ориона-128 есть, и называется она "Орион-ПРО" :)
И да, немножко вайтованные 10 МГц ПРО'шки интереснее Турбы-200%
Замечание точное. Все значимые доработки ОРИОНА - Z80, его турбирование, диспетчер ОЗУ (хотя и в извращённой форме), большой ROM-BIOS, прерывания, большой экран, 4 плоскости экрана и слоты расширения, реализованы в ОРИОН-ПРО.Цитата:
Сообщение от Denn
Только при этом перестарались. Если бы КНГМД перенесли на периферийную плату, убрали бы ненужные 4 плоскости экрана и всё упростили бы до минимума, то при столь качественной разводке получился бы великолепный компьютер с размерами даже меньше платы ОРИОНА. В частности, раз 4 обращения за цикл строба видеорегистра, позволяет иметь 2 плоскости из всего одной банки РУ7, зачем тогда вторая банка РУ7-мых? Ещё два диспетчера с окнами по 8К (для ОЗУ и ПЗУ) не нужны, - если есть окно коммутации размером в 16К, включайте в это окно и ПЗУ 27256 и нет проблем, никакого лишнего расхода деталей. Т.е если бы сделали практически ОРИОН, как я и предлагал всегда, то это не раскололо бы платформу и не погубило бы ОРИОН. А главное, на доводку схемы и печати не ушло бы 5 лет. Анонсирован ОРИОН-ПРО в середине 1993, и расчёт был выпустить ОРИОН-ПРО в начале 1994. И это было вполне реально, если бы не извращались с архитектурой, а ограничились бы обычным ОРИОНОМ на Z80, пусть даже на такте всего 2.5 МГЦ.
Не согласен. Даже 10 МГЦ с ОЗУ на 2.5 МГЦ дают ~5 МГЦ реального такта. Заставить ОЗУ работать на такте 5 МГЦ важно потому, что это даёт возможность сделать схему WAIT для такта в 10 МГЦ, также как в ОРИОН-ПРО и получить 5 МГЦ умноженные на 1.41. Некрасиво говорить, что в ОРИОН-ПРО 10 МГЦ, надо говорить 10 МГЦ с WAIT, а это всего ~6.5 МГЦ реального такта. Вскоре ОРИОН, по крайней мере мой, будет работать быстрее, чем ОРИОН-ПРО. Быстрая статика, включённая вне экранной области даёт реальные 10 МГЦ, так что, даже без ускорения на 1.41, мой 200%-турбированный ОРИОН быстрее, чем ОРИОН-ПРО.Цитата:
Сообщение от Denn
Мне интересна статистика использования Z80B в ОРИОН-ПРО.
У меня почему-то Z80B не работал выше, чем 9 МГЦ (причём не только в ОРИОНЕ), хотя С.Караваев утверждал, что в его схеме установки Z80, любой Z80B без всякого подбора тянул 10 МГЦ. Также в документации ОРИОН-СЕРВИС указано, что половина имеющихся Z80B тянула 10 МГЦ (хотя это и не показатель, т.к там циклы памяти сильно вайтованные). По паспорту Z80B обязан работать только на 6 МГЦ, так что 10 МГЦ это за пределами типового оверклока.
4-плоскостной цвет реализуется в мультикарте, которую можно не ставить.Цитата:
Сообщение от barsik
Есть утилита SPEED-TEST, не показывает она 6,5 МГц на реале.Цитата:
Сообщение от barsik
В моём "ПРО" работает именно Z80B, в режиме "10 МГц" работа стабильная. Но за это пришлось побороться, да...Цитата:
Сообщение от barsik