Interleaving video memory acces for the MC6845

[olof-a]

I recently got an MC6845, and I have been able to produce a screen-full of text. My test setup has the data bus connected to an Arduino, the 6845's address bus simply going to an 8K SRAM, the
character clock at 1MHz, and pixels output at 8MHz. The 6845 is programmed to provide a 50hz VSync, and has exclusive access to the memory bus.
I would now like to interface it to a 65C02. For the 6845 to be of any use, the 65C02 would of course have to be able to read/write to/from video memory. I am currently thinking of two methods for
splitting memory access between the two chips. First would be the 6845's CLK (character clock) input and the 65C02 PHI2 input sharing the same signal, and the 65C02 RDY and BE inputs being
high during the blanking intervals and the end of a scanline/field. This method would result in no MPU activity while an image is displayed.
The second method would be (as the title suggests) interleaving memory access. The datasheet for the MOS 6545-1 has a diagram showing the timing of this method (Figure 6, attached to this post.)
I am uncertain of how I should go about implementing this. I'm currently thinking that I would only need 2 octal buffers on the 6845's address outputs, whose inverted output-enables are connected to
PHI2, and the 65C02's BE connected to PHI2 as well. This would disconnect the 6845's address bus from the rest of the system when PHI2 is high, while enabling the 65C02's buses, and do the
opposite while PHI2 is low. I believe that this would also require the character clock to be driven by PHI1 instead of PHI2.
Interleaving memory access seems almost too easy, especially when considering the pros of it. It feels like I must be missing something, and as such, I have written this post in order to double check
with you all. Thanks in advance for your input on the matter.

[gfoot]

olof-a wrote:

I am uncertain of how I should go about implementing this. I'm currently thinking that I would only need 2 octal buffers on the 6845's address outputs, whose inverted output-enables are connected to
PHI2, and the 65C02's BE connected to PHI2 as well. This would disconnect the 6845's address bus from the rest of the system when PHI2 is high, while enabling the 65C02's buses, and do the
opposite while PHI2 is low. I believe that this would also require the character clock to be driven by PHI1 instead of PHI2.
Interleaving memory access seems almost too easy, especially when considering the pros of it. It feels like I must be missing something, and as such, I have written this post in order to double check
with you all. Thanks in advance for your input on the matter.

I'm afraid I think that connecting BE to PHI2 is not going to work very well - it means that while PHI2 is low, the 6502 is not driving the address bus, and you won't be able to do any address decoding until PHI2 goes high again. At that point you're going to have to delay the operations you perform while PHI2 is high until the address bus is stable again, and until your decoding logic has all propagated. Things like memory writes and I/O operations especially need to be delayed, as if you try to do them too soon they'll go to the wrong addresses, with lasting effects.

Usually systems I've looked at put bus transceivers/buffers/multiplexers between the CPU and the (video) memory address bus (and data bus). The BBC Micro (http://www.mdfsnet.f9.co.uk/Info/Comp/B ... ts/bbc.gif, lower centre area of the circuit) used buffers (ICs 8,9,10,11,12,13) for the address bus, and a transceiver (IC14) for the data bus. For the revised "B Plus" (http://www.mdfsnet.f9.co.uk/Info/Comp/B ... bcplus.gif, bottom centre again but also snaking up the middle a bit) they switched to tri-state multiplexers which are actually more or less used like buffers again - the multiplexing is, I believe, just there due to how dynamic RAM works. So really in principle it was just buffers again. For the later Master, they used custom programmed logic chips.

Most of my own designs (e.g. https://github.com/gfoot/simplevga6502/ ... ematic.png) have used bus transceivers for this, but I usually just use them like one-way buffers, with the direction fixed.

You can also use 2-to-1 multiplexers, with the 6845 and 6502 driving the inputs and the multiplexer choosing which one to send to the RAM's address bus based on e.g. PHI1 or PHI2. It should work well and they don't need to be tristate for this.

But again there's nothing wrong with using buffers, since you're already doing that for the 6845 - you just need to use them between the 6502's address bus and the video RAM's address bus.

[sburrow]

olof-a wrote:

the 65C02's BE connected to PHI2

This is exactly what I do in my VGA builds, and it works great. As long as you get the timing down, and the logic, everything works well for me. That is, though, at lower speeds. As Bill (plasmo) pointed out, it won't give you as much access time. I'm running mine at 3 MHz which gives me plenty of time to access 70ns Flash ROM even with PHI2 connected to BE. If you go too fast though, you are essentially halving the time your address and data pins are valid.

Thanks!

Chad

[barnacle]

A caution there - I too have successfully used BE and PH2 tied together but at speeds up to 2MHz with no faster testing - is that it might upset/break operation of e.g. 6522 that's relying on the address being there before PH2.

Neil

[olof-a]

Quote:

But again there's nothing wrong with using buffers, since you're already doing that for the 6845 - you just need to use them between the 6502's address bus and the video RAM's address bus.

The extra buffers make sense now that I think about it. I was hoping I would be able to save a few sockets and keep the circuit simple but I guess I'll just have to 'bite the bullet'. Thanks for clearing stuff up.

[jds]

If you haven't already read this, Synertek app note 3 has useful information on the various ways of interfacing to the 6545.

I particularly like the example of using the 6545 address lines as a keyboard scanner.

[BigDumbDinosaur]

jds wrote:

If you haven't already read this, Synertek app note 3 has useful information on the various ways of interfacing to the 6545.

I particularly like the example of using the 6545 address lines as a keyboard scanner.

Reading that app note reminded me of how primitive the 6545 was compared to later video display controllers (VDC).

[barnacle]

Hmm. Can't connect to the archive...

Neil

[BigDumbDinosaur]

barnacle wrote:

Hmm. Can't connect to the archive...

Neil

I just tried it and everything was hunky-dory.

[L0uis.m]

Hi Neil,

BigDumbDinosaur wrote:

barnacle wrote:

Hmm. Can't connect to the archive...

Neil

I just tried it and everything was hunky-dory.

I tried it too and it was indeed a slow connection and difficult to download at the moment (suppose location/time dependant).
I already downloaded that file some time ago, maybe this will help:

[barnacle]

Thanks Louis, got it now, ping time in excess of thirty seconds and about ninety seconds to resolve the page. Downloaded quickly enough once it found it, though.

Code: Select all

barnacle@barnacle-Latitude-9430:~$ ping archive.6502.org
PING archive.6502.org (172.105.137.7) 56(84) bytes of data.
^C
--- archive.6502.org ping statistics ---
32 packets transmitted, 0 received, 100% packet loss, time 31765ms

Neil

[BigDumbDinosaur]

barnacle wrote:

Code: Select all

barnacle@barnacle-Latitude-9430:~$ ping archive.6502.org
PING archive.6502.org (172.105.137.7) 56(84) bytes of data.
^C
--- archive.6502.org ping statistics ---
32 packets transmitted, 0 received, 100% packet loss, time 31765ms

31765ms?  It’s all those barnacles slowing down your Internet boat. 

[barnacle]

Yeah, the drag is amazing. But it usually makes for a peaceful trip.

Neil

p.s. not responding today, either. Though no problems with the forum. Web.archive is throwing a 503/no server available error, so I guess it's their end.

[BigDumbDinosaur]

barnacle wrote:

p.s. not responding today, either. Though no problems with the forum. Web.archive is throwing a 503/no server available error, so I guess it's their end.

Sounds like a recalcitrant router somewhere.

[GARTHWILSON]

The separate archive site was apparently having problems.  It's working at the moment.  See viewtopic.php?p=108480#p108480 for the explanation of why there was this redirect.