13 Aug
2012
13 Aug
'12
2:36 p.m.
On 08/11/2012 04:12 AM, emanuel stiebler wrote:
On 2012-08-10 14:58, Andrew Lynch wrote:
Yes it was though I think the Rainbow used the Z80 as an IOT processor.
The video was CGA level
not VGA. Doing VGA video makes finding compatible monitors easier (CGA
(9pin)went the way of
the dodo). That does not require you to do VGA level video.
VGA is video side timing issue not so much the bus side. But pushing a
lot of bytes through the 7220
at about no less than 800NS per byte (likely 10 to 20x that) to move a
megabyte is going to take 10s
of seconds as it's all port IO and thats not all that fast.
Each color plane needs to be 38400bytes, if you want 8BPP. That means
at least three planes.
to fill the memory the first time will have to move 115kb, at S100 8086
speeds thats likely
to take a while, a long while.
All the PC video above CGA was memory mapped as CPUs can read/write ram
far faster than
funnel everything though an IO port with status check. If you uyse 2
port ram then
the 7220 primitives are useless, and all early the PC drivers did that
in the CPU not the
graphics board logic.
Allison
Does anyone know of an X Window server
implementation for the NEC
7220 GDC?
The chip has several names including the Intel 82720, NEC 7220A, NEC
7220D,
uPD7220, uPD72020, etc. Essentially this graphics chip was the main
rival
to the MC6845 prior to the domination of the IBM PC architecture for
microcomputers.
(I read some of the replies ...)
So, you're not looking for the graphing capabilities of the 7220,
you are looking for a dumb frame buffer.
And if you cut it down to it, just use a mc6845 to do it (if you
insist on old technology) or go back to the FPGA idea, which would be
my first choice for a frame buffer on any bus.
I had a 7220 on the mc68000 back then (actually one 7220 for every
color bit) and the interface to the frame buffer was dog slow.
BTW, wasn't the 7220 also in the rainbows? There should be a lot of
documentation for it there ...
Cheers