Такой вопрос - какие сигналы от Z80 следует подтягивать к +5В, кроме шины данных?
Неактуально - всё это описано в Z80-UM...
Вид для печати
Такой вопрос - какие сигналы от Z80 следует подтягивать к +5В, кроме шины данных?
Неактуально - всё это описано в Z80-UM...
Для тестирования корректности функционирования подсистем пишу более расширенный тест, чем стандартный для ПРО.
На данный момент готовы проверки 6 видеорежимов из 8 - остались только 3-х и 4-х битные.
Результаты 4-х и 16-и цветных режимов:
Вложение 65691Вложение 65692Вложение 65693Вложение 65694
Заодно выводится номер столбца-знакоместа для проверки корректности широкоэкранного режима.
Выбор теста осуществляется DIP-переключателями конфигурации ПРО (не инверсные значения, то есть "флажок" в эмуляторе означает "0" в бите):
- Биты 0-2 - номер проверяемого видеорежима;
- Бит 3 - активация турбо-режима;
- Бит 4 - активация широкого экрана;
- Биты 5-7 - не используются. Резерв для тестирования PIO.
Пишу на С, собираю через SDCC, поэтому выходной код не самый оптимальный. Но зато легко и быстро пишутся программы).
PS: Жду CPLD'шки для сборки макетки. А пока - вот таким вот тестом буду проверять симуляцию в FPGA...
В продолжение темы о тесте - перевёл полностью на ASM. Не требует памяти, работает чисто на регистрах.
6 тестов из 8 уместил в 2Кб - без агрессивных оптимизаций и сжатия, включая шрифт 8*8 для 128 символов.
Собственно, текущая версия теста (исходник и бинарник) - в аттаче, если кому интересно.
Вложение 65698
О назначении переключателей было написано выше, потому не дублирую.
Прошивается вместо ROM1, которая на 8Кб.
- - - Добавлено - - -
PS: Это мой первый опыт на ASM'е Z80, просьба тапками не закидывать -_-
Этаж сколько эта мини платка с смд халявными микрухами (из прошлой жизни) жрет на один см квадратный. Орион-Про отдыхает:v2_dizzy_roll:
Такой вопрос - насколько актуален объём памяти в 1Мб? Или "всем хватит" 512Кб?
Просто пытаюсь максимально впихнуть в ресурсы по видеопортам и не хватает ячеек из-за "жирного" диспетчера памяти. А выносить часть портов, относящихся к памяти, в другой корпус - не очень хорошо, поскольку они только внутри и коммутируются всё равно.
Готового ПО под такой объём ОЗУ в природе нет. И ситуация тут следующая. Если бы в Орионе был 1 Мб, то это было бы классно, и, например, я бы в своей ОС с удовольствием поддержал (а точнее сказать, в таком случае вообще пересмотрел бы архитектуру ОС). Но, есть "но"... при условии популярности такой платформы среди пользователей. А мы все понимаем, что этого не случится.. увы.Цитата:
Сообщение от andreil
Поэтому, если технически сложно сделать "метр", то я бы оставил 512 Кб.
Не то, что сложно, просто я пытаюсь вырезать до минимума необходимого, что бы уместить в 1 чип почти всё, касающееся памяти (порты F9, 08, 04, 05, 06 - стандартный, Z80-Card, Pro). Если порт F9 ещё можно вынести "наружу", то остальные будут реализованы "в чипе", что бы избавиться от ожиданий при обращении к ВВ55, на которых они реализованы в оригинале. Сооружать "эмулятор" ВВ55 на рассыпухе не вижу смысла вообще.Цитата:
Сообщение от Denn
- - - Добавлено - - -
Очень много ячеек занимают синхронные счётчики - использовать внешние не позволит количество выводов.
Синхронность релизована "в лоб" - выдачей данных по ниспадающему фронту (счёт - по восходящему фронту). То есть на 10 битный счётчик тратится 20 ячеек, таких у нас 2...
- - - Добавлено - - -
Кстати, по портам - порты диспетчера памяти (04-06) софтом только пишутся или ещё и читаются?
Порт 0А, например, читается - тут само его назначение предписывает это (управление RAM, ROM). иначе приходилось бы это же состояние хранить отдельно в памяти для модификации отдельных битов.
Немножко перефразирую: "Странно как-то ты, дядя Фёдор, бутерброд кушаешь..." (C)Цитата:
Сообщение от andreil
Для синхронного n-битного счётчика необходимо и достаточно n триггеров/ячеек. "Ведущий-ведомый" триггеры в ОРИОНЕ, и уж тем более в счётчиках строк/столбцов, ИМХО, совершенно не нужны...
Делал так - в итоге получаю глитчи в реале из-за асинхронности счётчиков и полный разлад всего видеотракта, поскольку возникают "левые" импульсы для счётчика строк. Первоначально я так и было, но при проверке оно работало через раз - наблюдалась вот такая вот картина на счётчиках:Цитата:
Сообщение от LeoN65816
https://image.prntscr.com/image/Dsjf...qxbEubihhg.png
На картинке не вижу ничего "нехорошего", нет других сигналов, от которых зависят счётчики...
На всякий случай напомню о синхронности: у счётчиков строк и столбцов должен быть один (!), единственный (!!), общий (!!!) клок, и это должен быть пиксельклок. А вот разрешения клока у счётчиков столбцов и строк должны быть разными, являющимися комбинаторной функцией от предыдущего состояния. Причём, функция разрешения счёта/сброса счётчика столбцов должна являться переменной для функции разрешения счёта/сброса счётчика строк. Вот посмотри и проникнись ;) :Цитата:
Сообщение от andreil
Результат здесь.Код:module HVSync (
input wire PixClock,
output reg HSync,
output reg VSync,
output reg [2:0] R,
output reg [2:0] G,
output reg [2:0] B);
parameter HVA = 1024; // Visible Area
parameter HFP = 24; // Front Porch
parameter HST = 136; // Sync Time
parameter HBP = 160; // Back Porch
parameter VVA = 768; // Visible Area
parameter VFP = 3; // Front Porch
parameter VST = 6; // Sync Time
parameter VBP = 29; // Back Porch
//variables
reg [10:0] PC = 0; // Pixel Counter (Column, X)
reg [9:0] LC = 0; // Line Counter (Row, Y)
wire VA = (PC <HVA) & (LC < VVA); // Visible Area on screen
always @(posedge PixClock)
begin
// VA <= ((PC < HVA-1) | (PC == HVA+HFP+HST+HBP-1)) & ((LC < VVA) | (LC == VVA+VFP+VST+VBP-1));
HSync <= (PC >= HVA+HFP-1) & (PC < HVA+HFP+HST-1);
if (PC < (HVA+HFP+HST+HBP-1))
PC <= PC + 1'b1;
else begin
PC <= 0;
VSync <= (LC >= VVA+VFP-1) & (LC < VVA+VFP+VST-1);
if (LC < (VVA+VFP+VST+VBP-1))
LC <= LC + 1'b1;
else
LC <= 0;
end
end
// Color Image
always @(posedge PixClock)
begin
if (VA)
begin
if ((PC[7:0]==0) | (PC[7:0]==255) | (LC[7:0]==0) | (LC[7:0]==255))
begin
R <= 7;
G <= 7;
B <= 7;
end
else begin
if (LC[7:6]==0)
begin
R <= ~PC[9:7];
G <= 0;
B <= 0;
end
if (LC[7:6]==1)
begin
R <= 0;
G <= PC[8:6];
B <= 0;
end
if (LC[7:6]==2)
begin
R <= 0;
G <= 0;
B <= ~PC[7:5];
end
if (LC[7:6]==3)
begin
R <= PC[6:4];
G <= PC[6:4];
B <= PC[6:4];
end
end
end
else begin
R <= 0;
G <= 0;
B <= 0;
end
end
endmodule
В 90-х я заложил в Альтаир-ДОСе карту памяти до 1Mб, при том на реальных клонах у нас было по 512к, которые при наличии электронного диска (он в этом же ОЗУ порта F9) занимали всю память так, что электронный диск был меньше желаемого (т.к. пользовались еще большим количеством разных прог - драйверов, мониторов, плееров и т.п., а они все сидят в памяти доп. страниц). Но тогда у всех были только дисководы и без электронного диска было никак. Сейчас есть IDE, SD - более быстрые и емкие, делай нехочу, и можно обойтись без эл.диска. А вот для UZIX иметь хотя бы 1Мб крайне желательно, ибо там каждый процесс по 60к и на 512к можно одновременно иметь только 5 процессов (из которых один init, т.е. по факту четыре, а если еще иметь и cron, так и вообще - три). Кароче, я за 1Мб в базе и с опцией расширения (если не шибко усложнит).Цитата:
Сообщение от andreil
Посмотрим, но вариант с памятью >1Мб не укладывается в GAL, если рассматривать такой вариант. И в CPLD на 128 ячеек так же не укладывается уже.Цитата:
Сообщение от Error404
В CPLD впихнул почти весь видеотракт:
- Счётчики горизонтали и вертикали - 20 ячеек + 8 на логику;
- Переключение турбо-режима (и бит порта 10);
- Порт видеобанков - 4 ячейки (номер "банки" + бит широкого экрана);
- Мультиплексирование адреса для памяти - 19 ячеек;
- Арбитраж памяти - 10 ячеек (вместе с управлением буферами к Z80);
- Дешифрация портов видео - 3 ячейки;
- Порты управления памятью - 44 ячейки.
Расчёты примерные, и не включают в себя ячейки на формирование выходов (ШД + ещё пара), вот и получается "внатяг".
PS: Китайцы-посредники крупно кинули с CPLD - в их фотографиях они были, а к нам не пришли. Будем ругаться по этому поводу, потому что я в минусе на 100$ по ним только. А пока - начал паять макетку на дискретках и ATF (как раз позавчера программатор для них пришел).
- - - Добавлено - - -
Кстати, посчитал на бумажке примерные временные задержки в случае использования ATF и быстрой памяти (как у меня, 10нс) - видеоданные будут отставать от синхронизации на 7-40нс, то есть до 1 пикселя смещение.
И очень плохо получается с безвейтовой работой процессора с памятью на частоте процессора 12,5МГц (кстати, мой Z84C0020PEC такую частоту тянет, но греется ощутимо). Дело в том, что длительность импульса записи составляет около 80нс. С учётом задержек в логике и прочем, получаем около 60нс.В итоге, что бы гарантированно иметь доступ к памяти на такой частоте без ожиданий, частота переключения "видео-процессор" для памяти должна составлять 12,5МГц. В противном случае будут "промахи" по записи - в симуляции это было очень хорошо заметно, когда идёт заливка экрана - при первом проходе что-то пропустило и залило потом.
Из неявных проблем конструкции - буфер между памятью и процессором не получится выполнить на АП6 и прочих буферах. При текущих параметрах необходимы защёлки как минимум на чтение (как это реализовано в ПРО), иначе конец чтения может попасть на интервал доступа видео к памяти. И потеряем байт(ы). В итоге получается сразу 4 корпуса вместо 2-х - по 2 на каждое направление, оба защелки (например, ИР22 или аналогичные).
2-мя защелками, как в ПРО, не обойтись - шина памяти двунаправленная.
- - - Добавлено - - -
По поводу памяти - как на счёт использования SDRAM?
Да, для инициализации придётся ставить хоть какую-то CPLD для реализации конечного автомата. Но такую память сейчас можно найти в любом магазине с комплектующими по копеечным ценам.
Из плюсов - большие объёмы с минимальными затратами (легко организовать объёмы от 8Мб и больше, нам интересны только до 4Мб, дальше порты ПРО не дадут адресовать уже).
Минусы:
1) Повышенная тактовая частота - для тактовой процессора 12,5МГц и длительности сигнала записи в 1 такт требуется тактовая частота памяти в 50МГц (работаю над уменьшением до 25МГц, курю ДШ);
2) Менее "паябельные" корпуса для обычных паяльников.
ЕМНИП в любом Орионе с Z80 всегда обращение процессора попадает на интервал доступа диспетчера памяти (если поделить время работы с памятью как 50:50). В журнальном Орионе связано с тем, что у Z80 на 20% длиннее сигналы обращения к памяти чем у 8080 под который составлена журнальная схема. Для этого делали доработку "в один порез" на арбитре D13 изменяя эту пропорцию 50:50 на более подходящую. Это чтоб обойтись без регистров (хотя до того были варианты и с дополнительной ИР82 как самое очевидное "решение в лоб". Орион ПРО тут не может быть ориентиром, он весь собран из "решений в лоб" и поэтому в нем 150 корпусов против 65 в оригинальном Орионе).Цитата:
Сообщение от andreil
Примерная структурная схема текущего варианта Ориона, без части портов, ПЗУ и всех УВВ. Память в обоих направлениях буферизирована регитрами/защёлками для обеспечения корректности данных.
Реализована работа с SDRAM - ради этого пришлось увеличить частоту. По факту память будет тактироваться от 100МГц (через фазосдвигающую цепочку и XOR). В противном случае память не успевает отработать в отведённое время (для чтения и записи требуется 8 тактов). Очень тормозят циклы ожидания - их тут половина, иначе память не успевает по факту (всё по ДШ).
«Ученье - вот чума, ученость - вот прична,Цитата:
Сообщение от andreil
Что нынче, пуще, чем когда,
Безумных развелось людей, и дел, и мнений.»
А. С. Грибоедов «Горе от ума»
Сорян, я не удержался. :)
Не, ну правда, в Спектрумы ставят любую статику на простой защелке CAS (или RAS) на одном регистре. И оно там работает на частотах 3.5 и 7 МГц вот уже как пару десятилетий (это стали делать сразу как статика подешевела) в тысячах экземплярах у нас и за рубежом. При этом базовая схема остается совсем не переработанной, без каких либо изменений. Ну не читали они даташиты - и слава богу, все работает.
Понятно, что тут VGA и поэтому частоты видеоконтроллера вдвое большие, но не вдесятеро же.
- - - Добавлено - - -
Думаю, если все так критично, то оправдан уход от "прозрачного ОЗУ" (вейтить проц в угоду видеоконтроллеру, или выправлять плавающей растактовкой проца - на Орионе и такое было в Ташкентском Турбо). Это всяко лучше, чем как в старые времена организовываить рейд на оборонное предприятие дабы выкрасть секретную космическую разработку-ОЗУ, работающую на таких частотах.
Да уж, ради 10 МГц такта (для ПРО) реального компа вдувать 100 МГц - это жёстко. Я бы пошёл по пути МПС сама по себе, а "видяха" сама по себе. Разумеется через двухпортовку. Как-то сразу всё проще и логичнее выходит. Но это просто мысли вслух, своего мнения ТС не навязываю.
Ввод SDRAM - это чистейший эксперимент. И да, они на каждом углу сейчас есть - выпаиваются с любых планок памяти со старого компьютера. На любой барахолке можно купить пачку планок. Так что совсем не дефицит ;)Цитата:
Сообщение от Error404
И да - её имплементация - чистейший эксперимент. Думаю сейчас назад на SRAM вернуть. Думал сэкономить на пинах за счёт мультиплексирования адреса, но не получилось, по сути.
PS: Если не тормозить процессор, то на максимальной частоте (12,5МГц) строб записи получается всего 80нс (сигнал /WR от Z80). SDRAM за это время должна отработать все 7 тактов цикла записи (IDLE, RAS, NOP, NOP, CAS, NOP, NOP). Без NOP'ов не получится (даже без 1) - сразу не работает и всё. Если тактирование скинуть до 50МГц, тогда можно выкинуть их часть - завтра с этим и буду крутить, как получится.
Пока что работает стабильно, но чтение памяти процессором не проверял вообще...
Со статикой максимум, что удалось впихнуть - 4 чипа памяти. Дальше не хватает ног у управляющей CPLD - и так уже 100% занято, остались только ноги JTAG'а (но это совсем край уже).
Получается очень компактно, но 23 корпуса... 4 из них - SRAM (по просьбе Error404, что бы можно было нарастить до 2Мб просто допайкой чипов).
Сижу и думаю - если и порты так же в CPLD вторую упаковать, то ВЕСЬ Орион умещается на 1 платке. Главное - грамотно скомпоновать, что бы вписаться в 2 слоя ПП. Места сейчас вполне хватает для подобных манёвров.
а раньше он на нескольких платках что ли помещался? :-)Цитата:
Сообщение от andreil
Всё дело в размерах платки, которые ограничены 10*10см. Больше - не охота платить зазря...Цитата:
Сообщение от Stampmaker
Пожаловался? Ты такое пилишь. {censored}
Напоминаю, это ваш последний штрафной балл.
Извиняюсь, но к чему такие резкости? И где Вы увидели жалобы?Цитата:
Сообщение от OrionExt
Всё ясно с уважаемым...
За выходные почти развёл платку. Уже почти закончил питание и тут вспомнил, что я не вывел на разъём синхру :v2_dizzy_facepalm:
Завтра подумаю как их лучше всего провести через текущие дебри дорожек и полигонов, что бы питание особо не побить.
А пока вот 2 картинки: верхний слой и нижний слой.
Всё строго в 2-х слоях, полигон "общего" в местах перехода перфорировал переходными для снижения потерь на них. Так же слежу, что бы питание и "общий" были как можно "жирнее" - исхожу из общего тока в 4А, что бы хватило с запасом.
Например, дорожка VCC, идущая по правому краю в нижнем слое, имеет ширину 2мм, а слева - 1мм. Сделал разводку с разграничением по положительному питанию - 1 трасса на Step-Down до 3.3В и околопроцессорную обвеску с процессором, вторая уже полностью разведена.
Вариант данного участка платы ещё не финальный (из-за тех 2-х сигналов), так же потом ещё долго буду проверять ширину питания, что бы везде хватило.
По поводу 3,3В - это пока в теории, скорее всего будет без него, то есть только 5В.
Хостинг изображений какой-то странный - не показывает верхнюю четверть рисунка. Плата же квадратная? Или нет?
А где на ней процессор? Он же ведь не в ПЛИС?
Я обрезал верх просто - там пока вообще пусто. Процессор и ПЗУ ещё только добавляю в схему.Цитата:
Сообщение от Error404
Вот вся плата вместе с процессором, ПЗУ и второй CPLD. Так же разместил конфигурационный переключатель. Остались ещё блокировочные конденсаторы и подтягивающие резисторы - добавлю в последнюю очередь уже. Пока ещё пытаюсь скомпоновать, переставляя оставшиеся 3 корпуса :)
- - - Добавлено - - -
Из отличий от стандартного ПРО - ПЗУ будет одна. В ней будут обе прошивки (ROM1, ROM2), переключаемые адресом A16 (формируется на основании сигналов выборки ROM. Так же адресные выводы А16 и А17 будут выведены на джамперы для выбора текущего банка.
Системный разъём - пока что оригинальный из журналов (распиновку брал в №4 за 93 год), а не ПРОшный.
- - - Добавлено - - -
Ещё думаю вывод PGM завести на CPLD - что бы в будущем иметь возможность перепрошить её средствами самого компьютера. Пущу через джампер, что бы можно было разорвать в любой момент.
- - - Добавлено - - -
Основная Шина, очень жирная :)
Выше - системный разъём, на который и выводятся почти все сигналы из этого пучка. Ну и соединяет основные 4 корпуса - процессор, ПЗУ и 2 CPLD...
Это исключит возможность использовать Альтаир-ДОС из ПЗУ. Конечно, в ПЗУ есть еще и ПРО-ДОС, но она несамодостаточная (там только код ОС и Нортон, и никакой файловой системы - чтобы что-то делать обязательно нужен дисковод FDD), тогда как в Альтаир-ДОС полноценная файловая система на весь расширенный (выше первых 64к) объем ПЗУ и файлы туда можно положить любые - это автоматизировано в моем TotalCommander (DoubleCommander, Far) плагине для работы с файловыми системами CP/M. Также, в пустые места первых 64к ПЗУ ROM2 я встроил "псевдо ромдиск-Ордос" (чтобы не делать для этого отдельную плату расширения) на 8к, управляется этим же плагином.Цитата:
Сообщение от andreil
У ПЗУ 2 старших адреса выведены на джамперы. А в процессорной CPLD 15 пинов остались свободны и я их вывел на "гребёнку". Так что соединить 2-мя проводками и дополнить прошивку CPLD - и готово расширение ПЗУ до 256Кб, управляя стандартным портом.Цитата:
Сообщение от Error404
Но да, может лучше будет-таки вывесить отдельную мелкую ПЗУшку для ROM1-BIOS, что бы не засирать половину ёмкой - это можно будет сделать через системный разъём и те же свободные пины, например.
Так что всё решаемо и очень быстро. Просто места под вторую ПЗУ на плате уже нету вообще, только если крепить её "на сопли" к имеющейся.
256кб - ни то ни сё. Какие вообще ПЗУ максимальной емкости есть в планаре с 8-битной организацией? На память приходит только 27/28x040 (512кбайт). А есть ли более ёмкие параллельные TTL-совместимые ПЗУ? 27с322 не предлагать - у них 10 лишних ног для возможности 16-разрядности (хотя и таки да - 4Mбайт в одном кристалле!), а тут лишние ноги на плату не влезают. Или влезет?Цитата:
Сообщение от andreil
При текущей компоновке - уже даже 2 дорожки дополнительных от CPLD до ПЗУ не влезут - и так уже плотненько, а на втором слое я питание разводил. Если пихнуть больше трасс - где-то вполне может просесть "общий". Не хочу потом напаивать провода вдоль трасс для увеличения пропускной способности по току :)Цитата:
Сообщение от Error404
По ПЗУ - путаю, у меня заложена 29F040, то есть 512Кб. На материнских платах их хватает. Да даже на Али чуть больше 1$ за корпус стоят. Дальше - уже другие корпуса, если рассматривать корпуса PLCC-32.
Вот внешний вид платы на данный момент - остались только сигналы прерываний. Верх и низ.
И да - на плате не уместились ни клавиатура, ни ROM-диск. Всё это придётся делать отдельной платой, подключаемой через системный разъём. Так что потом ещё долго буду думать - "а всё ли я туда вывел?" :)
Сейчас, как видно из картинки, получилось 26 корпусов (2 из них - одногейтовые инверторы). Весь видеовыход собран на логике. Во второй CPLD ещё достаточно свободных ячеек имеется для организации чего-либо (например, через свободные пины подвесить что-либо из периферии, если вывести их на системный разъём и т.д.). Основное назначение этих пинов на данный момент - использование в случае, если я что-либо "забыл" при переносе, что бы не паять к выводам волоски ;)
Итак, в отладке через ЛА нашел косяки в реализации и исправил их.
Сейчас вроде бы что-то запускается, но не полностью - на экране остаётся мусор, не отображаются символы. В общем, буду дальше отлаживать. Уверен на 95%, что ошибка опять в менеджере памяти (по схеме ПРО - правый верхний угол первой страницы, я там очень много перевёл в другой базис и мог напортачить).
Так что - сижу и дальше пошагово сверяю с эмулятором и декомпилом...
- - - Добавлено - - -
Мда, а дальше - Ж*** с разбором кода. Оный копируется по кусочкам в оперативу, откуда и выполняется. Пока всё "сошью" в IDA, задолбается уже =/
Хм, нашел место, которое выполняется некорректно - сверял с эмулятором на том же ROM'е.
Исполняемый код:
Данный сегмент зануляет один столбец экрана и вызывается в цикле до конца экрана.Код:seg005:F3F2 sub_F3F2:
seg005:F3F2 push bc
seg005:F3F3 push hl
seg005:F3F4 inir
seg005:F3F6 pop hl
seg005:F3F7 pop bc
Команда INIR - читает из порта (C) и пишет в (HL), при этом увеличивая HL и уменьшая B, пока B не станет равен 0.
При выполнении этого кода "в железе"наблюдается отсутствие приращения для регистра HL - картинка с ЛА по ссылке
Буду копать причины такого поведения - до этого момента всё выполнялось вполне нормально.
Самый первый столбец обнуляется совсем другим кодом:
Сделано не самым оптимальным кодом, но авторам, видимо, было виднее...Код:seg007:F448 sub_F448: ; CODE XREF: seg007:loc_F42Fp
seg007:F448 ; seg007:F438p
seg007:F448 push bc
seg007:F449 push hl
seg007:F44A ld d, a
seg007:F44B cpl
seg007:F44C ld e, a
seg007:F44D
seg007:F44D loc_F44D: ; CODE XREF: sub_F448+9j
seg007:F44D call sub_F3C0
seg007:F450 inc l
seg007:F451 djnz loc_F44D
seg007:F453 pop hl
seg007:F454 pop bc
seg007:F455 inc h
seg007:F456 dec c
seg007:F457 ret
seg004:F3C0 sub_F3C0: ; CODE XREF: sub_382E+1Ep
seg004:F3C0 ; sub_F448:loc_F44Dp
seg004:F3C0 ld a, (iy+0)
seg004:F3C3 and d
seg004:F3C4 ld c, a
seg004:F3C5 ld a, (hl)
seg004:F3C6 and e
seg004:F3C7 or c
seg004:F3C8 ld (hl), a
seg004:F3C9 ret
seg004:F3C9 ; End of function sub_F3C0
PS: Очень бесит, что по одним и тем же адресам в памяти пишутся разные подпрограммы. Раз - одна записана, через пару вызовов - уже другая и с другим стартовым адресом:v2_dizzy_facepalm::v2_blink::v2_con f2::v2_crazy:Моя не понимать, зачем так писалось...
Завтра попробую понять причину некорректности обнуления памяти - из-за этого в дальнейшем каша на экране. А возможно и отсутствие символов связано с этим...
Область F000..F3FF - непереключаемая область страниц в режиме Ориона-128 и как переключаемая, так и нет в режиме ПРО (зависит от портов управления). В непереключаемой области места мало (плюс там еще системные переменные Монитора), а для межбанковских процедур его надо прилично (особенно это жмёт в режиме Ориона-128) - поэтому там и пишут процедуры одна поверх другой в мизерных не задействованных ничем областях.
Если быть точнее, то это касается всей области F000-FFFF.Цитата:
Сообщение от Error404
Но вот причину такого поведения процессора я не могу понять. Может софтовое ядро проблематичное - сейчас я с ним работаю, поскольку с реальным пока имеются аппаратные проблемы.
Возвращаясь к теме - для компактного варианта платы я не нашел в продаже таких ёмких чипов. Может я что-то не так ищу, ткните носом...Цитата:
Сообщение от Error404
А так - можно обойтись и 1 корпусом. Просто в верхних 2Кб будет размещён ROM1-BIOS, выборка которого будет происходить "автоматом" путём выставления на всех старших адресах (А13 и далее) лог.1 - реализуется подобное достаточно легко. Ну и плату придётся чутка подправить, что бы все адресные ноги были заведены на логику.
И самое главное - что бы чип был достаточно быстрым, поскольку время чтения составляет всего-то около 150ns при максимальной тактовой частоте (по результатам симуляции, по факту надо ориентироваться на ещё меньшую цифру, скорее всего). Вот кусочек захвата как раз с чтением из ROM2 (шаг выборок - 10ns):
https://image.prntscr.com/image/jT-h...Tz6BOwvkyg.png
Из подобной быстрой памяти я нашел только SST39SF040 - в худшем случае скорость доступа составляет 70ns, что покрывает потребность "с запасом". Если надо будет увеличить разрядность - будет проще использовать несколько таких чипов, судя по всему.
PS: И сейчас я всё-таки подумываю об отделении процессора с его логикой и ROM-ом на отдельную платку - тогда будет куда проще в остальном. Ну и на плате видео появится место для "творчества", о котором говорили ранее. ПГД будет проще организовать с такой же МС памяти, по таймингам она вполне удовлетворяет требованиям.
Итак, вопрос по памяти - насколько нужны 3-х и 4-х битный видеорежимы?
Думаю всё-таки отделить основную память процессора от видеопамяти и разместить на плате видеоадаптера 1 чип двухпортовки (64К*16). К этой же памяти будет обращаться и процессор, а всё что выше - на плате процессора чипами обычной SRAM уже, если надо.
Просто для 2-х битовых режимов (стандартных для простого Ориона) хватит и 1 чипа, а для более "широких" режимов смысл от установки 2-х чипов двухпортовки теряется уже - дешевле будет поставить более сложную схему управления обычной статикой и разместить всю память на плате видео (как сейчас).
Всё, платы ушли в производство - видеомодуль и кроссовая.
Картинки для видео:
Скрытый текст
Память поставил двухпортовую, 2 чипа по 64К*16. Порты F8 и FA выполнил на ТМ9 - ИР35 тяжело достать, пришлось отказаться.
Вся схема выполнена на рассыпухе с применением GAL - здесь их 3 штуки (2 для счётчиков и 1 на видеовыход). Дешифрация портов и сигналы управления памятью будут заведены с процессорного модуля, где (скорее всего) будет стоять уже CPLD'шка.
Так же добавил на будущее посадочные места под чип памяти в PLCC32 и 3 чипа в SOIC-16 (для последних разведено и питание).
Так же очень много перфорации на полигоне с "землёй" для уменьшения количества "узких" мест для тока.
Кроссовая плата - для подключения 5-и модулей и подачи питания на них (2 разъёма MOLEX, как для питания IDE).
Пока запланировано 3 модуля - видео, процессорный и периферия (клавиатура, дисковод/эмулятор и прочее. пока ещё даже не думал над ним).
Дополнено: Чип памяти 1.
А какую двухпортовку использовал (маркировка, питалово)? Чипы у тебя уже есть? Почём брал и где? Почему/зачем две двухпортовки?Цитата:
Сообщение от andreil
1 - IDT7028L15PFI, 5В.Цитата:
Сообщение от LeoN65816
2 - Уже идут, если что - возьму у другого продавца.
3 - 45 юаней за штуку, на тао :)
4 - Потому что имеется поддержка видеорежимов Орион-ПРО, где нужно 4 плоскости (32 бита). В текущем варианте все видеоданные идут напрямую с памяти на сдвиговые регистры, без защёлок и прочего.