ZXMAK2 - Виртуальная машина ZX Spectrum

[Lethargeek]

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

а там разве вот прям код анализируется? а не (например) юла морозится до фронта

[goodboy]

вот этот тызыкс

скорее всего оцифровка делалась в автоРежиме.
если перегнать в wav и `правильно` оцифровать - заработает.

[ZXMAK]

Странно. Может на старом DirectX так и можно было сделать, но начиная с DXGI в описаниях четко сказано, что если окно открыто на конкретном дисплее, то цепочка буферов и ее обновление привязывается именно к тому дисплею, на котором открыто окно. Иными словами, без закрытия и открытия окна заново на новом дисплее, и создание новых привязанных к этому окну буферов, синхронизироваться под другой дисплей не получится.
Но я это пока не проверял.

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

- - - Добавлено - - -

а там разве вот прям код анализируется? а не (например) юла морозится до фронта

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

Грубо говоря это попытка не эмулировать кусок кода, а сразу подставить готовые результаты. Но проблема в том, что корректно проанализировать загрузчик на лету довольно проблематично, не потеряв в скорости и корректно обработав все возможные варианты загрузчиков.

Я даже не стал смотреть как это делается, т.к. тот-же fuse при загрузке с кассеты дико тормозит на медленных компьютерах, таких как raspberry pi. А я именно под raspberry pi и затачиваю zxmak2.

PS: посмотрел код fuse, да - там длинный свитч проверяющий текущую инструкцию и считающий что код загрузчика всегда одинаков и только такой как заложен в эмулятор, там в коде эмулятора захардкожено назначение регистров и битов в регистрах для загрузчика, поэтому такая акселерация загрузки не будет корректно работать для нестандартных загрузчиков.

[goodboy]

я ускорение загрузки edge load не делал

вроде-бы там просто включается дикая турба и выключается после загрузки.

[ZXMAK]

вроде-бы там просто включается дикая турба и выключается после загрузки.

нет, эмулятор сразу модифицирует регистры процессора:

static void
do_acceleration( void )
{
  if( length_known1 ) {
    /* B is used to indicate the length of the pulses */
    int set_b_high = length_long1;
    set_b_high ^= ( acceleration_mode == ACCELERATION_MODE_DECREASING );
    if( set_b_high ) {
      z80.bc.b.h = 0xfe;
    } else {
      z80.bc.b.h = 0x00;
    }

    /* Bit 5 of C is used to indicate the current microphone level */
    z80.bc.b.l = (z80.bc.b.l & ~0x20) | (tape_microphone ? 0x00 : 0x20);

    z80.af.b.l |= 0x01;

    /* Simulate the RET at the end of the edge-finding loop */
    z80.pc.b.l = readbyte_internal( z80.sp.w ); z80.sp.w++;
    z80.pc.b.h = readbyte_internal( z80.sp.w ); z80.sp.w++;

    event_remove_type( tape_edge_event );
    tape_next_edge( tstates, 1 );

    successive_reads = 0;
  }

  length_known1 = length_known2;
  length_long1 = length_long2;
}

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

Мне такой подход не нравится, поэтому я такой акселератор загрузки не стал добавлять, хотя флаги LENGTH_SHORT и LENGTH_LONG прикрутил, на случай если захочется поэкспериментировать.

[Lethargeek]

если перегнать в wav и `правильно` оцифровать - заработает.

в смысле "перегнать" - какой, неисправленный?
так он же воспроизведётся неправильно))
а исправленный уже нет смысла перегонять

PS: посмотрел код fuse, да - там длинный свитч проверяющий текущую инструкцию и считающий что код загрузчика всегда одинаков и только такой как заложен в эмулятор, там в коде эмулятора захардкожено назначение регистров и битов в регистрах для загрузчика, поэтому такая акселерация загрузки не будет корректно работать для нестандартных загрузчиков.

в zxspin, наверно, что-то сложнее, потому что для него я затрудняюсь сходу назвать загрузчик, который НЕ сработает с edgeload

вроде-бы там просто включается дикая турба и выключается после загрузки.

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

[Advertiser]

[ZXMAK]

в zxspin, наверно, что-то сложнее, потому что для него я затрудняюсь сходу назвать загрузчик, который НЕ сработает с edgeload

если поставить цель обмануть захардкоженую в эмуляторе логику для загрузчиков, то я думаю не проблема сделать загрузчик, который не будет работать ни в zxspin, ни в каком другом эмуляторе использующем edge load акселерацию. Т.к. невозможно захардкодить в эмуляторе поддержку всех возможных загрузчиков, а код с таким анализом будет сильно тормозить.

- - - Добавлено - - -

но для некорректного тызыкса не должно быть разницы в таком случае - а он грузится

потому что edge load - это не загрузка, это обман загрузчика эмулятором, с подсовыванием ему готовых данных напрямую вместо реальной эмуляции. Анализ длительности импульса при этом не производится, поэтому даже если импульсы некорректные и сигнал никогда не сможет быть загружен реальным спектрумом, загрузка в таком эмуляторе всегда будет "успешной". Эмуляции загрузки при этом по сути не происходит, просто данные из tzx напрямую записываются в память спектрума, счетчик в регистрах подкручивается чтобы загрузчик думал что загрузка произошла.

PS: Кстати, в этом очевидно и кроется ответ, как такой битый TZX появился. Ктото протестил в эмуляторе с edge load что программа "грузится" и выложил TZX, а на самом деле TZX битый, в нём потеряна реальная длительность импульсов, он не будет грузиться на реальном спектруме.

И восстановить длительность импульсов будет проблематично. В данном случае я просто взял TZX с другим релизом этой программы и посмотрел в ней длитетльность импульсов, но если бы смотреть было некуда, то пришлось бы анализировать код загрузчика и подбирать опытным путём чтобы сделать такой TZX загружаемым.

И наверняка таких битых TZX немало, благодаря этой edge load акселерации...

[goodboy]

в смысле "перегнать" - какой, неисправленный?
так он же воспроизведётся неправильно))

TZX (problem) -> WAV
и указав (в параметрах MakeTZX) NormalROM создаётся вполне рабочий TZX

[ZXMAK]

TZX (problem) -> WAV
и указав (в параметрах MakeTZX) NormalROM создаётся вполне рабочий TZX

не поможет. В этом TZX указаны стандартные длительности импульсов. Вот фрагмент из asm файла сформированного дампером:

#code BLOCK7_DATA, 0, *, flag=$ff, pause=0
        .tzx-pilot-sym  0,  2168        ; symbol#0 for pilot pulses
        .tzx-pilot-sym  0,  667,735     ; symbol#1 for sync pulses
        .tzx-pilot      0,3220 , 1,1    ; 3220 pilot pulses (symbol#0), then one sync pulse symbol (symbol#1)
        .tzx-data-sym   0,  855,855     ; symbol#0 for bit 0
        .tzx-data-sym   0, 1710,1710    ; symbol#1 for bit 1

а должны быть укороченные:

#code BLOCK7_DATA, 0, *, flag=$ff, pause=0
        .tzx-pilot-sym  0,  2165        ; symbol#0 for pilot pulses
        .tzx-pilot-sym  0,  714,714     ; symbol#1 for sync pulses
        .tzx-pilot      0,3261 , 1,1    ; 3261 pilot pulses (symbol#0), then one sync pulse symbol (symbol#1)
        .tzx-data-sym   0,  615,615     ; symbol#0 for bit 0
        .tzx-data-sym   0, 1230,1230    ; symbol#1 for bit 1

Сравните длительность импульсов 855 и 1710 тактов против 615 и 1230 тактов в оригинале.
Синхроимпульс тоже неправильный - 667,735 вместо 714,714 в оригинале.

Очевидно ошибку не заметили из-за того, что для теста загрузили файл в эмуляторе с edge-load, который из-за ошибки загрузил его как корректный. На самом деле в нем отсутствует важная информация о длительности импульсов и восстановить ее было бы довольно сложно, если бы не было аналогичного рабочего релиза. Т.е. загрузить на реальном спектруме было бы невозможно, только в эмуляторе с загрузкой edge-load, которая игнорирует длительность импулсов и пишет данные сразу в регистры процессора подменяя счетчик.

[goodboy]

ага, понял.
действительно (сразу не заметил) проверял с включённым EdgeLoad.
причём грузит только в модели48к