Video display controller with VGA output

[DerTrueForce]

My opinion on the matter are thus:
While this conversation is interesting to spectate, I don't particularly care whether Doom did full-display redraws, or partial redraws, or delta redraws. It did what it did well enough to create a considerable stir. I do think this conversation highlights the reasons that GPUs became the dominant technology.

Looking to the present, I think being able to access the raw bitmap is nice. I think hardware acceleration for such things as sprites, scrolling, text rendering, and drawing primitives(line, circle, etc) are probably more useful for the types of computers that the members of this site are likely to build. The Gameduino series do some of these things, if I remember correctly. I'm not sure if they do all of them.

[BigEd]

> probably more useful for the types of computers that the members of this site are likely to build.

I wouldn't be comfortable summarising the members of this site - they are varied, and many are quiet. I think mostly of text-based computing but I like to see graphical patterns and graphs. I have also played some games in my time.

I would expect, in the fullness of time, over the course of years, to see everything here: textual displays, bitmap displays, tiled displays, displays with sprites, displays with VLSI engines, with FPGA engines, with TTL engines. Even vector displays.

[BigEd]

There's a project using micro controllers which might be relevant. I've put it in its own thread:

• Slightly OT: an impressive video subsystem on an 8 bit micro

[mojo]

BigEd wrote:

There's a project using micro controllers which might be relevant. I've put it in its own thread:

• Slightly OT: an impressive video subsystem on an 8 bit micro

Interesting, they use a couple of AVRs. One to generate the video display and one as a blitter.

One idea I had was to use dual port RAM for this. The 6502 only accesses RAM on every other cycle anyway and most RAM is much faster than that, so you could probably do a decent 8 bit/pixel bitmap streaming via CPLD, with the other port used for a GPU made from an MCU.

[GARTHWILSON]

mojo wrote:

The 6502 only accesses RAM on every other cycle anyway

?? If you do for example,

Code: Select all

        LDA  FOOBAR1
        ADC  #<some_number>
        STA  FOOBAR1
        JMP  <label>

with the code in RAM and the variable not in ZP, that's already 13 cycles in a row of RAM access with no let-up. It should be pretty common to have 50 in a row with no let-up. I think the percentage of dead bus cycles is something like 25%, not 50%. There are ones like CLC, INX, etc. that are two cycles, with one being a dead bus cycle.

[BigEd]

(I imagine mojo meant 'every other phase' - with an adequately fast RAM, the 6502 can share it with other machinery, with no loss of performance.)

[mojo]

Aye, that's what I meant.

[drogon]

mojo wrote:

Aye, that's what I meant.

It was a common technique used by early computers like the Apple II and so on. That's why their clock frequency looks weird, but it's a good fraction of the NTSC (or PAL) line rates. It's also why you need memory that's (over) 2x as fast in a 6502 system than you might initially think. Effectively you get dual-port RAM "for free" - not free in that you need additional logic (like the tristate buffers in the early NMOS systems) and more "glue" but a good way to make video if you get it right ... the 6502 gets full access on one half cycle and the video generator uses the other half cycle all synchronised to the clock.

Which (and someone correct me if I've mis-remembered) the UK-101 didn't quite get right and you got "snow" over the screen when writing to it due to some fractional timing issues.

-Gordon

[Chromatix]

I think some CGA hardware had a similar problem. There was a software workaround but I'm not certain whether it eliminated the problem (at a performance cost) or only reduced it.

[whartung]

Chromatix wrote:

I think some CGA hardware had a similar problem. There was a software workaround but I'm not certain whether it eliminated the problem (at a performance cost) or only reduced it.

As I recall using the BIOS to run CGA had the snow problem, but stuffing data straight in to the frame buffer did not.

[unclouded]

drogon wrote:

I settled on a library called SDL which is ostensibly cross-platform, however what it gives is a buffered "poke pixels at the display" type of interface. So I poke pixels into it then call an "update" function which magically blits the software framebuffer I have to the real screen. It can do this very, very fast - even on a Raspberry Pi without using the GPU.

Of-course after doing it, the cool kids told me I was doing it wrong, however it worked very well for me (and still does today), but I know it's "wrong".

I used SDL on the Nokia N900 and it was faster and more responsive than Hildon, which was using the "accelerated" features of that platform. SDL was so quick that I was doing 60fps animation with Ruby. IIRC, the N900 is an ARMv5 so Ruby should be pretty slow in theory.