Вид для печати
К сожелению, сайт zxnext.narod.ru уже давно не обновляется и я потерял надежду увидеть схему этого клона. Судя по описаниям, которые я встречал, там используется второй Z80 как "законодатель" архитектуры.
Нет ли возможности выложить его схему или ссылку где можно посмотреть? Заранее благодарен.
Напиши мне в мыл. Я тебе пришлю.Цитата:
Сообщение от MakSer
А можно и мне отправить на keeper[гггав]webbuilding.in.ua
Все заявки на мое мыло (указано на сайте в моей подписи).Цитата:
Сообщение от Keeper
СОрри пока не отправил! ОТправлю сегодня завтра.
Архив здесь: www.nedopc.com/zxnext.rar
Качество правда неважное.
А интересно не осталась прошивка под видео проц. Все таки оригинальная разработка. Z80 в качестве видеоконтроллера.Цитата:
Сообщение от CHRV
Дык кажись в теме Расскажите о ZX Next http://zx.pk.ru/showthread.php?t=112 должна быть . Пока приаттачу .
З.Ы. Она есесно не кряканая . И адреса запутаны .
http://zx.pk.ru/showthread.php?t=112
Вот хороший тред за сабж :v2_clap2:
Цитата:
Сообщение от Orionsoft
Спасибо, конечно - все читать времени нету, да интернет у меня не резиновый, так чем закончилось история с прошивкой? Надеюсь, никого этим не обижу, мне чисто с образовательной целью.
Походу ничем :\
Может я и ошибаюсь, но с коды команд читаются из первого килобайта, а данные, если таковые имелись из второго. Тем самым если какой нибудь переход отличный от rst будет закодирован, ну и чтение с параметрами. Опять же могу и ошибаться.Цитата:
Сообщение от fan
В принципе логике это подается - в тех местах, где должна быть команда, во второй половине пзухи нулик.
Ошибаетесь :) На ПЗУшке перепутаны адресные линии:Цитата:
Сообщение от Mick
VCPU -> ROM
A0 = A1
A1 = A2
A2 = A3
A3 = A4
A4 = A5
A5 = A6
A6 = A10
A7 = A9
A8 = A8
A9 = A0
/M1 = A7
Старшие адреса
A11 = NMI
A12 = KSYN
A13 = в схему...
A14 = BLANK
A15 = FLASH
Да, действительно, на схеме ножки ПЗУ пронумерованы не как в справочнике, это меня и сбило с толку. Как приятно, что я ошибся :)Цитата:
Сообщение от Keeper
Добавлено через 12 часов 5 минут
Немного поразвлекался с адресами и вот составил некую таблицу. Короче ПЗУшка разбивается на блоки по 64 байта - 32 блока.
Блоки
M1 =0 M1 =1
(считываются коды команд) (считываются данные)
1. 000h - 07Eh 17. 080h - 0FEh
2. 400h - 47Eh 18. 480h - 4FEh
3. 200h - 27Eh 19. 280h - 2FEh
4. 600h - 67Eh 20. 680h - 6FEh
5. 100h - 17Eh 21. 180h - 1FEh
6. 500h - 57Eh 22. 580h - 5FEh
7. 300h - 37Eh 23. 380h - 3FEh
8. 700h - 77Eh 24. 780h - 7FEh
9. 001h - 07Fh 25. 081h - 0FFh
10. 401h - 47Fh 26. 481h - 4FFh
11. 201h - 27Fh 27. 281h - 2FFh
12. 601h - 67Fh 28. 681h - 6FFh
13. 101h - 17Fh 29. 181h - 1FFh
14. 501h - 57Fh 30. 581h - 5FFh
15. 301h - 37Fh 31. 381h - 3FFh
16. 701h - 77Fh 32. 781h - 7FFh
Блоки 1...8 и 17...24 сформированы из четных байт, остальные из нечетных. Вроде бы так
Кроме того еще и биты данных запутали, тоже не совпадают с ногами ПЗУ по справочнику.
Вот пораскидывал битики данных, которые также перекрутили.
VCPU VROM
D0 => D4
D1 => D3
D2 => D2
D3 => D6
D4 => D7
D5 => D0
D6 => D1
D7 => D5
Надо думаю накидать, разворачивалку ПЗУ в нормальное линейное простанство, посмотреть что же там такое интересное. :)
Да уж, вот у людей голова работала, надо же до этого додуматься, респкет разработчикам.
Занимаюсь :) Кстати сворачивалка тоже будет. Пока сильно торможу т.к. на си писал последний раз 1.5 года назад, подзабыл, да и Dev-Cpp какой то немного не такой :)Цитата:
Сообщение от Mick
ИМХО должны быть готовые (ведь достаточно часто в девайсах такой изврат применяется), но нарыть не смог , ибо понятия не имею как они по научному называются %(
Вот попробуй посмотри , я накидал вчера маленькую программу - возможно я и ошибся где то, поправьте - катал наскорую руку. По крайней мере что то я прошивку с первого раза не понял. :(Цитата:
Сообщение от Keeper
Вот попытался получить прошивку. С ходу не понятно - в принципе не разбирался так особо со схемой. Возможно и ошибся где то. Так что ждем еще одну для сравнения.
Чет с моей совпадений мало :) У меня пока сворачивание не дает исходную прошивку, где-то я набажил... Буду разбираться...Цитата:
Сообщение от Mick
Кстати для проверки: первый байт исходной прошивки 0xF3 после перестановки битов у меня получается 0xF9 в Вашей первый байт 0xBB. Надо смотреть кто из нас не так переставляет адресные линии или разряды данных...
Закончил утилиту.
Вот и я говорю - что то она мне не нравится(это я про свою) :)Цитата:
Сообщение от Keeper
Наверное что я забыл как всегда :)
Смастерил свою прогу. Сначала результаты были своими... :(. потом помедититровал над адресами (оказалось что сделал все наоборот), получилось все как у Mick. Потом помедитировал над данными, и оказалось что тоже все наоборот сделал... В итоге результат как у Keeper.
Подскажите, а чем тактируется Video Z80? я не нашел ~Q2
На втором листе схемы вывод 8 одного из инверторов D1 = /Q2Цитата:
Сообщение от MakSer
Тактовая частота 3.5МГц :)
Я тоже нашел ошибку - да прошивка получается как у Keeper. Короче ошибся я с направлением преобразования битами, вместо декодера получился кодер :) Посему я свою прошивку удалил.Цитата:
Сообщение от molodcov_alex
Перепутанные адреса и данные в ZX-Next это не защита. Очевидно, что перекодировать назад такую прошивку большого труда не составляет.
Причина такого решения в том, что при разводке платы ставилась задача уложиться в шаг 1,25 мм между дорожками. В начале 90-х это было необходимо, поскольку изготавливать платы более высокого класса было дороже. Да и настраивать/ремонтировать платы с близко расположенными дорожками сложнее. Поэтому когда я разводил плату, я спросил у Леонида Ермакова (автора прошивки Next ROM Video), имеет ли для него значение порядок следования адресов-данных. Он ответил, что разницы нет. И я развел адреса и данные как было удобнее.
Использование сигнала М1 тоже не являлось защитой. Причина, по которой сделано именно так в том, что на адресных линиях Z80 в видиопроцессоре ZX-Next формируются различные сигналы. Поэтому, занимать лишние адреса под память видеопроцессора было нельзя. Их и так не хватало. Но меньшее число адресов означает меньший объем адресуемой памяти, а это тоже ограничение (на объем ПЗУ).
Решение с M1 позволяло использовать память команд и данных отдельно. То есть Z80 в такой схеме может адресовать 64К команд плюс 64К данных. Как способ расширения адресуемой памяти в ZX Spectum это не годится. Но для видеопроцессора такое решение очень подходило.
Сама схема видеопроцессора в ZX-Next очень простая: Z80, ПЗУ и два порта. Все. А гибкости очень много: можно выбирать видеопамять в любой последовательности, иметь любое (программируемое) количество строк в кадре, положение INT и экрана. А главное, все это не зашито железно, и не требует паяльника в случае доработок.
Вот несколько примеров, где видеопроцессор ZX-Next просто идеально подходит:
1.«Пентагоновские/не Пентагоновские» развертки». Нужно 320 строк вместо 312 для корректной работы дем – нет проблем!
2.Требуются времянки специфичные для фирменных машин (положение экрана и INT) – опять же количество строк, положение экрана, все задается программно.
3.Даже для введения разработанного (намного позднее) Alco графического режима 384x304 в ZX-Next не нужен паяльник. Достаточно перепрограммировать код в ПЗУ.
Причем, для управления этими видеорежимами не нужны дополнительные порты ZX Spectrum. Команды видеопроцессору можно передавать, используя оговоренные последовательности HALT от основного Z80.
Да тут собствеено и так ясно, что так просто никто не защищает, посему я например изначально не считал это защитой. Для меня интерес чисто любознательный, как раньше люди ухитрялись вытворять такие чудеса. Вдруг какая нибудь идея да и пригодиться :)Цитата:
Сообщение от Conan
во-во сделай то-же на 6845Цитата:
Сообщение от Mick
Надоже кто то отозвался, а блин опять свет в комнате забыл включить. Привет коша, вообще завидуют молча если сказать нечего.Цитата:
Сообщение от Black_Cat
А вообще я идеями не брезгаю и люблю творческий процесс. Вот назло тебе сделаю новый комп с 6845 девайсом.
чему завидовать :) ? У меня уже ZX-NEXT'ы JTNовские были если уж на то пошло, дык я себе ни одного не оставил. А уж чудом а-ля АТМ-хх меня точно не соблазнишь :)
Единственное в какойто мере оправданное применение 6845 в Спеке может быть в видеосканере по типу как в ZX-NEXT'е, о чём я тебе собсно и сказал :). Ума хватит сделать - дык и сделай :) , а назло или ещё как - мне побарабану :)
Ну это понятно, но согласитесь что разбираться с прошивкой намного удобней если адреса и разряды данных не перепутаны.Цитата:
Сообщение от Conan
Я немного посмотрел прошивку и не понял ровным счетом ничего :( Пробовал загружать в кеш в unreale но в начале получил безконечный цикл... Я пока думаю чего б придумать :)
Вот это интересно. В текущей прошивке это используется? Еще Вы упоминали об отдельной истории с генерацией NMI может раскажете?Цитата:
Сообщение от Conan
2CHRV: Роман, вы не могли бы ещё пару раз считать прошивку и выложить дампы?
2Moderators: Может есть смысл объединить этот топик с уже существующим "Расскажите о ZX Next" Тогда вся инфа будет в одном месте.
Ну как по твоему его хочу пользовать, если ты просматривал мои потуги в теме про 6845 контроллер, он собственно и занимается генерацией видео. А здесь говоря про идеи, это подразумевались - как програмные алгоритмы, так и схемотехнические. Если тебе интересно пообщаться о применении 6845 в Спеке, то есть на то тема специальная. А здесь вроде тема про другое.Цитата:
Сообщение от Black_Cat
Добавлено через 1 минуту
Я думаю, там надо глобально дизассемблировать для начала, хотябы получить исходный текст, чтобы совместно со схемой уже рассматривать.Цитата:
Сообщение от Keeper
Думаю что лучше разбираться постепенно. А то вот разные подводные камушки будут попадаться...Цитата:
Сообщение от Mick
Код:0000 LD SP,HL
0001 LD A,I
0003 RETNZ
0004 IM 2
0006 LD B,A
0007 DJNZ 0008 тут dnjz идет на следующий байт
0008 RST38 который 0xFF - при дизассемблировании
будет бок, все равно дамп смотреть надо
0038 JP (HL) hl = 0
Цитата:
Сообщение от Keeper
Ты не забывай, что еще надо отслеживать M1, а это значит что байт данных параметра для DJNZ будет из другой области памяти, а точнее из 408h => FEh. Посему может и непонятно. Они же хитрецы не звбывай:)
Так что эмулятор вряд ли поможет, тут наверное ручками придется.
P.S. Только что заметил неточность, вместо байта EFh, написанного мной должен быть байт FEh. Исправил это недоразумение. Извиняюсь
Правильное замечание. Но прежде всего надо осознать несколько ключевых подходов к программированию в такой системе:Цитата:
Сообщение от Mick
1. Всегда следим за шиной адреса. Ибо все, что на нее попадает, может либо вызвать NMI, либо отразиться на экране. То есть надо представлять временные диаграммы (с точки зрения тактов и ША) для КАЖДОЙ КОММАНДЫ.
2. Ключевым элементом является переключение ША из «0» в «1» и наоборот. С первого взгляда вроде бы все просто: любой JP или JR. По факту сразу же вылезает IR. Поэтому единственной парой команд (из всех, что есть у Z80) которые могут использоваться для этого будет:
LD I,A
JP (HL)
Других однозначных последовательностей не существует. Разумеется, перед подобным переходом надо подготовить значения в регистрах.
3. В видеопроцессоре нет ОЗУ. Это значит, что все динамические данные передаются только через регистры Z80. Насколько я помню, задействованы практически полностью оба набора (основной и альтернативный).
4. По поводу возникновения NMI подробно расспросил JTN, ответы есть в теме «Расскажите про ZX Next».
5. Видеопроцессор регенерирует ОЗУ. Это значит, что даже вне экранных адресов он перебирает адреса в ОЗУ. Перед тем, как будет сгенерирован Reset для основного Z80, видеопроцессор уже проводит несколько (не помню уже сколько) циклов регенерации.
6. Надо уточнить (уже не помню) изначальные значения регистров, включая флаговый.
Вот тут я долго сомневался, я почему-то решил что /M1 генерится для всех байтов команды а не только для КОП. Спасибо.Цитата:
Сообщение от Mick
Извиняюсь за тормоза, но я последний раз использовал асм Z80 в году эдак 2002 (xas rulez!!!) По-этому буду постепенно вспоминать :)
Эмулятор поможет т.к. для развернутой прошивки адрес данных получается добавлением 1024 к адресу следующего(их) байтов :) Увы, удобней врядли получится :)
Добавлено через 10 минут
Я пока в первых байтах прошивки, там вроде NMI и INT не грозят :)Цитата:
Сообщение от Conan
Я ещё повторю вопросы, интересно для общего развития: зачем /HALT CPU завели на D7 VCPU и зачем инверсный Q4 завели на D0 VCPU? Про NMI вы написали что это отдельная история, которую хотелось бы прочитать, хотя я снова перечитаю тему "Расскажите про ZX-NEXT" может я что-то пропустил.
Это сделано для управления видеопроцессором. Через эту цепочку можно передавать различные команды в виде последовательностей HALT с CPU. Изначально планировалось использовать для запроса номера прошивки (как часть защиты, связывая номера в NEXT ROM Video и ROM CPU). Но потом от этого отказались, хотя кусок кода возможно и остался в ПЗУ. Практически использовалось для задачи видеорежима, когда требовалось переключение между 640*200 и 640*400 (интерлейс). Что зашито в конкретной ПЗУ сказать сложно.Цитата:
Сообщение от Keeper
Q4 заведен на D0 VPU для синхронизации. Дело в том, что видеопроцессор должен быть синхронизирован до такта с другими элементами компьютера (например, записью данных в регистр атрибутов и сдвиговой регистр пикселей). Алгоритм синхронизации очень простой, нужно лишь обнаружить момент переключения Q4 с помощью IN, а затем в зависимости от фазы выровнять кол-во тактов до определенного места в программе.Цитата:
Сообщение от Keeper
Есть и вторая функция у Q4: VPU отслеживает его (блокировку) для перехода в CGA (640*200).
Про NMI вот тут JTN спрашивал:Цитата:
Сообщение от Keeper
http://zx.pk.ru/showpost.php?p=3717&postcount=60
P.S. INT на VPUприходит постоянно, как обрабатывается сказать не могу – код не я готовил. Изначально в основном цикле прерывания были запрещены. Скорее всего, только при старте используется.
Схемка с описанием .
Прошивки тут .