BBC BASIC 3D 10 PRINT - The Crunching

Of course, I wouldn't let it lie. I couldn't resist a bit of crunching on the program! Final score is 144 bytes, including the BBC setup bits (66 without).

[@10p6]

Change the line number to single digit to save another byte.

[@archibaldbuttle7]

So this turned into a puzzle I couldn't resist! 🙂 I started out with the code as it was at about 7m into this video. My first discovery was that VDU 22 can replace the MODE statement, allowing it to be combined into the mega VDU statement shaving off a few more bytes. As @GeorgeFoot and @kaminutter pointed out, the FOR loop can be got rid off. When considered in the context of the outer REPEAT loop, and we're in a 40 column screen mode, what it does is stop B from getting inverted at the beginning of each line. I replaced it with IF POS > 0 THEN B = -B allowing the other B=-B to be got rid of. As George also suggested you can also avoid subtracting 1 from Z, saving another couple of bytes. Using an IF statement meant I had to use two lines, but it still saved a few bytes and my end score was 137 bytes. George's suggestion of using lower value characters should give a few more, but as I'd started from the pre-crunched VDU statement I haven't tried that. It also feels like there should be a way of avoiding the IF statement by using some alternate maths logic for working out the colours, allowing the code to be a one-liner, but my BBC BASIC skills are covered in 30+ years of rust and I haven't had enough coffee. 🙂

[@lsbyte]

The problem with using VDU 22 is that doesn't alter BASIC's HIMEM and your stack will be left somewhere in screen memory, if you don't fix it. The IF idea is good although I can't see how to get something else on the same line - I'm not sure what the rules are here: if you end up with something smaller across two lines, does that win? ;-).

[@archibaldbuttle7]

@@lsbyte ah - the HIMEM thing explains why i get a tiny bit of screen corruption. Thanks for explaining that - I'd been studiously ignoring it. ;-) Curiously it seems I was wrong about using VDU 22 giving some savings - on changing it back to use MODE it's 2 bytes smaller!

[@lsbyte]

It's the same mistake I made thinking VDU 17 was smaller than COLOUR. Those sneaky tokens!

[@HatStand1000]

Use VDU 22,1 to change to Mode 1 and add the VDU command into the other VDU commands

[@dcocz3908]

Replace UNTILFALSE with UNTIL0

[@kaminutter]

I changed the code to remove the for loop statement for a if pos=0 then b=not b not sure if this saves anything but the output still works. Never thought about combining vdu statements to 16 bit digits before.

[@lsbyte]

I thought about doing something with IF but the problem is you then can't put anything further on the line (as the bits are the colon are part of the IF).

[@KaosSchmoo]

Do you need a line number if there is only one line?

[@archibaldbuttle7]

You do for it to be a valid BBC Basic program, rather than just a one line statement. It needs to be a program to be able to measure the size of the code (PRINT TOP-PAGE). I did wonder if changing the code to use of line number 1 instead of 10 could save a byte, but a quick check shows me that's not the case.

[@lsbyte]

Yep - I think line numbers are always two bytes. And, if it's not a program, I can't save it (well, maybe to a *SPOOL file, but then I lose the tokenisation saving!).

[@GeorgeFoot]

You could define lower value characters instead of 240 and 241. Also maybe there's a way to get rid of the nested loops? Maybe B=128*((POS+VPOS)AND1) then you don't need the C loop? Also don't subtract 1 from Z, adjust the rest instead

[@lsbyte]

Not subtracting 1 from Z is a good idea and I've saved a byte or two with that. I think VPOS probably won't work, though, as it'll go wrong at the bottom of the screen (when VPOS stops increasing) but I have done something similar with POS=0 to get rid of the inner loop. Down to 140 bytes now!