If you want to use the 6847 with PAL, search for the Acorn Atom video PAL boards, they are available on the net although I can't remember where.

I used a pair of MC1496 modulators with a 6847 to generate NTSC colour - the design is based on the Acorn Atom colour card. This isn't difficult to do.

If you want PAL it becomes more difficult because you have to keep swapping the phase of the colour sub-carrier. And if you want a 50Hz scan rather than a 60 Hz scan, it becomes very difficult, since you have to stop the clock to the 6847, count clock pulses externally and generate line sync pulses, then restart the 6847 when sufficient extra lines have been scanned. The Acorn Atom board added 25 lines at the top and 25 lines at the bottom of each scan for a total of 50 lines per scan or 100 lines every 2 scans - thus going from 525 lines to 625 lines. It took about a dozen TTL chips to do this and if you want to do this and add colour, you would have to worry about colour bursts as well - this is why I never bothered using the 6847 to generate PAL.

If you are happy with monochrome graphics, the 6847 connected to a monochrome monitor gives an excelent display. The colour modes give a grey-scale image, although in 4 colour modes you only ever get 3 shades of grey since two colours always have the same luminance value. Connecting the colour sub-carrier outputs of the 6847 into the video amplifier through resistors can overcome this, although some playing around with resistor values will be needed to give good results.

The 6847 needs to be synchronised to the CPU to prevent snow on the image. The 6847 needs a 3.579 MHz clock but because its clock input uses an edge detector circuit, there is no way of telling which edge of the clock it is using.

I run the 6502 at half the 6847 clock. The CPU has access to the memory when phase2 is high and the 6847 when phase2 is low. Between the data bus and the 6847 I used a 74HC574 latch which latches the data bus on every rising edge of the phase2 clock. I found that this completely cured the synchronisation problem, allowing me to run programs from the video memory with no snow whatsoever.

The 6561 PAL VIC chip can be removed from a PAL VIC20. Used with a modern 65C02 that has data and address bus enable means you only need a couple of buffers for the data bus. Synchronisation between the CPU and the 6561 is automatic if you feed the CPU clock from the 6561 as the data sheet says. On a PAL TV or monitor, the 6561 can produce a character resolution of 26 x 32 characters - even though the data sheet says the chip can only handle a 700 character screen! The chip can do larger text resolutions but 26 x 32 is the largest that will fit on a TV screen without characters being lost off the edges. There are two versions of this chip and each needs a slightly different video output amplifier. The amplifier circuit I used was a direct copy of the one in the VIC20.

The only problem I have with the 6561 is that it will plonk itself into the memory map at $2000 to $20FF - which sits right in the middle of the RAM area. It is possible to move this by circuit tricks but whatever you do, you will have to ensure that you don't have memory mapped into the same address as the VIC chip.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

I was first thinking about using two rams, but the graphic board gets way too big, so...
Could i just put some latches, and then wait for the last line(i think the last line on the tv is not displayed?) and then write?

Assuming you are using the 6847.

You will need two 8-bit buffers (eg 74HC541) between the CPU address bus and the graphics RAM. Also, you will need a bi-directional buffer (eg 74HC245) between the CPU data bus and the graphics RAM. You enable the buffers when the CPU reads or writes to the graphics RAM and phase 2 is high. You have to make sure the direction line of the data buffer is set according to whether the CPU is performing a read or a write.

To prevent the CPU from causing snow on the screen during reads from and writes to the graphics RAM, you then have two options.

1 Only allow the CPU to access the graphics ram when the 6847 FS pin is low. This pin is low for every scan line that is not part of the actual graphics display, including the top and bottom borders and frame flyback. This ensures that the CPU only accesses graphics RAM when the 6847 is not using it. This allows your CPU to run at any speed and not be synchronised to the 6847.

2 Synchronise the CPU with the 6847. To do this, clock the 6502 with the 6847 clock divided by 2. Then connect a 74HC574 latch between the graphics RAM data bus and the 6847 data bus (inputs to RAM, outputs to 6847). Connect the 6502 phase2 line to the 74HC574 clock line. This ensures that valid data is always available to the 6847 even when the 6502 is accessing the graphics RAM and prevents CPU accesses from causing snow on the display. Using this method the 6502 can freely access the graphics RAM at any time. Since it only requires 1 extra chip, it is my prefered method.

This method should also work if you clock the 6502 at the same clock speed as the 6847 (3.579 MHz). However, I havn't tried this so I cannot confirm that it will work.

If you havn't already done so, I suggest you download and study the Acorn Atom circuit diagram. This computer used a 6502 CPU and a 6847 VDG. The circuit diagram shows exactly how to connect the two chips together. The Atom monitored the FS line to determine when to write to the graphics RAM to prevent snow.

_________________
Shift to the left,
Shift to the right,
Mask in, Mask Out,
BYTE! BYTE! BYTE!

In the N8VEM project we have had luck with the TMS9918. It is still easy to get and can be interfaced fairly simply.

http://n8vem-sbc.pbworks.com/w/browse/# ... 0%28SCG%29

I have attached the 9918 card from the link above to the N8VEM 6502 SBC with no problems.

Dan

_________________
Dan Werner

Here is the schematic:

http://n8vem-sbc.pbworks.com/w/file/243 ... CG-sch.pdf

_________________
Dan Werner

The TMS9918 looks a bit more complex, and it needs 16k of ram, which is a bit much... My memory map kooks like this: 32k ram, 4k onboard i/o, 4k expandable i/o, 8k graphic, 16k eeprom. Ill try to stick with mc for now since i bought already... I don't know what is happening with that Unicorn emectronicy company, i placed a oreder the day that post came, and i sent a email, but nothing yet.
And thanks about the info for the mc, i was looking for a pin which would indicate that the line is not visible, i will try to do the trick with the laches...

Edit: The TMS9918 looks very nice indeed, it costs about 14$ on ebay, and it might be useful for another project(if not this)!

The 9918 does use 16K, but it is outside the memory map of your CPU, it only uses a few bytes from your CPU's memory map. All of the communication is done through the chip, which is a bit slower but much less complicated to interface to.

Dan

_________________
Dan Werner

As alternative, you might want to look at the Nec 7220... it appears to have been well regarded in its day. I think there is also a card being made with this controller by the N8VEM people.

Didn't know that, thanks for the info, but still i rather use this one since i already bought it, but it would be nice to have a system with it...
My ebay seller told me that he found some ic which could be used as a replacement for the MC1372:
CX556A
uPC1352C
TDA3570

They are a bit different, but might be useful...

I've been trying to get the MC6847 to work, but it seems i did something wrong... Can i make a video amplifier with a BC109C transistor, or with a LM387?

I have a thread at brielcomputers where I log my progress on my color graphics card for the micro-kim. My schematic is there if you need them.

http://www.brielcomputers.com/phpBB3/vi ... f=13&t=937

How did you convert ascii characters to the characters for the crtc, and how does it move text up when a new line(\n) is inserted?

The MC6847 has an internal character generator and a character ROM generating 64 different characters.

The following picture shows you the characters.


The first character '@' is obtained by storing a 0 in the video memory, a 1 for the letter 'A' and so on. To convert an input ascii character would be as simple matter of subtracting an offset from the ascii character and storing it into memory.

Any scrolling that needs to take place will have to be implemented in software by simply moving everything from the 2'nd line and onwards, 32 bytes down in memory. The device have no support itself for doing that. In fact, the only thing programmable is the control input pins on the device, and that is only affecting graphic modes, inversion and color space. My schematic shows you how you can connect these signals.

I was thinking to add atmega8 for calculating characters, backspace, scrolling, and all the text functions... So characters would input on a latch connected to the atmega8, and then the atmega8 would know the position in the ram, and if a new line is necessary, and write into the ram...

Why not let the 6502 do all that?