MODE 7 Vertical Rupture

Got a programming project in mind? Tell everyone about it!
User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

MODE 7 Vertical Rupture

Postby kieranhj » Tue Mar 07, 2017 10:13 pm

Hey everyone,

I thought I would start sharing some of my prototypes more regularly with you all, rather than sit on stuff for months and then surprise you with a whole Bad Apple. (Although that was fun to see the reactions.)

Continuing the MODE 7 / Teletext theme, I thought I would see if I could get vertical rupture working to do a per scanline scroll for the credits in our next demo. After spending a bit of time getting my head around RTW's explanation and sample code from RS I figured out the construction of a MODE 7 screen and the necessary timings etc. Attached is a small demo - some of the little glitches need ironing out to make it perfect but you should get the idea.

Note I've only tested this on b-em and jsbeeb - I will get chance to try real hardware tomorrow - but let me know what you think. I've not seen this anywhere before, is it a first?!
Attachments
mode7-smooth.zip
Smooth (scanline) scrolling in MODE 7
(2.52 KiB) Downloaded 31 times
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MODE 7 Vertical Rupture

Postby tricky » Tue Mar 07, 2017 10:35 pm

Nice, I think you should be able to turn the display off at the top to hide the top line and broken double height.

tom_seddon
Posts: 84
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby tom_seddon » Wed Mar 08, 2017 2:45 am

You can probably make something of this, but do try it on real hardware :-|

I suspect the problem is that jsbeeb isn't emulating the teletext display quite right. The SAA5050 ignores the CRTC's character row counter, and maintains its own, based on counting hblanks. (see, e.g., viewtopic.php?f=53&t=12436&p=158808#p158808) So you always get character row 0 on scanline 0, and so on...

--Tom

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Wed Mar 08, 2017 8:39 am

tom_seddon wrote:You can probably make something of this, but do try it on real hardware :-|

I suspect the problem is that jsbeeb isn't emulating the teletext display quite right. The SAA5050 ignores the CRTC's character row counter, and maintains its own, based on counting hblanks. (see, e.g., viewtopic.php?f=53&t=12436&p=158808#p158808) So you always get character row 0 on scanline 0, and so on...

--Tom

Doh! That's my own thread, so I should know that already. :)

It doesn't work on real hardware alas, but is still an "interesting" effect. As you say, the SAA "knows" which scanline is being displayed so chooses the appropriate scanline of its internal character set according to the memory it is being fed. This means that the screen contents is fixed in place but we still have the CRTC overlaid on top of this so you end up with a "vertical blind" effect in which rows can have bottom half of characters at the top and vice versa.

I know the SAA ignores scanlines by counting hblanks but what about character row counter? You can set the memory address used (albeit with the 10-bit address limitation) but is this cached for the whole frame or does this get reset each CRTC cycle?

Hmmm, you can still move the MODE 7 screen up & down using R5 Vertical Total Adjust, so maybe the answer is to do something simpler and just increment that register and use a timer to turn the screen off at top & bottom so you can't see this, rather than use vertical rupture cleverness.
Attachments
WP_20170308_08_33_39_Pro.jpg
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Wed Mar 08, 2017 9:35 am

OK, so this version does work on real hardware but doesn't have nice borders at the top & bottom so you can see the old character row disappear and the new one appear (and is a bit jerky but I'm sure that could be sorted.)

Experiments show it's fine adding additional scanlines to the screen using CRTC R5 Vertical Total Adjust to move the whole image up & down but if you use R8 to turn the screen display off & on (via a timer) then the SAA and CRTC then start to differ on what is being displayed and I get the split lines. Still don't fully understand why that is!

I would have to decide whether this effect is acceptable for a future demo; showing the workings kind of ruins things. :-k
Attachments
mode7-smooth.zip
One scanline scrolling but no nice borders
(2.48 KiB) Downloaded 23 times
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MODE 7 Vertical Rupture

Postby tricky » Wed Mar 08, 2017 12:59 pm

You may still need vertical rupture to get the vsync consistent, otherwise you will get the screen bouncing on some CRTs (like Gil and I did bitd).

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: MODE 7 Vertical Rupture

Postby Rich Talbot-Watkins » Wed Mar 08, 2017 3:13 pm

Experimenting with stuff like this will be a really great way to stretch the teletext hardware to its limits, and ensure that emulation is corrected accordingly!

I'm still not 100% clear how the SAA chip manages its internal scanline counter, but here's my guess. As well as being reset to 0 on VSync, it also seems as if it only gets incremented when display is enabled. We can determine that from the fact that, no matter what R5 is set to, it always starts the first character row at the topmost scanline. (Otherwise we might expect changing R5 to change the top displayed scanline of the character row.)

So that could be why your original code might be failing - the changes to CRTC R8 to turn off the display are pausing the SAA internal scanline counter increment. Possible solution - instead of turning off the display like that, just substitute the top left and bottom left characters with control code 24 (conceal row) when you want the display to be hidden. Same timing as before, and actually a tiny bit faster than using the CRTC! :lol: Then you should be able to continue to use the rupture technique to split the frame in two, in order to maintain the necessary 312 (and a half) lines.

Actually, that's another question - how does interlaced sync and video work in this case? By ramming two CRTC frames into a single PAL refresh, are you getting odd and even fields in the same refresh, or does the SAA chip also determine odd/even by some other means (e.g. counting VSyncs and alternating)?

Also, does this screen splitting technique even work with interlace? You might need to split three times in order to preserve the additional half scanline which comes from the differing sync pulse configurations between odd and even fields (see here). That might lead to slightly more complex timing, given that odd fields are 64us longer than even fields.

Edit to add: You don't necessarily need to use vertical rupture to achieve this kind of smooth scrolling. But you do need to find some way to ensure that the frame contains exactly 312 (or 312.5) lines. Firetrack does this by defining a single off-screen character row with a different R9 (number of scanlines). This would probably be much easier in this case, although the timing sounds a bit more tricky.

Second edit to add: Something still doesn't quite figure though. I assume the SAA gets display enable low during hsync where I would've expected it increments its scanline counter. So maybe it's not relying on that. Or maybe it increments it on the rising edge, i.e. when the left border ends, just prior to starting a new visible line. Would need to look at the circuit diagram and the datasheet to determine this I guess.

Third edit to add: Conceal text is no good because it gets cancelled by any other colour control codes. Rats!

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MODE 7 Vertical Rupture

Postby tricky » Wed Mar 08, 2017 5:13 pm

It may be possible to enable the display at the point where the scan line is counted and disable it the rest of the time, although this brings even more sensitive timing in to play.
I was also wondering about switching mode for the top (and maybe bottom) to hide the teletext.

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: MODE 7 Vertical Rupture

Postby Rich Talbot-Watkins » Wed Mar 08, 2017 9:40 pm

tricky wrote:You may still need vertical rupture to get the vsync consistent, otherwise you will get the screen bouncing on some CRTs (like Gil and I did bitd).

Yeah, wrapping R5 from 7 back round to 0 always resulted in a big bounce when I used to try this back in the day. It was only many years later that I learnt why...

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 1:22 pm

Rich Talbot-Watkins wrote:
tricky wrote:You may still need vertical rupture to get the vsync consistent, otherwise you will get the screen bouncing on some CRTs (like Gil and I did bitd).

Yeah, wrapping R5 from 7 back round to 0 always resulted in a big bounce when I used to try this back in the day. It was only many years later that I learnt why...

I haven't tried with my CRT yet but will give it a go at the weekend. Works fine on my LCD via SCART but I guess that will be a lot more tolerant to a variety of input signals.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 1:46 pm

Rich Talbot-Watkins wrote:Experimenting with stuff like this will be a really great way to stretch the teletext hardware to its limits, and ensure that emulation is corrected accordingly!

Yes, it certainly seems that the Teletext implementation is one of the weaker aspects of the BBC emulations available. At the Teletext event the other week we also found a bug in the SAA5050 implementation of the Teletext spec regarding Hold Graphics! We suspect this is because the chip was essentially the first produced so was probably designed & implemented around the same time the spec was actually being written & finalised.

Rich Talbot-Watkins wrote:I'm still not 100% clear how the SAA chip manages its internal scanline counter, but here's my guess. As well as being reset to 0 on VSync, it also seems as if it only gets incremented when display is enabled. We can determine that from the fact that, no matter what R5 is set to, it always starts the first character row at the topmost scanline. (Otherwise we might expect changing R5 to change the top displayed scanline of the character row.)

How exactly does R5 work? According to the AUG these extra lines get added to the end of the screen before retrace or do they actually get added to the start of the screen after retrace? I'm guessing either way the net result is adding a delay to the raster so that the next frame is positioned differently.

Rich Talbot-Watkins wrote:Actually, that's another question - how does interlaced sync and video work in this case? By ramming two CRTC frames into a single PAL refresh, are you getting odd and even fields in the same refresh, or does the SAA chip also determine odd/even by some other means (e.g. counting VSyncs and alternating)?

Also, does this screen splitting technique even work with interlace? You might need to split three times in order to preserve the additional half scanline which comes from the differing sync pulse configurations between odd and even fields (see here). That might lead to slightly more complex timing, given that odd fields are 64us longer than even fields.

I'm not sure that the interlace does work in my first example - again this is just beyond my understanding of how the PAL signal is constructed. I did notice that in this instance the Teletext characters look weird & blocky - presumably missing the diagonal interpolation that happens when upscaling the internal 6x10 character set into 12x20 (interlaced) pixels. I need to read that documentation you helpfully linked a few times I think. :)

Rich Talbot-Watkins wrote:Edit to add: You don't necessarily need to use vertical rupture to achieve this kind of smooth scrolling. But you do need to find some way to ensure that the frame contains exactly 312 (or 312.5) lines. Firetrack does this by defining a single off-screen character row with a different R9 (number of scanlines). This would probably be much easier in this case, although the timing sounds a bit more tricky.

Ah OK, so if I understand correctly Firetrack achieves its scrolling by: setting R5 to offset the top of the screen by up to one character row (8 scanlines), using R8 to turn off the screen for the top character row so we get a consistent border, then turning the screen off at the bottom of the desired window and finally rounding off by setting R9 to reduce the last character row to have 8-R5 scanlines so we end up with the correct total of 312 for the PAL frame?

We know that R9 does affect the MODE 7 screen but I still don't quite see how to use it for this effect if we can't turn off the screen to get a hard edge at the top.

On a side note - do all the CRTC registers, other than R12+R13, get read on demand, i.e. not cached? So if I'm changing R9 throughout the frame (for some funky effects) then this just needs to be timed appropriately, not necessarily using vertical rupture to generate additional CRTC cycles?

Rich Talbot-Watkins wrote:Second edit to add: Something still doesn't quite figure though. I assume the SAA gets display enable low during hsync where I would've expected it increments its scanline counter. So maybe it's not relying on that. Or maybe it increments it on the rising edge, i.e. when the left border ends, just prior to starting a new visible line. Would need to look at the circuit diagram and the datasheet to determine this I guess.

That was going to be my next question: can someone with better understanding of the Beeb circuit diagram and the SAA datasheet figure this out (please)?

Rich Talbot-Watkins wrote:Third edit to add: Conceal text is no good because it gets cancelled by any other colour control codes. Rats!

:D
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
1024MAK
Posts: 6785
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: MODE 7 Vertical Rupture

Postby 1024MAK » Thu Mar 09, 2017 3:23 pm

With interlaced video, there is a big difference between a video field and a video frame. A video frame is made up of two fields. TV standard analogue video (even before PAL or NTSC was developed, which are bolt on colour standards) only transmits one complete frame at 25Hz. Each frame is made up of two interlaced fields. There are two different fields. Each field is transmitted at 25Hz, so taken together, that makes the fields 50Hz.

In the first transmitted field, the first line of video information is displayed on at the top of the screen. The vertical (or field) scan coils (controlled by the vertical time base circuits) moves the electron beam down continually. So the horizontal lines actually slope down slightly, as the line is scanned left to right. Then the horizontal (line) scan coils moves the beam very quickly back to the left. The next line of that field is then drawn. This continues until the bottom. The vertical scan coils then moves the beam to the top again, but now the beam starts halfway across the screen. The next line goes in between the previously drawn lines from the earlier field. Hence interlaced.

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
Rich Talbot-Watkins
Posts: 1117
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: MODE 7 Vertical Rupture

Postby Rich Talbot-Watkins » Thu Mar 09, 2017 3:40 pm

kieranhj wrote:Yes, it certainly seems that the Teletext implementation is one of the weaker aspects of the BBC emulations available. At the Teletext event the other week we also found a bug in the SAA5050 implementation of the Teletext spec regarding Hold Graphics! We suspect this is because the chip was essentially the first produced so was probably designed & implemented around the same time the spec was actually being written & finalised.

Haha if they can't get it right, what hope do we emulator authors have! So what's the nature of the bug? How intriguing.

kieranhj wrote:How exactly does R5 work? According to the AUG these extra lines get added to the end of the screen before retrace or do they actually get added to the start of the screen after retrace? I'm guessing either way the net result is adding a delay to the raster so that the next frame is positioned differently.

It just specifies extra scanlines which are added to the CRTC refresh to fine-tune the timing. In total there are (R4+1)*(R9+1)+R5 scanlines in the frame, and Vsync is triggered at scanline R7*(R9+1). So R5 will always be added after retrace; it's the scanlines at the bottom of the top border, before the screen 'proper' begins. So incrementing it will result in the screen being moved down by pixel amounts. But then you have to take away some scanlines below so the total adds up to 312. One way to do that is with the rupture technique (which is cool because it means you can have a stationary bit of screen underneath the scrolling window with separate addresses), or you can use Firetrack's method and just force one of the character rows to have fewer scanlines by making changes to R9 with some careful timing.

kieranhj wrote:I'm not sure that the interlace does work in my first example - again this is just beyond my understanding of how the PAL signal is constructed. I did notice that in this instance the Teletext characters look weird & blocky - presumably missing the diagonal interpolation that happens when upscaling the internal 6x10 character set into 12x20 (interlaced) pixels. I need to read that documentation you helpfully linked a few times I think. :)

Yeah, fairly sure the rupture technique won't work correctly with interlace unless you split an odd number of times, because the SAA will be getting the same field each frame (as both odd and even fields will occur within one PAL frame).

kieranhj wrote:Ah OK, so if I understand correctly Firetrack achieves its scrolling by: setting R5 to offset the top of the screen by up to one character row (8 scanlines), using R8 to turn off the screen for the top character row so we get a consistent border, then turning the screen off at the bottom of the desired window and finally rounding off by setting R9 to reduce the last character row to have 8-R5 scanlines so we end up with the correct total of 312 for the PAL frame?

Yeah pretty much. I would probably set R9 to 16-R5 for one row, and reduce the row total by one, just for easier timing!

kieranhj wrote:We know that R9 does affect the MODE 7 screen but I still don't quite see how to use it for this effect if we can't turn off the screen to get a hard edge at the top.

Yeah, ordinarily changing R9 will screw everything, because the SAA expects 10 scanlines per character (and counts them accordingly). But you would just need to change it for one offscreen row when apparently the SAA isn't counting. We know this won't affect anything as it happens after VSync and before the new frame starts.

kieranhj wrote:On a side note - do all the CRTC registers, other than R12+R13, get read on demand, i.e. not cached? So if I'm changing R9 throughout the frame (for some funky effects) then this just needs to be timed appropriately, not necessarily using vertical rupture to generate additional CRTC cycles?

Yep exactly. R12 and R13 are only read at the frame start (they're transferred into the current address internal register). Everything else is read at the moment it's required, and compared for equality. So yeah timing can be crucial when doing the Firetrack trick - and also if you've set R9 to 13 (for example), and the internal counter has already passed 13, it won't trigger until it wraps back around to 13 - beware!

kieranhj wrote:can someone with better understanding of the Beeb circuit diagram and the SAA datasheet figure this out (please)?

I think the best way is to infer it from what the hardware does when pushed to these kind of limits. Fairly sure we've already got a pretty good understanding of everything now, but there are still a few SAA inputs which I haven't quite figured yet. It'd be nice to know what happens if you use R8 to turn display off and on again during the middle of a line refresh. Does it increment the counter again, or is that tied more to Hsync? And if not, how does it know not to count outside the bounds of the teletext screen?

User avatar
1024MAK
Posts: 6785
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: MODE 7 Vertical Rupture

Postby 1024MAK » Thu Mar 09, 2017 4:20 pm

More detail on interlaced video here (PDF)

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 7:48 pm

1024MAK wrote:More detail on interlaced video here (PDF)

Mark

Thanks Mark! That made for some interesting reading on the train, although I quickly got to my limit of analogue signal theory. The stuff about colour perception and encoding was all very enlightening, also the specific numbers involved in constructing an image (e.g. why each scanline is 64us, number of scanlines for vertical retrace) plus the part about Teletext encoding, of course. :)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 9:36 pm

1024MAK wrote:With interlaced video, there is a big difference between a video field and a video frame. A video frame is made up of two fields. TV standard analogue video (even before PAL or NTSC was developed, which are bolt on colour standards) only transmits one complete frame at 25Hz. Each frame is made up of two interlaced fields. There are two different fields. Each field is transmitted at 25Hz, so taken together, that makes the fields 50Hz.

In the first transmitted field, the first line of video information is displayed on at the top of the screen. The vertical (or field) scan coils (controlled by the vertical time base circuits) moves the electron beam down continually. So the horizontal lines actually slope down slightly, as the line is scanned left to right. Then the horizontal (line) scan coils moves the beam very quickly back to the left. The next line of that field is then drawn. This continues until the bottom. The vertical scan coils then moves the beam to the top again, but now the beam starts halfway across the screen. The next line goes in between the previously drawn lines from the earlier field. Hence interlaced.

Mark

It's funny how these topics come up every few years - I did a search for "interlace" and there are some interesting & illuminating threads from 5+ years ago that are quite similar. :)

I'm still slightly confused as to how interlace applies to the Beeb though, please forgive me. Given that any PAL signal has 625 lines split across two interlaced fields, but the Beeb can only output 312 lines, what exactly is the effect of turning interlace on or off for MODES 0-6? Presumably we're sending the same data to both fields in both instances anyway? Or are we sending nothing to one of the fields if interlace is disabled? I can just about see the difference on my Sony CRT with my Model B in MODE 0, with the non-interlaced picture being more "steady".

In MODE 7 I can grok it more because the display comes through the SAA Teletext chip which will send different data depending on the field.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 9:40 pm

Rich Talbot-Watkins wrote:
tricky wrote:You may still need vertical rupture to get the vsync consistent, otherwise you will get the screen bouncing on some CRTs (like Gil and I did bitd).

Yeah, wrapping R5 from 7 back round to 0 always resulted in a big bounce when I used to try this back in the day. It was only many years later that I learnt why...

So I did try both versions on my Model B with Sony CRT TV and it works the same as my LCD. I have no problem adding additional scanlines to the display with just R5 all the way up to 31, which shifts screen down by 3 character rows. Am I just "lucky" that the TV is relatively new and can therefore cope with a wider range of input signals - would this cause an older TV to barf and start rolling the display?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

SarahWalker
Posts: 1040
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby SarahWalker » Thu Mar 09, 2017 10:24 pm

kieranhj wrote:I'm still slightly confused as to how interlace applies to the Beeb though, please forgive me. Given that any PAL signal has 625 lines split across two interlaced fields, but the Beeb can only output 312 lines, what exactly is the effect of turning interlace on or off for MODES 0-6? Presumably we're sending the same data to both fields in both instances anyway?

In interlaced sync mode (which the OS uses for MODES 0-6), the same data is sent for both fields, but each field is offset by half a line, meaning the display jumps/flickers slightly. This is more noticeable on some displays than others - on my old Hitachi 14" TV it looked really bad.

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Thu Mar 09, 2017 10:38 pm

SarahWalker wrote:In interlaced sync mode (which the OS uses for MODES 0-6), the same data is sent for both fields, but each field is offset by half a line, meaning the display jumps/flickers slightly. This is more noticeable on some displays than others - on my old Hitachi 14" TV it looked really bad.

So in a non-interlaced mode the fields are just not offset? So effectively there are gaps between the scanlines and whether you can see these or not is dependant on the TV screen again?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
tricky
Posts: 1916
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: MODE 7 Vertical Rupture

Postby tricky » Thu Mar 09, 2017 11:35 pm

kieranhj wrote:So I did try both versions on my Model B with Sony CRT TV and it works the same as my LCD. I have no problem adding additional scanlines to the display with just R5 all the way up to 31, which shifts screen down by 3 character rows. Am I just "lucky" that the TV is relatively new and can therefore cope with a wider range of input signals - would this cause an older TV to barf and start rolling the display?


Warning, lots of guess work follows:

I never tried it in mode 7, but I can't see why that would make a difference.

I believe it jumps because there used to be an analogue circuit which tried to smooth out the vertical offset.

I think it is similar to why changing the h-sync pulse width can be used to move the screen half a character sideways on a CRT, but not a new LCD.

For both, I guess you could have the digital timing on a new CRT - Any ideas?

I also had a thought about why R5 works for teletext, and my guess is that the chip only counts h-syncs when the video is enabled, meaning that it starts when the display does.

I also had some mad ideas about having multiple h-sync pulses in a single scan line to trick the teletext chip in to thinking multiple lines had passed, my guess was that they could be short enough and not be noticed by a TV (One of my LCDs barely notices a full size one!).

guesser
Posts: 143
Joined: Mon Jun 26, 2006 9:21 pm

Re: MODE 7 Vertical Rupture

Postby guesser » Fri Mar 10, 2017 10:14 pm

kieranhj wrote:Given that any PAL signal has 625 lines *snip*


Apart from the ones that don't. [-X

Sorry, conflating PAL with 576i is a particular bugbear of mine :P

guesser
Posts: 143
Joined: Mon Jun 26, 2006 9:21 pm

Re: MODE 7 Vertical Rupture

Postby guesser » Fri Mar 10, 2017 10:37 pm

Rich Talbot-Watkins wrote:Haha if they can't get it right, what hope do we emulator authors have! So what's the nature of the bug? How intriguing.


Based on the output from Kieran's Mode 7 image converter the SAA5050 appears to have a hold mosaics bug where it only stores a mosaic character in its internal register if a hold mosaic control code has been encountered on the line, otherwise it ignores it.
As an example consider a line which contains the following characters:

Code: Select all

white mosaics code, any pattern of mosaic 'sixels', hold mosaics code, red mosaics code, green mosaics code, blue mosaics code, etc.

The SAA5050 starts the line with its "held mosaic" register set to the space character which it displays in place of the white mosaics code (so far so good), then it displays the appropriate mosaic for the next character code but crucially does not store the code in its internal register. After that it displays spaces for all the subsequent control codes rather than the same mosaic character in various colours etc.

At the show we saw that the real beebs exhibited this behaviour, as did the teletext decoder of a very old LOGIK TV. We didn't dismantle it to confirm that it also used an SAA5050 but the character set was right and I can't believe that two chips have the exact same bug and character set. :D

I didn't have time during the event to experiment further and I don't have a beeb set up here, so I don't know if it only works correctly when hold is active or if it works after a hold and release. I would expect the former, that the logic to store a value is erroneously combined with a register bit stores hold mode.

SarahWalker
Posts: 1040
Joined: Fri Jan 14, 2005 3:56 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby SarahWalker » Fri Mar 10, 2017 10:46 pm

Rich Talbot-Watkins wrote:Actually, that's another question - how does interlaced sync and video work in this case? By ramming two CRTC frames into a single PAL refresh, are you getting odd and even fields in the same refresh, or does the SAA chip also determine odd/even by some other means (e.g. counting VSyncs and alternating)?

Just had a quick look at this as it was bugging me, the SAA5050 is determining odd/even field via the CRS input, which is connected to !SC0 on the CRTC.

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Sat Mar 11, 2017 11:23 am

So, I managed to get this working as I wanted: single scanline scrolling with hard edge top & bottom borders on real hardware. It took a bit of work and some very careful timers but the overall approach is:

For a scrolling window of 23 character rows with a blank row above & below, top character row must remain blank spaces. Then say we want N blank scanlines we compress rows 1 + 2 into a single 10 scanline row with very careful timing.

    Wait for vsync interrupt
    Set R5 (Vertical Total Adjust) to 12-N -> moves screen down by 10-N scanlines

    Wait exactly 12-N scanlines -> interupt lands on scanline 0 of CRTC row 0
    Set R9 (scanlines per character) to N-1 -> first character row is all blanks so we get N blank scanlines - SAA counts N scanlines

    Wait exactly N scanlines -> interrupt lands on scanline 0 of CRTC row 1
    Set R9 to 2*(9-N) (adjusted for interlace) -> gives us 10-N scanlines of the second character row

    *crucially because the SAA does its own scanline counting internally we get the bottom 10-N scanlines of the character set, as we wanted, rather than the top, which we see in the emulator - so this only looks correct on real HW today*

    Wait exactly 10-N scanlines -> interrupt lands on scanline 0 of CRTC row 2
    Set R9 to 18 (mode 7 default) -> we're all back in sync between SAA & CRTC

    Wait exactly 22 character rows -> interrupt lands on scanline 0 of CRTC row 24
    Set R9 to N-1 -> gives us N scanlines of the last character row (SAA provides top N scanlines of the character set, as we want)

    Wait exactly N scanlines -> interrupt lands on scanline 0 of CRTC row 25
    Set R9 back to 18
Phew! But take a look, it does work. :D I ended up making a small addition to the b-em debugger (screen x,y coordinates during render which effectively represents the "beam" position) so I could get the timing spot on.

The observant amongst you will realise than N=0 is a special case - for this I'm setting R5=12 but only drawing 23 character rows starting at row #1.

The doubly observant will notice that I don't have a complete 312 line screen here because I'm compressing two 10 scanline character rows into one, so I'm 10 scanlines short. I'm sure this can be fixed by adding an extra character row to the CRTC that's not displayed. I will get that fixed but wanted to share where I'd got to.

Finally, there is still a little bit of "bibbling" at the top of the screen when it comes to graphics characters, this doesn't seem to be present with text, which is rock solid. I wonder if the SAA handles graphics characters in a particular way?
Attachments
mode7-smooth.zip
Single scanline scroll, hard borders, real hardware
(2.63 KiB) Downloaded 23 times
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
simonm
Posts: 166
Joined: Mon May 09, 2016 2:40 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby simonm » Sat Mar 11, 2017 11:37 am

=D> =D> Very cool!

tom_seddon
Posts: 84
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby tom_seddon » Sat Mar 11, 2017 2:54 pm

I'm afraid the new one had problems on my Master 128 + CRT :( - http://www.tomseddon.plus.com/beeb/VID_ ... 255946.mp4

--Tom

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Sat Mar 11, 2017 3:02 pm

tom_seddon wrote:I'm afraid the new one had problems on my Master 128 + CRT :( - http://www.tomseddon.plus.com/beeb/VID_ ... 255946.mp4

--Tom

I'm guessing 312 lines is important then. :) I will fix that up and try again. Weird that my TV's are so tolerant of just about anything.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
leenew
Posts: 3393
Joined: Wed Jul 04, 2012 3:27 pm
Location: Doncaster, Yorkshire

Re: MODE 7 Vertical Rupture

Postby leenew » Sat Mar 11, 2017 3:21 pm

Hi,
It's really jittery on my commodore 1084 monitor with a model B. :cry:

Thanks,

Lee.

User avatar
kieranhj
Posts: 524
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: MODE 7 Vertical Rupture

Postby kieranhj » Sun Mar 12, 2017 12:32 am

leenew wrote:Hi,
It's really jittery on my commodore 1084 monitor with a model B. :cry:

Thanks,

Lee.

Bugger! Please could someone try this version on their system that was previous jittery? I've adjusted the CRTC setups so should (fingers crossed) have 312 lines per frame as required. Still getting a bit of flicker on the top row but I think that's something to do with the timing of the line copy rather than anything else. My main concern is whether the picture is stable on your CRT? Mine is fine but clearly it is happy to accept out of range signals. :(
Attachments
mode7-smooth.zip
Please test whether the image is stable on your CRT!
(2.66 KiB) Downloaded 25 times
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

tom_seddon
Posts: 84
Joined: Mon Aug 29, 2005 11:42 pm
Contact:

Re: MODE 7 Vertical Rupture

Postby tom_seddon » Sun Mar 12, 2017 1:59 am

kieranhj wrote:Bugger! Please could someone try this version on their system that was previous jittery? I've adjusted the CRTC setups so should (fingers crossed) have 312 lines per frame as required. Still getting a bit of flicker on the top row but I think that's something to do with the timing of the line copy rather than anything else. My main concern is whether the picture is stable on your CRT? Mine is fine but clearly it is happy to accept out of range signals. :(


Looks very nice now :)

It does have the flicker on the top row.

--Tom


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest