Graphics data in main memory?

[barrym95838]

gfoot wrote:

If you are interested in this kind of thing, it's well worth reading about how the Atari 8-bit systems did all this. Their video hardware was way ahead of its time.

I have read several articles and sincerely admired ANTIC (and POKEY too) from a distance for many years, but I never found room on my bedroom desk for Atari hardware (it was already covered with Apple ][+ and Commodore 64 hardware). Display lists seem like a very flexible and elegant way to handle text and graphics.

[BigEd]

I think there's a couple of ways in which thinking of bandwidth can be quite useful
- the bandwidth needed from RAM to keep the video system working
- the bandwidth needed from the CPU to RAM to update (enough of) a full frame in good time

Sprite hardware helps with the second, as it's a cheap way to animate the visible pixels without moving data around. DMA might help too, or indeed a blitter.

Another approach is to offer tile-based graphics. The CPU updates tiles or indices and the video system pulls together the visible frame.

To some extent I feel that sprites and tiles both tend to push game design in certain directions, but they are a good way to get more from less.

[gfoot]

Sprite and tile hardware can also help with bandwidth because the sprite and tile image data can easily be stored in separate banks of RAM... if you can afford it!

[BigEd]

Good point! One way to look at bandwidth is as the product of bus width and bus transfer rate. So, if you can use a wider bus, or more busses, you get more for a given transfer rate.

Another useful idea is decoupling. If two systems have to run in lockstep, or if they have to use the same bus widths, that can be a limitation. It can be useful for the video system to access memory with a wider bus than the CPU does, or to run at a different speed. Ideas above about posting writes into a buffer can be seen as decoupling too - decoupling the write-as-requested from the write-as-performed.

[Greg816v2]

BigDumbDinosaur wrote:

Looking back on it, although the VIC-II was seen as a “revolutionary” video controller at the time, it was really a primitive device—poorly thought out in several ways, and something I could never get excited about. The 40×25 text display sucked for programming purposes and the lack of a hardware cursor meant the kernel had to artificially generate one, eating up a not-insignificant number of clock cycles during processing of the jiffy IRQ.

The VIC-II's hi-res mode was a royal pain to program due to the fact that pixel locations were not progressively addressable, as could be done with the C-128's 8563 VDC, and the 8568 in the C-128DCR.

Yep, I was just reading a doc about the VIC-II that outlined how no matter the mode, it made the exact same memory accesses - very clever for cost saving and simplifying the chip, with the side effect that graphics mode was laid out just like character mode.

The 40 column limit was always a pain, I was jealous of other systems with an 80 column mode. I ended up writing an 80 column emulator in assembly that used hi-res graphics mode and split each 8x8 cell into two 4x8 characters. With an effective width of only three pixels for each character (leaving space in between the chars) it was just barely readable. But, I could at least log onto BBSes that assumed 80 columns and get some readable output.

Quote:

Speaking of graphics, for a first unit build, I suggest you consider not doing on-board video and if you do, do text mode only. Unless you have significant experience scratch-designing and building computers you may get yourself in over your head with the complications that will ensue and become discouraged. In other words, you want to avoid creeping featurism. As you gain experience, you'll be better able to anticipate and avoid problem areas, especially in matters related to timing.

That certainly makes sense! I have built some very minimal breadboard 6502 designs with 2 line LCDs, but regardless don't have much plans for graphics. I'd love to have 80 column VGA output, and some kind of command line OS.

I'm just fascinated with the different ways video was accomplished in the old systems!

[BigDumbDinosaur]

Greg816v2 wrote:

Yep, I was just reading a doc about the VIC-II that outlined how no matter the mode, it made the exact same memory accesses - very clever for cost saving and simplifying the chip, with the side effect that graphics mode was laid out just like character mode.

With Jack Tramiel in control of Commodore, everything was about cost. The VIC-II was an outgrowth of that.

Quote:

The 40 column limit was always a pain, I was jealous of other systems with an 80 column mode. I ended up writing an 80 column emulator in assembly that used hi-res graphics mode and split each 8x8 cell into two 4x8 characters.

Simulation of an 80-column display was something that a number of people did, with varying results. Fundamentally, it was limited in clarity due to the limitations of the available video monitors. I tried such an 80-column simulation on my C-64 in hopes of having a proper text editor for writing code. It was an eye-watering experience after a while and I reverted to the “stock” display, and lived with it. I wasted no time getting a C-128 when they became available, just so I could have a legible 80 column display.

Quote:

With an effective width of only three pixels for each character (leaving space in between the chars) it was just barely readable. But, I could at least log onto BBSes that assumed 80 columns and get some readable output.

As I recall, many of the Commodore-oriented BBSes of the time could accommodate the C-64's 40-column display. You had to select your display from a menu before proceeding. Once I had the C-128 and suitable terminal software I was no longer seeing a BBS through a 40-column “keyhole.”

Speaking of terminal software, I used something called MicroVT100 on the C-128, which not only accurately simulated a DEC VT-100 terminal, but even set up VT-100 glyph data in the VDC to support all the VT-100 character set. Plus it remapped some of the keyboard decoding so characters that weren't native to the C-128, such as the UNIX pipe symbol, were available. With that, BBS usage become much more enjoyable, limited only by Commodore's dumb 6551 simulation in the kernel and the resulting error-prone and slow serial communication.

Quote:

BigDumbDinosaur wrote:

Speaking of graphics, for a first unit build, I suggest you consider not doing on-board video and if you do, do text mode only.

That certainly makes sense! I have built some very minimal breadboard 6502 designs with 2 line LCDs, but regardless don't have much plans for graphics. I'd love to have 80 column VGA output, and some kind of command line OS.

There are several text-mode solutions available that will drive a VGA monitor with 80 columns. This is one I've built for testing with one of my POC units. It uses a TTL-level, TIA-232 interface to connect to the host, which of course means the host has to have a compatible serial port.

Quote:

I'm just fascinated with the different ways video was accomplished in the old systems!

Those old systems were timing nightmares. Looking back at it, I'm amazed they actually worked and were stable, especially the C-128 and its dual-processor, dual-video, triple-personality design. Says a lot about the engineering abilities of the blokes who designed them.

[barrym95838]

BigDumbDinosaur wrote:

The VIC-II's hi-res mode was a royal pain to program due to the fact that pixel locations were not progressively addressable, as could be done with the C-128's 8563 VDC, and the 8568 in the C-128DCR.

I can imagine that cost may have been an issue ... or maybe a very tight schedule, or both. Woz (undoubtedly working under similar constraints) created some eccentric magic on the Apple ][ video generator in 1977 using off-the-shelf ICs, but his circuits required even more software contortions. Still, the Apple ][ easily had the most featureful display of the '77 trinity, and he was kind enough to provide optimized firmware routines to deal with the frustrating quirks of the display map, so the casual user didn't need to resort to tons of POKEs as was the case with the VIC-20 and C64.