What is needed is an MCU with 6502 compatible bus capability, but the only ones I found can only be bus master for talking to LCDs...

In addition to following David's project I've been wrestling with this for months myself on my own project. I've looked at CPLDs/FPGAs, Propellers, AVRs...there are a number of options with various trade-offs. In the end I've more or less settled on a Propeller on this iteration, with 80 column text and maybe some low-res graphics. The nice thing about the Propeller is that there is actually enough horsepower to run VGA, audio (SIDcog), PS/2, and SPI, with cogs to spare. The only limiting factor I've run into is available I/O pins.

Down the road I intend to finish my CPLD-based video project, which provides text & graphics with a directly-addressable frame buffer. The plan is to have a single expansion connector on the new SBC so that I have a platform for testing my designs before committing to building an entire SBC around it.

You are correct. The VS23S010-D is a nifty little chip, and there IS enough bandwidth to do full screen refreshes at 30 fps if you wanted to directly from a microcontroller, but it's typically not necessary. Just copy the changes to the display memory and that's it. There is even the ability to program interrupts for any screen line. I am using an interrupt that is generated at the end of the last display line, given me an interrupt when the vertical blanking area starts. This prevent "tearing" when I copy the entire 16bit color 320x240 buffer during the vertical blank period. I am using this chip for outputting composite video from a thermal imager. I use the off screen area for the font data and I can block copy the font characters as a simple OSD on top of the normal video data.

There is already a 2D gaming system called "BasicEngine". It uses the ESP8266 Wifi module along with the VS23S010-D chip for the video. It's open source. You should check it out to give you an idea of what is possible. The setup uses SPI only for data transfers and it's basically realtime. I use the parallel transfers.

This looks very interesting, ideal in fact: https://github.com/maccasoft/propeller-graphics-card

Just needs modifying to use the 6800 bus instead of the Z80 one.

Yea, I don't doubt the chip itself, I was doubting whether a 6502 had enough oomph to drive a display like that. Or, rather, how fast a CPU would need to be to effectively drive a chip like that.

What micro controller are you using? How fast is it?

Thinking even more (always dangerous), especially today, the idea of "poking" in to screen RAM is really the anomaly, I think, even historically rather than reality. Especially today when everything is being run by GPUs and talking high level protocols and object (rectangle, lines, circles, etc.).

I (foolishly!) decided some 8 years ago or so that I wanted to write what I considered to be "my" BASIC interpreter - so set about doing so in C under Linux. At that point, while I'd been using Linux since day 1 and Unix (with and without X windows) since {mumble} and having worked for 3D graphics companies, and a PC games company, I'd never written any graphical or X windows programs under Linux/Unix... So working it all out was a bit of a challenge. I settled on a library called SDL which is ostensibly cross-platform, however what it gives is a buffered "poke pixels at the display" type of interface. So I poke pixels into it then call an "update" function which magically blits the software framebuffer I have to the real screen. It can do this very, very fast - even on a Raspberry Pi without using the GPU.

Of-course after doing it, the cool kids told me I was doing it wrong, however it worked very well for me (and still does today), but I know it's "wrong".

Or is it?

I think it's a matter of perception and having my own little 2D graphics library (the usual stuff, lines, clipping, shapes, circles, polygons, sprites, etc.) has done me well for many little projects involving bitmapped displays on Pi's, Arduinos and so on. I also like turtle graphics...

But today... We want (or think we want) more pixels, more colours, higher resolutions... But we only have an 8 or 16 bit micro running at 14Mhz (if we're lucky) and without some sort of hardware assist, going above what's effectively composite video resolutions starts to become hard - in terms of hardware and getting the software fast enough.

Stefanies Foenix has a 640x480 VGA output with 8 bits per pixel. To draw a diagonal line from one corner to the next means putting down 800 pixels while calculating Bressenham in 16-bits. I don't know if her FPGA is doing the basic drawing (in addition to tile and sprite handling), or the 65816, but if it's the 65816 it's going to be visible.

And I've just seen someone ask: Will it run Doom on 8-bit Daves Facebook group (and I'm sure this will be asked again, and again, and ...)

The way round that is to say: What do you want to draw a line for? Use a paint program to design background tiles and sprites instead. Maybe that's it. It won't give me my turtle graphics though.

The VS23S010-D is a nice solution - it's effectively memory, can be pixel poked (via a peripheral bus interface), but also has a fast 2D memory move engine. (aka blitter) but could a 6502/816 drive it? I think so - more-so if you look at some of the C64 stuff from the "demo scene" people. Even Apple II which is also a 1Mhz 6502 and BBC Micro which is a 2Mhz 6502 has had some fantastic games and demos written.

We have a modern 65C02, fast memory to match, a multitude of graphics options.... Just write the code

-Gordon
(but will it run Doom?

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

In my experiences, when the cool kids tell me I'm doing it wrong you can pretty much bet I'm doing it right. Or, at the very least, DOING IT. Many times the cool kids just spew out what they read in an effort to look smart and sophisticated.

I say march on and do it your way.

I still format my code to 80 characters. On my widescreen monitor. Why? Because I like old standards...and get off my lawn!

_________________
Cat; the other white meat.

It's just so easy to say "will it run doom" on any thread about retro graphics. It's boring, it's almost trolling. The point of Doom was that it pushed a particular platform quite hard. Any given platform will afford ways of writing some games with ease, and will be capable of being pushed to support other games. And yet other games will be forever out of reach.

If you happen to have a large bitmapped display and a comparatively slow processor, and you want an interactive responsive graphical game, just design and implement a game which doesn't redraw the whole display.

And indeed, if you're designing graphical hardware, you'll be making choices and tradeoffs: TTL or LSI or CPLD or FPGA, memory mapped or command port or display list, pixel planes or chunky pixels, colour maps, sprites, blitter.

There's not much point looking at an implementation and calling out whatever it hasn't got or can't do. There's bound to be something. How about looking at the implementation and seeing what it can do? See how you can push it.

Well, they are just killing any suggestions now, looks like they are going with the crappy Gameduino with an SPI interface. Hardly very C64 like. I guess that project is a write-off, it's going to suck.

Still, freed from the limitations of it, I'd love to see a system based on a better chip. Maybe a good project for me.

It's a good thought: if there's a particular system you'd really like to see, build it!

I am using a 70MIPs PIC microcontroller, but I could use a .1 MIPs CPU to do the same thing. That's the great thing about this chip. It's just a frame buffer that you place data into. The chip handles everything else. A 1MHz 6502 is plenty fast enough to do this. How fast can you write bytes via a parallel interface? That's really what's going on.

I am behind Stefany's Foenix project (I will be developing the disk drive code and such for it as soon as I have one of the new prototypes). One of the FPGAs (there are several) is a graphics engine. So you will just poke a buffer and the data will magically appear on the screen, much like the VS23S010-D chip.

You can fill a pool with a drinking straw. I don't doubt you can move data to the chip. But as Gordon mentioned, drawing an 800 pixel line on a display, pixel by pixel, is expensive. On a 70MIPS controller, I have "budget" to do that, on a .1MIPS CPU, I don't.

Just using a raw dump of X, Y, Color, 5 byte (16 bit X and Y + 1 byte color) * 800 is 4000 bytes. And grabbing a random block move routine from the web get a very aggressive 13 cycles per byte (which doesn't include extra stuff for moving more than one page). That alone is 52MS on a 1MHz 6502. That's basically 2 frames at 30FPS just to draw one, pre-calculated line.

I don't know what resolutions the chip can drive. I know there seems to be a lot of video RAM where you can pre-load a bunch of textures and blit them around cheaply. But beyond moving pre-loaded block around, things get really slow, really fast. And that's over the parallel interface, much less an SPI interface - especially a bit banged one. Oh. My.

There's a reason that 8 bit machines are comparably low resolution. Where folks worked with frame buffers topping out at 8K of RAM (which would cost 4 frames to fill...).

Watching a 1Mhz 6502 trying to fill up a 640x480 pie chart would be a painful process indeed.

The single most important feature to include in a video display intended for 2D gaming is the ability to scroll, both horizontally and vertically, without having to copy the pixels around. That allows implementing a big playfield and moving rapidly and smoothly through it, while only having to draw at the offscreen edges and to update sprites moving within it (which is a much more tractable problem).

One way to do that is to slap down one of those 2MB EDO DRAM chips, which have 1024 rows and 1024 columns of 16 bits each, as your framebuffer. For each scanline of the display, you store somewhere convenient a row number and starting column number within the DRAM. Just before the display area begins on each scanline, you activate the correct row of the DRAM, load a 10-bit column counter with the starting column, and just increment the column address for each pixel (or pair of pixels, if you're doing 8-bit output).

These DRAMs are fast enough for SVGA resolution at 8bpp; you'll need a buffer to convert each 16-bit word output into a sequential pair of 8-bit colour codes, and some sort of CLUT to convert that into RGB values. You'll also need to do some refresh circuitry (perhaps triggered by the hsync signal) and provide some way to write to the DRAM (when it's not busy with scanout).

You can do a lot of clever effects by manipulating the row and column addresses independently - effects which many demoscene productions rely on, but have to brute-force the video hardware into doing by "racing the beam", but which this hardware design would support natively. You could even include a pointer to a different CLUT for each row, and/or a different front and back porch definition to make some rows cover only a small part of the display. Note that the column addresses wrap around seamlessly, instead of spilling onto the next DRAM row, which probably makes some horizontal scrolling scenarios easier.

If you then repeat most of that hardware and use it as high bits of the CLUT, you can have an independently update/move/scrollable overlay, supporting all of the fancy effects the background layer does, with many potential applications:

• Static text which doesn't interfere with scrolling the background behind it.
• A mouse cursor which can be moved without redrawing the screen behind it.
• Sprites which can be moved around by erasing their old positions instead of redrawing the background under them.
• Complex framing, such as a gunsight or periscope, which doesn't interfere with drawing or scrolling the playfield, and even supports alpha blending (with a suitably chosen 16-bit CLUT).

I think you can do a lot with hardware like that, with relatively low hardware complexity compared to a true sprite system. You might not even need an accelerator or blitter per se, though you will need to contend with the long periods in which the DRAM cannot be written to because it's busy with scanout.

Two lessons that I learned from the Amiga's shortcomings, specifically for gaming scenarios:

1) Bitmaps are static. (The hardware can pan them, but you're not going to get to animate/update them much, even with the blitter.)
2) Bitmaps have low color. (Tile based systems select a palette per tile, so 2- or 4-bit graphics can still have dozens or hundreds of colors in multi-tile objects, instead of sharing 4-16 across an entire bitmap.)

While palette tricks can mitigate these to some level, bitmap playfields are no match for tile based systems for this class of hardware in terms of dynamic animation, colorfulness, and lower processing & memory overhead.

(Obviously as the brute force of hardware increased, bitmaps won out because they're unrestricted and you can effectively have a software-defined graphics system at 60fps.)



But not everything is a game. When it comes to utilities and productivity, it's hard to beat the flexibility of a bitmapped screen, even if it's not updating at the speed of action games. In a bitmap mode, pixels need to be easy to address individually (even when <8bpp), a hardware block copy is very handy, and static raster splits are still useful. Plus, it really helps to keep the resolution around what the CPU can reasonably manage with respect to the size of the framebuffer.

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

The concern I have with "tile based" graphics is that you might need to look at several tiles in sequence to discover which one has the topmost opaque pixel at any particular scanout location. This is a greater and variable demand on bandwidth than a straight bitmap or even a single-overlay system that I outlined, and thus complicates the hardware design.

I understand the VIC-II got around this by loading the current row of each active sprite into some internal memory, and having dedicated logic around that memory to resolve the overlaps internally. It's not immediately clear how to do that in discrete logic, especially to support a larger number of sprites than the C64 did.