Generating composite video signal with 74166 shift register

[DPax92]

Hello everyone!

I really need some help to understand if I'm on the right path.

I would like to add a text only, monochrome composite video out to my simple 6502 computer. I would like to achieve it using only logic and memory and no dedicated microcontrollers, because I would like to learn and understand the hardware design required to achieve it.

Currently, my idea is shown in the scheme below. The composite signal would be generated by a 74HC(T)166 PISO shift register using a 8MHz clock signal. The clock would be divided by 8 by a binary counter to provide a 1MHz clock for the 65c02. The video data would be fed by a char ROM.

It is my understanding that to provide a constant feed of serialized data from the shift register I must provide an active low LOAD signal to the 74166 during the first low-to-high edge of the 8 clock cycles used to send out every byte of video data coming from the char ROM.

To generate such LOAD signal, I thought about this system:
An inverted clock signal is fed to a second counter. The three least significant bits of the counter are ORed to provide the LOAD signal shown in the timing diagram (signal 6). The active high RES(ET) signal is ORed with the input clock, so that the second counter, using the B clock input, starts first ensuring that the LOAD signal is low during the first low-to-high edge of the clock, and not the second.

Naturally, the video output of the shift register would be mixed with a SYNC signal to provide the necessary composite syncronization.

Does my idea make any sense? Is there any simpler way to achieve this?
Pardon me if I wrote some horrible mistake, I'm completely selft taught in the field of electronics apart for some rudimentary electrical engineering classes during college!

Thank you!

Davide

[GaBuZoMeu]

I think it should work the way you have figured. Looking at the specs of the shift register, there is no hold time requirement for /PE to ^CLK. So it should be sufficient to use the 4075 to detect state 7 from the first counter (the one that drives the clock to the 65C02 and drive /PE with that. It takes a few ns to detect state 7 so /PE is not yet valid when bit 7 is shifted out, but when the transition to state 0 happens, the /PE is still low.

I think it is not required to stop the clocks during RESET - but the clock for the 65C02 should not gated by RESET !

[cbmeeks]

I don't know if this would help, but if you can find the ULA book from Chris Smith, he does an amazing job of explaining how the ZX Spectrum generated NTSC and PAL video using counters, etc.

Very well written with lots of diagrams.

The ZX Spectrum generated color but you could probably leave some of that out.

[BigEd]

If you'd like to look at prior art, I think the Compukit UK101 had this kind of video system - it's almost the same design as the Ohio Superboard's. I think schematics of both can readily be found. But of course, you might well prefer to follow your own path, and that's good too.

[Dr Jefyll]

Hello, Davide, and welcome!

Forgive me, but I haven't fully analyzed your diagram. I'm a little short of time, and you've labeled many of the IC pins with the pin number, rather than the pin name (which of course identifies its function). Although the chips themselves are familiar, most of us don't know the pin numbers by memory.

Nevertheless, I think I get the general idea, and I can suggest an alternative which you may prefer (as it involves fewer IC's). I suggest you use the 8 MHz signal to clock a 74xx163 4-bit synchronous counter. This can be used as a divide-by-eight, as follows: There's an output (usually called TC) which goes high only when Terminal Count is reached -- ie, when wraparound is about to occur; ie, when the 4 outputs equal binary 1111 (hex F). TC can be inverted and fed back into the /PE input, which means the next clock edge will cause the chip to load rather than count. Assuming you apply binary 1000 to the parallel inputs then the value loaded will be 8. The result is actually quite simple -- the pattern of counting (in hex) ends up being 8, 9, A, B, C, D, E, F, 8 etc (because F is always followed by 8 ).

In other words, you have a divide-by-eight, with 1 Mhz appearing on the Q2 output. And you can probably use TC to tell your video shift register that it's time to load (rather than shift). If that's not clear I can create a diagram for you (but not this morning).

sn74hc163.pdf

(1014.62 KiB) Downloaded 119 times

It sounds as if you understand the '166 shift register properly, but for confirmation you may wish to read the latter portion of this thread (which also pertains to using a '166 for video), starting here.

Finally, you haven't explained what drives the input of the Character Generator ROM. There are various options possible, but FWIW there is a classic technique which Don Lancaster promoted in the 1970's (also adopted by the Timex/Sinclair ZX1000), known informally as Cheap Video. I've successfully implemented Cheap Video on three different computers, and posted about the technique here.

Cheers,
Jeff

[DPax92]

First of all, thank you all for your kind help!

GaBuZoMeu wrote:

but the clock for the 65C02 should not gated by RESET !

Ah! That would have been quite the mistake, making the reset of the 6502 impossible, thank you for spotting it!

GaBuZoMeu wrote:

it should be sufficient to use the 4075 to detect state 7 from the first counter (the one that drives the clock to the 65C02 and drive /PE with that. It takes a few ns to detect state 7 so /PE is not yet valid when bit 7 is shifted out, but when the transition to state 0 happens, the /PE is still low.

I believe I understand your suggestion, I initially considered something similar but I am not very confident about timings and I was afraid I might do something wrong! There is one thing I do not understand: the 4075 is a OR gate, shouldn't I be using a NAND gate to detect state 7 with a low pulse?

BigEd wrote:

If you'd like to look at prior art, I think the Compukit UK101 had this kind of video system - it's almost the same design as the Ohio Superboard's. I think schematics of both can readily be found. But of course, you might well prefer to follow your own path, and that's good too.

cbmeeks wrote:

I don't know if this would help, but if you can find the ULA book from Chris Smith, he does an amazing job of explaining how the ZX Spectrum generated NTSC and PAL video using counters, etc.

Very well written with lots of diagrams.

The ZX Spectrum generated color but you could probably leave some of that out.

Thank you both for your suggestions, I will definitely look into them!

Dr Jefyll wrote:

many of the IC pins with the pin number, rather than the pin name (which of course identifies its function). Although the chips themselves are familiar, most of us don't know the pin numbers by memory.

I am really sorry about that I drew this scheme initially as a "constructive" diagram before realising I was not sure it would work and deciding to ask for help. Next time I will definitely put pin names!

Dr Jefyll wrote:

In other words, you have a divide-by-eight, with 1 Mhz appearing on the Q2 output. And you can probably use TC to tell your video shift register that it's time to load (rather than shift). If that's not clear I can create a diagram for you (but not this morning).

Thank you very much for your suggestion! So, if I understand correctly, this circuit would provide the same result as GaBuZoMeu's solution?

Dr Jefyll wrote:

Finally, you haven't explained what drives the input of the Character Generator ROM.

I have read Don Lancaster's cheap video solution, and I find it quite fascinating! However, my understanding is that using that approach, a lot of CPU time would be needed to drive the screen, am I correct?
What I was thinking about was to use an other solution mentioned in the forum, i.e. to store the video information (chars in my case) in RAM, and have a counter fetch them while the 6502 is not reading from the data bus (that would be when PHI2 is LOW, am I correct?) using bus transceivers. I am still in the process of understanding all the issues related to this approach, because I started by "the end", i.e. the shift register. I will definitely ask more questions about this in the near future!
I will definitely begin by putting a simple counter to provide the address to the char ROM to test the sistem naturally.


Kind regards,
Davide

[Dr Jefyll]

DPax92 wrote:

So, if I understand correctly, this circuit would provide the same result as GaBuZoMeu's solution?

Broadly speaking, yes. In both cases we use the 8 MHz pixel-clock signal to generate a pair of 1 Mhz signals, one with 50 % duty cycle (for the 65C02) and one with 87.5 % duty cycle (for the /Load input of the '166). Possibly I've misunderstood, but GaBuZoMeu's proposal might look like this (below). And he's right -- you don't need two 193's. One will do. But, as you say, a NAND gate would be better. An OR would send its output low when the 3-bit count is zero, and that doesn't seem right (to me).

Quote:

I have read Don Lancaster's cheap video solution, and I find it quite fascinating! However, my understanding is that using that approach, a lot of CPU time would be needed to drive the screen, am I correct?

Yes, but it's a tradeoff that has benefits as well.

Understand that generating video is a hard problem! You need to move a lot of data very quickly, and the timing is needs to be cycle perfect if you want a stable display. Cheap Video uses software to replace a lot of the hardware you'd otherwise need. Neither approach can avoid the complexity... it's just that software is easier and cheaper to "build" than hardware. (The only way to truly avoid the complexity is to let video be handled by a separate subsystem, such as a Propeller, Pi or Arduino.)

If you prefer to crunch the problem entirely in hardware, perhaps you can select a DMA controller IC (intended for 6800 family, for instance) that has the necessary counters included internally. That would be worth looking into. And Dual-Port RAM offers a different set of tradeoffs which might interest you. The "best" choice will depend on your abilities and your preferences.

Quote:

What I was thinking about was to use an other solution mentioned in the forum, i.e. to store the video information (chars in my case) in RAM, and have a counter fetch them while the 6502 is not reading from the data bus (that would be when PHI2 is LOW, am I correct?) using bus transceivers.

Yes, using the memory when PHI2 is low is a good way to avoid interfering with what the CPU is doing. (BTW, notice this changes when the /Load needs to occur, relative to the 65C02 clock.)

By the way, the "use the memory when PHI2 is low" is also applicable to Cheap Video! Although you'll still need transceivers or multiplexers to allow memory sharing, you won't need to add any counters; just add a second microprocessor (as I did back in the 20th Century with this project). An interesting spinoff is that you can execute two software threads simultaneously if you're willing to temporarily stop producing video.

-- Jeff

Edits: clarity, especially re use of the PHI2-low period

[GaBuZoMeu]

DPax92 wrote:

... shouldn't I be using a NAND gate to detect state 7 with a low pulse?

Yes, of course, I didn't look for the 4075, sorry. But Jeff's idea using the HC163 instead of the HC193 is even simpler and preferable! As counting and loading happens only during ^CLK you can use the inverted TC to do both: (p)resetting the counter and prepare the parallel load of your shift register. This is how synchronous action works, everything has to be valid some ns before ^CLK. Changes afterwards doesn't matter.

During PHI2 = low you can access the data bus in case of a 65C02. (The 65C816 uses this period to provide the bank address.)

But addressing the text RAM (I assume text as you are going to use a character ROM) requires another set of bus drivers that can be turned on and off or a multiplexor. With today's fast RAMs and ((E)EP)ROMs this should be no problem up to 4 or 5 MHz bus frequency (PHI2). More expensive would be using a Dual Port RAM, where accesses can be done freely from both sides. But then you can run your CPU at any clock rate and you would not need any sort of bus multiplexing.


Regards,
Arne


[edit]: interesting cross post

[drogon]

Actually, something I've just posted in another topic is worth a read, as it also uses a 74166 shift register - as well as half a dozen others- it's how the Apple I does its video. In essence, it's not using precious system RAM, but 6 x 1024 bit x 1 shift registers constantly circulating data to hold the screen caracters, 6 bits per character, being clocked out to another shift register which goes into the character generator ROM, the output of which goes into another shift register to clock the pixels out...

https://www.sbprojects.net/projects/apple1/terminal.php

It's clever, uses no system RAM, but is slow in that the write timings need to work in with the scan lines, but it might give some food for thought...

-Gordon

[DPax92]

Dear all,

thank you for your kind help! As you have correctly asked how I think to generate the address for the character rom, I have started a new thread (viewtopic.php?f=12&t=5476) to better explain my idea on the rest of the circuit so not to get off topic, but please feel free to remove the thread if you think I should continue here!

Thank you again!

Kind regards,

Davide