New hardware trick: "vertical rupture" on the Acorn Electron

[0xC0DE]

I discovered this yesterday by tinkering with stable raster code on my Acorn Electron: some sort of "vertical rupture" effect on the Acorn Electron.
As you know there is no CRTC to abuse, only the (limited) ULA. And as far as I know this has never been done on the Elk before. I didn't even know or expect it to be possible to be honest.

@DaveB, @ThomasH: I would be very curious to see if this works on the Elk FPGA or if you could make it work in CLK (it doesn't at the moment).

Very first demonstration (video on Twitter):

https://twitter.com/0xC0DE6502/status/1 ... 55778?s=20

What happens in this first proof of concept is that the first character row (MODE 4) is duplicated down the screen. This is done by briefly switching to MODE 3 at the end of every scanline. I was looking for another effect but stumbled upon this instead!
So far this only works on a real Electron.

Edit: the video accidentally shows a 25fps effect but it also works at 50fps

[hoglet]

@DaveB, @ThomasH: I would be very curious to see if this works on the Elk FPGA or if you could make it work in CLK (it doesn't at the moment).

If you post an SSD file I'll give it a try.

Dave

[0xC0DE]

@DaveB, @ThomasH: I would be very curious to see if this works on the Elk FPGA or if you could make it work in CLK (it doesn't at the moment).

If you post an SSD file I'll give it a try.

Dave

Here you go!

stable-raster-experiments.ssd

(7 KiB) Downloaded 90 times

[SarahWalker]

Interesting. Guessing this is interrupting the "is this the end of the character row?" check at character line 7/9, meaning the character line counter wraps back round without advancing the address counter.

I wouldn't say this is actually rupture though, unless you can find a way to reload the address counter mid-screen.

[0xC0DE]

Yes, I'm experimenting with that now. I also want to know if it works in MODE 5.

[tricky]

Encouraging for what else might be possible, even if it eats nearly all of your CPU cycles.

[0xC0DE]

Encouraging for what else might be possible, even if it eats nearly all of your CPU cycles.

Update:
It works in MODE 5 as well.
I can start and stop the 'rupture' anywhere on the screen. Every char row as far as I can tell, not every scanline though.
I can also manipulate both PAL fields in a completely separate way. Leads to some interesting effects (multi layer, mixing colours) but with a horrible 25fps flicker that I can't stand on my monitor (maybe on a proper CRT it wouldn't be so bad?).

@tricky: the effect you saw in my video on Twitter barely eats any cycles at all. I have so much cycles to spare! (but burning them away at the moment to stay in sync with the stable raster)

Edit: there doesn't seem to be a way to reload FE02/03 (screen start address) or the internal address counter once the display is active. The screen start address only gets picked up once at the start of the display.

[tricky]

I meant that everything has to be cycle counted exactly, so its more work to fill the gaps.

It has probably already been done, but can you use 1 pixel high char rows to get two frames in 1/50 second?
Just thinking status area + scrolling region, but I'm not sure what scrolling you can do!

In my experience, flicker will be bad on any CRT, only some dodgy smoothing or slow LCD response (or dodgy emulator ) will not flicker

PS, just realised, that doesn't use your new technique at all!

[0xC0DE]

It has probably already been done, but can you use 1 pixel high char rows to get two frames in 1/50 second?

I don't think this has ever been done on an Electron (1 pixel high char rows). You may be slightly overestimating the capabilities and user configurability of the ULA
But keep the ideas coming. Who knows what else we will discover in ancient hardware!

[oss003]

Isn't this method like yours ........ a bit of ....
It is based upon a 6845.

https://int10h.org/blog/2015/04/cga-in- ... lustrated/

Greetings
Kees

[hoglet]

Here you go!
stable-raster-experiments.ssd

I've just tried that, and (not surprisingly) it didn't work.

It seems the trick to to prevent the address counter from incrementing to the next row isn't currently working with Electron FPGA.

Looking at the VHDL, it looks like it might work, so this could just be a minor timing difference. The "last line" test is done on the falling edge of hsync.

Is there a version that uses MODE4/MODE6 rather than MODE4/MODE3?

This would be simpler to debug, because there would be no memory contention. Or do you rely on the memory contention to maintain a stable raster?

Do you do the mode change at the end of every scanline (i.e. every 64us)?

Dave

[0xC0DE]

Isn't this method like yours ........ a bit of ....
It is based upon a 6845.

https://int10h.org/blog/2015/04/cga-in- ... lustrated/

Greetings
Kees

Yeah, that is almost completely not the same at all

[0xC0DE]

Looking at the VHDL, it looks like it might work, so this could just be a minor timing difference. The "last line" test is done on the falling edge of hsync.

Is there a version that uses MODE4/MODE6 rather than MODE4/MODE3?

This would be simpler to debug, because there would be no memory contention. Or do you rely on the memory contention to maintain a stable raster?

Do you do the mode change at the end of every scanline (i.e. every 64us)?

I simplified my previous code and it indeed also works with MODE 6 instead of MODE 3 (it is now also the advertised 50fps instead of 25fps):

mode6.ssd

(8.75 KiB) Downloaded 81 times

I use the following timing (for each PAL field):
1. each scanline starts in MODE 4 or 5
2. exactly at the boundary of the active part of a scanline (40us) and the HSYNC period (24us) the switch to MODE 6 is made; that is done with an lda/sta pair that takes 6 cycles so this sequence is executed at exactly 34 cycles into the active part of the scanline. This is done only on every 8th scanline (last one of each char row)
3. if you switch right back to MODE 4/5, it won't work properly. At the moment I switch back to MODE 4/5 right after the 14th cycle in the HYSNC period. That is, the lda/sta pair is executed after 48us of the current scanline.
So it looks like the "last line" test is done somewhere in that period. I haven't tried to pinpoint it to the exact cycle.

If you look at the VHDL, do you think there are other exploitable hardware quirks/glitches in the ULA? Any way to reload the internal screen address counter for instance? I'm very interested in any information you may glean from this.

[hoglet]

(Crossed posts....)

I've done a bit more debugging of this now, and have it working.

The effect is possible because the "last line" signal inside the ULA is used at two different points in time.
- At the start of HSYNC: if last line is true the row address is advanced to the next character row
- At the end of HSYNC: if last line is true the row counter (counting lines withing a character) is reset back to zero, otherwise it is incremented

The sequence of events to generate this effect is:
- the active part of the line is output in mode 4
- mode change: 4->3
- at the start of HSYNC, "last line" will be true if the row counter has reached 9 (which it never does, so the row address is never advanced)
- mode change: 3->4
- at the end of HSYNC, "last line" will be true if the row counter has reached 7, so the row counter never gets beyond 7

To get this working on Electron FPGA, I had to make two changes:
1. Update the row counter at the end of HSYNC (due to a bug it was being updated at the start of HSYNC)
2. Delay HSYNC by 2us

The second of these changes should not have been necessary, and needs further investigation. I could see on a scope the timing of the mode change was out by 2us, so the 3->4 transition was happening just after HSYNC, rather than during HSYNC.

Here's a sample of the code that does the mode change:

Code: Select all

03.407546 : 1146 : A9 A0    : LDA #$A0      ; (2)
03.407548 : 1148 : 8D 07 FE : STA $FE07     ; (4)      change to mode 4 (should be in the middle of hsync)
03.407552 : 114B : C6 0C    : DEC $0C       ; (5)
03.407557 : 114D : 30 02    : BMI $1151     ; (2)
03.407559 : 114F : 10 DB    : BPL $112C     ; (3)
03.407562 : 112C : 6E 65 13 : ROR $1365     ; (6)
03.407568 : 112F : 6E 65 13 : ROR $1365     ; (6)
03.407574 : 1132 : 6E 65 13 : ROR $1365     ; (6)
03.407580 : 1135 : EA       : NOP           ; (2)
03.407582 : 1136 : 6E 65 13 : ROR $1365     ; (6)
03.407588 : 1139 : EA       : NOP           ; (2)
03.407590 : 113A : 24 00    : BIT $00       ; (3)
03.407593 : 113C : EA       : NOP           ; (2)
03.407595 : 113D : A9 98    : LDA #$98      ; (2)
03.407597 : 113F : 8D 07 FE : STA $FE07     ; (4)      change to mode 3 (should be in the middle of hsync)
03.407601 : 1142 : 6E 65 13 : ROR $1365     ; (6 + N)  the +N is due to memory contention with the active line
03.407607 : 1145 : EA       : NOP           ; (2)

                                              (63 + N)

03.407609 : 1146 : A9 A0    : LDA #$A0

It's very clever how this code works. It's nominally 63 cycles, but the part in that runs in Mode 3 is subject to memory contention if it collides with the active line. What seems to happen is that it self-synchronizes to the scan line, and you end up with a stable raster and exactly N=1 cycle of contention.

The fact that I had to adjust the position of hsync slightly suggests that my period of simulated memory contention is out by the same amount. What I really should do is to use the scope a real electron and look at the exact timing of the mode change wrt HSYNC.

Dave

[0xC0DE]

It's very clever how this code works. It's nominally 63 cycles, but the part in that runs in Mode 3 is subject to memory contention if it collides with the active line. What seems to happen is that it self-synchronizes to the scan line, and you end up with a stable raster and exactly N=1 cycle of contention.

Thanks for the detailed investigation, Dave! I love reading about this from a hardware perspective.
The 63 cycles is correct because I left 1 cycle for MODE 3 in the active part of the scanline. I was assuming the MODE change had to be done in the active part. Which turns out not to be true. See my MODE 6 version. That should be exactly 64 cycles. This stable raster is not dependent on memory contention but on cycle counting. I may try to create a version that does rely on memory contention to make my life easier and stop cycle counting.

[hoglet]

I've taken a measurement from a Elk with a real ULA, and it's is not quite what I was expecting:

This is running the original Mode 3/4 version. The top trace is HSYNC (plus some crosstalk from the active part of the line). The bottom trace is showing the data written to bit 4 of &FE07: low indicates mode 4, high indicates mode 3.

It seems mode 3->4 transition happens just after the end of HSYNC, not during HSYNC as I was expecting was needed.

So back to the drawing board....

If you look at the VHDL, do you think there are other exploitable hardware quirks/glitches in the ULA? Any way to reload the internal screen address counter for instance? I'm very interested in any information you may glean from this.

There are actually two VHDL models of the Electron ULA:
- my one, created mostly in 2016, based on our collective understanding of the ULA at that point in time
- Hicks' one, created in 2019, based partly on some difficult to read but original schematics of the Ferranti ULA (that I got via Harry Barman)

Hicks' implementation is likely to be more faithful, but there still questions about how accurate the schematic are. He found some bugs in the schematic that are not present in the real ULA.

In both cases, I think the sceen address registers at FE02/3 are consulted just once a field.

Dave

[tricky]

Didnt Orlando change tbe number of lines per char to scroll firetrack on the elk?

[0xC0DE]

Didnt Orlando change tbe number of lines per char to scroll firetrack on the elk?

No, that's a different trick, also exploited in my Bouncing Basketball demo. This exploits the 2 scanline gap of MODE 6 to push the screen down in increments of 2 scanlines.
For the longest time I also thought Nick Pelling (Orlando) wrote the Elk version of Firetrack but he corrected me on Twitter: it was Chris Terran who wrote the Elk version.

[0xC0DE]

Exploiting the effect some more: https://www.youtube.com/watch?v=MePpfsDMuiM

Tech info: split MODE, split colour palette, split rupture effect.

[hoglet]

Just to close the loop on how/why this "vertical rupture" effect works....

I've gone back to the original Ferranti ULA Schematics posted in this thread and now really do understand how this effect is working. There is some commentary from Hicks in that thread which is very useful indeed (thanks Gary).

There's two parts to it:

1. Preventing row address from advancing to the next row.

This is on sheet 2 of the schematics. The start address of the current row is stored in QSTART[14:6]. This is made up of transparent D-type latches, and the clock input includes the term (LS and BLINEB). LS is an active high version of HSync. BLINEB is an active low version of "last line" condition.

To prevent the row address from advancing, it's necessary to switch to text mode before HSync starts and only switch back to a graphics mode after HSync ends. This effectively supressed the clock pulse. If you refer back to the scope plot here that's exactly what Kelvin's demo is doing.

2. Preventing the character row line from ever reaching 9.

This is on sheet 7 of the schematics. The line within the current row is stored in VAX3 and VA[2:0] (i.e. it's a 4-bit counter) made up of T-type flip-flops. The clock input is LS (line sync), so the counter increments once per line. The implementation of this counter is a little unusual, in that there are two reset signals:
- the first reset affects bits 3..0, and is asserted if the count ever reaches line 10 (1x1x) in text mode (and also at the start of the field)
- the second reset affects only bit 3, and is asserted in graphics mode

These resets work together as follows:
- in text mode the counter counts from 0...9, briefly hits 10 (for a few ns) and is immediately reset to 0 (by reset 1).
- in graphics mode, bit 3 of the counter is held in reset (by reset 2), and bits 0..2 are left to free-run (0..7)

The effect of the second reset is important for this effect to work. Any time a graphics mode is entered (regardless of the timing wrt HSync), the top bit of the counter is immediately cleared.

It was this second reset signal that was missing from Electron FPGA, and here's the fix:
https://github.com/hoglet67/ElectronFpg ... 71ff11480d

With this in place, both versions of the Vertical Rupture demo work correctly.

The other thing I looked for on sheet 2 of the schematics is a way to force the screen start address to be reloaded into QSTART. As far as I can tell there isn't one. This is loaded once at the start of each field (under the control of the ADDINT signal, which is generated during the last line field). This seems pretty definitive.

Dave

[0xC0DE]

This is some exceptional sleuthing on your part!
I really enjoy reading this and I will also be reading that thread you linked to.
I hope software emulator authors (including myself) will implement this as well.

Edit: I may have another question for you Dave about another anomaly...

[0xC0DE]

@DaveB (or somebody else): maybe you could help me figure this out.

I have an image in MODE 4 (or 5) and want to try to displace it horizontally by less than 64 bytes (the usual granularity of hardware scrolling via FE02/03).
The idea is: display the last few bytes of the MODE 4/5 scanline in MODE 0 such that the next scanline (or at least, char row) is hopefully displaced because MODE 0 'eats' bytes twice as fast as MODE 4/5.
I now have the following result. It looks like 1 in every 8 scanlines is displaced by approx. 16 pixels (2 chars). So something is happening but of course I would like to see all scanlines displaced like this. Maybe you have a fresh idea about this? Or why/how does it even work?

displacement.ssd

(8.75 KiB) Downloaded 70 times

I don't know the magic formula but the image above (only on a real Electron) is the result of:
Every 1st (out of 8 ) scanline: last 7 cycles of the active part of the scanline is in MODE 0
2nd: last 6 cycles....
...
7th: last 1 cycle
8th: no cycles in MODE 0

You can see the garbage in the bottom right corner. This is pulled onto the screen from &3000 because of the screen wrap around (I think).

[hoglet]

@DaveB (or somebody else): maybe you could help me figure this out.

I can have a try....

When the ends of lines 0..6 are reached, the video address counter is re-loaded from the internal "start of row" register (QSTART on the Schematics). So any extra bytes "eaten" by switching to mode 0 at the end of the previous line have no effect. The start of row register only implements bits 14..6, so bits 3..5 of the video address are re-initialzed with zero (and bits 2..0 come from the line counter within the row). What this effectively means is that lines 1..7 will always start at a multiple of 64 bytes.

When the end of line 7 is reached, the video address counter would normally point to the start of the next row. So it's value is retained as the video address for line 8, and it is also writen back to the "start of row" register as the start of the next row. But again, only bits 14..6 are used.

So only line 8 is affected in any way by eating extra bytes, and the effect only lasts for that one line.

Looking at the timings of the mode changes on a scope, I think you might be out by 1us:
- line 0 has 8us of Mode 0 before the end of the active line (not 7us)
...
- line 7 has 1us of Mode 0 before the end of the active line (not 0us)

By switching to Mode 0 for 1us, you are eating one extra byte, and every 8th line is offset by one character. But this only affects that one line, because of the lack of bits 3..5 in the internal "start of row" register.

The only way I can see this effect working is if the mode change overlaps with the start of the active line, rather than the end. It would would need to be done on every line, and it would just affect the remainder of that line. Is this something you have tried?

Dave

[0xC0DE]

The only way I can see this effect working is if the mode change overlaps with the start of the active line, rather than the end. It would would need to be done on every line, and it would just affect the remainder of that line. Is this something you have tried?

Thanks for your detailed response, Dave, I think I understand what is happening now. And it also confirms I should abandon this idea.

I think a mode change (MODE 0-3) that overlaps the start of each scanline is impossible because the CPU is then stalled until HSYNC, effectively leavning no room to switch back to MODE 4-6 during the remainder of that scanline.

[hoglet]

I think a mode change (MODE 0-3) that overlaps the start of each scanline is impossible because the CPU is then stalled until HSYNC, effectively leavning no room to switch back to MODE 4-6 during the remainder of that scanline.

Yes, you are right, that would only work if the code was in sideways ROM or RAM.

Dave

[0xC0DE]

I think a mode change (MODE 0-3) that overlaps the start of each scanline is impossible because the CPU is then stalled until HSYNC, effectively leavning no room to switch back to MODE 4-6 during the remainder of that scanline.

Yes, you are right, that would only work if the code was in sideways ROM or RAM.

Dave

That's an interesting thought. I did make some demo effects before in ROM for extra speed (in SWRAM actually). In my stable raster code all interrupts are off anyway and I don't use the stack. I should then only avoid using zeropage and then everything will execute at 2MHz with no memory contention, right? Hmm, that opens up a new world of effects!

[hoglet]

That's an interesting thought. I did make some demo effects before in ROM for extra speed (in SWRAM actually). In my stable raster code all interrupts are off anyway and I don't use the stack. I should then only avoid using zeropage and then everything will execute at 2MHz with no memory contention, right?

There are a couple of things I think still slow down to 1MHz:
- IO accesses (FCxx, FDxx, FExx)
- keyboard accesses (i.e. ROM slots 8/9)

So timing gets a bit more complicated.

You might also need to make use of self-modifying code in places (e.g. to avoid indirect (ZP),Y address).

Dave

[0xC0DE]

That's an interesting thought. I did make some demo effects before in ROM for extra speed (in SWRAM actually). In my stable raster code all interrupts are off anyway and I don't use the stack. I should then only avoid using zeropage and then everything will execute at 2MHz with no memory contention, right?

There are a couple of things I think still slow down to 1MHz:
- IO accesses (FCxx, FDxx, FExx)
- keyboard accesses (i.e. ROM slots 8/9)

So timing gets a bit more complicated.

You might also need to make use of self-modifying code in places (e.g. to avoid indirect (ZP),Y address).

Dave

I'm up for a challenge if a cool new effect is just around the corner!

[!FOZ!]

Didnt Orlando change tbe number of lines per char to scroll firetrack on the elk?

No, that's a different trick, also exploited in my Bouncing Basketball demo. This exploits the 2 scanline gap of MODE 6 to push the screen down in increments of 2 scanlines.
For the longest time I also thought Nick Pelling (Orlando) wrote the Elk version of Firetrack but he corrected me on Twitter: it was Chris Terran who wrote the Elk version.

I have just been playing Firetrack on the Elk and I continue to be blown away with what was achieved here. I am also pondering if it actually is using some sideways ram like the BBC version (my Elk has some). The reason I think this is that the question mark pattern in the first level on the BBC version is the clue early in the game that sideways ram is being used. Or maybe it’s due to it using a different mode and the screen being slightly smaller opening up more memory for level data? Secondly I’ve played three levels in an each is different, not just color changed but diffent layouts. Frankly I also find the collision detection and overall feel of the game more solid than the BBC version - which I know is possibly crazy talk!

[0xC0DE]

Frankly I also find the collision detection and overall feel of the game more solid than the BBC version - which I know is possibly crazy talk!

No, you are definitely on the right track here!

The Electron version doesn't use SWRAM and it uses exactly 10K of screen RAM.
It is a technical marvel and a great game for sure!