Просмотр полной версии : Чтение/запись ОЗУ спектрума с помощью интерфейса внешней памяти ОМЭВМ
Добрейший вечерок!
Я тут недавно - начал разбираться с :v2_dizzy_keyboard:Компаньоном 2, сделал удобную плату для вывода всех контактов с системного разъёма на беспаечную макетную плату с помощью проводков для последней. И вот задумался: с помощью /BUSRQ можно же подключить к системе что-то вроде 1816ВЕ51 или at89s52/atmega8515 и т. п. (частоту можно взять с разъёма же) чтобы что-то поделать, например, сабж. Atmega8515 может делать инструкцию за такт и имеет гибко настраиваемый интерфейс внешней памяти (втч можно адресовать 64К) - поделив (или не поделив) частоту с системного разъёма (8МГц) можно добиться нужного. Единственное, как поведёт себя БМК? Посмотрел ZX Spectrum ULA - прямого ответа не нашёл. Посмотрел в интернетах - никто не делал такие вещи, неужели есть какие-то серъёзные подводные камни?
:v2_dizzy_stupid:
- - - Добавлено - - -
К примеру, хочу я загрузить программу в ОЗУ:
Подклчаю ноутбук через недорогой "USB to TTL" UART к Atmega8515,
Отправляю на неё байт программы,
По прерыванию последовательного порта Atmega дёргает /BUSRQ, ждёт /BUSACK (и отсутствие сигналов от БМК),
Записывает байт, отпускает /BUSRQ и ждёт новый байт программы,
И так вся программа.
а если уточнить для чего такое железо? Если контролировать выполнение программы на железе и управлять ходом выполнения, то это классический ICE(in-circuit emulator). Можно отслеживать и активность ULA при желании и любых других частей схемы. Только просто MK даже более мощным, чем перечисленные вами скорее всего не обойтись. Нужно или мастерить адаптер к ПЭВМ через USB, BT или COM/LPT последнее менее предпочтительно, или ставить FPGA производительный, с большой памятью и ядром CPU. Если же делать расширение аппаратных возможностей архитектуры, то это тоже делалось многократно и многочисленными авторами и по памяти, и по функциям( ввод/вывод, звук, графика, отдельные сложные процедуры) и по вычислениям. Можно еще сделать программно-аппаратный комплекс для тестирования отдельных компонентов, узлов любых плат Спектрума на неработающем или не совсем работающем железе. Такого никто пожалуй не делал, кроме Сергея Зонова, мне во всяком случае в публикациях такое не попадалось. Судя по вашему добавлению, Вас интересует скорее последнее, ведь таким способом можно протестировать и любую ячейку памяти на остановленном процессоре. Ну а если работают процессор и память, то уже можно запустить и обычные тесты. Единственное, если удачный интерфейс на компе(ноутбуке), то этим смогут пользоваться даже новички.
Посмотрел в интернетах - никто не делал такие вещи, неужели есть какие-то серъёзные подводные камни?
Ну, как бы есть уже, делал себе, DivGMX (https://zx-pk.ru/threads/27225-divgmx.html) называется. Подключается к шине ZX Bus и может работать как устройство которое тебе нужно. На плате есть HDMI для вывода изображения, USB Host, RTC, SD, SDRAM 16MB, FLASH 8MB. Можно даже выводить отладочную информацию на экран.
http://forum.tslabs.info/download/file.php?id=1739&mode=view
Если же делать расширение аппаратных возможностей архитектуры, то это тоже делалось многократно и многочисленными авторами и по памяти, и по функциям( ввод/вывод, звук, графика, отдельные сложные процедуры) и по вычислениям.
DivGMX представитель этого направления. Для инструмента для сборки, наладки и тестирования он пригоден отчасти, так как последний должен уметь: 1) хотя бы останавливать и запускать впаянный в плату CPU 2)читать произвольную ячейку памяти и/или порт, записывать их кроме ППЗУ 3)запускать в пошаговом режиме программу, до точек останова и по условиям сохраняя трассу в отдельной памяти и это самый примитивный ICE
Давненько была задумка сделать просто переходник на UART для Компаньона 2 и отлаживать с его помощью всякие МК.
Почитав на эту тему, пришёл к выводу, что для классического варианта нужно многовато микросхем (которых у меня ещё и нет) вокруг ВВ51 для для организации UART через него используя доступные с системного разъёма 8 МГц.
Зато у меня есть вышеперечисленные МК, 8515 с ядром AVR аж 3 штуки.
Интерес к 8051 и Ко у меня тоже давно, примерные их возможности знаю, так что мысль о использовании интерфейса внешней памяти МК появилась сама собой.
Сейчас я вижу идею с UART для Компаньона 2 так:
Раз уж подключаем через МК, почему бы не переложить часть вычислений на последний? Пусть МК ложит в память спектрума (как бы в буфер приёма, а может и на клавиатуру, экран? и т. д.) принятый байт (уже, возможно, перекодированный) и, например, поднимает где-то в памяти флаг. В свою очередь, спектрум может ложить отправляемый байт в буфер отправки в своей ОЗУ и поднимет свой флаг (можно и обмениваться прерываниями, но пока не придумал как это сделать по-простому).
А при ровно 8МГц от системного разъёма можно организовать нестандартную высокую скорость обмена данными.
Такая себе реализация, но и на жизнь она пока не претендует :)
Сейчас интерес к UART не столь высок, как к предлагаемому способу обмена данными, ведь через него можно делать много вкусного, например, легко и быстро загружать и выгружать (!) программы спектрума без магнитофона (как в моём добавлении к первому сообщению или с SPI Flash), наверное, можно даже имитировать некоторую периферию, работающую через порты.
Только вот, получается, я работаю с ОЗУ не напрямую, а через ULA, вероятно, настроенную на тайминги Z80 (то есть, скорее всего, для /WR не обойдётся без регистра сдвига с логикой в качестве линии задержки) и время от времени оккупирующую ОЗУ для видео и делающую прочие шалости. Серъёзной помехой я считаю возможное торможение процессора через остановку подачи частоты от ULA, но я не могу найти инфу - Т34ВГ1 тормозит проц через остановку подачи частоты или через /WAIT?
Погуглив ещё немного, нашёл http://zxbyte.ru/at_keyboard_controller_for_zx.htm, там использовался аж прямо 8031, но к системным шинам спектрума напрямую шины 8031 не соединены, вроде. Кстати, скорее всего, устройство связано со Скорпионом (и Сергеем Зоновым).
Там же http://zxbyte.ru/alf_upgrade.htm, но работает только с ПЗУ.
Отладка ULA и процессора, конечно, не помешала бы, но, действительно, не для тех МК это дело. Трогать, собственно, остановленный процессор я не могу, в регистры не загляну :) Ходом управления программы я так особо не поуправляю. А с периферией рабочая система и без отладчика может разобраться (хотя это тоже идея - отладка нерабочей системы), так что я вижу пользу приемущественно с махинациями ОЗУ извне с помощью МК и мелкой логики, а такие монстры как SMD ПЛИС не в счёт :) Но про DivGMX не знал, сейчас буду прочёсывать эту тему.
В моей нескромной фантазии в идеале сейчас получается универсальный инструмент на МК и мелкой логике (то есть довольно дешёвый), не знаю зачем он мне такой универсальный и сделаю ли я его, но идеей стоило поделиться)
Фишка этой темы не сколько в расширении аппаратных возможностей архитектуры Спектрума, сколько в подключении уже реализованного интерфейса внешней памяти различных МК (приемущественно в DIP корпусе - удобно и недорого).
в регистры не загляну :) Ходом управления программы я так особо не поуправляю. А с периферией рабочая система и без отладчика может разобраться (хотя это тоже идея - отладка нерабочей системы), так что я вижу пользу приемущественно с махинациями ОЗУ извне с помощью МК и мелкой логики, а такие монстры как SMD ПЛИС не в счёт :)
ну тогда для начала надо приладить МК к ноутбуку( если он старый - в нем com порт есть, а если новый, то usb переходник). Прилаживать надо так, чтобы ноги у МК от параллельных портов свободными оставались, еще лучше, чтобы были с 3 состояниями. Есть еще всякие платки готовые типа USB - TTL-КMOP на e-Bay, но с их софтом надо отдельно разбираться. Когда у Вас будет софт, чтобы подергать ножками просто так и по таймеру, можно начинать цеплять схемы, в том числе и ZX-Spectrum. Для простоты можно для начала подцепить тот же MК и генерить ему прерырывания или пинами его дергать и интерфейс для ноута(писи) набросать. По поводу того, что содержимого регистров не достать. Записывается в память процедура манипуляции с содержимым регисторов и считывается результат из ячеек памяти, куда их содержимое переписывается. Прерывание генерится извне, процедура выполняется, результат забирается в ноут(писи). Научиться манипуляциям с z80 и ULA лучше не на целом zx компе, а на его частях. Z80 придется изучить в деталях, чтобы понять различия его поведения с регенерируемой( динамической) памятью и статической в зависимости от схемы. Чтобы одним устройством все варианты охватить схему его и программы придется усложнять. Если предпочитаете разрабатывать снизу в верх, то надо идти от простых вариантов к сложным. Если сверху вниз, то весь проект прорабатывать и оставлять сперва заглушки, которые потом заполнять.
Для простоты можно для начала подцепить тот же MК и генерить ему прерырывания или пинами его дергать и интерфейс для ноута(писи) набросать.
Действительно, сработает ли прерывание, если процессор будет как-либо приторможен для генерации видеокартинки?
Прерывание генерится извне, процедура выполняется,
Так можно делать, но имелось ввиду, что остановленный процессор не потыкаешь как через JTAG.
Смотрите, предлагаю следующее - поставить работу Atmega8515 от внешнего генератора по спаду тактового сигнала (то есть сместить работу МК на пол такта!) и подавать половину от 8МГц.
https://b.radikal.ru/b21/1912/75/5230dbafbb02.png (https://radikal.ru)
Это процессор,
https://d.radikal.ru/d14/1912/b5/59139a8aa4a1.png (https://radikal.ru)
А это МК.
Сигнал /WR с МК можно затормозить типа регистром сдвига на двух D триггерах и отдавать логическое объединение результата и оригинального сигнала.
- - - Добавлено - - -
Этот вариант предполагает точную имитацию процессора, освобождая от вникания в заморочки ULA, но принуждает работать МК на частоте процессора и смещённо (что может и +).
Возможно, можно не имитировать процессор так точно и работать на 8МГц, но тогда нужно, действительно, вникать в ULA.
Проблема конкурентной с ULA памятью остаётся.
Для моего понимания ваш вариант очень сложен. HALT State (output, active Low). HALT indicates that the CPU has executed a
HALT instruction and is waiting for either a nonmaskable or a maskable interrupt (with the mask enabled) before operation can resume. During HALT, the CPU executes NOPs to maintain memory refreshes. А вот здесь кажется все просто. Отключаете выбор памяти платы. Подсовываете процессору команду HALT, его регистры "замораживаются"( вот только как регенерируется динамическая память в разных спектрумах надо смотреть через CPU или от внешней схемы) и вы можете спокойно их снять через процедуру обработки прерывания, которую временно запишете в нужную память. Слетает ли при этом картинка на экране? Не суть важно, экранная память остается в неприкосновенности и при желании вы сможете продублировать ее на ноуте(писи). Проблемы с конкурирующим доступом в память от видеоконтроллера и возможно других устройств. Ну чтобы их остановить надо найти узел в схеме где разделяется доступ по сигналу выборки и что-то свое ставить в разрыв. Иначе как от нашего девайса память выбирать? Хотя все-равно если через процессор регистры в память скидываем их (конкурирующие девайсы)надо отключать! Чтобы задавать произвольный адрес и данные потребуется много линий и нужно выяснить у остановленного процессора они в z-состоянии? Если нет, то вся идея летит к черту! А вообще для экспериментов с живым z80 есть более простой девайс, подключаемый к Arduino retro shield z80. Правда там частота прогона далеко не рабочая, посему подозреваю, что и процессор д.б. Full Static Design.
Z-состояние ног процессора я как раз и хочу выявлять по сигналу /BUSACK, который является ответом процессора на /BUSRQ. Механизм /BUSACK, /BUSRQ создан, чтобы без опаски брать у процессора шины.
Кстати, выяснил (из датащита), что у Atmega8515 шины адреса и данных, которые доступны как активируемая по флагу SFR специальная функция двух портов, даже при работе с внутренней памятью дёргает контакты шин адреса/данных, не трогая при этом сигналы /WR /RD, так что по-хорошему нужно использовать шинные формирователи с третьим состоянием, но можно обойтись включением функции интерфейса внешней памяти только по надобности во время /BUSACK.
Идея с /HALT действительно стоящая, но в контексте этой темы нужно сначала разобраться хотя бы с чтением памяти.
Судя по https://faqwiki.zxnet.co.uk/wiki/T34VG1 , Т34ВГ1 во время цикла генерации точек экрана тормозит процессор через /WAIT (сама, не зависимо от каких-либо внешних воздействий), значит можно выявить этот цикл и брать шину сразу после него.
Т34 какой-то у меня в коллекции микросхем есть. Только не знаю рабочий и какого завода производства. И не знаю Full Static Design он ( "заводится" ли с частот близких к нулевым ) или нет. Да и сокет тогда на плату для экспериментов придется ставить с нулевым усилием. Шаг ножек-то у него не буржуйский. Честно говоря мне пока что спаяли плату на 68с03 из той же серии, а остальные лежат пока не распаянные. MEGA 2560 которая нужна для спарки тоже китайская, но вроде завелась под Arduino и с 68с03 retro shild. Там в Arduino в окне com-порта появилась надпись на осмысленном английском. Но вот теперь мне нужно выбрать кандидаты для написания IDE под Win 7 32 bit. Начал с Borland C++. Когда-то мне немцы ставили дистанционно Embracader-о, но в приступе ярости снес тогда его с компа, так как с той халтурой мне подлянку подсунули( дали левую библиотеку ковырять без описания, а я терпеть не могу всякие такие штуки в проектах, когда не предупреждают заранее). И пару лет как-то вообще не было нужды вспоминать про программерские экзерсисы вот и стоял комп чисто под коммерцию и потрындеть. Так что сходу понять, что и в какой мере дружит с Win 7 и при этом имеет доступ к com порту не получается. У Вас же если есть рабочий инструментарий - пробивайтесь. ICE под z80 все-таки как будто-бы кто-то когда-то делал, но сейчас нигде не купить! И эти девайсы редкие, а в реальное железо без них не залезть! Лет тридцать пять тому назад у меня был на рабочем месте ICE80 от комплекса КРАМ, а позже ICE51. Очень облегчали жизнь в эпоху отсутствия многоканальных цифровых осциллографов. Да и литературы никакой на эту тему особо не попадалось так что в виде статьи составит честь любому журналу.
Начал с Borland C++
Кажется, инструментарий для работы с C++ не очень подходит для МК, но если бы я сидел на винде, а не на Linux, то поставил бы AVR Studio, так тоже делают.
Про концепцию - эта задумка (сабж) в моей голове похожа скорее на периферию с Прямым Доступом к Памяти, хочется внедриться в уже имеющуюся систему - Компаньон 2 (на панельке только ПЗУ), но retro shield - тоже весело, хоть и требует целую Мегу - я бы вместо неё применил контроллер в DIP-40 на макетке.
Кстати об осциллографах, посчастливилось мне пощупать свой Компаньон 2 с Т34ВГ1 (через удобную плату для системного разъёма, кстати). Одна из картинок:
https://c.radikal.ru/c17/1912/41/84a896c8bfcd.png (https://radikal.ru)
1 - /WR; 2 - /WAIT.
Видно, что, как и упоминалось в https://faqwiki.zxnet.co.uk/wiki/T34VG1 (но я недопонял при первопрочтении), в Т34ВГ1 /WAIT не вычисляется мудрёной логикой, а подаётся статично миллион раз в секунду таким образом, что процессору доступно только 1/4 общей полосы пропускания. Хе-хе) Это уже облегчает задачу корректной работы с памятью.
Кажется, инструментарий для работы с C++ не очень подходит для МК
я имел в виду инструментарий для работы с МК или ЦП на ПК. Стал копать про Arduino и нагуглил Processing Language. За 15 минут с нуля набросал такой вот скетч:
import processing.serial.*;
Serial serial; // создаем объект последовательного порта
String received; // данные, получаемые с последовательного порта
int flag=1, s=10; // второй параметр отступ по вертикали от верхнего левого угла окна
void setup()
{
size(480, 320); // общий размер окна граф. консоли в пикселях
serial = new Serial(this, "COM33", 115200); // у меня на компе адаптер usb2.0 DEXP поэтому USB-COM порт цепляется
// двузначным номером, скорость подобрал в Arduino по выводу читаемых символов
}
void draw() {
if (flag == 1) {
clear();
flag =0; }
if ( serial.available() > 0) { // если есть данные,
// считываем их и записываем в переменную received
received = serial.readStringUntil('\n');
}
// Настройки для текста
textSize(10); // размер шрифта в пикселях
if (received != null) {
text(received, 50, s);
s=s+10; // след. строка 10 пикселями ниже
}
}
выводит с моего Retro Shild почти ту же инфу, что и монитор порта Arduino в Win7 32 bit
Я задумал подобную штуку токо для моего zanac-ex автомата на основе msx2, вот тема на другом форуме http://www.nedopc.org/forum/viewtopic.php?f=68&t=19660
Со спектрумом сложнее все это дело, потому что есть разные клоны, разные методы торможения процессора и refresh памяти.
Если брать стандартный спекки то у него проц тормозится по CLK процессора и та память что от 0x8000 refresh-ится процессором, т.е. чтобы лазить по ULA памяти нужно это делать синхронизированно с CLK эмулируя поведение z80... ну и надолго шину не отбирать ато refresh обломается
По структуре device-a есть такое соображение, это должен быть MCU типа stm8 или atmega328 с библиотекой V-USB, а с другой стороны у него должен висеть i8255 который бы мог читать шину Z80 и также программировать регистры защелки (ир82?) для компаратора сигналов на шине (чтобы ловить любой pattern на шине и выставлять ~wait_n. Почему i8255 + регистры... потому что потом это дело можно будет и на arduino подрубить и на другой спекки или c64 или LPT или еще куда нибудь. Т.е. нет желания потсаживаться на конкретный MCU, нужно бы создать стандартный код работы с i8255 и железной частью, а вот управлять сценариями работы конечно легче имея условный serial terminal с командами типа как в gdb.
Насчёт выбора МК: я придерживаюсь ОМЭВМ с интерфейсом внешней памяти, поясняю: такие контроллеры как 8031 (кр1816ве31) даже не имеют встроенной ПЗУ и общаются, например, с 27c128 почти как Z80 (см. графики таймингов выше) - через шины адреса и данных (с использованием защёлки для половины адреса, это отнимает у МК 19 контактов). Это происходит аппаратно — прошивка находится во внешней ПЗУ. Таким же образом 8051 семейство может общаться с ОЗУ, и вот это я хочу использовать. Atmega8515 стырила распиновку 8051 и сохранила интерфейс внешней памяти для ОЗУ, при этом выполнение инструкции уже занимает 1 такт (8051 — 12 тактов). Поэтому сейчас я надумал следующий алгоритм: при приёме байта по UART Atmega поднимает BUSRQ, ждёт BUSACK, ждёт, когда т34вг1 (что есть, с тем и работаю) попытается приостановить проц через WAIT, после с помощью nop выбирает момент перед возвратом WAIT (см. осциллограмму) и использует интерфейс внешней памяти для записи/чтения байта, возвращает шину процессору, тот рефрешит память пока atmega ждёт следующий байт. Всё на ассемблере. В принципе, можно сделать прерывание атмеги по iorq Z80, тогда это будет как бы как периферия. В моих мыслях сабж виднеется как программа-монитор спектрума через UART, через который можно помимо прочего удобно загрузить программу напрямую в ОЗУ спектрума.
Я задумал подобную штуку токо для моего zanac-ex автомата на основе msx2, вот тема на другом форуме http://www.nedopc.org/forum/viewtopic.php?f=68&t=19660
Со спектрумом сложнее все это дело, потому что есть разные клоны, разные методы торможения процессора и refresh памяти.
Если брать стандартный спекки то у него проц тормозится по CLK процессора и та память что от 0x8000 refresh-ится процессором, т.е. чтобы лазить по ULA памяти нужно это делать синхронизированно с CLK эмулируя поведение z80... ну и надолго шину не отбирать ато refresh обломается
По структуре device-a есть такое соображение, это должен быть MCU типа stm8 или atmega328 с библиотекой V-USB, а с другой стороны у него должен висеть i8255 который бы мог читать шину Z80 и также программировать регистры защелки (ир82?) для компаратора сигналов на шине (чтобы ловить любой pattern на шине и выставлять ~wait_n. Почему i8255 + регистры... потому что потом это дело можно будет и на arduino подрубить и на другой спекки или c64 или LPT или еще куда нибудь. Т.е. нет желания потсаживаться на конкретный MCU, нужно бы создать стандартный код работы с i8255 и железной частью, а вот управлять сценариями работы конечно легче имея условный serial terminal с командами типа как в gdb.
там по сылкам разработки ИНЭУМ для СМ1800 а были еще ВНИИЭМ для 8080 и 8031(ПС01 И ПС04) Здесь же надо их усовершенствовать если возможно. Для чего необходимо переводить в z состояние выводы z80 в любой схеме включения и тормозить его, не останавливая циклов refresh для дин. памяти а внешним процессором(или его адаптером) полностью контролировать эти шины! Насчет "просто приостановить"...а что там с шинами и refresh циклами? И еще ...а если CPU не full static design?Тогда не очень то с CLK поиграешься
Преимущество связи по UART в этом случае в том, что за один раз можно класть в спектрум только один байт, а между приёмом байтов отдавать шины обратно процессору, то есть можно не думать про refresh. Atmega8515 на 3,6864Мгц сможет положить байт в память быстро, тактов за 20.
Про клоны, думаю, время торможения через clk можно как-то отслеживать с помощью счётчика МК.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot