Here is the small section of the NTSC Video Generator that is responsible for delaying the incoming 3.579MHz color carrier frequency into 32 equal phase steps.


Chroma Phase Delay Circuit

The original 3.579 color burst reference clock (279 ns) passes through 32 buffers, each one chained to the next, and tapped at the output, giving 32 possible 8-9 ns propagation delays lasting between 0 and 300 ns, depending on how taps are arranged. Chroma address bits 0-3 select the 74HC4051 channel outputs, and the 74HC138 acts as a 2 to 4 decoder, selecting one of the four 4051s using bits 3 and 4.

This series of delays splits the color into 32 divisions along the NTSC color wheel...


Chroma Phase Delay Circuit

For every one of those colors, the Luma Data will output 8 bits, creating 32 colors with 256 brightness levels. This translates into 8192 total colors.

Unlike Amiga HAM mode, these colors are fully available, and will not bleed into each other. My horizontal resolution of 360 (320 visible) does push the limits of NTSC a bit, but having so many shades to work with will minimize artifacts.

In previous retro works (1990's), I used a simplified version of the above circuit to generate 8 delays in a 16 color palette and it worked great.

I plan to wire this up very soon to see what it looks like on screen when my VIC-20 shoves out all 8192 colors to my trust 1702 monitor. Go VIC!

Brad

Here is the 8 Bit Luma R2R DAC I intend to try...


256 Brighness Levels

Output voltage looks good, and is adjustable between .8 and 1.2 volts.
The diode blocks forward voltage form the Sync Pin, but allows dropping to ground.
Resistors r17 and r23 make a variable resistor that adjusts "Video Level".

Not sure how I am going to mix Chroma with Luma yet.
Probably another transistor to modulate the output.

Brad

Have you thought about using PWM for the video DAC?

Your pixel clock is something like 5MHz, so if you had PWM at say 100MHz you might be able to generate a decent image. Could be very challenging on breadboard though, and with parts from the era you are targeting.

I have actually tried that in the FPGA version of this project that I have been using as a test bed for various video experiments such as color space, DAC response, and optimal overscan on different monitors.

In one test, I clocked a Spartan-6 at 14.318 MHz, and used a 16X PLL to create a 229.088 MHz master clock from which I derived the timing for my 360x240 frame (burst *64).

From there, I divided by 32 to derive the 7.159 pixel clock, and then setup phase shifts for 32 possible colors. For Luma, I drove PWM at the 229 MHz to see how it would work.

The result... not good.
Compared to the trusty old resistor DAC or ladder, PWM is not as good.
I would guess the PWM would need to be much higher, perhaps a GHz?!

I once tried doing VGA analog that way as well, and it was a disaster.

I also experimented in using those RGB to NTSC chips like the ADV724, but once again, the image quality I managed on my breadboard logic / R2R systems was far superior. .. less artifacting, less flicker, smoother color, no dot crawl.
Something cool about seeing the magic happen with 15 cents worth of resistors anyhow!

Brad

Here is the NTSC Video Frame Generator.
Operation is simple, X and Y counters triggering comparators to create signals.
The 74HC74 flip flops toggle between on and off states.


NTSC Frame Generator

Full size image...
http://lucidscience.com/temp/jetpack-frame-1l.png

The Pixel Clock is 7.159MHz, which is twice the Color Burst frequency.
The generated image will be 376 x 240 pixels, with about 320 x 200 on screen.
Having more pixels than a CRT can display means no borders (overscan).

The output signals will be sent to other logic to build a complete NTSC signal.
Counters will also send their addresses to the Dual Buffer Video Memory.

I will probably build this along with the Chroma Generator to test them both.

Brad

I've been thinking about ways to do sprites and would love to hear your thoughts on it. It seems like you get to a certain stage, let's call it "Neo Geo", where hardware sprites with priority and the like take up so much silicon it's ridiculous. Then you have blitters... And maybe some kind of hybrid where it has local storage for one scanline and blits all sprites into it with microcode.

I'd love to hear your thoughts on the various options!

I have always approached Sprites the same way... with no restrictions on size.

One could actually start a heated discussion on whether my hardware actually fits the proper definition of Sprites at all, but I say it does!

Before I explain how my SpriteGen works, I should mention the hardware I am working with…

Media Memory : 4MB of SRAM made using sixteen 512K 10ns SRAMS paired together to create 4MB of 16 Bit Memory. Media Memory is exclusively dedicated to the Sprite Generator.

Sprite Generator : Dual programmable 9 bit counters, each made by chaining three 74HC163 counters together. The start count is set by the 6502, by writing data to 74HC574 latches that feed the load pins on the counters. Counters are capable of running up to 20MHz, although I may only get 10MHz bandwidth due to chaining propagation and reset sequences.

My Sprites have no limitation on size whatsoever. In fact, a game screen may actually be made from one massive 8192 color bitmap with dimensions as large as 4096 x 4096! Of course, the largest single Sprite I can write to the viewport would be 360 x 240, and even then it will end up with overscan.

To define a Sprite or Bitmap, the 6502 writes to several registers in the Sprite Generator…

- Source X : 12 Bit address to define the X location in MediaMem.
- Source Y : 12 Bit address to define the Y location in MediaMem.
- Destination X : 9 Bit address to define the X location in Back Buffer Mem.
- Destination Y : 9 Bit address to define the Y location in Back Buffer Mem.

The above regs are all latches that feed the counter Load Data functions.
Since my Color Space is 13 bits, I have 3 extra bits that are used to define the Sprites, and the control the following hardware functions…

- Bit 13 : Wrap X Counters / Clock Y Counters
- Bit 14 : End of Sprite / Reset Counters
- BIT 15 : Alpha Color, skip pixel draw

By using the 3 extra bits as microcode, the Sprite Generator will be extremely fast. Previously, I used 74HC688 comparators for X/Y wrap and Alpha, but only achieved 4MHz Sprite bandwidth. Yeah, that was still damn fast, but this time I expect 3 to 4 times that speed!

So that is my approach to Sprite Generation. I do this in hardware, and Sprites are fully alpha aware, so I consider them to fit the legal definition of what a Sprite actually is.

With even 8MHz counter speeds, I could easily fill 100% of the screen with Sprites 2.5 times over. Considering a typical Sprite of 32x32 pixels, that would be 152 Sprites at 60 frames per second, each with 8192 on screen colors. I bet VIC’s younger brother C64 will be a bit jealous seeing that!

So that’s my Sprite plan. You can see how it worked at only 4MHz and with 256 colors on my Vulcan-74 project…

https://www.youtube.com/watch?v=3fXuFCxMHVI
https://www.youtube.com/watch?v=XuzK2BwvmKQ

Cheers!
Radical Brad

Sprites are just cool. When I first got a C64 back in 1984 (I think) the hardware sprites were of great interest. I also found the raster line interrupt capability of the 6567 chip to be intriguing. I wrote some assembly code that would provide dynamic definitions to the sprites... effectively giving you 8 sprites per hardware sprite. The screen was basically banded into 8 groups vertically, so you had the 8 HW sprites defined for each band from a set of RAM based pointers and data to define them. I had this working very well and made up a simple demo showing 64 sprites on screen that also had simple animation by altering the sprite data during the interrupt routine that swapped out all of the sprite definitions.

I started working on code for software sprites, but I don't recall if I ever finished it... it allowed for 64 SW sprites with an 8x8 pixel size. I should probably dig out my old diskettes and see what I still have. In any case, I'm following your JetPack project with great interest.

_________________
Regards, KM
https://github.com/floobydust

Here is the Master Clock Generator...


All clocks derived from a single 14.318MHz clock

If the Sprite Generator is robust enough, I may try to go beyong 14MHz.
The Pixel and Burst Clock need to be synchronous, but not the Sprite Gen

Brad

As far as I understand the Neo Geo, it's fetching one sprite's graphics at a time, and drawing it painter's algorithm style into a 1-scanline "frame buffer" for effective priority. It's fast enough to do 96 per line, but it also has multiple wide dedicated buses out to cartridge graphics ROM, grabbing pixel/palette/meta data in parallel so there isn't much waiting around. That doesn't strike me as taking up egregious amounts of silicon, even with the additional features of linking sprites together into 2d sheets and vertical scaling.

Of course, if you had VIC-II style hardware with dedicated silicon shift registers per sprite, vying for realtime priority, that would be a vast ocean of silicon.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I like this description of what I am building!....

Fascinating. So how do you handle sprite priority, is it just fixed?

I really like the Neo Geo technique of everything being a sprite and having a huge number of them, but there were some limitations even back then. It could scale, but only to make sprites smaller, not larger. No rotation or anything like that, and no transparency.

I'd love to see a graphics system that combined all the best ideas from the era. Massive number of big, flexible sprites with the chaining function of the Neo Geo. Scaling and rotation like the SNES. Co-processor and blitter like the Amiga.

Priority on my system is simple... draw Sprites in ordered layers.
If I draw 300 Sprites, the first is at the bottom layer, last is on top.
Nothing else to it... just like dropping a bunch of playing cards!

I decided to have NONE of the goofy limitations of the 80's and 90's era systems.
I have no fixed dimensions, no size limitations, and Sprites have all colors (8192).
My Alpha Pixels are stored as microcode in the data, so speed will be amazing.

If I remember, Neo could do 384 Sprites in total, but at a max width of only 16 pixels.
My SpriteGen can do Sprites larger than the 360x240 screen, and has no limits on number.

I will probably also do some kind of box collision lookup in dedicated fast SRAM as well.

Brad

Yeah, I see, but what I'm trying to ask is how your hardware handles sprite priority at the logical level. Do you have some kind of loop that iterates through all enabled sprites, or is there a decoder that decides for each pixel which sprite to use?

There is no reason to handle priority at the hardware level with this kind of flexibility.

Imagine this pseudo-code, running on the VIC-20...



So there is your priority.
I lay down a 360,240 background, then the Player Ship, then the 150 Enemy Ships.
Whatever is drawn first (Background) is under everything drawn next and so on.
If I want the Player Ship to spin around under the Enemy Ships, then I draw it before Enemy.

The hardware does not care. It just sits ready to blast out millions of pixels from the Media RAM to the Back Buffer.

Can't imagine being constrained by having to "pre-define" Sprites like the C64 (or Neo on your case).
That would be no fun indeed, and the hardware would be super slow and massive.

Here is a 65C02 pushing out 1000+ Sprites using my Sprite Generator...

https://www.youtube.com/watch?v=GrsY4SpFpHs

This one was a prototype in an FPGA, so it's not as fast as what I am making on the breadboard.
I think it had a 4MHz bandwidth max, whereas I am now shooting for 16MHz!

Notice how all Sprites are prioritized?
That's 1000 individual Sprites, all layered by priority in code, not hardware.
How?... Just draw them in whatever priority you want!

Brad