A question regarding 6502 being interfaced to a 8/16 bit bus

[flydeath]

Hello everyone I have a question regarding the 6502 cpu bus interface. Ok so in the C64 both the 6502 and Vic II chip share memory access time with each other right, and as far as I know both chips have 8 bit data buses so I imagine that interfacing both of them together to the 64k of ram was trivial. Well what I want to know if you could that same trick using a 16 bit graphics chip, ie a video chip with a 16 bit data bus?
Like for example say what if the C64's 64k of ram was split in to two 8 bit banks of 32k each, could the 6502 have interfaced to all 64k of it using its 8 bit bus, while at the same time, the hypothetical 16 bit video chip interfaced to the same 64k using its 16 bit bus?

[Dr Jefyll]

Welcome, uh.. flydeath (!)

The topic of mixing 8- and 16-bit interfaces has come up before. Here is one relevant post, and using the forum's Search function you may find others.

The diagram in my post shows just a single device (presumably a video chip) attached to the 16-bit bus, but you could also attach memory to the 16-bit bus.

Getting all this to work with a C64 will be challenging, but sometimes it's educational (and fun!) just to kick the concepts around!

-- Jeff

[flydeath]

Thanks for the reply Jeff, yeah like I mentioned earlier the reason I brought up the C64 was because of its memory sharing architecture with its 6502 and Vic II chips, when I found out about it I naturally became curious with the idea of mixing both a 8 and 16 bit bus using the same concept with a more advanced graphics chip.

[Martin A]

One example posted here a few years ago of a 8/16 mixed width video display is: viewtopic.php?f=4&t=4994

Th CPU on the 8 bit side sees a total of 8k locations, character data on even addresses and colour data on the odd ones.

The CPLD on the other hand sees 4k locations of 16 bits of colour/character data.

[gfoot]

My 640x480x3bpp video circuit works this way too, with the video side reading essentially a 16 bit bus and the CPU side writing to it as an 8 bit bus in two banks. I don't have a circuit diagram to hand in image format - I only have kicad format on my GitHub - but I talked through the upgrade at the schematic level here: https://youtu.be/cFJX95zQj4w

The main trick is using two 8-bit-wide RAM ICs in parallel to make the 16 bit bus, then using one (actually two) of the address bus lines to control their chip enables from the CPU side. My address bus is essentially 23 bits wide, as I use all 8 port B pins on a 6522 as a short term bank register, then map 32K of CPU address space to address video RAM, giving 15 more address lines from the CPU. Nearly all of them are needed for this resolution and colour depth.

[AndersNielsen]

My 6502sbc currently does bw characters by taking 1 ascii byte from RAM at 2MHz, turning it to 8 lines x 8 cols with a ROM and shifting it out at 16Mhz.

I’ve been thinking about it for weeks but haven’t had the time to breadboard it, but I think the simplest way to add color might be to add a second RAM like suggested here and then using the 16Mhz character signal to flip an address line instead of directly driving a color line - I’m hoping that’ll give me 8 bit front and background color per character with only 3x the amount of framebuffer. In my case 2k ascii(with blanking), 2k foreground and 2k background.
64x32 characters including sync and blanking = 51x30 actual characters = 408x240 effective pixels

I’m worried my HM62256 might not be fast enough though..

[gfoot]

AndersNielsen wrote:

I’m worried my HM62256 might not be fast enough though..

Maybe consider using a multiplexer instead. E.g. if you have four bit colour (like the CGA palette) then you could define a foreground colour and background colour in an eight bit attribute byte, and use a quad 2-to-1 multiplexer like 74HC157 to choose between them, with the output of your shift register driving the multiplexer's select input.

Or use two 4-bit transceivers (74HC243), one for foreground and one for background, with one enabled when the shift register output is high and the other when it is low.

Either way I'd be inclined to feed the result through a final D flipflop to even everything out and prevent transient results from reaching the monitor.

[AndersNielsen]

gfoot wrote:

AndersNielsen wrote:

I’m worried my HM62256 might not be fast enough though..

Maybe consider using a multiplexer instead. E.g. if you have four bit colour (like the CGA palette) then you could define a foreground colour and background colour in an eight bit attribute byte, and use a quad 2-to-1 multiplexer like 74HC157 to choose between them, with the output of your shift register driving the multiplexer's select input.

Or use two 4-bit transceivers (74HC243), one for foreground and one for background, with one enabled when the shift register output is high and the other when it is low.

Either way I'd be inclined to feed the result through a final D flipflop to even everything out and prevent transient results from reaching the monitor.

Going down to 4bit color would certainly slow things down enough buuut I’m not quite ready to give up on 256 colors yet
I think I’ll try to throw a ‘245 on the color RAM data bus(for isolation) along with a ‘273 I can clock output with - which I can also disable when writing RAM..
worth a shot. Not impossible 70ns RAM would work at 62.50ns

[Sheep64]

AndersNielsen on Thu 31 Mar 2022 wrote:

64x32 characters including sync and blanking = 51x30 actual characters = 408x240 effective pixels

It is unusual to have an odd number of columns but that makes perfect sense. I wrongly assumed that you sought a widescreen ratio while filling the maximum number of pages. In this case six. Commodore designs made similar choices. For example VIC20's 22*23 display almost fills one page and Commodore 64's 40*25 almost fills four pages.

Either way, 51*30 text display allows 6*256 byte blocks or 3*512 byte blocks to be loaded from storage and displayed on screen. This is suitable to play uncompressed text animation.

AndersNielsen on Thu 31 Mar 2022 wrote:

I think the simplest way to add color might be to add a second RAM like suggested here

There are multiple ways to scale a video system. The most minimal systems only displayed 64 characters. That's ASCII $20 to $5F - upper case only - using 0.5KB ROM. Commodore allowed 7 bit ASCII and used the top bit for inverted video. The cheapest way to achieve this is to feed all character RAM outputs into 2KB character ROM. The inverted video bit allows color text on black background or black text on color background. It only requires one bank for color values and said bank does not have to be particularly wide. The Commodore VIC20 was famous for having 1K * 4 bit palette RAM because it was cheaper than 0.5K * 8 bit RAM. This scheme can be extended with a global background color and global border color.

I highly recommend RRGGBBII for colors where the least significant bits are shared between red, green and blue. In particular, it permits 16 shades of gray.

So far, this requires two RAM chips, one ROM and no multiplexing beyond processor write/video read. With a third RAM chip, it is possible to set foreground/background separately within each tile. Dropping the inverted video bit allows the number of symbols to be doubled.

Four RAM chips, two ROM chips allows independent foreground/background and allows logical OR of the character ROMs. This allows thousands of symbols to be displayed.

With extra RAM chips, the palette can be improved. With extra RAM and ROM, available symbols can be vastly increased. At this point, you may have an 80 bit video bus or similar. Or maybe much wider if you have two or more displays. At this point, a video accelerator of some form becomes very worthwhile.

Anyhow, the general plan is:

• Deliberately make the video bus as wide as possible.
• Accelerate the really wide video bus when it gets too slow.

[AndersNielsen]

Sheep64 wrote:

I highly recommend RRGGBBII for colors where the least significant bits are shared between red, green and blue. In particular, it permits 16 shades of gray.

Thanks for the advice!

How does this compare with RRRGGGBB? I’ve yet to enter the funky world of messing with palettes in GIMP or python and haven’t heard of sharing the lower bits but it makes sense.. more even distribution?

I’m thinking I can use 2k RAM for symbols and another RAM for foreground + background color (2k +( 2k + 2k))

[barrym95838]

Sheep64 wrote:

I highly recommend RRGGBBII for colors where the least significant bits are shared between red, green and blue. In particular, it permits 16 shades of gray.

I need to know more detail about this, please. I'm not planning on building a display interface, but the concept makes my curiosity itch.

[akohlbecker]

barrym95838 wrote:

Sheep64 wrote:

I highly recommend RRGGBBII for colors where the least significant bits are shared between red, green and blue. In particular, it permits 16 shades of gray.

I need to know more detail about this, please. I'm not planning on building a display interface, but the concept makes my curiosity itch.

You might find this interesting https://www.bigmessowires.com/2008/07/0 ... tte-setup/

[AndrewP]

Sheep64 wrote:

I highly recommend RRGGBBII for colors where the least significant bits are shared between red, green and blue. In particular, it permits 16 shades of gray.

akohlbecker wrote:

You might find this interesting https://www.bigmessowires.com/2008/07/0 ... tte-setup/

This made my curiosity itch too. But Bigmessowires doesn't mention how to implement it beyond maybe one DAC feeding into another DAC. As I have no background in all that analogue guff that sounds like a horrible solution to me (I mean it's probably a beautiful solution but I don't get it).

Having a brief pause in the crazy deadlines we have at the office at the moment I though I'd try and sketch up a digital solution instead. I think it should be possible to take an 8Bit RRGGBBII value and turn it into a 15bit (or 24bit padded with zeros) value using only 5 ICs. One '139 (or '138) selector, three '16244 line drivers and one '257 multiplexer.

Wire II into the '139 and send its 4 outputs into the 4 enables on RED '16244. Wire RR into the inputs of the '16244 four times but offset by the intended intensity (wire the two unused inputs to ground in each case). Wire all the same outputs of the '16244 together. i.e. All bits 0 get wired together, all bits 1 get wired together, all bits 2 and all bits 3. This creates a nice single chip 4 bit by 4 to single 4 bit multiplexer.

Do the same using another '16244 for GREEN. And another for BLUE. This gives us 12 bit colour which might be good enough if you only allow II values of 00, 01, and 10. However going 8bits RRGGBBII to 12bits R3R2R1R0G3G2G1G0B3B2B1B0 seems like a bit of a waste.

The fifth bit can be generated using a single '257 for all three colours. Wire the high bit of each colour into the 'zero' selector inputs. Wire ground into the 'one' selector inputs. Wire Y3 from the '139 into the '257s Selector. The 4 bits of output on the '257 become the fifth bits of RGB with the last output unused. That gives us a decent 15bits R4RRRRG4GGGGB4BBBB (or even RRRRR000 GGGGG000 BBBBB000 if you have a 24bit DAC) from 8bits of RRGGBBII.

For all of the work above it's probably just easier to write a palette into 3 8bit data by 8bit address ROMs (or RAMs) and use the 8bits of RRGGBBII as the address. At which point you just a have normal 256 colour palettised to 24bit colour display

[Sheep64]

Regarding RRGGBBII, I've drawn a diagram but this may only confuse the matter. RRGGBBII is, technically, a four dimensional color-space, like CMYK. Therefore, I have omitted green and drawn a projection of red, blue and intensity on a two dimensional plane. I am not adverse to drawing a projection of a hyper-cube but it is time consuming and doesn't advance my argument.

Starting from RGBI, we have two cubes of color: a dark cube where I=0 and this overlaps with a light cube where I=1. Along the diagonal from black to white, we have four colors where R=G=B: black, dark gray, light gray, white. This is similar to EGA. RGBI can be extended to two bits per channel. This leads to four overlapping cube meshes where each mesh has 64 points. Also, we have 16 colors where RR=GG=BB. Within each cube, there are four points where RR=GG=BB and there are four cubes. This scheme is always superior to RRGGBB unless two bits are used for horizontal and vertical sync (as occurs in Gigatron design). In particular, an even tempered allocation of bits is best for representing light and dark skin tones. From empirical tests using Perl to make GIMP palettes, I found that schemes with superior representation of light skin tones do so at the expense of dark skin tones. Don't be a casual racist.

The (dis)advantage of RRGGBBII is that colors are muted because the overlapping color cubes only meet the black and white corners of RGB color-space and not the red, green, blue, yellow, cyan or purple corners. This provides more compatibility with brightness oriented Y* and *K color-spaces, such as YUV, YIV, YCbCr and CMYK. In these cases, one axis provides brightness (Y) or darkness (K). The reason for these color-spaces is to maximize the representation of color over bandwidth limited composite video cable, to minimize perceptual allocation of bits or to minimize the cost of ink. Viewed from the basis vectors of RGB color-space, one axis is along the diagonal from black to white and the overlapping volume of cuboids is awkward. However, RRGGBBII, with six clipped corners, is partially aligned with the clipped volumes common to RGB, CMYK and other color-spaces. Therefore, RRGGBBII reduces the proportion of colors which can be displayed but not printed, printed but not displayed, displayed but not streamed and streamed but not displayed.

I would implement RRGGBBII using three 74HC161 in a non-counting latch configuration. The use of three identical components would minimize signal skew. This would be commonly followed with three R2R DACs and no-one considers the slew rate of 25.175MHz 640*480 VGA using through hole passive components. However, R2R DACs introduce their own non-linearity because there is unwanted current flow within the resistor network. Use of diodes only complicates the situation. If the least significant bits are redundantly latched then non-linearity is contained within each channel. To reduce components, people may be inclined to have one eight bit latch, such as 74x574, and arrange the highest resistances such that a small amount of back-flow occurs between the three color channels. Don't do that. It will further mute the colors and it is a distinctly different color-space. The only place where resistor cross-flow is useful is in gfoot's 2 bit per pixel hack where green is the average of red and blue. This provides the never-known-for-its-subtlety Commodore Amiga WorkBench 1.3 palette of black, orange, blue and white.

I really hadn't considered non-linear brightness response and this is a fraught problem. Mammal brightness perception is non-linear and involves square roots. Meanwhile, linearity of NTSC/PAL/VGA is implicit and rarely equivalent. Does a equal step in voltage represent an equal step in monitor luminance, an equal step in perceptual brightness, or something else? I prefer maximum perceptual range but a minimal system may be approximately linear and this may skew towards a pastel palette. Some monitors may convert linear voltage into perceptual brightness but this feature may be absent from cheap LCD panels. R2R values can be tweaked to approximate perceptual brightness but this may be counter-productive in common scenarios.

AndrewP's barrel shifting eliminates most of the unwanted non-linearity while keeping most of the wanted non-linearity. Full implementation requires 15 bits of latch (two 74HC574) and monitor gamma setting remains desirable, if available. However, any decent discrete implementation requires multiple chips and gamma settings.

You may be inclined to store RRGGBBII such that BPL/BMI/BVC/BVS could be used on the intensity bits. This may seem preferable to advantaging one color channel over the others. However, it is preferable to store intensity in the least significant bits because a video codec can approximate MPEG lighten/darken by using INC/DEC. This doesn't work for all values and the effect is guaranteed to be worse than MPEG encoding. However, it requires minimal clock cycles and it works effectively if there is a huge number of tiles. INC/DEC is also preferable for computing LUT for drop-shadow of partially occluded video windows. Specifically, it is possible to select anything from zero shadow to absolute shadow. A utility for the Amiga had similar functionality. Therefore, it is definitely within range of 14MHz 65816. As I previously noted:

Sheep64 on Mon 21 Dec 2020 wrote:

I fear that we are "generals preparing for the last war" and that we are devising the perfect word processing system when the baseline specification is video conferencing.

On Fri 15 Jan 2021, I said that I am working on 8K video and 3D surround sound. On Wed 1 Jun 2022, I said that I am working on a combined Video/Audio/Network interface. If you're following closely, you'll know that Project Snail memory map is now upwardly compatible with 16K video, Dolby 7.1 surround sound, 3D Auro 11.1 audio and 3D, third order Ambisonics.