I was pretty active in the BBC Scene at the time and had a front row seat to a whole pile of the backstory here, and yet I do not recall anybody that pulled this off in a stable and reproducible manner (T1 + some 6845 register hacks).
The problem was that timing the switch point in software was fraught with trouble because you just might end up making the switch at the wrong moment which caused it to jump vertically (or garble a part of your screen). The other problem was that if you wanted perfect timing it was possible but that left you without enough cycles to run your game. Braben & Bell solved this to the point that it was considered stable enough for inclusion in production. Similar hacks had been done on the Atom prior to the BBC so it wasn't as if the knowledge wasn't out there but no game publisher had - as far as I know - seen fit to release a game that used it.
It would be great if you could answer this and point out exactly where this was used prior to Elite on the Beeb, that would set the record straight on this once and for all.
I agree, I think Elite was the first commercial example of a split-screen mode on the BBC. It does flicker a bit at the switchover point when the disk is being accessed, as it is interrupt-based, but it's not too bad. There’s lots of detail on how it works here:
My favourite inplementation of this technology is in Geoff Crammond's Revs, which doesn't flicker at all, as the palette switches are cleverly done where they won't be seen if they aren’t perfect. Read all about it here:
What really gets me about this whole discussion is that lots of this stuff feels like yesterday to me. And yet, it's been almost 40 years. Mnemonics and register offsets for peripherals are all jumping to attention for immediate use. But don't ask me what I ate last week...
I am prettty sure I could write a decently sized Z80 or 6502 program for the Beeb or the Speccy from scratch without reference, or at least a decent set of 3D transformation functions. I could not tell you how to load a JSON file from a folder in Python if my life depended upon it. I have to write that latter code on an almost weekly basis. I will say that the internet and instant access to online references has absolutely destroyed my memory more than any amount of age or caffeine.
I think in part this is because the size of the building blocks has gone up tremendously. In the dark ages you'd write roughly as much code for your program as there was ROM in the machine to begin with. That balance made it possible to 'know' every byte of the map and to have an intimate understanding of the software that came with your machine, it's CPU and how it all hung together.
The balance has shifted to the point where your program is likely only an extremely small fraction of the total that is running on your machine and that powers your application. So it has simply become impossible to be that familiar with the remainder.
Having given this quite some thought over about 20+ or so years, and having written a little on the phenomenon, purely as an layman in psychology but as a professional in software development, and observing many developers, and myself as well, I have to strongly disagree on the point you make, but am open to discussion on the matter.
I believe that assistive technologies, from the most advanced tools we have today, to the most mundane of "hinting of parameters to a function" and code base navigation via "jump to definition/declaration" which first started appearing in Visual C++ 6.0 around 1998 there has been a degradation in committing facts about the architecture of the code and functions and APIs to memory.
This isn't a case of "bah humbug, the youth of today and their fancy geejaws" but very much a case of "why bother remembering that when the machine will remind me." I am sinful of this too. Guilty, as charged, m'lud.
My conclusions are very much observational but also align with the scant amount of professional research done on the subject. For confirmation bias, I recommend the Outer Limits episode "Stream of Consciousness."
I note that there are four areas in life where this is occuring most profoundly: cooking, navigation, software development, telephone numbers (and other contact details). Whilst it has been many years since I could tell what every cycle, byte and register was doing in any reasonably complex system I work on, I can still walk through most of what is going on in a system from the silicon running the code to the UI appearing on another person's screen on the other side of the world.
It isn't the understanding, it's the remembering what that function was called again, and where did I put that function I wrote ten minutes ago?!? And it isn't age related, because I've tested that hypothesis too both on myself and on others. Assistive technologies are wonderfully enabling, but they make us dumber.
I'm more than willing to concede that that memory assist is also a factor. But the amount of data is so large now that that too has a role, even if you really wanted to remember all of it you probably could not.
I can see the difference in my own head: the knowledge I have about the 8 bit systems that I worked on is pretty much complete, from the hardware schematic, instruction set, memory map, ROM contents all the way up to whatever code I wrote back in the day.
As opposed to the UNIX systems that I worked on, which for me really predated any assistive tech because I didn't use any. But my knowledge about the C-standard library, while good is not 100% coverage and I know I occasionally have to look up the parameters to various functions.
And then we come to today, where for my current project (pianojacq.com) I still don't use any assistive technologies (no, seriously) but I also know that I do not know more about the runtime environment than I absolutely need to get the job done.
I don't have a smartphone, obviously I'm getting older as well but my own code I know inside out, for all of those phases.
I don't recall if Elite was the first game or not to have stable mixed mode. It was most likely the first, and once demonstrated, other developers implemented the idea too. I recall that the mode 4 of Elite wasn't strict mode 4 because they wanted a certain amount of pixels that would divide evenly by a number, so when the interrupt fired, the mode could be changed. It's been a few years since I worked on the Beeb.
You probably already know this, but to fill in context the screen would flicker because the NMI that handles disc IO would fire, and would be serviced before IRQ1 if both fired together, and also you cannot interrupt an interrupt.
BBC Micro Advanced User Guide pages 359 and 370 detail the 6845 and ULA demonstrated Mode "8" and I recall Practical Computing and Acorn User also had listings for doing tricks with the interrupts and the mixed mode, though don't ask me issue numbers.
I picked a random video of yours "ABug 09 Explaining Elite" and jumped forward to 2:22 to skip the intro, and said "oh, that's a matrix transposition function" when the code popped up on the screen. It's funny how some of that crap sticks with you.
The problem was that timing the switch point in software was fraught with trouble because you just might end up making the switch at the wrong moment which caused it to jump vertically (or garble a part of your screen). The other problem was that if you wanted perfect timing it was possible but that left you without enough cycles to run your game. Braben & Bell solved this to the point that it was considered stable enough for inclusion in production. Similar hacks had been done on the Atom prior to the BBC so it wasn't as if the knowledge wasn't out there but no game publisher had - as far as I know - seen fit to release a game that used it.
It would be great if you could answer this and point out exactly where this was used prior to Elite on the Beeb, that would set the record straight on this once and for all.