There are many tricks that can be used to get more video bandwidth, and when this project is done, I will finally launch my 2 websites (AVRCade.com and Vulcan74.com) to show the multitude of graphics and games systems I have made from just about every processor available.

I will also be collecting and detailing projects that others have made, and hope to grow the sites into a huge community of Audio / Video Retro Hackers!

One of my favorite tricks to double the bandwidth on a processor bit-banging video is to send the clock directly to the LSB on the memory.
Since I always split my address into X and Y, this gives the horizontal line twice the speed.
An example would be an AVR pumping out addresses to SRAM. Since AVR needs to instructions (2 cycles), it can only manage 10MHz bandwidth.
By counting out bits 1-8 from the AVR while the clock simultaneously toggles bit 0, yo get 20MHz, and up to 512 horizontal pixels.
I did this on an ATMega324 many years back.

Although I don't want to get too far into all of this here, another trick (since shift registers were mentioned) can give you 256 colors for nothing.
Instead of just banging out the serial stream as mono color pixels, send the serial output to the OE of a latch.
Now you just load the latch with some value before the horizontal render loop, and you can draw characters with 256 colors! No overhead!

Anyhow, I have more than 20 completely documented Video Game Systems and Audio projects to detail on these sites. (15 years worth!).
Everything from 555 timers doing NTSC to FPGAs bit blasting HDMI! I can't wait to build a community and learn some new tricks!!

I will probably keep my mind active by coding my ATiny project until the new year, as I am away from my lab a lot now.
The ATiny project (Quark-85) packs into a 6 inch box, so it can come along with me!
When my life settles again, I will be working on Vulcan-74 with a vengeance.

Thanks again to all who commented and offered advice, this is a great community!

Cheers!
Radical Brad

I'm glad I'm not the only one who takes a little project on holiday with him!

I had an idea for a crazy video generator. Instead of bitmaps or tiles, run-length encode the display. It would be ideal for flat shaded 3D graphics like the Hard Drivin' era Atari stuff. Each scanline would be encoded as a series of colour+number_of_pixels pairs. Output code would just jump to the right place in a long strong of NOPs to create a row of pixels of the correct length. The only slightly tricky part is handling the end of the scanline, but you could do it with another interrupt that just changed the return address on the stack before returning.

Reminds me of C64 speed code. You could actually do it as self-modifying code if your MCU supports that.

Yeah, if I am not coding or laying down chips for at least an hour a day, I start to become sane, and that's not good!
Some like to watch TV to relax, other like to Design TV to relax!

Your RLE idea is a good one, and it does work well!
I did this in an ATtiny-45 once as the main driver, and in my current ATiny85 system, RLE is a storage option, with on-the-fly unpacking.
I use the following format... Start Position (8 Bits), Length (8 Bits), and Color (4+4 Bits).
Color only needs 4 Bits, so one Byte covers two lines worth for color.
This is great for packing solid shapes with minimal memory.
SpaceBalls Demo on an ATiny Processor anyone??

The Multimedia Converter I wrote for Vulcan also allows packing as RLE, with 1,2,3,4, and 8 bit palettes available.
I will post this program when it is more refined. It writes C or ASM data for any toolchain.

For those that want to mess around with bit-Banging VGA, here is a simple Timing Generator I wrote...



Download the Visual Basic EXE...
http://avrcade.com/temp/VGA.exe

It lets you alter the Pixel Clock for various standards to calculate Timing needed to keep close to the VGA Spec.
Default mode is the proper 25.175MHz Pixel Clock for the 640x480 @ 60Hz standard.

I plan to redo this program as well, and make it do a LOT more.
It was just a quick hack to show timings, so don't expect too much out of it!
The "RS" button Resets the timing to the proper spec for each standard.
The "HZ" button changes scan rate for some modes, but I plan to remove it, as 60Hz is all that is needed these days.
The "DV" numbers are what you get after dividing the clock. DV2 means your uC can set the address once every 2 cycles max.

For those just starting out in VGA signal generation, here is a legend...



You can safely "fudge" the timings a bit by stealing and borrowing from the Porch area, but try to keep totals exact.
Older CRTs are more fussy, and newer LCD's can lock down as low as 53Hz sometimes.
I prefer to count every cycle and follow the standards exactly.

Cheers!
Radical Brad

Nice! Those old demos are a constant source of inspiration for me. I really like when some seemingly small and almost trivial feature or hack allows you to do incredible effect.

A good example would be the rotozoom things in a couple of Sanity demos, most notably Roots. Others had managed to do them at lower resolution using a copper chunky display or something like that, but Sanity found another way. They realized that with a carefully selected small tile and carefully crafted bitmaps they could render a plane rotating on two axis by just poking the bitmap pointers and adjusting the colour palette on every scanline. As far as I'm aware no-one else ever managed to copy it.

I love palette based graphics, BTW. There are so many cool tricks you can do with a separate palette.



Thanks, I'm going to play with it...

Dr Jefyll, on this sort-of topic, I came across your post here: http://anycpu.org/forum/viewtopic.php?f=20&p=43

I like the idea of board. Would you be interested in publishing full schematics? Make a PCB? I have a few HD6309s lying around here. It'd be neat to build.

Even more interesting would be to replace the 6809s with a couple of 65c265s clocked at 8mhz? Or would the dual porting of the SRAMs not work as well with a higher clock rate?

Yes, this design uses the common trick of running memory twice as fast as the CPU so that video accesses occur transparently. What's unusual is that the video section is simply another CPU. This design was my second cheap-video machine!

Hah! -- the notion of a 6309 remake occurred to me, but I have too many projects already. Still, if there's any interest I'd be happy to advise, and maybe hash out a first-draft schematic.

The original schematic used 64Kbit DRAMs -- which were cutting-edge at the time! -- but of course modern SRAMs have far surpassed that density, and SRAM is much easier to work with. So I'd drop DRAM from the design, which means multiplexers become optional. I'd prefer to eliminate them altogether, and have the two processors do the memory-sharing by tying the RAM directly to both CPU buses. The Phase1 period for one CPU would be the Phase2 period for the other, and each CPU would have its BE input de-asserted during that CPU's Phase1. Hmmm, maybe have a brief, intervening anti-glitch "dead time" during which neither CPU's Phase2 signal is active.

Does the '265 have a pin that can function as a BE input? I haven't the patience to comb through that darn datasheet right now. As for clock rate, I'm sure a pair of 6309's could be made to work at or near their rated maximum. (3 MHz, is that right?) Modern RAM's could easily do 6 million accesses per second. I'd worry more about whether the BE inputs respond quickly enough -- that might limit clock rate. Ditto with a pair of 8 MHz 265's. The RAM's could do 16 million accesses per second, but there's the question re BE. If BE won't work we could reinstate the multiplexer...

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

65c265 has BE and RDY. Same as 816 it seems.

And also a special interrupt driven "parallel interface bus" specifically designed for multiprocessor systems. Badly documented.

Sorry for "unexpectedly bumping in":
Reading this thread since a while,
and I have to say that Oneironaut has a very impressive project going here.

I never found the time to dig into generating color or high resolution video signals...
my projects mostly had circled about getting a CPU up and running and such.

My last CRT\LCD project was here: D04
It only displayed just 40*25 monochrome text and 320*200 monochrome graphics,
mixed together with XOR gates.

Video address and sync signals were generated by a lookup table inside
a 27C512 EPROM, with a 15 Bit counter at the EPROM address lines.


What made the (somewhat simple) design of D04 a bit big was,
that the CRT\LCD controller "mirrored" the CPU RAM write cycles into its own display RAM.

D04 passively "snooped" the 6502 bus for write cycles to 0x0400..0x7FFF,
stored address and data of such a write cycle into latches,
and wrote the data into its own display RAM later.


Background is, when ignoring the stack area at 0x0100..0x01FF in memory,
there are no two consecutive write cycles on a 6502 (not 65816 !) bus.

The "worst case scenario" would be code like

Where one 'STA abs' has three read cycles, followed by one write cycle.

So when keeping address and data of CPU write cycles in latches,
and D04 only is able to write into its own display RAM at 1MB/sec.,
it becomes possible (in theory) to run the 6502 CPU at up to 4 MHz.

Would be interesting to know, how fast a CPU could go when using a FIFO
instead of a latch for holding address and data of CPU write cycles...
...it's just a thought.

Holiday greets to all!

Some time in Feb, when I have time to be in my workshop again, progress on Vulcan-74 will resume.
Looking forward to finishing up the Sound Generator, and then starting on the hard wired version.

To keep sane, I have been coding a Video Driver for a small AVR.
Sometimes you need a project that will travel!

Cheers!
Radical Brad

https://www.youtube.com/watch?v=yXhaw3-3eWA
The Quark demo is fascinating!
I like the smooth motion and the fine control thrust.. Kudos!

Thanks!
I liked the Quark Video Driver so much, that I gave it a new home in a different AVR.
Now using the ATMega-328, which is the same one used in an Arduino.
Still pushing it at 36MHz, and doing 184x160 VGA, but now it has 128 colors and much better sound.
Will mess around with this one while I still need to be "portable".

http://www.avrfreaks.net/forum/quark-32 ... atmega-328

Have a great New Year!!
Radical Brad

Happy New Year to you too, Brad!
Your concepts are revolutionary and truly Lazarus-ish

I find it more challenging if it’s to design a discrete logic actual hardware sprite engine with much less amounts of RAM, with all priority flags, XY flipping, tile indexing and all that..

Of course it’s very top-notch skill to redefine this work using multiple frame buffers.. However, the pinnacle of the 80's was to make a definite rendering pipeline using the basal amount of SRAM..

A lot of earlier 3d software renderers did something like this, and it's typically called a "span buffer" or sometimes "s-buffer", though the latter name has a lot of more recent overloads. There should still be lots of reference material out there for that style of rendering.

(Specifically referencing Hard Drivin', that did do 50% stippling on some of its polygon fills, so the buffer would have to be able to remember another layer or two of active spans to dither between them.)

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

It looks like there is one available on eBay now:

http://www.ebay.com/itm/-/301853927333

But it isn't cheap...

Hopefully, that wasn't one of the originals from the famous "jar" of first runs that were for sale.
Only the top layer of chips worked as legend has it!

Brad