New Trick And No Treat - A Cautionary Tale

When dealing with hardware like the ST, one of the most valued currencies back in the day were the so-called "hardware tricks"¹. The limitations of the ST were so severe, that everything that helped mitigate that, even a little, was very, very welcome. May this be bigger 800k floppy disk formats, mixed resolutions, buzzer/digi-/SID-sound, the various overscan types and of course the king of the playground - hardware scrolling. Especially the last one was very shushed about by the people in the know and if one managed to catch a glimpse of how that specific magic machinery worked - oh boy, it was mind-boggling.

I am sure we all remember seeing the TCB Fullscreen, the ULM Scroller Fullscreen or hearing the buzzer or even YM-SID-sounds for the first time - this sense of the world expanding, like literally, is hard to explain - let alone to reproduce. The fact that this machine still produces new hardware tricks up to this day - like various new YM effects, generalized 4-bit hardware-scrolling, new screen resolutions just to name a few, is simply astonishing and keeps the platform interesting and challenging at the same time.

That's why the idea came up to take you, dear reader, on a small journey to where a new hardware trick gets discovered - and then even further down into it's ultimate culmination in... failure.

When Conversations Go Boom

Let's rewind a bit. The whole thing starts with James Boulton² doing a post on X showing his new shifter-replacing graphics card experiments³ that claims to support all the nifty overscan tricks and alike. Always searching for new solutions to get a future-proof-ish picture out of our system my interest was instantly piqued and I contacted him to ask if this thingamajig really would support all of the display tricks and that he probably for sure had missed at least one of the later techniques how dares he, I want my perfect display solution, I want it, like, now, etc. etc. 

James - being the nice guy he is - replied calming down my fears, saying I shouldn't fret, he will check, all of the tricks work or at least can be made to work easily.

Just when exhaling in relief, I caught a glimpse of this sentence: 

"I just discovered yesterday that you can reset the screen address to 0 at any time on STFM by using the 68k reset instruction".

I stopped. Read again.

That's just some curious thing, right? Right. Could not be used for anythi... wait.

A bit of conversation ensued, with me finally asking if I could do some tests using his discovery - because I could not get rid of that nagging feeling that it could be useful.

Into the MMUnknown

Bare with me while I try to explain for a moment what exactly the above sentence means in the hardware trick world - if you (for obvious reasons) aren't interested, just skip to the next "Anyhow".

When the ST displays his image, there is a tight-knit machinery of several chips involved. One is the shifter that basically produces coloured pixels onto the screen from a palette and a few bytes of data. The data converted into pixels stems from a location determined by the MMU; it keeps track of what data was read and put onto screen, and basically then orchestrates the next data to be displayed - and so on and on for every 16 pixels until the display area ends⁴.

Why is this important? Because it's more or less an affair you can't really interfere in usually; it starts it's thing on the beginning of the screen, stomps through, goes back to the top, doing it again etc. Only between two of those consecutive frames the software can e.g. change the RAM position, where the screen is read from.

Now, what the spoiled STE and Amiga users can do, is changing the RAM position at will, anywhere in the screen, meaning: during display. 

Let's imagine a top-down racing game with two players; on the STE one can just do all the scrolling for the upper player screen and set the RAM display position to the one of the second player map in the middle of the screen (a so-called screen split) and scroll that one independently, too.

The ST, however, can't do that⁵. The poor CPU has to copy all the data by itself.

But that's where James' discovery comes in - we use the RESET instruction at a pre-determined time, which pulls the RESET line low for 124 clock cycles and subsequently (more or less indirectly) resets the MMU. If James' observation was correct, we could change the screen address mid-screen on a plain ST at will!

I'll let that sink in.

Anyone still with me? No? Okay, I'll admit I might be a bit over-excited just there. But let's see how the story unfolds.

Anyhow

Anyhow - as it's always the case with things in general, they aren't as easy at it seems. When starting to test this newly lend-to-me superpower of "setting the screen address mid-screen to zero" (that's the official name of this trick for now) it became clear pretty quickly, that something was off. The screen split worked on my Mega ST, and another 1040STF, but not on a load of other machines.

At first, I thought the MMU synthesizing the RESET signal from other inputs (there's no RESET pin on the MMU) could be the culprit, as in: some state the MMU sees could be different, so it synthesizes a RESET on one machine, but not on the other. Frantic testing with several machines and states ensued. Spoiler alert: boy, was I wrong.

But first we should talk about the other elephant in the room: how does having a screen address of 0 (yes, that's zero) help us with anything? I mean, RAM addresses $0-$7 are read-only⁶, $8 is the start of all the (interrupt) vectors the CPU needs, followed by TOS variables, only quieting down a bit after $500. Even after ditching the system (which every responsible democoder should) we're only safe after $140 or so, leaving still at least two scanlines worth of garbage that taints our screen after the split. Not ideal at all. But. Except for "rare" cases like HBL/digidrum/sidsound we don't need any of this during display. We might want the VBL irq address at $70 - but on the other hand we don't really need it though, we could e.g. poll the current screen address instead if waiting for the VBL, so we are fine for the rest of the display⁷. The only "garbage" on screen we can't control is $0-$7 then. But let's just assume we can hide that for now (either via black palette or by other means).

Now that we successfully removed that garbage from our spectators line of sight, we are ready to go: we finally can set up the second screen at $8, do our screen split at say line 100 via RESET and have two independent screen addresses on-screen on a bog-standard ST.

Yay?

There's even more one could think of doing with this, like hardware-scrolling for example.

Could. If it weren't for the gruesome things I am about to report in just a second. But before that let me just take a breath, reach over to take Damo's hand (who's sitting at the  table next to me, possible due to the curtesy of Buxton Bytes, which is being in full swing around me as I write this), so I'm not alone while recollecting the scary and gruesome facts.

The reader might recollect that there were problems to get it run on a lot of machines. It worked on my Mega ST for example. On James' Mega ST. On one other STF. Three machines out of 10+(ish) tested. Sparing you the long-winded search story, let's cut to the chase:

The Ultimate Failure

It only works on IMP MMUs.

....yay.

Non-IMP MMUs (or "Ricoh MMUs", being the most seen kind of MMU by far) do not show the same reaction to RESET as IMP MMUs. In fact, I can't be sure if it does not detect it or just reacts differently - but the point stands, the screen address counter does not get reset.⁸

So what's left to say - a new, shiny ST hardware trick discovery turned out to be an ultimate failure due to only supporting like 10%⁹ of the machines available. You can't impress ST demo lovers all over the world if they can't run it on their machines, can you.

Apart from that there are a few other downsides to this: the RESET instruction is connected to a lot of other chips that are stopping their regular work - 50 times a second. This means, that e.g. the keyboard is not working¹⁰ and it will get pretty interesting to get sound of the YM while it is interrupted that often. While one might be able to do suitable workarounds for both downsides, the fact that RESET spreads through the whole system even as far as to ACSI devices, it might be possible that a RESET bombardement at 50hz might have side effects on that hardware and/or storage.¹¹

Silver linings?

But this would not be a good story if there wasn't some unexpected turn of events right? Well, there's at least one silver lining: the Shifter also seems susceptible to reset. As in: it loses its internal counters and starts its work anew, even while working on a 16px block. It hasn't been tested on enough Shifter revisions yet, but there is a strong indication that 4px hw scroll might be possible using RESET. It could even be independent of GLUE/CPU-wakestate and shifter-wakestate. But that's the subject of another article (and a lot of behind-the-scenes discussion).

¹ and Amiga jokes, but that's another article
² of SainT, Lynx/Jaguar GameDrive and quite some more fame
³ this is so awesome!
⁴ of course the GLUE plays an important role, too, but it's not really something that would shine as an anecdote at a party, so we skip it here
⁵ and as we already know: "the ST can't do that" is rarely accepted by ST coders
⁶ not really RAM to say the truth, but the first 8 bytes of ROM blending in here
⁷ and of course we can race the beam and set/restore the irq vectors/display data as needed
⁸ I asked our resident chief of hardware and all things chip decaptivation, Ijor - and he confirmed the suspicion that the Ricoh MMUs indeed have a much more reduced RESET circuit
⁹ guesstimate, might be 9%
¹⁰ except if you are lucky and own a Mega ST - the keyboard cable has no RESET line and the IKBD is inside the Mega ST keyboard, so no way it gets reset by software
¹¹ which is also the reason why there's no example code coming with this article - it might not be safe to run such code