Bouncing Basketball tech demo on the Acorn Electron

[0xC0DE]

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

Wow, Dave, this is great! And also a bit strange to see my own code analysed like that

I knew my cycle timings had to be spot on (or else it would all fall apart) but to see it confirmed is really nice!
Your FPGA + ICE-6502 would have been an invaluable tool for me when I first created a stable raster on the Electron.
Big compliment to you that your FPGA can play this demo flawlessly!
I would love to see your FPGA + ICE-6502 in action at ABUG!
(crazy idea: would these tools also help in hunting down the spurious Bad Sum errors I'm getting with my Bad Apple demo on Elk/MMFS?)

As you discovered, after the initial PAL field detection code and syncing to DispEnd interrupt, all interrupts are turned off (and FE00 is not polled again) and 40K cycles are counted for every PAL frame to stay in sync.
MODE 1 (and all other high bandwidth screen modes) are interesting because of the memory contention issue. It allowed me to create a new version of the basketball demo that doesn't require a strict stable raster (like this version). Because of the "self-synchronizing" property (still not exactly sure how this works). I can use a normal DispEnd interrupt (including interrupt jitter) and adjust the timing between fields manually during development. That way 100% cycle counting (which is a slow and painful process) is not necessary during VBLANK (But is still needed during active display if you want some scanline shenanigans).

About (software) emulators.
Electrem chokes on the initial sync phase. After a few seconds it finally exits the sync phase but the timing for the actual demo is all wrong as well.
Elkulator is pretty accurate. I only need to add/subtract 16 cycles here and there to get it to work. Really helps during development and for taking a video of my demo.
MAME: somehow I can't get it to work anymore. It chokes on disk access and I have put it aside for now.
Electroniq (my own): is the worst of all because I didn't have cycle accuracy in mind when I wrote it. I could improve it so much with my current understanding of the Electron

[hoglet]

I would love to see your FPGA + ICE-6502 in action at ABUG!
(crazy idea: would these tools also help in hunting down the spurious Bad Sum errors I'm getting with my Bad Apple demo on Elk/MMFS?)

Yes, I'm sure they would.

I'll definitely be bringing them along.

Dave

[Pernod]

MAME: somehow I can't get it to work anymore. It chokes on disk access and I have put it aside for now.

Which disk interface did you try to use? For ssd I always use the Pegasus, I think AP4 may have issues. The demo runs but doesn't look great, and will serve as an excellent test case when I get back to improving the video emulation.

[0xC0DE]

Which disk interface did you try to use? For ssd I always use the Pegasus, I think AP4 may have issues.

I use Plus3 + ACP DFS 2.10.
Will try some different combinations because I want to be able to test in MAME as well.

The demo runs but doesn't look great, and will serve as an excellent test case when I get back to improving the video emulation.

I hope it will be useful to improve MAME

[Pernod]

I use Plus3 + ACP DFS 2.10.
Will try some different combinations because I want to be able to test in MAME as well.

That's basically an AP4, try mame64 electron -exp romboxp -cart1 peg400.

[0xC0DE]

I use Plus3 + ACP DFS 2.10.
Will try some different combinations because I want to be able to test in MAME as well.

That's basically an AP4, try mame64 electron -exp romboxp -cart1 peg400.

First I updated MAME. I have a lot of ROMs (don't remember where I downloaded them from, probably a zip file provided by you) but I don't have peg400. I feel like I should be able to find it myself but I can't! On that note, where can I find other new ROMs. I would really like to keep my MAME updated with all expansions for the Electron.

[Arcadian]

I dumped a couple of Peg roms years back, both here: http://www.stairwaytohell.com/roms

[0xC0DE]

I dumped a couple of Peg roms years back, both here: http://www.stairwaytohell.com/roms

Thank you!

[Lardo Boffin]

How on earth do you go about writing something like this?

[0xC0DE]

How on earth do you go about writing something like this?

Excellent question!

It starts with a desire to create something new. Mistakes will be made, disappointment is around the corner, so perseverance is key.
And you need an idea. Usually inspired by other demos or games. And a sense of "how could I make something like this on the Electron?".
And intimate knowledge of the system (Acorn Electron in my case) you are coding for.
Then it's all one step at a time. Trying, failing, improving. Building upon stuff that I made before and learning from others.

To be more specific about the basketball demo:
1. I had created a stable raster with cycle perfect timing before so it's like having 100% control of the Electron and the screen
2. I had created a demo framework before that sets up the basic stuff, claims all memory and all CPU by shutting out MOS completely
3. I knew from Firetrack (on the Electron) that smooth vertical hardware scrolling in increments of 2 scanlines was somehow possible. And I read a vague description on Wikipedia on how to possibly go about achieving that by switching screen modes at the right time
4. Using the stable raster it has become surprisingly easy to create colour cycling horizontal bars in any number, size or colour. And to experiment with screen mode switches at any desired location until it was just right
5. The basketball image was converted with the excellent BBC Micro Image Converter
6. Using a perfected toolchain (VSCode, BeebAsm, emulators like Elkulator, MMFS and a real Electron) it has become faster and easier to develop and test my code
7. Then, if you're lucky, you bask in the glory of the handful of people enjoying your creation And you move on to the next project...

One thing that is very important for demo coding (in general I guess) but especially on a humble machine like the Electron: moving bytes is EXPENSIVE. See if you can get a similar effect in a CHEAP way by either changing the screen start address, or by rapidly switching the colour palette, or by changing screen modes, or a combination of all.
Similarly, doing runtime calculations is EXPENSIVE. See if you can get a similar effect in a CHEAP way by doing the calculations beforehand and storing them in a table to be used at runtime.

Something like this?

[Lardo Boffin]

That makes it sound easy!