For a 320x200 display, you need 8000 bytes for B&W, and 24000 for RGB color.
If you're willing to make a subtle compromise, you can stick with 65536 colors and get away with 16000 bytes. For 99% of the applications you might want to run, it'll look the same.
So far, the ATMEL ATMega162 looks the most promising. It has 1k of SRAM and 16k Flash. Font data can be stored on the FLASH. It also has enough I/O to allow external shifting and host PC I/O.
Folks, don't forget that powerful bit- or nybble-serial interfaces can be made too. For bit-serial devices, you can use a VIA's serial port with a very high baud rate. True, obviously parallel is better, but the lack of direct access to the video RAM can be exploited to your benefit by transferring medium-level to high-level graphics commands instead of raw bitmaps. You basically get a graphics coprocessor for free.
Even if you don't have the resources to support a complete set of high-level commands, you can get by quite nicely with a set of medium-level commands. For example, you can implement Bresenham's run-slice line drawing algorithm in software, and the actual mechanism to draw the lines in the coprocessor. A single byte to the graphics controller can not only draw up to 64 contiguous pixels in whatever color you want, it can optionally advance the Y-coordinate up or down as needed for the next slice. Statistically, the worst-case line you'll ever draw will be a diagonal, 45-degree inclined line, where the number of bytes sent to the controller will be equal to the number of pixels wide or high of the line. For
all other lines, the number of bytes sent to the controller is guaranteed to be less than its major dimension.
The run-slice command would look like this:
Code: Select all
Bit 7-6: Command bits
00: Other commands
01: After drawing the slice, advance the minor axis coordinate by 1.
10: After drawing the slice, retard the minor axis coordinate by 1.
11: After drawing the slice, do nothing.
Bits 5-0: Number of pixels in vertical or horizontal slice. 0=64 pixels.
Obviously, the controller would need to know in advance whether horizontal or vertical slices are needed, and another set of commands would need to be sent to set the initial (x,y) coordinate, drawing color, and line pattern, if any. Some hypothetical examples:
Code: Select all
Set pen's X coordinate:
CMD XL XH
Set pen's Y coordinate:
CMD YL YH
Set pen's foreground or background color:
CMD ColorL ColorH (or ColorR ColorG ColorB if needed)
Set pen's line pattern:
CMD PatternL PatternH
Set pen's transparency mode:
CMD
If you're thrifty enough, you could even get it to support sprites in a higher-level than most video subsystems do. So even though the bandwidth between the video system and the main CPU is restricted, you might still end up with a net performance gain due to the parallel processing that results (e.g., while the graphics processor is drawing the current slice, the 6502 is likely to have already figured out how long the next slice will be).
The hardware is actually not too hard. The heart of the system is 74ACT715.
Even then, that chip can be replaced with custom counter arrangements and such. It looks complicated because there are so many chips you have to deal with. But the circuit concept is actually very, very simple. The 74ACT715 just replaces a lot of chips with a single chip.
In a nutshell, vgate clears the counters and hgate is used to enable the counters. The counters step through RAM sequentially, providing the necessary dot data to the shift register. The hardest part was enabling a way to update the RAM from the host in between the necessary access to keep the shift register moving dots.
Another advantage of taking the frame buffer off-line from the CPU: this problem disappears entirely, enabling the CPU to run at full speed, all the time, everytime.
--
Samuel A. Falvo II
AFTER 3 page long discussion have you came up with something?
