That's when the EOR function is useful.

I am using something similar to this routine, converted to assembly:

http://homepage.smc.edu/kennedy_john/BCIRCLE.PDF

See page 6 for the C code example.

Only requires * 2, negation, addition and subtraction. No multiply or divide and no trig or geometry. Quite fast.

Here's the QuickBASIC code I used to prove it works, and translated to assembly:



I also used this code for my graphics library for CC65 on SBC-3.

Daryl

EDIT - Added QuickBASIC code example

I have a huge amount of Flash so memory usage is not the issue. I'm up to 12% including all the font's so code duplication is not an issue.

I have already added the clear line, box, circle, and both fill's and yes, I do have a clear the screen. Forgot to mention it but it was the first routine I wrote!

Daryl

Sounds interesting, but I'm not sure I have the RAM to support that. At this point, this will just be simple graphics engine. The user will have to keep track of the "windows" and redraw contents on the host side.

BTW, my next step will be to see if the onboard serial shift register can be implimented to provide an uninterrupted bit flow for the composite video. The ATMega8 SPI register has a flaw in that you need a least 1 cycle in between successive writes. This is not a problem for text based graphics as the extra space between characters is not an issue. But having a gap every 8 pixels is definitely an issue for graphics. The ATMega1284's have a USART that can be operated in SPI mode that might not have that same flaw. That's first on the test agenda.

Daryl

I assembled the composite video output (two resistors and an RCA jack) and tested the USART in SPI mode. The timing works great - no more gap between bytes. However, the idle state of the MOSI output cannot be set using the typical CPHA bit. Instead, the USART idle state (high) gets set reguardless of the CPHA bit. This will not do at all. Even after trying to work around it by disabling the USART during the blanking intervals, I still get a vertical line just left of the active video portion caused by the 2 cycle delay between activating the USART and writing the first $00 output. No joy!

The easiest fix is to just add a 74HC165 shift register and do the shifting externally. Bummer.

Daryl

Hi Daryl
That sounds familiar - is this exactly what the fignition has? See this post and the picture on this page.

Edit: (As the glitch has totally predictable timing, would it be possible to suppress it using an output pin and an interrupt routine, and just some minimal external hardware?)

Cheers
Ed

How about using an external inverter on the MOSI output ?

Brain fade! I was supposing the whole scan line was somehow being sent without CPU intervention, so there's free time to jump in and fix the glitch with a simple external and-not gate which is only active just before the active pixels. But presumably in reality the CPU has to keep the USART transmit buffer full, and is quite busy already. I was also supposing a single external gate is preferable to an external shift register - maybe it isn't.

Edit: ah - I see you have a cunning timing fix - great!

Cheers
Ed

Yes, that's exactly the issue. Only difference is he's using a different AVR.

Last night, I decided to experiment with reducing the time delay from the end of the hsync pulse to the start of the USART. That effectively moves the entire display towards the left edge. I was able to shift the start to the left enough for the line to move outside the left edge of my screen. I then just added an extra 0x00 byte afterwords to keep the active screen data more centered. I won't guarantee the line is off-screen for everyone, but it is on my 22" LCD TV and my 5" mini LCD screen. Problem solved!!!

Daryl

That's a clever plan! Is it worth sharing with Julian (fignition)?

Cheers
Ed

Here's a quick demo:

http://youtu.be/xeZAqz3Xzjs

My usb capture device is not very high quality. The conversion plays a bit jerky. The actual demo is not jerky at all.

There are two artifacts that I see that might be issues:

1) since the screen data can be updated anytime the refresh is not in progress, you see "ripples" anytime the data is being updated as the refresh scan line passes it. It's most noticeable during text scrolling, especially the smooth scrolling down.

2) The pixels are not square. This is obvious when viewing the circles. They appear stretched vertically. On my LCD display, which has square pixels, the circles are round. As I recall, my old apple and C-64 tv screens also had this stretched effect. I am running the AVR at 16MHz with a dot clock of 8MHz. I then switched to a 14.318MHz oscillator (7.159MHz dot clock) to see if the stretching gets better. It did but not enough to matter. The demo was shot with the 14.318MHz clock.

Fixes for both issues would result in poor performance. If I only update screen RAM during blanking periods, then graphics performance will be too slow. There is not enough RAM to double buffer the display. To make the pixels square would require an even slower dot clock. This will reduce the 320 dot horizontal resolution.

Another issue is that I am unable to get the full 240 scan lines on the composite display. I currently have it clipped to 200 lines. I think I can get 220 lines and will experiment with that. PAL systems have more scan lines and should not be limited.

I may experiment with a 20MHz oscillator and 5 MHz dot clock to see if I can get a 256 x 200 composite display. This should square up the pixels and as an added benefit, would allow for a double buffered display.

So many options..... so little time.

Daryl

I PM'd Julian just now.

Daryl

I did some more experiments today. The 20MHz oscillator with 5MHz dot clock resulted in the pixels being too wide and the resulting circle was stretched horizontally. I then placed a 12MHz oscillator with 6MHz dot clock and that yielded a much better circle. As a result, it also clips the horizontal pixel size to about 280. So 280x216 (35x27 text) is about the largest size I can produce for NTSC composite video.

I forgot I was using 2k of RAM for the font so double buffering is still not possible unless I reduce the screen size to 256x200. For graphics, this might be acceptable, but that reduced my text to 32x20. That's below the 40 column "standard" of the old micros (An original design goal).

I may play with overclocking the AVR to 24MHz to allow for a clk/4 dot clock (6Mhz) and try to keep all the screen updates in the blanking/retracing periods to permit single buffering without the artifacts. The faster speed might be able to render graphics fast enough in the shortened window.

Otherwise, its back to the original 16MHz with the non-square pixels and 320x216 window. The LCD driver will still be able to run the full 320x240. I am still trying to locate a cheap supply of these types of LCD.

That's all for now. Will be working for the next 12 days straight so no updates are expected for a while.

Comments are welcome

Daryl

Hi folks,

That's interesting stuff - and getting a solution without any extra components is pretty cool. One of the alternatives I had thought about was to invert the whole of the display so we'd get:

Sync Video
0 0 = Unused, Don't care.
0 1 = 0v
1 0 = 0.3v
1 1 = 1.0v

I think it's possible to do that with a simple circuit involving 3 (or 4) resistors and a transistor, which is pretty much as complex as my 2 diodes and 2 resistor circuit. Here's the description:



However, it may be that there are values for Ra so that Rc and Rc might be the same thing:



I haven't tried to figure out the values of the resistors to make this true, but it's in the back of my mind. Can it work? Here, obviously the initial white pixel links straight into the video data.

However, I also see problems with this approach and the one where the stripe is moved off-screen. Firstly, off-screen. Surely to make it properly off-screen you'd have to put the stripe into the color-burst part of the display, would that be a problem? However (again) the color-burst needs several µs of a 4.43MHz signal which the stripe wouldn't provide. If it's guaranteed to be ignored then I think I'd try it; putting that part of the code into my sync generator; thanks very much for the idea!

Secondly, the problems with an inverted (i.e. true video) display occur for the same reasons, as soon as the hsync is done the output would be 1.0v which I think messes up the color balance on many TVs. It's a problem for example with the ZX80 video circuitry, a problem that perhaps a single pixel stripe doesn't have.

Sync Generation

I don't know if you guys are doing this, but on FIGnition sync generation is almost entirely automatic: there's only 1 interrupt for every section outside of the display area (top margin, bottom margin and 4 interrupts for the equalisation pulses) and this is possible because FIGnition uses the 16-bit timer to count those periods.

https://github.com/Snial/FIGnition/blob ... rc/Video.c

Libby8

But I think you have an exciting project, hooking a classic CPU to an MCU for video. Would your AVR also be able to boot your CPU and act as the I/O glue logic too? I think these things should be possible, it'd enable a computer to be built with nothing more than an 8-bit CPU + MCU + SRAM + Flash storage. In Libby8 for example, the MCU has no control of the address bus, instead it boots the CPU by resetting it; disabling the Sram OE (most of the time) and then feeding the CPU with the equivalent of:

.byte 0,0 ;pretend reset address is 0, but it doesn't really matter.
LDA #ROMByte0
STA ROMAddr0 ;MCU relinquishes the data bus for the store itself.
LDA #ROMByte1
STA ROMAddr1
etc.

instructions and finishing with a JMP to wherever the ROM should really start and enabling OE. A 16Kb ROM could be copied in about 1/8th of a second (6 or 7 cycles/byte).

Of course it wouldn't be compatible with any 80s computer, but that wouldn't be my goal:

https://sites.google.com/site/libby8dev/libby8/concept

apologies for contaminating the site with a Z80-based machine, but I figure the concept transfers to a 6502, 65816 (and 68000 too, which is also still available).

Keep up the good work though, it's a great thread, I had noticed it a little while ago

-cheers from julz

Hi Jules,

Good info. I considered placing a CMOS inverter on the data output and the pixel generation logic would just be reversed (0= white, 1=black).

This is the NTSC timing I'm using. Reference this app note (1/2 way down):
http://www.maxim-ic.com/app-notes/index.mvp/id/734

The blanking period, which included the front porch, hsync, back porch with burst, is 10.9us. My sync pulse is 4.56us wide and the the USART gets turned on at ~10.833us. This is on the tail end of the back porch and after the burst window (just barely). Since this is a monochrome display, I am not generating any burst signal. Most NTSC TV's can handle this as they were designed to be backwards compatible with the B&W video standard.

I have not re-looked at the PAL timing yet. My previous projects supported PAL but I cannot remember all the differences. There should be a point on your back porch that would work too. Unfortunately, my multisystem TV died last year so I have no way to test it anymore.

My AVR solution uses a 16 bit timer to time each horizontal line. There are two interrupts (using the two ouput compare registers), one just prior to the end of line, which puts the MPU to sleep. Then, a few cycles later, the second IRQ fires and drops the sync pulse. In this way, the actual IRQ response time is always the same. The rest of the points (Hsync end, left edge, and vsync end) are derived from the timer. through simulation, I can prove that every line has matched timing.

The three VSync lines sets the first IRQ a little sooner then exits. When the IRQ fires, it raised the sync pin, then sleeps. Also, blank lines exit as soon as the hsync is raised. Both actions allow the MPU more time for the main program.

Sounds like your system uses the Interrupts very efficiently as well.

I had not planned any bootstrapping with this device. Instead, it will have several methods of interface to the host device.

Cheers!

Daryl