Bottom Border with Floating Bus (is hard...)

I'm using the Floating Bus trick ( https://www.usebox.net/jjm/blog/zx-spectrum-floating-bus/ ) to change the bottom border.

Problem is it doesn't catch the beam at exactly the same time depending on what code ran before. So timings are different between sprite moving vs standing still. I've sort of got standing still and moving left/right timed.

And to make it worse, it's even effected by where the sprite is on the screen (it falls apart in this release if you move over to the left). Same with scoreboard, depending ono status it affects timings. I assume this is memory contention. Which makes things even more super complicated than just timing for moving vs not moving.

So for now I've just added a simple continuation of the main screen river into like a waterfall in the bottom border. It works to start with, and you can move sprite left/right with Q/W a little and it holds together. But it falls apart at edges, and ZX/OK/PL keys to change scoreboard can mess it up further.

Unless there's a way to catch the beam with identical timing every frame, no matter what code was run previously, this is just too complicated to do this way. You'd need an Atari 2600-style kernel with timings always aligned to the t-state in every path...

Sprite Added (bottom border WIP)

Added a sprite that scrolls with Q/W.

First attempt was all code-based shifting and flipping. Good learning, But it's just too slow for the 2/3 of the frame time I have to render with the borders, even with everything unrolled and optimized.

So I pre-rendered everything. Turns out my 4x2 sprite, 4x3 with offsets, only needs 1,536 bytes for all 8 offset frames plus flipped versions. And it's super fast, and super easy!

While doing the code-shifting version I learned how macros work, including local labels, and there's still one in the XOR code.

Also added floating bus tricks to try and do the bottom border. Thing is... it seems you can't just look for your trigger colour with the floating bus trick and be perfectly in-sync every frame. What happens during the main frame render affects exact timings, so you end up flashing in bottom border.

I tried adding multiple checks and it improved things... but it's still flashing. I suspect without going full Atari 2600 kernel you can't have perfect floating bus tricks. So it's fine for getting extra 56 rows of CPU instead of using interrupts, but maybe not for bottom border.

But I'm going to keep trying!

For this .sna the bottom border is turned off. Uncomment call to BOTTOM_BORDER_RENDER in sb_main.asm to see the current state of the bottom border.

Keys for lives & energy

Lives go up and down with Z/X keys. Energy with P/L.

Score for O/K needs some BCD maths so that's next.

But for now - it shows the engine handling the basic of being a scoreboard!

BCD Score

Added O/K keys inc/dec'ing the score, using DAA to correct the byte for Binary Coded Decimal (BCD) notation.

So the whole scoreboard works now.

Now... can I be bothered to make a demo game to show it off?

Basic Timings

Got the basic border timings down.

Top boarder draws directly from memory using OUTI and lots of fun timings. This is just blue/magenta stripes for now, but making it show score/status is just a matter of updating the buffer during the main game loop.

Then the sky boarder draws. This is only left and right. I did start just continuing the top boarder draw, wasting some memory, but the memory contention kicks in as the ULA starts drawing the screen, so I ended up just writing two columns on either side of the screen with custom timings, and not wasting memory as a nice side effect.

I used Gemini AI to create the main scene - as I can't even draw a cloud! I tidied it up by hand in MS Paint, as the AI didn't get the idea of having the sky take up exactly 32 rows - LLMs and numbers, amiright!? ;)

Then put the image through Spectra http://www.fruitcake.plus.com/Sinclair/Spectrum/Spectra/SpectraInterface_Software_ImageConverter.htm -- to make a binary file, which like a SCREEN$ is just 6,144 pixels followed by 768 attrs, which I can then INCBIN at ORG $4000 to be the screen.

Then I manually added border clouds. There are only 2 columns on either side, so it's very blocky, but it kinda blends in. It shows the concept - and someone who can actually do 8bit gfx could probably make it look really good.