6502.org

kctia:


Again, you can also use digitized composite. If you store your pixels as 16 bit words, you can have 6-bits dedicated to luminance, and 5 bits each to the I and Q color burst phases. Or, just store the raw DAC output sequence in RAM and spit it out an 8-bit R-2R DAC. You literally are not going to get any simpler than that. Monochrome is trivial, though color support may involve some math as you need to figure out the composition of the chroma and luma signals.

Am outputting to plain RGB at NTSC frequencies. Such a unit outputting NTSC and VGA will get higher marks from hobbyists instead of locking into one or the other.

The C64DTV does it with a 4-bit luma and 4-bit chroma DACs, so a 5-bit DAC is all that is really required for this type of stuff.

Never heard of the C64DTV. Throw a link?

Quote:
8 bit port with signals compatible to 65C22 (use the register/data addressing fields trick used in the TMS34010 where the first byte is the register specifier and the second byte is data.)

I don't understand.

Simpler interfacing to use such a graphics board with an SBC.
You send 2 bytes in a row
Byte 1: register addres
Byte 2: register data

and use those in a variation thereof.

Quote:
An eprom space for graphics to be references from the FPGA. Test patterns, game graphics, you name it. This way, you dont have to spend precious ROM space on your 6502 uploading graphics into it. Have this rom up to 27C801 which gives 1 meg by 8 of graphics fun


Umm...not sure I understand this either. What do you mean by "references from the FPGA?" Why not just use a huge addressing capacity instead? Something like the VIC-II chip's ability to address only 16K of video memory, but most of those bits are programmable but fixed based on various VIC-II registers? (E.g., sprite address pointer bytes, for example, or character map pointer, or character font pointer, etc)

None of the above. Back when I was designing on this game system called Neo Geo, all graphics where sprite based as 16 by 16 tiles. You could select from 65,356 of these tile graphics. The basics for a sprite anyways would be:

SpriteTile#
SpriteX
SpriteY
SpriteXScaling (Neo Geo did these on the fly by a hardware lookup table)
SpriteYScaling

The idea being the 27C801 would store all the graphics you want, then you can simply call them up.
PutSprite(Graphic#325,Xpos320,Ypos2)

Quote:
USB, tis a must as well.

I'll leave that for a microcontroller to deal with -- that has no place belonging inside the FPGA itself, unless that was its sole purpose.

The FPGA would be in effect a programmable graphics board. More versatile. 8 bit port for the SBC, USB for people who want to address it via usb, I2C for the same kind of thing. Versatility, ya know...



Quote:
Do you think it could be done to the point of less than $150 per board?

In mass quantities, perhaps. Not in singles.

I differ. The test board is $150. The chip is $23 in single quantitites. I estimate that a board utilizing the specs would be around $129, single quantitites. or less. If it gets higher than $150, then simply buy the test board from above and program it in the methods then sell that!

Your best bet would be to just output at NTSC, and then include a scan-converter circuit for VGA then, because I'll be honest -- NTSC and VGA are so far apart that they're not even considered remotely compatible. The only thing they share in common is vertical sync frequency.
http://www.hackaday.com/entry/1234000153073548/

http://en.wikipedia.org/wiki/C64_Direct-to-TV

to name just a few.
OH -- I see what you're talking about. Yes, the program I had in mind for the ATmega32s were going to rely on the 6522's port-A automated handshake mode. The data-available and data-ack signals were going to be sampled every 8 pixels, so it would support 144KBps best-case data transfer throughput. Since video RAM is 2K per chip, the need for the more dynamic features doesn't exist, since the CPU can (in theory at least) bit-bang video memory with plenty of time to spare.

A similar interface would be relatively easily achieved with an FPGA as well, but to be honest, you can't do it with a simple alternating address/data/address/data sequence, because you run the risk of losing synchronization. therefore, I'm using a 9-bit port, where the 9th bit indicates that you're loading an address versus transmitting normal data.
You and I need to exchange notes. I had no idea you were on the NeoGeo's hardware design team. All of my experience comes from Commodore hardware (and limited Atari hardware, but only indirectly, via the Commodore-Amiga).

The idea that I had for the FPGA-based solution was that I was going to have a 12.8MBps bus, so that I could deliver a real 640x480 16-color display, or 320x480 256-color display. Inspired by Jay Minor's work, the display data was going to be broken up into 8 bitplanes, each of which is independently enabled, with unique DMA fetch pointers for each plane. When an idle "time slot" is encountered, the CPU is allowed access to the frame buffer. Obviously, the CPU has access during all sync/retrace periods too. Thus, enabling all 8 planes results in the slowest CPU access rate, while a monochrome display results in the fastest. (Well, while still being able to display something.)

But here is where my idea differs from most: each bit plane is its own monochrome sprite. Each sprite contributes a different weight to the color look-up tables -- hence, sprite 0 contributes bit 0 of the pixel number, sprite 1 contributes bit 1, etc. Therefore, you can have 8 monochrome sprites per line with no discernable playfield, OR, you could have 4 monochrome sprites per line with a 16-color playfield, OR you could have 2 monochrome sprites, an 8-color sprite, and an 8-color playfield (3 playfield bits + 2 monochrome sprite bits + 3 8-color sprite bits = total of 8 bits to CLUT), etc. Sprite depth priority is, therefore, controlled exclusively by how the CLUT entries are loaded.

Also unlike Atari and Amiga-style video chips, I was planning on supporting having sprites be able to be retriggered on a single scanline. Hence, though you have only 8 hardware sprites, you're allowed more than 8 sprites on a single scanline, IF your CPU is fast enough to keep up (which a 4MHz 65816 ought to be, especially if a 1.19MHz 6507 can do it in the Atari 2600).
But, how many sprites are allowed on a single horizontal scanline at once? How is this communicated to the graphics chip? It sounds very much like a display list (a la GTIA or Amiga's Copper) would have made much more sense. Indeed, the Atari 7800's display list system is *dang* slick, and I've also strongly considered that approach as well.

kc5tja: I wasnt on the hardware design team. I worked for SNK for 5 years after a 6 year stint with Romstar. I had some experience in the programming and helped rewrite the programming book but the coding I did never made it out to the product level. There were some auxiliary projects I was involved with such as a ticket dispenser for FECs, a driving controller and a mechanical crane game.

The Neo Geo is an interesting design all its own, it is an upgraded version of an older game system made by Alpha Denshi. It is neat being a sprite only system, no backgraound graphics planes. The Neo Geo used the same basic concept but added in a scaling lookup table ROM aqnd integrated about 150 chips into 3 customs. The low level programming included toolbox calls to the main rom, so you were able to use sprite and bookeeping calls for anything.
the Neo Geo used 380 possible sprites in a list with up to 6 sprites on a single scan line at any one time. The sprites per line approach I didnt like from seeing the Atari spec sheets. It makes your processor have to work much harder to keep things going an dkeep its list in its own memory. I prefer the graphics processing system to have its own RAM with the sprites attribute list and you merely update it as needed. Yup, a display list.

One useful Neo Geo system command was the CHAIN command. You set a single target sprite, then you CHAINed each suceeding sprite to that first one. You then moved the one single sprite and they all moved with it. Fantastic for scrolling backgrounds.

The sprite palletes were a tad bananas. Each sprite could be 16 colors and you had two pallete tables. The first would allow up to 256 colors with a secondary pallete table giving 32,768 colors.


For this video thing for work, I wasnt considering sprites as my work usage is a series of static test patterns with set colors for checking monitors and DVD players. If I wanted to get motion video, I would go for a .AVI clip embedded.

The XESS looks like a darned good bet, especially on the hobbyist level, like ours. $150 with the proper programmming would give us a toolbox level graphics system. Conceptually, it is the next step up from Darryl's implementation with the ATMEga as a text display.

For a simple arcade usage, I do like the EPROM socket with all the graphics in there. Entirely possible to run an SBC6502 with a display controller and come out with an 80s or 90s level graphics and gameplay.

San Diego, you are some 80 miles from me, am in Riverside county. Drop on by some weekend. Neo Geo stuff is quite packed away, though

To add to the festivities, www.digilient.cc offers FPGA boards for 50 bucks or so.

http://www.digilent.cc/Products/Detail. ... ogrammable
VERY yummy. Can see about adding an NTSC outboard to this pup....

Their older XC95 I want to use that chip since it is a 10 buck chip from Digikey. Make THAT into a 50 buck video board. Need a test board using the XC95108 then....

URL not found from my location; domain doesn't resolve.

The first link didn't work, but the second one did.

Daryl

Well, that's a set of CPLDs, not FPGAs. Think of CPLDs as sitting half-way between PLAs and FPGAs -- in fact, they're usually implemented as a set of PLAs internally connected by a central interconnect of some kind.

And, like PLAs, they're *fast*. So while the logic density isn't nearly as high as an FPGA, they can operate at rediculously high clock frequencies.

Spelling error -- corrected link is as follows:

http://www.digilent.cc/

thanks, No brains on my part for the bad url.

Bummer for the day, I do like the XC95 tester they have, but it is long gone and out of production.

Got my own decision today to strike differently a tiny bit. Might have to make a pay deal with anyone on here who can program the buggers. am going to do my own board design and work a pay deal to get it programmed. the upshot is also that the finished code will be on here along with the board design to create a cheap and easy video for under $50.



Basic things to it:

1. Board is the standard size from ExpessPCB. (3 boards for 51 bucks, need we say more?)

2. the XC95801 is the weapon of choice.
Reasons:
a. The design on the elm page is using it, so it WORKS.
b. DigiKey sells it for $12.10 in quantities of 1 and it goes down to 10 buck something in a quantity of 25.
c. The package design allows for a socket with regular pins. Means it is NOT a flatpack for soldering (ok, this be important, specially in the roll your own. this is the reason I knocked out the Spartan and Coolrunner series from my design)

3. A variety of input ports for various needs
a. usb (work)
b. I2C (why not?)
c. 8 bit parallel port with control lines

4. static screen RAM, 1 chip. hopefully, DIP package.

5. 27C801 maximum graphics EPROM. I am assuming that most of us have EPROM programmers at this point in time. It is also easier to have the eprom socket than to throw in a flash RAM or something. Cheaper, too. (you can throw in a smaller EPROM for a tinier bit set, but tis nice to have the capability, k?

Once the hardware board design is ready to boogie, I will have it up here for everyone.

Daryl, I love your text generator which this has some conceptual basis on, but for the work project, it has to have some graphics bang. And there is simply nothing else on the market low cost enough with the bang for the buck needed. So call it a part 2....

I think you meant the XC95108? 84pin PLCC. However, the part you quoted for price has 15ns delay. You may need to look at the 7.5ns version, which sells for $28.65
try this chip: Cypress 512kx8 SRAM w/12ns access time - CY7C1049B
Only drag is that its a 36pin .4" SOJ package. I have been unable to find a socket for it.
Thanks... it is a basic text display but is quite useful. I had one person modify it by using the on-board shift register vs. using the 74HC165!
You can also opt to use the SPI port vs. parallel input and save even more space, parts, cost!!!

95801, I get dyslexic sometimes

The slower seems to work with that one guy's link of showing onscreen. The pinout should be the same so it is a socketed upgrade if needed. Hacker's delight.

thank on the RAM idea, that kind of RAM should not be too bad to handle for soldering. It is the BGA chips that we cant handle as hobbyists....

Am going to add in a JTAG connector for programming. Can't seem to find a consistant pinout for it, though. Can you guys throw me a consensus there?

also for colors, am going for 15 bits, 5 pins for each color, allowing for 32,768 so you allocate 2 bytes for the colors. Or it can be reconfigured to palletize and run final output that way . I need the colors more for the testing since the guy's board only does 512 colors. Not as useful...

CY62128BLL-70SXC at Digikey. SOIC package. Much easier to solder

2.72 in quantitites of 1.

quantity is zero right now, but I emailed concerning lead time.

this should work out best....