Very close, if not the same, but drawn a bit differently.
Here's what I have in mind, simplified to a 16K ram chip so I don't have to include address decode logic in the diagram.

This is just view from the video system, I haven't shown any decoding required to map the banks into CPU address space for read write.
An advantage of this system is any banks not in use for display can be used for storage, filesystem buffers etc.

I'm not seeing that extra clock cycle, a little more hold time for the second SRAM to stabilize perhaps, though I'm not sure it's enough to need a faster SRAM.

Code:

                   
        ╶───────────────────────────┐
                 10 Bit Address Bus │
        ╶─────────────┐  ┌───────┐  │       
                      │  │       │  │       
                      │  │    ┌──┴──┴─────────────┐
                      │  │    │                   │
                      │  │    │ 1KB Attribute RAM │
                      │  │    │                   │
                      │  │    │                   │
                      │  │    │ 1 1 1 1 . 0 1 1 0 │
                      │  │    └─┬─┬─┬─┬───┬─┬─┬─┬─┘
                      │  │      │ │ │ │   │ │ │ │                         ┌──────────────────┐
                      │  │      │ │ │ │   │ │ │ │                         │                  │
                      │  │      │ │ │ │   │ │ │ └─────────────────────────┤ Colour Circuitry │
                      │  │      │ │ │ │   │ │ └───────────────────────────┤                  │
                      │  │      │ │ │ │   │ └─────────────────────────────┤                  │
                      │  │      │ │ │ │   └───────────────────────────────┤                  │
                      │  │      │ │ │ │                                   │                  │
                      │  │      │ │ │ │      16KB Attribute RAM           └──────────────────┘
                      │  │      │ │ │ │   ┌───────────────────────┐
                      │  │      │ │ │ └───┤                       │
                      │  │      │ │ └─────┤A10-A13 (RAM Page/Bank)│
                      │  │      │ └───────┤                       │
                      │  │      └─────────┤                       │
                      │  │                │                       │
                      │  └────────────────┤                       │
                      │                   │A0-A9 (8x8 Block Addr) │
                      └───────────────────┤                       │
                                          └─────┬─┬─┬─┬─┬─┬─┬─┬───┘
                                                │ │ │ │ │ │ │ │            ┌────────────────────────┐
                                                │ │ │ │ │ │ │ │            │                        │
                                                │ │ │ │ │ │ │ └────────────┤  Attribute Circuitry   │
                                                │ │ │ │ │ │ └──────────────┤                        │
                                                │ │ │ │ │ └────────────────┤                        │
                                                │ │ │ │ └──────────────────┤                        │
                                                │ │ │ └────────────────────┤                        │
                                                │ │ └──────────────────────┤                        │
                                                │ └────────────────────────┤                        │
                                                └──────────────────────────┤                        │
                                                 8 Bits of attribute DATA  │                        │
                                                                           └────────────────────────┘

Nice ASCII art !

Ah, I see.

So iAttribute RAM is an _additional_ SRAM chip, with a 74157 4:1 MUX controlled by AEC
in front of the A13..A10 inputs for switching between Attribute RAM Data output 7..4 (AEC=0)
and CPU address bus A13..A10 (AEC=1) or such.

Of course, the propagation delays of both SRAMs would add, but with 10ns RAMs that won't be critical.


Hmm...
Before we are starting to dive a little bit too deep into "gadgetry", maybe it would be good to spend
some thoughts about what sort of applications the end user would like to run "on a C64 on steroids",
what the "killer features" for a VIC-2.5 should look like for supporting this...
...and how to implement them without unnecessarily complicating the life of the coders.

I used a Unicode 'Box Drawing Tool'
http://marklodato.github.io/js-boxdrawing/



I figured a stand alone chip would make sense as it gets accessed in parallel, simplifying the decode logic and timing requirements.
The A0 to A13 are relative to the RAM chips address lines, you probably wouldn't just mux the whole 16KB onto the CPU bus at once, but rather, go through some decoding to map it into a suitable area of the CPU address in one 1KB chuncks, re using the existing colour RAM address space would be ideal. But yes, a mux on A13..A10 (relative to the 16KB RAM chip) is the first step. A13..A10 state would be controlled by a register, like LPX.

The enable/disable, in case of badly behaved software makes for interesting thinking. You could turn the new stuff on with two sprites. Basically you monitor the X&Y registers of two sprites, if the magic number is correct in all 4 registers, latch the enable line for the new stuff. An arbitrary offscreen X/Y location for each of the two sprites is your key, not likely to be hit by accident.


What everyone wants:
Higher resolution display modes along with 80 column text mode.
More colours.

What might be useful (that can make use of the new attributes):
Sprite-background collision assistance (the ability to disable it per individual 8x8 block)
Background priority (in front of or behind sprites on individual 8x8 block basis)
Flip and 90 degree rotation of any individual 8x8 block (allowing reuse of graphics thus saving RAM)
Switching between multicolour mode and hires mode on an 8x8 block basis could be useful.

Here's another option.

The C64 reads 8 bits of bitmap data per character cell on every visible line, plus 12 bits of pointer+colour per character cell on so-called 'bad' lines. In bitmap modes, the pointer data is interpreted as colours.

But that's not actually true. Colour RAM is feeding its 4 bits of data to VIC every cycle. They just get discarded when they aren't being read along with the character pointers.

Extend colour RAM to 8 bits wide, and make it a reasonable size (ignoring how it gets mapped into CPU memory). Add a register to give a base address for when it is read along with the character pointers, and another for when it is read along with bitmap data.

That gives 16 bits of pointer/colour data per character cell, and another plane of bitmap. You can do a lot with that. Standard modes become 2 bits per pixel, and multicolour is 4 bits per pixel. You'd want to arrange for the standard C64 behaviour when the extra plane is 0, and probably have a bit in a register to force reads from it to 0.

Having 4 bits per pixel in multicolour mode opens up another possibility, which I will call mixedcolour mode. Most of the values give the double-wide pixel a colour from a register or from one of the per-cell colour sources. But some allow different colours for the left and right halves (there are 2 more combinations of colour_ram_low and colour_ram_high, and 6 if you include $d021). That gives a per-pixel choice of either more colours or higher resolution.

Coding or writing text certainly is more fun with 80 column text mode.
For having a nice text editor, maybe it would be useful if one could select
between 4 different character sets with two Attribute Bits.
Maybe blinking or underlined characters also might be nice.

Higher resolution display modes also would be nice.
of course, having 8 color Bits per pixel would require a _high_ bandwidth on the bus...
...and a lot of memory: 62.5kB of memory for a 320*200 resolution.

Collision assistance and priority assistance also might be nice.
Hmmm... switching between multicolor and hires could be useful for the one or other video game.

Rotating an 8*8 block in 90 degree steps by hardware has the disadvantage, that 40 8*8 blocks
might need to be fetched in advance to do the rotation, so line crunching tricks probably won't work well.

;---

Some other nice features:

The sprite video data is fetched in the border (or outside the visible area),
3 Bytes per sprite per raster line. (I'm simplifying things a bit here.)
So besides that it would eat up some memory, nothing speaks against having
sprites with a size of up to 24*200 instead of just 24*21 pixels.

Of course, horizontally increasing the sprites requires a bigger bus bandwith.
But when having enough memory, it might be interesting to have one or two
(partially transparent) sprites over the background screen...
...at the size of the background screen.

;---

If the external data bus would be 16 Bit, and the address bus would be partially split
for both of the 8 Bit RAM blocks (like in the C65), the Attribute RAM could be anywhere
inside another 64kB block of memory.
And then, we could have horizontal\vertical hardware scrolling at Byte level,
this requires quite some tinkering with the COLUMN counter.

For vertical hardware scrolling, we just need a register containing a start address
for the COLUMN counter. When increasing that register by 40, the display just starts
one line of text later.

When tinkering a little bit more with the COLUMN counter, we could define that one
line of characters takes (for instance) 256 Bytes in memory than just 40 Bytes,
(still only 40 Bytes of text per character line are displayed of course)
and from there you only neet to increment the start address register to have
horizontal scrolling.

The Rockwell 6545-1 had those features for bytewise horizontal and vertical scrolling.
Datasheet page 4, page 6.
But it would be better not stick with a fixed size of 40 or 256 Bytes per line of text,
it certainly would be better to keep this variable.

// Ok, so the COLUMN counter then better should be a register plus an adder instead of _just_ a counter.

Hmm... I'm in total unawareness about how to implement hardware windows on the screen... I'd really like to keep that unawareness...

@John West: sorry, had not noticed your post in time while typing my text.


Yep, somewhere up in this thread we had this idea of using an 8 Bit RAM chip for the color RAM,
then to read 8 Bit from it while PHI2=1 and another 8 Bit while PHI2=0 (16 Bit per PHI2 cycle).


Now that's a new trick !

I interpret this as "make the color RAM 64kB in size, and tinker a bit with its address lines
for fetching a Byte during PHI2=0 that could be used either as >Attribute< or as >pixel data<".

Hmm... looks like address bus from the VIC-II to main RAM and to color RAM then (partially) needs to be split.


For backward compatibility to the original C64, that is.


Hmm... twice the hires resolution indeed !

Correct me if I'm wrong:
I think that multicolor would be either 2 Bits per Pixel, or 4 Bits for two Pixels.
2 color Bits per pixel doubles the resolution for multicolor.
4 color Bits for two pixels opens some nice possibilities...
Plus those 4 additional Bits for an 8*8 block, since color RAM is 8 Bit now.

Edit:
Because of how the character generator is accessed by the VIC-II,
IMHO only graphics display modes could be improved this way,
and text display modes still would be limited to 40 characters per line.
But it's a nice idea, and I like it.

You could re-use of the Bits that control 8K graphics page mapping, double the X/Y resolution requires 2 Bits (for 4 x graphics pages), and they aren't needed in text mode (you'd be mapping in char ROM or 'User Defined Graphic banks' (or a mix) in the same way though), this lets you select upper case, lower case, and two other sets based on the 8x8 block basis. True underline mode requires that the 8x8 blocks have gaps between them, but an underline charset could be used to fake it. I'm not sure blink get used enough to dedicate a Bit to it, it can be simulated with an empty UDG bank and an second copy of the 'attribute bank in use' where the 'blink' 8x8's are set to the empty UDG bank (toggling between attribute banks under interrupt control would then blink all the blinking text with a single bitflip)The 8K graphics page banking allows for double the resolution, are still many colour tricks to look at, but yes, direct colour mapping 8 bits per pixel needs comparatively HUGE bandwidth. Switching any 8x8 to text mode would also be interesting.Yes, I was thinking silly things in regard to rotation, flips are easier though (reverse the data bits for X-Flip, and the 3 lowest bits of the graphics fetch for Y-Flip)I've put some thought into sprites and I keep coming back to "Sprites are difficult". You'd have to use parallel buses for each sprite as trying to do prefetch will end up eating the entire scanline.

An arbitrary increase in mapped scrollable area means an arbitrary increase in mapped colour RAM to do so, which might be an issue. The r6545-1, being monochrome didn't have to worry about it.
An arbitrarily sized visible window into an arbitrarily sized screen/plane is quite doable, but it's at odds with the VIC-II architecture, requiring a bitmapped colour and a linear address space for the entire screen.

Different meaning of the Attribute Bits for text and graphics mode, makes a lot of sense.
Underlining text maybe could be done by inverting the last Byte fetched from the character generator.
I agree, that blinking probably won't be getting used quite often.

In extended color text mode (MCM=0, ECM=1, BMM=0) Bit 7..6 of the video RAM are used for selecting 4 color registers,
so one could have only 64 different characters on the screen. Having two Attribute Bits for selecting the character set
would turn this back to the usual 256 characters... but it would be a kludge.


Absolutely. IMHO this calls for a completely different hardware "subsystem", with the display memory integrated to it.
Somewhere up in this thread, I had mentioned the EFF9367.
Back in 1987, I did build a 6502 computer with 32kB SRAM, plus an EF9367 subsystem with 192kB DRAM,
display had 512*515 pixels, 8 colors per pixel...


Hmm... text and graphics mixed, sounds good.


When spending some more thoughts on this:
Horizontally flipping an 8*8 graphics block could be done with maybe two 74157 multiplexers in front of the shift register.
(or by having two shift registers, the inputs of one shift register normally connected, the inputs of the other connected
with the Bits in a reversed order, then to switch between the outputs of both shift registers with a multiplexer).
Vertically flipping an 8*8 graphics block probably could be done by inverting the three output Bits of the ROW counter
with 7486 XOR gates.
BTW: if two Attribute Bits would be used for switching between 4 different character sets (1kB each), flipping/rotating
the characters would be easy if every character set would be rotated by 90 degrees.


Horizontally bigger sprites would be difficult, because at a ca. 1MHz PHI2 the bus certainly doesn't have the bandwidth required.
Vertically bigger sprites means just tinkering little a bit with the sprite display logic. (Edit: this includes the sprite address counters too, of course.)


Certainly yes, and to be on the safe side I already had pointed this out...


The 6545\6845 only generates the display memory address, the sync signals etc.
The part that turns the Bytes from memory into a serial bitstream for video isn't included in the 6545\6845.
BTW: in early PC graphics cards, the 6845 was used, too.


I still would like to keep that unawareness about hardware windows...
But when taking a look at the column counter, it appears that it increments in a somewhat linear fashion.
The program counter in a processor also increments in a somewhat linear fashion.
So if (hypothetically spoken) we would see that COLUMN counter as sort of a program counter,
and add a set of JMP\JSR\RTS to the Attribute Bits and have sort of "interrupts" triggered at specific 8*8 block locations
(with logic similar to the sprite comparators), I'd like to point out that a hypotethical non_linear address space
for the screen in theory unfortunately might be possible...
But implementing something like that would require a lot of circuitry, and actually using it would be sort of an "origami trick".

Hmm... 8 Bit Atari ANTIC and the Display list...

;---

After tinkering a bit more with John West's idea, I'd say with a bigger color RAM and a (partially) split address bus,
it might be possible with a ca. 1MHz PHI2 to display text and something like hires graphics mixed.
So either to take one Bit from the character generator and to XOR it with one Bit from the graphics memory...
or to take those two Bits and to do sort of a "multicolor encoding".
Anyhow, this won't be too useful, because the VIC-II won't be quite the sort thing you would be using for CAD applications.

Spent some more thougths on the Atari ANTIC...

If the VIC-2.5 would have some status signal outputs indicating what it tries to read from memory
(remember the FC2..0 lines from 68k ?), and if the address bus pins of that VIC actually would be
bi_directional, and if there would be a write enable not only for the data bus, but for the address bus too...

One could (in theory) be able to build a "coprocessor" that could write address registers\counters in the VIC
by "taking over" the address bus in the right moment without that this requires additional bus bandwidth.

There would be some more interesting/funny things possible when the data bus (including color data
and R/W) would go through that coprocessor before it enters the VIC.

It all still would be sort of an "origami trick"...
...but with this, I now got that idea\concept off my desk ! Case closed. Woot.

Bit's 7 and 6 were probably used because they had no other settable bits that were in direct relation to screen memory, but we have a hole bank of bits (that could be extended even wider).
We could have the effect of extended color text mode without the reduction in charset.It always looks lopsided when a system contains more display RAM than system RAM, but that doesn't detract from the fun.A single bit could be used to switch the 8x8 into the opposite of what your current mode is, graphics to text and vice versa.Two 74157 multiplexers in front of the single shift register should do it. The ROW counter is a good place to tap in for vertical.
I didn't even think of a pre-rotated charset, that would work well, and could be done easily with a user defined set created from a once off rotation of the char ROM at runtime.Thanks. I missed that in the datasheet.Okay, I'll keep my 6 adders and 4 registers to myself then. Non_linear frame buffers were the norm in the PC's DOS days so it's certainly possible, but I was thinking in terms of that thing you wish to remain unaware of.
My method of doing that 'thing' requires a linear address space.
A bigger colour RAM adds some more options, though I'm not sure I'm following the split address bus idea properly.

I was starting from the original modes of 320 pixels in standard resolution and 160 double-wide pixels in multicolour. You normally get 1 bpp or 2 bpp in these modes. With an extra 8 bits coming from what was colour RAM, that doubles to 2bpp or 4bpp respectively, keeping the pixels the same size. So 'standard' keeps its resolution, but gets the colour choice that multicolour used to have. Multicolour gets even more colours. The 'mixedcolour' trick lets the double width pixels of multicolour mode have two different colours where you need higher resolution. You could also have a super high resolution mode with 1 bit per pixel, and 640 pixels across.

That's if you stick to 1MHz, of course. At 2MHz everything doubles. You get 80 characters across, 640 pixels in high resolution, 320 pixels in multicolour, 1280 in super high resolution.

I was imagining using the top half of the colour RAM data as an extra per-cell colour source. But there's no reason you can't store other attributes there instead. I don't see rotation working, but flip would be a useful option.

Better control over sprite priority and collision would be very valuable. You could do that with per-cell attributes, or with per-colour attributes in the palette. I don't know which would be more useful.

I forgot to mention the palette. Colour registers ($d020, $d021, and so on) can all be extended to 8 bit, and address a 256 entry palette. The per-cell colours (from colour RAM in character mode, and also from screen memory in bitmap mode) are (in my imagined setup) 4 bits, and address 16 entry palettes. There's no reason that these palettes have to be the same, apart from the increasingly crazy number of chips you'd have to use in a TTL implementation. But a TTL VIC is a crazy idea already



If you're using the standard character ROMs, then you won't get any benefit. And in any case you won't get more than 40 characters at 1MHz. But if character bitmaps are in RAM, then you can put another plane in colour RAM and get the same benefits of more colours.



The C64's VIC II already sort of has two memory interfaces. You've got an 8 bit wide main memory with 14 (I think) address lines (plus two more from a CIA register somewhere, I think), and a separate 4 bit wide colour memory with 10 address lines. The low 10 bits of the address for each memory are always be the same for accesses where the colour data will be used, so they share the physical address bus. The data busses are separate: there are 8 pins for main memory and a separate 4 for colour.

If you allow yourself the luxury of a package with more than 40 pins (or a TTL implementation which doesn't care about the pin limitation at all), you can add more address lines to the colour memory. Actually, there's no reason they need to be in a VIC register at all: you might add a third CIA and use some of its outputs for the colour memory's extra address lines. This gets closer to two completely independent memory interfaces, but not quite all the way. You still end up sharing the low ten address bits. (Or 11 if you're running at 2MHz and have an 80 column mode).

I have no idea how to do hardware windowing either. I did think about it many years ago, but I can't remember any of the details. I never came up with something that would work nicely anyway.

Hmm... reminds me: long time ago, maybe in 1984, I did read an advertisement in a computer magazine about a special HD63484 based graphics card for the AT PC...
IIRC the graphics card had been in the price range of a new car... I'm not talking about a VW Beetle here...


http://6502.org/users/dieter/xp/x45/x45.htm


Nah, just post it.
Whoever would be going to implement that TTL VIC-something, it won't be me.
My "job" here only is to collect/sort some technical info and some odd ideas for giving him\her a better starting point.


A linear address space maybe gives the readers less of a headache than a nonlinear address space, that's OK...


Let's say, a graphics picture on the C64 takes 8kB.
64kB RAM, so there are 8 Block 8kB each in the RAM, selected by the address lines A15..13.

If you would have 64kB of color RAM, which also can be broken into 8 blocks 8kB each,
and during PHI2=0 you would be fetching a highres graphics picture from the main RAM while simultaneously fetching another
highres picture from the color RAM, when A15..0 from the VIC-II goes to both RAM chips, both graphics pictures have to be
in an 8kB block starting at an identical address... and that would be a little bit impractical for the end user.
;
But if you would connect A15..0 from the VIC-II to the main RAM, and let's say B15..13 (three additional address lines) and A12..0
to the color RAM, the start address of the 8kB block in the main RAM and the 8kB block in the color RAM can be different.
;
That would be the description of how and why to split A15..13 of the address bus.

Thanks for describing it more into detail (I think I got that concept).


I think that 90 degrees rotation would require to pre_fetch 40 blocks 8 Bytes each and to keep them inside the VIC-2...
but that prefetch certainly would create other issues... line crunching tricks proably won't work well then.
The result of vertical flipping seems to look like the result of a 180 degree rotation.


I think per-cell, but per palette also would be useful (thanks for pointing this out).


Hmm... good point !
If one would be building a palette from SRAM, it probably would be 10ns 512kB SRAMs anyway, so more than one 256 entry palette is possible.


...Not more crazy than trying to build something like a 20 MHz TTL CPU running 6502 machine code.


That, or a character ROM for the CPU and another (identical) character ROM inside the VIC-II...


Nicely explained.
And since the color RAM has only 10 address lines, and one page of text has 1kB, and the character to be displayed plus the color
are fetched simultaneously, there was no need for splitting the address bus in the C64.


Ja, but when considering the size of that TTL 6522, building a TTL 6526 would require quite a few chips...
Might be better trying to avoid having three TTL 6526s in the system...


Looking forward to see that idea from Cray Ze...

I see what you mean now, it could even be used in conjunction with the method shown in the diagram at the top of this page. In that method, the colour RAM is replaced with an 8 Bit wide RAM (though it could be wider if needed). Bits 4..7 of the new colour RAM then drive the high address lines of a 16K RAM, providing 16 banks of 1KB 8Bit colour/attribute RAM. In either case, it looks like expansion based around colour RAM is a good starting point.

Hmm, that's a mountain of chips, not quite as scary as the Lorraine project (Amiga) prototypes, but still more than enough to make the Spock eyebrow thing happen.Likewise, it's a good thought exercise, and someone may have an interest in implementing some of the ideas, but personally, I'll be keeping any video chip designs well within the realms of VHDL.