CRTC chip
CRTC chip
Hello!
Since i am building a 6502 project i wanted to have a color graphic module. So i found about the MC6847 CRTC color chip, and so i bought it on ebay. And i also had to buy the MC1372, and i did, on ebay. But there was a problem with the seller, and i never got the MC1372. So i asked a ebay seller who has all kind of old ic stuff, but he can't find it...
So i have two choices:
1. Have black and white graphic.
2. Get another color CRTC chip...
So does anyone know how could i replace the MC1372 chroma modulator chip with something other, or some other CRTC color chip that is similar to the MC6847 (i prefer PAL)?
Since i am building a 6502 project i wanted to have a color graphic module. So i found about the MC6847 CRTC color chip, and so i bought it on ebay. And i also had to buy the MC1372, and i did, on ebay. But there was a problem with the seller, and i never got the MC1372. So i asked a ebay seller who has all kind of old ic stuff, but he can't find it...
So i have two choices:
1. Have black and white graphic.
2. Get another color CRTC chip...
So does anyone know how could i replace the MC1372 chroma modulator chip with something other, or some other CRTC color chip that is similar to the MC6847 (i prefer PAL)?
- GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
What out for the bus interface and the capabilities of those chips. The VIC 6560/6561 was built into the Commodore VIC20 - which had colour yes, but only 22 characters per line for example. The other chips have been used in the C64 and C128 (IIRC) and have been built for that specific environment. You may use them in other systems, but due to that history they have their peculiarities. The provide PAL resp. NTSC compatible (depending on the chip, the timing is fixed!) signals.
For a general purpose CRTC I use the 6545/6845 which has programmable timing and can thus be used for PAL as well as NTSC, but neetds more external logic, esp. if you want color.
André
Edit: the 6545 and 6845 are mostly compatible. See http://www.6502.org/users/andre/hwinfo/crtc/index.html
For a general purpose CRTC I use the 6545/6845 which has programmable timing and can thus be used for PAL as well as NTSC, but neetds more external logic, esp. if you want color.
André
Edit: the 6545 and 6845 are mostly compatible. See http://www.6502.org/users/andre/hwinfo/crtc/index.html
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
This might interest you. I bought 10 of them last year. They were Hitachi (HD46505SP) 6845 equivalents.
-
leeeeee
- In Memoriam
- Posts: 347
- Joined: 30 Aug 2002
- Location: UK
- Contact:
ElEctric_EyE wrote:
This might interest you. I bought 10 of them last year. They were Hitachi (HD46505SP) 6845 equivalents.
And i can't find the dragon 32 schematic...
Unicorn electronics lists MC1372 on their website, http://www.unicornelectronics.com/IC/MOTOROLA.html at a fair price.
- GARTHWILSON
- Forum Moderator
- Posts: 8774
- Joined: 30 Aug 2002
- Location: Southern California
- Contact:
Quote:
Minimum order 25$...
I just submitted a order and i had to add a feeewwwwwwww more items, it will be for some next project...
Ok now lets assume i will use the Motorola mentioned in the first post, now i have seen there is a pin that disconnects the CRTC form the address bus, so it can be written into the memory. Does interrupting the address cause visible artifacts on the tv screen?
Ok now lets assume i will use the Motorola mentioned in the first post, now i have seen there is a pin that disconnects the CRTC form the address bus, so it can be written into the memory. Does interrupting the address cause visible artifacts on the tv screen?
Yes it does,
You will either need to implement some sort of synchronization method that tells the CPU when it can write to the memory without causing screen disturbances. An interrupt caused by FS* is one way of doing that, polling FS* on a port pin is also doable but more expensive CPU cycle wise.
Another way of handling this issue is by implementing a double buffering scheme in hardware. You could have two SRAM devices separated by buffers, where you would always read and write into the SRAM that isn't used by the 6847 and then use a control bit in a register somewhere to simply switch the SRAMs.
I have tried both and the last one is more efficient but more expensive board area wise and more complex to design and build.
You will either need to implement some sort of synchronization method that tells the CPU when it can write to the memory without causing screen disturbances. An interrupt caused by FS* is one way of doing that, polling FS* on a port pin is also doable but more expensive CPU cycle wise.
Another way of handling this issue is by implementing a double buffering scheme in hardware. You could have two SRAM devices separated by buffers, where you would always read and write into the SRAM that isn't used by the 6847 and then use a control bit in a register somewhere to simply switch the SRAMs.
I have tried both and the last one is more efficient but more expensive board area wise and more complex to design and build.