Basically, text-mode, but instead of monochrome characters, it supported, say, 16x16 pixel full-color bitmaps.



The TIA chip in the 2600 was the direct ancestor of the GTIA and CTIA chips used in the home computers that followed. I agree that the GTIA/CTIA chips are superior, especially when driven with ANTIC. Otherwise, it'd be like trying to generate video on the Amiga by having the CPU slam the Denise chip, and ignoring the Agnus chip completely.



I agree. These systems were overwhelmingly superior to any 8-bit computer or console of their day. (Bit of trivia: the 7800 is so named because 2600 + 5200 = 7800; the 5200 was not 2600 compatible, while the 7800 was.)



You might want to check out "The Machine Room" website. It lists a lot of older 8-bit consoles and computers, including giving some technical details about them. It's not really deep stuff, but it usually can give some insight on what keywords to look for on Google. For example, I never knew the Atari TT's blitter chip supported a 16x16 bitmap "halftone" RAM in its register set; I thought it was purely a two-source blitter. Until I visited that site.

URL: http://www.machine-room.org/



I haven't done a detailed analysis of what would be needed, but I suspect at least three counters would be needed. I agree that it is not a design suitable for discrete TTL components though. I also will not be implementing this (at least at first), since I also lack the resources for such a highly integrated design.

Personally, in my own design, it's going to be inspired primarily by the Atari ST's "shifter" chip and by the Amiga's Agnus design. Basically, in the spirit of Shifter, the video memory bandwidth remains constant between all supported video modes. This permits simpler DMA hardware (in particular, only a single DMA channel is necessary). There are two horizontal resolutions: 640 pixels (256 colors), and 320 pixels (65536 colors). Both are fixed palette. I suppose if I wanted to support a 16-color mode, I could also handle a 1280 horizontal resolution too. But I don't really need that, and then, I'd need to support a palette register system to make it truely useful. Too much complexity for me.

The Agnus influence comes from the simplification that the video fetch pointers do not reset themselves at the end of a video frame. Regular vertical sync interrupts that the CPU must receive are used to reset them under CPU control. I was also considering supporting a general-purpose raster compare interrupt system too, so as to support split-screens and 240 pixel vertical resolutions as well.

In 320 pixel mode, each pixel consumes two bytes, containing 5 bits of red, 6 for green, and 5 for blue. Typical of how PC graphics cards display 64K colors.

In 640 pixel mode, I have the following layout: RRmGGGBB. The RRm field forms a 3-bit red field. GGG forms a 3-bit green field. BBm forms a 3-bit blue field. Although three 3-bit fields normally creates a 512 color display, the 'm' bit (which stands for magenta) is shared between the red and blue channels, thus halving the number of colors actually viewable to 256. I've done some testing of this mechanism on my own computer using software simulation, and the initial results are quite nice. I'm going to do more testing of course. But it gives a clean, 8-shades of grey, and discoloration of cyans and yellows isn't visible to my eye. I think I made a good compromise solution.

:]
kc5tia maybe you use 5:5:5 scheme and save that one bit for alpha channel? :>

Well, I'm not so sure, to be honest. If I hadn't spilled my guts about my design ideas, I could have marketed such a video system to the folks here, and maybe even elsewhere, I don't know. A CPLD or FPGA with this video architecture in place would probably sell moderately well here, but I'm not sure it'd be enough to recover development costs. (just curious -- quick poll -- who'd be interested in such a design for the 6502 and/or 65816? How much would you be willing to invest in such a component? Would you be happy with a plug-in card instead of a single chip solution? Would you be willing to pre-order these components? Pre-order or not, what kind of quantities are you considering?) Most people here seem to build just quick one-off designs, and they're happy with that same design for years and years. Then again, I'd have to write the programmer's reference manuals for it, which would just contain all the same information anyway, so maybe it's still a sellable idea.

That being said, if I DID go that route, I'd probably use that transparency bit primarily to implement sprite transparency, rather than framebuffer transparency. Framebuffer transparency requires some kind of genlock, which I personally don't have any experience with (but I can get experience with it if there is commercial interest in it).

What are your thoughts on this? Are you (the reader) interested in NTSC/PAL as well as VGA frequencies?

Candle: If you would like a list of some of the chips used, I can always go out to my game room and look =) I have about 22 coin-ops ranging from old old (space invaders, pacman, startrek,etc.) to new (House of the Dead, Revenge from mars, etc.)

KC5TJA:


I must have mis-understood, I was under the impression that greener was going to use the pic for handling the graphics and such and ultimately create the game base of the system using a 6502 type cpu - at the time when I had written it, the only future design I had noticed on greeners site was :



But I see a section that has been added to the video - "An early application experimenting serial communication and sprites " that I don't remember seeing before.

Also....


as I recall, you can actually write to video ram during a refreshcycle - this is what causes the shearing of the display that happens if you don't wait for the verticle sync (at least in mode x)
*EDIT*: let me make a slight modification to this paragraph - rather then just saying "during the draw cycle" I should say rather at periods in-between when pixels are being drawn - at least this is how I understood the issue, I may be very mistaken in how it works, but I just wanted to clarify my understanding, if I'm wrong, if you could explain it in more detail I'd be most appreciative - my favorite thing is to learn and understand things, not give wrong information

But I can see your point in multiple back buffers beyond 2, but, I had already mentioned that using video ram for sprite storage was a common decent practice - I didn't really see a use for generating so many extra back buffers with directx, but I can see how having one backbuffer with just background another with foreground, etc. would work out fairly well.

I had never been to that machine room site, thank you for the link, I am enjoying it very much

I also appreciate all of your input on some of the way these older systems did things, there's a lot of the older technology I am not nearly as familiar with, and reading your posts have been wonderfully informative.

In terms of a solution for video access, I think it'd be a cool idea, especially if it could be flexible enough to work with a variety of processors, so if it were general enough that as long as you sent it the right instructions/data at the right time it would work. I'd love it, definitly save a lot of time since video output is definitly not my strong suit (although I understand and follow most of what I have seen I still have a little trouble with the timing diagrams, especially for composite NTSC output) I'd say if it did vga that'd be great, I'd love to have access to NTSC though.

A single chip solution would be nicer then a plug in card, but I'm flexible (I say single chip as if I were to build something small, and be using video display to just see what was going on or for debugging or routine maintenance, it's easier (and cheaper) to carry a 4 inch video screen that I use with my video cameras then it is to find a cheap small VGA compatible unit =)

Quantity - well, that's a tough one, can't say how many I'd want or use. at least 2, possibly 3, possibly more if I ever come up with something cool. Since I do this (tinkering with 6502, modifying kits, etc.) as more of a hobby I wouldn't have a huge quantity need. But, it would be nice to have if ever made available.

_________________
-Tony
KG4WFX

as far as i am concern i _MIGHT_ be able to order small quantity of such chips/carts (50 or so, not so important if it would be single chip solution - more important if it would fit in 100mils raster) but i cannot guaratee anything
framebuffer transparency would be essential here and genlock capability is as simple as providing indenpedent pixel clock as i told you and trigered counters for pixels...
but this is deep future for now...

Question to Greener:

Ok, I've been looking over everything and the timing info and I'm just confused about one thing, I'm hoping you might be able to clear it up for me.

The sync pulse at the end of the frame that represents the gun moving back to the top of the screen. Looking at:

http://www.epanorama.net/documents/pc/vga_timing.html

is that the P pulse? I think it is, it seems awefully small to me, but hey, video is not my area of expertise =)

_________________
-Tony
KG4WFX

I was going off what he wrote here. I know he is planning on a 6502-based system in the future, but his immediate needs are for the PIC system.



The shearing occured when you placed something on the video card's internal data bus at precisely the same time the video dot shifter was reading data from the bus. As a result, either incorrect data or NO data was displayed during that fetch cycle, due to bus contention.

However, except for the original IBM VGA and some early Trident VGA cards, I haven't seen this ever be a problem in years and years. Most video cards are intelligent enough now to insert wait states as appropriate, after filling a (usually) 16-byte deep write-queue FIFO (as I understand current hardware implementations; the FIFO being flushed every horizontal sync period).



I guess I just don't see the difference between what you're describing and what I'm describing. If you have one frame buffer, and one "back buffer" per displayed object, then to render the screen, you need to write into the frame buffer from lowest to highest priority object (where high priority objects appear "on top of" lower priority objects) memory. Only the rectangle which is "dirty" needs updating; this minimizes CPU and/or blitter overhead. But the point is, each object has its own frame buffer which can be drawn into. The screen might be 1024x768, but the mouse pointer itself might be only 16x16.

Modern GUIs extend this to ALL visual elements, by describing their screens in terms of scene graphs and even "software" display lists (the former is used by Apple's MacOS X, for example; display PDF).



NTSC and PAL are technologically more difficult for me. It would actually be much easier for me to use "luminance" and "chroma I&Q" instead of R, G, and B channels for NTSC video (I'm sure it's the same for PAL, but I have absolutely zero experience dealing with PAL at all). Otherwise, I'd need to find some way to convert R, G, and B into YIQ form. I'm sure there are dedicated chips to do this; if so, that'd make things somewhat easier for me.

NTSC monochrome would be even easier for me to support, though.

BTW, many people are using 6502s and 65816s clocked at 1MHz or 2MHz still. This bus speed really isn't suitable for 640x480x256 color displays (it'd take anywhere between 2.5 to 1.25 seconds just to update the whole display; plus, drawing individual characters on the display will be quite visible and noticable). Therefore,

* Are you looking for unified memory architecture (e.g., system RAM and video RAM are the same), or split RAM architecture? If you do want a UMA, what kind of system RAM bandwidth are you willing to afford?

* What video resolutions are you interested in? What kind of color depth are you looking for?

* If the hardware can provide any services to make writing the software easier, what would those services be, ideally?



I'll wait until I hear back from more people, if any at all, before making a final decision. It's just that I don't want to invest $300 into a development kit, only to "just barely" break even, if that. In fact, even if only 6 chips were purchased and I priced them at $30 each, I'd still be taking a huge loss on the project.

Perhaps I can augment my lineup with a good and solid general purpose chipset too, including a much needed update to the 6551 ACIA (gosh, that's the limiting piece of hardware I'd ever seen for the 65xx-family support peripherals!). Heck, maybe I can even finally give the 6502 community the ability to use USB 1.1 devices too. And then there's the all-important DMA and sound capabilities that I'm sure quite a few would like to have as well. SID chips are getting hard to find now-a-days, and the Yamaha(-clone) chips are limiting in their own little ways too.

Any suggestions for what you'd like to see most? If I can amortize my investment across a whole family of peripherals, I think that'd be best.

You know, it's funny -- Garth Wilson has been trying to get me into doing this for months. Maybe now is the right time.

Mike, if possible, I'd like your input on this as well. What do you think? What kind of market would be for something along these lines? Would you be willing to promote these products to other 6502 entheusiasts in the hopes of getting higher sales? If so, what kind of volumes are we looking at?

kc5tja: What I would need in video capability...

Well, there are multiple levels depending on what I am playing with....

Video:

Most important - more likely for my needs ATM - text capability, basic, rudimentary graphics, it'd be nice to have a slot for an eprom that I could just drop in that would be coded with my own custom 8x8 or 8x12, etc graphics - obviously the different sizes would need to be stored in certain locations to make it easier for the controller chip to know where something is. Color not vital, but if basic 4 or 16 colors are available, great - black and white is the key - this type of need is covering the situation of "I need to see what my thing is doing, I need to see what the data it has collected is, I don't need fluff to get the job done".

Not so important - 256 color, 320x200 or 640x400 resolution max, this is play zone, to try things, experiment with graphics and capabilities.

Least important - the capability to do bitblitting, transparency bits taken into account, quick efficient page flipping, etc.

Sound: To me, this is not a vital area, I don't mess with sound to much, but I'd love to play if the opportunity arose. This would have to be a simple inteface where it would deal with most of the overhead for the sound. One important thing were tho if I were to have a sound interface chip would be the ability to feed it a frequency number and be able to tell it to start/stop and have it generate on its own without extra communication from the main processor (if you would like to know the details of why this is important, shoot me a message off list, the project isn't important enough/related enough to 6502 stuff to warrant getting into the details here)

Networking - ACK, this would be awesome. I would love to have networking interface capability, although a tcp/ip stack would need to be written by someone. Most of my house is wired in some way for ethernet, it would be sweet to be able to communicate / control experiments from my computer without having to go out and do it, plus it would allow for more freedom with other experiments.

USB - well, this would be cool, but I don't know the USB protocol at all, so I'm really not sure if this would be useful to me

chip based solution to CF storage - this would be nice, something where a single chip, perhaps a few caps and resistors and the connector bar and the chip would handle all of the communication, all the host software would need to do is query to see if there is a card inserted, and if booting, inform the controlling chip where to look for data, and for saving, send it the information and file name and it would then store on the card (would be nice if in DOS format) bits.

Any of these using shared memory would be nice, especially things like the CF unit, put all the bits in a block of memory and tell the controller where the block is (or have a predefined block) and tell it to do the rest while the cpu goes back to doing what it needs to do.

Now, on the other side of the world - one of the things that confuses me fairly easily (it's one of those things that has always given me trouble, which is why I have steered away from it in my ideas/designs) is shared memory between preipherals and the CPU - ie: video ram shared in main ram - I don't understand how to make it work right without causing a major problem - docs on making this work, or reference material for it would be wonderful - so those of us that have been splitting things up could now possibly save space and make our designs more efficient

_________________
-Tony
KG4WFX

Hi all! I would have posted a message this morning - except my computer froze when I clicked the preview button. Go figure, you update the software for your DVD player and everything goes downhill from there.

My son has also gotten enough candy to keep me going for weeks and weeks! (c:



You can still get the spec sheet for the TMS34010 from the Texas Instruments web site. Not sure if that's what you were looking for though.



That is correct. I'm just starting where I can, and the video seemed appropriate. I think I'm pretty close to a workable design that I can bring to my homebuilt 65xx system.



I'm just a bit impatient, that's all. (c:



Believe it or not, video isn't my thing either. Just to qualify, here's the vertical timing section:



My understanding is that the Vsynch is just the signal to trigger the retrace. You'll note that the back porch adds at least 1ms of time. Beyond that, I really don't know.



I'm not sure that there is much of an interface for a compact flash card, is there? It just emulates an IDE interface. There is definately software to write - but others have already done this.



Me too. That's why I'm planning everything separately. Plus, 320x200x256 doesn't leave me much memory for a program!

I would, however, love to hear about it.



I will ultimately be interested in having NTSC -or- VGA. (Actually, wouldn't HDTV be cool for games?) I'm not sure I'd actually purchase anything, however. I'm squarely in the trying to figure it out category and am not willing to put too much money anywhere.

Maybe later when I have real plans... I think one of my solutions will scale to a full VGA; maybe beyond that. However, it's a multi-chip solution, and I'm leary of the wiring that will need to be done.

Right now, I've got a lot of ground to cover - and the tinkering has been wonderful for my education. I would have never guessed that in something like 2 months I'm not only doing simple electronics, I'm producing video signals! I also see how much I don't know and need to know.

> Color not vital, but if basic 4 or 16 colors are available, great - black
> and white is the key - this type of need is covering the situation of "I
> need to see what my thing is doing, I need to see what the data it has
> collected is, I don't need fluff to get the job done".
>
> Not so important - 256 color, 320x200 or 640x400 resolution max, this
> is play zone, to try things, experiment with graphics and capabilities.

Has anyone here tried the graphics LCDs? How easy are they to use? (Much easier than video circuits for NTSC or PAL, no doubt). I've used the intelligent character LCDs several times. They virtually all interface the same way, and it's quite easy. Is this true of the graphics LCDs? How about color?


> > chip based solution to CF storage - this would be nice, something where
> > a single chip, perhaps a few caps and resistors and the connector bar
> > and the chip would handle all of the communication, all the host
> > software would need to do is query to see if there is a card inserted,
> > and if booting, inform the controlling chip where to look for data, and
> > for saving, send it the information and file name and it would then store
> > on the card (would be nice if in DOS format) bits.
>
> I'm not sure that there is much of an interface for a compact flash card,
> is there? It just emulates an IDE interface. There is definately software
> to write - but others have already done this.

One that looks really easy to use is MultiMediaCard in SPI mode. The MMC is smaller than CF, has only 7 connections (including power and two grounds), the connector is under $2 at Digi-Key. And for the latest, at least two companies are introducing MMCs this quarter with a gigabyte in this card that is approximately postage-stamp sized! And since you can use it in SPI mode like a flash chip with no FDC, it's just memory and you can put things in there any way you want. You don't have to use a FAT or anything complicated (unless you want it PC-compatible). This is more suitable since we're mostly using 5V and don't want to have to do a lot of level-translation for 3V parts or wire up the 50 pins of CF. Atmel's DataFlash MMC is 5V-logic-compatible, but I don't know that other manufacturers' will be, which is why I'll be using an LM339 14-pin quad comparator between it and a few 65c22 I/O bits.

As far as I can tell, the VGA-resolution graphical LCDs take (digitized) VGA signals. There appears to be a 44-pin standard which includes 18-bits for color information, syncs, power, clock, etc.

You still need a video refresh circuit of some kind to make use of most graphical LCD panels. Plus, they're still very expensive. A relatively small (I forget exactly how big it was; I think 10" comes to mind) fixed frequency 640x480 unit with 262,144 color support costs as much as a brand new ViewSonic 17" SVGA monitor that can handle 1280x1024 and 16.8M colors.

Is this the SmartMedia connector? I've actually have an old 2MB card from an old Apple digital camera. I can't find it, but I swear the older cards are labelled as 5V. The newer ones, however, are definately 3V (I just looked). Oh, sorry! - you've already answered that concern using the Atmel's card anyway. Comments are out just for validation, then.

Regarding the CompactFlash - correction, the specification I'm looking at is CF+ so this might be null and void - states in section 4.3 (page 30) Vcc = 5V +/- 10% or Vcc = 3.3V +/- 5%. I actually see the FAT (or whatever standard format) as being a bonus. This way, the EEPROM I write essentially can boot from the CF card. I take the card from my machine, move it to the PC, compile some stuff, save it to the CF card, move it back the machine, and power it up. Done! No special hardware involved beyond the EEPROM. Actually, if I were clever, I could probably do EEPROM updates with some funky write sequence to initiate it.



I did a little hunting too, but never found anything besides various LCD products - for instance, the CrystalFontz site. They don't have color, and 320x240 is around $150 for single orders. That's the cheaper ones too. Ouch!

Garth:

In terms of graphic LCD's, are you talking about the non-vga ones? ie like these:

http://www.crystalfontz.com/products/index-grph.html

although I am not sure where to get color ones, I have used these types. They are fairly easy to use, the fun thing is remembering to think in columns rather then rows (the 8bits you send is 8bits in a column in a given row).

I've used the 128x64 w/ neg volt generator.

And of course, if you're talking about the ones with a vga input, that answer was from others =)

but I still have no idea where to get colors ones like the one I listed.

_________________
-Tony
KG4WFX

> In terms of graphic LCD's, are you talking about the non-vga ones? ie like these: ...

There are literally scores of companies, if not hundreds, making LCD modules. Crystalfontz is not one I've heard of, but that looks like the general idea. One manufacturer I tend to favor (from our business, where we've used their character LCDs) is Hantronix http://www.hantronix.com/2_1.html

One of their many models, the HDM3224-5 is a 320x240 monochrome graphic LCD whose interface apparently consists of a 4-bit data bus plus data shift clock (like synchronous serial, but you send four bits at a time instead of one), a data latch signal, and a "begin scanning" signal. The seven lines mean you could interface it with less than one whole port of a 65c22, with no supporting logic, and no attention from the processor is needed except when you're sending new info to display. The diagonal viewing area of actual dots is 4.75". Without going into analog, NTSC, or VGA, Hantronix' graphic LCD modules go from 120x32 to 320x240 and 640x200.

They do also have color LCDs which don't require any input except when feeding new information. The HDM64GS24C, for example, is 240x64, and has 16 address lines, 8 data lines, and 6 lines for memory and I/O select, read, and write.

> for instance, the CrystalFontz site. They don't have color, and 320x240
> is around $150 for single orders. That's the cheaper ones too. Ouch

In my situation with so many projects I want to do, I might prefer to pay the $150 than to spend months researching and building something complicated to feed video to a TV or other monitor.

>Is this the SmartMedia connector?

That's the one.

i have to say that 44 pin connector is not standard one, most of vga/xvga lcd panels wants their data to be serialized you have few clock lines, and 8 bit of data - transfer is r then g then b, and so on until you reach end of line