6847 external character ROM

[brain]

Looking to use a 6847 on a project, and wanted to try to use the external ROM for characters noted in the datasheet. But, I am confused about how to feed some of the character ROM address lines (the 8 that appear to be coming from the Data bus, but that does not make sense to me)

Anyone ever used the external ROM on the 6847?

Jim

[L0uis.m]

Hello Jim,

Maybe these (compiled pages from a datasheet) will help:

[Rob Finch]

I have used the 6847 before, but not with an external character ROM. I assume you are referring to the schematic figure 23 in the data-book? It may be a little confusing but data lines coming from the display memory need to be connected to the address lines of the character generator. The address lines from the VDG are feeding the display memory to select the memory cell containing the character to display. Then having the character to display on the data bus, it is used as an index into the display ROM. There are tri-state buffers to isolate the CPU data bus from the output of the generator ROM.
It saves 3 or 4 chips to use the VDG’s internal character ROM.

I think the Y, R-Y, and B-Y signals can also be used without the MC1372 via voltage comparators to generate RGB signal levels. It may be possible to interface to a VGA connector. I sketched up a circuit to interface to a monitor a while ago which I may still have somewhere on my computer. I never got around to trying it though.

Another solution for using an external ROM, may be to mutliplex the data bus into the address lines of the display memory. Part of the display memory would then be for a programmable character set. The character set could just be stored in a ROM connected in the ordinary fashion, and software used to load the the display memory appropriately. It may be fewer parts if the character set is stored in the system ROM.

[Rob Finch]

I made a sketch for an alternate external ROM system. I think something along these lines would work. But it needs the CPU to copy the character images. It may be fewer parts if there is already a system ROM.

6847 alternate ext. ROM

[brain]

Hello Jim,

Maybe these (compiled pages from a datasheet) will help:

Thanks, but I already pored over the data sheet (downloaded). However, Rob Finch's comment about the data from the regular memory (which is addressed by the VDG) being used as the top 8 bits of the address for the external ROM makes sense to me. I was trying to determine why data lines would be used as address lines.

Jim

[brain]

Rob Finch wrote:

I have used the 6847 before, but not with an external character ROM. I assume you are referring to the schematic figure 23 in the data-book? It may be a little confusing but data lines coming from the display memory need to be connected to the address lines of the character generator. The address lines from the VDG are feeding the display memory to select the memory cell containing the character to display. Then having the character to display on the data bus, it is used as an index into the display ROM. There are tri-state buffers to isolate the CPU data bus from the output of the generator ROM.

Thanks, that made it click. I was trying to determine why data lines would be connected to address lines. It makses sense now.

That said, one of the reproductions (for which there is only pics, not schematic), has a few more ICs than shown in the datasheet, so I am wondering if there's more complexity than illustrated.

https://thezippsterzone.com/2018/05/09/ ... ter-rom-1/

Specifically:

https://i0.wp.com/thezippsterzone.com/w ... C464&ssl=1

I see 2 '157s (which are the buffers showin the diag), an '86 (which could replace the NAND gate in the design), an '04 (the inverter in the diag, though an '86 could also be used), and a 749X (maybe a 7493, replacing the '161 that needs to be the rest of the address bus), but then a 7473 (?) and an unnamed IC (maybe a 7492 divide by 12, since the 90 can't be preloaded). The '73 seems odd as I don't see it anywhere in the schematic, unless it's part of the 7493?/7492? counter/reset (not sure why they would not just use the preloadable '161 as shown in page 14 in @Louis.m's atatchments.

Maybe it's that the LowerKit designer did not understand the '161 idea, or they wanted the ROM laid out a different way (to use the std way shown in the 6847 datasheet, I assume the lower 8 address lines would go to the data bus lines "the character", and the upper 4 address lines would go to the counter. So, the first line of the first char would be at 0, the second line at 256, etc. Not sure it saves anything, though, as 256x12 is 3072, and 256x16 is 4096, and ROMs never came in 12x256 sizes. Thus, you're wasting 1024 bytes either way. And, it's a ROM, so not sure anyone would care how the data is stored there (obviously if it was RAM, you would).

Jim

[Rob Finch]

Quote:

the character", and the upper 4 address lines would go to the counter.

I think it is more likely that the lower address bits are connected to the counter, and address bits 4 to 11 of the ROM connected to the data bus. That way the first row of a bitmap is at address 0, the second at address 1, etc. Each character would use 16 consecutive bytes then. The FF might be to control one of the other signals on the 6847 like the alpha vs graphics signal. Or to disable the external ROM.
Using a couple of adders on the address lines would allow the ROM contents to be packed. (The character number could be multiplied by 12 using adders, then added to the counter, but that may cause timing issues).

Nice photos. Reminds me of reverse engineering some circuit boards.

The 6847 is simple enough. I wonder if it would fit in a CPLD. Something like the AppleII's video chain would likely fit. It seems a bit strange to me to go modern with CPLD then go retro and use the 6847. Why not just put the whole thing in CPLDs and leave out the 6847.

[brain]

I guess I was trying to put myself back in the 1980's "be as compact as possible" mindset.

Though my Google-fu was not doing well last night, I did finally find the manual for this product:

https://colorcomputerarchive.com/repo/D ... Manual.pdf

And, on page 30, the schematic is there.

As you surmised, A0-A3 is the output of the 7493 counter.
The '93 is clocked from Horizonal Sync, via an inverter. So, increment once per line
The '73 is still confusing me, though.
DA0 will toggle during the screen addressing. It's then inverted, so first char location would be low to high, which means the JK is clocked, J is 1, K=0, meaning Q would go high as the DA0 returns to 0, I assume after putting char position 511 on the screen.
Thought it says Q on the schematic, pin 13 is actually !Q, so Q1 would go low.
Low would then enable the RP signal (!RP, but inverted) going into the '125, which then would put low at the R pins on the '93.
counter counts.
When !RP goes low, RP would be high, and the counter resets.

I guess the '73 was to create an initial !RP signal (the datasheet notes that RP does not trigger until 12 lines have been output) to reset the counter at the beginning of a frame, but it seems like it would have been just as easy to use !RP & !FS as the input to the reset. I must be missing something....

Jim

[L0uis.m]

Note: As far as I know the advantage of using the data byte from the display memory for the lower address lines (0 through 7) of the character generator and the counter output (the 161) for the upper address lines (8 through 11) is that when using the maximum of 256 different characters, all data in the character generator memory is contiguous and the size of the generator memory is only 3 KB instead of 4 KB with intervals of four unused bytes in between every twelve bytes (when using the counter for address lines 0 through 3 and the data byte for address lines 4 through 11).

[Rob Finch]

Putting the counter on the upper bits is a decent idea. It would work well if the display memory is used to store the glyphs and the glyphs are copied there from ROM. One thing to consider is finding or writing a piece of software that will allow editing character glyphs and save them in a binary format compatible with the way the ROM is organized.

If the system ROM is used to store the glyphs, then just about any format could be used. The glyphs could be stored in a compressed format, then expanded and copied to the display memory (it is a one-time operation). For example, assuming one wants a space between rows of characters, chars could be stored with 11 scan lines instead of 12, with the 12 line assumed blank. A char bitmap area in the display memory may need an offset added (flipped a-bit) so it does not collide with the regular display memory. May need a larger display memory.

[L0uis.m]

Hello Rob (and Jim),

Rob Finch wrote:

One thing to consider is [··] a piece of software that will allow editing character glyphs and save them in a binary format compatible with the way the ROM is organized.

That won't be very difficult, add 1 to the high byte (instead of to the low byte) for each next line of a character (just like the 161 counter does).