6847t1 Font Mystery

[hoglet]

Hi all,

There are two versions of the 6847:
- the original version with an internal character ROM of 64 characters
- the "t1" version with an internal character ROM of 96 characters, which adds lower case, and tweaks many of the other characters

For several years now, the AtomGODILVideo adapter and AtomFPGA have supported both fonts, and the font can even be switched at runtime. The Atom Software Archive splash screen is also rendered using the 6847t1 font.

But I'm now starting to suspect that I have been using the wrong font for the 6847t1

Very few real machines include a 6847t1 - I think only later models of the Tandy CoCo 2 - and there seems to be conflicting evidence of what the font looks like.

The datasheet contains a version:

link

Which rather looks like this (apart from one pixel in G):

link

But MAME contains a somewhat different font, which *might* come from the CoCo 3 (which is a custom chip rather than a 6847t1).

There are several different characters: @ G J # $ ' , . 3 6 9 : ; g j p q t y

And confusingly, this blog talks in detail about the differences:
https://damieng.com/blog/2016/08/09/typ ... ixels-more

But it's using a cropped version of an image I think that's come from MESS, the predecessor of MAME:
https://en.wikipedia.org/wiki/TRS-80_Co ... vdg_lc.png

It's the MAME one I think that I used in AtomGODILVideo.

I really want to understand what the 6847t1 actually produces.

I've scoured the internet for a photo of an actual CoCo2 screen. This is the best I found:

This supports the theory that the data sheet font is correct.

Does anyone have a machine with a real 6847t1 and would be willing to take some better photos?

Can anyone help solve this mystery in any other way?

Dave

[hoglet]

One more data point... Here's a CoCo3 via a RGBtoHDMI:

https://www.youtube.com/watch?v=pJgq_Wc5DgI&t=2383s

The CoCo3 does not have a real 6847, it has a custom chip (the ACVC) with an internal character generator ROM.

[BeebMaster]

My current Atom pictures aren't good enough to show the 6847 in detail, but some of the screens might be OK to identify the font:

http://www.beebmaster.co.uk/Atom/Atoms.html

How do I tell the difference between the two chips, is it clearly marked which is which?

I think I have some new-old-stock 6847 which I bought about 15 years ago.

[BeebMaster]

Mmm, another mystery, I can't find them. I don't even have a record of ever having any, they are on my still-searching list last updated 12th April 2004, although that isn't conclusive as I did subsequently find a source of certain parts on that list.

I'm sure I had a least one, I remember the gold package. Maybe I had to put it in an Atom, but I would have kept the old one, I never throw anything away like that.

[hoglet]

My current Atom pictures aren't good enough to show the 6847 in detail, but some of the screens might be OK to identify the font:

All Atoms were manufactured with the original MC6847, and we have that font captured unambiguously.

It's only the MC6847T1 where there is this uncertainty/confusion.

Of couue, it's always possible someone has fitted a T1 as an after-market "upgrade" to an Atom but I've never seen that in practice.

Dave

[Pernod]

It looks like MAME implements multiple fonts depending on type of 6847 (PALS, NTSC, T1, etc.), as to whether they are correct I wouldn't know. The CoCo and Dragon communities do use MAME, and would've expected some comment from them if there are issues.

[hoglet]

This page contains some another useful data point:
http://amxprojects.com/?p=2387

The character set matches the data sheet:

The VDG is a XC80652P:

The XC80652P is a pre-production/pilot-production version of the 6847T1. It's commonly seen in the later CoCo2 models.

Dave

[hoglet]

It looks like MAME implements multiple fonts depending on type of 6847 (PALS, NTSC, T1, etc.), as to whether they are correct I wouldn't know. The CoCo and Dragon communities do use MAME, and would've expected some comment from them if there are issues.

Sorry for the mega long response. I need to document this so I don't get confused again in the future.

MAME defines five 6847 fonts (in mc6847.cpp) used by various MAME video devices:
- ntsc_square_fontdata8x12 (used by MC6847_NTSC, MC6847Y_NTSC)
- pal_square_fontdata8x12 (used by MC6847_PAL, MC6847Y_PAL)
- ntsc_round_fontdata8x12 (MC6847T1_NTSC, GIME_NTSC)
- pal_round_fontdata8x12 (used by MC6847T1_PAL, GIME_PAL)
- s68047_fontdata8x12 (used by S68047)

The original 6847

The "square" varients are for the original 6847 with a square capital O, and are quite widely used in MAME:

The following use MC6847_NTSC:

Code: Select all

src/mame/drivers/dragon.cpp:	MC6847_NTSC(config.replace(), m_vdg, 14.318181_MHz_XTAL / 4);
src/mame/drivers/mc1000.cpp:	MC6847_NTSC(config, m_vdg, XTAL(3'579'545));
src/mame/drivers/spc1000.cpp:	MC6847_NTSC(config, m_vdg, XTAL(3'579'545));
src/mame/drivers/uchroma68.cpp:	MC6847_NTSC(config, m_mc6847, XTAL_UCHROMA68);
src/mame/drivers/coco12.cpp:	MC6847_NTSC(config, m_vdg, XTAL(14'318'181) / 4); // VClk output from MC6883
src/mame/drivers/shine.cpp:	MC6847_NTSC(config, m_vdg, 3.579545_MHz_XTAL); // or really PAL?
src/mame/drivers/apf.cpp:	MC6847_NTSC(config, m_crtc, 3.579545_MHz_XTAL);
src/mame/drivers/mc10.cpp:	mc6847_ntsc_device &vdg(MC6847_NTSC(config, "mc6847", XTAL(3'579'545)));
src/mame/drivers/phc25.cpp:	MC6847_NTSC(config, m_vdg, XTAL(3'579'545));

The following use MC6847_PAL:

Code: Select all

src/mame/drivers/dragon.cpp:	MC6847_PAL(config, m_vdg, 4.433619_MHz_XTAL);
src/mame/drivers/z80ne.cpp:	MC6847_PAL(config, m_vdg, 4.433619_MHz_XTAL);
src/mame/drivers/z80ne.cpp:	MC6847_PAL(config, m_vdg, 4.433619_MHz_XTAL);
src/mame/drivers/z80ne.cpp:	MC6847_PAL(config, m_vdg, 4.433619_MHz_XTAL);
src/mame/drivers/atom.cpp:	MC6847_PAL(config, m_vdg, XTAL(4'433'619));
src/mame/drivers/phc25.cpp:	MC6847_PAL(config, m_vdg, XTAL(4'433'619));
src/mame/drivers/vtech1.cpp:	MC6847_PAL(config, m_crtc, XTAL(4'433'619));

The PAL and the NTSC versions fonts differ in just three characters:

The E character:

Code: Select all

PAL  0x00, 0x00, 0x00, 0x3E, 0x20, 0x20, 0x3C, 0x20, 0x20, 0x3E, 0x00, 0x00,
NTSC 0x00, 0x00, 0x00, 0x3E, 0x20, 0x20, 0x38, 0x20, 0x20, 0x3E, 0x00, 0x00,

PAL:        NTSC:
..*****.    ..*****.
..*.....    ..*.....
..*.....    ..*.....
..***...    ..**....
..*.....    ..*.....
..*.....    ..*.....
..*****.    ..*****.

The F character:

Code: Select all

PAL  0x00, 0x00, 0x00, 0x3E, 0x20, 0x20, 0x3C, 0x20, 0x20, 0x20, 0x00, 0x00,
NTSC 0x00, 0x00, 0x00, 0x3E, 0x20, 0x20, 0x38, 0x20, 0x20, 0x20, 0x00, 0x00,

PAL:        NTSC:
..*****.    ..*****.
..*.....    ..*.....
..*.....    ..*.....
..***...    ..**....
..*.....    ..*.....
..*.....    ..*.....
..*.....    ..*.....

The 3 character:

Code: Select all

PAL 0x00, 0x00, 0x00, 0x1C, 0x22, 0x02, 0x0C, 0x02, 0x22, 0x1C, 0x00, 0x00,
NTSC 0x00, 0x00, 0x00, 0x1C, 0x22, 0x02, 0x04, 0x02, 0x22, 0x1C, 0x00, 0x00,

PAL:        NTSC:
...***..    ...***..
..*...*.    ..*...*.
......*.    ......*.
....**..    ....*...
......*.    ......*.
..*...*.    ..*...*.
...***..    ...***..

In each of these cases, the PAL varient is correct, which happens to be the version the MAME Atom model uses (why, I have no idea). As far as I know, all there isn't a PAL version of the 6847, so I would have expected the two fonts to be identical.

The 6847T1 (and GIME)

The "round" varients are for the 6847T1 with a rounded capital O, and for the CoCo3 GIME VDC.

The following use MC6847T1_NTSC:

Code: Select all

src/mame/drivers/coco12.cpp:	MC6847T1_NTSC(config.replace(), m_vdg, XTAL(14'318'181) / 4);

The following use MC6847T1_PAL:

Code: Select all

...nothing...

The following use GIME_NTSC:

Code: Select all

src/mame/drivers/coco3.cpp:	GIME_NTSC(config, m_gime, XTAL(28'636'363), MAINCPU_TAG, RAM_TAG, CARTRIDGE_TAG, MAINCPU_TAG);

The following use GIME_PAL:

Code: Select all

src/mame/drivers/coco3.cpp:	GIME_PAL(config.replace(), m_gime, XTAL(28'475'000), MAINCPU_TAG, RAM_TAG, CARTRIDGE_TAG, MAINCPU_TAG);

The problem here is that the actual MC6847T1 and GIME fonts are very different. The "round" fonts in MAME match the GIME font. Which means they are wrong for the MC6847T1. This only affects MAME's emulation of the later versions of Coco 2, as this is the only thing that uses MC6847T1.

I expect this hasn't been noticed because most CoCo 2 machines were fitted with the original 6847, and this is likely what people use.

The "round" PAL and NTSC fonts differ only in character 0x40 (the first character in the lower case set):

Code: Select all

PAL  0x00, 0x00, 0x18, 0x24, 0x20, 0x70, 0x20, 0x24, 0x78, 0x00, 0x00, 0x00,
NTSC 0x00, 0x00, 0x10, 0x28, 0x44, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,

PAL:        NTSC:
...**...    ...*....
..*..*..    ..*.*...
..*.....    .*...*..
.***....    ........
..*.....    ........
..*..*..    .......
.****...    ........

I've been doing all this digging because I want to use accurate fonts in the Pico Atom VGA firmware. Based on this, I'll add three fonts:
- CHARSET0: the 6847 font as defined in MAME: (pal_square_fontdata8x12)
- CHARSET1: the 6847T1 font as defined in the MC6847T1 datasheet
- CHARSET2: the GIME font as fefined in MAME: (ntsc_round_fontdata8x12)

Dave

[oss003]

Dave, I found this about the Coco 1,2 and 3.
Maybe it helps with the fonts.

BTW the Coco also has Semi Graphics 8 (4x3), 12 (4x2) and 24 (4x1) modes .....
These aren't standard 6847 modes are they?

Greetings
Kees

[Prime]

My current Atom pictures aren't good enough to show the 6847 in detail, but some of the screens might be OK to identify the font:

How do I tell the difference between the two chips, is it clearly marked which is which?

The 6847 in the Atom will be the original version. The T1 version has an internal latch on the databus, which is driven by external circuitry in the CoCo2, specifically the SAM, this illiminated the need for an external LS latch. It might be possible to fit one in an Atom, but you would need external driver circuitry which the Atom does not have.

Cheers.

Phill.

[Prime]

Dave, I found this about the Coco 1,2 and 3.
Maybe it helps with the fonts.

BTW the Coco also has Semi Graphics 8 (4x3), 12 (4x2) and 24 (4x1) modes .....
These aren't standard 6847 modes are they?

No, not standard modes.
In the Dragon and CoCo, there is a 'memory controller' called the SAM (synchronous address multiplexor) which manages the DRAM and interleaves
CPU and VDG access. In a SAM based system, the SAM generates the video addresses that are used to fetch video data from the RAM, this is why only DA0 is connected to anything, as it's used to sync up the SAM with the VDG. To do this however the SAM has to be told what video mode is in use.
Obviously in text mode it will scan the first 32 bytes of video RAM for the first 12 (0-11) scan lines** and then the next 32 for 12-23 etc. In graphics mode it will generally scan a group of bytes for each scanline.

The extra SG modes are implemented by programming the VDG for a semi mode and programming the SAM for a graphics mode. This means that bytes are not repeatedly scanned by the SAM but the VDG interprets them as if they where text/semi data. Also allows you to have some 'psudo' custom characters.

**Really 'pixel lines'

Cheers.

Phill.

[robcfg]

This is quite interesting, as there are no PAL and NTSC versions of the 6847 as far as i know.

I just received some nice pictures from decapping a 6847 from a CoCo2, which happened to be not working.

Here you have the font array, with the font dots marked in white.

The font is actually 5x7 and each character is stored as a column in the image.

The result is also attached as a png file.

We'd need to find a XC and a T1 and decap them to finally get all fonts correctly.

[allenhuffman]

This is quite interesting, as there are no PAL and NTSC versions of the 6847 as far as i know.

I just received some nice pictures from decapping a 6847 from a CoCo2, which happened to be not working.

Greetings. I found this thread while researching the T1 used in the CoCo. A few days ago I learned of some modes it added that I never knew about back in the 80s.

Where did these decapping images come from? I only learned of this process the other day, with some folks wanting to have the one to the Coco 3s GIME chip.

[robcfg]

Hi,

The decap was done by Sean Riddle, who usually dwells in the MAME forums.

I've asked him if he'd be able to do it. I'll come back to you when I get an answer.

Needless to say, you'd need to send a GIME chip to him, but the good thing is that it can be a non-functional one.

Cheers,
Rob

[robcfg]

Well, that was fast!

Sean is getting a 1986 and a 1987 GIME chips for decapping, so I guess we'll see the pictures in the near future.

If your chip is different, then it would be nice to send it to him so we can compare all GIME revisions.

Also, if you can keep the chip until we confirm that the decaps are good, it would be fantastic, as sometimes the dies can break and would need another chip to try.

Regarding the process, if I remember correctly, the chip is torched in order to melt the package and get to the die, and then it's put in hot acid to clean it as much as possible. Then the pictures are taken with a motorised microscope and stitched together with a software like Fiji.

Cheers,
Rob

[allenhuffman]

Sean is getting a 1986 and a 1987 GIME chips for decapping, so I guess we'll see the pictures in the near future.

If your chip is different, then it would be nice to send it to him so we can compare all GIME revisions.

How curious. Unless there are two people on the world trying to do this with a GIME at the moment, I suspect someone else I know is the one providing the GIME chips. "It’s a small world after all!"

We do have potential access to some early prototype GIME chips but I do not know if the possessor of them would want them sacrificed. But, there are several known to exist.

I have been experimenting with the T1 via the XROAR emulator lately, and it may be doing a few things wrong in regards to the alternate color mode, but the author is checking against real hardware. I only knew about lowercase in the chip, and was unaware of the other text mode capabilities.

I just read up on the Acorn. I was aware of the BBC Micro but did not know about the earlier Acorn using the VDG.

[robcfg]

Hi Allen,

How curious. Unless there are two people on the world trying to do this with a GIME at the moment, I suspect someone else I know is the one providing the GIME chips. "It’s a small world after all!"

Could this person you know be some Roger Taylor by any chance? http://www.cococommunity.net/mystery-256-color-mode/

We do have potential access to some early prototype GIME chips but I do not know if the possessor of them would want them sacrificed. But, there are several known to exist.

It would be nice if we could get our hands on one of those for decapping, just to be able to study it, but as you say, it's hard to destroy the chip for that.

I have been experimenting with the T1 via the XROAR emulator lately, and it may be doing a few things wrong in regards to the alternate color mode, but the author is checking against real hardware. I only knew about lowercase in the chip, and was unaware of the other text mode capabilities.

Ciaran Anscomb is the one behind XRoar, and I can tell you that he's a super nice guy, very open to constructive feedback. You can get in touch with him at his web site https://www.6809.org.uk/ciaran/ or at the Dragon Archive forums https://archive.worldofdragon.org/phpBB3

Right now he's working on the latest release of XRoar and it's adjusting the T1 emulation, so I think it's the perfect time to jump in.

If you register at the Dragon Archive, drop me a line and I'll ask them to expedite your account validation.

Cheers,
Rob

[scruss]

I know this thread's already gone to hardware places few others would go, but if you need the fonts compared on actual hardware, forum user waltermixx has Atoms and multiple CoCo models on his bench.

[allenhuffman]

Ciaran Anscomb is the one behind XRoar, and I can tell you that he's a super nice guy, very open to constructive feedback. You can get in touch with him at his web site https://www.6809.org.uk/ciaran/ or at the Dragon Archive forums https://archive.worldofdragon.org/phpBB3

Right now he's working on the latest release of XRoar and it's adjusting the T1 emulation, so I think it's the perfect time to jump in.

Looks like I have registered there before, so I’ll have to start browsing — see you around!

[allenhuffman]

Did anyone ever produce a lower case upgrade for the Acorn? I had one for my TRS-80 Color Computer. It was a board that plugged in to the VDG socket, then the VDG plugged in on top of it. It provided a crappy font with lowercase.

[IanB]

There are two versions of the 6847:
- the original version with an internal character ROM of 64 characters
- the "t1" version with an internal character ROM of 96 characters, which adds lower case, and tweaks many of the other characters

I recently picked up a PAL Tandy colour computer 2 and that has an XC80652P which as mentioned above is actually a 6847T1

Here are a couple of RGBtoHDMI screencaps

There are many character differences # % ' ( ) * , . / 0 4 9 ; ? @ N O S W [ / ] plus the font is at the top of each character cell rather than the bottom presumably to support lower case and it doesn't have two different orange levels for text and graphics:

(I tried adjusting the Y thresholds)

Here is a normal 6847 for comparison. If you flip between this and the above T1 capture you can see the character shift:

[allenhuffman]

Tim Lindner has a great article about the font differences…

http://tlindner.macmess.org/?p=913

[B3_B3_B3]

1) Leaving out lower case in the earlier 6847s seemed a curious omission, surely lower case is important...? Did it not fit?


2) Why are the 2 and especially the 4 colour mode colour set choices so strange imo (colour on a green background?) Was it for woz ntsc style artifact colour?



3) Has anyone fitted the Tandy CoCo3's 6847 'descendent', the Gime (Graphics Interrupt Memory Enhancer)/Advanced Color Video Chip (ACVC)  ic to their atom?
https://www.cocopedia.com/wiki/index.php/GIME

https://en.m.wikipedia.org/wiki/TRS-80_Color_Computer

[sixxie]

Just thought I'd chime in that there's yet another variant seemingly in existence. The Tandy Deluxe Colour Computer was apparently going to use the T1. But a working recovered prototype appears to have a chip halfway between the two.

Labelled "SC80651P" as well as "MC6847P", it has lowercase on board, but the older "square O's" uppercase font, as far as we can tell.

We don't yet know whether it does any of the other T1 stuff like border control, or if it has the extra latch on board / burst timing outputs. It might get some attention at the next CoCoFEST in May.

Edit: whoops, been pointed out to me I tyoped there. It really is marked MC6847P like a normal VDG, not MC6846P which would be something else entirely.