I think the C64 has a colour-attribute approach, like the Spectrum, which cuts down significantly on RAM footprint, and therefore also allows for quicker updates. Unlike the Spectrum it also has the benefit of sprites. I'm sure a Brad-sized breadboard could put the VIC-II into 74 series logic, but for compact size and price a CPLD or FPGA or microcontroller would be needed. Probably CPLDs are too small. It's barely worth distinguishing CPLDs, except for some people thinking that CPLDs are fine but FPGAs are unacceptable. What Dave, or Stefany, or Quinn, or anyone else has to do is realise they can't please everyone, and choose their own tradeoffs. Which is easier if you're just scratching an itch, and harder if you're hoping to sell in volume.

The ARM isn't slow, but the Pi has other considerations. DRAM for a start which gets refreshed independently of the ARM, so the ARM gets stalled when that happens. There is also the video refresh too which I think also stalls the ARM. you have no real control over this. The net result is that if you're polling (or taking an interrupt) on a signal, there is every chance you might miss it. The Pi is essentially a GPU with an ARM bolted on the side, almost as a secondary consideration.

Then there's the OS - PiTubeDirect is a "bare metal" system, but Linux is the default for most people.

So a nice little ARM chip with a meg of static RAM and on-board video generator, lots of GPIO and off you go...

-Gordon

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

Doing some research the only issue with that ARM is that there is some bus contention and no way to prioritize the video generation DMA. This is the basic problem with every MCU - even when you have DMA, it's never able to take priority and precise timing.

But if the "host" is handshaking properly (i.e. set data, set RDY pin, wait for GOTIT pin, rinse and repeat), the Pi shouldn't miss anything, right?

It may stall, sure, but the handshaking should prevent actual data loss, right?

What do y'all feel is the minimum processor that can drive VGA effectively? What frame rate would you look for?

According to the Wiki VGA is:

• 640x480 16 color (4bit/pixel 153,600 BpF, Bytes per Frame), 4.3MB/s for 30 FPS (It also says monochrome, but I don't know if that means gray scale)
• 320x200 256 color (64,000 BpF), 1.8MB/s for 30 FPS

So, it seems to top out at 4.3MB/s for 30FPS. Obviously, you don't need to drive it that hard. But you would still probably need at least that much internal bandwidth for a full screen game (I don't know if VGA commonly supplies double buffered displays). You can always incrementally update a frame buffer without having to repaint the entire thing.

But either way that's a lot of bandwidth for legacy micro to drive.

The minimum CPU is determined by the pixel clock. 640 pixels is about 25MHz, 320 is obviously half that. So for a typical game you need to pump out pixels at about 12.5MHz, for 80 column text you need 25MHz.

Now look at how fast your CPU can pump pixels. For monochrome you might be able to use an SPI port running at half the clock speed, so you need 25MHz to do 320 pixels. SPI is nice because it's often buffered, which makes timing a lot easier.

But for colour you probably need to push 8 bits at once to GPIOs. You can either make your CPU use an interrupt and copy data from RAM to the GPIO port as fast as possible, but then your CPU is tied up for about 80% of the time and can't manage the 6502 bus. So really you need DMA to do it, and on most MCUs DMA is not very consistent (lots of jitter) and rarely runs at anywhere near the clock speed.

It's kind of a pain actually, maybe an FPGA is the way to go. But they are expensive and there are not many open source tools for them.

The open source tools are coming along. The Lattice ICE40 parts are well supported. A dev board is £20 to £50 and a chip is £5 or so. Of course, there's a learning curve, and the parts may be tricky for a hobbyist to solder.

Is that right? 320x240 is only one-quarter as many pixels as 640x480, not half as many. Also, you can get 80 columns quite clearly with only 480 dots across, with characters five pixels wide plus a pixel column of separation between characters. That's the width of text used on intelligent character LCD modules.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Exactly right.


Indeed.

What I'm getting at is using the Pi or some other SBC as a 6502 CPU level bus interface device. So your 6502/816 writes to a memory location - the Pi/SBC has to listen to the Ph2 clock, the R/W line, the address lines (or "IO" decoded signal and - e.g. some address lines for a register), then sample (or write) the data at the appropriate interval to emulate a cpu-bus level device or memory. There are a lot of people who still want to poke pixels into a framebuffer... This thing is easier with an FPGA than a Pi/SBC device.

Stick it at the end of a strobe+ack 8/16 bit bus like what a 6522 can give you and it's trivial, if a few cycles slower.



I think going above 320x240 (ish) is too much without some sort of hardware assist - like a blitter and off-screen memory, so the blitter can do a 2D move at < one cycle per byte rather than 7 (or whatever) it might take a 6502/816 to do.

And going over 255x255 resolution, you're already into needing 2 bytes per co-ordinate too. It all adds up and increases the code complexity for our little 8-bit micro, so sure, I could hook a $5 micro to a 6502 and get it to display 1920x1080x32bpp but what would a 6502 be able to do with it? Even loading a static background image - that's 8MB, so quite a lot to pull through an 8-bit micros 'disk' interface...

However, without a blitter, some of the later games on the Apple II look very good, given the Apple II's video memory arrangement. Same for the Beeb. (ie. Elite) When was the first blitter? I think Atari had something, certainly the Amiga. (Just checked - seems 1985 in the Amiga for a 'home' type system) The C64 has sprite control though, but I note from the wikipedia entry that pixel poking while possible is very slow... (I've never owned a C64)

I'm also starting to think that we ought to abandon VGA too, or at least worry less about the physical connection. Even though retro'r'us we can't stop some of the physical stuff from getting away from us. I started looking at composite... Today I have just 2 displays that have composite inputs. (My 3rd old green tube monitor died) TTL RGB, anyone? I think I'm going to be happy with a device that generates HDMI knowing that there are good HDMI to VGA adapters out there now.

Cheers,

-Gordon

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

Yea, that's what I was thinking as well. I'm content with a handshake for my purposes, though, so the Pi should still be ok.

Well, that's kind of what crossed my mind regarding that VS23S010D chip. IT may be able to drive a VGA display just fine, but can a micro drive it with enough bandwidth to matter. I didn't look at the spec sheet in detail, but it seems to offer different resolutions, as well as an on board blitter. That may well be enough to make it work well for a text display with limited graphics. Upload the character set in to unused Video RAM, and blit from that.

Closest thing that the Atari had was programmable character sets, and sprites. Neither of which I'd really classify as a blitter.

As I've mentioned before, I never thought driving raw VGA was a good idea, but the idea of driving a "graphics chip" that presented VGA as output, but offered a more limited, more suitable for a micro interface on the front.

Your point earlier about the Pi being a GPU with an ARM chip I think is very akin to a lot of the early micros. The graphics hardware was deeply intertwined in to the computer design, and a lot of CPU cycles were dedicated/lost to the graphic hardware trying to feed the voracious and uncompromising composite video demands. In the end the graphics/display hardware was the real master of the bus, and the CPU just got time when it could.

And much of the interface work necessary to pull it off is above many hobbyists, especially if they have to design the graphics part themselves (unless, apparently, you do everything in raw TTL lol).

I think it's much more capable than that - there is plenty of spare RAM inside and with clever manipulation of the internal blitter then tiled backgrounds, sprites and text is more than possible. You just need to think differently - think more in terms of a picture than pixels. So load it up with the background, sprites, font and so on, then it's a matter of poking registers than pixels.

I'm going to do effectively the same with a Pi, although I can fix the resolution to something suitable - I did all the graphics code for what I want some 7-8 years ago for my BASIC interpreter then ported it to the Pi as soon as I got one. My graphics driver does sprites, etc. in software - mostly because I didn't know how to do anything more at the time under Linux.

-Gordon

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

Yea, I don't know if it supports transparency or not. That would be necessary to do any kind of sprite thing (to a point, you can block move the scan lines on large solids, I'm sure as long as you're not moving pixel sized checkerboards, sprites with holes in them can still be worked OK).

Datasheet says it is only PAL/NTSC, no VGA (31kHz) support.

All the tools are beta and don't work properly on Windows. Believe me, I've tried.

Hmm, OK, that might be a bit of an obstacle. Have you tried a virtual machine? (revaldinho runs a Mac, but uses the linux version of the xilinx tools in a VM.)

Or indeed if using Windows 10, they should work just fine under the Linux Bash Shell.

Dave