Shop OBEX P1 Docs P2 Docs Learn Events
PROJECT: XVIDEO Driver For HX512K (UPDATED TOOL NO LZ YET) — Parallax Forums

PROJECT: XVIDEO Driver For HX512K (UPDATED TOOL NO LZ YET)

Jasper_MJasper_M Posts: 222
edited 2010-01-27 17:38 in Propeller 1
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:
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
«13

Comments

  • epmoyerepmoyer Posts: 314
    edited 2007-06-11 17:51
    I'm game; I'll give it a shot when I get home tonight.
  • potatoheadpotatohead Posts: 10,261
    edited 2007-06-11 18:37
    I looked through your code and am wondering if somehow that write one pixel with the overscan color trick can be used to address the timing issue on my high-color demo program. I've tried syncing up the video generator, and so far have not had much luck. I'm gonna take a deeper look through your program this evening, hoping to understand how pixels are being generated better.

    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.
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-11 18:55
    potatohead said...
    I looked through your code and am wondering if somehow that write one pixel with the overscan color trick can be used to address the timing issue on my high-color demo program. I've tried syncing up the video generator, and so far have not had much luck. I'm gonna take a deeper look through your program this evening, hoping to understand how pixels are being generated better.

    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.
    Ok, if you read the code, I'm gonna warn you that there are some comments left from an older driver test w/ bigger resolution and I've also moved stuff around so some comments are out of the place (of course you can ask me if there's something confusing)

    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, #0                                                                                                           
    
    

    That 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.
  • potatoheadpotatohead Posts: 10,261
    edited 2007-06-11 19:39
    Nice!

    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.
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-11 19:50
    potatohead said...
    Nice!

    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.
    Oh, I got pretty stable 12-pixel clock video already. Here's what did the trick: the total scanline clocks·47*16 for colorburst plus 3008 for active scanline is not a multiple of 12: (3008+47*16)/12 = 313,33333333333333333333333333333. So I changed the 47 from HSYNC· to 46,· (3008+46*16)/12 = 312.

    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.
  • potatoheadpotatohead Posts: 10,261
    edited 2007-06-11 21:45
    Got it on the back porch bit. I lumped it all together, thanks. Appreciate the timing hints too. I was taking the wrong approach, and it's nice to know that [noparse]:)[/noparse]

    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
  • epmoyerepmoyer Posts: 314
    edited 2007-06-12 04:12
    Jasper,

    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?
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-12 06:07
    epmoyer said...
    Jasper,

    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.
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-12 06:09
    potatohead said...
    Got it on the back porch bit. I lumped it all together, thanks. Appreciate the timing hints too. I was taking the wrong approach, and it's nice to know that [noparse]:)[/noparse]

    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...

    It may not be needed, depending on the rest of the code... If it works (on other Props too), you have no problem...
  • edited 2007-06-12 14:29
    So, it has 84 colors and generates different saturations when the color cycle happens... wow. how many different saturations are there in this program if you count the color wave/cycle?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Realize that I am really a mad scientist··· and


    Don't forget it!

    http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg

    ·
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-12 14:51
    Bob the Builder on a C64 said...
    So, it has 84 colors and generates different saturations when the color cycle happens... wow. how many different saturations are there in this program if you count the color wave/cycle?

    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.
  • epmoyerepmoyer Posts: 314
    edited 2007-06-12 15:13
    Jasper,

    Here is a screen shot of what I am seeing.
    1024 x 768 - 270K
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-12 15:19
    epmoyer said...
    Jasper,

    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?

    Oops, I have too long HSYNC ... I'll edit this thread soon and include a new test, ok?
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-12 16:01
    UPDATED. (in first post, 224px, fixed the HSYNC)
  • epmoyerepmoyer Posts: 314
    edited 2007-06-12 16:04
    Thanks. I'm at work again now so I'll give it another shot when I get home tonight.
  • epmoyerepmoyer Posts: 314
    edited 2007-06-13 03:25
    Image is stable now, but I thought it was supposed to look like a checkerboard and it does not. I see lots of horizontal mustard colored lines. Multiple resets and power cycles yield the same result.
    1024 x 768 - 370K
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-13 05:59
    epmoyer said...
    Image is stable now, but I thought it was supposed to look like a checkerboard and it does not. I see lots of horizontal mustard colored lines. Multiple resets and power cycles yield the same result.

    No, that's perfect. ^_^Thank you ^_^b today I can begin with rendering code \o/
    Me said...
    Horizontal lines and one thick vertical bar this time.

    It was only the first demo that had a checkerboard pattern...
  • BaggersBaggers Posts: 3,019
    edited 2007-06-13 08:53
    Just out of curiosity, ( this is probably more for Andre' ) while one cog is bashing the ram in sequential access for speed, does that mean, that no other cog will have access to it?
    I don't have an SRAM card YET, but was curious.
    Baggers.
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-13 10:15
    Baggers said...
    Just out of curiosity, ( this is probably more for Andre' ) while one cog is bashing the ram in sequential access for speed, does that mean, that no other cog will have access to it?
    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.
  • edited 2007-06-13 18:25
    What is your goal for this program? I'm not sure what your trying to do! confused.gif

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Realize that I am really a mad scientist··· and


    Don't forget it!

    http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg

    ·
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-13 19:25
    Bob the Builder on a C64 said...
    What is your goal for this program? I'm not sure what your trying to do! confused.gif

    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 ^_^
  • edited 2007-06-13 19:44
    Good idea! [noparse]:D[/noparse] But, why do you call it High color if it's not using the full 86 color pallete?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Realize that I am really a mad scientist··· and


    Don't forget it!

    http://raydillon.com/Images/Illustration/GameArt/WildIsle/WildIsle-Ink-ScientistClose.jpg

    ·
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-13 20:05
    Bob the Builder on a C64 said...
    Good idea! [noparse]:D[/noparse] But, why do you call it High color if it's not using the full 86 color pallete?
    It is using the full palette. I just didn't remember how many colors we're full color : P. The rasterizer definitely supports all 86 colors.
  • AndreLAndreL Posts: 1,004
    edited 2007-06-13 22:50
    Two cogs could read from the memory seperately, but you would have to make sure that the IO is set for input on both, etc. since really the bottle neck is there are only one set of IO lines going to the interface, so two people can't write/read at the same time. But, you could write a driver that was multi cog friendly and use a message passing mechanism to make sure that one cog was done with the memory etc. and you could sync them up for specific operations like fast reading etc.

    Andre'
  • BaggersBaggers Posts: 3,019
    edited 2007-06-14 08:57
    Thanks Jasper_M and Andre'
    Just as I thought basically, awkward, just needs a new workaround [noparse]:)[/noparse]
  • epmoyerepmoyer Posts: 314
    edited 2007-06-16 05:38
    Here's a demo that I've been wanting to see since I heard of the E512K. This is a screen full of randomly placed squares of random colors using the full "standard" 86 color Hydra pallet. The source code is based on Jasper's JAM_XVIDEO_RAS_001.spin post; I modified the draw code but the rendering code is untouched.

    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
  • potatoheadpotatohead Posts: 10,261
    edited 2007-06-16 08:18
    Excellent work!

    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?
  • Jasper_MJasper_M Posts: 222
    edited 2007-06-16 09:32
    Wow, epmoyer that's cool ^_^b I wanted to make my test program draw the palette but didn't have time to do that...

    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
  • BaggersBaggers Posts: 3,019
    edited 2007-06-16 13:32
    Jasper, I like your approach [noparse]:)[/noparse] it should be interesting to see the outcome [noparse]:)[/noparse] Can't wait...

    Baggers.
  • epmoyerepmoyer Posts: 314
    edited 2007-06-16 14:48
    Jasper said...
    epmoyer, I assume you are making a video driver for the HX512K.

    Yeah, sure; If you're not headed down the pixel based path then I will.
    Jasper said...
    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?

    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.

    potatohead said...
    What's the draw time? How many bytes / scan line can be moved?
    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.
Sign In or Register to comment.