MODE 7 emulation (was SAA5050 Reverse Engineering)

[jgharston]

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.

Yes, eg &23 in video memory should be rendered as a UKP symbol. The VDU driver and the OSBYTE 135 read-char-from-screen code must shuffle between video memory codes and ASCII codes.

[guesser]

the Parrot of Doom

I shall have to adopt that name for that test

[Soruk]

the Parrot of Doom

I shall have to adopt that name for that test

I can't take any credit for that, that's from scarybeasts' disc menu!

[Soruk]

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.

Yes, eg &23 in video memory should be rendered as a UKP symbol. The VDU driver and the OSBYTE 135 read-char-from-screen code must shuffle between video memory codes and ASCII codes.

I'd forgotten about OSBYTE 135 - that's now fixed and checked in.

[Deleted User 9295]

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.

We discussed this last August. You said then:

"I see the difference here being that the BBC stores the unshuffled character, Matrix Brandy stores the shuffled character value when the high bit isn't set. I can fix this (not straight away as I'm away on holiday) but the array it's reading holds the values by the screen update code and GET(x,y) so I would rather not change that - most likely I'd shuffle in the read and write memory calls for that address block".

I'm not clear whether that's what you've ended up doing, but it might be worth checking that your concerns then have been addressed.

[Soruk]

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.

We discussed this last August. You said then:

"I see the difference here being that the BBC stores the unshuffled character, Matrix Brandy stores the shuffled character value when the high bit isn't set. I can fix this (not straight away as I'm away on holiday) but the array it's reading holds the values by the screen update code and GET(x,y) so I would rather not change that - most likely I'd shuffle in the read and write memory calls for that address block".

I'm not clear whether that's what you've ended up doing, but it might be worth checking that your concerns then have been addressed.

I had forgotten about that - annoyingly. Still, it's fixed now. The shuffle code is removed from the MODE 7 line rendering code and added to the VDU driver and OSBYTE 135 handler. Characters in the buffer are, as they are on the BBC Micro, stored in memory in the values expected by the SAA5050.

[Deleted User 9295]

I had forgotten about that - annoyingly.

That's supposed to be my problem, not yours!

[Coeus]

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.

And isn't the the approach taken by both BBC BASIC for SDL and Matrix Brandy BASIC? It would make sense for something which doesn't claim to be a BBC micro but simply to run BASIC programs that were written for it. Emulator writers are more likely to refer to the actual hardware.

Back to the issue of fonts, do you know anything of the history of the teletext fonts that ended up in Matrix Brandy BASIC and in BBC BASIC for SDL? As you say, there are remarkably similar. Did one or both of them originate with the Mode 7 emulation in RiscOS? Compared to B-Em's usual font which is constructed by up-scaling the SAA5050 font (for text characters, not sixel graphics - the sixel character definitions were never in the SAA5050) the BBC BASIC for SDL and Matrix Brandy fonts have quite a square look about them. One factor maybe that B-Em up-scales to grey-scale rather than two-level, but I wonder if there is anything else.

[Soruk]

Back to the issue of fonts, do you know anything of the history of the teletext fonts that ended up in Matrix Brandy BASIC and in BBC BASIC for SDL? As you say, there are remarkably similar. Did one or both of them originate with the Mode 7 emulation in RiscOS?

Matrix Brandy has a pixel-perfect copy of what is present in RISC OS 5. I couldn't find the font definition in the RO5 sources so I worked from a screengrab from RPCEmu and hand-calculated the 16x20 font - with one exception. I didn't like the * rendition, so I reworked it to be a stretched version of the SAA5050 shape. If memory serves, I think Richard calculated his from stretching the Bedstead font (which would explain the SAA5050 shape of the * character). My sixels are calculated on the fly with an and-mask for separated graphics.

[Deleted User 9295]

I think Richard calculated his from stretching the Bedstead font

That's basically right, except that I didn't need to do the stretching myself because Bedstead has an 'extended' version (Bedstead-ext.otf) which is already the correct shape. There was still plenty of opportunity for me to add my own 'artistic touch' because the sampled Bedstead characters were rarely usable without editing - both because of sampling artefacts and because Bedstead is based on the original SAA5050 font so doesn't take advantage of the increased resolution available in a 16x20 bitmap.

[Deleted User 9295]

the sixel character definitions were never in the SAA5050

Not in the sense of being stored as bitmaps, but of course they are still defined and generated by the SAA5050, albeit by counters and logic gates.

[kieranhj]

the Parrot of Doom

I shall have to adopt that name for that test

I can't take any credit for that, that's from scarybeasts' disc menu!

That’s my creation, sorry!

[Deleted User 9295]

I wonder if there is anything else.

A contributory factor could be that both I and Soruk assume that 'graphics units' are square, but on the BBC Micro they're not. So all output, whether in MODE 7 or any other mode, will appear stretched horizontally compared with how it would look on a BBC Micro (feeding a TV or correctly-adjusted monitor).

The Beeb's master pixel clock is 16 MHz (12 MHz in MODE 7), it would have needed to be about 14.75 MHz to produce square graphics units. Or put another way, the MODE 7 character cell in BBC BASIC for SDL 2.0 and Matrix Brandy would need to be 15 pixels wide, not 16, to come close to the BBC Micro's rendering.

[Coeus]

Not in the sense of being stored as bitmaps, but of course they are still defined and generated by the SAA5050, albeit by counters and logic gates.

Indeeddreamsel has described the logic in the reverse engineering thread: viewtopic.php?p=307064#p307064

But what I really meant was in the character ROM. Sarah explained above that B-Em's current rending of the separated graphics has sixels of uneven width because a 6x10 cell is being up-scaled to 16x20. Brandy generates the graphics on-the-fly as I assume BBC BASIC for SDL does and it seems like B-Em may be able to produce a version of these sixels that is more like how they actually appear by ignoring the 6x10 grid and generating the sixels directly into the 16x20.