The Definitive Programmer’s Guide to Using the Floating Bus Trick on the ZX Spectrum

[Ast A. Moore]

As promised, I did a write-up on the subject of the floating bus. Keep in mind that this document is in its first draft stage and thus in a state of flux. As more questions arise (and as I come up with better ways of presenting the material), I’ll try to augment it or even rewrite it completely.

Another point to keep in mind is that due to the nature of the subject, it’s impossible to keep the article equally entertaining for both experienced programmers and novices. The former might find several aspects of it too obvious—or even condescending—while the latter might feel it’s too technical and goes right over their head. To the more experienced bunch I say, tough tamales. If you’re a novice, however, and have more questions, don’t hesitate and ask them in this thread. Your questions (and the discussion they open) and suggestions will help me with a rewrite.

I hereby present to you:
“The Definitive Programmer’s Guide to Using the Floating Bus Trick on the ZX Spectrum.”

[Nomad]

[Ersh]

Bloody brilliant! Thanks!

[Seven.FFF]

Nice aticle, @Ast A. Moore. I pointed a couple of people on FB in your direction the other day, regarding the +2A/3 floating bus.

István Novák is making a Spectrum dev environment and emulator as a Visual Studio 2017 extension.

He has plans to eventually support Visual Studio for Mac OS too, so keep an eye on this project

[Joefish]

Interesting. But you mention the timing is critical to be sure of reading attribute bytes rather than pixel bytes, but don't explain what that timing depends on. I don't know, but here's a guess - are you relying on contention of the IN instruction itself?

Also, presumably you could plant the value '255' in contended memory, then read it back, and that value on the floating bus would let you detect the top-left of the screen whichever machine you were on?

[Wall_Axe]

thanks, so it seems you have to detect if the machine is a 2+a and then implement the new floating bus routine

[Ast A. Moore]

Nice article, Ast A. Moore. I pointed a couple of people on FB in your direction the other day, regarding the +2A/3 floating bus.

István Novák is making a Spectrum dev environment and emulator as a Visual Studio 2017 extension.

He has plans to eventually support Visual Studio for Mac OS too, so keep an eye on this project

Thanks, Robin! I’m not on Facepalm , so if you could also link them directly to my article that’d be great.

As for a development environment, I think I’m all set for now. Günter and I (well, Günter mostly, obviously) are working on adding TZX support to zasm as well. When that’s done, I won’t even be needing Tapir, as adding TZX blocks will be done straight via assembler directives. It always fills my heart with joy when people actively work on any Spectrum-related cross-platform solutions, though. So kudos to István for putting in the hours. (And it’s a lot of hours; I know that from working on my syntax highlighter for zasm.)

[Ersh]

If the CPU is suspended for 4 T-states while the ULA fetches bitmap, attr, bitmap, attr. When the CPU is released shouldn't every read of the port be that last 'attr'? Clearly that's not the case, just wondering how that works. Also how is the well-timed loop 'synchronized' to always get the attr? It takes a certain amount of T-states but doesn't it need to start at the right time as well?

[Ast A. Moore]

Interesting. But you mention the timing is critical to be sure of reading attribute bytes rather than pixel bytes, but don't explain what that timing depends on. I don't know, but here's a guess - are you relying on contention of the IN instruction itself?

If you’re referring to the +2A/+3 code, then the port itself doesn’t seem to be contended. The LD A,(NNNN) instruction is what affects the timing, as reading from a non-contended address will break the sync.

Also, presumably you could plant the value '255' in contended memory, then read it back, and that value on the floating bus would let you detect the top-left of the screen whichever machine you were on?

Not quite. You see, it doesn’t make a difference whether you read or write it. Once it appears on the bus, the bus will latch it. Moreover, it doesn’t have to be 255; it can be any value that is different from what appears on the screen outside (ahem, inside, rather) the border. Other than that, sure, there’s nothing stopping you from detecting the top of the screen using this method. (Of course, reading is faster, because you’d need to load A with a value before writing it to a memory address.)

I think I’ll include a more illustrative example—similar to the one I used in my test originally back in 2017. I intentionally filled the top two thirds of the screen with the bitmap pattern consisting of the same value as my attribute test byte. The entire loop, including the padding instruction, was meticulously crafted to avoid syncing to that bitmap pattern.

[Ast A. Moore]

thanks, so it seems you have to detect if the machine is a 2+a and then implement the new floating bus routine

Yes. That’s exactly what I did in my tests and Yankee. I test the machine type, then inject different values into the timing loop via self-modifying code. Well, the default loop is tailored for the +2A/+3, so if the architecture check determines it’s not a +2A, then the code of the loop is modified to suit the 48K/128K/+2.