PROJECT: XVIDEO Driver For HX512K (UPDATED TOOL NO LZ YET)
Jasper_M
Posts: 222
Okay, I'll be in army for some time. It's only six months (confirmed now), so I'll be free 4.1.2008 (D/M/YYYY). No updates. I can code on most weekends.
UPDATED TOOL
NOTE THAT THE XVIDEO DRIVER ARCHIVE DOESN'T CONTAIN THE UPDATED TOOL!
-binary output
-more accurate (the .NET framework has a bug getting brightness or maybe it's just doing something weird...)
-ACO file that has all supported colors (for Photoshop swatches)
-sprite sheets
No LZ yet, I noticed a bug in the decompressor that I didn't have time to fix.
FIRST REAL RELEASE!
208x192 resolution, full color
16 sprites (4 32px sprites per scanline)
2 independently scrollable tilemaps (one below sprites, one over them)
background color
A highly WIP tool for converting sprites & tiles.
DEMO PROGRAM WITH MARIO GFX INCLUDED
Original plan was to make this 12FPS, 224px horiz. resolution, but now it is 15FPS and 208 horizontal resolution.
Pixel loop is still the same 3-instruction one:
2 cogs involved, rendering cog and rasterizer cog (renderer cog renders tilemaps and sprites and writes to SRAM, rasterizer cog reads from SRAM to NTSC). Renderer cog works on active scanline while rasterizer cog is reading, and either writes or skips (fast-forwards) a scanline on every HBLANK. 4 real NTSC scanlines are used to render one scanline.
SUMMARY OF THE OLD TEXT: XVIDEO is an NTSC driver I'm making for the HX512K Memory expansion card. It uses counters for nearly all operations on the SRAM (only exceptions being programming it initially and loading addresses). There have been problems with keeping counters in sync etc. In the previous thread was a test program too, just to see if the rasterizer driver's counters would keep in sync.
EDIT: Removed some old text which is not valid anymore
Post Edited (Jasper_M) : 9/17/2007 4:29:37 PM GMT
UPDATED TOOL
NOTE THAT THE XVIDEO DRIVER ARCHIVE DOESN'T CONTAIN THE UPDATED TOOL!
-binary output
-more accurate (the .NET framework has a bug getting brightness or maybe it's just doing something weird...)
-ACO file that has all supported colors (for Photoshop swatches)
-sprite sheets
No LZ yet, I noticed a bug in the decompressor that I didn't have time to fix.
FIRST REAL RELEASE!
208x192 resolution, full color
16 sprites (4 32px sprites per scanline)
2 independently scrollable tilemaps (one below sprites, one over them)
background color
A highly WIP tool for converting sprites & tiles.
DEMO PROGRAM WITH MARIO GFX INCLUDED
Original plan was to make this 12FPS, 224px horiz. resolution, but now it is 15FPS and 208 horizontal resolution.
Pixel loop is still the same 3-instruction one:
pixel_loop
mov c_r0, ina
waitvid c_r0, #%%2
djnz c_px_ctr, #pixel_loop
2 cogs involved, rendering cog and rasterizer cog (renderer cog renders tilemaps and sprites and writes to SRAM, rasterizer cog reads from SRAM to NTSC). Renderer cog works on active scanline while rasterizer cog is reading, and either writes or skips (fast-forwards) a scanline on every HBLANK. 4 real NTSC scanlines are used to render one scanline.
SUMMARY OF THE OLD TEXT: XVIDEO is an NTSC driver I'm making for the HX512K Memory expansion card. It uses counters for nearly all operations on the SRAM (only exceptions being programming it initially and loading addresses). There have been problems with keeping counters in sync etc. In the previous thread was a test program too, just to see if the rasterizer driver's counters would keep in sync.
EDIT: Removed some old text which is not valid anymore
Post Edited (Jasper_M) : 9/17/2007 4:29:37 PM GMT
800 x 533 - 56K
Comments
The color cycling suggests to me, you've got it, but I just don't quite understand it! (Hoping that's the case, really.)
Any chance you might have a quick moment to make some suggestions before you take off?
In a nutshell, propeller standard colors are always consistant. Artifacted colors are not. Resetting the prop, often results in a different set of colors.
I've got the problem with resetting the prop causing colors change only when left overscan is not divisible by the pixel clock - eg. if 1 pixel is 12 color clocks and overscan is 256 pixels (I'm not quite sure why, but that's what I've learned by trial & error).
To get the clock strobe synchronized the real solution was to set the clock strobe as output on the exactly right moment. This is done by using smaller color clock (VSCL of 8 if I recall) to fine-tune the moment when the OR DIRA, #c_strobe_mask occurs (and adding same kind of fine-tuning to turning it off).
The color-cycling trick works because the phase of the input voltage of the TV is mapped to a certain color at a certain point in time, and that point is determined by the color-burst. So if the phase of colorburst is shifted, all hues will change.
And something between the vertical syncs there's a piece of code like this (it must be a lot before the code where CTRB is used, because it'll take some time for the PLL to stabilize to the new phase):
cmp phsa_threshold, phsa wc if_c mov phsb, #0That synchronizes the counters so they don't slowly shift off sync. Without that, removing the crystal a few times could get the counters easily off sync, but with it it works anyway.
That helps a ton actually. Essentially, there is a difference between the PLL and the system clock that gets worked out, if the back porch is a multiple of the pixel clock. I think I can get there, thanks.
And the term back-porch is used for a part of HSYNC, that's blacker than black while overscan is the unused region of active pixel data.
And here's a tip: For debugging purposes, experiment with your code using both checkerboard patterns and also with even and odd scanlines in different color. Checkerboard patterns help to find really small offsets in the clock, while full single-color scanlines help diagnosing if you're reading too much from the HX512K or too little (if the diagonal error is from bottom-right to lower-left, you're reading too much, if it's opposite, too little). This of course applies only to developing for HX512K or any other device that uses CTRB or something as a clock.
Edit: You nailed my problem! Thanks. Making a simple timing change does the trick. I'll go back and do the other piece too, but I'm not sure why it's needed exactly...
Post Edited (potatohead) : 6/12/2007 5:40:45 AM GMT
I tried it several times with resets and power cycling and it never syncs for me. I'm using a Curtis RT700 LCD TV. So far it has performed well with all other Hydra apps. Anything I should tweak to see if it syncs?
You mean there's problems with the TV signal itself, not the image content (checkerboard)? I'm going to test it on LCD when I get home.
It may not be needed, depending on the rest of the code... If it works (on other Props too), you have no problem...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Umm, there are only 2 levels of saturation, color and black and white (saturation means colourfulness, ie. how far the color is from grayscales), only the hue (is it red, green or what color) changes - and change must be applied to the whole picture (or per scanline, but I see no use for that).
And 84 is the standard amount of colors supported by hi-color drivers.
Here is a screen shot of what I am seeing.
Oops, I have too long HSYNC ... I'll edit this thread soon and include a new test, ok?
No, that's perfect. ^_^Thank you ^_^b today I can begin with rendering code \o/
It was only the first demo that had a checkerboard pattern...
I don't have an SRAM card YET, but was curious.
Baggers.
Well, yes., it's practically impossible - or at least very very very hard.
1) it'd be very hard to get the 2 cogs synchronized so that they wouldn't try to access the bus simultaneously. It'd be possible though.
2) (the bigger problem) the SRAM has an internal address counter that usually increments after a read/write. that means that if 2 cogs would access the ram simultaneously, there'd have to be some scheme to handle the change in SRAM address counter. One solution could be interleaved buffers (1 byte for cog 1, next byte for cog 2 ...). Or loading (latching) the address every time - but that negates all the speed bonus, so it's out of question. What I'm going to do here is to write and read in turns - rasterizing cog (the one outputting video) reads during the scanline and the one rendering the scanlines writes during HSYNCs.
The bottom line is that a scheme to synchronize ram access is needed as well as a scheme to control the SRAM address counter.
EDIT: if you plan on using the SRAM to store game data and access it while it's still being used as video buffer, it could be easily done on VSYNC, 60 times every second.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
My goal is to make an gfx engine with tilemaps and sprites and high color in only two cogs. And I'm pretty sure that I'll succeed ^_^
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Realize that I am really a mad scientist··· and
Don't forget it!
http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg
·
Andre'
Just as I thought basically, awkward, just needs a new workaround [noparse]:)[/noparse]
There's also some code in there to render the full pallet in an organized arrangement; you can un-comment it (and comment the random squares code out) if you want to see the whole pallet all at once to tweak your TV's color settings (or just run REM_color_chart_010 (from the hydra CD) which displays the same colors).
Just in case you're reading this and missed the point, Remi's demo shows all 86 colors at once by carefully assigning a tile pallet and using a tile based engine to draw the full color pallet in squares which are exactly aligned to the tile boundaries, whereas with the E512K and Jasper's driver it is possible to arbitrarily color any pixel on the screen with any of the 86 palette colors.
In a nutshell, this path will ultimately open the door for pixel drawn (i.e. like SpaceWar!, as opposed to sprite based like DonkeyKong) E512 games which use the full pallet. What remains is to create a page swapping scheme (so that one page can be rendered to the screen while another page is used to draw the next game frame) and an arbitration method to allow drawing and rendering to occur pseudo concurrently.
Post Edited (epmoyer) : 6/16/2007 5:54:40 AM GMT
It will be nice to have a full on pixel mode display buffer. The on the fly stuff is interesting, but I think this will open up more game options for more people, given the drivers boil down to an easy to use package.
What's the draw time? How many bytes / scan line can be moved?
And my driver won't be pixel based. I will release a version of the rasterizing driver that makes it easy to build an own driver...
The driver I'm making is going to be a tile+sprite based driver. the idea is that it will render the frames 12FPS, not 60FPS so it'd be like rendering with 5 cogs while actually using only 1 for rendering.
So why is it hard to make a pixel based driver? Because I'm accessing the SRAM completely linearly. The cycle will be like this:
READ AND DRAW A SCANLINE
WRITE A SCANLINE (SCANLINE NUMBER 0)
READ AND DRAW A SCANLINE
SKIP A SCANLINE (FAST-FORWARD THE MEMORY)
READ AND DRAW A SCANLINE
SKIP A SCANLINE (FAST-FORWARD THE MEMORY)
READ AND DRAW A SCANLINE
SKIP A SCANLINE (FAST-FORWARD THE MEMORY)
READ AND DRAW A SCANLINE
WRITE A SCANLINE (SCANLINE NUMBER 4)
So I'm not rendering scanlines sequentially. If you'd want to render sequentially, you'd have to use VBLANK period for rendering, I'm using only the active video+hsync. Sequential rendering is needed to keep scanline state - eg. for line-drawing algorithms and such.
epmoyer, I assume you are making a video driver for the HX512K. If you want to use the XVIDEO rasterizer, I'd like to hear requests or something so I could make a specialized version?
EDIT: Try this with the code epmoyer posted, use the palette code and add this in the first function, after the cognew and assignment to s_ras_cmd:
repeat s_ras_colorburst_shift++ waitcnt(cnt+80_000_000/12)Post Edited (Jasper_M) : 6/16/2007 9:41:48 AM GMT
Baggers.
Yeah, sure; If you're not headed down the pixel based path then I will.
I don't need anything specific. You've got all the guts there to read bytes and generate a full color NTSC signal. I can munge it into what I need. The challenge of course is arbitrating for the SRAM between the drawing functions and the rendering functions. I'll be using the Extended Address Mode version of the E512K PLD (from http://forums.parallax.com/showthread.php?p=656146) so that I can support two 42K pages with rapid random access times for double buffered video.
I have no idea! In Jasper's demo (and my modified version) the pixel buffer gets drawn in its entirety first, then the renderer is fired up to display it. Drawing and rendering don't happen concurrently. I'm thinking perhaps the renderer will need to cache a scan line into local cog RAM and then the draw engine can write SRAM in the down time during each horizontal line, or perhaps the draw engine will have to run in the vertical blank. Or both. I haven't spun the numbers yet. Achievable frame rate will depend on how much time the draw engine can get to clear the inactive page, and then draw a reasonable amount of stuff.
I'd love to be able to trick some hardware "block fill" assist into the PLD but I'm sure I'll be able to wrangle the space for that. It sure would be nice to be able to blank the inactive page quickly.