it's a bad ide :/
1mhz and digital scope.. brrr...
in poland similar device costs $237 and noone buy it..
you can have digital scope with 12mhz bandwith (it comes as diy kit, you connect it to pc for display, software included)
and trully analog 1 trace scope for $170
you may want to look at http://sklep.pnet.pl/cgi-bin/main.cgi?pokaz_grupe=15 for details
also i'm sure you can get sth better than this digital 1mhz scope shit on ebay for less money

To greener - with regards to fonts and such....



Now, I'm not sure how it is done with video output - considering certain info is stored in RAM and certain info taken from ROM, but I know on a pic project I was/am working on (taking a TenTec 2m radio and completely re-doing the front end to it with a graphic lcd display and more control buttons) - I took a 16f877a with a graphic lcd and a parallel EPROM and it has been working great - I generated my fonts on my pc - used a program to rip the fonts to bits, and then burned them onto my eprom.

I ended up with more bits worth of fonts and graphic characters then my 877 had flash, so it worked out wonderfully. So, I propose a slight change in your design to allow for an eprom to be insterted - to have it send bits to store in the ram for a given character at a given position.

Now, I'm not sure how well this little proposal would work, but if you could make it work out, it would save space in the pic for more coding, and allow many more fonts then you can contain now, along with built in graphic sets - could make certain sprite sets very easy to deal with if stored in eprom.

ps - if you plan to keep using the pic as the interface chip, but need more pins, look into PIC18C658 or PIC18C858 or one of the other 40 MHz PIC's with 50+ I/O pins - granted it means a change of packaging style, but it would allow you significantly more flexibility based upon the design you are going for, plus with the extra pins you would not need multiplexers, which would save clock cycles from having to switch external chips on and off so that the pic can focus on getting data and putting it on the screen as fast as possible.

No. The 6522's serial port is a high-speed (capable) serial port that is synchronous. The UART is an asynchronous serial port.

The 6522's serial port consists of DATA and CLOCK. Since there is only one data pin that is used for input and for output, only half-duplex communications can occur. There is no need for a start or stop bit, as the CLOCK provides explicit clocking for the data. This is why it's a synchronous serial port.

The UART, on the other hand, is asynchronous. It has two data lines: one for transmit, and one for receive. Thus, it can transmit and receive at the same time. The downfall is that it requires a start and stop bit for proper synchronization, so that the other device(s) know when to start and stop reading the serial data. Also, since no clock is available (hence the term "asynchronous"), proper bit timing is assumed by both parties.

This is why it's perfectly possible to hook up a 2400 bps modem to a 4800 bps serial port (and you'll get garbage on the screen as a result, because of the timing differences). Had the serial port been synchronous, it wouldn't have mattered.



It really doesn't matter. Serial is just slower than a parallel interface, usually by a factor of 10 or so.



Depends on whether there would be any significant benefit to it. If the same PIC is going to be decoding the separate addresses as a command for some things, and the contents of a "command register" for other things, that seems pretty wasteful to me. But, it depends on the precise timing requirements you need on the host processors, the graphics engine processor (which is the PIC in thiscase), etc.

Frankly, if I could, I'd map everything into RAM somehow. Bank switching may be necessary. For example, a technique that is substantially faster than the serial port idea is to treat the video device's frame buffer AND register set as a separate address space, which the 6502 has a, say, 256 byte window to. Let's assume that $D000-$D0FF is the window, and $D100 is a register which controls the visible window. This gives up to 64KB of "video I/O memory." (256 bytes immediately available to the CPU times 256 combinations in $D100 = 65536 total bytes.)

So, we can say that pages 0 through 127 map to video memory, pages 128 through 254 are unused, and 255 is the video controller's register set. This can give you 256 bytes of register space to play with.

Again, this is off-the-cuff, hand-waving design here.



A sprite is a small bitmapped image which can be displayed anywhere on the screen. It usually has a priority bit controlling whether it appears in front of, or behind, the playfield graphics. More sophisticated implementations even have hardware collision detection, to enable the host processor to know when a sprite collides with another sprite, or with some playfield data.



All video hardware which does not support sprites must deal with this. For example, on the PC architecture, it is actually vastly faster to draw the entire screen in normal RAM first, making sure to draw the playfield first, then overlaying any sprite information, then copy the whole screen into video RAM.

The Atari 7800 and the Amiga was a turning point in most game machine designs. Though the mechanism differed between these systems, it was recognized that layering graphics from the "bottom up" this way was actually superior, AND it supported variable-sized objects on the screen (as you can imagine, most hardware sprite implementations have limited bitmap sizes and color depths). The Amiga had it's blitter, which was used to overlay graphics at the framebuffer level, while the 7800 did it on a scan-line by scan-line basis using a sophisticated display list technology.

I love the 7800's approach to it, as it supported as many sprites as video memory bandwidth allowed, and didn't require any CPU intervention (except to build and manipulate the display lists). Something like that could actually be used to implement a windowing environment virtually entirely in hardware, where software allocated its own bitmap space in RAM, and the video chip did "scatter-gather DMA" to build the image, one line at a time. And it offered a totally seamless mixture of true character mode display and graphics. Good Lord, Atari should have pushed the 7800 harder, and definitely should have kept that concept for their Atari STs. It was truely quite a beautiful piece of digital engineering artwork.

> No. The 6522's serial port is a high-speed (capable) serial port that is
> synchronous. The UART is an asynchronous serial port.

Not to be contrary-- but I probably could have been more clear when I said the 65c22 could be used. The question was,

> is the 65c22 serial output able to communicate with the PIC UART?

and I answered specifically the "serial output" part. Having the 65c22 take serial input from a UART is not possible without external hardware to sense the start bit and generate the clock from it. It just wouldn't be worth it. So we're talking about a one-way communication line-- not even half duplex.

So can the 65c22 be used as an asynchronous output? Yes, by having the software put the start and stop bits in as I mentioned earlier, and setting the speed so the bit rate matches what the receiver expects. The synchronous serial clock line (CB1) will not be connected in this case. After a bit is shifted out of the 65c22's SR, the data line remains at the last state; so since you end with a stop bit, it remains "marking" until the start bit of the next frame produces a transition to "space", which the receiver uses to start its internal the clock to know when to expect each successive bit. Since the 65c22's SR is fixed at 8 bits, the requirement for start and stop bits take you down to 6 bits of data per frame unless you use two 8-bit frames to synthesize each longer resulting frame (like the common 10-bit frames). Unless you use a 16-bit frame (which I've never heard of and the PIC UART does not support), you will end up with several "marking" bits after the stop bit of each frame. This wastes a little time but does not cause any problems.

The only time I've done this was for a product that could get away with 64 characters, so I used 8-bit frames with 6 bits of data. I added a negative $20 offset to the ASCII chart so we could get from $20 to $5F, and get all the numerals, capital letters, and a lot of the special characters. I think the phase-2 speed was 2MHz; so since the high byte of the T2 latch (T2LH) does not get used in this mode, the slowest standard speed I could go was 4800bps.

The faster you want to go, the lower the T2LL value will be and the more granularity you get in the speed. To go the fastest semi-standard speeds (like 115.2kbps and 250kbps) without getting framing errors at the receive end, you may have to make small adjustments in the phase-2 clock rate to compensate for this granularity.

Garth
WB6NUY

Greener: I have another idea, probably been hashed before elsewhere, but I don't know. I realize that all of my suggestions have been for hardware changes, but I am just shooting from the hip with ideas that I see as I read over how you have done it.

Obviously, your goal is driving this thing for text and graphics display, with the ability to do games.

I propose another change that I was thinking about while in the car today. Instead of a single sram chip holding the entire screen - do two sram chips.

1 sram chip would be the current display, the 2nd would be the "back buffer".

I assume you have done some game programming in the past, or at least researched it. What you essentially do is draw to the back buffer, and at a certain time, usually during the verticle re-trace you would send an instruction to make the current screen ram become the back buffer and the back buffer become the ram for screen display so that there is a seemless switch between the two.

Now, how to do this is another fun thing - I suggest you investigate a new design - this design would involve a few more IC's. 2 sram chips, some bank switching chips, at least 1 pic, possibly 2 or perhaps another cpu.

Now, what you do is you have 1 pic acting as the front end to the display, it will receive the data and put the pixels in place either as single pixels or as hard coded bitmaps of letters or whatever - this would all happen in the back buffer (well, you should be able to set back buffer operation on or off), then this pic would also have a test, you query it and it will tell you if the verticle retrace is going on, or have it send a signal to an interrupt to inform you when a verticle retrace is happening (the gun moving from the bottom of the screen to the top). At that point, if the back buffer is ready, you tell the chip to switch sram chips for back buffer and front buffer. The new front buffer will now get drawn on the screen while you do your work on the back buffer. This way if something takes a while to draw, it won't look wiered during screen drawing periods.

Now, I say you might need two pics for this - one pic to handle timing and outputting to the display, the other pic to just be an interface to the real world and handle character generation. The two pics would communicate only in so far as the drawing pic informing the other when the verticle retrace is happening.

If you were to move to one of the larger pics, you could then handle all of this within one chip, have an 8 bit parallel input along with a read/write pin, EN pin, etc. it might even be conceivable to allow for 16 bits, 8 bit data, 8 bit address to make easier access to address registers that hold flags of the current state of operation or special flags to control how video is handled - ie: instructions on resolution, color depth, etc.

Basically you would be making a more full featured video controller.

Please don't take offense to the next set of paragraphs, I have no idea how much you are aware of game programming, or graphics programming or what. Realize I am NOT a master at this, I have done a good amount of reading and still have a bunch of books on game programming (it was something I always wanted to do since I was a kid, but my drawing skills suck, and certain levels of math I am not strong in either =( ) The next few paragraphs talk about sprites and backgrounds a bit.

Now, in terms of sprites and drawing over the background and such. First of all, if you use sprite graphics, you will need to determine a specific color that is the "background" color - so that when you draw the sprite on the background, you will just not paint the section of the sprite that si the transparent background.

The fun part: The background - keeping it alive, and making it so you can operate at full speed.

Let's say you are doing a game that is screen based (not a side scroller), where action takes place on one screen, then a door is opened and another screen is started. Why re-draw the entire screen each frame? it's pointless, and cycle wasting - the way it is normally done is something like what follows (keep in mind, it's been a long time since I researched game programming in depth (been too busy), but I do remember certain things fairly well =)

Method 1:
Draw the background (a lot of times the background will be tiles, and the background will actually be a table of telling you what tile is where)
Draw the sprite
draw the foreground
- sprite moves
only redraw the background tiles that were originally covered by the sprite
redraw the sprite in its new position
only redraw the foreground tiles that need to be re-drawn due to sprite moving.

So this way the sprite will move and you have done a minimal amount of drawing to the screen. if your sprite is an 8x8 sprite, and you background tiles are 16x16 and your foreground tiles are 16x16, the most tiles you would need to re-draw would be 8 (assuming sprite is at the intersection of 4 tiles and you have 1 background layer and 1 foreground layer), and 1 sprite tile - this is a considerable savings over re-drawing the entire screen.

Method 2:

Draw background
Copy section of background where sprite is
Draw sprite
Draw foreground
- sprite moves
copy old background into place where sprite was
re-draw the foreground
copy background where sprite is going to go
draw sprite
draw foreground

When dealing with tile drawing, although this method as I recall becomes faster, I personally think method 1 is easier to implement. I am sure there are many other ways of doing it, but hopefully this will get you going.

If you can find it, you might want to look up a book from Andre LaMothe called Game Programming in 21 Days - it's an older book, back from the DOS era, but it would be more accurate to what you are trying to do.

-Tony
KG4WFX

tancor: i already suggested double buffering technique some posts ago
7 pages long, no conclusions, and counting

Yup, you are right, I just went back and read over some of the past posts (took a while to find it, it was back on page 4). Only difference was I was putting it in perspective of how greener was doing it. To be honest, I completely forgot about your post there oh well. it's a good idea either way

-T
KG4WFX

I'm a bit behind and this is my second time answering questions, so I'll be a bit terse ... my computer rebooted in the middle of a post I was doing just after dinner.

UART: I re-checked in the spec sheet. The PIC18F4220 actually has a USART, not sure if that makes any difference. However, I do want to put something "useful" together, and I'll drive the application from another PIC using the USART. See the bottom of the video2 project. (Sorta sounds like a PIC project, but I'm not far enough along to setup a 65xx at the front - I haven't even assembled an EEPROM programmer yet!!)

Future video: Some of the following talk is in my future video section along with diagram(s). Only one right now, but I'll add more - I got sick of Paint.

Double buffering: I've got a few idea sketches, and one of them is two video buffers. Besides some wiring complexity, one of the problems is replicating buffers. There is the displayed buffer and the buffer being updated. When the update buffer is ready for display, that buffer needs to be replicated into the other buffer. Not fun. An idea did just occur though - Just after switching, the two buffers may be able to be synched during the first screen redraw. One chip is in read mode while the other is in write mode. If they both shared the address lines and data lines during that redraw, the buffer replication would happen pretty quickly. Hmm... I smell lots of complexity there!!

Chip/function separation: I like that idea. I've got a PIC12F675 which might do the trick. I haven't really looked at it - it's an 8 pin DIP and I think I have 5 pins to mess with. It also simplifies everything. Both of my future ideas have separated the chips for this reason. Plus, as has been suggested, various memory address can be mapped into the PIC.

Sprites: I'm actually going to try method 2 with my "application" with the video2 design. I'm so short on memory, it's pathetic - but I think I can set aside 256 bytes for this. Thats two 8x8 sprites with a copy of whatever was in the background.

I didn't apply sprites to the double-buffering, but you're right up to a point, and I like the idea. Wouldn't keeping track of the background become an issue with just two buffers? Think about it - where is a clean copy of the background? Maybe three buffers would be needed? A clean background buffer, the displayed buffer, and the buffer being updated... just a thought.


I'm almost thinking I'll need more RAM made available too. It would be nice to have the RAM available for downloaded tiles, sprites, and bitmapped fonts - maybe even pallettes. Unfortunately, that's way out in the future, because the complexity scares me!!

I think that's everything. I'm submitting this before my computer takes over again...

A lot will depend on how you plan on handling it. I know when I experimented, I tried a variety of different methods....

Tiles in main memory, and double buffering in video ram of just what's displayed.

Tiles in an area of video memory seperate from the display memory (this was done because it is quicker on VGA cards, as I recall, to transfer bits from video ram to video ram then from main ram to video ram.), + double buffers.

Then of course the directx way of doing things - main display and as many back buffers as one could possibly desire (I've only had a use for a main and a back, but I've read some books/articles that like to utilize extra back buffers, but in its defense - the convenience is that directx will use all available video ram before spilling back buffers into main ram)

The clean copy of the background will be either the section you grab out, or via the tile matrix in main ram to let the program know which tiles belong where. The tiles themselves don't get modified, they will only get drawn.

Assuming you are using a 6502 for the main processor, You should be able to make some cool games with only 64K address space, but if you feel you need more you can creatively utilize bank swapping to gain access to other blocks of ram, similar to the way Apple did on the //e to access 128K+ (heck I have 1.5meg in my //e lol) - just be careful how you handle bank switching, you could find yourself in an area all of a sudden without half your program.

Or you can look into moving to the 65816 to open up a much wider address range.

Just some thoughts =) granted, I could just be making your life more miserable with more ideas

-T
KG4WFX

greener: you don't really need to transfer anything from auxilary buffer to main buffer, just swap buffers! this may be done by simply multiplexing CS line of those memories
problem with double buffering is when you have static display - you need to draw whole screen twice, and you have to wait for v-sync to occur before you start drawing to the next frame buffer (i assume that they are multiplexed by hardware at every frame end)
you're talking about sprites (which are complicated enougt), but seems to forget about smooth scrolling abilities

and beside - most game boxes (at least older one) utilized character display for all output - this greatly reduces frame buffer size in cost of character memory - but as every level consist of some set of chars this is no problem

double buffering technique gives one opportunity for implementing interlace - this may sound silly to consider at all, but if you're planning (like i do) 4 bits per pixel by simply adding option of shifting odd frames by a half of pixel you may extend both color depth (you may change palletes during retrace) and visible resolution

you may also consider solution used by some coin up games, where multiple buffers were used and displayed simultanously during scan
sprites and objects on one buffer, main screen on other, and bacground at third - this allows for hardware implementation of paralaxa

Candle, it turns out that most of the home game systems of old used sprite systems, some most interesting designs.

Atari 2600: 7 sprites allowed per line and 40 blocks of low res per line. The programmer had to change what was displayed on eahc line to do its thing.

A gREAT graphics chip for its time was the TMS9928. This featured a character screen background and 16 sprites. It was used in the TI99/4A computer and the Colecovision. UIf you can get the chip these days, its interfacing is quite simple and it has a TV output and also a video input where you can overlay the chip graphics.

A more modern chip about 10 years ago and still great fun is the TMS34010. That one was bit mapped fun with ploygons and draw routines. Atari used it for their Hard Drivin games and Williams used it for some great games such as Mortal Kombat. (1 and 2, 3 used it as the main cpu and 4 was on another system entirely).

The majority of arcade games tended to use TTL chips to create sprite systems, though. A good example was a game I worked on many years ago called Time Soldiers. The sprite generaltion circuit was completely made from TTL and RAM chips galore....

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

i don't say that sprites are irrelevant, or sth, i just want to put here some others things to consider
what kind of game you can do with sprites only? international karate?
i'm a bit exagerating now, but for a reason
and phleease :] don't tell me about atari 2600 poor thing has one chip (stella is the name) responsible for graphics, music and having some ram in it - everything on this system was done by cpu - one need to change display buffer each line to get something on screen at all
i was thinking about NES and SNES machines, since they were extremly popular in europe, and produced really good graphics (for that time)

Yes. The problem is twofold: one, you can't access video RAM (any video RAM, on or off screen) while video refresh is occuring in most (S)VGA cards. And with refresh rates getting into 100Hz or more now-a-days, this restriction will become ever more a problem; second, bus bandwidth is a huge limiting factor. Even PCI bus is sorely limited compared to today's graphics requirements. This is the reason AGP ports exist. And is the reason why we have AGPx8 now too, with x10 just on the horizon. Bus bandwidth is a very critical problem when dealing with games.



I do not see fault in this. Consider too that software sprites will usually need their own back-buffer so that they can restore the playfield if they're ever turned off or moved. Fortunately, only as much memory as is required to do this is really necessary. Also, remember that many video card's blitters work only in pure video memory, while others take a severe performance hit (again, due to PCI or AGP bus bandwidth limitations) to do blits from the host memory space.



This is hardly a fear. The real fear is when you accidentally bank out the I/O registers used to perform the memory banking in the first place.

That being said, I believe he wrote that he's currently using the PIC for the game engine, as that's what he's familiar with. I believe, if I read his post correctly, that he'll consider a 6502 system once he's happy with his current system (and has an EEPROM programmer ).



Strongly recommended.

Actually, if the video circuitry dealt exclusively with sprites (e.g., no playfield at all), and supported variable sized sprites, then it could do a lot. The Atari 7800's video circuitry is built on this premise, and I would love to see it resurrected. It's a beautiful design. I think it's wholesale superior to how the Amiga generated its video. It network card terms, it employed "scatter/gather DMA" instead of a single, flat, highly sequential set of DMA channels.



Say what you will of this system, the fact that the CPU did so much is precisely the reason I have high respect for it. The graphics that it DID have, considering it's 1977 introduction (or was it 1976? I forget now), was absolutely fantastic.

I actually downloaded "Stella", a 2600 emulator for Linux, and am playing a few of the games I enjoyed back when I was a kid again. Modern games sure don't have as much fun factor, especially now that I know what the guts of the 2600 are doing.



Yes, I believe they had quite a number of sprites, but also supported tiled modes too (as evidenced in any RPG game for the systems). I don't know too many of the details of these game systems though.

kc5tia: what do you mean by "tiled mode"?

atari 2600 was on polish market after atari 800xl and 65xe, not to mention pegassus (clone of NES) - so watching this graphics was nothing more than empty laught for every polish folk - this is base of my opinion...
atari 5200 and 7600 never get here, and thats real clishe
could someone put together information about all video chips used in diffrent console/coin game designs? maybe some links, so all of us could take a look at designs and learn sth from this
i've already searched the net for TMS processor, but found almost nothing

building scatter/gather dma controller from ttl chips is not an option for me, building this on fpga/cpld chip is more close to my abilities but still way ahead of my current knowledge on this subject - lots of counters i presume..
i really think this is the poit to start of simplyfying our designs back to the point where one can easly implement it in hardware