Teletext to Viewdata server

[Soruk]

Hi,

Over on the Teefax thread I posted about my Viewdata server, serving Teefax to Viewdata clients.

I'm starting this thread here as it seems I have inadvertently hijacked that thread!

The Viewdata server is at pegasus.matrixnetwork.co.uk teletext.matrixnetwork.co.uk port 6502. It has its limitations, first and foremost FASTEXT isn't supported as it uses the 25th line, which is out of bounds for Viewdata. It's also highly experimental but I try to maintain a 24/7 uptime for it. It also supports "illegal" magazine numbers - as it just looks at the files that underpin the TEEFAX service so all pages in the hexadecimal range 000 to FFE are available, thus supporting a maximum of 4095 individual pages!

As such, it also serves a local service "Matrix Teletext" from P900, mainly featuring some local news services.

EDIT: Disconnect code changed to FFF.

It's listed "out of the box" in Matrix Brandy's Telstar client, and Richard Russell's telstar.bbc as bundled with BBCSDL is easily modified to connect to the service. EDIT: It's now listed out of the box in BBCSDL too.

Any comments regarding this server, as opposed to the TEEFAX service itself please use this thread rather than the existing Teefax thread.

Edited in 2022: Server has moved to teletext.matrixnetwork.co.uk:6502

[trixster]

Thanks for doing this, it’s brilliant

[Deleted User 9295]

My telstar.bbc client (as supplied with BBC BASIC for SDL 2.0) isn't behaving exactly as it should when displaying Teefax pages via your gateway. I think I've traced the cause to how you are handling double-height text; I would not have expected you to be sending anything in the second row of a double-height 'pair' (since the displayed contents are entirely dependent on what is in the first row of the pair) but it looks as if you are.

For example on the front page, in row 7 (which is the second row of the double-height "MATRIX NETWORK GATEWAY TO TEEFAX!") you seem to be sending the sequence 0x20 0x08 (space followed by cursor left). Of course this should have no visible effect, but because of the way my client works it can cause the row to 'glitch', especially on a slow machine.

I will try to work around it my end, since strictly my client is at fault, but I wonder whether you are sending something in the second row of the pair deliberately.

[Soruk]

My telstar.bbc client (as supplied with BBC BASIC for SDL 2.0) isn't behaving exactly as it should when displaying Teefax pages via your gateway. I think I've traced the cause to how you are handling double-height text; I would not have expected you to be sending anything in the second row of a double-height 'pair' (since the displayed contents are entirely dependent on what is in the first row of the pair) but it looks as if you are.

For example on the front page, in row 7 (which is the second row of the double-height "MATRIX NETWORK GATEWAY TO TEEFAX!") you seem to be sending the sequence 0x20 0x08 (space followed by cursor left). Of course this should have no visible effect, but because of the way my client works it can cause the row to 'glitch', especially on a slow machine.

I will try to work around it my end, since strictly my client is at fault, but I wonder whether you are sending something in the second row of the pair deliberately.

This stems from two things.

Firstly, the framebuffer is cleared to a single space character in each line (to compensate for the 0x08..). The lines' data are populated as found in the .tti files, which aren't necessarily in order. Once populated, the entire frame buffer is sent, including blank lines (with their space).

Secondly, to compensate for different behaviour I spotted a long while back between my client and yours where a row of 40 characters followed by a CR/LF caused in mine to insert a blank line where yours didn't when connected to Telstar - thus I implemented the "scroll protect" mode as found on the BBC Master and later machines into Matrix Brandy. But, I found another problem, shown in screenshots in the other thread that when assuming that behaviour, some other clients were putting blank lines in! So - to work around this, after every line is sent, a 0x08 is transmitted so that irrespective of the line-wrap mode it displayed correctly. I agree, it's a weird hack, but I'm not really sure how else to approach this.

I guess I could, if a line consists of a single space, just send 0x0D 0x0A, instead of 0x20 0x08 0x0D 0x0A.

[Deleted User 9295]

some other clients were putting blank lines in! So - to work around this, after every line is sent, a 0x08 is transmitted so that irrespective of the line-wrap mode it displayed correctly. I agree, it's a weird hack, but I'm not really sure how else to approach this.

Very cunning! I assume that there is a 'correct' way for a Videotex terminal to handle a full 40-character line followed by CRLF, and I admire you for being so considerate of those that don't conform. I couldn't find a specification online to confirm what that correct behaviour is however; do you know of one?

[Soruk]

Very cunning! I assume that there is a 'correct' way for a Videotex terminal to handle a full 40-character line followed by CRLF, and I admire you for being so considerate of those that don't conform. I couldn't find a specification online to confirm what that correct behaviour is however; do you know of one?

I don't, I just made my client from packet traces and having a reference for what it should look like when connecting to Telstar. My assumptions proved flawed when (initially) NXtel wouldn't render correctly. Really, I'm just making it up as I go along.

[Deleted User 9295]

Really, I'm just making it up as I go along.

In the absence of a formal specification I think it's reasonable to assume that the way CommSoft and the official BBC Micro Prestel System behave in this respect (which I trust is the same!) can be taken as a reference. Perhaps somebody with the appropriate hardware and ROM(s) can ascertain this.

[Soruk]

Really, I'm just making it up as I go along.

In the absence of a formal specification I think it's reasonable to assume that the way CommSoft and the official BBC Micro Prestel System behave in this respect (which I trust is the same!) can be taken as a reference. Perhaps somebody with the appropriate hardware and ROM(s) can ascertain this.

That would be useful indeed.

In the meantime, I've made the change to the server so if the line is blank (a single space) it just sends 0x0A instead.

[Deleted User 9295]

In the meantime, I've made the change to the server so if the line is blank (a single space) it just sends 0x0A instead.

That's excellent.

[Soruk]

HOLD page is now supported - press H, and jumping through a carousel is too - press .

REVEAL is client-dependent. On the Matrix Brandy client it's CTRL-R to toggle, on BBCSDL's telstar.bbc it's F1 to reveal, F2 to conceal.

[Deleted User 9295]

on BBCSDL's telstar.bbc it's F1 to reveal, F2 to conceal.

Can I take this opportunity to mention that telstar.bbc has recently been updated to include Teefax in the list of services, plus a couple of minor improvements.

[Soruk]

on BBCSDL's telstar.bbc it's F1 to reveal, F2 to conceal.

Can I take this opportunity to mention that telstar.bbc has recently been updated to include Teefax in the list of services, plus a couple of minor improvements.

Absolutely - it also gets a mention on P903.

[Deleted User 9295]

Absolutely - it also gets a mention on P903.

Thanks. Annoyingly, immediately after posting my comment I found another bug in telstar.bbc (the worst kind: statistical and intermittent). Now fixed in v0.23.

[tjewell]

Hi all. I've been having huge fun getting this working with an old Tandata Td1616 Prestel terminal. However, I do seem to be having problems with scrolling pages, as illustrated in the attached image. This isn't limited to Teefax, but also occurs on NXTel and CCL4 - however, this thread seemed a good place to find people who might be able to help me. (It does behave on Telstar)

As far as I can see, there's no option to turn off scrolling as an option on the Tandata. I'd not noticed the problem before as my old Dragon 64 client is too stupid to scroll anyway. I could add a hack to the softmodem that the Tandata is dialling into to possibly strip out new lines from the end of the page, but I'd like a better understanding of what the issues are first.

Many thanks in advance!

Oh and a picture of the terminal itself.

[Deleted User 9295]

I could add a hack to the softmodem that the Tandata is dialling into to possibly strip out new lines from the end of the page, but I'd like a better understanding of what the issues are first.

I'm not sure that this will be the slightest bit helpful to you, but in my telstar.bbc program I use VDU 23,16,1;0;0;0; to enable "scroll protection". Without that measure, the CRLF at the end of the last line can result in an unwanted scroll, which I'm assuming is what you're seeing on your terminal. I wonder if it has a similar capability that you could enable?

[Soruk]

Hi all. I've been having huge fun getting this working with an old Tandata Td1616 Prestel terminal. However, I do seem to be having problems with scrolling pages, as illustrated in the attached image. This isn't limited to Teefax, but also occurs on NXTel and CCL4 - however, this thread seemed a good place to find people who might be able to help me. (It does behave on Telstar)

As far as I can see, there's no option to turn off scrolling as an option on the Tandata. I'd not noticed the problem before as my old Dragon 64 client is too stupid to scroll anyway. I could add a hack to the softmodem that the Tandata is dialling into to possibly strip out new lines from the end of the page, but I'd like a better understanding of what the issues are first.

My Viewdata client (and it seems, also Richard Russell's) assumes once the cursor moves down from line 23 it returns to line 0. At the end of each line in the Teefax Teletext server I do VDU8,13,10 (backspace, carriage return, next line). This is to ensure proper rendering when a newline is requested after 40 characters have been written, that the client doesn't accidentally double-space. The BBC Master and later have an option called "Scroll Protect" (which my client uses in Brandy BASIC), so the cursor doesn't move to the next line automatically until another character is written, but my Teletext server doesn't require this feature to exist.

What I could do for the Teefax server is if Line 23 is being sent, instead of sending 8, 13, 10; to send 8, 13, 30 (HOME) instead. Whether it still mucks up if a character is written at the last character cell is to be seen....
Edit: Change made. Does it help?

[tjewell]

Edit: Change made. Does it help?

Thanks for making the change, but sadly no, it still scrolls up. Telstar does behave however, so I'm not sure what the difference is.

[Soruk]

Edit: Change made. Does it help?

Thanks for making the change, but sadly no, it still scrolls up. Telstar does behave however, so I'm not sure what the difference is.

Is it every page, or only certain pages on the Teefax server that go wrong like this?

[Deleted User 9295]

My Viewdata client (and it seems, also Richard Russell's) assumes once the cursor moves down from line 23 it returns to line 0.

Without seeing a copy of the official Prestel Terminal Specification (and I can't find one online anywhere) I don't know whether this is mandated or not. Indeed I didn't know that genuine Prestel Terminals ever scrolled, so the behaviour of this Tandata TD1616 is the first evidence I've seen that they do.

[tjewell]

Is it every page, or only certain pages on the Teefax server that go wrong like this?

As far as I can tell, it's every page. Also pages that carousel, like page 100, don't seem to give me enough time to enter a new page number before they refresh.

(btw, I really should have said at the start how great this service is - I'm really enjoying using it, even with the scrolling!)

[Soruk]

Is it every page, or only certain pages on the Teefax server that go wrong like this?

As far as I can tell, it's every page. Also pages that carousel, like page 100, don't seem to give me enough time to enter a new page number before they refresh.

(btw, I really should have said at the start how great this service is - I'm really enjoying using it, even with the scrolling!)

Another change, on the last line I now just send 8, 30 (backspace, home) - the CR (13) was rather pointless!

[tjewell]

Another change, on the last line I now just send 8, 30 (backspace, home) - the CR (13) was rather pointless!

Sorry to say it's still doing it! I've tested a few pages. Oh, just discovered the 'Hold' command, which makes it much easier to change pages when I'm on a carousel page.

[Soruk]

Another change, on the last line I now just send 8, 30 (backspace, home) - the CR (13) was rather pointless!

Sorry to say it's still doing it! I've tested a few pages. Oh, just discovered the 'Hold' command, which makes it much easier to change pages when I'm on a carousel page.

I'm not sure what to suggest then I don't have any hardware Viewdata kit, and the only software ones I've used (Richard's client and mine) have been written without any sight of the actual specification.

[Deleted User 9295]

Another change, on the last line I now just send 8, 30 (backspace, home) - the CR (13) was rather pointless!

Once you've removed the CR, isn't the backspace also rather pointless?!

If the bottom line is 'full' (40 characters long) I don't think there's any workaround available at the server end if the terminal chooses to scroll as soon as the last character is written, there has to be a capability in the terminal similar to the BBC Micro's 'scroll protect' to prevent that.

Really we need sight of the Prestel Terminal Specification. Evidently it has been available fairly recently, since Amazon has a listing; I've added it to my 'shopping list' so I should be notified if it's available from them again. I expect there are plenty of copies gathering dust on shelves, if only we knew where!

[tjewell]

Thanks for all your help Soruk! The only thing that puzzles me is that John Newcombe's Telstar service works just fine (although it's the only one that does). I've hacked my softmodem to dump out the stream of characters, see if I can work out what the difference is.

Does anyone have a good guide to what the special characters do? It's a very long time since I've done anything with teletext!

[Soruk]

Another change, on the last line I now just send 8, 30 (backspace, home) - the CR (13) was rather pointless!

Once you've removed the CR, isn't the backspace also rather pointless?!

Fair point! Now my server only sends HOME.

If the bottom line is 'full' (40 characters long) I don't think there's any workaround available at the server end if the terminal chooses to scroll as soon as the last character is written, there has to be a capability in the terminal similar to the BBC Micro's 'scroll protect' to prevent that.

An early bugfix I received from the BBC Micro email list from Gareth Babb (one of the CCl4 guys) was to screen-wrap, that is, once the cursor wants to move down from the bottom row to jump back to the top row - which is why I'm not getting the scrolling problems now.

Another change I've made, more to the numbering in the 9xx magazine, is that since these pages are only accessible via viewdata clients, to treat the entire number space as hexadecimal. (Yes, I know hex is valid in normal Teletext space but can't be dialled in via a remote control).

...and possibly the first Teletext advert since digital switchover on P998!

Thanks for all your help Soruk! The only thing that puzzles me is that John Newcombe's Telstar service works just fine (although it's the only one that does). I've hacked my softmodem to dump out the stream of characters, see if I can work out what the difference is.

Does anyone have a good guide to what the special characters do? It's a very long time since I've done anything with teletext!

For codes following ESC (0x1B), the code to be displayed is 128+(char MOD 32).
129-135 are text mode colours in BBC Micro MODE 2 order, 145-151 are graphics-mode colours in the same order. 136 is Flash On, 137 os Flash Off, 140 is Double Height Off, 141 is Double Height On. There are some others too affecting the way graphics are handled.

[Deleted User 9295]

Does anyone have a good guide to what the special characters do? It's a very long time since I've done anything with teletext!

The videotex (teletext/prestel) control characters are the same as used in MODE 7, of course (barring subtleties around the way double-height, conceal/reveal and start/end box behave), so any BBC BASIC reference is likely to include them. For example you can find them in the BBC BASIC for Windows manual. The Broadcast Teletext Specification is also available online.

[Deleted User 9295]

An early bugfix I received from the BBC Micro email list from Gareth Babb (one of the CCl4 guys) was to screen-wrap, that is, once the cursor wants to move down from the bottom row to jump back to the top row - which is why I'm not getting the scrolling problems now.

Yes, I know, I do the same, but that's a fix only available at the terminal (client) end, not the server end. It's one reason why I concluded that 'official' Prestel terminals probably don't scroll, but the Tandata example here appears to disprove that.

[Soruk]

An early bugfix I received from the BBC Micro email list from Gareth Babb (one of the CCl4 guys) was to screen-wrap, that is, once the cursor wants to move down from the bottom row to jump back to the top row - which is why I'm not getting the scrolling problems now.

Yes, I know, I do the same, but that's a fix only available at the terminal (client) end, not the server end. It's one reason why I concluded that 'official' Prestel terminals probably don't scroll, but the Tandata example here appears to disprove that.

I wonder if it's a case of the bottom line being a "use with caution" one... a particularly horrible hack, I guess would be to just not send the 40th character of the bottom row (taking into account the number of ESC characters...)

[Deleted User 9295]

I wonder if it's a case of the bottom line being a "use with caution" one... a particularly horrible hack, I guess would be to just not send the 40th character of the bottom row (taking into account the number of ESC characters...)

Well, personally, I'm certain you shouldn't be hacking your server to fix a problem in one particular client, which might not be working for a completely different reason. Your server should be doing exactly what the original Prestel servers did, back in the day; the trouble is we don't know for sure what that is! It seems to me highly unlikely that Prestel was designed so that the last character in the bottom row can't be used.