FPGA replacement for VIC I chip?

[eslapion]

If a "training student" can map out the content of the original IC then once you have that map its a lot cheaper, faster and reliable (better yield) to use that map to create a design for modern technology chips instead of trying to fab a batch of clones made using legacy technology.

[Kakemoms]

If a "training student" can map out the content of the original IC then once you have that map its a lot cheaper, faster and reliable (better yield) to use that map to create a design for modern technology chips instead of trying to fab a batch of clones made using legacy technology.

FPGA is cheaper. Modern fab masks.. well not so cheap as they are quite large. Maybe if one could put it onto an ASIC test run for a few devices.. but still costly.

Students are free, and they dont pay for cleanroom usage here.

[eslapion]

FPGA is cheaper. Modern fab masks.. well not so cheap...

FPGA and CPLD are modern technology and can certainly do a perfectly adequate job IMHO.

I prefer CPLDs for most stuff because they require less surrounding hardware but there are cases where FPGA is definitely the best choice.

[lance.ewing]

I'm interested more in how the original chip behaved rather than trying to create the equivalent with today's tech.

Well, you got me there! I am completely baffled by that sentence.

You're quite right, I phrased that sentence very poorly. I didn't intend to imply that studying the original chip doesn't play a big part in reproducing it with today's tech. What I meant was that my personal interest at the present time is in the internals of the original chip, mainly to satisfy my own curiosity rather than in using what I might learn to build something equivalent. Please accept my apologies that I wasn't clearer with what I said earlier.

My hardware knowledge is as bad as my word choice unfortunately. I'm mainly a software guy, although as a hobby I'm fascinated by things like 4-bit home brew CPUs and things like that. And I do have a big interest on what is going on inside the original chip, enough to want to try to teach myself about the fabrication processes used back then and try to puzzle out that die shot. It's certainly a time waster though, so I may end up joining the retirement team in 22 years time.

If anyone is interested in having a look, I recently created a PNG showing only the metal layer.

https://sites.google.com/site/mos6561vi ... _final.png

It isn't exactly aligned with the original die shot by any means. I took a lot of short cuts when creating it. I wrote little throwaway algorithms of various kinds that attempted to snap the metal lines to a grid half the width of the metal lines and it made most of the edges square. The end result looks okay visually, and I find it interesting from the point of view of being able to fill a line with a particular color and see where that fill goes, that kind of thing. It was meant to be an aid in helping me to easily identify what the various metal lines are and certainly not to be exact. I didn't have the time to follow the edges exactly.

Here is one attempt where I was trying to color code various lines. The green are the lower eight data lines, the red and blue the two power lines, the purple and light pink the phase 1 and 2 clock lines, the orangey brown are some of the address lines, the cyan and darker pink are the lower four address lines:

https://sites.google.com/site/mos6561vi ... _coded.png

Hopefully someone else with an interest can find a use for these. I'm not likely to revisit it for a while.

[Kakemoms]

It's certainly a time waster though, so I may end up joining the retirement team in 22 years time.

Oh you are welcome to join! We will certainly crack out the workings of it then

Interesting color-map! It gives an improved overview of where the different structures are located. I have never actually looked into what kind of internal lines that the 6561/6560 uses, but this kind of shows it.

The 6561 and later 6569 both had problems with RAM speed which kind of lays it out as a "hand-to-mouth" way of routing signals through. E.g. there are no internal registers, so all data simply has to pass through on a single cycle and result in a new pixel on the screen. This is also easy to see if you work with raster-effects by using the 6502 along the 6561; it takes at least four cycles to change a specific memory address (STA or alike) so that you can use the 6502 to change color every 4 pixels at its fastest.

I always wonder why the MOS team didn't think of multiplexing two 6561 to make a 40 col "version" with slower RAM..but in retrospect of the ingenious way it was designed, they probably did. There is just so little information on the "failed" 6562 and 6564 to be found.

[eslapion]

The 6561 and later 6569 both had problems with RAM speed which kind of lays it out as a "hand-to-mouth" way of routing signals through. E.g. there are no internal registers, so all data simply has to pass through on a single cycle and result in a new pixel on the screen.

Can you explain this to me, please ?

I always assumed displaying 8 pixels of one character required parallel to serial conversion which in turns requires at least 8 registers of one bit or D-Q flip-flops or macrocells...

[lance.ewing]

I think you're right. I'm fairly sure I've already identified the shift register in the die shot that handles that. I can see that the char data gets loaded in to it in parallel and that it appears to have links between each bit to handle the shift. I'll put another png online later today highlighting the part I mean. From memory I think it had pass transistors on each of those links, which makes sense. The dot clock signal, running at 4 times the cpu clock, must be connected to those 8 pass transistors.

[Kakemoms]

The 6561 and later 6569 both had problems with RAM speed which kind of lays it out as a "hand-to-mouth" way of routing signals through. E.g. there are no internal registers, so all data simply has to pass through on a single cycle and result in a new pixel on the screen.

Can you explain this to me, please ?

I always assumed displaying 8 pixels of one character required parallel to serial conversion which in turns requires at least 8 registers of one bit or D-Q flip-flops or macrocells...

Poor choice of words. There are only control registers. I am not sure if it employs a shift register, but if it does, it is certainly of a better design than the VIA shift register..

http://archive.6502.org/datasheets/mos_ ... 61_vic.pdf

[Mike]

The 6561 and later 6569 both had problems with RAM speed which kind of lays it out as a "hand-to-mouth" way of routing signals through. E.g. there are no internal registers, so all data simply has to pass through on a single cycle and result in a new pixel on the screen. This is also easy to see if you work with raster-effects by using the 6502 along the 6561; it takes at least four cycles to change a specific memory address (STA or alike) so that you can use the 6502 to change color every 4 pixels at its fastest.

Thou shalt not post bleary-eyed on March, 32nd.

[Kakemoms]

I think you're right. I'm fairly sure I've already identified the shift register in the die shot that handles that. I can see that the char data gets loaded in to it in parallel and that it appears to have links between each bit to handle the shift. I'll put another png online later today highlighting the part I mean. From memory I think it had pass transistors on each of those links, which makes sense. The dot clock signal, running at 4 times the cpu clock, must be connected to those 8 pass transistors.

Which partially tells the answer; it takes two cycles at 1MHz to fetch the 8 pixels of data (efficiently 0.5MHz). These are output at 4.4MHz (PAL) so does not need to be held.

Now, if you actually found the shift register it just means that I am plain wrong.

[lance.ewing]

In about 5 hours, I'll be home and I hope to post something that shows the part I'm referring to and then we can decide if it is a shift register or not. To my self-taught amateur eyes, it looks like it would behave as one, but I may be wrong. The input data to it is the char data, and its proximatey to what I think is the color decoding logic seems to fit in.

[Mike]

Just for the facts:

- VIC and CPU take turns each ~1 µs: ~500 ns for a memory access of VIC, ~500 ns for a memory access of the 6502,

- each character is two CPU cycles wide: 8 pixels @ 4.43 MHz (PAL, =4x CPU clock) means one character takes 2 µs to be displayed,

- in one of those two clocks, VIC fetches the character code from the text screen (and also the colour data),

- in the next clock, it fetches the character data (8 bit) from the character ROM, or the internal RAM,

- this character data then gets serialised onto screen by a shift register.

- if STx is used to update a VIC colour control register, that can be done every 4 cycles,

- which corresponds to two characters width, or 16 pixels.

[Kakemoms]

Just for the facts:

- VIC and CPU take turns each ~1 µs: ~500 ns for a memory access of VIC, ~500 ns for a memory access of the 6502,

- each character is two CPU cycles wide: 8 pixels @ 4.43 MHz (PAL, =4x CPU clock) means one character takes 2 µs to be displayed,

- in one of those two clocks, VIC fetches the character code from the text screen (and also the colour data),

- in the next clock, it fetches the character data (8 bit) from the character ROM, or the internal RAM,

- this character data then gets serialised onto screen by a shift register.

- if STx is used to update a VIC colour control register, that can be done every 4 cycles,

- which corresponds to two characters width, or 16 pixels.

Well, I guess this sums it up.

The question boiled down to whether the chip is treating the data internally at 4x clock speed (e.g. on-the-fly) or not. If its working at 0.5x clock speed internally and then shifts the 8-bit result into a video stream or just picks a single bit (per clock) and works at it with 4x clock speed that goes directly into the stream.

My thinking was that in the latter case, the input bit would be held high or low for 8 cycles, so you wouldn't need an internal register to hold the value. I see now that this is wrong since the memory access is multiplexed the way it is and the only way to hold the input (over 8 cycles) would be to have a latch/flip-flop, it wouldn't work otherwise.

[lance.ewing]

The following picture shows the section where I think the shift register lives:

The red rectangle shows the shift register. The light blue ellipse is showing the data lines coming in in parallel. You can see them coming in to the picture at the top, highlighted in yellow. If you view the full picture, these poly and diffusion lines go back up towards the main data lines. I believe that this is where the character data comes in. It must get loaded in parallel every two cycles. Every other cycle, the cell index is loaded in to the address computation logic, which is in the diagonally opposite side of the die shot from this shift register.

The white circle shows one of the pass transistors that I believe controls the shift of a bit from one position to the next. These pass transistors are all linked to the same metal line. The signal on this line must be at 4 times the normal machine cycle. If you look at the lowest one, there is a line of poly (the lines in pinky brown) that is going off to the right and controlling an additional four other lines. Those seem to be coming down from the color decoding bit.

The rectangle in pink is showing where the three color register values are coming down. The fourth color comes in from the right at the top, highlighted in green. The mode is also somewhere near here. Those lines have come in from the top four data lines, i.e. the ones that bring in the foreground color from color RAM. So in the top right corner, we appear to have all four colors ready to be used in the color decoding. We have the character data coming down from the top left, and we have the shift register shifting out the bits. Somewhere within the parts I haven't highlighted is logic to use the bits being shifted out to decide what colors to use. The output of that must then head off to another part of the chip where it generates the actual color value from the color number chosen.

[eslapion]

@lance.ewing
You have a good understanding of this section of the chip.

Would you be able to turn that into a logic gates diagram? Ideally with a positioning that resembles the positioning on the die so one can superpose the diagram over the photo to get a feel of how it works.

Added edit:
I think you may not have been wasting your time after all...