Hardware темы, которых TSL боится :)
Posted: Thu, 21.05.2015 13:25:13Hardware темы, которых TSL боится 
Буду выносить сюда hardware темы, обсуждение которых в соответствующем разделе TSL боится
1. Совместимость с TFT мониторами.
1) Суть проблемы: старые матрицы выпускались токо под кадровую 60Гц, новые матрицы уже выпускаются под кадровую до 48Гц, и в отрасли тенденция к разработке матриц с кадровой до 30Гц. Ессно, новые матрицы дороже и реже, но они всёж есть. Т.е. если не покупать самый дешёвый хлам, то выше вероятность найти монитор поддерживающий 48Гц кадровой.
2) Суть проблемы 48Гц в ZXEvo: конечно же суть в ламерстве NedoPC, её разработавшей . Предыстория ZXEvo: CHRV мечтал втюхать спектрумистам ATM под видом Спектрума , поэтому переделал развёртки ATM под Пентагон . НО!!!!!! Реальный Пент 128 имел кварц не на 14МГц, а на 14,3МГц, что давало ему кадровую ~50Гц!! NedoPC это проигнорировала, и создала исскусственно проблему 48Гц, с которой все, кто купил девборду ZXEvo, и юзают развёртки Пентагона теперь маются .
Решение проблемы для мониторов всёж поддерживающих 50Гц, но не поддерживающих меньше (такие есть) - замените кварц 14МГц на 14,3МГц, а лучше на 14,336МГц . Ессно, при этом AY будет играть чуть выше , но в реальном Пенте128 он так и играл . К тому же в оригинаальном Спектруме128 тактовая выше 14МГц, т.е. в отечественных 3,5МГц клонах частота AY чуть занижена, а в Пенте128 чуть завышена, так что получаемое отклонение от оригинала для кварцев 14МГц/14,3МГц +/- сопоставимо .
2. Совместимость с шиной NemoBus.
Шина NemoBus - дефакто стандарт современного отечественного спектрумостоения, соблюдение которого гарантирует безконфликтную работу периферийных устройств. Шина NemoBus стандартизирована, и подробно описана во всех своих версиях, включая перспективные, документацию можно взять здесь: http://zx.clan.su/forum/7-82-1 . Непрерывно проводится работа по её поддержке и развитию.
1) Проблемы совместимости девборды ZXEvo со стандартом NemoBus.
Предистория.
Т.к. ZXEvo разрабатывала NedoPC, при том разрабатывала не под архитектуру Спектрума, то и с поддержанием на аппаратном уровне спектрумовских стандартов группа NedoPC не заморачивалась. Поэтому шина периферийных устройств девборды ZXEvo физически не может поддерживать все возможности шины NemoBus, и соответственно, девборда ZXEvo не в состоянии в полной мере корректно воспроизводить работу отечественных клонов спектрума с шиной NemoBus. Попытка группы NedoPC представить вырожденную ими шину периферийных устройств как ZXBUS (название шинного интерфейса оригинального компьютера ZX Spectrum 16/48k) - не более чем ещё одна попытка CHRV и группы NedoPC ввести в заблуждение пользователей компьютера Спектрум, так же, как и в случае самоназвания PentEvo для конфигурации развития CP/M компьютера ATM-2. Т.е. это очередная попытка обмана и манипуляции доверием спектрумистов со стороны CHRV и NedoPC, с целью втюхать им некое развитие ATM под видом Спектрума.
Решение.
Не все, но некоторые из отсутствующих сигналов можно допаять самостоятельно, например сигалы CLK (A8), 14MHz (A5), часть других сигналов возможно генерировать со стороны периферийных устройств втыкаемых в шину.
2) Проблемы совместимости конфигураций PentEvo и TSEvo со стандартом NemoBus.
Даже те сигналы, которые NedoPC завела в ZXEvo, не гарантированно соответствуют стандарту NemoBus в существующих конфигах PentEvo и TSEvo, что приводит к невозможности работы части периферийных устройств стандарта NemoBus с этими конфигами.
Основной проблемой несовместимости данных конфигов со стандартом NemoBus является несоблюдение ими основополагающего принципа работы шины NemoBus - метода арбитрирования захвата портов. Из-за этого часть периферийных устройств прекрасно работающих на клонах спектрума с шиной NemoBus, не могут работать с этими конфигами на ZXEvo.
Решение.
Изучить спецификацию стандарта NemoBus, и привести данные конфиги в соответствие со стандартом NemoBus.
P.S. От разработчиков этих конфигов приходилось слышать, что дескать это невозможно ибо приведёт к диким задержкам и т.д. . Насамделе это не более чем попытки оправдать своё нежелание править конфиги, ибо в основном все вопросы решаемы .
3) Проблемы переноса конфигов PentEvo и TSEvo на другие develpment board.
Совершенно необязательно при портировании конфигов, тащить на другую девборду и все их баги и недоделки. Так например для адаптера внешней шины ReVerSe вполне реально исключить все недостатки присущие конфигам PentEvo и TSEvo, что позволит пользователям иметь выбор между корректно работающей в соответствии со стандартом NemoBus шиной периферийных устройств девборды ReVerSe и кривым поделием группы NedoPC.
3. Совместимость по дешифрации портов.
Конфиг PentEvo, а так же созданный под его влиянием конфиг TSEvo, изначально идеологически позиционировались именно как архитектуры предназначенные для демомейкинга, что обусловило выбор таймингов Пентагона в их архитектуре. Но требования к архитектуре компьютера предназначенного для демомейкинга не ограничиваются его таймингами. Важным элементом демомейкерской архитектуры компьютера так же является максимальное приближение к особенностям упрощённой дешифрации оригинального ZX Spectrum 128, что позволяет использовать такую фичу, как обращение одновременно к нескольким портам для экономии тактов процесора.
Как ни парадоксально, но именно ориентированные якобы на демомейкинг архитектуры PentEvo и TSEvo имеют изначальную концептуальную ущербность не позволяющую реализовать заявленную их авторами идеологическую направленность архитектуры на демомейкинг, и состоящую в полной короткой дешифрации базовых системных портов #FE и #7FFD, и портов AY, что не позволяет использовать одновременное обращение к этим портам.
Предистория.
Полная короткая дешифрация базовых системных портов #FE и #7FFD в PentEvo обусловлена тем, что группа NedoPC в силу характерной для неё патологической инертности мышления (в силу которой NedoPC уже 9 лет упорно лжёт, отрицая совершённую ими изначально ошибку, при определении принадлежности платформы ATM к клонам Спектрума) так и не смогла осилить архитектуру шины NemoBus, являющуюся стандартом отечественного спектрумостроения, и без реализации которой принципиально невозможно обеспечить оригинальную дешифрацию системных портов #FE и #7FFD при одновременной поддержке большого количества новых портов.
Полная же короткая дешифрация базовых системных портов #FE и #7FFD в конфиге TSEvo обусловлена тем, что TSL тупо доверился "авторитету" NedoPC, и скопировал её кривую шину со всеми вытекающими из этого проблемами.
Решение.
Если не тупить патологически, как это принято в NedoPC, а хоть на минуту включить мозги, то при наличии NemoBus все проблемы решаются элементарно. Например для TSEvo может быть рекомендована следующая конфигурация приоритета захвата адресного диапазона портов:
1) Высший приоритет захвата портов отдаётся TS видеоакселератору (диапазон #xxAF), и включенному ему в параллель первому слоту. При необходимости сюда же можно отнести и порты ZSD (но обязательно при полной 16-ти дазрядной дешифрации порта #0077).
2) Следующий приоритет отдаётся второму слоту (потом третьему, если их три).
3) Следующий приоритет отдаётся портам периферийных устройств: NemoIDE (в его оригинальной дешифрации), BDI, кемпстон мыше и джойстику, RS232, #EFF7, и портам часов.
4) Следующий приоритет отдаётся системным портам #FE, #7FFD и портам AY.
5) И наконец самый низкий приоритет отдаётся несуществующему "порту" #FF, доступ к которому осуществляется вообще без какой либо дешифрации, а исключительно по отсутствию захвата диапазона портов всеми реальными устройствами.
4. Совместимость по шине данных.
Предистория.
Архитектура Спектрума задаёт обязательную подтяжку шины данных в единицу с помощью резисторов, и если этого нет, то это однозначно НЕ СПЕКТРУМОВСКАЯ!! архитектура. На резисторной подтяжке шины данных завязана работа так называемого порта #FF, из которого на бордюре читается #FF, а так же работа маскируемых прерываний. В отличие от клонов Спектрума, девборда ZXEvo не имеет этого ключевого элемента аппаратной архитектуры Спектрума - резистивной подтяжки шины данных в единицу. Вместо этого по определённому условию на шину данных выдаётся #FF из FPGA... Трудно определить истинную причину такого странного аппаратного решения со стороны NedoPC - то ли CHRV забыл развести матрицу резисторов на плате, а потом сделал вид что так и задумано, то ли lvd бездумно содрал конфиг с чего-то, что не имело внешнего процессора и шины расширения, и соответственно подтяжка эмулировалась внутри FPGA. В любом случае в NedoPC серьёзно лоханулись, а принимая во внимание эпопею с уже девятилетним враньём CHRV по поводу того как они в NedoPC лоханулись с определением принадлежности ATM к клонам Спектрума - то собсно ожидать от них правды и по этому поводу не приходится .
Хотя конечно если рассуждать с точки зрения что PentEvo как клон ATM не является клоном Спектрума, то отсутствие одного из ключевых элементов Спектрумовской архитектуры в ZXEvo собственно не должно вызывать вопрососов - ну не Спектрум оно, что с него взять, имеет право не иметь подтяжки
Итак, рассмотрим чем же грозит простому юзеру такое странное решени от NedoPC, которое так же бездумно скопировано и в конфиге TSEvo от TSL.
1) Работа с вектором прерывания.
Увы, но о том, что внешние устройства в соответствии со спектрумовской архитектурой имеют право выставлять свой вектор прерывания, в NedoPC очевидно не знают, а поэтому, как в конфиге PentEvo, так и в базирующейся на её исходниках TSEvo их авторы зарубили эту возможность на корню.. При попытке выставить внешним устройством вектор прерывания, есть вероятность, что сдохнет либо это устройство, либо FPGA.
2) Работа при захвате портов.
Зачастую юзеры, введённые в заблуждение CHRV & Co., и наивно полагающие что имеют дело с клоном Спектрума, пытаются воткнуть в ZXEvo ёлку для клона Спектрума. Увы, втыкать в НЕСПЕКТРУМ ёлку от клона Спектрума - это не совсем безопасное занятие. Суть проблемы в том, что в конфигах базирующихся на исходниках PentEvo, если от внешних устройств не приходят сигналы IORQGE в цикле чтения, то FPGA выставляет на шину #FF. Но!! При использовании ёлки имеющей на борту свой собственный арбитр приоритетов, IORQGE от устройства воткнутого в эту ёлку задерживается её арбитром. Поэтому может возникать ситуация, когда устройство честно выставило IORQGE и собственные данные на шину, но IORQGE из-за задержки в арбитре ещё не дошло до FPGA и поэтому FPGA сама выставляет в это же время на шину #FF. Опять же возникает конфликт на шине, с определённой вероятностью могущий привести к выходу из строя либо периферийного устройства, либо FPGA. Особенно не рекомендуется втыкать в PentEvo/TSEvo не исправленный в соответствии с рекомендациями http://zx.clan.su/forum/8-118-777-16-1387740869 , кривой старый GS, активно размножаемый zorel'ом вместе со всеми его схемотехническими багами, который умудряется выставлять данные на шину ещё до прихода сигнала RD/, а IORQGE формировать после прихода IORQ/, и гарантированно вступающий в конфликт с FPGA.
Ничего подобного в клоне Спектрума произойти не может принципиально!
Решение.
Самое простое - изменить конфиг таким образом, чтоб шина данных FPGA работала в режиме открытого стока. Правда при этом возможно данные от FPGA несколько потеряют в крутизне фронтов. Насколько это критично надо экспериментировать. Ессно генерилку #FF надо выкинуть напрочь (мож даже от этого экономия какя получится ).
Если крутизна фронтов будет неудовлетворительной, то оставив тристабильной шину данных FPGA, можно просто подтянуть её внешними резисторами к +3,3В. Для Z80 это вполне штатное включение резисторной подтяжки, о чём судя по всему в NedoPC не знают .
P.S. Т.к. NedoPC и TSL архитектуру Спектрума знают весьма поверхностно, то акцентирую внимание на том, что в архитектуре Спектрума внешнее устройство имеет право выставлять вектор прерывания не целиком байтом, а отдельными разрядами. Поэтому, если вы засунете в FPGA свой собственный контроллер прерываний, то работать на шину он обязан так, как будто в режиме открытого стока. Т.е. единицы на шине данных должны формироваться резисторами подтяжки, а не буферами FPGA. Например для TSEvo при формировании вектора прерывания, в ноль будут дёргаться только либо D1, либо D2, а остальные разряды должны быть в Z-состоянии, ессно при подтяжке шины данных резисторами в единицу.
5. Совместимость по биперу.
Биперная музыка для спектрумовской сцены - это один из её базисов. Бипер наряду со спектрумовским экраном, это то, что было, есть, и будет всегда. Даже AY вторичен и не обязателен, в то время как бипер обязателен для каждого клона Спектрума, тем более для компьютера претендующего на использование в качестве сценерской платформы. Тем не менее, как это ни странно, но в довольно большой части клонов бипер схемотехнически реализован неправильно, что, естественно приводит к неправильному звучанию биперных композиций. Не стал исключением такой кривой реализации бипера и компютер ATM, передавший по наследству эту кривизну своему эволюционному развитию воплощённому по задумке группы NedoPC в девборде ZXEvo и конфиге PentEvo. Суть же проблемы с реализацией бипера состоит в том, что в оригинальном Спектруме сигнал формируется не единственным разрядом D4 #FE, а двумя разрядами D3,D4 #FE имеющими разные весовые коэффициенты, и образующие нелиейный 2х битный ЦАП. Т.е. в оригинальном Спектруме биперный сигнал имеет отнюдь не два уровня 0 и 1, как это реализовано в PentEvo, где D3,D4 #FE просто складываются по модулю два. Что характерно, конфиг PentEvo многократно использовали как компомашину на некоторых пати . Можно только представить что там звучало вместо нативной спектрумовской биперной музыки, и о каком уровне пати можно говорить при использовании такой кривой реализации бипера . Конечно, не все биперные композиции используют оба разряда D3,D4 #FE, но есть такие, которые воспроизводят разные звуковые каналы через разряды D3,D4. Примером использования обоих разрядов D3, D4 порта #xxFE для генерации звука может служить игра Manic Miner, где через разряды D3, D4 воспроизводятся разные звуковые каналы. Поэтому в клонах, в которых для вывода звука используется только один из разрядов, или оба разряда смешиваются с одинаковыми весовыми коэффициентами, или как в PentEvo складываются по модулю два, мелодия искажена, т.к. часть сигналов теряется. Эта проблема оставалась длительное время не замеченной т.к. что бы заметить разницу надо иметь кроме клона ещё оригинальный Спектрум, и при этом обладать ещё и музыкальным слухом. Те же, кто имел дело только с криво реализованным бипером так и оставались в неведении, что в оригинале музыка звучит совсем иначе.
Можно ли это исправить конкретно для девборды ZXEvo? Можно конечно попытаться применить ШИМ для бипера, но гарантировать аутентичность звука при этом нельзя.
Буду выносить сюда hardware темы, обсуждение которых в соответствующем разделе TSL боится
1. Совместимость с TFT мониторами.
1) Суть проблемы: старые матрицы выпускались токо под кадровую 60Гц, новые матрицы уже выпускаются под кадровую до 48Гц, и в отрасли тенденция к разработке матриц с кадровой до 30Гц. Ессно, новые матрицы дороже и реже, но они всёж есть. Т.е. если не покупать самый дешёвый хлам, то выше вероятность найти монитор поддерживающий 48Гц кадровой.
2) Суть проблемы 48Гц в ZXEvo: конечно же суть в ламерстве NedoPC, её разработавшей
. Предыстория ZXEvo: CHRV мечтал втюхать спектрумистам ATM под видом Спектрума , поэтому переделал развёртки ATM под Пентагон . НО!!!!!! Реальный Пент 128 имел кварц не на 14МГц, а на 14,3МГц, что давало ему кадровую ~50Гц!! NedoPC это проигнорировала, и создала исскусственно проблему 48Гц, с которой все, кто купил девборду ZXEvo, и юзают развёртки Пентагона теперь маются .Решение проблемы для мониторов всёж поддерживающих 50Гц, но не поддерживающих меньше (такие есть) - замените кварц 14МГц на 14,3МГц, а лучше на 14,336МГц
. Ессно, при этом AY будет играть чуть выше , но в реальном Пенте128 он так и играл . К тому же в оригинаальном Спектруме128 тактовая выше 14МГц, т.е. в отечественных 3,5МГц клонах частота AY чуть занижена, а в Пенте128 чуть завышена, так что получаемое отклонение от оригинала для кварцев 14МГц/14,3МГц +/- сопоставимо .2. Совместимость с шиной NemoBus.
Шина NemoBus - дефакто стандарт современного отечественного спектрумостоения, соблюдение которого гарантирует безконфликтную работу периферийных устройств. Шина NemoBus стандартизирована, и подробно описана во всех своих версиях, включая перспективные, документацию можно взять здесь: http://zx.clan.su/forum/7-82-1 . Непрерывно проводится работа по её поддержке и развитию.
1) Проблемы совместимости девборды ZXEvo со стандартом NemoBus.
Предистория.
Т.к. ZXEvo разрабатывала NedoPC, при том разрабатывала не под архитектуру Спектрума, то и с поддержанием на аппаратном уровне спектрумовских стандартов группа NedoPC не заморачивалась. Поэтому шина периферийных устройств девборды ZXEvo физически не может поддерживать все возможности шины NemoBus, и соответственно, девборда ZXEvo не в состоянии в полной мере корректно воспроизводить работу отечественных клонов спектрума с шиной NemoBus. Попытка группы NedoPC представить вырожденную ими шину периферийных устройств как ZXBUS (название шинного интерфейса оригинального компьютера ZX Spectrum 16/48k) - не более чем ещё одна попытка CHRV и группы NedoPC ввести в заблуждение пользователей компьютера Спектрум, так же, как и в случае самоназвания PentEvo для конфигурации развития CP/M компьютера ATM-2. Т.е. это очередная попытка обмана и манипуляции доверием спектрумистов со стороны CHRV и NedoPC, с целью втюхать им некое развитие ATM под видом Спектрума.
Решение.
Не все, но некоторые из отсутствующих сигналов можно допаять самостоятельно, например сигалы CLK (A8), 14MHz (A5), часть других сигналов возможно генерировать со стороны периферийных устройств втыкаемых в шину.
2) Проблемы совместимости конфигураций PentEvo и TSEvo со стандартом NemoBus.
Даже те сигналы, которые NedoPC завела в ZXEvo, не гарантированно соответствуют стандарту NemoBus в существующих конфигах PentEvo и TSEvo, что приводит к невозможности работы части периферийных устройств стандарта NemoBus с этими конфигами.
Основной проблемой несовместимости данных конфигов со стандартом NemoBus является несоблюдение ими основополагающего принципа работы шины NemoBus - метода арбитрирования захвата портов. Из-за этого часть периферийных устройств прекрасно работающих на клонах спектрума с шиной NemoBus, не могут работать с этими конфигами на ZXEvo.
Решение.
Изучить спецификацию стандарта NemoBus, и привести данные конфиги в соответствие со стандартом NemoBus.
P.S. От разработчиков этих конфигов приходилось слышать, что дескать это невозможно ибо приведёт к диким задержкам и т.д.
. Насамделе это не более чем попытки оправдать своё нежелание править конфиги, ибо в основном все вопросы решаемы .3) Проблемы переноса конфигов PentEvo и TSEvo на другие develpment board.
Совершенно необязательно при портировании конфигов, тащить на другую девборду и все их баги и недоделки. Так например для адаптера внешней шины ReVerSe вполне реально исключить все недостатки присущие конфигам PentEvo и TSEvo, что позволит пользователям иметь выбор между корректно работающей в соответствии со стандартом NemoBus шиной периферийных устройств девборды ReVerSe и кривым поделием группы NedoPC.
3. Совместимость по дешифрации портов.
Конфиг PentEvo, а так же созданный под его влиянием конфиг TSEvo, изначально идеологически позиционировались именно как архитектуры предназначенные для демомейкинга, что обусловило выбор таймингов Пентагона в их архитектуре. Но требования к архитектуре компьютера предназначенного для демомейкинга не ограничиваются его таймингами. Важным элементом демомейкерской архитектуры компьютера так же является максимальное приближение к особенностям упрощённой дешифрации оригинального ZX Spectrum 128, что позволяет использовать такую фичу, как обращение одновременно к нескольким портам для экономии тактов процесора.
Как ни парадоксально, но именно ориентированные якобы на демомейкинг архитектуры PentEvo и TSEvo имеют изначальную концептуальную ущербность не позволяющую реализовать заявленную их авторами идеологическую направленность архитектуры на демомейкинг, и состоящую в полной короткой дешифрации базовых системных портов #FE и #7FFD, и портов AY, что не позволяет использовать одновременное обращение к этим портам.
Предистория.
Полная короткая дешифрация базовых системных портов #FE и #7FFD в PentEvo обусловлена тем, что группа NedoPC в силу характерной для неё патологической инертности мышления (в силу которой NedoPC уже 9 лет упорно лжёт, отрицая совершённую ими изначально ошибку, при определении принадлежности платформы ATM к клонам Спектрума) так и не смогла осилить архитектуру шины NemoBus, являющуюся стандартом отечественного спектрумостроения, и без реализации которой принципиально невозможно обеспечить оригинальную дешифрацию системных портов #FE и #7FFD при одновременной поддержке большого количества новых портов.
Полная же короткая дешифрация базовых системных портов #FE и #7FFD в конфиге TSEvo обусловлена тем, что TSL тупо доверился "авторитету" NedoPC, и скопировал её кривую шину со всеми вытекающими из этого проблемами.
Решение.
Если не тупить патологически, как это принято в NedoPC, а хоть на минуту включить мозги, то при наличии NemoBus все проблемы решаются элементарно. Например для TSEvo может быть рекомендована следующая конфигурация приоритета захвата адресного диапазона портов:
1) Высший приоритет захвата портов отдаётся TS видеоакселератору (диапазон #xxAF), и включенному ему в параллель первому слоту. При необходимости сюда же можно отнести и порты ZSD (но обязательно при полной 16-ти дазрядной дешифрации порта #0077).
2) Следующий приоритет отдаётся второму слоту (потом третьему, если их три).
3) Следующий приоритет отдаётся портам периферийных устройств: NemoIDE (в его оригинальной дешифрации), BDI, кемпстон мыше и джойстику, RS232, #EFF7, и портам часов.
4) Следующий приоритет отдаётся системным портам #FE, #7FFD и портам AY.
5) И наконец самый низкий приоритет отдаётся несуществующему "порту" #FF, доступ к которому осуществляется вообще без какой либо дешифрации, а исключительно по отсутствию захвата диапазона портов всеми реальными устройствами.
4. Совместимость по шине данных.
Предистория.
Архитектура Спектрума задаёт обязательную подтяжку шины данных в единицу с помощью резисторов, и если этого нет, то это однозначно НЕ СПЕКТРУМОВСКАЯ!! архитектура. На резисторной подтяжке шины данных завязана работа так называемого порта #FF, из которого на бордюре читается #FF, а так же работа маскируемых прерываний. В отличие от клонов Спектрума, девборда ZXEvo не имеет этого ключевого элемента аппаратной архитектуры Спектрума - резистивной подтяжки шины данных в единицу. Вместо этого по определённому условию на шину данных выдаётся #FF из FPGA... Трудно определить истинную причину такого странного аппаратного решения со стороны NedoPC - то ли CHRV забыл развести матрицу резисторов на плате, а потом сделал вид что так и задумано, то ли lvd бездумно содрал конфиг с чего-то, что не имело внешнего процессора и шины расширения, и соответственно подтяжка эмулировалась внутри FPGA. В любом случае в NedoPC серьёзно лоханулись, а принимая во внимание эпопею с уже девятилетним враньём CHRV по поводу того как они в NedoPC лоханулись с определением принадлежности ATM к клонам Спектрума - то собсно ожидать от них правды и по этому поводу не приходится
. Хотя конечно если рассуждать с точки зрения что PentEvo как клон ATM не является клоном Спектрума, то отсутствие одного из ключевых элементов Спектрумовской архитектуры в ZXEvo собственно не должно вызывать вопрососов - ну не Спектрум оно, что с него взять, имеет право не иметь подтяжки
Итак, рассмотрим чем же грозит простому юзеру такое странное решени от NedoPC, которое так же бездумно скопировано и в конфиге TSEvo от TSL.
1) Работа с вектором прерывания.
Увы, но о том, что внешние устройства в соответствии со спектрумовской архитектурой имеют право выставлять свой вектор прерывания, в NedoPC очевидно не знают, а поэтому, как в конфиге PentEvo, так и в базирующейся на её исходниках TSEvo их авторы зарубили эту возможность на корню.. При попытке выставить внешним устройством вектор прерывания, есть вероятность, что сдохнет либо это устройство, либо FPGA.
2) Работа при захвате портов.
Зачастую юзеры, введённые в заблуждение CHRV & Co., и наивно полагающие что имеют дело с клоном Спектрума, пытаются воткнуть в ZXEvo ёлку для клона Спектрума. Увы, втыкать в НЕСПЕКТРУМ ёлку от клона Спектрума - это не совсем безопасное занятие. Суть проблемы в том, что в конфигах базирующихся на исходниках PentEvo, если от внешних устройств не приходят сигналы IORQGE в цикле чтения, то FPGA выставляет на шину #FF. Но!! При использовании ёлки имеющей на борту свой собственный арбитр приоритетов, IORQGE от устройства воткнутого в эту ёлку задерживается её арбитром. Поэтому может возникать ситуация, когда устройство честно выставило IORQGE и собственные данные на шину, но IORQGE из-за задержки в арбитре ещё не дошло до FPGA и поэтому FPGA сама выставляет в это же время на шину #FF. Опять же возникает конфликт на шине, с определённой вероятностью могущий привести к выходу из строя либо периферийного устройства, либо FPGA. Особенно не рекомендуется втыкать в PentEvo/TSEvo не исправленный в соответствии с рекомендациями http://zx.clan.su/forum/8-118-777-16-1387740869 , кривой старый GS, активно размножаемый zorel'ом вместе со всеми его схемотехническими багами, который умудряется выставлять данные на шину ещё до прихода сигнала RD/, а IORQGE формировать после прихода IORQ/, и гарантированно вступающий в конфликт с FPGA.
Ничего подобного в клоне Спектрума произойти не может принципиально!
Решение.
Самое простое - изменить конфиг таким образом, чтоб шина данных FPGA работала в режиме открытого стока. Правда при этом возможно данные от FPGA несколько потеряют в крутизне фронтов. Насколько это критично надо экспериментировать. Ессно генерилку #FF надо выкинуть напрочь (мож даже от этого экономия какя получится
). Если крутизна фронтов будет неудовлетворительной, то оставив тристабильной шину данных FPGA, можно просто подтянуть её внешними резисторами к +3,3В. Для Z80 это вполне штатное включение резисторной подтяжки, о чём судя по всему в NedoPC не знают
. P.S. Т.к. NedoPC и TSL архитектуру Спектрума знают весьма поверхностно, то акцентирую внимание на том, что в архитектуре Спектрума внешнее устройство имеет право выставлять вектор прерывания не целиком байтом, а отдельными разрядами. Поэтому, если вы засунете в FPGA свой собственный контроллер прерываний, то работать на шину он обязан так, как будто в режиме открытого стока. Т.е. единицы на шине данных должны формироваться резисторами подтяжки, а не буферами FPGA. Например для TSEvo при формировании вектора прерывания, в ноль будут дёргаться только либо D1, либо D2, а остальные разряды должны быть в Z-состоянии, ессно при подтяжке шины данных резисторами в единицу.
5. Совместимость по биперу.
Биперная музыка для спектрумовской сцены - это один из её базисов. Бипер наряду со спектрумовским экраном, это то, что было, есть, и будет всегда. Даже AY вторичен и не обязателен, в то время как бипер обязателен для каждого клона Спектрума, тем более для компьютера претендующего на использование в качестве сценерской платформы. Тем не менее, как это ни странно, но в довольно большой части клонов бипер схемотехнически реализован неправильно, что, естественно приводит к неправильному звучанию биперных композиций. Не стал исключением такой кривой реализации бипера и компютер ATM, передавший по наследству эту кривизну своему эволюционному развитию воплощённому по задумке группы NedoPC в девборде ZXEvo и конфиге PentEvo. Суть же проблемы с реализацией бипера состоит в том, что в оригинальном Спектруме сигнал формируется не единственным разрядом D4 #FE, а двумя разрядами D3,D4 #FE имеющими разные весовые коэффициенты, и образующие нелиейный 2х битный ЦАП. Т.е. в оригинальном Спектруме биперный сигнал имеет отнюдь не два уровня 0 и 1, как это реализовано в PentEvo, где D3,D4 #FE просто складываются по модулю два. Что характерно, конфиг PentEvo многократно использовали как компомашину на некоторых пати
. Можно только представить что там звучало вместо нативной спектрумовской биперной музыки, и о каком уровне пати можно говорить при использовании такой кривой реализации бипера . Конечно, не все биперные композиции используют оба разряда D3,D4 #FE, но есть такие, которые воспроизводят разные звуковые каналы через разряды D3,D4. Примером использования обоих разрядов D3, D4 порта #xxFE для генерации звука может служить игра Manic Miner, где через разряды D3, D4 воспроизводятся разные звуковые каналы. Поэтому в клонах, в которых для вывода звука используется только один из разрядов, или оба разряда смешиваются с одинаковыми весовыми коэффициентами, или как в PentEvo складываются по модулю два, мелодия искажена, т.к. часть сигналов теряется. Эта проблема оставалась длительное время не замеченной т.к. что бы заметить разницу надо иметь кроме клона ещё оригинальный Спектрум, и при этом обладать ещё и музыкальным слухом. Те же, кто имел дело только с криво реализованным бипером так и оставались в неведении, что в оригинале музыка звучит совсем иначе.Можно ли это исправить конкретно для девборды ZXEvo? Можно конечно попытаться применить ШИМ для бипера, но гарантировать аутентичность звука при этом нельзя.
