чтение/запись в видеопамять на OriginalSpeccy
 

кто знает, как именно "тормозит" сабж?

при чтении из нечетного банка (1,3,5,7) выдаётся WAIT, если луч не на бордюре. количество тактов WAIT зависит от текущего такта и составляет величину от 0 до 7 тактов. за подробностями можно обратиться к любому эмулятору, поддерживающему contended memory - RealSpectrum, Z80S, ZX32

и не только при чтении, но и при записи

а у себя когда(-нибудь) поддержишь? ;)

нет :)

А по какой причине отказался от поддержки w98?
Я вот уже 3 года юзаю версию 0.20 fix#2.
Так-что СПАСИБО за рульный эмуль!
Если бы не он то думаю не сушествовало всех те проектов
которые реализовала n-Discovery за прошедшие 3 года.
Реальный спек конечно рульно, но для активного кодинга эмуль не заменим.

потому что сейчас у меня нет этой самой 98-й и проверять не на чем. вот я, от глюков подальше, и перестраховался

для кодинга как раз в новой версии появились метки из XAS и ALASM. так что, теперь вообще можно от STS отказаться

Если кто не знал, в фирменных компах, если HALT выполняется из #4000-#7fff, то программа обработки прерываний запускается ровно с первым пикселем нового растра.
И это есть круто :)

Боюсь погнать, но имхо в оригинале не вайты долбались, а просто CLK от проца отрубалось (в "Байте" так точно ^_^)

original timings
 

возможно, кому-то это покажется интересным. пару лет назад, мы стремились сделать все наши работы доступными пользователям оригинальных машин, поэтому я попросил у phoenix/ra/pdz описания таймингов. вот его ответ:

It's very nice to hear such good will trying to make code for
different speccys, but im afraid it will be very difficult for you
to fix for example multicolour without testing. You will see why.
First of all there are 4 different 'firm' 128K speccys. There's 128K +,
+2, +2A and +3. 128K + and +2 have equal timings between each other,
and +2A and +3 have equal timings between each other too. Now comes the
big problem. Some memory pages are slow, which means that if you read/write
to them while frame is displaying speccy screen, it will slow down cpu. If
border is being displayed (or vertical retrace) there is no slow down. So now
here's the info for each group:

128K + / +2
-----------

- 228 Tacts per scanline
- 311 lines per frame
- 63 lines before TV picture
- 70908 Tacts per frame
- Pages 1,3,5,7 are slow (but only when displaying screen)
- if I is set to point to slow ram, computer gets snow on screen
and may crash.
- port #FF works
- out (#FD),rampage works as on pentagon

+2A / +3
--------

- 228 Tacts per scanline
- 311 lines per frame
- 63 lines before TV picture
- 70908 Tacts per frame
- Pages 4,5,6,7 are slow (but only when displaying screen)
- No problem with I pointing to slow ram
- port #FF doesn't work
- must use out on #7ffd or out (#FD),rampage with 6th bit set (as on scorpion)
- Has faster slow ram than 128K + / +2

And how does the slow ram works? It's a bit complicated and thats why i mean
you probably need to test it. Specially coz area 4000-7fff is always a slow
ram page,
and you must access it to make fx. If accessing slow ram while screen is
being displayed,
a delay of 0-6 will be applied (0-7 on +2A/+3). This delay isn't random, it
has an order,
but i can't remember it right now. So what should one do to make sure code
runs optimally
on all firm speccys:

- NEVER point I to slow ram.
- Keep all critical code in fast ram.
- If possible, do test for model (or ask user) to use optimally
fast ram pages. (first demo i saw that does this is _laya by baze/3sc)
- Try and run code that uses slow ram a lot when screen isnt being displayed.
(for example, you can have music player in slow ram if you call it right
after
interrupt, because screen wont be displayed then and it wont slow down
nothing)

As you can see, making code to run ok on firm speccys isn't that easy ;) If
you ever
need to get some code tested on firm speccy i'll be glad to test it here
for you. Any
questions, etc mail me :)

Hope this helps!