I was wondering how many people would be interested in a simple "graphics card" (It, I suppose, truly is - just not by modern standards! )

The device would support composite NTSC, PAL, SCART RGB and VGA signalling.

Most graphics modes would be tile based, because of ram limitations, and palletized to 4, 16 or 256 colours (It is obviously reduced as resolution is increased)

The device would itself be exposed as 4 "IO Ports," them being

0 - Control
2 - Address
3 - Data
4 - Data++

Control is used for things such as setting resolution, and reading/writing to the I2C bus (Used for storing the firmware, determining what type of display is connected, and for VGA monitors, for reading the EDID ROM)

Address is used to set/read the 16-Bit address pointer

Data is used to read/write a given address
Data++ reads/writes a given address, and increments the data pointer

The device would attach to the motherboard using a 16 pin connector

Vdd (3.3v) - I could make this 5v if it's an issue
D0
D1
D2
D3
/INT
D4
D5
D6
D7
VSS
WR / /RD
/CS
A0
A1
VSS

The 3.3v could be a problem. It's only, even if I put the 3.3v regulator on the board, going to be able to put out 3.3v signals

If this is an issue, one solution would be to put a 74xx245 on the motherboard to buffer the bus, however, it already has it's own doing level translation. On the other hand, if your processor needs this buffer, then it is likely it's operating slowly enough for it not to matter

Comments?

Where's the datasheet?

I think we'll need more information before we can say for certain whether it'd be appealing or not.

[quote]
Where's the datasheet?
[/qoute]

I haven't made it yet

Scratch the 16-pin connector, and add 4 more

Vdd (3.3v) - I could make this 5v if it's an issue
D0
D1
D2
D3
/INT
D4
D5
D6
D7
VSS
WR / /RD
/CS
HLD
VSS
A0
A1
A2
A3
VSS

I might specify that the connector is allowed to be longer, for cards which wish to export their internal memory directly (For example). It would be nice if this became a "Simple AGP" kind of connector. I certainly intend to design other (More powerful) cards with better capabilities.

I'm currently designing the hardware. I'll then write up the preliminary datasheet, and post a link to it here

I probably won't be using one of these for the Kestrel-2, because I already have too much invested in its current graphics architecture.

But, I can see reviving the Kestrel-1 design and using one of these things.

What will its performance be when working with raw bitmaps?

Ideas to consider (not necessarily now, but for the future):

- Make the control, data, and data++ registers 16-bits wide, so as to allow either a 6502 or a 65816 to work with it with equal facility. The 65816 can work with an 8-bit device, of course, but to do so you have to drop the registers into 8-bit mode first. That cuts graphics throughput in half. I can discuss my ideas in greater detail if you wish.

- Support a block-move page of memory, again in support of the 65816's MVx instructions. Basically, this is a whole page that is mapped to the data++ register. This allows for even more rapid placement of long strings of graphics (7 cycles per byte).

Preliminary datasheet available Here!

I'll put more complex information in, like how exactly to go about doing an I2C read/write, following the fabrication of the first PCB hardware. I intend to also provide some example demos for use on a 6502 CPU



The device itself is now down to 1 address line, so just address and data++

I can't see any issue with making "fake 16-bit" registers by making that single address line A1 rather than A0. This wouldn't be a huge disadvantage for 6502 based systems, either



I can't see an easy way of doing this that isn't going to end up feeling horribly hackish.

How big is the speed difference between doing it all to the same location veurses a page copy?[/url]

Easily a factor of two in performance in all but the most tightly coded examples.

However, don't worry about it. If you are down to just two registers, then it's a simple matter of using A8 instead of A0 or A1 to address the chip. Although your 2-registers now sucks up 512 bytes of I/O space, at least half of the space is usable for hammering graphics data into VRAM.

I like the idea of using a single address register. It allows for upward compatibility with larger address spaces. As I envision it, writing an address to the chip should be something like:



I like it.

Ive calculated the maximum bitmap resolution to be 320x200, at 16 colour palette mode.

This consumes a whole 32,000 bytes, leaving 768 free for the registers and palette

This is REALLY squeezing it. You would have to load up the display code into the display area, and utilize the fact that the adaptor will initialize itself in "Ignore the screen; display plain black" mode to allow you to then update the display without it showing junk.

And, at this size, you need 1.875 mbyte/s to update the screen every frame. The only way you would manage this is to feed it using a DMA engine, considering that the controller can only respond at about ~2.5MHz. And thats if you hit the bus in the correct phase.

Hmm... Maybe I should develop a DMA controller to acompany it

One point that I'll make is that I don't envision a standard interface to the card, partially because the the interface is directly accessing the Propeller's internal memory.

On the other hand, it's not touching any special processor registers, partially because the Propeller has none in hub RAM.

As long as you don't assume the location of the bitmap font is constant, I suppose I could maintain a consistent interface.

If somebody implemented this on a non-propeller CPU, they would have to implement their own ROM bitmap font, however. Additionally, different cards would need different firmware images uploading to them.

I suppose it would have a "halfway house" of standardization: You would need a driver for the card to set video modes, etc, but on the other hand, you wouldn't need a driver for drawing to it, provided you understood the set mode. You could probably implement a GEM like GUI pretty well (That is, each application gets it's own "desktop"). You might have some issues if you want to put multiple windows on the same desktop, if one app wants a 16 colour paletted mode and another a 24-bit true colour mode (On a future card)

That could actually work. I suppose the best course of identifying the card is to put an 16 byte UUID as the first entry in the register space, partially because it's simpler than me handing out IDs myself, and partially because it's much smaller than people assigning their own names

If you go for 256 x 256, your x and y addresses can stay at one byte. Same with a 256 color pallete.

That is the stunt Game Plan used.

The Propellor has 32K internal RAM? KEWL.

_________________
"My biggest dream in life? Building black plywood Habitrails"