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?

If i got it right EhBasic, doesn't do such things. It has only a input and output address on the monitor program...

I am not familiar with EhBASIC, but I have no doubt that it can PEEK and POKE individual address bytes and twiddle the bits, and also CALL a machine-language routine. Regardless, machine-language interrupt-service routines can run underneath it without it even having to know they're there. I looked over EhBASIC years ago and could see that it was an excellent BASIC for 6502.