Contended memory /Медленная память/ на Original Speccy

[elfh]

возможно, кому-то это покажется интересным. пару лет назад, мы стремились сделать все наши работы доступными пользователям оригинальных машин, поэтому я попросил у 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!