Here are some pictures of the outside and the inside of a Commodore Bildschirmtext II Decoder Cartridge for the C64 – a 6800-based computer connected to the expansion port!
Bildschirmtext (Btx) was a German online service that existed from 1983 to 2001. Here are some videos of what it looked like.
To use the service with a C64, this decoder cartridge was required, which connected to the expansion port.
The cartridge is actually a Siemens product, it’s just Commodore-branded. The sticker says:
- SIEMENS
- Universal Btx Decoder
- S30817-S721-B101-7/02 EX/W8
- A30817-X732-B100-4-11
- Commodore Artikel Nr. 606491
The box with the Deutsche Bundespost logo is the registration (A506 131V). At the time, only explicitly Post-approved devices and software were allowed to be used for participating in Bildschirmtext.
(This is the “Btx Decoder Modul II”, even though the cartridge doesn’t say so. There was a completely different first model.)
There are three DIN ports at the back, from left to right:
* Modem: This connects to the proprietary Deutsche Bundespost “DBT-03” modem (1200 baud down, 75 baud up).
* RGB: This is for connecting an analog RGB monitor.
* FBAS: This port is identical to the C64 video port and allows using a C64 monitor.
The Post-approval for participating in Bildschirmtext required the decoder to be able to show a pixel-exact image of the service (480×240 pixels with 32 out of 4096 colors)1. Since the VIC-II in the C64 could not meet this, the decoder cartridge had its own video controller and therefore its own video ports.
This is the output of the cartridge on startup. Note the different font, with 12×10 pixel characters. (The VIC-II is still active and shows a message that the user should connect the video cable to the cartridge instead.)
The board reveals that the cartridge doesn’t only have its own video chip, it also has its own CPU, RAM and ROM – it’s a complete computer that only connects to the C64 in order to reuse the keyboard and the disk drive.
These are the major chips:
* Motorola MC6803: a 6800-family microcontroller
* Motorola MC68HC34: Dual-Port Memory Unit
* 64 KB RAM (two 41464 64Kx4 DRAM)
* 32 KB EPROM
* D65040GF206: NEC µPD65000 series CMOS gate array
The hardware hasn’t been analyzed much. The communication with the modem, the decoding of the CEPT data stream and the interaction with the Btx service are handled by 6800 CPU and the software in the EPROM.
I am assuming the software writes the RGB values of every single scanline into the dual-port memory in real-time, which the gate array then reads to generate the video signal – like on the Atari VCS and the Sinclair ZX81. This keeps the complexity of the video hardware minimal.
The chipset and the firmware are probably very similar to the technology used in dedicated Bildschirmtext terminals.
References
-
A hardware decoder was only required until 1990, when Deutsche Bundespost was finally convinced to allow software decoders. It was then enough if the pixel-exact image could be printed to paper, which was met as long as the decoder software included a 24-pin (black and white) printer driver.↩
The 6800 bus has the same cycle structure as the 6502 (as the 6502 borrows that from the 6800). Thus at least in theory the gate array could contain counters that control the address bus on the “half cycle” where the CPU doesen’t control the bus, much like the VIC chip does, and thus video could be generated in hardware.
What clock speed is the 6803 rated at, and what would the minimum for generating the video signal be?
Btw the case seems like the same, more or less, that the REU uses, except of course the holes for the DIN connectors and the labels.
It’s strange that there is no pass-through for the video cables.
The dual port memory unit is marked as XC68HC34. As I recall, the XC prefix indicates the chip is a preproduction engineering sample.
It would be interresting to compare the ROM of that board with the one in the Siemens BTX terminals.
I do have the ROM of 2 different Loewe terminals and those seem to have been written in some high level language as it seems like the registers were re-assigned. The Loewe terminals were based on 8032 or something.
What is noteworthy is that they used a Japaneese chip for the display. It could be that this is a terminal designed for Captain.
Ahh sorry, a gate array would of course also make sense. There were dedicated chips available late in the BTX development which would cut cost. Since BTX is moderately complex, my guess is that this gate array could house a full text-mode display. After all it’s nothing more than reading 4+ bytes from the character position, then reading 2 bytes from the character memory, and shifting it out, switching between foreground and background colour, essentially just like any other “modern” text mode console works.
Having the CPU writing every line as RGB values into RAM would be very hard as the pixel clock of BTX typically is 12 MHz.
@Christian Berger
The original LOEWE BTX decoder was in fact based on a version of the 8051 – in fact, my predecessor here at Coburg University, Prof. Hilmar Missbach, was the lead developer of the first BTX decoder at LOEWE in the 1980s, see
https://www.spiegel.de/spiegel/print/d-14019866.html
I can try to find out more details of that decoder if you’re interested…
Yes!
The 8032 is iirc an 8031 with some differences, while the difference between 8031 and 8051 is that one of them has internal mask programmed ROM and the other one requuires an external ROM (which uses up a bunch of pins that could otherwise be used as GPIO). So the 8051 and 8032 is just different members of the same microcontroller family.
Btw what was so special about Bildschirmtext that made it require this special video hardware? As an example, in Sweden we had “Datavision” (and perhaps some other smaller services) which used the same video specifications as teletext. That was great as a C64 can display that. As it didn’t scroll and as data were recieved at 1200bps the C64 could keep up with the dispaly in hires mode, which made stuff like freely selectable background for each char and double height chars possible. Thus the hardware for “Datavision” were just a cartridge containing a ROM (which could be pirated onto a floppy disk and started with pressing reset or a SYS command) and a modem capable of both 300/300 (originate and answer) and 75/1200 (only originate) using an AMD “Worldchip” modem-on-a-chip IC and the regular discrete things and glue logic that is needed, which were connected to the user port. You had to use a regular telephone to dial the database and when you heard the modem answer tone you’d push the “data” button on the modem, keep it pressed for a while, and hope that the LED would not turn off when you released the “data” button. Then put the phones handset on hook again. The modem did disconnect automatically if the answering modem did drop the line though, so it didn’t hang on to the line if the connection were disrupted. You could of course also use any RS232 interface for a C64 and any other modem that did raw 75/1200 on RS232. There were also some modems that only did 75/1200 but those weren’t as popular. I think there were no formal requirements to use an approved terminal, although the modem itself had to be approved for connection to the public telephone network.
If the Bildschirmtext did some hires stuff I can understand why it needed special hardware. But from what I saw on those gif animations in a previous post, it seems like regular teletext hardware would had been good enough. In some cases any 40*24 capable display might even had been good enough although it would had been boring without the block graphics and color.
“Btw what was so special about Bildschirmtext that made it require this special video hardware?”
Well originally Bildschirmtext was meant to work with the same hardware as teletext. In fact one idea was to have the (back then) expensive video hardware (1kbyte of RAM + character generator) double for both Teletext and Bildschirmtext. That old standard used during the pilot phase was later named “Prestel”.
However after the pilot phase, the postal company decided to go big and add just about any feature you could wish for in text modes. They wanted many standard glyphs (I think something like 1024) in high resolution and attributes on every character position as well as full row attributes. Instead of 8 colour codes you’d have 32 out of a palette of 4096. Of course it also had user definable characters in several bit depths and sizes… and multiple blink modes. All of that was in the “new” “future proof” standard “CEPT”.
In a way, if Bildschirmtext would have been successful, Germany would have had a rather decent foot in the home computer industry. After all the graphic capabilities of a Bildschirmtext terminal were rather advanced for the time. Austria did build a home computer, the MUPID around that. It’s no wonder talking and self-driving cars were fairly normal in the late 1980s.
BTW, since the character cells were 12×10 instead of 8×8, the 40×25 display actually required 480×250 pixels… somewhat more than what the C64 could display. Also colours wouldn’t change on 8 pixel boundaries and so son. Yes, there were pure software decoders available, but those wouldn’t be legal (until rules were changed so a printout was OK).
There is, BTW a project going on at https://github.com/bildschirmtext/ to make the decoder and the central available.
I have made 2 photographs of the Siemens MultiKom-S1 board here:
http://casandro.dyndns.org/btx/MultiKom-S1/
BTW the MultiKom-S1 is clocked at 28,8MHz because it outputs video at 625 lines 60Hz to conform to the “flicker free” requirements for TV monitors. It even has a special 60 Hz video output. It uses standard AT-Keyboards, BTW.
The Loewe designs did essentially the same, even on the TV sets.
BTW the Loewe design also is special for having at least 2 microcontrollers, one for the decoder, one for the keyboard. Even on all-in-one devices those are separated by optocouplers.
The directory posted above now also contains the ROM dump of a Siemens Terminal. It’s 128kBytes in size, but my reader read that twice.
From what I can tell, starting at $4000 there’s a 6×10 character set which is probably used for the 80 column mode. Starting at $6000 there’s the 12×10 character set with each scanline using up 2 octets with a total of 768 glyphs.
I wonder if that can also be found in the C64 decoder.
BTW the manual of this cartridge actually lists some locations to be called to do several things. It can, apparently, also display a limited version of those pages via the C64.
It seems like this could actually even be used to have an additional 80 column mode. The ROM certainly has both the 40 and the 80 column fonts.
The manual is here, BTW:
https://archive.org/details/commodorebtxdecoderii/mode/2up
It does have an ASCII-Mode where it defaults to 80 columns.
Here is a little demo of it:
https://www.youtube.com/watch?v=53-Yar-enZA&feature=youtu.be