BBC Micro and Acorn Electron demo effects

[tricky]

Very nice, it's good to see one that isn't just horizontal (like all mine!).

[oss003]

Hi,

Great demo but are you willing to upload the source code so that I can test it on the Atom?

Greetings
Kees

[davidb]

Nice and smooth. Well done!

[FourthStone]

very nice demo

[0xC0DE]

Thanks everyone, nice to hear!
I have the Starfield demo running on my trusty Electron next to me while typing this. It's very soothing and a great screen saver

@Kees: I haven't given much thought to releasing my source code yet. I will PM you the essential parts of my Starfield demo so you can try to get it to run on an Atom.

[Elk2019]

0xC0DE. An amazing piece of coding and a great screen saver too! Reminds me of L/R view in ELITE and opening titles of classic STAR TREK series. It certainly has a calming effect and demonstrates what is possible on the Elk. Well done!

[marcusjambler]

Cool Demos....

[0xC0DE]

Thanks guys. I really appreciate it!

[Mr B]

I've just got to say - where were you 20 years ago on the electron Some amazing stuff!!!

[0xC0DE]

Thank you Mr B!
Let's see. 20 years ago I had already moved on to PCs and my Electron was safely stored away in the loft
However, 35(!) years ago I played many games on the Electron, tried writing my own games in BASIC and dabbled unsuccessfully in 6502 machine code. Dreaming about creating the things I do for a hobby now. I couldn't have created these demo effects back in the day. Funny how things turn out!

[Dethmunk]

Thank you!

if you can just get the Electron ULA to play a decent tune

Now there's a challenge!

Has anybody ever gotten a decent tune out of the Electron's speaker?
(any particular game with an outstanding tune I should check out for example?)

The Electron has had some ok tune-age...
FRAK! rendered some nice tunes...
https://youtu.be/0oADqPx5Bv0

Zalaga had some decent little ditties...
https://youtu.be/TGZalhQ3v6E

[0xC0DE]

Finally, a new demo effect: RACING THE BEAM

This one will only work on an Acorn Electron (from tape or disk), not on a BBC.
I have only tested it with MMFS (PAGE=&1900).
It will NOT work 100% correctly on any existing Electron emulator; only on the real machine!

Technical details:

• MODE 2

• 50 fps

• Extreme cycle counting, i.e. racing the beam

• Detects even and odd fields of the interlaced display

Future experiments:

• Trying different 'flows' >> done! see below

• Playing a tune >> done! see next post

Enjoy! And please report any glitches you may find.


Electron disk:

racingthebeam.ssd

(200 KiB) Downloaded 113 times

Electron tape:

racingthebeam.uef

(14.33 KiB) Downloaded 106 times

Update: trying a different shape/flow:

racingthebeam.ssd

(200 KiB) Downloaded 87 times

[0xC0DE]

As an initial proof of concept I have now added a catchy tune. So this is officially my first demo with music.
NOTE: The music was originally written by Orlando for the Electron version of Frak!.
It's one of the better tunes I have ever heard on the Electron's speaker. Same goes for the (hidden) tune in Zalaga (also by Orlando).

Does anybody know of any better music on the Electron?

Technical info: instead of translating Orlando's (BASIC) music program into machine code, I "recorded" the tune with my Electron emulator by saving all writes to &FE06. This raw data (just over 1Kb) is then played back in my demo. The original program uses SOUND and ENVELOPE which I cannot use anyway because MOS is disabled in my code.

Demo with tune:

racingthebeam.ssd

(200 KiB) Downloaded 85 times

racingthebeam.uef

(14.33 KiB) Downloaded 94 times

Edit: watch it on YouTube now: https://www.youtube.com/watch?v=1sm_0msFCzA

[0xC0DE]

"VERTICAL BARS" demo effect on the Acorn Electron.
Will work on the real machine and on any Electron emulator as well.

Tech info: MODE 2, 50fps, buttery smooth animation in various directions/colours/speeds/sizes/splits.

Electron disk:

verticalbars.ssd

(200 KiB) Downloaded 106 times

Electron tape:

verticalbars.uef

(13.97 KiB) Downloaded 89 times

YouTube: https://www.youtube.com/watch?v=b67lBEbNZEg

[tricky]

How about sneaky mirror alternate columns for the middle one

[0xC0DE]

How about sneaky mirror alternate columns for the middle one

I may be able to do that but I'm struggling to understand what exactly you mean by that

[Elk2019]

Absolutely amazing effects you have created on the humble Electron. Who said the Elk could not manage smooth scrolling? I remember an effect I saw on the C64 BITD where the coder would display a bitmap image & then move it around. Would this be possible on the Elk or Beeb?

[0xC0DE]

Thank you. On the Beeb definitely. On the Elk: depends on the size of the bitmap and the screen mode.

[0xC0DE]

Who said the Elk could not manage smooth scrolling?

Also, see if you can figure out how the smooth scrolling is actually achieved
Hint: not all is what it seems....

[Doctorj1]

Who said the Elk could not manage smooth scrolling?

Also, see if you can figure out how the smooth scrolling is actually achieved
Hint: not all is what it seems....

Quick palette switching?

[0xC0DE]

You are on the right track. However, quick colour palette changes are not necessary. Once every frame (or rather, field) is enough.

[ThomasHarte]

It will NOT work 100% correctly on any existing Electron emulator; only on the real machine!

I dispute this claim.

... and since I haven't changed anything in the timing on the Electron part of my emulator in a few years, I backdate that to 2019. All I did was download the demo and run it, no tweaking was involved, no changes will be forthcoming.

EDIT: I'll try to grab a video later but, for the record, that correlates with this moment in the real-hardware video:

[tricky]

I can't think how to do it with only one set of palette changes.
Does it look good a scan line at a time?
Do you get any CPU in MODE 0-2 while the beam is off-screen per scanline?

[ThomasHarte]

Do you get any CPU in MODE 0-2 while the beam is off-screen per scanline?

Yes — on lines with pixels you get 1Mhz access to RAM in the border region, i.e. 24 cycles/line.

[0xC0DE]

I dispute this claim.

Could you try this one as well?

viewtopic.php?f=64&t=18431

[ThomasHarte]

I dispute this claim.

Could you try this one as well?

viewtopic.php?f=64&t=18431

Alas something seems to be off with that; I guess I don't quite have one of my interrupts properly placed horizontally. The ball bounces up and down properly, and the raster bars look correct, but it flashes between being in its proper position and being split over the edge of the screen. Which I assume to mean that my emulator is misplacing the mode split, and that's where I make the guess about horizontal placement.

Changing my placement is supposed to be as simple as tweaking a constant, if indeed that's the real problem. This section of code is a bit more embarrassing to me than many because I restarted emulation to get up to speed on modern C++ and this is very early code from that effort, but the constants I'm using are here, i.e. within a complete frame — two fields — I'm signalling the real-time clock interrupt at cycles 16704 and 56704, and the end-of-display at 36736 and 76672. If you take those numbers modulo 128, the first graphics fetch occurs at cycle 33.

So I have the two end-of-display interrupts occurring 33 cycles before pixels occur [@2Mhz], the first real-time clock occurs 31 cycles after pixels began on its line, and the second — like the horizontal positioning of end-of-display — occurs 33 cycles before they began.

If you can see any obvious issues with those numbers, let me know! Otherwise the bug is obviously more nebulous. And sorry for the minor thread hijack!

And: mode (and palette) changes always take effect immediately, which it strikes me now might or might not be true.

Typing completely extemporaneously: I'm also curious as to whether I'm doing what hardware would do if there's a 40 <-> 80 mode split on the final line of a character row with regard to updating the address. If the logic is what feels easiest, that on lines 1–7 of a character row a row start address is incremented and reloaded, and on line 8 the final counter is stored back to that row counter, then you could get smooth horizontal scrolling so I guess probably not? E.g. switch from a 40-column mode to an 80-column mode eight 40-column character from the end of the display, the display will consume 16 bytes instead of eight for the rest of the line and then on you'll have offset the video address by 8, i.e. one character square.

Have you poked at that on real hardware at all?

EDIT: it was hard to grab a clean shot, but this shows the errors in rendering currently in my emulator; the mostly-gone basketball in the middle is the end of a correct period of correct placement, and the more solid one at the outside is the beginning of a period of incorrect placement.

[0xC0DE]

Typing completely extemporaneously: I'm also curious as to whether I'm doing what hardware would do if there's a 40 <-> 80 mode split on the final line of a character row with regard to updating the address. If the logic is what feels easiest, that on lines 1–7 of a character row a row start address is incremented and reloaded, and on line 8 the final counter is stored back to that row counter, then you could get smooth horizontal scrolling so I guess probably not? E.g. switch from a 40-column mode to an 80-column mode eight 40-column character from the end of the display, the display will consume 16 bytes instead of eight for the rest of the line and then on you'll have offset the video address by 8, i.e. one character square.

Have you poked at that on real hardware at all?

Just to let you know: this has been in the back of my mind, trying to fight its way to the front. In theory / on paper this (smooth horizontal scrolling, 1 byte at a time) sounds completely possible. I am going to try this on real hardware, starting from a stable raster so I have complete control of every cycle for precise timing. Will let you know what happens!