OK, no worries -- I was mainly just answering the thumbnail question. I wasn't aware that other forums take off-site images and create thumbnails on the fly. But I did notice you're hosting the images on your own site.

The second paragraph of my post wasn't directed at you specifically; it was a reminder to everyone. No need to use third-party image-hosting sites.

Looking forward to seeing your blog when you publish...

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Nice project, I sure missed a lot while I have been away, stuck in the Matrix of the "real world".

Yep, I am AtomicZombie on all other forums. Not sure why I chose to use this username here!
Let me know if I can assist with AVR assembler / video in any way... that's my thing.

You may even consider an XMega, it has 32K interal SRAM and can easily bit bang full color, even NTSC.
If you go with 16 colors, you could even double buffer a VIC-20 sizes screen at 176*184.

Look forward to seeing more of your work.
Brad

Thanks.

I picked the ATmega mostly because through hole. I've also been through a few iterations of my design and ideas since then, so I'll be sticking to the original monochrome video I have, although I'm going to consider it "optional" - mostly because it slows other operations down - the ATmega is now running the filing system, serial keyboard and some other stuff too.

I still have some timing issues - it generates a rock-solid image on my modern multi-input portable TV, but it wobbles a little on an old analog monitor - I think I'm suffering from a 1 cycle jitter issue which I've seen fixed up in some ASM code, however my generator is 100% C code right now. the TV (capable of 720p with HDMI, composite, uhf, scart, etc. inputs) probably samples and stabilises it. It's not a big issue in the grand scheme of things, so my thoughts are that the SBC is really a 6502 with serial interface, and I have a separate "graphics card" planned (a $5 ARM based computer) much like some of the early system had separate boards for other "stuff".

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Yes, that 1 cycle out of 500,000 / frame is always enough to cause jitter.

If you are using GCC, you could code your interrupt in ASM and then use the Jitter Fixer code I posted at AVR Freaks. You could even call your render loop from there if you prefer to stay in C.

Here is an example from a VGA video game system I did for an Atmega-328.
The ASM side handles the interrup entry here, including jitter fixer...



Instead of rendering the frame here, you could always boot out and just call your C driver instead.



I based my timing on this one for 640x480 @ 60Hz...



Here are the timer settings...



Being a 328P, it overclocks to 40Mhz (32MHz safe margin), so there is a lot of headroom for graphics!
The 1284P is a better choice for retro BW video though, as it has so much internal SRAM.
Sadly, the 1284 will not run safely beyond 25MHz.

Here is a quick NTSC Timing Calc I made that allows you to try various clock settings...

http://lucidscience.com/temp/ntsc.exe

It also keeps to the burst multiple in case you ever want to do color.

Brad

Thanks - I'll check the code snippets shortly - I've not done any AVR assembler, but I think the idea is that you take up the jitter by waiting until the timer low value is at a fixed value appropriate to your video generator...?

I'm using an Atmega1284p clocked at 16Mhz. video resolution is 320x240x1 - PAL composite output.

I use T2 to generate an interrupt every 16µS. The video shifter uses the 2nd serial port in SPI mode and PortD, bit 4 for sync output.

Other than the jitter, the issue is that leaves little time to do anything else - so out of every 64µS, I'm clocking out 40 bytes which takes 40µS (SPI clock is 8Mhz) plus a few more for back/front porch, etc. I do get a good number more free cycles at the start & end of each frame when outputting blank lines and vsync. Overclocking would help, but I've never been a fan of really pushing the limits (says the guy with the 16Mhz 65c02 on stripboard

Couple of videos:

https://youtu.be/09zhGUbVxdU

https://youtu.be/1Iv-bDmkW2M

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

It looks great so far!
Sounds like you just need to ditch that lattency and you are good to go.

My Jitter Fixer reads the low byte of the timer used to generate the interrupt as soon as it is entered.
Since we know that any AVR instruction can last between 1 and 4 cycles, this is the error that needs to be corrected, as we cannot know which instruction had just completed before the interrupt triggering.

So we compare the low byte of the timer to the expected "best case" value, which in the case of my posted asm snippet.
14 cycles represents the total of all cycles rquired to get to the actual compare being done...



From there the differece between a "true" compare state and "false" compare state ballance out the lost cycles.

I have defeated Mr. Latency on an AVR 2 other ways as well, which may be more C friendly...

1) Keep your graphics loop quick enough to not last more than one frame and then issue a sleep command.

This will put the AVR in a known state so that there is no cycle imballance when entering the interrupt.
The difficlty here is that you are almost "chasing the beam".

This old demo of mine does that...

https://hackaday.com/2018/03/08/racing- ... an-attiny/


2) Use a second timer and compare the value before your sync is issued.

Similar to the balanced delay of reading the actual interrupt timer, you do a short delay based on the value of a second free running time that is initially reset in your startup code. The issue there is a wasted timer, and that the C compiler monkey may optimize your delay loop out.

I can certainly take a poke at your code sometime and see what I can do.

Just for eye candy and possible future color expansion ideas of your project, here is an XMega managing 256*240 with 256 colors. All video generation is done in software with no external help. All graphics and audio jammed into program memory...

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


Cheers!
Brad

OK, so I added this into my video generator right at the start of the ISR:



and it might have worked if I'd not appeared to have made a slight error on the PCB and I've transposed to pins on the ATmega side of things. I may give it a go back on my stripboard version, just to prove that it works, however doing this reminded me of how many cycles on the ATmega I'm losing and how much RAM that I'd been using as buffers and a ramdisk for my filing system. Recovering those pins will let me use I2C and an SPI bus too.



There is no real "graphics loop" - once the 6502 is booted, the ATmega is sitting in a tight loop, waiting for the 6502 to send a message then it executes the command - serial out, draw a line, open a file, write data, ...



It looks good, but I'm really going to use a bit of a blob for colour graphics - a nice little $5 system that I've been using for a number of years now so I already have some nice graphics and gpio code written for. All I need is a bus interface with level shifters (it's a 3.3v device). This is a solved problem though.

So my 6502/65816 will be piggy in the middle with the ATmega doing disk IO, serial, I2C, SPI on one side and the tiny little $5 SBC on the other side doing screen, keyboard & mouse .. Not much different to using the TI99 system, a microcontroller, that fancy RAM, or an FPGA solution really...

Cheers,

-Gordon
(edits to fix the quoting)

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Look forward to seeing the progress.

You may need to tune the compare value since you are using inline.
If you are patient, just start at say 10, and work up until all jitter is gone!

Brad