MODE 7/75

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

MODE 7/75

Postby kieranhj » Tue Jan 17, 2017 10:05 pm

Hey all,

Small oddity this one. I've been messing around with CRTC registers (as you do) to better understand how R9 (scanlines per character) can be used and ideally abused for some interesting demo effects. As I'm (still) on a big MODE 7 odyssey, I came up with a variation that has 75 character rows, each just one teletext pixel high (6 interlaced scanlines) - this means you're only limited to two colours (background + foreground) per 2x1 pixel block rather than 2x3 character cell. It does require 3x as much memory and, here's the kicker, you have to copy those 3000 bytes into the screen buffer at &7C00 just ahead of the raster.

mode7-75.zip
MODE 7/75 no Hold Graphics
(16.22 KiB) Downloaded 24 times

Take a look at the attached disk to see what I mean. When it boots (or if you use *MODE775 on its own) you'll get a screen of stripes but more than two colours per "character row". Use *MODE775 <file name> to load one of the 3000 byte images that I created by hacking my old image2mode7 tool to generate triple height MODE 7 screen buffers. If you *LOAD one of the files then you'll see what the Teletext chip thinks it contains, but we're only letting it send the top few scanlines of each character row to the actual screen.

More technical details: R9 is set to 4 (so actually 6 interlaced scanlines per character row.) I'm using vertical rupture to rewrite carefully chosen CRTC registers 3x per frame (25 visible rows but must calc vsync + vertical total in terms of the squished character rows) then using an unrolled copy loop, also appropriately timed, to copy data starting at &7000 in 1000 bytes chunks to &7C00 three times.

Not sure what use this is, as to the untrained eye the resulting images are not that different from a usual MODE 7 limited screen, but I think there could be some mileage in demo effects that are generated "just in time" for the raster that break the limitations of traditional Teletext (but without requiring 16+k for an 8 colour screen.) Given that you have to copy 3000 bytes around every 20ms there's not a great deal of time for anything else but you could just write results directly to the frame buffer if appropriately organised.

I'll lob the code on GitHub shortly if anyone's interested. I haven't tested this on real hardware yet but B-Em and jsbeeb are happy (BeebEm explodes.) Let me know what you think!

Edit: just tried this on my Master and got some nasty artefacts which I suspect are my misunderstanding of how Hold Graphics works in Teletext rather than the approach itself. I will regenerate the pictures without Hold Graphics to keep things simple. (This would suggest there's a bug in B-Em and jsbeeb for how Hold Graphics is supported but I'll worry about that another day.)

Edit 2: after removing the Hold Graphics character I no longer get blank characters in the image but on a real machine I get significant horizontal gaps (albeit quite stable.) Hmm, this warrants further investigation. I guess CRTC + Teletext emulation is hard, particularly when I'm trying to break them. :D
Attachments
WP_20170117_22_32_14_Pro.jpg
Parrot real hardware
red75.jpg
Parrot in B-Em

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

Re: MODE 7/75

Postby kieranhj » Wed Jan 18, 2017 8:02 pm

Hmmm, I wonder if this is the issue:

dp11 wrote:A very small bug. I think. In mode 7 if you set R9 of the 6845 to 31 and display an "A". You get the full "A" but then the top of "B" where are it should I think be the top of "A" . The SAA5050 should should count hsync pulses to work out which row of a character to display and not sneak a look at the 6845 :)

Can anyone concur?

(From http://stardot.org.uk/forums/viewtopic.php?p=149906.)

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

Re: MODE 7/75

Postby kieranhj » Wed Jan 18, 2017 9:12 pm

So that does seem to be the case - if I change the MODE 7 frames to be full character blocks (not just the top two Teletext pixels) then the image becomes whole.

parrot_beeb_working.jpg

There's obviously a small timing or register issue somewhere as there's still a single black line, but overall pretty close.

Updated ssd attached. At least I know this is viable on real hardware - just wondering what the "practical" applications might be! :)
Attachments
mode7-75.zip
(16.2 KiB) Downloaded 13 times

User avatar
FourthStone
Posts: 386
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: MODE 7/75

Postby FourthStone » Wed Jan 18, 2017 10:15 pm

Nice one, good to see the hardware being pushed to the limits :twisted:

I always thought that mode 7, with it's tiny comparable ram requirements, would be a good (only!) option for video shorts or similar demos. I think utilizing a bank (or three) or sideways ram plus what ever is left below vid ram combined with some hefty compression might allow 10-20 seconds of pixelated magic :-k

Thanks for posting the details.

SteveF
Posts: 429
Joined: Fri Aug 28, 2015 8:34 pm

Re: MODE 7/75

Postby SteveF » Wed Jan 18, 2017 11:02 pm

kieranhj wrote:So that does seem to be the case - if I change the MODE 7 frames to be full character blocks (not just the top two Teletext pixels) then the image becomes whole.

Congratulations, really glad (and impressed) you managed to get this working on real hardware! The improvement over regular mode 7 might not be obvious to the inexpert eye but I bet it will make a big difference on the right images. Might this make dithering much more attractive?

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

Re: MODE 7/75

Postby kieranhj » Wed Jan 18, 2017 11:07 pm

FourthStone wrote:Nice one, good to see the hardware being pushed to the limits :twisted:

I always thought that mode 7, with it's tiny comparable ram requirements, would be a good (only!) option for video shorts or similar demos. I think utilizing a bank (or three) or sideways ram plus what ever is left below vid ram combined with some hefty compression might allow 10-20 seconds of pixelated magic :-k

Thanks for posting the details.

Thanks. Will post the code now it works.

You've not seen my 3 minute MODE 7 video demo that fits on a double sided 80T disk (400K) and runs on an unexpanded Model B with a real floppy drive, have you? Yeah, I should finish that one and release it... still trying to find some awesome music though. :-k

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

Re: MODE 7/75

Postby kieranhj » Wed Jan 18, 2017 11:18 pm

SteveF wrote:Congratulations, really glad (and impressed) you managed to get this working on real hardware! The improvement over regular mode 7 might not be obvious to the inexpert eye but I bet it will make a big difference on the right images. Might this make dithering much more attractive?

Thanks Steve. It should be easy enough to add 75 rows as an option to the image converter (rather than just hacking it) so can definitely post it and do some more tests.

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

Re: MODE 7/75

Postby Rich Talbot-Watkins » Thu Jan 19, 2017 1:32 pm

kieranhj wrote:Hmmm, I wonder if this is the issue:

dp11 wrote:A very small bug. I think. In mode 7 if you set R9 of the 6845 to 31 and display an "A". You get the full "A" but then the top of "B" where are it should I think be the top of "A" . The SAA5050 should should count hsync pulses to work out which row of a character to display and not sneak a look at the 6845 :)

Can anyone concur?

(From http://stardot.org.uk/forums/viewtopic.php?p=149906.)

Yeah, it looks as if the SAA5050 doesn't have scanline number input pins, so it must have internal counters which keep track of this. Glancing over the datasheet, the only signal I can see which seems kind of pertinent to the display layout is LOSE (load output shift register enable) which appears to need to be high for the duration of the display enabled part of the screen. So I guess it uses this to count scanlines.

This raises a few questions:
  1. How does the 5050 distinguish between the start of a character row and the start of a new scanline within a character row? The latter needs to reset its internal scanline counter.
  2. Or does it just assume characters of 10 scanlines? How does it synchronise the start of the frame in that case?
  3. What happens if R9 is set differently from its default? If R9<18, do we get the second character row starting midway down? If R9>18, what does it do with the extra rows? Wraparound? Blank?
  4. Does LOSE come from DISEN from the 6845? Is it possible to confuse Mode 7 by turning display off and on midline, and forcing it to start a new line prematurely?
  5. How are the other 5050 inputs derived from the CRTC and/or Video ULA outputs?

I think there's definitely a few unexplored corners of Mode 7 to be exploited! The hold graphics thing is utterly obscure (and not even documented in the SAA5050 datasheet, not that I guess it would be), but I think the actual hardware itself probably has a few edge cases which have not yet been thoroughly experimented with!

That parrot looks great with the 75 row mode btw! :)

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

Re: MODE 7/75

Postby SarahWalker » Thu Jan 19, 2017 6:38 pm

Rich Talbot-Watkins wrote:[*] Or does it just assume characters of 10 scanlines? How does it synchronise the start of the frame in that case?

Looks to be the DEW pin, which is connected to VSYNC on the 6845.

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

Re: MODE 7/75

Postby Rich Talbot-Watkins » Thu Jan 19, 2017 8:21 pm

Right, and having looked at the Beeb circuit diagram, it looks like GLR is derived from HSYNC. LOSE appears to come from DISEN (and is latched by IC15), so I guess it all begins to fit into place.

So I'm assuming, based on that, that the 5050 is hardwired to generate 10 scanline high characters. Which means, in theory, when setting R9 to a lower value, it wouldn't start subsequent rows at scanline 0, but instead according to its own internal counter (but fetching new character data from the next row of the screen). I wonder how this corresponds to the results from real hardware. I'd've thought, given that teletext pixels are not uniform in height (they go 3, 4, 3 within the character), you'd get strange visual results unless the CRTC row heights were also set to 3, 4, 3 scanlines. Maybe I'm missing something else?

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

Re: MODE 7/75

Postby kieranhj » Thu Jan 19, 2017 8:40 pm

Rich Talbot-Watkins wrote:So I'm assuming, based on that, that the 5050 is hardwired to generate 10 scanline high characters. Which means, in theory, when setting R9 to a lower value, it wouldn't start subsequent rows at scanline 0, but instead according to its own internal counter (but fetching new character data from the next row of the screen). I wonder how this corresponds to the results from real hardware. I'd've thought, given that teletext pixels are not uniform in height (they go 3, 4, 3 within the character), you'd get strange visual results unless the CRTC row heights were also set to 3, 4, 3 scanlines. Maybe I'm missing something else?

Yes, that's what I'm seeing above on real hardware. When I was only using the top two teletext pixels I got empty spaces where the 5050 was reading from scanlines beyond 3. This was "fixed" when I started using full character blocks. Essentially I've just got a triple height MODE 7 screen and then squashing it so each character row is only 3 scanlines (but clearly those can be taken from different parts of the actual character definition.)

Characters are actually output from 5050 as 12x20 according to Wikipedia but given that we're interlaced can treat this as 12x10. In the example above I'm only displaying 3x 75 scanlines (225) so "missing" 25 lines. I too am not sure why this works with internal scanline counting going 3, 4, 3 up to 10. It would be possible to make a screen like this but would require tighter timing for the vertical rupture and screen character row copy code.

User avatar
Lardo Boffin
Posts: 594
Joined: Thu Aug 06, 2015 6:47 am

Re: MODE 7/75

Postby Lardo Boffin » Thu Jan 19, 2017 9:03 pm

Looking at the rather cool parrot image are you able to set single 'pixels' to different colours without all the business of wasting a whole character setting the colour first? If so that could make for some awesome low resolution games.
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

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

Re: MODE 7/75

Postby Rich Talbot-Watkins » Thu Jan 19, 2017 9:37 pm

Now I've looked again at the gappy parrot captured from a real machine, I see there are exactly the kind of artefacts I'd expect to see, e.g. orphaned single pixel scanlines and blocks of (what looks like) 2 pixel high runs of colour. Not entirely sure what would be responsible for the gaps! It shouldn't be possible to read off the end of a character glyph (the internal counter ensures that).

Seems to me that, to be able to get unique control codes per teletext pixel, you're going to need to do far more careful timing, and set R9=4, apart from every third one (starting from the second) which has R9=6 - in order to coincide with the graphics glyphs. Which sounds horrible!

User avatar
SimonSideburns
Posts: 251
Joined: Mon Aug 26, 2013 8:09 pm
Location: Purbrook, Hampshire
Contact:

Re: MODE 7/75

Postby SimonSideburns » Thu Jan 19, 2017 10:26 pm

Like you say, I didn't get anything similar to your images on BeebEm (hardly surprising).

Sounds like it could be a nice effect though.

I'm not as technical as you guys so don't worry if I'm simply rambling, but if you only printed full blocks (all six elements of a graphic) would it then not matter if it was on a 4 or a 3?
I'm writing a game where you can change your character from a Wizard to a monkey to a cat.

Well, Imogen that!

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

Re: MODE 7/75

Postby tricky » Thu Jan 19, 2017 10:44 pm

I was thinking along similar lines to Simon, but having five scan lines per character with the whole height the same colour.
I think this would effectively double the vertical colour resolution (2/3 vertical "pixel" resolution) and not require any special timing.
On a model B, you could even use the 2K mode 7 trick and not have to do any copying ;)

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

Re: MODE 7/75

Postby Rich Talbot-Watkins » Fri Jan 20, 2017 11:54 am

Yeah that's a possibility too, definitely less timing sensitive, and also less to copy around (freeing up some time to do... anything else). Would still allow for higher resolution attribute changes too, though not per-teletext-pixel as might have been nice.

Still struggling to think of a cause for the 'hold graphics' gaps in the parrot. Assuming that the held value is reset at the start of each line, I can't see why it would work any differently. I found this specification document here - http://www.etsi.org/deliver/etsi_i_ets/ ... 06e01p.pdf - and G.3.3 specifies a particularly tricky case which I doubt any of the emulators handle (the separated graphics attribute not taking effect until the first non-control code is encountered, if held graphics is enabled).

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

Re: MODE 7/75

Postby simonm » Fri Jan 20, 2017 12:33 pm

On a related note, Kieran and I have been working on a teletext demo lately (we're trying hard to finish it up!).
One of the effects is taking advantage of the hold graphics feature to give a 38x25 7 colour character block canvas capability. It works well for certain full screen effects.

Character coding per row is as follows

Code: Select all

(gc0)(158)(255)(gc1)(gc2)(...)(gc37)


where gcN = the graphics colour code for pixel canvas column N (0-37)

One side effect is that there is a doubled column on the left hand side due to the 158,255 but I cant see anyway to dodge that. I also cant see any way to get black 'pixels' either, since storing anything but a graphics colour code between 145-153 seems to break the hold effect for the remainder of the row.

Example:
plasma.png



Adding Kieran's technique above, I presume we could in principle achieve a 38x75 7 colour wide-teletext-pixel canvas. Which could be cool.. :D

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

Re: MODE 7/75

Postby kieranhj » Fri Jan 20, 2017 4:47 pm

tricky wrote:I was thinking along similar lines to Simon, but having five scan lines per character with the whole height the same colour.
I think this would effectively double the vertical colour resolution (2/3 vertical "pixel" resolution) and not require any special timing.
On a model B, you could even use the 2K mode 7 trick and not have to do any copying ;)

Yes, I was thinking exactly the same thing - a 50 row mode would be much easier to implement and I just saw your note on the bbc-micro digest about the memory address wrap around on real Model B hardware. This would give quite nice square-ish pixels but wouldn't look like teletext so much any more with its iconic 2x3 chunky pixel arrangement. I'll knock this up tomorrow and share what it looks like.

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

Re: MODE 7/75

Postby kieranhj » Fri Jan 20, 2017 4:48 pm

simonm wrote:Adding Kieran's technique above, I presume we could in principle achieve a 38x75 7 colour wide-teletext-pixel canvas. Which could be cool.. :D

I actually started this as an investigation to give you 38x50 pixels for the plasma effect! I can probably hack that into the source again...

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

Re: MODE 7/75

Postby kieranhj » Fri Jan 20, 2017 4:54 pm

Rich Talbot-Watkins wrote:Still struggling to think of a cause for the 'hold graphics' gaps in the parrot. Assuming that the held value is reset at the start of each line, I can't see why it would work any differently. I found this specification document here - http://www.etsi.org/deliver/etsi_i_ets/ ... 06e01p.pdf - and G.3.3 specifies a particularly tricky case which I doubt any of the emulators handle (the separated graphics attribute not taking effect until the first non-control code is encountered, if held graphics is enabled).

Yes, this is a bit of a mystery. I've submitted the bug to jsbeeb (which you probably saw) and also to https://github.com/rawles/edit-tf as a bug/query, since I was using that as a reference and Simon Rawles is part of the small group of hard-core UK Teletext enthusiasts. At first I wondered if this was a variation from the standard in the implementation of the SAA5050 but apparently that is an iconic chip used in many, many devices historically, so would seem unlikely! I'm hoping they figure out what's happening here.

I also saw the note about separated graphics being held, err, separately for the hold character but never seen this "in the wild".


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest