> Blit needs two basics. One bit per pixel and two bits. That is it.

No, that's not it. You could parameterise a blit close to that easy on modern platforms with relatively uniform memory layout. Not on 8-bit home computers.

The Apple graphics modes as far as I understand stored 7 pixels per pair of adjacent bytes and the high bit shared across the pixels, to pick from an 8 colour palette with bleeding possible between pairs of pixels, while the C64 stores 4 pixels per byte, with each adjacent pair of bits representing one pixel.

The natural implementations of those two on a 6502 is completely different. And the bleed considerations for colours are completely different as well. But ignoring colour, unless the guts of this is written manually for each to minimize the umber of shifts and adds, you'll be blitting at maybe a tenth of optimal speed if you're lucky. To add the Amiga into the mix, since it's on the list of supported platforms.

But even for monochrome, different stride will mean a handwritten different version will mean a massive difference between platforms on a CPU like the 6502 that has no built in multiply.

You may call it a "driver", but really for a basic source to destination blit without any operations in between, handling the bit layout and stride is basically the entire blit function.

> Color maps and such do not need to be a part of things, or the programmer can manipulate them directly where they are available.

You can't do blits without taking into account the colour registers on the C64 unless you limit yourself to 4 colours (prefilling all the colour data with the same values), because they are affected by the position of the pixel. So either you drop down to four colours (including the background) instead of 16, or you can't ignore colour maps. Remember we're not talking palette settings her, but the per 4x8 pixel colour data.

So then you've basically decided to make something that will look totally inferior to anything anyone used to a C64 expects. That's fine. But if so, why bother targeting a C64? Nobody is going to say today "oh, this software only works on a VIC-20, what will I do?" - if they wan't to try it they'll just start a VIC-20 emulator - Commodore emulators like VICE supports most of the 8-bit Commodore machines anyway.

> Your comment on the C64 Robotron is interesting. Had they broke a few rules, it could have delivered more like the Apple 2 did.

They didn't need to "break any rules" - you can multiplex sprites or use character graphics to achieve far more very easily. That is part of the point: sticking to just the simplest means possible either looks ugly, or requires other tradeoffs, but if you actually use the capabilities of the platform you'd get something closer to R-Type than Robotron in terms of amount of dynamic elements and retain the gameplay. You don't need to even push the limits to get to something far better looking and playing than the C64 Robotron port on the C64. But you do need to actually make use of the capabilities of the platform. And bitmaps are not it.

> I was there in 85, and plenty of us played the crap out of Robotron on the Apple and PC

That may be a fine reason for targeting Robotron type games to Apple users used to that quality graphics, but both Apple and PC games were laughed at by C64 users at the time as ugly and primitive. It may well be that is a reason for our difference in perspective - to me there's little nostalgia with games that basic, as those were not the quality of games I remember spending time playing as a child.

> Recently, I have been enjoying things on Apple, Spectrum, and soon maybe a BBC Micro. Bitmaps and clever ways of delivering the goods. I found there are things to appreciate, I would have not before.

That's fine. But then I'd rather see something that actually takes advantage of the platform they're on and shows me something different, rather than something reduced to a lowest common denominator that doesn't show off what any of those platforms actually can do.