Dragon 200E Lower Case Daughterboard ROM question

[Go4Retro]

I've been working on archiving the font ROM images for the "lowerkit" CoCo lowercase mod, and completed my archival work:

https://www.go4retro.com/2024/10/31/exp ... ing-fonts/

And, I ran across DragonPlus' Dragon 200E Lower Case Daughterboard, with a download of the font data. I thought I'd quickly chop up the 64kB master font file into the specific individual fonts, but I quickly noticed the font data is stored in a completely different way. the first byte of the first font bitmap is at memory location 0, second at 256, etc.

From that, it appears the lower 8 bits of the EPROM address are tied to the memory bus 8 data lines, and the 4 counter lines from the 6847/74LS161 combo are tied to the upper 4 bits. But, when I look at Dragon lowercase mod monitor pics of the 256 characters in the charset, the first 128 chars are the font, and the second are the SG chars, like on the CoCo. Still, if I chop the font file up into 2kB chunks, the data does not line up.

I don't see a schematic of the Dragon200E PCB anywhere, and I don't own a DragonPlus PCB, but does anyone know if the design uses address line 8 on some switch, or similar, or are the second 2kB fonts of every 4kB font set just not usable by the PCB?

My current extraction of the fonts is here:

https://github.com/go4retro/dragonplus- ... n/charsets

And, the various fonts are here:

https://github.com/go4retro/dragonplus- ... ets/fixrom

while the (admittedly quick and dirty) font SVG images are here:

https://github.com/go4retro/dragonplus- ... ts/drawsvg





















If you look, you can see several are duplicates. COmputing md5sum over the files and sorting shows this:

Code: Select all

17185b9f8da2250493744fca41cdf87d *DragonFont14.0.bin
1d31066c487dac3a8f16925dd188e8da *DragonFont08.0.bin
20d0524d7fd26b52740314b32c0a88fc *DragonFont00.1.bin
2336904a8d455017bc867c4eff24cc1e *DragonFont03.1.bin
34c3500dc9a7327388e880a565ccee81 *DragonFont06.0.bin
3ac2bec18a4f8f4dda2c62091dce3da9 *DragonFont14.1.bin
3cec63a172d295910872955dbf127ccb *DragonFont13.0.bin
42f9b08eeb0adb72ce49c2ade75e2a44 *DragonFont06.1.bin
43b36a36cb20d4c8954e28666fa4b95e *DragonFont10.0.bin
444d540154e6c4c906821aa9de8ce437 *DragonFont04.1.bin
444d540154e6c4c906821aa9de8ce437 *DragonFont05.0.bin
54f6e2a085bf68e5513a88b266e566c5 *DragonFont13.1.bin
5b750ae82070de32848a897582325797 *DragonFont11.0.bin
616aa57c6ea6bab087cdecce7ff9240a *DragonFont05.1.bin
7254672fccfe68c050a9d9bbb8a39b4b *DragonFont09.1.bin
7254672fccfe68c050a9d9bbb8a39b4b *DragonFont10.1.bin
72ba52fc18a3f8813ac7b4614c668ee2 *DragonFont03.0.bin
74bda0da8238a474da2dd816179c1fb6 *DragonFont12.0.bin
90fe876cac9c7b83949ae673beb7493e *DragonFont00.0.bin
9c417687702ce732486306317cf07eff *DragonFont07.1.bin
9d4a3610a163613da980e99b87e1817b *DragonFont02.0.bin
a68f741e81806d24cd1a29ca9ce3c63d *DragonFont09.0.bin
b5a69e93ad7ee7c401d29e636fac84cb *DragonFont11.1.bin
c6b82af674b853a4bdfeb3621433932a *DragonFont04.0.bin
d314b341e7c5480712d5127329bac015 *DragonFont07.0.bin
d9aea692a4c34e225af568ac26ed0656 *DragonFont01.1.bin
d9aea692a4c34e225af568ac26ed0656 *DragonFont02.1.bin
e910e7ce125816a4fbf64fb0023bc421 *DragonFont15.0.bin
e93fddadd6500e19edb5a4d6576799de *DragonFont01.0.bin
fbd52ccec720de9ac27af93d02117df1 *DragonFont08.1.bin
fbd52ccec720de9ac27af93d02117df1 *DragonFont12.1.bin
ff4d2778fad8bc8ede94870353e6ab80 *DragonFont15.1.bin

Just trying to sort out if I am parsing the file wrong, or what.

Jim

[robcfg]

Hi Jim,

You can see the original Dragon 200E daughterboard here: https://archive.worldofdragon.org/index ... ragon_200E

Here you can see also how the data is organized in the internal rom of the MC6847: https://en.wikipedia.org/wiki/Motorola_ ... _generator

Hope this helps!

[Go4Retro]

Thanks, I already saw those pictures, but thy don't provide enough detail on how the data lines of the 6847 socket are mapped to the EPROM address line.

The internal 6847 font doesn't really help, because it's a "synthetic" font. The ROM stores a 5x7 representation of the font glyph, and then pads the 5x7 to 8x12 during render, to save die memory. But, I do understand how the 6847 external ROM is accessed, as it's explained in the datasheet:

https://www.go4retro.com/2024/10/29/how ... -you-go-2/

The unknown is that the 6847 external EPROM usage asks that you take the 4 bit output of the counter connected to the 6847 and the 8 bits of the data lines normally going to the 6847, but it does not stipulate how you connect those to an EPROM/FLASH ROM.

on the CoCo lowerkit product, and reproductions, the counter outputs are connected to the lowest 4 bits of the EPROM address, meaning a font bitmap would be organized as a contiguous set of 16 bytes in memory, with each character residing in memory locations <character code>*16 - <character_code*16+15. But, on the Dragon 200E board, they appear to be organized as <character code>+0*256,<character code>+1*256,...<character code>+15*256. That fine (if a bit hard to create fonts in...), but when I use that algorithm on 256*16 = 4096 bytes of the Dragon220E font rom on DragonPlus' web site, I see two different 128 glyph character sets, not a 256 byte single character set.

That would imply the upper 4 bits are the counter output, and the lower 7 bits are the data from the video memory (the 6847 socket data lines), but bit 7 of the EPROM address either is connected to something else, or you just can't access those font glyphs (because, when bit 7 is high, it looks like the Dragon switches to "graphics" mode via the 6847 A/G line, and character glyph 128-255 are rendered as semigraphics chars, not font data.

[Go4Retro]

I thought I'd reach out to DragonPlus directly, but their contact form is disabled.
JIm

[Alastair]

I thought I'd reach out to DragonPlus directly, but their contact form is disabled.
JIm

Hello Jim, if John (of DragonPlus Electronics) does not reply to this thread within the next few days you can PM him here under the username "dublevay" memberlist.php?mode=viewprofile&u=7991

[Go4Retro]

I'm still not for certain, but it looks like the !INT/EXT line on the 6847 socket is used to select which of the 2kB banks in a 4kB ROM set you use. If so, that helps explain why the font sets are 4kB in size.

Does anyone have a dump of the original EPROM or a link to it? That would assist in understanding the operation.

Jim

[robcfg]

We got you covered!
https://archive.worldofdragon.org/brows ... 5B!%5D.zip

[Go4Retro]

We got you covered!
https://archive.worldofdragon.org/brows ... 5B!%5D.zip

Thanks!

OK, all test point to the INV line being EPROM address line A7, which selects the upper or lower 128 chars in a 256 char set.

I find it interesting that there's non 0 data in the last 4*256 bytes of the ROM:

Code: Select all

Byte: 0000 00 '        '
Byte: 0100 18 '   **   '
Byte: 0200 18 '   **   '
Byte: 0300 10 '   *    '
Byte: 0400 08 '    *   '
Byte: 0500 00 '        '
Byte: 0600 00 '        '
Byte: 0700 00 '        '
Byte: 0800 00 '        '
Byte: 0900 00 '        '
Byte: 0A00 00 '        '
Byte: 0B00 00 '        '
Byte: 0C00 FF '********'
Byte: 0D00 FF '********'
Byte: 0E00 FF '********'
Byte: 0F00 FF '********'
Byte: 0001 00 '        '
Byte: 0101 00 '        '
Byte: 0201 00 '        '
Byte: 0301 00 '        '
Byte: 0401 00 '        '
Byte: 0501 0C '    **  '
Byte: 0601 02 '      * '
Byte: 0701 1E '   **** '
Byte: 0801 22 '  *   * '
Byte: 0901 1D '   *** *'
Byte: 0A01 00 '        '
Byte: 0B01 00 '        '
Byte: 0C01 FF '********'
Byte: 0D01 FF '********'
Byte: 0E01 FF '********'
Byte: 0F01 FF '********'
Byte: 0002 00 '        '
Byte: 0102 00 '        '
Byte: 0202 00 '        '
Byte: 0302 20 '  *     '
Byte: 0402 20 '  *     '
Byte: 0502 3C '  ****  '
Byte: 0602 22 '  *   * '
Byte: 0702 22 '  *   * '
Byte: 0802 22 '  *   * '
Byte: 0902 5C ' * ***  '
Byte: 0A02 00 '        '
Byte: 0B02 00 '        '
Byte: 0C02 FF '********'
Byte: 0D02 28 '  * *   '
Byte: 0E02 FF '********'
Byte: 0F02 FF '********'
Byte: 0003 00 '        '
Byte: 0103 00 '        '
Byte: 0203 00 '        '
Byte: 0303 00 '        '
Byte: 0403 00 '        '
Byte: 0503 1E '   **** '
Byte: 0603 20 '  *     '
Byte: 0703 20 '  *     '
Byte: 0803 20 '  *     '
Byte: 0903 1E '   **** '
Byte: 0A03 00 '        '
Byte: 0B03 00 '        '
Byte: 0C03 FF '********'
Byte: 0D03 43 ' *    **'
Byte: 0E03 FF '********'
Byte: 0F03 FF '********'
Byte: 0004 00 '        '
Byte: 0104 00 '        '
Byte: 0204 00 '        '
Byte: 0304 02 '      * '
Byte: 0404 02 '      * '
Byte: 0504 1E '   **** '
Byte: 0604 22 '  *   * '
Byte: 0704 22 '  *   * '
Byte: 0804 22 '  *   * '
Byte: 0904 1D '   *** *'
Byte: 0A04 00 '        '
Byte: 0B04 00 '        '
Byte: 0C04 FF '********'
Byte: 0D04 29 '  * *  *'
Byte: 0E04 FF '********'
Byte: 0F04 FF '********'
Byte: 0005 00 '        '
Byte: 0105 00 '        '
Byte: 0205 00 '        '
Byte: 0305 00 '        '
Byte: 0405 00 '        '
Byte: 0505 1C '   ***  '
Byte: 0605 22 '  *   * '
Byte: 0705 3E '  ***** '
Byte: 0805 20 '  *     '
Byte: 0905 1C '   ***  '
Byte: 0A05 00 '        '
Byte: 0B05 00 '        '
Byte: 0C05 FF '********'
Byte: 0D05 20 '  *     '
Byte: 0E05 FF '********'
Byte: 0F05 FF '********'
Byte: 0006 00 '        '
Byte: 0106 00 '        '
Byte: 0206 00 '        '
Byte: 0306 0C '    **  '
Byte: 0406 12 '   *  * '
Byte: 0506 10 '   *    '
Byte: 0606 3C '  ****  '
Byte: 0706 10 '   *    '
Byte: 0806 10 '   *    '
Byte: 0906 10 '   *    '
Byte: 0A06 00 '        '
Byte: 0B06 00 '        '
Byte: 0C06 FF '********'
Byte: 0D06 20 '  *     '
Byte: 0E06 FF '********'
Byte: 0F06 FF '********'
Byte: 0007 00 '        '
Byte: 0107 00 '        '
Byte: 0207 00 '        '
Byte: 0307 00 '        '
Byte: 0407 00 '        '
Byte: 0507 1C '   ***  '
Byte: 0607 22 '  *   * '
Byte: 0707 22 '  *   * '
Byte: 0807 1E '   **** '
Byte: 0907 02 '      * '
Byte: 0A07 1C '   ***  '
Byte: 0B07 00 '        '
Byte: 0C07 FF '********'
Byte: 0D07 31 '  **   *'
Byte: 0E07 FF '********'
Byte: 0F07 FF '********'
Byte: 0008 00 '        '
Byte: 0108 00 '        '
Byte: 0208 00 '        '
Byte: 0308 20 '  *     '
Byte: 0408 20 '  *     '
Byte: 0508 2C '  * **  '
Byte: 0608 32 '  **  * '
Byte: 0708 22 '  *   * '
Byte: 0808 22 '  *   * '
Byte: 0908 22 '  *   * '
Byte: 0A08 00 '        '
Byte: 0B08 00 '        '
Byte: 0C08 FF '********'
Byte: 0D08 39 '  ***  *'
Byte: 0E08 FF '********'
Byte: 0F08 FF '********'
Byte: 0009 00 '        '
Byte: 0109 00 '        '
Byte: 0209 00 '        '
Byte: 0309 08 '    *   '
Byte: 0409 00 '        '
Byte: 0509 18 '   **   '
Byte: 0609 08 '    *   '
Byte: 0709 08 '    *   '
Byte: 0809 08 '    *   '
Byte: 0909 1C '   ***  '
Byte: 0A09 00 '        '
Byte: 0B09 00 '        '
Byte: 0C09 FF '********'
Byte: 0D09 38 '  ***   '
Byte: 0E09 FF '********'
Byte: 0F09 FF '********'
Byte: 000A 00 '        '
Byte: 010A 00 '        '
Byte: 020A 00 '        '
Byte: 030A 02 '      * '
Byte: 040A 00 '        '
Byte: 050A 06 '     ** '
Byte: 060A 02 '      * '
Byte: 070A 02 '      * '
Byte: 080A 02 '      * '
Byte: 090A 22 '  *   * '
Byte: 0A0A 1C '   ***  '
Byte: 0B0A 00 '        '
Byte: 0C0A FF '********'
Byte: 0D0A 35 '  ** * *'
Byte: 0E0A FF '********'
Byte: 0F0A FF '********'
Byte: 000B 00 '        '
Byte: 010B 00 '        '
Byte: 020B 00 '        '
Byte: 030B 20 '  *     '
Byte: 040B 20 '  *     '
Byte: 050B 22 '  *   * '
Byte: 060B 24 '  *  *  '
Byte: 070B 28 '  * *   '
Byte: 080B 34 '  ** *  '
Byte: 090B 22 '  *   * '
Byte: 0A0B 00 '        '
Byte: 0B0B 00 '        '
Byte: 0C0B FF '********'
Byte: 0D0B 20 '  *     '
Byte: 0E0B FF '********'
Byte: 0F0B FF '********'
Byte: 000C 00 '        '
Byte: 010C 00 '        '
Byte: 020C 00 '        '
Byte: 030C 18 '   **   '
Byte: 040C 08 '    *   '
Byte: 050C 08 '    *   '
Byte: 060C 08 '    *   '
Byte: 070C 08 '    *   '
Byte: 080C 08 '    *   '
Byte: 090C 1C '   ***  '
Byte: 0A0C 00 '        '
Byte: 0B0C 00 '        '
Byte: 0C0C FF '********'
Byte: 0D0C 20 '  *     '
Byte: 0E0C FF '********'
Byte: 0F0C FF '********'
Byte: 000D 00 '        '
Byte: 010D 00 '        '
Byte: 020D 00 '        '
Byte: 030D 00 '        '
Byte: 040D 00 '        '
Byte: 050D 74 ' *** *  '
Byte: 060D 2A '  * * * '
Byte: 070D 2A '  * * * '
Byte: 080D 2A '  * * * '
Byte: 090D 2A '  * * * '
Byte: 0A0D 00 '        '
Byte: 0B0D 00 '        '
Byte: 0C0D FF '********'
Byte: 0D0D 45 ' *   * *'
Byte: 0E0D FF '********'
Byte: 0F0D FF '********'
Byte: 000E 00 '        '
Byte: 010E 00 '        '
Byte: 020E 00 '        '
Byte: 030E 00 '        '
Byte: 040E 00 '        '
Byte: 050E 2C '  * **  '
Byte: 060E 32 '  **  * '
Byte: 070E 22 '  *   * '
Byte: 080E 22 '  *   * '
Byte: 090E 22 '  *   * '
Byte: 0A0E 00 '        '
Byte: 0B0E 00 '        '
Byte: 0C0E FF '********'
Byte: 0D0E 55 ' * * * *'
Byte: 0E0E FF '********'
Byte: 0F0E FF '********'
Byte: 000F 00 '        '
Byte: 010F 00 '        '
Byte: 020F 00 '        '
Byte: 030F 00 '        '
Byte: 040F 00 '        '
Byte: 050F 1C '   ***  '
Byte: 060F 22 '  *   * '
Byte: 070F 22 '  *   * '
Byte: 080F 22 '  *   * '
Byte: 090F 1C '   ***  '
Byte: 0A0F 00 '        '
Byte: 0B0F 00 '        '
Byte: 0C0F FF '********'
Byte: 0D0F 52 ' * *  * '
Byte: 0E0F FF '********'
Byte: 0F0F FF '********'
Byte: 0010 00 '        '
Byte: 0110 00 '        '
Byte: 0210 00 '        '
Byte: 0310 00 '        '
Byte: 0410 00 '        '
Byte: 0510 3C '  ****  '
Byte: 0610 22 '  *   * '
Byte: 0710 22 '  *   * '
Byte: 0810 22 '  *   * '
Byte: 0910 3C '  ****  '
Byte: 0A10 20 '  *     '
Byte: 0B10 00 '        '
Byte: 0C10 FF '********'
Byte: 0D10 4F ' *  ****'
Byte: 0E10 FF '********'
Byte: 0F10 FF '********'
Byte: 0011 00 '        '
Byte: 0111 00 '        '
Byte: 0211 00 '        '
Byte: 0311 00 '        '
Byte: 0411 00 '        '
Byte: 0511 1E '   **** '
Byte: 0611 22 '  *   * '
Byte: 0711 22 '  *   * '
Byte: 0811 22 '  *   * '
Byte: 0911 1E '   **** '
Byte: 0A11 02 '      * '
Byte: 0B11 00 '        '
Byte: 0C11 FF '********'
Byte: 0D11 48 ' *  *   '
Byte: 0E11 FF '********'
Byte: 0F11 FF '********'
Byte: 0012 00 '        '
Byte: 0112 00 '        '
Byte: 0212 00 '        '
Byte: 0312 00 '        '
Byte: 0412 00 '        '
Byte: 0512 2C '  * **  '
Byte: 0612 32 '  **  * '
Byte: 0712 20 '  *     '
Byte: 0812 20 '  *     '
Byte: 0912 20 '  *     '
Byte: 0A12 00 '        '
Byte: 0B12 00 '        '
Byte: 0C12 FF '********'
Byte: 0D12 41 ' *     *'
Byte: 0E12 FF '********'
Byte: 0F12 FF '********'
Byte: 0013 00 '        '
Byte: 0113 00 '        '
Byte: 0213 00 '        '
Byte: 0313 00 '        '
Byte: 0413 00 '        '
Byte: 0513 1E '   **** '
Byte: 0613 20 '  *     '
Byte: 0713 1C '   ***  '
Byte: 0813 02 '      * '
Byte: 0913 3C '  ****  '
Byte: 0A13 00 '        '
Byte: 0B13 00 '        '
Byte: 0C13 FF '********'
Byte: 0D13 52 ' * *  * '
Byte: 0E13 FF '********'
Byte: 0F13 FF '********'

And, there it is:

Code: Select all

00000D00  FF FF 28 43 29 20 20 31 39 38 35 20 20 45 55 52  ÿÿ(C)  1985  EUR
00000D10  4F 48 41 52 44 20 53 2E 41 2E 20 20 2D 20 20 44  OHARD S.A.  -  D
00000D20  52 41 47 4F 4E 20 32 30 30 20 20 20 41 55 54 4F  RAGON 200   AUTO
00000D30  52 3A 20 20 4A 4F 52 44 49 20 20 50 41 4C 45 54  R:  JORDI  PALET
00000D40  20 20 4D 41 52 54 49 4E 45 5A 20 20 20 20 20 FF    MARTINEZ     ÿ

I assume everyone else knew that was there, but it was neat to see.

It also gives a plausible explanation on why they assembled the font rom the way it's configured. Doing so gives 1024 bytes (256*4) at the top of the ROM for stuff like this.

Has anyone put this into a Dragon 32 or 64 (I know John sells it for that purpose) and if so, how well does it work? I don't have a 200e, but I do have a D64.

Jim



Jim

[robcfg]

I have a Dragon 200 (which is a D64 in a fancy new case) with the 1st version of the Dragonplus daughterboard and the D200-E roms and it works like a charm!

[Go4Retro]

I have a Dragon 200 (which is a D64 in a fancy new case) with the 1st version of the Dragonplus daughterboard and the D200-E roms and it works like a charm!

Good to know. I see John is out of stock on the kits, not sure if he's planning to make another run.

I put my progress to date up on github: https://github.com/go4retro/dragonplus- ... n/charsets with a bit of text on how the files were arranged.




Jim