ZXMAK.NET 2 alpha небольшой ремикс :)

Цитата:

---

Сообщение от ZEK

Тут может быть такое же решение как и в железе - приоритеты, тобиш логика IOQGE
если откликнулось устройство которое сидит раньше в цепочке (к примеру в первом слоте слотовых машин) IORQGE то остальные идут лесом.

---

попробовал вариант с массивами делегатов, я пошел дальше и на обращение к памяти тоже делегатами рулится. Сделал так - есть менеджер шины, в котором регистрятся все девайсы реализующие IBusListener. Менеджер шины при регистрации вызывает метод BusInit у каждого девайса в котором девайсы сообщают на какие события они подписываются, например:

Код:

---

public void BusInit(IBusManager bmgr)
{
  // false - это M1
  bmgr.AddListenerReadMemory(0xC000, 0x4000, false, readPage4000);

  bmgr.AddListenerReadPort(0x0001, 0x0000, readPortFE);
}

private void readPage4000(long cpuTact, ushort addr, ref byte value)
{
  value = RAMS[5][addr&0x3FFF];
}

private void readPortFE(long cpuTact, ushort addr, ref byte value)
{
  value = (value & 0xBF) | GetTapeBit(cpuTact)? 0x40:0x00;
}

---

к сожалению производительность упала на 30-40%, при том-же функционале :( Может написать часть эмулятора на Си?
Пока рано делать окончательные выводы, т.к. при вызове делегатов многовато лишнего происходит, нужно посмотреть что можено соптимизировать...


в аттачменте пробный вариант с BusManager (глубоко не проверял, но с виду все вроде работает)

---------- Post added at 10:02 ---------- Previous post was at 08:42 ----------

Цитата:

---

Бажка с востановление контекста графического устройства, видать обрабатывается только состояние DeviceNoReset или как то так, а на DeviceLost вываливает исключение (ноут усыпил с включеным эмулятором, после пробуждения красный крест вместо картинки)

---

хм, на десктопе проверял в разных режимах все ок, иногда только в лог пролетают единичные InvalidCall на текстуре после манипуляций с фокусом и старт-стопом. Проверю на ноутбуке...

Цитата:

---

Сообщение от Vitamin

Если зарегистрировано несколько делегатов на чтение- вот это уже плохо, ибо конфликт на шине.

---

конфликт - это не страшно, конфликтное устройство просто может забивать результаты других устройств, при конфликтах его можно просто отключить. Зато девайс может устанавливать только свои биты в результате.
Плохо то что вызов кучи делегатов на каждый доступ к памяти кушает много времени...

Цитата:

---

Сообщение от Alexander Makeev

Зато девайс может устанавливать только свои биты в результате.

---

И такая ситуация существует в железе. Не помню где но что то с глюкчасами связанное. Так же к примеру контролер клавиатуры от caro который умеет команды принимать чтением из порта FE тож только своими битами управляет и трогает магнитофонный бит.

---------- Post added at 16:13 ---------- Previous post was at 15:09 ----------

Для памяти может вместо делегатов использовать expession? по идее быстрее будет, потеряется возможность multicast но для памяти как бы и не надо.

Цитата:

---

Сообщение от ZEK

Для памяти может вместо делегатов использовать expession? по идее быстрее будет

---

в этом случае, как мне кажется, никакого выигрыша не будет. Наоборот даже будет лишняя потеря времени на компиляцию Expression'а в рантайме

Цитата:

---

Сообщение от Alexander Makeev

Плохо то что вызов кучи делегатов на каждый доступ к памяти кушает много времени...

---

При таких вот массовых опросах провайдеров можно использовать один прием. Я его открыл для себя, когда писал анализатор данных для ZXTune. Вместо того чтобы дергать каждый детектор на каждый байт смещения во входных данных (очевидный алгоритм поиска) делается следующее. Результатом работы каждого детектора является пара чисел- сколько байт он проанализировал (их можно пропустить для анализа) и сколько байт его можно не трогать. Эти числа взаимоисключающие, разумеется.

В ситуации с эмулем результатом может стать одно число вида "позвать через N тактов".
Разумеется, это лишь идея, ее результат будет зависеть от исполнения:)

после оптимизации кода процессора под новую модель с BusManager, результат таков: падение производительности на новой модели составило 23%. Решил оставить, т.к. уж больно удобная модель получилась :)

Как выяснилось, львиную долю дополнительного времени съедает подписка Beta Disk Interface на ReadMemoryM1. Кода в обработчиках фактически нет, но при подписке на ReadMemory производительность сразу проседает на 15%. Вот код обработчиков:

Код:

---

        public void BusInit(IBusManager bmgr)
        {
            bmgr.AddListenerReadMemoryM1(0xFF00, 0x3D00, readMem3D00_M1);
            bmgr.AddListenerReadMemoryM1(0xC000, 0x4000, readMemRam);
            bmgr.AddListenerReadMemoryM1(0xC000, 0x8000, readMemRam);
            bmgr.AddListenerReadMemoryM1(0xC000, 0xC000, readMemRam);

            bmgr.AddListenerWritePort(0x8002, 0x0000, writePort7FFD);

            bmgr.AddListenerWritePort(0x00E3, 0x0003, writePortCMD);
            bmgr.AddListenerWritePort(0x00E3, 0x0023, writePortTRK);
            bmgr.AddListenerWritePort(0x00E3, 0x0043, writePortSEC);
            bmgr.AddListenerWritePort(0x00E3, 0x0063, writePortDATA);
            bmgr.AddListenerWritePort(0x00E3, 0x00E3, writePortBETA);

            bmgr.AddListenerReadPort(0x00E3, 0x0003, readPortCMD);
            bmgr.AddListenerReadPort(0x00E3, 0x0023, readPortTRK);
            bmgr.AddListenerReadPort(0x00E3, 0x0043, readPortSEC);
            bmgr.AddListenerReadPort(0x00E3, 0x0063, readPortDATA);
            bmgr.AddListenerReadPort(0x00E3, 0x00E3, readPortBETA);

            bmgr.AddListenerReset(busReset);
        }

        private void busReset(long cpuTact)
        {
            m_selTrdos = false;
            m_lock = false;
            writePort7FFD(cpuTact, 0x7FFD, 0);
        }

        #region RDMEM

        private void readMem3D00_M1(long cpuTact, ushort addr, ref byte value)
        {
            if (m_romPage == 1)
                m_selTrdos = true;
        }

        private void readMemRam(long cpuTact, ushort addr, ref byte value)
        {
            m_selTrdos = false;
        }

        #endregion

---

обнаруженые недостатки на примере бета диск интерфейса:
- из девайса бета диска приходится мониторить чтение памяти чтобы отловить вход в TRDOS для разрешения обработки портов (сами ROM переключаются в девайсе Memory);
- из девайса бета диска приходится мониторить RESET и запись в порт 7FFD на предмет битов LOCK и ROM, чтобы блокировать вход в TRDOS из 128K ROM

вот что на данный момент получилось - см.аттачмент. Сыровато пока, но работает :)
Уже проясняется где можно оптимизацию сделать - слушать порты например можно только в одном устройстве, а в остальных искать на шине девайс с нужным интерфейсом и брать данные вывода в порт у него. Таким образом можно уменьшить дублирование обработки портов...

что нового:
- добавлен индикатор доступа к диску :)
- добавлена страница с настройками дисплея (сглаживание, VBlank, индикторы)
- мелкие фиксы и рефакторинг кода Z80 с оптимизацией под BusManager
- fix Z80 interrupt timing
- fix Z80 HALT issue (z80 snapshot)
- fix Z80 mistakes (undocumented DD/FD opcodes)
- реализован базовый класс UlaGeneric, на основе которого можно создавать стандартные со своими модами
- добавлен ULA девайс для Pentagon без обрезки по бордюру
- добавлен ULA девайс для Scorpion
- добавлен ULA девайс для ATM1 (только стандартный видеорежим)
- добавлен ULA девайс для Profi (пока не работает, т.к. требует соответствующую память)


PS: залил версию 204, в 203 был баг с отладчиком (повторно не открывался)

Новая версия 2.0.5:
- исправлены тайминги SEEK для ВГ93 (CHORDOUT)

Нужно бы заняться ВГ93, т.к. движок от unreal никуда не годится. Кто-то может помочь со сбором информации по ВГ93 на реальном железе?

Ближе к зиме буду подрубать к DE1 Nemo FDC
можно будет вымерять все вдоль и поперек.

может кто подскажет, в харькове можно гдето приобрести компактный спектрум на Z80 и ВГ93, на современной элементной базе? Интересно с железкой поковыряться :)
Главное не старый гроб, т.к. некуда ставить. Что-то типа маленькой коробочки по размерам с роутер-мыльницу, но чтоб проц Z80 был :)