MODE 7 emulation (was SAA5050 Reverse Engineering)

[Deleted User 9295]

Out of the emulators I've got lying around, only beebjit and b2 look to render it ok.

If you acknowledge them as "emulators" (which as far as MODE 7 is concerned they are) you can add BBC BASIC for Windows and BBC BASIC for SDL 2.0 to the list.

BBCSDL:

BBC Master for reference:

[scarybeasts]

That's great -- it's definitely got the teletext state machine working correctly.

It may be an intentional choice, but you might want to check your separated graphics rendering, which appears to be bottom anchored instead of top anchored as per the real hardware. (It's similar little rendering issues that prevented me from listing BeebEm as correctly rendered.)


Cheers
Chris

[Deleted User 9295]

It may be an intentional choice, but you might want to check your separated graphics rendering, which appears to be bottom anchored instead of top anchored as per the real hardware.

(Edited for brevity)
Yes, it was intentional. Having available a full 16x20 character cell, with each pixel individually addressable, allows me more flexibility in respect of font design and graphics shapes (for example the three vertically separated 'sixels' are all the same height):

[Soruk]

There was a bug in Matrix Brandy's implementation which was tripped on the Clear Held Character #2 test. I've just checked in a fix for that.

Here's my rendering of how Matrix Brandy spaces the separated graphics...

[Deleted User 9295]

Here's my rendering of how Matrix Brandy spaces the separated graphics...

The issue of how one should render separated graphics in a 16x20 cell is highly subjective. On the SAA5050 there was no choice: its character cell is 6x10 (character rounding doesn't affect graphics) so the only possibilities in the horizontal direction were for the sixels to be one-pixel wide and the gaps to be two-pixels, or for the sixels to be two pixels wide and the gaps to be one pixel. Understandably, the latter option was chosen.

In considering the 16x20 situation, one then has to ask: should one try to emulate the SAA5050 and make the sixels much wider than the gaps - and evidently that's what you have done - or take advantage of the higher resolution to achieve a 'better' result, which is (arguably) for the sixels and the gaps to be the same width - which is what I do.

The main references we have of what should be considered 'optimum' are the various official teletext specifications, but unfortunately they are not very helpful in this regard because they assume that the character cell is seven pixels wide, not six, so their sixels are unevenly spaced with the gaps being alternately one and two pixels!

[jgharston]

From the diagrams in the back of the BBC User Guide, the teletext character font is on a 5x9 grid. From observation there is a 1-pixel gap between characters, so inference is that character cells are a 6x10 pixel grid. This then leads to the conclusion that graphics cells are 3+3 horizontally. Dividing 10 by 3 "won't go", observation shows the middle is bigger, and a big middle spreads the "bulge" evenly, so leading to the conclusion that graphics cells are 3+4+3 vertically.

From observation and rationalisation, separated graphics are 1+2+1+2 horizontally, so the gaps are equal and the blobs are equal. Following on from this is the conclusion that separated graphics are 2+1+3+1+2+1 vertically.
That was my conclusion back when I wrote a teletext print dump program, and a Spectrum teletext emulator. Using the Spectrum's 8x8 character cell gave 1+3+1+3 x 2+1+1+1+2+1.

Plus I'm sure there was probably something in the Telesoftware downloads and/or Micro|Acorn User.

A bit after I did the above I got the actual documentation, which confirmed everything I'd worked out from the user guide and by eye and logic:


So, graphics cells aren't on a 7-pixel grid, and seperated graphics sixels ahould be equally sized and equally spaced horizontally.

[Deleted User 9295]

So, graphics cells aren't on a 7-pixel grid, and seperated graphics sixels ahould be equally sized and equally spaced horizontally.

Everything you said agrees with what I posted, and confirms what we already knew. As such it doesn't, I think, add anything to the debate (if indeed there is a debate) over whether Matrix Brandy's separated graphics are preferable to BBC BASIC for SDL 2.0's separated graphics or not.

They both have "equally sized and equally spaced" sixels horizontally, not least because that is pretty much guaranteed if the character cell is an even number of pixels wide, whether that be 6 or 16!

Either way I won't be changing mine, they have been the way they are for 20 years (in BBC BASIC for Windows) and nobody has ever remarked on them or suggested they could be improved. Changing them now, for whatever motive, fails the test for benefit over cost.

[scarybeasts]

Hi,

Here's an updated SSD with a TELETST that checks behavior of double height change vs. held character. I think this is the correct rendering:

Cheers
Chris

[Deleted User 9295]

Here's an updated SSD with a TELETST that checks behavior of double height change vs. held character.

This is BBC BASIC for SDL2.0's rendering:

[Soruk]

Here's an updated SSD with a TELETST that checks behavior of double height change vs. held character.

This is Matrix Brandy's rendering...

Unlike last time, no further bug fix required

Edit: Here is RISC OS 5.28's rendering. RISC OS 3.71 is equally correct but has the old low-resolution Teletext emulation.

[Deleted User 9295]

Unlike last time, no further bug fix required

Hmm, you had more luck than me:

[Coeus]

Ok, ignoring the new double height change for the moment, here is B-Em's rendering of the scarybeasts test:

So after some bug fixes, the only test it is failing is where the separated graphic is joined to the block before that. What is that test actually testing? After looking at it for a while I am wondering if this is testing the handling of control codes at all and is maybe instead testing the definition of the characters concerned. Do you believe that to be the case?

In B-Em there is also the fact that the characters are resampled to fit a different final resolution than their original definition so this could also be contributing.

Meanwhile I'll download the latest version and test the double-height change.

[Deleted User 9295]

I am wondering if this is testing the handling of control codes at all and is maybe instead testing the definition of the characters concerned. Do you believe that to be the case?

Indeed, I felt exactly the same. With a character cell being only 6 pixels wide on the original SAA 5050, separated graphics sixels are bound to touch either the character cell to the left or the one to the right, and this test seems to be expressing a preference for the latter (which is admittedly consistent with how alphanumerics are positioned).

But it's got nothing to do with control-character decoding or state machine behaviour, so I'd rather remove it from this program. Cosmetic appearance of alphanumerics and mosaics is of interest, but it's in a different category.

[scarybeasts]

So after some bug fixes, the only test it is failing is where the separated graphic is joined to the block before that. What is that test actually testing? After looking at it for a while I am wondering if this is testing the handling of control codes at all and is maybe instead testing the definition of the characters concerned. Do you believe that to be the case?

Yes, that's the case. I added the test when I noticed beebjit wasn't rendering the teletext engineering test page correctly, compared to a real model B.

Like jsbeeb, beebjit copied its glyphs from b-em initially (thanks b-em), so that reminds me: I think a few of the glyphs in b-em are a pixel out here and there, e.g. the "M" glyphs looks like its middle stalk doesn't extend down enough. I found this jsbeeb patch useful: https://github.com/mattgodbolt/jsbeeb/c ... c9cd5d73b8


Cheers
Chris

[Coeus]

Thanks, Chris and Richard. Here's B-Em's rendering of the test now:

and here is the character set with the jsbeeb patch applied:

And here is a program to print the character set in each of the three modes, alphanumeric, contiguous graphics and separated graphics.

Code: Select all

   10MODE7
   20PROCA(32,63)
   30PROCA(64,95)
   40PROCA(96,127)
   50PRINT
   60PROCG(32,63)
   70PROCG(64,95)
   80PROCG(96,127)
   90PRINT
  100PROCS(32,63)
  110PROCS(64,95)
  120PROCS(96,127)
  130PRINT
  140END
  150DEFPROCA(S%,E%)
  160VDU32,32
  170PROCC(S%,E%)
  180ENDPROC
  190DEFPROCG(S%,E%)
  200VDU145,153
  210PROCC(S%,E%)
  220ENDPROC
  230DEFPROCS(S%,E%)
  240VDU146,154
  250PROCC(S%,E%)
  260ENDPROC
  270DEFPROCC(S%,E%)
  280FORC%=S%TOE%
  290VDUC%
  300NEXTC%
  310PRINT
  320ENDPROC

which I have added to the attached SSD along with the others.

What remains slightly odd about B-Em's rendering is that some of the sixels in the separated graphics seem bigger horizontally than others.

[Deleted User 9295]

And here is a program to print the character set in each of the three modes, alphanumeric, contiguous graphics and separated graphics.

BBC BASIC for SDL2.0's rendering:

[SarahWalker]

What remains slightly odd about B-Em's rendering is that some of the sixels in the separated graphics seem bigger horizontally than others.

It's the result of trying to wodge a 6/12 pixel wide font into a 16 pixel wide font. 16 doesn't divide into 3 very well.

[Soruk]

And here is a program to print the character set in each of the three modes, alphanumeric, contiguous graphics and separated graphics.

Matrix Brandy's rendering...

Edit: And, for completeness, here is RISC OS 5.28's rendering of the same test.

[Deleted User 9295]

It's the result of trying to wodge a 6/12 pixel wide font into a 16 pixel wide font. 16 doesn't divide into 3 very well.

That's precisely why my preference is to redesign the entire MODE 7 character set (and mosaics) from scratch to suit a 16-pixel-wide character cell, which is what you see in the above screenshots from BBC BASIC for SDL 2.0 and Matrix Brandy.

Doing that might not be quite so 'faithful' to the original SAA5050, but neither are the results you get from scaling up from 6/12 pixels to 16. I'd rather any 'inaccuracies' result from a subjective improvement rather than a worsening!

(To add more confusion, the aspect ratio would actually be closer to the BBC Micro if the final character cell was 15 pixels wide rather than 16).

[Soruk]

Unlike last time, no further bug fix required

Hmm, you had more luck than me:

This is now fixed - discussion was in the Matrix Brandy thread.

[Coeus]

While we're discussing fonts, I believe there are other chips in the same series as the SAA5050 which have the character set localised to a different place. Did the BBC Micro ever use any of these, the German one, for example?

[Coeus]

That's precisely why my preference is to redesign the entire MODE 7 character set (and mosaics) from scratch to suit a 16-pixel-wide character cell, which is what you see in the above screenshots from BBC BASIC for SDL 2.0 and Matrix Brandy.

Richard, I had a very quick look in the GitHub repository for BBC BASIC for SDL 2.0 and from what I can see it is using TTF font rendering in which case I assume it uses the bundled Bedstead font? Strangely, at https://fontlibrary.org/en/font/bedstead the on-screen examples appears to be in a serif font and yet I am sure the original font is sans-serif (as well as being monospaced).

[Deleted User 9295]

I had a very quick look in the GitHub repository for BBC BASIC for SDL 2.0 and from what I can see it is using TTF font rendering in which case I assume it uses the bundled Bedstead font?

No. BBC BASIC for SDL 2.0 can use TTF and OTF fonts, including Bedstead, but it is supplied with two bitmap fonts to allow it to emulate MODEs 0 to 7 without recourse to TTF and the overheads that implies. These bitmap fonts are an 8x8 font which is used in MODEs 0 to 6 and a 16x20 font which is used in MODE 7.

These fonts can be found in the GitHub repository in the file(s) bbdata_xxx_xxx, for example bbdata_x86_64.nas. Look for the labels bbcfont and ttxtfont respectively.

Soruk's Matrix Brandy also comes with both 8x8 and 16x20 fonts. The former is probably identical to mine (and to the font used on the BBC Micro etc.) but the latter is slightly different from mine. There's some value in having minor differences because it allows for the origin of any illegitimate copies to be traced!

[Deleted User 9295]

While we're discussing fonts, I believe there are other chips in the same series as the SAA5050 which have the character set localised to a different place. Did the BBC Micro ever use any of these, the German one, for example?

BBC BASIC for SDL 2.0 comes with the mode7llb.bbc library which supports selecting the character sets available from the other chips in the SAA505x series. If you have a suitable browser you can see this in action here. Click or press the space bar to toggle between the two pages.

Note that a Greek option is available in my library even though, strangely, I don't believe there was ever a SAA505x chip which provided that language.

[Pernod]

While we're discussing fonts, I believe there are other chips in the same series as the SAA5050 which have the character set localised to a different place. Did the BBC Micro ever use any of these, the German one, for example?

The other SAA505x chips were likely only seen in teletext equipment in other European countries, the German Beeb has the usual SAA5050.

There's also a later SAA5240 series that provided three character sets in a single chip, and SAA5243 providing six. These character sets differ from the SAA5050 in that they are true 12x10 fonts rather than 5x9 that are upscaled and rounded.

The SAA5240 was used in the Morley Teletext adaptors, but only to capture teletext pages, the data was then passed to the BBC to be displayed by the SAA5050. The Electron version of the Morley Teletext adaptor would display the internal character set, so also adds MODE7 to the Electron but this is MIA.

The SAA5240A is also used in the Acorn Communicator, whereas the Italian Communicator uses the SAA5240B which defaults to the Italian character set.

[Soruk]

Soruk's Matrix Brandy also comes with both 8x8 and 16x20 fonts. The former is probably identical to mine (and to the font used on the BBC Micro etc.) but the latter is slightly different from mine.

The most noticeable difference in our 8x8 fonts is the letter Q, where mine is identical to RISC OS and the BBC, yours looks more like a VGA card version.

[Deleted User 9295]

The most noticeable difference in our 8x8 fonts is the letter Q, where mine is identical to RISC OS and the BBC, yours looks more like a VGA card version.

Ah, OK. You can guess which I prefer....

I think I've mentioned before that my father was a commercial artist and I acquired from him an interest in typography which I retain to this day. I have, in the distant past, set metal type from genuine 'lower and upper cases' and even once knew where each character could be found in the case. I also used a treadle-operated printing press on a number of occasions.

[Coeus]

So just for reference, here are some photographs of the same teletext test screens from a BBC Master. Sorry, no CRT, though.

For the last one, I added a further test which switched back from separated graphics to contiguous graphics. This makes plain that the space is the separated graphics is on the left, not centred.

[Deleted User 9295]

This makes plain that the space is the separated graphics is on the left, not centred.

Nevertheless I remain convinced that it should be centred, when that is possible (which it isn't with the SAA 5050, but is with a 16-pixel-wide character cell). That's how the original 1976 Teletext Specification illustrated it.

[Soruk]

So just for reference, here are some photographs of the same teletext test screens from a BBC Master. Sorry, no CRT, though.

Thank you for this, I've now got Matrix Brandy rendering the Parrot of Doom correctly! The way it loads into screen memory, it also showed me I needed to do the character shuffle at the point of writing characters to the screen memory in the VDU driver, rather than the renderer.