Bouncing Basketball tech demo on the Acorn Electron

[0xC0DE]

The possibilities are endless now that I am officially "Master of the Electron raster"

Here is my Bouncing Basketball tech demo on a standard Acorn Electron.
https://youtu.be/PUl1SGUSkbI

Tech info: MODE 1, 50fps, smooth hardware scrolling (not just 1 character row at a time), multiple colour cycling bars in background and foreground, stable raster with 100% perfect cycle counting.

Edit: try it on your own Acorn Electron (will NOT work on any emulator) with this ssd:

basketball.ssd

(200 KiB) Downloaded 151 times

[kieranhj]

You’re just showing off now.

Any chance of an ssd now I’ve got my Elk set up with an SD64 plz?

Looking forward to what you come up with next and maybe a full length demo for NOVA2020...?

[roland]

How to draw a basketball .... that would be my first challenge. And after that ... make that ball bounce. I really shouldn't know where to start. Impressive what you get out of an Electron


Is there any chance that you combine some of your demos to one sequence that I can run from an MMC card? I am trying to start a Retro Computer User Group in my area and a combination of your demos would really be great to show to the public.

[0xC0DE]

You’re just showing off now.

Any chance of an ssd now I’ve got my Elk set up with an SD64 plz?

Looking forward to what you come up with next and maybe a full length demo for NOVA2020...?

Definitely showing off!

I will add the ssd to my original post tonight.

NOVA2020 sounds great but I can't promise anything!

[0xC0DE]

How to draw a basketball .... that would be my first challenge. And after that ... make that ball bounce. I really shouldn't know where to start. Impressive what you get out of an Electron


Is there any chance that you combine some of your demos to one sequence that I can run from an MMC card? I am trying to start a Retro Computer User Group in my area and a combination of your demos would really be great to show to the public.

Thanks Roland!
I will let you in on a little secret: I didn't draw that basketball myself!
I just find a suitable image and then process it with GIMP and BBC Micro Image Converter.

I think it's great that you are starting a retro group in your part of NL!
I have quite a few demo effects and one real demo for the Acorn Electron now.
It's not that easy to just string a few demo effects together but I could provide separate ssd files if you tell me what you are looking for.
My one and only real demo is Bad Apple for the Electron. But it's only tested on MMFS (not on DFS and not on any other SD-card solution).
What is the configuration of the Electron that you will be using?

[oss003]

Looks great .... and fast ....

This reminds me at an Atomic demo I made years ago ....

https://youtu.be/WJzOTKMsNyE

Greetings
Kees

[0xC0DE]

Looks great .... and fast ....

This reminds me at an Atomic demo I made years ago ....

https://youtu.be/WJzOTKMsNyE

Greetings
Kees

Thanks Kees! Yours looks great as well. A tribute to Amiga Boing Ball, right?

[0xC0DE]

ssd added to original post

[roland]

I think it's great that you are starting a retro group in your part of NL!

Yes, I need a retro group since the Atom User Group has died in November 2019
I am cooperating with XP2002 on this forum to set up new meetings for all retro computers and also game consoles from BITD. It turned out he lives only 5km away from me

I have quite a few demo effects and one real demo for the Acorn Electron now.
It's not that easy to just string a few demo effects together but I could provide separate ssd files if you tell me what you are looking for.
My one and only real demo is Bad Apple for the Electron. But it's only tested on MMFS (not on DFS and not on any other SD-card solution).
What is the configuration of the Electron that you will be using?

My Electron has MMFS (a small card reader hooked up to a user port board, fitted in my Plus1). If chaining the demo effects is not easy, perhaps a menu on the MMFS with the demos is also usable for demonstration purposes. IIRC the Electron can also be configured to run a !BOOT file on break, right?

[julie_m]

It's certainly impressive! The timing of the bounces feels right; I don't know whether you're solving the differential equations on the fly or just using a pre-calculated list of positions, but either way it's impressive.

By the way, have you ever tried creating graphics on an Amstrad PCW8256 with its amazing 720 pixels over 256 scanlines, each individually-positionable in memory?

[roland]

This reminds me at an Atomic demo I made years ago ....
https://youtu.be/WJzOTKMsNyE

I completely missed that demo on the Atom .... is it on the software archive?
I'd like to see this running on my 8MHZ FPGAtom

[0xC0DE]

It's certainly impressive! The timing of the bounces feels right; I don't know whether you're solving the differential equations on the fly or just using a pre-calculated list of positions, but either way it's impressive.

By the way, have you ever tried creating graphics on an Amstrad PCW8256 with its amazing 720 pixels over 256 scanlines, each individually-positionable in memory?

Thanks!

Yes, doing partial differential equations on the fly ... here they are:

Code: Select all

.bouncedata
  equb 82-82
  equb 82-82
  equb 82-80
  equb 82-78
  equb 82-76
  equb 82-74
  equb 82-72
  equb 82-68
  equb 82-64
  equb 82-60
  equb 82-56
  equb 82-50
  equb 82-44
  equb 82-38
  equb 82-32
  equb 82-24
  equb 82-16
  equb 82-8
  equb 82-0
  equb 82-8
  equb 82-16
  equb 82-24
  equb 82-32
  equb 82-38
  equb 82-44
  equb 82-50
  equb 82-56
  equb 82-60
  equb 82-64
  equb 82-68
  equb 82-72
  equb 82-74
  equb 82-76
  equb 82-78
  equb 82-80
  equb 82-82
.endbouncedata

Sorry, never used any Amstrad!

[0xC0DE]

I think it's great that you are starting a retro group in your part of NL!

Yes, I need a retro group since the Atom User Group has died in November 2019
I am cooperating with XP2002 on this forum to set up new meetings for all retro computers and also game consoles from BITD. It turned out he lives only 5km away from me

I have quite a few demo effects and one real demo for the Acorn Electron now.
It's not that easy to just string a few demo effects together but I could provide separate ssd files if you tell me what you are looking for.
My one and only real demo is Bad Apple for the Electron. But it's only tested on MMFS (not on DFS and not on any other SD-card solution).
What is the configuration of the Electron that you will be using?

My Electron has MMFS (a small card reader hooked up to a user port board, fitted in my Plus1). If chaining the demo effects is not easy, perhaps a menu on the MMFS with the demos is also usable for demonstration purposes. IIRC the Electron can also be configured to run a !BOOT file on break, right?

Sending you a private message....

[julie_m]

Am I right in thinking that the actual basketball itself contains only 3 colours; leaving you a fourth palette entry to use for where the "rainbow" lines pass in front of the ball? Or am I going in totally the wrong direction there?

[0xC0DE]

Am I right in thinking that the actual basketball itself contains only 3 colours; leaving you a fourth palette entry to use for where the "rainbow" lines pass in front of the ball? Or am I going in totally the wrong direction there?

Almost correct! The rainbow bar in front of the basketball is where all 4 colours are changed. The rainbow bars behind the basketball is where only one of the four colours is changed. The basketball itself can only use a maximum of 3 colours this way.

[julie_m]

Almost correct! The rainbow bar in front of the basketball is where all 4 colours are changed. The rainbow bars behind the basketball is where only one of the four colours is changed. The basketball itself can only use a maximum of 3 colours this way.

Right ..... so the colours are "transparent" for the background, and red, yellow and black for the ball, which is initially a static image in screen memory; then in between each scanline and the next, you are setting the palette as required (all 4 colours if the rainbow is in the foreground, just the background colour if the rainbow is in the background, and the background is black between the rainbow bands) and between each frame and the next you are setting the "beginning of screen" address so the ball appears at the desired height?

[0xC0DE]

Almost correct! The rainbow bar in front of the basketball is where all 4 colours are changed. The rainbow bars behind the basketball is where only one of the four colours is changed. The basketball itself can only use a maximum of 3 colours this way.

Right ..... so the colours are "transparent" for the background, and red, yellow and black for the ball, which is initially a static image in screen memory; then in between each scanline and the next, you are setting the palette as required (all 4 colours if the rainbow is in the foreground, just the background colour if the rainbow is in the background, and the background is black between the rainbow bands) and between each frame and the next you are setting the "beginning of screen" address so the ball appears at the desired height?

Yes, that's it! Sounds pretty simple, eh?
Until you realize that the Electron has an always-on interlaced PAL frame with two differently timed fields.
And you have to find a way to determine which field is active.
And you need 100% cycle counting in your timing critical code.
And you realize that MODE 1 stalls the CPU for the active (visible) part of every scanline.
And you realize that you can only change the screen start address in steps of 64 bytes (i.e. 4 characters left/right, 1 char row up/down).
And you need to switch screen modes at least 3 times every PAL field.
And so on....

[VectorEyes]

Until you realize that the Electron has an always-on interlaced PAL frame with two differently timed fields.
And you have to find a way to determine which field is active.
And you need 100% cycle counting in your timing critical code.

... sounds horrible but not *that* bad so far...

And you realize that MODE 1 stalls the CPU for the active (visible) part of every scanline.

... OH DEAR GOD!

[BigEd]

... try it on your own Acorn Electron (will NOT work on any emulator) ...

That sounds like a challenge - what are the rough edges in emulators that stop this working? One or two things, or many things?

[0xC0DE]

... OH DEAR GOD!

[0xC0DE]

... try it on your own Acorn Electron (will NOT work on any emulator) ...

That sounds like a challenge - what are the rough edges in emulators that stop this working? One or two things, or many things?

From my experience it boils down to timing issues. None of the emulators have 100% accurate timing. My own emulator is the worst to be honest. You won't notice these tiny differences when playing the average game. But when every CPU cycle matters (like in some of my demos) then it quickly falls apart.

On the bright side: you could use some of my demos as a benchmark for how close your particular emulator comes to a real Electron

[BigEd]

On the bright side: you could use some of my demos as a benchmark for how close your particular emulator comes to a real Electron :mrgreen:

A fine idea!

[julie_m]

It's only like playing an instrument -- you just have to sound the right notes, in the right order, in time with the rhythm of the song ..... Please don't think I'm trying to belittle any of your achievements, just explain them in terms I can understand myself. Chasing the electron beam is something I haven't dared attempt yet (though "build a circuit on breadboard, from scratch, to draw a picture on a TV screen" is definitely on the bucket list; and I figure as long as I've got said list, I'm unlikely to kick said bucket ..... there must be another reel left, the audience are still seated .....) and I genuinely admire anyone who can do it.

I haven't got a real Electron to try it on but in the video, I cannot see any of the tell-tale artefacts of timing errors anywhere -- which surely would be aggravated by the MPEG compression in the video -- so I reckon you have your timing absolutely bang on.

I guess the Electron ULA (which itself is emulating some of the functionality of a device that was originally intended to create a monochrome display from a character-mapped memory representation and font memory, being slightly misused to create a colour display directly from a bit-mapped memory representation) must be a real headache to emulate in a time-critically perfect way. Steve Furber must have been breathing solder flux fumes or something -- the Electron's memory model using four 64K * 1 bit DRAM chips and time-sliced accesses to emulate a 32K * 8 bits organisation can most politely be described as bonkers! With a processor such as the Z-80, you would need to run the memory at double speed in order to be able to work two 4-bit accesses into the time for a single 8-bit access; but the 6502 does things on both the rising and falling edges of the clock, so you effectively have to run the memory at four times speed. And the memory speed already has to be double the processor clock speed, so the ULA can create the display in between ticks of the 6502 clock ..... so that chip is running blisteringly fast. (This must ultimately have had some influence on the ARM design, even if it was just showing it was possible at all for silicon to run that fast.)

Anyway,

[0xC0DE]

Please don't think I'm trying to belittle any of your achievements, just explain them in terms I can understand myself.

I wasn't thinking that but I thought you (and anybody else) might appreciate the challenges of getting from idea to execution.

Anyway,

Thanks again!

[jms2]

I have just tried this on my Electron - although I didn't seriously believe you were making this up, I decided I had to prove to myself that it was really possible...

It's really incredible! It doesn't look like something that an Electron can produce at all.

Is the basic technique similar to the method used to scroll the screen 1 pixel in Electron Firetrack? Presumably it isn't, because Firetrack flickers?

[0xC0DE]

I have just tried this on my Electron - although I didn't seriously believe you were making this up, I decided I had to prove to myself that it was really possible...

It's really incredible! It doesn't look like something that an Electron can produce at all.

That's the biggest compliment I could possibly hope for so thank you very much!

Is the basic technique similar to the method used to scroll the screen 1 pixel in Electron Firetrack? Presumably it isn't, because Firetrack flickers?

Firetrack on the Electron actually moves 2 scanlines at a time which proved to me that smooth hardware scrolling was actually possible on the Electron. I am using the same technique as far as I can tell (from what I read on Wikipedia about it of all places; I haven't inspected the actual code).

To be fair, Firetrack is an actual playable game and mine is just a tech demo where timing can be precisely controlled.

So far I haven't been able to coax 1 scanline super smooth vertical hardware scrolling out of the ULA in the Electron...

[gidandridge]

Just grabbed the SSD file and run it on my own Electron.

Little bit stuck for words, except perhaps, stunned.

Amazing piece of work.

[jms2]

Aside from the programming, there are some very clever design choices in your demo. Obviously creating horizontal rainbows gets all the colours on the screen at the same time, with minimal processor overhead. But also using a basketball, which is basically all one colour, allows red/yellow dithering to give a surprisingly accurate rendition of the real thing.

It looks like an Archimedes demo as a result.

[0xC0DE]

Wow! And here I am just grateful that a handful of people in the world actually enjoy what I am making for the Electron

[hoglet]

try it on your own Acorn Electron (will NOT work on any emulator) with this ssd:

I've just had a play with this on Electron FPGA, and it's now working very well:

It's a fantasic bit of code Kelvin!

I've got the ICE-6502 integrated into Electron FPGA, which has let me explore how the code is working.

The initial synchronization code is really nifty

Code: Select all

0F08 : 8C 05 FE : STY $FE05     ; 4
0F0B : 86 0C    : STX $0C       ; 3
0F0D : A2 DB    : LDX #$DB      ; 2
0F0F : 20 9B 18 : JSR $189B     ; 6 + 100 * 219 + 86 = 21992 (343.625 lines)
0F12 : A6 0C    : LDX $0C       ; 3
0F14 : 8C 05 FE : STY $FE05     ; 4
0F17 : 4C 00 10 : JMP $1000     ; 3
1000 : 86 0C    : STX $0C       ; 3
1002 : A2 B2    : LDX #$B2      ; 2
1004 : 20 9B 18 : JSR $189B     ; 6 + 100 * 178 + 86 = 17892 (279.5625 lines)
1007 : A6 0C    : LDX $0C       ; 3
1009 : 20 96 18 : JSR $1896     ; 20
100C : 20 96 18 : JSR $1896     ; 20
100F : 20 96 18 : JSR $1896     ; 20
1012 : 20 93 18 : JSR $1893     ; 19
1015 : 2C 00 FE : BIT $FE00     ; 4
1018 : F0 03    : BEQ $101D     ; 2
101A : 4C 08 0F : JMP $0F08     ; 3
                                ; = 39999 = 1 frame - 1 cycle
101D : 8C 05 FE : STY $FE05
1020 : 20 96 18 : JSR $1896
1023 : EA       : NOP
1024 : EA       : NOP
1025 : 4C 00 11 : JMP $1100

And here's it's actually working in real time with a couple of watch points set:

Code: Select all

ICE-6502 In-Circuit Emulator version 0.981
Compiled at 16:19:10 on Dec 15 2019
8 watches/breakpoints implemented
Tracing every 1 instructions while single stepping
CPU free running...
Interrupted
03.182630 : E33C : D0 27    : BNE $E365
>> watch f08
Ex Watch set at 0F08
>> watch 1100
Ex Watch set at 1100
>> c
CPU free running...
13.328780 : Ex Watch hit at 0F08       // 39999 cycles
13.368779 : Ex Watch hit at 0F08       // 39999 cycles
13.408778 : Ex Watch hit at 0F08       // 39999 cycles
13.448777 : Ex Watch hit at 0F08       // 39999 cycles
13.488776 : Ex Watch hit at 0F08       // 39999 cycles
13.528775 : Ex Watch hit at 0F08       // 39999 cycles
13.568774 : Ex Watch hit at 0F08       // 39999 cycles
13.608802 : Ex Watch hit at 1100       // 40028 cycles
13.648738 : Ex Watch hit at 1100       // 39936 cycles
13.688738 : Ex Watch hit at 1100       // 40000 cycles
13.728738 : Ex Watch hit at 1100       // 40000 cycles
13.768738 : Ex Watch hit at 1100       // 40000 cycles
13.808738 : Ex Watch hit at 1100
13.848738 : Ex Watch hit at 1100
13.888738 : Ex Watch hit at 1100
13.928738 : Ex Watch hit at 1100
13.968738 : Ex Watch hit at 1100
14.008738 : Ex Watch hit at 1100

You can see each iteration of the F08 loop is indeed taking 39999 cycles, as it hunts for the edge of the display interrupt.

Then, once it gets into the 1100 loop, it's taking 40000 cycles (including stalls).

Given the complexity of what you are doing, this is amazing!

What's interesting is the main code seems to be self-synchronizing, inspite of it never actually reading FE00. You can see that if you use the ICE to pause and then resume the 6502:

Code: Select all

Interrupted
02.653205 : 1897 : EA       : NOP 
>> c
CPU free running...
06.136818 : Ex Watch hit at 1100
06.172274 : Ex Watch hit at 1100
06.211626 : Ex Watch hit at 1100
06.250858 : Ex Watch hit at 1100
06.289650 : Ex Watch hit at 1100
06.328554 : Ex Watch hit at 1100
06.358626 : Ex Watch hit at 1100
06.392506 : Ex Watch hit at 1100
06.431642 : Ex Watch hit at 1100
06.471522 : Ex Watch hit at 1100 <<<<<< back in sync
06.511522 : Ex Watch hit at 1100
06.551522 : Ex Watch hit at 1100
06.591522 : Ex Watch hit at 1100
06.631522 : Ex Watch hit at 1100
06.671522 : Ex Watch hit at 1100
06.711522 : Ex Watch hit at 1100
06.751522 : Ex Watch hit at 1100
06.791522 : Ex Watch hit at 1100
06.831522 : Ex Watch hit at 1100
06.871522 : Ex Watch hit at 1100
06.911522 : Ex Watch hit at 1100
06.951522 : Ex Watch hit at 1100
06.991522 : Ex Watch hit at 1100
07.031522 : Ex Watch hit at 1100
07.071522 : Ex Watch hit at 1100

After resuming, the frame times for the first few frames are all over the place (as is the display). But then it settles down and resynchronizes. I guess this is because the code ends up self-synchronizing to the periods of memory contention from the use of Mode 1.

I only hit one issue getting this to work on Electron FPGA. When I first tried, I was getting a stable raster but the ball was all over the place. It looked like when the video address was wrapping around, it was wrapping to the wrong place. The following change to the ULA fixed this:
https://github.com/hoglet67/ElectronFpg ... 46200c?w=1

Just before the first active line, the ULA was sampling the screen start address and mode base values, for use the current field. It turns out it was probably incorrect to sample the mode base. I've looked at the original ULA Schematics and also Hicks' re-implementation, and neither seem to do that.

However, after making this change, I seem to have broken Firetrack, so something is still not 100% correct.

Anyway, this is indeed a great test for both Emulators and FPGA re-implementations!

Dave