MSX - VDP. Что делать с V9958. Пора менять?

[OrionExt]

Тут еще одна историческая загадка. Почему не использовали сигнал wait самого V9958?

А придумали внешнею тормозилку, которая получилась не очень удачная (клац) и тормозит не всегда по делу (доступ к внутренним регистрам VDP).

Дойдет очередь до замены Z80 на Z180 и обязательно попробую wait от V9958. Да и установка Z180 (HD64180) в MSX2 была проделана в Victor HC-90 до выхода MSX TurboR.

[s_kosorev]

Ответ прост

пруф - не домыслы

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

И пред отвечу. Набери три слова R800, WAIT ,V9958 и получи ответ=) В гугле.

а в сумме на единицу времени?

[OrionExt]

а в сумме на единицу времени?

Да кто его знает.

Просто пользователи TurboR подметили что в режиме R800 и при интенсивном обмене с VDP процессор начинает тормозить и проигрывать по производительности Z80. Даже программу приводили в пример, правда, название забыл. Нашел EVA-player.

[ivagor]

Как я понял из прочтения интернетов, S1990 в turboR после обращения к портам vdp считает 8 мкс. Если за эти 8 мкс не было больше обращений к vdp, то все нормально. А вот если в течении этих 8 мкс случается попытка второго обращения к vdp, то процессор waitится до окончания 8 мкс.
В "обычном" msx2 единственный тормоз, про который я знаю - дополнительный такт в цикле M1 Z80.
В пзу можно найти примеры двух обращений к vdp с интервалом <8 мкс, например в msx2ext.rom
298С out (99h),a
298E ld a,8Fh
2990 out (99h),a
интервал между двумя out (99h) на msx2 (с учетом торможения в M1) будет 20 тактов, т.е. примерно 5.7 мкс, что < 8 мкс.

Насчет почему в turboR 8 - как я понял, требуемая vdp задержка может составлять от 2 до 8 мкс (в зависимости от разных условий), и разработчики turboR сделали по максимуму, чтобы все работало и в худшем случае.

[OrionExt]

ivagor видимо так. И по факту вышло хрено.

Вот еще интересный эксперимент был проделан c wait v9958, не касающийся R800.

жмак

The /WAIT pin on the MSX bus works in a very similar way to the /INT signal: It's a big logic AND between all the built-in devices & slots so any of those can request a WAIT (or a interrupt, in that case) to the CPU.

This was a feature clearly designed to allow Z80s with more than 5.37MHz (*1) to access the VRAM.

I did some tests some years ago, but I had no access to a logical analyzer. Those obviously are not very precise tests, but probably results are enough for the educated guess, until someone dissects this better using a logical analyzer.

The V9958 /WAIT generation indeed seem to be somewhat intelligent. My test set was done connecting a LED to the V9958 /WAIT output pin, and connecting the /WAIT to the CPU. The circuit was designed so that only V9958 /WAIT requests would light up the LED, isolating any /WAIT requests from other devices. My circuit could also disable the M1 waitstate generator for an instant +/-20% speed increase.

The results were:

1. If the WTE bit of the R#25 is disabled, no waitstate request is ever generated
2. I tested with several CPU clocks, to check the limits. When the WTE bit is enabled, those were the results:
2.1) From 1.78MHz to 5.37MHz no waitstate seems to be generated. Disabling the M1 waitstate at 5.37MHz resulted in the LED lighting up very dimly.
2.2) At 6MHz, the led started blinking very dim. This means that very few waitstates were being generated. Disabling the M1 waitstate instantly increased the LED brightness a bit.
2.3) At 7.14MHz the led light strobe seemed to be around 25% of the LED brightness
2.4) At 10.74MHz the led light strobe seemed to be around 50% of the LED brightness

From the educated guess side of things, what seemed to happen is that when the Z80 tried some VRAM access before of it's reserved time slot, the V9958 would issue the /WAIT until the access time slot comes.

As the V9958 datasheet states, no WAITs seem to be generated for accessing the V9958 registers. It only generates WAITs for VRAM access.

*1: 5.37MHz seems to be the V9958 limit for VRAM access without extra waits. The register access handles 7.14MHz without trouble, and maybe can take even more.

[свернуть]

[ivagor]

Если wait, включение/выключение которого описано в разделе 5.1.2 pdf (стр. 7-8 документа, или 11-12 в файле) и wait в разделе 7.3.5 (стр. 17-18 документа или 21-22 в файле) - это один и тот же wait, то неудивительно, что в turboR пришлось тормозить чипсетом, т.к. wait от 9958 получается "не всеобъемлющий".

[Advertiser]

[OrionExt]

Ну, зафиксировали бы частоту на уровне 7МГц для доступа к регистрам, а видео-память разруливали бы от wait VDP. Так нет. Поступили по тупому. Нати вам таймер один на все.

Самое интересное wait VDP детище тех же разработчиков. И они прекрасно знали, как оно работает.

А то прямо диверсия какая-то

[TomaTLAB]

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

[ivagor]

С ходу не нагуглил, где читал, но вот нечто в этом духе. В TurboR планировали 9978, но его не доделали (по крайней мере не выпустили в массы), и поставили 9958.

[OrionExt]

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

Так как и писал ранее. Оставили бы z80 для совместимости. Не давайте и все преимущества R800 сведем почти к нулю.

C высоты годов оно конечно всегда лучше видно

С ходу не нагуглил, где читал, но вот нечто в этом духе. В TurboR планировали 9978, но его не доделали, и поставили 9958.

Это вообще печальная история.

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

А так задумка с двумя CPU очень хорошая. Тоже хочу что-то подобное сделать у себя. Правда, до конца не понял как