Retrosys Pong, graphics stack questions [attachments]

Sachiel7

Hello everyone,
Well, I said I was going to post some more info on the Retrosys as more developed and here it is. I've finished the circuit board for the system (yay!) and it looks pretty good to me. I definitially learned several things that need to be improved/modified in future designs.
Anyway, I wanted to code a basic game to test out a few system funtions, and so I wrote Retrosys PONG.
Its a very simple two player pong game. I'll include a ZIP of the code in this post. (And maybe·a screenshot)

So now I've gotten a bit more comfy with how things work on the prop, and typical programming practices.
But, I'm also running into some walls.
The main one that's bugging me right now is that the size of the stack for the graphics driver is just so big, it really limits the size of other objects, namely,
I cannot include the Hydra Sound System (HSS) in any of my projects that use the graphics
drivers as well. HSS doesn't take up too much space. Granted, music data can take up a few kb, but the driver itself fits in about ~2kb.
Anyone have any suggestions for getting HSS to run with a graphics engine?
Thanks,
Here's the Retrosys stuff:

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-

Michael Popoloski

That is precisely the reason why I am putting 4 MB of SRAM on my video game console that I am designing. I realized almost as soon as I got started with the Prop that 32KB just wasn't going to cut it. With 4MB, I can do high color bitmaped graphics, and a high quality sound system. At least in theory anyways. I have yet to see whether I will be able to pull it off.

Forrest

That's pretty impressive that you've got it working on the 1st prototype.

Why are you complaining about memory - what about those SRAM chips on your board?

Michael Popoloski

It was my understanding that he did not have SRAM, just flash memory and EEPROM. But maybe I am wrong.

Sachiel7

The front 4 chips are 1MB eeprom, clocked at a max freq of 1MHz, a little slow for realtime video applications, but good for sound and other data.
The rear 4 chips, however, are 4 8Mbit DataFLASH chips clocked at 20MHz, which may be ideal for video data. I'm thinking of writing a new 8-bit graphics driver that uses double buffering from the DataFlash.
Just off the top of my head, if I have a 256x192 rez video page where each pixel is one of 256 colors, then the size of the page is: 256x192 pixels x 8 bytes/pixel / 1024 KB = 48KB
The Dataflash outputs data on every low clock so if its running at 20 Mhz, it will output 1 bit every 10 Mhz, so it has an output flow rate of roughly 1220 KB/s. Dividing the video page into this transfer rate: 1220/48 = ~25 frames per second.
It's probably not going to work out this smoothly, but its a good starting point. The chips are capable of accepting data on the rise of the clock, so a second screen page could be written as the main page is being fed.
Does this sound somewhat feasible? Its a start, at least. The graphics would require no stack space on the processor for any graphics video pages or tileset data, just enough room for the object that streams the data and updates it to operate.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-

Sachiel7

Oh, the woes of the Graphics driver.
Well, I am trying to understand the Propeller Library objects as best I can, but since most of the essential stuff is in Assm, its not too easy for me (to me its all foreign)
Here's where I am at, currently:
I'd like to have a flat 256x192 resolution main video page that is stored on external memory. This memory page consists of color values for each pixel and are streamed to TV output.
However, when looking into the Video registers, I see that it is a system specification that the two modes, either 32 bits by 2 color or 16 bits by 4 color are used.
Ok, I can live with that. I choose the 16 bit / 4 color mode.
So, my first question is exactly how the propeller reads and/or outputs the video signal.
In both Spin and Assembly, I see the WaitVid command being the primary way to pass video data out to the generator, and therefore on-screen.
Thats cool. So, the thought comes to my mind, how exactly is this data treated? Is this output as a line of pixels? I would assume its much more involved than that, looking at the TV driver.
So, after trying to poke into the TV driver and see exactly what it entails, and being spooked a bit, I have come to the primary conclusion that the TV.spin object itself is most likely still a feasible
output driver. After all, it seems to only be applications using the Graphics.spin Object that require sooo much stack space, thus killing the possibility of too advanced programs, or too much upper memory data storage. (upper being Prop RAM)

So, I'm trying to understand the structure of the bitmap 'packet' that the TV driver reads. It seems to me the TV driver is optimized to how the Video Generator has been designed to function, ie, theyre really isnt a 'better' way to do it, other than the possibility of customizing it to read a different format of bitmap data.

In short, I've done alot of poking and prodding. All I'd like to do is write a new Graphics driver that allows me to take advantage of the TV.spin object, but that stores the bitmap data on external memory.
I'm sure I would at least need a bitmap buffer section of Prop RAM to shift in longs of bitmap data from external memory for the TV object to read; this would mean less tweaking the TV object.

I would simply like a basic driver to accomplish the following functions:
-Clear Page
-Copy Page
-PutSprite
-SetPixel
-GetPixel

There might be a few more, but thats all I'm interested in right now.
I include the Clear/Copy functions for double-buffering capability.

I am also curious how the double buffering is currently handled. From what I can tell, when the Graphics driver copies the page, it simply shifts the base page to the main page.
If the TV driver is (I assume) constantly reading the main page and displaying it (by sending the appropriate data to the Video Generator) how is it that we dont have issues of the page being written whilst being read at the same time? Is there a command that 'pauses' the TV driver from outputting data? Will the Video Generator continue to output anything if it isnt being fed data? I would assume not.

I know I probably sound like I'm jumping all over the board here, I'm just trying to understand alot of this, and its new to me.

So, the data fed to the Video Generator consists of 4 colors at a time and 16 2 bit patterns of pixels. Again, how is it that more than four colors are achieved in a 16 pixel stretch?

I understand its still too early for some solid in-depth documentation of the Library Objects, but I am starting to feel quite lost.

Anyone have any ideas how to begin tackling this beast?
Thank you all so much for the support you have offered so far, it has helped me overcome several bumps along the way, and I greatly appreciate it!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-

Michael Popoloski

If you have not done so already, I strongly suggest that you pick up the Game Programming for the Propeller Powered HYDRA book. It discusses a ton of stuff regarding the Propeller chip and graphics, and with the price drop it is now a sure-fire buy.

Sachiel7

Yeah, its on the waiting list (ie, payday)
Until then, Ive been tinkering with a few of the modified graphics drivers that people have been including in their demo programs. There's a raster-tv object that Dennis Ferron included in his Sand particle demo (BTW - Thanks Dennis, its really cool!) which does what I'm trying to do, just doesnt expand past a 4 color palette, from what I can tell.
Still, the fact that my Pong game could be expanded to more complex physics, background music and sound effects, and take up less RAM is promising, even if it means being limited to 4 colors to begin with.
I think the main issue I'm finding is that I'm still trying to determine the function of several of my onboard components. I had intended for each of the EEPROM banks to be dedicated to holding runtime data, such as video tile sets, audio data, etc. But I'm finding the speed of the Eeprom limits what I can expect it to do. For example, at 1 Mhz, youd be transferring about 122 KBs. If you'r tiles are in the format such that you pass 4 bytes of color palette addresses (1 long), then 16x1 longs of pixel data·(16x16) then a typical tile is 17 longs or 68 bytes (which I like the sound of). So, at 122 KB/s, thats 1837 tiles/sec. Now, this might sound great, hey, thats pretty fast, I'll admit. And thats plenty of tiles, but lets take a look at how many tiles we expect to push in a frame. Any game usually includes a tilebased level screen, at least, lets take a typical platormer for example.
If the game has a tiled background, that alone is 16x12 tiles, or 192 tiles fore the background.
Lets assume we will have several items on top of this layer that are about equal to two more backround layers. So rounding up, thats about 600 tiles per frame.
1837 tiles/ sec / 600 tiles/frame ~= 3 frames per second (= bleh!)
So, obviosly the eeprom is not going to be pulled from as such. However, if we reserve a chunk of Prop RAM for a 'tile buffer', to hold, lets say·64 tiles, thats·about · * 68 / 1024 = 4.25 KB, which is fairly feasible.
Things like this are my current topics on mind, as I have yet to finalize any type of defined data system.


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-

Ym2413a

To get (HSS) running with a graphic engines, you will have to use another engine that doesn't eat most of the chip's RAM.
The stock engine that comes with the propeller IDE doesn't allow for much else to run in the background. So your best bet would be using another engine for graphics.

Thanks.
--Andrew Arsenault.

Mike Green

As you've noticed, there's not a lot of documentation on the WAITVID instruction and its use other than what's in the Hydra manual. It's primarily a shift register with some extra logic to do color on a TV. It is inherently limited to 4 colors per pixel with the colors supplied per group of 16 pixels (for 4 color mode) or 32 pixels (for 2 color mode). Note that every group of 16 (or 32) pixels can have a different set of colors. It is possible to sync several cogs together so that a WAITVID instruction executes simultaneously in each of several cogs so that the number of bits available per color is doubled, etc., but no one has yet done that yet. Several cogs have been synced together to produce a higher bit rate and resolution, but not for color depth.

Sachiel7

Yeah, I've been tinkering with Dennis' Raster TV driver a bit more, and I've gotten it to do a few things.
I'm eagerly (and impatiently ) awaiting the arrival of my copy of 'Game Programming for the Propeller powered Hydra'.
I understand how Waitvid works, sort of. Shift in 4 colors and 16 pixels. Ok. But how exactly do I know what to shift and when? For example, does Waitvid go from each group of 16 pixels on the screen in order, and then loop around to the top again? How do I know timing wise which 16 pixels on the screen I'm writing?
Lets say I have a raster-based system that has a upper screen buffer display[noparse][[/noparse]screensize], and lets also say just for convenience I have automatically setup each·two longs·of the display buffer to be the exact format of data to pass along to Waitvid.
Here's what I would think might feed this to the screen: (this isnt intended to be perfect spin, just spin-psuedo )

repeat
 repeat counter from 0 to 6144 step 2
  Waitvid(@display[noparse][[/noparse]counter*32],@display[noparse][[/noparse]counter+1*32])
 

However, I obviously feel that this is too simple to be the case, and is likely wrong. What happens if somehow you get out of sync with where Waitvid is updating on screen? And what happens when you have more than 4 unique colors in the same 16 pixel stretch?
So, I assume this is incorrect. Could someone try to explain how to know which chunk of screen memory to pass to Waitvid when?
I still cant quite wrap my head around the assembly chunk of the TV driver enough to understand quite whats going on.
Anyway, Im working on a new 'Galaga' style space shooter, which I hope will contain Music/Sound FX, Color graphics, and two-player. Note that I may be taking advantage of the memory onboard the Retrosys to free up some Prop RAM, so depending on how things end up, it may not be as easily adaptable to everyone's system.
A HYDRA version could easily be expected, however, so we'll see.
Thanks for your support everyone!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-

potatohead

I've been working on the color depth thing. It's gonna be fairly easy on VGA, I've no joy yet on NTSC.
(some help, with driver basics, below)

***I understand how Waitvid works, sort of. Shift in 4 colors and 16 pixels.

Yep, you get to queue up your pixels, and it handles the timing. You can change how often it's loaded, and the scale (timing) of each pixel.


***Ok. But how exactly do I know what to shift and when?

You keep track of it, yourself. Essentially, you can start the superframe, then perform each task with the waitvid instructions, knowing they are working 16 pixels at a time. One area of confusion for me was how the entire video signal is generated. The sync signal levels are encoded as colors! So, your tilemap needs to account for this, setting the color maps appropriatly during the sync / overscan times.

You break a video frame into the core task elements, build the signal with the right timing, then having done this, you know where you are from task to task. It's all linear. You can output information to HUB memory along the way, if you want. So, a vertical blank flag, scan line counter, etc... are done by your driver as it draws the signal.

There is a fair amount of time between waitvids, for computation, fetching pixel data, writing to HUB ram, etc... There is more time during horizontal blank, and a lot of time during vertical blank.

Lay out the entire signal, in linear order, then break it into discrete tasks, then apply the waitvid command to the problem, changing scale, pixel clock (rate), etc... for each task. When an entire superframe is done, then you do it again. Interlaced signals have two slightly different frames, video game like signals are not generally interlaced and thus output the same kind of frame over and over. With the former you get one full image every 30th of a second, with the latter it's every 60th, which is why the video game people like this. (no motion blur)



***For example, does Waitvid go from each group of 16 pixels on the screen in order, and then loop around to the top again?

All it does is shift pixels out. What those pixels represent determines how the TV sees and syncs up to your image. (frame)

You get to represent sync pulses as pixels! In other words, you are in charge of nearly the entire signal. The Propeller will handle color generation issues (and that's the problem with increasing the color depth for me currently)

So, you output a proper signal and the TV finds it! It's all a linear stream of signals. Of course you know that, but the key point is this:

You use the waitvid commands, in sequence serially to display everything, even the sync, etc... At times, you change the scale and colors such that you are able to generate sync pulses of the right size. At other times when you are doing graphics, you then set your colors, by tile, such that all four are in the display ranges, not sync, and set the scale differently. During blanking times, you can also set the video output to be suppressed as well. (blank lines, etc...)


I've been going through both the TV driver and the high res VGA with cursor drivers line by line to grok what's happening. It's the only way to get where you can build your own signals. The cool thing about this is you can build nearly any signal. The bad part, unlike nearly any graphics engine, is that you must build the entire signal, if you want to do things other than what the drivers provide for.

The biggie for color depth appears to be getting the color burst stuff in sync. When you fire up more than one video generator, the color bursts appear to just do their own thing. (I've not figured this part out just yet.) The next time I get to work on the prop, I'm gonna have one generator generate the color, and another generate just intensity. There still will be four colors per waitvid, but with more intensity levels possible. This should also allow for more than 6 shades of grey as the video signals add together.

Another biggie, that does have a nice solution demonstrated by Chip in the high res VGA driver, is to get the COGs running at the same time, in sync. I suspect a full solution to the color depth thing is gonna require intraCOG communication as the drivers may well vary in function, thus will not remain in lock step executing the same things. I think I'm gonna use the I/O pins for this as they are nice and fast. (so we waste a pin, instead of wait for hub memory accesses...)

Probably more than you want to know at this stage, but at least you will have some scope and direction! If you stumble onto something, post it!

Sachiel7

Ahh, that expains alot! Thanks,

I think I need to learn more about the kind of signals I'm trying to generate.·I have no major experience with NTSC signals (I'll admit)

I almost wish someone would release a SPIN code version of the TV driver, just for interperative purposes.

Anyone know a good tutorial on the parts of an NTSC signal?

EDIT: Forgot to add guys, but I've got the first Retrosys Desktop Wallpaper ready!

Have fun!

(There's a widescreen and standard size)

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
-=Sachiel7=-



Post Edited (Sachiel7) : 4/4/2007 2:21:57 PM GMT

Ym2413a

Try this website. It's got a lot of nice slides.
http://www.ntsc-tv.com/

Hope that helps.
--Andrew Arsenault.

Ym2413a

Another thing. Maybe I'll work with you on the (HSS) support for the RetroSys.
Since you got extra memory to spare. The player could just handle samples and music data from external memory.

Really I was hoping to do this with the Hydra. Although it doesn't come stock with extra memory so I can't really support it. (Since most Hydra users don't have the Sram upgrade) I'm not even sure if it was released yet.

rokicki

Dunno if it was released, but Andre was showing me the SRAM module at the ESC.