6502.org

I suspect it's the latter. Lower bandwidth for chroma is a good match to the human visual system - we don't need every pixel to have a different colour. Some nice optical illusions make use of this. (See also Bayer filter)

Bit of both. The spec says that the colour signals shall be bandwidth limited to that value. The intent is that the colour information doesn't take up too much of the bandwidth of the overall system. There has to be a notch filter in the luminance signal to avoid luma information of the correct frequency being decoded as false colours - you've probably seen horrible crawling yellows and blues on checked or striped clothing on old TVs.

Another reason though is that it doesn't need to be any greater bandwidth; the human eye is very good about telling different colours apart, but not in noting exactly where these colours are. Since bandwidth is equivalent to the size of a coloured blob on screen (horizontally), increasing the bandwidth doesn't do anything for the picture other than increasing the cost to transmit it.

There's a good link here about how the frequencies were selected for NTSC to fit everything in the 5MHz bandwidth without causing nasty surprises. https://msys-mv.blogspot.com/2011/01/wh ... uency.html

But as Samuel Johnson said (of dancing dogs) the wonder is not that it does it so well but that it does it at all.

Neil

That part of the explanation helped. But the Atari 800 had over 256 colors, so they must have incredibly fine control over that phase delay.

Two ways to do that: either, as you say, very close control over the phase delay, or more likely, RGB output and an analog NTSC coder.

e.g. https://linearparts.com/documents/ASTEC ... e_Info.pdf I think that one is NTSC

Neil

A most impressive hack was the way that Sony avoided the license fees to use the default PAL decoder: rather than referring the colour burst phase, they observed the eight-field frame sequence... and derived the correct reference phase from there.

Neil

I wanted to share a technical victory I just had on this project: I've finally designed the IDT7007 dual-port SRAM out of the system by replacing it with a pair of single-port SRAMs.
My solution takes advantage of one side being read-only: Writes immediately take effect on the "system side" RAM, and the data+address are latched. This write will then be mirrored onto the "video side" RAM chip when the video circuit isn't busy reading.

This was actually somewhat tricky, and my initial prototype didn't work because at first I tried performing the write on the opposite phase of my pixel clock that latches the current color. Unfortunately I'd forgotten that the pixel latching signal is suspended during blanking intervals, so the writes during that time weren't going through. I ended up hacking in a shift register to create controlled delays of the pixel clock, and OR'ed together the original with a delayed copy to determine when it was safe to perform the copy.

The 7007 wasn't the only dual-port RAM I was using, but I found a drop-in replacement at a good price and enough quantity to make quite an absurd number of GameTanks. I think I'll still try to solve that puzzle as well, though it'll take a bit more research as my approach to share a single RAM between two busses using a FET switch didn't work at 3.5 and 14MHz.

So, you had one pending write for some small number of clock cycles? Something like a writeback queue, but very short? Nice idea!

Indeed! The access pattern is highly regular. The clocks involved are small number fractions off of each other, so there's only really five potential offsets between a data write and a pixel read.
For arbitrary usage rates it might need a deeper FIFO, but in this case the mirror writeback is faster than writes can happen so only the one queued element is needed.

Very cool!

What are the chips sitting on the bodged in breadboard? The two SRAMs and the shift register? (I've never used DIP SRAMs before so whilst they look physically small to me I don't have a point of reference).

The SRAMs are already on the board, I had orderd a PCBWay assembled prototype of my RAM replacement scheme but forgot about certain conditional clock suspensions. The chips in the breadboard are the shift register, a 74HC32 OR gate, and a 74HC04 inverter. Besides power and ground the connecting wires expose my 28MHz clock, the pixel clock, the latch signal for outgoing pixel color, the load signal !OE for fetching that pixel from RAM, and a masking signal for writebacks.

At first I'd gotten it working just using the inverter for delays, but when I swapped in different inverters from my bin the variation in prop delay was enough to break the timing. One chip would give a delay of 50ns while the other only 25ns. Which makes sense, the datasheet gives a range from 8-16ns and I was stacking all six.

Glad that you are making progress on the GameTank! Does this solution cost less? Or was there lacking inventory on the dual-port RAM?

Do you hand solder each GameTank yourself? Even the surface mount version?

Saw one of your latest videos on the GameTank Youtube Channel, I love the camera work and audio 'features', hilarious Keep them coming! Promoting your channel here: https://www.youtube.com/@gametank-console It seems you have more subscribers than me already, and way more views on individual videos! I probably aught to stop the teaching and posting math lecture videos, and switch over to homebrew 8-bit game development full-time

Thanks!

Chad

The dual-port RAM got hard to find anywhere but AliExpress, but it also does cost less to do it this way.

I've been letting PCBWay solder the surface mount GameTanks. It takes me a whole focused weekend to do the through-hole version, and my error rate with hand soldering this pitch of SMT is so high it would probably take a whole week to do one.

Though lately I've been considering the Lumen PnP machine to speed up my prototyping process.

More updates- finally started the crowdfunding campaign on Crowd Supply (basically Kickstarter for open source hardware)
Campaign:
https://gametank.zone/crowdsupply
Announcement video:
https://youtu.be/Zg9weWX294c

Still waiting on one more board revision from PCBWay to send off a representative unit for EMI testing. I'm gonna try sending it to Sunfire Testing, who gave a rather modest quote AFAICT for FCC SDoC and CE testing.

Which regions will you be certifying for? As I recall, there were slightly different requirements for different global regions, and meeting all of them (for our commercial product) was a real head-bender... and not cheap.

Neil