Screen switching, does it happen?

Share graphical tips, notes and queries related to our favourite screen layout and its editors.
Post Reply
dfzx
Dizzy
Posts: 81
Joined: Mon Nov 13, 2017 6:55 pm
Location: New Forest, UK
Contact:

Screen switching, does it happen?

Post by dfzx » Tue Dec 26, 2017 10:51 am

I cringe at my ignorance as I type this, but hey, I never had a 128K, and had moved on to 16 bit machines long before it came out.

I was looking at the specs of the 128K Spectrum and noted what appears to be banked screen memory. There are 8 16K banks which can occupy the range 0xC000 to 0xFFFF, and of those, bank 5 is frequently labelled as "screen 0" and bank 7 is frequently labelled as "screen 1". Example:

https://faqwiki.zxnet.co.uk/wiki/ZX_Spectrum_128

I presume the idea here is to be able to draw into one bank while displaying the other, then instantly switch screens via hardware in order to eliminate flicker. Is that how it works? I ask because I've never seen discussions on the topic. Everything I've ever seen about Speccy graphics and flicker relates to chasing "chasing the raster." No one ever seems to mention screen switching. Is that because it's just a given? Or is the technique not really used for some reason?

Also, I can't find a decent explanation of how these banked screens affect what happens to the normal screen at 0x4000, so if anyone would like to try to explain that to me that'd be appreciated. :)
0 x

User avatar
1024MAK
Microbot
Posts: 121
Joined: Wed Nov 15, 2017 2:52 pm
Location: Sunny Somerset in the U.K. in Europe

Re: Screen switching, does it happen?

Post by 1024MAK » Tue Dec 26, 2017 11:02 am

Yes, with the 128k machines the hardware is capable of displaying a screen from one of two available banks.
See here for more info...

The main limitation is that the normal screen memory stays in the normal place in the Z80 memory map (0x4000 and 0x7fff) and can't be paged out of this area. This does rather limit the usefulness of having two screen areas.

Mark
Last edited by 1024MAK on Tue Dec 26, 2017 11:11 am, edited 2 times in total.
0 x

AndyC
Microbot
Posts: 129
Joined: Mon Nov 13, 2017 5:12 am

Re: Screen switching, does it happen?

Post by AndyC » Tue Dec 26, 2017 11:04 am

Yes it does happen. :D

Screen 0 is the same memory that sits at #4000, so if you page that in at #c000 you can basically write to it via multiple addresses. The key benefit to paging it in is that your screen addressing code doesn't need to deal with different memory locations after you swap screen.

So why doesn't everyone use it? Firstly it makes your code 128K only. And it's not particularly easy to create a downgraded version of code that relies on hardware double buffer for a 48K version. So if you're designing your code around chasing the beam on the 48K, well you might just as well do the same on 128s too.

Secondly it reserves more memory (naturally) and forces you to deal with the 128's shonky banking arrangements all the time. A lot on of developers prefer to just treat the extra memory as one great big storage device that they "load" data from instead of multi-loading from tape/disk.
0 x

Ralf
Manic Miner
Posts: 686
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: Screen switching, does it happen?

Post by Ralf » Tue Dec 26, 2017 11:20 am

Why is so little discussion about 128kb screen switching?

Well, as others already said, many of us stll writing Spectrum programs want them to run on standard 48 kB model. It's the machine that most of us had in the past, I believe that 128kB models could be only about 10-20% of all Spectrum sold. So it's nostalgic for everyone and people consider it very often as some kind of unofficial standard.

And it was actually the same in the 80s. As most people owned 48 models, it was a must that your game ran on it so it sold well. And if the developer were already doing it for 48kB, he was often too lazy to make a different engine for 128 kB to get a little bit smoother movement. 48 kB code will work on 128 kB. Opposite way it won't work.

Going offtopic, it's not the same all around the world. In Russia, where active Spectrum community also exists, a standard machine is Pentagon which is a clone of Zx Spectrum 128, only very slightly modified. So a Russian developer won't worry at all if his program won't run on rubber keys Spectrum.

And finally many people find working with 128 kB memory paging and double screens awkard so they don't do it. As you noticed, it is also less documented.
0 x

Wall_Axe
Microbot
Posts: 147
Joined: Mon Nov 13, 2017 11:13 pm

Re: Screen switching, does it happen?

Post by Wall_Axe » Tue Dec 26, 2017 3:37 pm

what does this mean?

RAM banks 1,3,4,6 and most of 7 are used for the silicon disc; the rest of 7 contains editor scratchpads.
0 x

AndyC
Microbot
Posts: 129
Joined: Mon Nov 13, 2017 5:12 am

Re: Screen switching, does it happen?

Post by AndyC » Tue Dec 26, 2017 3:44 pm

It means that BASIC will use that memory for the RAMdisk by default (as will +3DOS if you use it from machine code). If you aren't using BASIC however (or aren't using the RAMdisk capabilities) then you're free to use it as you wish (although +3DOS will use a small amount of Page 7 for various disk buffers, which you need to consider if you will access the disk drive - including during loading)
0 x

Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Screen switching, does it happen?

Post by Hikaru » Tue Dec 26, 2017 5:16 pm

As people have pointed out, this setup is fairly awkward to work with, and most of the time it's not even really necessary (unfortunately, there are exceptions).
Regardless, I think it might be interesting to hear opinions on how to plan out things across the pages etc for such a game.

Personally I'm going from the assumption that a game probably won't be using all the extra pages at once during the actual gameplay.
- Page 2 (#8000-#BFFF): main fast code that needs screen and/or page access. Shared variables/buffers used by additional code in 128K pages.
- Page 0, aka 'What's normally at #C000 on a 48K': main fast code, non-drawing, no paging access. Game logic/variables/buffers, AY music code/data and such like. This is the 'logic formation'.

So in the general case, your game would be doing something like this:
1. Set page 0, do game logic, play AY etc.
2. For extra code located in other pages, call it from #8000.
2. Call drawing code at #8000, set up screen paging as needed, draw stuff.

The rest of it is more specialized so it might not apply in the general case. There's the 'visual formation' with page 7 enabled. In this case, both page 5 (#5B00-#7FFF) and page 7 (#DB00-#FFFF) are dedicated to hold graphics data and drawing routines. These are filled down from #FFFF, due to the fact that the memory at #5B00-#7FFF is more universal and can still be used for paging purposes and sharing things across the pages.
The drawing routines should use both #4000 and #C000 screen addressing depending on which one is active. So this doesn't use the above paging scheme that alternates between the two screens at #C000. It is normally only a bit more work, involving just the switching of your coordinate-to-screen routine to use #40 or #C0 in the simplest case.
This setup depends on whether you can fit most of your drawing inside border time. In return, you get a cache of 18944 bytes for your graphics, which I think is a fair number.

You also have pages 1,3,4,6. The problem with those is that half of them would necessarily be contended. It's either 1,3 (Sinclair) or 4,6 (Amstrad), which may or may not call for model detection, as well as some awkward paging methods. Again, it depends on how many pages you need available at once, and where in the frame your code runs. For convenience, you might want to put your AY music stuff in one of those, which wouldn't slow you down if it's running inside your ISR (i.e. guaranteed border time), and I assume there might be more things like that. It might make sense to think of those more as extra storage space, and repurpose from there as needed.
1 x
Inactive account

Post Reply