6502.org

No. I just whipped that out of a fading bioelectrical memory bank that has been refreshed sporadically but hasn't been thoroughly checked for parity errors in 59 years.

For what its worth, I too recall reading that the mapping of the video lines had to do with saving hardware in the video decoding circuitry. The video refresh was used for the DRAM refresh as well but as Mike said, the order of the scan does not matter - you just have to hit them all within the refresh period.

My own experimentation with video on the SBC-3 and AVR used very wide margins from the NTSC/PAL standards and was non-interlaced. The displays however worked well with CRT and LCD composite monitors. Thankfully those displays are very forgiving of the margins.

Daryl

Aha, someone else who built video on an AVR... I recall that to get the timing right, I had a program which was almost always in interrupt, except for the bit after each active line for a few microseconds before a timer put it to sleep - so the next sync could be correctly timed.

Neil

Another video on AVR do-er here... I did it as part of my original 6502 project, but abandoned it.

I did have a look at many different "racing the beam" solutions including the early ArduTV thing. e.g. Things like the original ZX80 were ... "interesting" and potentially "broken" but they did seem to work for the most part.

I wanted graphics so rather than using a "rom" lookup for the font in an e.g. 1KB display buffer, I had a ~9K display buffer for 320x220 pixels, so 40 bytes per row. Took an interrupt every 64µS and used that to fill the SPI port with the bytes, polling for the free flag to load up the next byte. Used 2 output pins to get the correct voltage levels as per the ArduTV thing. It all seemed to work just fine and I could adjust the image left/right and up/down.

The biggest drawback was the lack of time left over to do any actual processing - hence some systems (ZX...) which did a screen flicker on e.g. character entry and just blanked during program runs. I think it was the ZX81 that introduced fast/slow modes which could keep the video running during program execution - at the expense of speed...

I latterly abandoned it - purely for the speed issues as the AVR was also acting as a serial interface and filing system for the 6502 but it was a good experiment while it lasted.

https://youtu.be/09zhGUbVxdU


-Gordon

My best method used a timer interrupt which put the AVR to sleep just before the the 64us line sync timer interrupt - that way, the response time for the line sync interrupt was guaranteed, so no jitter. When the sync interrupt comes along:

• start the line sync
• wait 4.7us
• raise line sync
• wait 5.5us for start of active line
• each microsecond, read the character associated with the line position, read the character data associated with the character cell line, and output that data - 52 times
• start the timer
• return from interrupt
• serial port processing until sleep at about 63.5us

It's a long time ago, but I think I initially I used an external PISO. I played with the SPI outputs but the chip I was using insisted on having a ninth bit before it could be rewritten, and that meant a white screen, or a black screen with lots of white lines

As always the biggest problem was not enough ram for bitmap... others used very similar techniques to provide lower resolution colour outputs.

Neil

The "trick" is to use an AVR with the 2nd SPI interface which doubles as a 2nd serial port. That one avoids the annoying 9th bit output.

-Gordon

Thinking about it a little -- the order of refresh does not matter at all. You just have to hit every row every 2mS (I checked the datasheet) -- you can even do it all at once, but usually it is done a row at a time spaced out evenly...

So yes, the Apple ][ memory layout has to do with saving a few gates, although I can't remember how it actually works.

I did figure it out more than a decade ago when I built an Apple ][ in an XC3S1000, my first biggish FPGA project. Getting video to look right at VGA scanrates was particularly interesting.

Did someone say AVR and NTSC?

This is ancient now, but how I did my AVR jitter free interrupt was like this...
This will synchronize the interrupt by delaying a number of cycles to make up for previous instructions that may have been executing before the jump. On an XMega, you need 4 checks, but only 3 on Megas. This works perfectly and does not require ay sleep function.

Here is this code running on an XMega-384 from a project I did 14 years ago. All sound and video coming directly from the single AVR - no other ICs used.
The burst was generated by resetting the phase of PWM, so it could output 16 colors and luma was a 16 bit DAC so the total is 256 colors...

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

And one on a Mega-324.
On this one, chroma is gate delays and luma is a 16 bit R2R DAC...

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

NTSC generation was always so much more fun than simple VGA!

Brad

But sadly your system refutes the European expansion of the acronym "NTSC" : Never Twice (the) Same Color

True, but it was close enough for my eyes!
When I told the sprite to be red, it looked red every time for me.
When you generate video using a $5 micro and 4 resistors, you can't expect perfection!